一.Rebalance
- Rebalance是让consumer Group下所有的Consumer实例消费订阅主题的所有分区达成共识的过程。
- 在 Rebalance过程中，所有consumer实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。
- 整个过程中，所有实例都不能消费任何消息，对consumer的Tps影响很大。
二.coordinator-协调者
专门为Consumer Group服务，负责Group执行Rebalnce以及提供位移管理和组成员管理等。
- Consumer端应用程序提交位移时，其实是向Coordinator所在的Broker提交位移
- 当consumer应用启动时，也是向coordinator所在的broker发送各种请求
- 然后由Coordinator负责执行消费者组的注册，成员管理记录等元数据管理操作。
启动流程
- Broker启动时，会创建和开启响应的Coordinator组件
- kafka为某个consumer Group确定Coordination所在的Broker算法有两步：
- 确定由位移主题的哪个分区来保存该Group数据
- partitionId==Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。
- 找出该分区Leader副本所在的Broker，该broker即为对应的Coordinator；
实现流程：
- kafka会计算该Group的group.id参数的哈希值
- 比如你有个Group的group.id设置成"test-group",那么他的hashcode值是627841412
- kafka计算__consumer_offsets的分区数，通常是50个分区，之后将刚才那个哈希值对分区数进行取模加求绝对值计算即abs（627841412 % 50）=12
- 此时，我们知道位移主题的分区12负责保存这个Group的数据
- 第二步：找出位移主题分区12的Leader副本在哪个Broker上就可以了。
- 这个Broker，就是我们要找的coordinator。
实际使用
- Consumer应用特别是Java consumer API，能够自动发现并正确连接Coordinator
- 它能帮助我们解决定位问题。
- 当consumer Group出现问题，需要快速排查Broker端日志时，我们能够根据这个算法准确定位Coordinator对应的Broker，不必盲目排查。
Rebalance的弊端
- 影响consumer端TPS，在Rebalance期间，Consumer会停下来手头的事，什么也干不了。
- Rebalance效率不高。当前kafka的设计机制决定每次Rebalance时，Group下的所有成员都要参与进来，而且通常不会考虑局部性原理
真实的业务场景下，很多Rebalance是计划外的或者不必要的。
避免Rebalance 发生的时机
三.Rebalance 发生的时机：
- 组成员数量发生变化
- 订阅主题数量发生变化
- 订阅主题的分区数发生变化
后两个是运维主动操作，所以引发Rebalance是不可避免的。
Consumer实例增加这种情况很好理解，当启动一个配置相同的group.id值的Consumer程序时
实际上就是向Group增加了一个新的consumer实例
此时，Coorinator会接纳这个新实例，将其加入到组内，重新分配分区。
通常来说，增加Consumer实例的操作都是计划内的，可能出于增加TPS或提高伸缩性的需要
他不属于我们要规避的那类“不必要Rebalance”
四.哪些Rebalance是不必要的
第一类不必要Rebalance是因为未能及时发送心跳导致consumer被踢出Group引发
解决方案：
- 设置session.timeout.ms=6s
- 设置heartbeat.interval.ms=2s
- 要保证 Consumer 实例在被判定为“dead”之前，能够发送至少 3 轮的心跳请求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。
第二类非必要 Rebalance 是 Consumer 消费时间过长导致的。
解决方案：
- 增大max.poll.interval.ms参数值设置
- 排查Consuner端的GC设置是否合理
五.总结：
- session.timeout.ms
- heartbeat.interval.ms
- max.poll.interval.ms
- GC参数
版权声明：本文不是「本站」原创文章，版权归原作者所有 | 原文地址: