17 | 消费者组重平衡能避免吗？

胡夕



该思维导图由 AI 生成，仅供参考

你好，我是胡夕。今天我要和你分享的内容是：消费者组重平衡能避免吗?
其实在专栏第 15 期中，我们讲过重平衡，也就是 Rebalance，现在先来回顾一下这个概念的原理和用途。Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。
你可能会对这里提到的“协调者”有些陌生，我来简单介绍下。所谓协调者，在 Kafka 中对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。
具体来讲，Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Kafka消费者组的重平衡是一个常见问题，会影响消费者端的TPS，并在成员较多时变得缓慢且效率低下。本文详细介绍了重平衡发生的时机，主要是组成员数量变化。增加消费者实例通常是计划内的，而减少实例可能会导致不必要的重平衡。文章还介绍了Coordinator如何判断消费者实例是否已挂，以及相关参数的设置。StickyAssignor策略能尽量保留之前的分配方案，减少重平衡对系统的影响。建议合理设置session.timeout.ms和heartbeat.interval.ms的值，以及max.poll.interval.ms参数，确保消费者端的GC表现良好，从而避免非预期的重平衡。总的来说，文章提出了避免重平衡的方法，特别是针对不必要的重平衡。对于需要优化Kafka消费者组性能的读者具有一定的参考价值。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Kafka 核心技术与实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(120)

最新
精选

Icedmaze
在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待Rebalance的完成。这里想问的是，如果我有一个长耗时的业务逻辑需要处理，并且offset还未提交，这时候系统发生了Rebalance的话，是等待所有消费端当前消息都处理完成，再进行停止消费，并进行重新分配分区，还是说强制停止消费。如果强制停止消费的话，那么那些已经处理完成一半的数据并offset未提交的数据，势必会导致Rebalance后重新进行消费，导致数据产生重复消费。
作者回复: 你所谓的处理是指业务上的处理逻辑。对于Kafka而言，从poll方法返回消息的那一刻开始这条消息已经算是“消费”完成了。
2019-07-11
9
57
Liam
问个小白问题，如何排查得知broker rebalance 过多，通过broker日志吗？什么日志呢
作者回复: 去找Coordinator所在的broker日志，如果经常发生rebalance，会有类似于"(Re)join group" 之类的日志
2019-07-11
7
48
Icedmaze
那可否认为，之前poll的数据还是会被继续进行业务逻辑处理，若在rebalance停止消费期间offset并未进行提交，可能会造成该partition里面的同一批消息被重新分配给其他消费实例，造成重复消费问题。
作者回复: 是的
2019-07-12

36
What for
老师您好！请问如果使用 Standalone Consumer，是不是也不会发生 rebalance 了？感觉专栏里对 Standalone Consumer 就是提了两句，没有太多的介绍，相较于订阅模式它们有什么特点嘛？
作者回复: 不会。standalone consumer就没有rebalance一说了。它的特点主要是灵活和。虽然社区一直在改进rebalance的性能，但大数据量下consumer group机制依然有很多弊病（比如rebalance太慢等），所以很多大数据框架(Spark /Flink)的kafka connector并不使用group机制，而是使用standalone consumer
2020-02-03
3
34
李奕慧
“每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求，表明它还存活着。”这个是后台自动触发的还是每次主动poll消息触发的啊？
作者回复: 0.10.1之前是在调用poll方法时发送的，0.10.1之后consumer使用单独的心跳线程来发送
2019-07-11
4
25
诗泽
如果同一个group 的不同consumer 设置的session.timeout.ms 的不一样怎么办？协调者以最后一个consumer 为准吗？
作者回复: 取最大的
2019-07-11
3
21
墨渊战神01
Consumer 消费时间过长为啥会导致rebalance？是不能及时发心跳导致coordinator认为该consumer挂了吗？
作者回复: consumer主动关闭会主动向Coordinator发送LeaveGroup请求，从而让Coordinator第一时间开启rebalance
2019-07-11
2
18
千屿
我遇到一个很奇怪的问题，我消费者单线程使用订阅模式消费主题，主题下有三个分区，但是每次启动消费者，只能消费到一个分区的数据，在启动的日志里已经显示了该group已经分配到了三个分区，可是只会poll一个分区的数据。当我用多线程启动三个消费者实例是正常的，启动两个实例只能消费到两个分区数据，求各位大神指点下，谢谢了!
作者回复: 是否是因为某个分区的数据量太多，造成了其他分区的“假饿死”？
2019-07-11
4
14
丘壑
根据公式计算记过：partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)只可能是一个分区值，该分区值对于的leader副本的broker也只可能是集群中的一台，那么一个group进行位移提交的时候，只能是与集群中的一台broker进行交互了？这样是不是就会有性能瓶颈啊，没有充分利用集群中的broker啊，
作者回复: 不同的group id会被哈希到不同的分区上，从而不同的broker能充当不同group的Coordinator
2019-07-11

14
Berk
老师您好, 我们在生产环境中有一个90个分区的主题。部署了三十台机器的consumer group. 每个consumer理论上消费三个分区。我们发现有时rebalance发生后，分区不能平均的分配到consumer group中。极端情况下有的consumer被分到三十个分区。请问老师这种情况应该如何排查？
作者回复: 这是可能的。你可以试试换一个分配策略，比如设置partition.assignment.strategy=org.apache.kafka.clients.consumer.RoundRobinAssignor试试。后引入的RoundRobinAssingor在对抗极端情况时比默认的RangeAssignor要均匀一些，不妨试试
2020-04-20
2
12

收起评论