今天就跟大家聊聊有关如何分析Kafka中的reblance，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。Kafka常见的消费模式会以组进行组织，通常Kafa会将Topic的分区均匀的分配给同一个组下的不同实例，通常的策略有以下三种：Range：将单个Topic的所有分区按照顺序排列，然后把这些分区划分成固定大小的分区段并分配给每个consumer，默认策略Round：将订阅所有的Topic分区轮询分配给每个conumserSticky：规避数据倾斜，最大限度保证两次reblance间维持之前的分配方案目前触发reblance主要有以下几种情况：组成员发生变更：新consumer加入离开组、consumer意外崩溃组订阅的Topic数发生变化：比如基于正则表达式的订阅，当匹配正则表达式的新Topic被创建时组订阅的Topic的分区数目发生变更时consumer group可以执行多次reblance，为了保护consumer group特别是防止无效的offset提交，reblance generation通常用来标识某次reblance，每经历一次reblance该值都会加1，默认值是从0开始。假如一个genertion值为1的consumer发生了延迟提交，但是reblance已经产生了新的group成员并且generation值已经变为了2，那么该conumse的提交将会被拒绝(ILLEGAL_EXCEPTION)。Kafka会使用以下4组请求来完成reblance。Join 香港云主机Group：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请求。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有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注开发云行业资讯频道，感谢大家的支持。
本篇内容介绍了“怎么用Python处理Excel的数据”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！1. 先从Excel中加载数据：2. 简单地做一下数据清洗：…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
