《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集群以及消费组编号。

 

posted @ 2018-08-23 17:50  __Meng  阅读(407)  评论(0编辑  收藏  举报