消费者rebalance机制分析

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

一 触发rebalance的时机

有新的消费者加入

有消费者宕机或者下线

消费者主动退出消费者组

消费者组订阅的topic出现分区数量变化

消费者调用unsubscrible取消对某topic的订阅

2.1 查找GroupCoordinator
在poll数据的时候，首先会调用ConsumerCoordinator#poll查找GroupCoordinator

调器事件的轮询。这确保了协调器是已知的，并且是消费者加入了这个群组(如果它使用的是组管理)。这也可以处理周期性的offset提交，如果启用了它们。

2.2 进入Join Group 阶段

当成功找到GroupCoordinator之后，则进入Join Group阶段，此阶段消费者会向GroupCoordinator发送JoinGroupRequest请求，并处理响应。
我们先看一下JoinGroupRequest和 JoinGroupResponse的消息体格式：
JoinGroupRequest:
group_id: 消费者组的id

session_timeout: GroupCoordinator超过session_time指定时间没有收到心跳，认为消费者下线

member_id: GroupCoordinator分配给消费者的id

protocol_type: 消费者组实现的协议

group_protocols： 包含此消费者全部支持的PartitionAssignor类型

protocol_name:PartitionAssignor名字

protocol_metadata: 针对不同的PartitionAssignor，序列化后的消费者的订阅信息，包含用户自定义数据userData

1 解析JoinGroupResponse，获取memberId，generationId，和protocol等信息

2 判断响应的节点是不是leader，如果是leader则进入onJoinLeader方法，否则进入onJoinFollower方法

2 判断响应的节点是不是leader，如果是leader则进入onJoinLeader方法，否则进入onJoinFollower方法

完成分区分配后，就进入SynchronizingGroup State阶段，主要就是向GroupCoordinator发送SyncGroupRequest请求并处理SyncGroup
在前面onLeaderJoin方法，我们知道在获取分区分配结果之后，Leader将其封装成SyncGroupRequest, 但是我们看到了onFollowerJoin方法里也封装了SyncGroupRequest，但是这里边的分区分配结果是空的

然后调用ConsumerNetworkClient#send方法将请求放入unsent请求等待集合，等待被发送

我们在这里分析的是加入组的情况，其实当消费者离开组的时候，也会触发rebalance操作。

小结

参考资料和推荐阅读

1.链接: 参考资料.