目录
前言：
Rebalance 就是让一个 Consumer Group**下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。**在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。
消费组Group进行重平衡的条件有三个：
- 组成员数发生变更。比如有新的 Consumer 实例加入组或者离开组，抑或是有 Consumer 实例崩溃被"踢出"组。订阅主题数发生变更。
- Consumer Group 可以使用正则表达式的方式订阅主题，比如 consumer.subscribe(Pattern.compile("t.*c")) 就表明该 Group 订阅所有以字母 t 开头、字母 c 结尾的主题。在 Consumer Group 的运行过程中，你新创建了一个满足这样条件的主题，那么该 Group 就会发生 Rebalance。
- 订阅主题的分区数发生变更。Kafka 当前只能允许增加一个主题的分区数。当分区数增加时，就会触发订阅该主题的所有 Group 开启 Rebalance。
那我们该如何避免消费组进行重平衡勒？
协调者
所谓协调者，在 Kafka 中对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。
Consumer 端应用程序在提交位移时，**其实是向 Coordinator 所在的 Broker 提交位移。**同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。
所有 Broker 在启动时，都会创建和开启相应的 Coordinator 组件**。也就是说，所有 Broker 都有各自的 Coordinator 组件。**
重平衡的影响
发生重平衡时，会造成如下3点不良影响
- Rebalance 影响 Consumer 端 TPS。这个之前也反复提到了，这里就不再具体讲了。总之就是，在 Rebalance 期间，Consumer 会停下手头的事情，什么也干不了。
- Rebalance 很慢。如果你的 Group 下成员很多，就一定会有这样的痛点。还记得我曾经举过的那个国外用户的例子吧？他的 Group 下有几百个 Consumer 实例，Rebalance 一次要几个小时。在那种场景下，Consumer Group 的 Rebalance 已经完全失控了。
- Rebalance 效率不高。当前 Kafka 的设计机制决定了每次 Rebalance 时，Group 下的所有成员都要参与进来，而且通常不会考虑局部性原理，但局部性原理对提升系统性能是特别重要的。
在默认情况下，每次 Rebalance 时，之前的分配方案都不会被保留。全部打散重新进行分配，并不会保持之前的分配方案，不会实现分区分配的最小改动。
避免重平衡
对于重平衡慢的问题，kafka目前没有很好的解决方案，我们没办法解决 Rebalance 过程中的各种问题，我们只能尽可能的的去避免 Rebalance 吧，特别是那些不必要的 Rebalance。
在真实的业务场景中，**很多 Rebalance 都是计划外的或者说是不必要的。我们应用的 TPS 大多是被这类 Rebalance 拖慢的，**因此避免这类 Rebalance 就显得很有必要了。
要避免 Rebalance，还是要从 Rebalance 发生的时机入手。我们在前面说过，Rebalance 发生的时机有三个：
- 组成员数量发生变化
- 订阅主题数量发生变化
- 订阅主题的分区数发生变化
后面两个通常都是运维的主动操作，所以它们引发的 Rebalance 大都是不可避免的。接下来**，我们主要说说因为组成员数量变化而引发的 Rebalance 该如何避免。**
如果 Consumer Group 下的 Consumer 实例数量发生变化，就一定会引发 Rebalance。这是 Rebalance 发生的最常见的原因。
当我们启动一个**配置有相同 group.id 值的 Consumer 程序时，**实际上就向这个 Group 添加了一个新的 Consumer 实例。此时，Coordinator 会接纳这个新实例，将其加入到组中，并重新分配分区。通常来说，增加 Consumer 实例的操作都是计划内的，可能是出于增加 TPS 或提高伸缩性的需要。总之，它不属于我们要规避的那类"不必要 Rebalance"。
我们更在意的是 Group 下实例数减少这件事。如果你就是要停掉某些 Consumer 实例，**关键是在某些情况下，Consumer 实例会被 Coordinator 错误地认为"已停止"从而被"踢出"Group。**如果是这个原因导致的 Rebalance，我们就不能不管了。
当 Consumer Group 完成 Rebalance 之后，**每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求，表明它还存活着。**如果某个 Consumer 实例不能及时地发送这些心跳请求，Coordinator 就会认为该 Consumer 已经"死"了，从而将其从 Group 中移除，然后开启新一轮 Rebalance。
Consumer 端有个参数，**叫 session.timeout.ms，**就是被用来表征此事的。该参数的默认值是 10 秒，即如果 Coordinator 在 10 秒之内没有收到 Group 下某 Consumer 实例的心跳，它就会认为这个 Consumer 实例已经挂了。可以这么说，session.timeout.ms 决定了 Consumer 存活性的时间间隔。
Consumer 还提供了一个允许你控制发送心跳请求频率的参数，就是 heartbeat.interval.ms。这个值设置得越小，Consumer 实例发送心跳请求的频率就越高。**频繁地发送心跳请求会额外消耗带宽资源，但好处是能够更加快速地知晓当前是否开启 Rebalance，**因为，目前 Coordinator 通知各个 Consumer 实例开启 Rebalance 的方法，就是将 REBALANCE_NEEDED 标志封装进心跳请求的响应体中。
Consumer 端还有一个参数，用于控制 Consumer 实际消费能力对 Rebalance 的影响，即 **max.poll.interval.ms 参数。**它限定了 Consumer 端应用程序两次调用 poll 方法的最大时间间隔。它的默认值是 5 分钟，**表示你的 Consumer 程序如果在 5 分钟之内无法消费完 poll 方法返回的消息，那么 Consumer 会主动发起"离开组"的请求，**Coordinator 也会开启新一轮 Rebalance。
重平衡发生的场景
第一类非必要 Rebalance 是因为未能及时发送心跳，导致 Consumer 被"踢出"Group 而引发的。因此，你需要仔细地设置 session.timeout.ms 和 heartbeat.interval.ms 的值。
- 设置 session.timeout.ms = 6s。
- 设置 heartbeat.interval.ms = 2s。
- 要保证 Consumer 实例在被判定为"dead"之前，能够发送至少 3 轮的心跳请求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。
第二类非必要 Rebalance 是 Consumer 消费时间过长导致的
max.poll.interval.ms 参数值的设置显得尤为关键。如果要避免非预期的 Rebalance，你最好将该参数值设置得大一点，比你的下游最大处理时间稍长一点。
如果你按照上面的推荐数值恰当地设置了这几个参数，却发现还是出现了 Rebalance，建议你去排查一下 Consumer 端的 GC 表现，比如是否出现了频繁的 Full GC 导致的长时间停顿，从而引发了 Rebalance。