如何分析Kafka中的reblance
今天就跟大家聊聊有关如何分析Kafka中的reblance，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
Kafka常见的消费模式会以组进行组织，通常Kafa会将Topic的分区均匀的分配给同一个组下的不同实例，通常的策略有以下三种：
Range：将单个Topic的所有分区按照顺序排列，然后把这些分区划分成固定大小的分区段并分配给每个consumer，默认策略
Round：将订阅所有的Topic分区轮询分配给每个conumser
Sticky：规避数据倾斜，最大限度保证两次reblance间维持之前的分配方案
目前触发reblance主要有以下几种情况：
组成员发生变更：新consumer加入离开组、consumer意外崩溃
组订阅的Topic数发生变化：比如基于正则表达式的订阅，当匹配正则表达式的新Topic被创建时
组订阅的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组请求外，还有一个特殊的请求：
DescribeGroup：查看组的所有信息，包括成员信息、协议信息、分配方案以及订阅信息等。该请求不参与reblance，主要是管理员使用。
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有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。
