第1章：初始Kafka

数据为企业的发展提供动力。我们从数据中获取信息对它们进行分析处理然后生成更多的数据。每个应用程序都会产生数据包括日志消息、度量指标、用户活动记录、响应消息等。数据的点点滴滴都在暗示一些重要的事情比如下一步行动的方向。我们把数据从源头移动到可以对它们进行分析处理的地方然后把得到的结果应用到实际场景中这样才能够确切地知道这些数据要告诉我们什么。比如我们在淘宝网站上浏览感兴趣的商品浏览信息被转化为商品推荐并展示给我们。发布与订阅消息系统数据的发送者不会直接把消息发送给接收者这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类接收者订阅它们以便收到特定类型的消息。发布者与订阅者之间一般会有一个 broker也就是发布消息的中心点。如何开始发布与订阅消息系统的大部分应用场景都是从一个简单的消息队列或一个进程间通道开始的。例如你的程序需要往特别的地方发送监控信息你可以直接在应用程序或另一个可以在仪表盘上显示度量指标的应用程序之间建立联系然后通过这个连接推送度量指标。Kafka登场Kafka就是为了解决上述问题而设计的一款基于发布与订阅的消息系统它一般被称为分布式提交日志或者分布式流处理平台。文件系统或数据库提交日志用来提供所有事务的持久记录通过重放这些日志可以重建系统状态。同样的Kafka的数据是按一定顺序持久化保存的可以按需读取。此外Kafka的数据分布在整个系统里具有数据故障保护和性能伸缩能力。消息和批次Kafka的数据单元被称为消息为了提高效率消息被分批次写入 Kafka批次就是一组消息这些消息属于同一个主题和分区。如果每个消息都单独传输会导致大量网络开销。把消息分批次传输可以减少网络开销不过这要在时间延迟和吞吐量之间做出权衡。批次越大单位时间内处理的消息就越多单个消息的传输时间就越长。批次里数据会被压缩这样可以提升数据传输和存储能力但需要做更多的计算。主题和分区Kafka的消息通过主题进行分类主题就好比数据库表或者文件系统里面的文件夹。主题可以被分为若干个分区一个分区就是一个日志提交。消息以追加的形式写入分区中然后以先入先出的顺序读取。生产者和消费者Kafka客户端就是Kafka系统用户它被分为两种类型生产者和消费者。此外还有一些高级客户端API用于数据集成包括 Kafka Connect API 和用于流处理的Kafka Stream这些高级客户端API使用生产者和消费者作为内部组件提高了高级功能。生产者创建消息在其他发布与订阅系统中生产者可以被称为发布者或写入者。一般情况下一个消息会被发布到一个特定的主题上生产者在默认情况下把消息均匀地分布在所有主题上而不会特地关心写到哪个分区。不过在某些特定情况下生产者会把消息直接写到特定的分区。这通常与消息键和分区器来实现分区序为键生成的一个散列值并将其映射到指定的分区上这样可以保证同一个键的消息会被写到同一个分区上。生产者也可以自定义分区器根据不同的业务规则将消息映射到分区。消费者读取消息在其他发布与订阅系统中消费者可以被称为订阅者或者读者。消费者订阅一个或多个主题并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读过的消息。偏移量是另一种元数据它是一个不断递增的数据值在创建消息时Kafka会把它添加到消息里再给指定的分区里每个消息的偏移量都是唯一的。消费者把每个分区最后读取的偏移量保存在Zookeeper 或Kafka上。如果消费者关闭或重启它的读取状态不会丢失Broker 和 集群一个单独的 Kafka 服务器被称为 BrokerBroker 接收来自生产者的消息为消息设置偏移量并提交消息到磁盘保存。Broker 为消费者提供服务对读取分区和请求做出响应返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征单个 broker 可以轻松地处理几千个分区以及几百万的消息量。broker 是集群的组成部分。每个集群都有一个 broker 同时充当了集群控制器的角色自动从集群的活跃成员中选举出来。控制器负责管理工作包括将分区分配给 broker 和监控 broker。在集群中一个分区从属于一个 broker该 broker 被称为分区的首领。一个分区可以分配给多个 broker这个时候会发生分区复制见图 1-7。这种复制机制为分区提供了消息冗余如果有一个 broker 失效其他 broker 可以接管领导权。不过相关的消费者和生产者都要重新连接到新的首领。为什么选择Kafka多个生产者Kafka 可以无缝地支持多个生产者不管客户端在使用单个主题还是多个主题。所以它很适合用来从多个前端系统收集数据并以统一的格式对外提供数据。例如一个包含了多个微服务的网站可以为页面视图创建一个单独的主题所有服务都以相同的消息格式向该主题写入数据。消费者应用程序会获得统一的页面视图而无需协调来自不同生产者的数据流。多个消费者除了支持多个生产者外Kafka 也支持多个消费者从一个单独的消息流上读取数据而且消费者之间互不影响。这与其他队列系统不同其他队列系统的消息一旦被一个客户端读取其他客户端就无法再读取它。另外多个消费者可以组成一个群组它们共享一个消息流并保证整个群组对每个给定的消息只处理一次。基于磁盘的数据存储Kafka 不仅支持多个消费者还允许消费者非实时地读取消息这要归功于 Kafka 的数据保留特性。消息被提交到磁盘根据设置的保留规则进行保存。每个主题可以设置单独的保留规则以便满足不同消费者的需求各个主题可以保留不同数量的消息。消费者可能会因为处理速度慢或突发的流量高峰导致无法及时读取消息而持久化数据可以保证数据不会丢失。消费者可以在进行应用程序维护时离线一小段时间而无需担心消息丢失或堵塞在生产者端。消费者可以被关闭但消息会继续保留在 Kafka 里。消费者可以从上次中断的地方继续处理消息。伸缩性为了能够轻松处理大量数据Kafka 从一开始就被设计成一个具有灵活伸缩性的系统。用户在开发阶段可以先使用单个 broker再扩展到包含 3 个 broker 的小型开发集群然后随着数据量不断增长部署到生产环境的集群可能包含上百个 broker。对在线集群进行扩展丝毫不影响整体系统的可用性。也就是说一个包含多个 broker 的集群即使个别 broker 失效仍然可以持续地为客户提供服务。要提高集群的容错能力需要配置较高的复制系数。高性能上面提到的所有特性让 Kafka 成为了一个高性能的发布与订阅消息系统。通过横向扩展生产者、消费者和 brokerKafka 可以轻松处理巨大的消息流。在处理大量数据的同时它还能保证亚秒级的消息延迟。