Kafka 0.8 Consumer设计解析

摘要

　　本文主要介绍了Kafka High Level Consumer，Consumer Group，Consumer Rebalance，Low Level Consumer实现的语义，以及适用场景。以及未来版本中对High Level Consumer的重新设计–使用Consumer Coordinator解决Split Brain和Herd等问题。
　　
　　

1.High Level Consumer

很多时候，客户程序只是希望从Kafka读取数据，不太关心消息offset的处理。同时也希望提供一些语义，例如同一条消息只被某一个Consumer消费（单播）或被所有Consumer消费（广播）。因此，Kafka Hight Level Consumer提供了一个从Kafka消费数据的高层抽象，从而屏蔽掉其中的细节并提供丰富的语义。　　

1.1 Consumer Group

　High Level Consumer将从某个Partition读取的最后一条消息的offset存于Zookeeper中。这个offset基于Consumer Group来识别的。Consumer Group是整个Kafka集群全局的，而非某个Topic的。每一个High Level Consumer实例都属于一个Consumer Group。
　

(Kafka从0.8.2版本开始同时支持将offset存于Zookeeper中与将offset存于专用的Kafka Topic:__consumer_offsets中)

　Zookeeper中Consumer相关节点如下图所示

为了实现传统Message Queue消息只被消费一次的语义，Kafka保证每条消息在同一个Consumer Group里只会被某一个Consumer消费。与传统Message Queue不同的是，Kafka还允许不同Consumer Group同时消费同一条消息，这一特性可以为消息的多元化处理提供支持。

Kafka的设计理念之一就是同时提供离线处理和实时处理。

1.2 High Level Consumer Rebalance

（本节所讲述Rebalance相关内容均基于Kafka High Level Consumer-0.8版本的）
Rebalance的触发条件，自己复习复习。

Consumer Rebalance的算法如下：

将目标Topic下的所有Partirtion排序，存于Pt
对某Consumer Group下所有Consumer排序，存于Cg，第i个Consumer记为Ci
N = size(Pt) / size(Cg)，向上取整
解除Ci对原来分配的Partition的消费权（i从0开始）
将第i∗N到（i+1）∗N−1个Partition分配给Ci

最新版（0.8.2.1）Kafka的Consumer Rebalance的控制策略是由每一个Consumer通过在Zookeeper上注册Watch完成的。每个Consumer被创建时会触发Consumer Group的Rebalance，具体启动流程如下：

High Level Consumer启动时将其ID注册到其Consumer Group下，在Zookeeper上的路径为/consumers/[consumer group]/ids/[consumer id]
在/consumers/[consumer group]/ids上注册Watch
在/brokers/ids上注册Watch
如果Consumer通过Topic Filter创建消息流，则它会同时在/brokers/topics上也创建Watch
强制自己在其Consumer Group内启动Rebalance流程

在这种策略下，每一个Consumer或者Broker的增加或者减少都会触发Consumer Rebalance。因为每个Consumer只负责调整自己所消费的Partition，为了保证整个Consumer Group的一致性，当一个Consumer触发了Rebalance时，该Consumer Group内的其它所有其它Consumer也应该同时触发Rebalance。

该方式有如下缺陷：

Herd effect
　　任何Broker或者Consumer的增减都会触发所有的Consumer的Rebalance
Split Brain
　　每个Consumer分别单独通过Zookeeper判断哪些Broker和Consumer 宕机了，那么不同Consumer在同一时刻从Zookeeper“看”到的View就可能不一样，这是由Zookeeper的特性决定的，这就会造成不正确的Reblance尝试。
调整结果不可控
　　所有的Consumer都并不知道其它Consumer的Rebalance是否成功，这可能会导致Kafka工作在一个不正确的状态。

1.3 Coordinator

当前版本的High Level Consumer存在Herd Effect和Split Brain的问题。如果将失败探测和Rebalance的逻辑放到一个高可用的中心Coordinator，那么这两个问题即可解决。同时还可大大减少Zookeeper的负载，有利于Kafka Broker的Scale Out。

每一个Broker将被选举为某些Consumer Group的Coordinator。某个Cosnumer Group的Coordinator负责在该Consumer Group的成员变化或者所订阅的Topic的Partititon变化时协调Rebalance操作。

Consumer状态机

Down：Consumer停止工作
Start up & discover coordinator：Consumer检测其所在Group的Coordinator。一旦它检测到Coordinator，即向其发送JoinGroupRequest。
Part of a group：该状态下，Consumer已经是该Group的成员，并周期性发送HeartbeatRequest。如HeartbeatResponse包含IllegalGeneration错误码，则转换到Stopped Consumption状态。若连接丢失，HeartbeatResponse包含NotCoordinatorForGroup错误码，则转换到Rediscover coordinator状态。
Rediscover coordinator：该状态下，Consumer不停止消费而是尝试通过发送ConsumerMetadataRequest来探测新的Coordinator，并且等待直到获得无错误码的响应。
Stopped consumption：该状态下，Consumer停止消费并提交offset，直到它再次加入Group。

3.Low Level Consumer

　　使用Low Level Consumer (Simple Consumer)的主要原因是，用户希望比Consumer Group更好的控制数据的消费。比如：

同一条消息读多次
只读取某个Topic的部分Partition
管理事务，从而确保每条消息被处理一次，且仅被处理一次

与Consumer Group相比，Low Level Consumer要求用户做大量的额外工作。

必须在应用程序中跟踪offset，从而确定下一条应该消费哪条消息
应用程序需要通过程序获知每个Partition的Leader是谁
必须处理Leader的变化

使用Low Level Consumer的一般流程如下

查找到一个“活着”的Broker，并且找出每个Partition的Leader
找出每个Partition的Follower
定义好请求，该请求应该能描述应用程序需要哪些数据
Fetch数据
识别Leader的变化，并对之作出必要的响应

如果kafka partition 的leader发生了切换，是如何影响正在消费的consumer的？

consumer监听了topicPartition的更新，所以可以正常的切换到新的leader。有offset的存在，high water的存在，从上次的 offset 开始读，那就不会有不一致的问题。
所以在一般正常情况下，当 kafka 发生 failover 的时候，consumer 是不会读到不一致数据的。特例的情况就是，当前 leader 是唯一有效的 replica，其他replica都处在完全不同步状态，这样发生 leader 切换，一定是会丢数据的，并会发生 offset 不一致。