Kafka 核心技术与实战学习笔记（二十五）消费者组重平衡_kafka consumers preparing_rebalance

一.重平衡的触发条件：

• 组成员数量发生变化
• 订阅主题数量发生变化
• 订阅主题的分区数发生变化

组成员数据发生变化引发的重平衡最常见

产生原因：

• 消费者组内的消费者实例依次启动也属于第1种情况
• 每次消费者组启动都会触发重平衡

二.消费者端的心跳线程(Heartbeat Thread)

• Kafka Java消费者需要定期发送心跳请求（Heartbeat Request）到Broker端的协调者
• 以证明他还存活
• kafka 0.10.1.0版本之前，发送心跳请求是在消费者主线程完成的，也就是KafkaConsumer.poll 方法

存在问题：

•  消息处理逻辑也是在这个线程中完成的
• 一旦消息处理消耗过长时间，心跳请求将无法及时发到协调者哪里，导致协调者错误的认为该消费者已死
• 0.10.1.0 版本以后，社区专门引入单独的心跳线程执行心跳请求发送，避免这个问题。

三.重平衡通知机制

• 重平衡通知机制通过心跳线程来完成
• 协调者决定开启新一轮重平衡后会将”RANCE_IN_PROGRESS"封装金心跳请求的响应中，发送还给消费者实例
• 消费者实例发现心跳响应中包含"REBALANCE_IN_PROGRESS",就立马知道重平衡又开始了

四.消费者端参数heartbeat.interval.ms

• 设置心跳的间隔时间
• 这个参数真正作用是控制重平衡通知的频率
• 如果调低参数值，消费者机会更快的感知重平衡

五.消费者组状态机

• kafka为消费者组定义了5种状态：Empty，Deal，PreparingRebalance，CompletingRebalance和Stable

六.状态机各个状态流转

• 一个消费者组最开始是Empty状态。
• 当重平衡开启后，他会被置于PreparingRebalance状态等待成员加入。
• 之后变更到CompletingRebalanc状态等待分配方案。
• 最后流转到Stable 状态完成重平衡。

当新成员加入或已有成员推出时候

• 消费者组的状态从Stable直接跳到PrearingREbalance状态，此时所有现存成员必须重新申请加入组
• 当所有成员都退出组后，消费者组状态就变更为Empty
• Kafak定期删除过期位移的条件是，组要处于Empty状态
• 因此，如果消费者组停掉超过7天，该组位移数据就删除了。

七.消费者端重平衡流程

• 加入组                                                                                    JoinGroup请求
• 等待领导者消费者（Leader Consumer）分配方案             SyncGroup请求

八.JoinGroup请求

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

领导者消费者的任务是收集所有成员的订阅信息，然后根据这些信息，制定具体的分区消费分配方案。

九.发送SyncGroup请求

• 选出领导者知乎，协调者=吧消费者组订阅信息封装斤JoinGroup请求的响应体中，然后 在发给领导者
• 由领导者统一做出分配方案后，进入下一步：发送SyncGroup请求

 

SyncGroup请求目的：协调者把领导者指定的分配方案发给各个组内成员，所有成员成功接收到分配方案后，消费者组进入到Stabal状态，即开始正常的消费工作。

十.Broker端重平衡场景剖析

场景一：新成员入组

场景二：组成员主动离组

主动离组：指消费者实例所在线程或者进程调用close（）方法主动通知协调者它要退出

LeaveGroup请求

组成员崩溃离组

消费者实例出现严重故障，突然宕机导致的离组