reblance重平衡

发生时机

Rebalance 发生的时机有三个：

• 组成员数量发生变化

• 订阅主题数量发生变化

• 订阅主题的分区数发生变化

通知

协调者来负责管理消费者组的

弊端

Rebalance 的弊端是什么呢？总结起来有以下 3 点：

1. Rebalance 影响 Consumer 端 TPS。这个之前也反复提到了，这里就不再具体讲了。总之就是，在 Rebalance 期间，Consumer 会停下手头的事情，什么也干不了。

2. Rebalance 很慢。如果你的 Group 下成员很多，就一定会有这样的痛点。还记得我曾经举过的那个国外用户的例子吧？他的 Group 下有几百个 Consumer 实例，Rebalance 一次要几个小时。在那种场景下，Consumer Group 的 Rebalance 已经完全失控了。

3. Rebalance 效率不高。当前 Kafka 的设计机制决定了每次 Rebalance 时，Group 下的所有成员都要参与进来，而且通常不会考虑局部性原理，但局部性原理对提升系统性能是特别重要的。

规避

总而言之，我们一定要避免因为各种参数或逻辑不合理而导致的组成员意外离组或退出的情形，与之相关的主要参数有：

• session.timeout.ms//保持时间

• heartbeat.interval.ms//心跳时间

• max.poll.interval.ms//每次消费的处理最大时间

• max.poll.records//每次拉取的条数。

• GC 参数

1. 避免心跳超时。

常用的设置：session.timeout.ms=6s.heartbeat.interval.ms=3s。即：在被判定为dead之前，至少发送2个心跳。

1. 避免处理时间过长。