如何分析Kafka中的reblance

今天就跟大家聊聊有关如何分析Kafka中的reblance,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

创新互联从2013年成立,先为四川等服务建站,四川等地企业,进行企业商务咨询服务。为四川企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

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主要分为两步进行:

  1. 加入组:组内的所有consumer向coordinator发送JoinGroup请求,当收集好所有的JoinGroup请求后,coorinator需要从中选一个group leader,并把所有成员信息以及他们的订阅信息发送给leader。

  2. 同步更新分配方案:group leader负责分配消费方案,具体策略有文章开头的三种。分配完成后,leader会将分配方案封装进SyncGroup请求然后发送给coordinator。在这一步中所有的consumer都会发送SyncGroup请求,只不过只有leader中包含了分配方案。coordinator收到请求后,将每个consumer的消费信息进行抽取然后作为SyncGroup的响应发送给对应的consumer。

看完上述内容,你们对如何分析Kafka中的reblance有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


分享题目:如何分析Kafka中的reblance
文章分享:http://pwwzsj.com/article/pjsgoo.html