《Kafka技术内幕》学习笔记

第一章 Kafka入门

1.1 Kafka流式数据平台

Kafka作为流式数据平台的特点：

　　消息系统：两种消息模型：队列和发布订阅。

　　　　队列模型：将处理工作平均分给消费组中的消费者成员。

　　　　发布订阅模型：将消息广播给多个消费组（consumer group）

　　队列模式（点对点模式）：多个消费者读取消息队列，每条消息只发给一个消费者。

　　发布订阅模式：多个消费者订阅主题，主题的每条记录会发布给所有消费者。

　　存储系统：数据写入Kafka集群的服务器节点时，会复制多份来保证出现故障时仍然可用。

为了保证消息的可靠性，允许生产者的生产请求在收到应答结果之前，阻塞地等待一条消息，直到它完全复制到多个节点，才认为这条消息写入成功。

　　流处理系统：提供了流处理API，比如流的聚合、连接、各种转换。

　　将消息系统、存储系统、流处理系统组合在一起。

1.2 Kafka的基本概念

分区模型：

　　Kafka集群由多个消息代理服务器（broker server）组成。

　　每条消息都有一个topic，一个topic一般会有多个消息的订阅者。

　　每个topic都有1到N个分区。

　　分区中每条消息都会按照顺序分配到一个编号，叫做偏移量（offset）。

　　每条消息包含键值和时间戳。

　　Kafka以分区为最小的粒度，确保一个分区只属于一个消费者。

　　每个topic有多个分区，不同消费者处理不同分区，保证了消息的有序性，也做到了消费者的负载均衡。

消费模型：

　　消息的消费模型有两种：推送模型和拉取模型。

　　推送模型：由消息代理记录消费者的状态。发送完消息后，状态为已发送，消费者确认收到后状态为已消费。

这种做法是不可取的，因为消息代理要记录所有消息的状态。

　　拉取模型：Kafka采用拉取模型，由消费者自己记录消费状态。

消费者控制偏移量：可以按任意顺序消费消息，可以重置到旧的偏移量。

生产者发布的消息会一直存在集群中，不管有没有被消费，用户可以设置保留时间来清理过期数据。

分布式模型：

　　每个分区会以副本的方式复制到多个消息代理节点上。

　　其中一个节点为主副本（leader），其他节点作为从副本（follower）。

　　主副本负责所有的读写，从副本仅从主副本同步数据。

　　当一个主副本出现故障时，其中一个从副本会成为新的主副本。

　　分区的主副本是均衡分布在各个节点上的。

　　分区是消费者线程模型的最小并行单位。

　　消息没有键时，通过轮询方式发布到不同分区，如果有键，相同键的消息总是发布到同一个分区。

　　当一个新消费者加入消费组时，或者消费者离开消费组，都会触发再平衡。

　　Kafka消费消息时，只保证分区内消息的有序性，并不保证主题中多个分区的消息顺序。

1.3 Kafka的设计与实现

　　生产者使用批量发送消息集的方式解决了网络请求过多的问题。生产者会一次发送一批数据。

　　消费者拉取消息也可以一次拉一批。

　　允许消费者的拉取请求以阻塞式，长轮询的方式等待，直到有新的数据到来。

　　一个消息只有被完全复制到所有副本，才会认为消息被成功提交。成功提交的消息才对消费者可见。

Kafka对节点存活的定义：

　　节点必须和ZK保持会话。

　　如果节点是某个分区的从副本，那么它必须对主副本的写操作进行复制，并且不能落后太多。

第二章 生产者

2.1 新生产者客户端

　　生产者要发送消息，并不是直接发送给服务端，而是先在客户端把消息放入队列中。然后由一个消息发送线程从队列中拉取消息，以批量的方式发送消息给服务端。

　　生产者发消息给Kafka集群，可以同时往多个服务端节点写数据。

　　如果指定了消息的键，对键进行散列之后，再与分区的数量取模得到分区编号。

为消息选择分区：

　　生产者可以将一批消息分成多个分区，每个分区写入不同的服务端节点。

　　在客户端就为消息选择分区：因为这样才知道应该发送到哪个节点。

客户端记录收集器：

　　生产者发送的消息先缓存到记录收集器（RecordAccumulator)，再由发送线程Sender批量写入Kafka集群。　

　　消息发送线程按照分区的目标节点发送。

　　在发送线程需要数据时，记录收集器能够按照节点将消息重新分组再交给发送线程。

　　发送线程并不负责发送客户端请求，它拿到消息后，会创建好客户端请求，然后把请求交给客户端网络对象去发送。

客户端网络连接对象（NetworkClient）：

　　发送线程的run（）会调用3个方法：

　　ready（）：从记录收集器获取准备完毕的节点，并连接所有准备好的节点。

　　send（）：为每个节点创建一个客户端请求。

　　poll（）：轮询动作会真正执行网络请求。

选择器处理网络请求：

　　选择器使用javaNIO异步非阻塞方式管理连接和读写请求，它用单线程就可以管理多个网络连接通道。

　　生产者客户端只用使用一个选择器，就可以和集群的多个服务端进行网络通信。

　　SocketChanmel（客户端网络连接通道）：底层的字节数据读写都发生在通道上。

　　Selector(选择器)：选择器通过选择键的方式监听读写事件的发生。

　　SelectionKey(选择键)：将通道注册到选择器上。

第三章 消费者

使用消费组实现消息队列的两种模式：

　　同一个分区只可被一个消费者处理，这样可以不加锁，提升消费者处理能力。

　　每个消费者都可以配置一个所属的消费组，并且订阅多个主题。

　　同一条消息会广播给多个消费，单播给同一组中的消费者。

消费组再平衡实现故障容错：

　　如果一个消费者宕机了，分配给这个消费者的分区要重新分给组内的其他消费者。

　　如果新加入了消费者，分区也得重新分配。

　　如果订阅主题的分区发生了变化，所有消费者也要再平衡。

　　再平衡是消费组中的所有消费者都要执行重新分配分区的动作。

　　如果再平衡前，消费者C1保存了分区P1的消费进度，再平衡后C2可以从保存的进度继续读取P1。

消费者保存消费进度：

　　消费者客户端要保存消费消息的偏移量，即消费进度。

　　消费进度应该面向消费组级别，保证再平衡后，别的消费者也能拿到这个分区的消费进度。

　　消费进度保存在ZK中。

消费者与ZK的关系：

　　ZK不仅保存了Kafka的内部元数据，而且记录了消费组的成员列表，分区的消费进度，分区的所有者。

　　高级API：消费者代码不需要管理偏移量的提交。并且采用了消费组的自动负载均衡，确保消费者的增减不会影响到消息的消费。

　　低级API：通常针对特殊逻辑，比如消费者只想消费特定分区。代码要实现选择分区的主副本等这些。

3.1 消费者启动和初始化

　　消费者的配置信息要指定连接的ZK集群以及消费组编号。