Kafka消费者组重平衡流程

Kafka消费者组重平衡流程

Scroll Down

image.png

Kafka消费者组重平衡的作用是让组内各个消费者实例就消费主题的哪些分区达成一致。这整个流程需要借助Broker端的coordinator组件。以下的分析是基于Kafka 2.3版本。

重平衡触发的条件

重平衡触发有3个条件:

  1. 组成员数量发生变化。
  2. 订阅主题数量发生变化。
  3. 订阅的主题的分区数发生变化。

重平衡过程是如何通知到其他消费者实例的?

靠的是消费者端的心跳线程

Kafka的消费者需要定期发送心跳线程给Broker端,表明它还或者。这里要注意,0.10.1.0版本之前,发送心跳请求是在消费者主线完成的。这里有个比较大的问题是,假如消费者处理比较重,处理消息要花费比较多时间,这就会导致心跳线程无法及时发送到协调者那里,协调者会错误认为这个消费者已经“死”了。

重平衡的通知机制是通过心跳线程来完成,要想消费者实例更快得到通知,可以修改heartbeat.interval.ms参数。

消费者组状态机

Kafka设计了一套消费者组状态机(state Machine),来帮助协调者完成整个重平衡流程。分别有以下5中状态:

  1. Empty
  2. Dead
  3. PreparingRebalance
  4. CompletingRebalance
  5. Stable

各个状态含义如图: image.png

当触发我上面说的3个条件之一,会触发重平衡流程。

  1. 首先是PreparingRebalance状态,所有组内成员要离开组。
  2. 没有了成员,变成Empty状态。
  3. 接下来是CompletingRebalance状态,重新加入组,等待方案分配。
  4. 然后是Stable,分配好,正常工作。

以上步骤是已经启动好的消费者组才这样进行,假如是刚启动的话,第一步骤就是empty状态,重平衡开启时候,会变成PreparingRebalance状态。

Kafka定期删除过期位移的条件是组要处于Empty状态。

消费者端重平衡流程

在消费者端,重平衡分为两个步骤,分别是加入组和等待领导者消费者分配方案。这两步骤对应的请求分别为:JoinGroup请求和SyncGroup请求。

当有成员加入组时,它要向协调者发送JoinGroup请求,汇报自己要订阅的主题消息,收集好全部成员的JoinGroup请求后,协调者会指定一个消费者成为领导者消费者任务是收集所有成员的订阅消息,然后根据这些消息,指定具体的分区消费分配方案。

coordinator把所有消费者订阅主题情况,封装到JoinGroup请求的响应中,告诉领导者消费者。

image.png

接下来,领导者消费者会向协调者发送SyncGroup请求,将刚刚做出的分配方案发给协调者。值得注意的是,其他成员也会向协调者发送 SyncGroup 请求,只不过请求体中并没有实际的内容。这一步的主要目的是让协调者接收分配方案,然后统一以 SyncGroup 响应的方式分发给所有成员,这样组内所有成员就都知道自己该消费哪些分区了。

image.png

参考

  • 极客时间-《Kafka核心技术与实践》