消费者组 Consumer Group 和 重平衡 Rebalance

kafka设计了consumer group： 具有可扩展性和容错性的consumer机制，consumer group有3个特性：

1. Consumer Group 下可以有一个或多个 Consumer 实例。
2. Consumer Group有唯一标识Group ID，它是一个字符串。
3. Consumer Group 下所有consumer订阅的主题的单个分区，但是只能分配给组内的某一个 Consumer消费。

如果只有1个group，那么就是点对点（消息队列）模型；如果有多个group，那么就实现了发布/订阅模型。

一般情况下，一个Group 下的consumer实例个数 应该等于该group订阅topic的分区总数。

那么，每个consumer实例负责哪个或者哪些分区呢？这里提个概念 Rebalance。

Rebalance是分配一致性协议，规定了所有的consumer如何达成共识，怎么去分配订阅topic的每个分区。

当group内consumer实例数发生变化、订阅的topic数发生变化、订阅的topic分区数发生变化，都会触发重平衡Rebalance。

心跳线程

每个消费者端都有个心跳线程（heartbeat thread），用来告知Coordinator组件’我还活着‘。

重平衡Rebalance的通知机制是通过心跳线程来完成的。当协调者决定开启新一轮重平衡后，它会将“REBALANCE_IN_PROGRESS”封装进消费者心跳请求的响应中，发还给消费者实例，来通知消费者要进行重平衡过程了。

kafka设计了消费者组状态机来协调完成整个Rebalance过程。

消费者组有5中状态：

Empty，Dead，Preparing Rebalance（加入组），Completing Rebalance（等待leader consumer的分配方案）， Stable（完成）

Rebalance的缺点是：

1. 在Rebalance过程中，所有的consumer实例都要停止消费，有点像jvm的垃圾回执机制stop the world。

2. 一旦Rebalance，所有的consumer实例都要重新分配分区，那么实例连接在broker上tcp连接要断开然后重连。

希望社区能参考‘一致性哈希’算法，尽量减少全局的变动。

所以，尽量避免重平衡Rebalance的发生，

比如：

1. Broker端Coordinator组件没有收到group下的某consumer实例的心跳，则认为它挂了，默认是heartbeat.interval.ms = 10s检测一次，可以多设置几轮心跳请求，session.timeout.ms >= n * heartbeat.interval.ms ; n比如是3. 当超过session.timeout.ms时，该consumer实例就被剔除了。如果是consumer主动关闭，则第一时间会Rebalance。

2. 如果Consumer消费端处理业务逻辑的时间过长，或者max.poll.interval.ms设置的太小，或者max.poll.records设置的太大，这3种情况也可能会触发Rebalance。总之，consumer实例poll一次后（poll拉取消息前会自动提交offset到__consumer_offsets中，当时间间隔超过了设置的max.poll.interval.ms值，下一次调用poll方法还迟迟未发生时，consumer group会开启Rebalance，并且把将要提交offset的分区分配给了另一个consumer实例，原consumer实例遗憾的被踢出了。如果是手动提交时（enable.auto.commit = false），当下一次poll时，会触发CommitFailedException异常，说明了本次提交offset失败。悲剧的是，另一个consumer并不知道offset提交失败，从而导致了重复消费问题。

 

顺便提下位移 Offset。 consumer group怎么管理offset呢，用一组KV对， K是分区，V是消费该分区的offset。

以前，consumer group的位移数据是放在Zookeeper中，后来发现这会降低zookeeper集群的性能。

现在，consumer group将位移数据保存在broker端的内部主题中，

即把位移数据作为普通的kafka消息，提交到位移主题（__consumer_offsets）中，

__consumer_offsets的主要作用就是：保存Kafka消费者的位移信息

设计上，__consumer_offsets的key是： consumer group id + topic + partition

__consumer_offsets是kafka自动创建的，默认分区数是50，副本数是3。

 

注意：下面说的‘位移’指的是consumer端的位移，记录了consumer要消费的下一条消息的位移。

consumer端默认是自动提交位移，即enable.auto.commit = true， 配合auto.commit.interval.ms定期间隔时间提交位移，缺点是：消费太快时，可能写入的位移前一次是10，该次是15？ 如果没有消息可消费时，会定期一直写入10，直到有新消息可消费。

推荐采用手动提交offset，即enable.auto.commit = false。有2种提交机制：consumer.commitSync()（同步，缺点是有阻塞）,或者commitAsync()（异步，缺点是出错了不能自动重试），一般是两者结合一起用（如下图）。

代码：

 

那么随着时间越长，位移主题占用的磁盘空间越大，kafka后台线程Log Cleaner会定期的删除过期数据。