Kafka学习笔记: Kafka 2.3消费者组重平衡

 

消费者组的重平衡流程,它的作用是让组内所有的消费者实例就消费哪些主题分区达成一致。重平衡需要借助 Kafka Broker 端的 Coordinator 组件,在 Coordinator 的帮助下完成整个消费者组的分区重分配。

触发与通知

重平衡的 3 个触发条件:

  1. 组成员数量发生变化。  -- 每次消费者组启动时,必然会触发重平衡过程。
  2. 订阅主题数量发生变化。
  3. 订阅主题的分区数发生变化。

 

Kafka Java 消费者需要定期地发送心跳请求(Heartbeat Request)到 Broker 端的协调者,以表明它还存活着。

重平衡的通知机制正是通过心跳线程来完成的。

 

当协调者决定开启新一轮重平衡后,它会将“REBALANCE_IN_PROGRESS”封装进心跳请求的响应中,发还给消费者实例。当消费者实例发现心跳响应中包含了“REBALANCE_IN_PROGRESS”,就能立马知道重平衡又开始了,这就是重平衡的通知机制。

 

heartbeat.interval.ms 一方面 设置心跳间隔, 另一方面控制重平衡通知频率.

消费者组状态机

 

重平衡一旦开启,Broker 端的协调者组件开始工作, 利用自己设计的消费者组状态机(State Machine) , 实现控制消费者组的状态流转,完成重平衡流程。

它能够帮助你搞懂消费者组的设计原理,比如消费者组的过期位移(Expired Offsets)删除等。

 

Kafka 为消费者组定义了 5 种状态,它们分别是:Empty、Dead、PreparingRebalance、CompletingRebalance 和 Stable。

Kafka学习笔记: Kafka 2.3消费者组重平衡_第1张图片

 

流程图

Kafka学习笔记: Kafka 2.3消费者组重平衡_第2张图片

一个消费者组最开始是 Empty 状态,当重平衡过程开启后,它会被置于 PreparingRebalance 状态等待成员加入,之后变更到 CompletingRebalance 状态等待分配方案,最后流转到 Stable 状态完成重平衡.

当有新成员加入或已有成员退出时,消费者组的状态从 Stable 直接跳到 PreparingRebalance 状态,此时,所有现存成员就必须重新申请加入组。当所有成员都退出组后,消费者组状态变更为 Empty。Kafka 定期自动删除过期位移的条件就是,组要处于 Empty 状态。

 

如果你的消费者组停掉了很长时间(超过 7 天),那么 Kafka 很可能就把该组的位移数据删除了。

Removed ✘✘✘ expired offsets in ✘✘✘ milliseconds.

只有 Empty 状态下的组,才会执行过期位移删除的操作。

 

消费者端重平衡流程

重平衡的完整流程需要消费者端和协调者组件共同参与才能完成。

 

在消费者端,重平衡分为两个步骤:分别是加入组和等待领导者消费者(Leader Consumer)分配方案

这两个步骤分别对应两类特定的请求:JoinGroup 请求和 SyncGroup 请求。

 

当组内成员加入组时,它会向协调者发送 JoinGroup 请求。在该请求中,每个成员都要将自己订阅的主题上报,这样协调者就能收集到所有成员的订阅信息。一旦收集了全部成员的 JoinGroup 请求后,协调者会从这些成员中选择一个担任这个消费者组的领导者

通常, 第一个发送 JoinGroup 请求的成员自动成为领导者。你一定要注意区分这里的领导者和之前我们介绍的领导者副本,它们不是一个概念。这里的领导者是具体的消费者实例,它既不是副本,也不是协调者。领导者消费者的任务是收集所有成员的订阅信息,然后根据这些信息,制定具体的分区消费分配方案。

选出领导者之后,协调者会把消费者组订阅信息封装进 JoinGroup 请求的响应体中,然后发给领导者,由领导者统一做出分配方案后,进入到下一步:发送 SyncGroup 请求

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

 

JoinGroup 请求的处理过程

JoinGroup 请求的主要作用是将组成员订阅信息发送给领导者消费者,待领导者制定好分配方案后,重平衡流程进入到 SyncGroup 请求阶段。

Kafka学习笔记: Kafka 2.3消费者组重平衡_第3张图片

 

SyncGroup 请求的处理流程

SyncGroup 请求的主要目的,就是让协调者把领导者制定的分配方案下发给各个组内成员。当所有成员都成功接收到分配方案后,消费者组进入到 Stable 状态,即开始正常的消费工作。

Kafka学习笔记: Kafka 2.3消费者组重平衡_第4张图片

 

Broker 端重平衡场景剖析

场景一:新成员入组。

新成员入组是指组处于 Stable 状态后,有新成员加入。如果是全新启动一个消费者组,Kafka 是有一些自己的小优化的,流程上会有些许的不同。这里说的 是,组稳定了之后有新成员加入的情形。当协调者收到新的 JoinGroup 请求后,它会通过心跳请求响应的方式通知组内现有的所有成员,强制它们开启新一轮的重平衡。

Kafka学习笔记: Kafka 2.3消费者组重平衡_第5张图片

 

场景二:组成员主动离组。

消费者实例所在线程或进程调用 close() 方法主动通知协调者它要退出。协调者收到 LeaveGroup 请求后,依然会以心跳响应的方式通知其他成员.

Kafka学习笔记: Kafka 2.3消费者组重平衡_第6张图片

 

场景三:组成员崩溃离组。

 

崩溃离组是指消费者实例出现严重故障,突然宕机导致的离组。

它和主动离组是有区别的,因为后者是主动发起的离组,协调者能马上感知并处理。但崩溃离组是被动的,协调者通常需要等待一段时间才能感知到,这段时间一般是由消费者端参数 session.timeout.ms 控制的。也就是说,Kafka 一般不会超过 session.timeout.ms 就能感知到这个崩溃。当然,后面处理崩溃离组的流程与之前是一样的

 

Kafka学习笔记: Kafka 2.3消费者组重平衡_第7张图片

 

场景四:重平衡时协调者对组内成员提交位移的处理。

正常情况下,每个组内成员都会定期汇报位移给协调者。当重平衡开启时,协调者会给予成员一段缓冲时间,要求每个成员必须在这段时间内快速地上报自己的位移信息,然后再开启正常的 JoinGroup/SyncGroup 请求发送。

Kafka学习笔记: Kafka 2.3消费者组重平衡_第8张图片

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

引用:

Kafka核心技术与实战 - 胡夕

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(Kafka)