kafka消费者组重平衡全流程

最新推荐文章于 2025-08-05 10:46:13 发布

paradoxxi

最新推荐文章于 2025-08-05 10:46:13 发布

阅读量955

点赞数 12

CC 4.0 BY-SA版权

分类专栏： kafka学习专栏文章标签： kafka 分布式

本文链接：https://blog.csdn.net/m0_60788247/article/details/136436291

kafka学习专栏专栏收录该内容

9 篇文章

订阅专栏

本文详细阐述了Kafka中的消费者端重平衡过程，包括心跳机制、状态流转、JoinGroup/SyncGroup请求以及Broker端的场景分析，如新成员加入、成员主动/被动离组和重平衡期间的位移处理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

靠消费者端的心跳线程

kafka 消费者需要定期的发送心跳请求到broker端的协调者，表明它还存活

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

消费者组状态机

状态流转：

一个消费组最开始是Empty状态
当重平衡过程开启后，会被置于PreparingRebalance状态等待成员加入
之后变更到CompletingRebalance状态等待分配方案
最后流程到Stable状态完成重平衡
当有新成员加入或已有成员退出时，消费者组的状态从Stable直接跳到PreparingRebalance状态
所有现存成员必须重新申请加入组，当所有成员都推出组后，消费者组状态变更为Empty
kafka定期自动删除过期位移的条件就是，组要处于Empty状态，因此，如果你的消费者组停掉了很长时间（超过 7 天），那么 Kafka 很可能就把该组的位移数据删除了

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

消费者端重平衡流程

加入组 JoinGroup请求，会向协调者发送JoinGroup请求，在该请求中，每个成员都要将自己订阅的主题上报，这样协调者就能收集到所有成员的订阅信息，一旦收集了全部成员的joinGroup请求后，协调者会从这些成员中选择一个担任这个消费者组的领导者，一般第一个发送JoinGroup请求的成员自动成为领导者，但这里的领导者和之前的领导者副本不是一个概念。

领导者消费者的任务是收集所有成员的订阅信息，然后根据这些信息，制定具体的分区消息消费分配方案，协调者会把消费者组订阅信息封装进joinGroup请求的响应体中，然后发给领导者，由领导者统一做出分配方案后，进入到下一步

等待领导者消费者分配方案SyncGroup请求：

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

JoinGroup