Kafka--初识Kafka
前言
数据为企业的发展提供动力。我们从数据中获取信息，对他们进行分析处理，然后生成更多的数据。每个应用程序都会产生数据，包括日志消息，度量指标，用户活动记录，响应消息等。数据的点点滴滴都在暗示一些重要的事情，比如下一步行动的方向。我们把数据从源头移动到可以对它们进行分析处理的地方，然后把得到的结果应用到实际场景中，这样才能够确切地知道这些数据要告诉我们什么。例如我们在Amazon网站上浏览感兴趣的商品，浏览信息被转化成商品推荐，并在稍后展示给我们。
这个过程完成的越快，组织的反应就越敏捷。花费越少的精力在数据移动上，就能越专注于核心业务。这就是为什么在一个以数据为驱动的企业里，数据管道会成立关键性组件。如何移动数据，几乎变得与数据本身一样重要。
发布与订阅消息系统
数据的发送者不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者订阅它们，以便接收特定类型的消息。
发布与定于系统一般会有一个broker，也就是发布消息的中心点。
Kafka概念
Kafka是一款基于发布与订阅的消息系统，它一般被称为分布式提交日志或者分布式流平台。
文件系统或数据库提交日志用来提供所有事务的持久记录，通过重放这些日志可以重建系统的状态。同样地，Kafka的数据分布在整个系统里，具备数据故障保护和性能伸缩能力。
Kafka的设计目的是提供一个高性能的消息系统，可以处理多种数据类型，并能够实时提供纯净且结构化的用户活动数据和系统度量指标。
消息和批次
Kafka的数据单元被称为消息。
消息类溢余数据库里的一个数据行或一条记录。消息由字节数组组成，所以，对于Kafka来说，消息里的数据没有特别的格式或含义。
消息可以有一个可选的元数据，也就是键。键也是一个字节数组，键一般用来进行分区选择。
为了提高效率，消息被分批次写入Kafka。
批次就是一组消息，这些消息属于同一个主题和分区。
如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。
不过，这要在时间延迟和吞吐量之间做出权衡：批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但要做更多的计算处理。
模式
消息模式有许多可用的选项。如JSON和XML，不仅易用，而且可读性好。不过，它们却反强类型处理能力，不同版本之间的兼容性也不是很好。
Kafka的许多开发者喜欢使用Apache Avro，它最初是为Hadoop开发的一款序列化框架。
Avro提供了一种紧凑的序列化格式，消息和消息体是分开的，当模式发生变化时，不需要重新生成代码。
它还支持强类型和模式进化，其版本既向前兼容，也向后兼容。
数据格式的一致性对于Kafka来说很重要，它笑出了消息读写操作之间的耦合性。如果读写操作紧密地耦合在一起，消息订阅者需要升级应用程序才能同时处理新旧两种数据格式。
定义良好的模式，并把它们存放在公共仓库，可以方便我们理解Kafka的消息结构。
主题和分区
Kafka的消息通过主题进行分类。主题就好比数据库的表，或者文件系统里的文件夹。
主题可以被分成若干个分区，一个分区就是一个提交日志。
消息一追加的方式写入分区，然后以先入先出的顺序进行读取。
由于一个主题包含多个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。
Kafka通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上，也就是说，一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。
生产者和消费者
Kafka的客户端有两种基本类型：生产者和消费者。除此之外还有其他高级客户端--用于数据集成的Kafka Connect API和用于流式处理的Kafka Streams，这些高级客户端API使用生产者和消费者作为内部组件，提供了高级的功能。
生产者创建消息。
一般情况下，一个消息会被发布到一个特定的主题上。生产者在默认情况下把消息均匀地分布到主题的所有分区上，而不关心特定消息会被写到哪个分区。
不过，在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。
这样可以保证包含同一个键的消息会被写到同一个分区上。
生产者也可以使用自定义的分区器，根绝不同的业务规则将消息映射到分区。
消费者读取消息。
消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。
消费者通过检查消息的偏移量来区分已经读取过的下次。
偏移量是一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。
在给定的分区里，每个消息的偏移量都是唯一的。
消费者把每个分区最后读取的消息偏移量保存在Zookeeper或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。
消费者是消费者群组的一部分，也就是说，会有一个或多个消费者共同读取一个主题。
群组保证每个分区只能被一个消费者使用。
消费者与分区之间的映射通常被称为消费者对分区的所有权关系。
多个消费者组成的消费者群组可以消费包含大量消息的主题。而且，如果一个消费者失效，群组里的其他消费者可以接管失效消费者的工作。
多个生产者
Kafka可以无缝地支持多个生产者，不管客户端在使用单个主题还是多个主题。
所以它很适合用来从多个前端系统收集数据，并以统一的格式对外提供数据。
多个消费者
Kafka也支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。
这与其他消息队列不同，其他队列系统的消息一旦被一个客户端读取，其他客户端就无法再读取它。
多个消费者可以组成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。
broker和集群
一个独立的Kafka服务器被称为broker。
broker接受来自生产者的消息，为消息设置偏移量，并保存消息到磁盘保存。
broker为消费者提供服务，对读取分区的请求作出相应，返回已经提交到磁盘上的消息。
根据特定的硬件及其性能特征，单个broker可以轻松处理数千个分区以及每秒百万级的消息量。
broker是集群的组成部分。
每个集群都有一个broker同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。
控制器负责管理工作，包括将分区分配给broker和监控broker。
在集群中，一个分区从属于一个broker，该broker被称为分区的首领。
一个分区可以分配给多个broker，这个时候会发生分区复制。这种复制机制为分区提供了消息冗余，如果有一个broker失效，其他broker可以接管领导权。
不过，相关的消费者和生产者都要重新连接到新的首领。
消息保留
保留消息（在一定期限内）是Kafka的一个重要特性。
Kafka broker默认的消息保留策略是：
要么保留一段时间（比如7天）；
要么保留到消息达到一定大小的字节数（比如1GB）。
当消息数量达到这些上限时，就消息就会过期并被删除，所以在任何时刻，可用消息的总量都不会超过配置参数所指定的大小。
主题可以配置自己的保留策略，可以将消息保留到不再使用它们为止。
可以通过配置把主题当做紧凑型日志，只有最后一个带有特定建的消息会被保留下来。这种情况对于变更日志类型的数据来说比较适用，因为人们之关心最后时刻发生的那个变更。
伸缩性
Kafka从一开始就被设计成一个具有灵活伸缩性的系统。对在线集群进行扩展四号不影响整体系统的可用性。
高性能
通过横向扩展生产者，消费者和broker，Kafka可以轻松处理巨大的消息流。在处理大量数据的同时，它还能保证亚秒级的消息延迟。
数据生态系统
Kafka为数据生态系统带来了循环系统。他在基础设置的各个组件之间传递消息，为所有客户端提供一致的接口。
当与提供消息模式的系统集成时，生产者和消费者之间不再有紧密地耦合，也不需要在它们之间建立任何类型的直连。
我们可以根据业务需要添加或移除组件，因为生产者不再关心谁在使用数据，也不关心有多少个消费者。
使用场景
活动跟踪
Kafka最初的使用场景是跟踪用户的活动。
网站用户与前端应用程序发生交互，前端应用程序生成用户活动相关的消息。这些消息可以是一些静态的消息，比如页面访问次数和点击量，也可以是一些复杂的操作，比如添加用户资料。
这些消息被发布到一个或多个主题上，由后端应用程序负责读取。这样，我们就可以生成报告，为机器学习系统提供数据，更新搜索结果，或者实现其他更多的功能。
传递消息
Kafka的另一个基本用途是传递消息。
应用程序向用户发送通知（比如邮件）就是通过传递消息来实现的。
这些应用程序组件可以生成消息，而不需要关心消息的格式，也不需要关心消息是如何被发送的。一个公共应用程序会读取这些消息，对它们进行处理。
格式化消息（也就是所谓的装饰）
将多个消息放在同一个通知里发送
根据用户配置的首选项来发送数据
使用公共组件的好处在于，不需要在多个应用程序上开发重复的功能，而且可以在公共组件上做一些有趣的转换，比如把多个消息聚合成一个单独的通知，而这些工作是无法在其他地方完成的。
度量指标和日志记录
Kafka也可以用于收集应用程序和系统度量指标以及日志。Kafka支持多个生产者的特性在这个时候就可以派上用场。
应用程序定期把度量指标发布到Kafka主题上，监控系统或告警系统读取这些消息。
Kafka也可以用在像Hadoop这样的离线系统上，进行较长时间片段的数据分析，比如年度增长走势预测。
日志消息也可以被发布到Kafka主题上，然后被路由到专门的日志搜索系统或安全分析应用程序。
更改目标系统不会影响到前端应用或聚合方法，这是Kafka的另一个优点。
提交日志
Kafka的基本概念来源于提交日志，所以使用Kafka作为提交日志是件顺理成章的事。
我们可以把数据库的更新发布到Kafka上，应用程序通过监控事件流来接收数据库的实时更新。
这种变更日志流也可以用于把数据库的更新复制到远程系统上，或者合并多个应用程序的更新到一个单独的数据库视图上。
数据持久化为变更日志提供了缓冲区，也就是说，如果消费者应用程序发生故障，可以通过重放这些日志来恢复系统状态。
另外，紧凑型日志主题只为每个键保留一个变更数据，所以可以长时间使用，不需要担心消息过期问题。
流处理
流处理是有一个能提供多种类型应用程序的领域。
可以说，它们提供的功能与Hadoop里的map和reduce有点类似，只不过它们操作的是实时数据流，而Hadoop则处理更长时间片段的数据，可能是几个小时或者几天，Hadoop会对这些数据进行批处理。
通过使用流式处理框架，用户可以编写小型应用程序来操作Kafka消息，比如计算度量指标，为其他应用程序有效的处理消息分区，或者对来自多个数据源的消息进行转换。
