今天就跟大家聊聊有关如何分析Kafka中的reblance，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
Kafka常见的消费模式会以组进行组织，通常Kafa会将Topic的分区均匀的分配给同一个组下的不同实例，通常的策略有以下三种：
Range：将单个Topic的所有分区按照顺序排列，然后把这些分区划分成固定大小的分区段并分配给每个consumer，默认策略
Round：将订阅所有的Topic分区轮询分配给每个conumser
Sticky：规避数据倾斜，最大限度保证两次reblance间维持之前的分配方案
目前触发reblance主要有以下几种情况：
组成员发生变更：新consumer加入离开组、consumer意外崩溃
组订阅的Topic的分区数目发生变更时
reblance generation
consumer group可以执行多次reblance，为了保护consumer group特别是防止无效的offset提交，reblance generation通常用来标识某次reblance，每经历一次reblance该值都会加1，默认值是从0开始。假如一个genertion值为1的consumer发生了延迟提交，但是reblance已经产生了新的group成员并且generation值已经变为了2，那么该conumse的提交将会被拒绝(ILLEgal_EXCEPTION)。
reblance协议
Kafka会使用以下4组请求来完成reblance。
JoinGroup：consumer请求入组
SyncGroup：group leader把分配方案同步更新到组内所有成员中
HeartBeat：consumer定期向coordinator汇报心跳表明自己依然存活
LeaveGroup：consumer主动请求coordinator自己将要离组
除了上面4组请求外，还有一个特殊的请求：
reblance过程中，coordinator需要接收来自consumer的JoinGroup和SyncGroup请求。当reblance成功以后，consumer定期向coordinator发送HeartBeat请求，consumer同时也会根据HeartBeat响应中是否包含REBLANCEINPROCESS来判断当前group是否开启了新一轮reblance。当consumer主动离组时，需要向coordinator发送LeaveGroup请求。
reblance流程
consumer reblance之前需要首先选定coordinator所在的broker(并且建立Socket连接)，算法：
Math.abs(groupId.hashCode)%offsets.topic.num.partitions。
reblance主要分为两步进行：
加入组：组内的所有consumer向coordinator发送JoinGroup请求，当收集好所有的JoinGroup请求后，coorinator需要从中选一个group leader，并把所有成员信息以及他们的订阅信息发送给leader。
同步更新分配方案：group leader负责分配消费方案，具体策略有文章开头的三种。分配完成后，leader会将分配方案封装进SyncGroup请求然后发送给coordinator。在这一步中所有的consumer都会发送SyncGroup请求，只不过只有leader中包含了分配方案。coordinator收到请求后，将每个consumer的消费信息进行抽取然后作为SyncGroup的响应发送给对应的consumer。
看完上述内容，你们对如何分析Kafka中的reblance有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注编程之家行业资讯频道，感谢大家的支持。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
