在介绍消费者的时候提到了消费者重平衡，这个机制的设计给我们提供了高可用，自动负载等等的便利。但是同时也带来了一些问题本篇来分析一下这个问题。
1. Rebalance 影响 Consumer 端 TPS。
Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，所有 Consumer 实例共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。
所谓协调者，在 Kafka 中对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行Rebalance 以及提供位移管理和组成员管理等。具体来讲Consumer端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送各种请求，然后由Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操作。
所有 Broker 在启动时，都会创建和开启相应的 Coordinator 组件。也就是说，所有
Broker 都有各自的 Coordinator 组件。那么，Consumer Group 如何确定为它服务的
Coordinator 在哪台 Broker 上呢？其实在所对应分区的leader 副本上。
2. Rebalance 很慢。
如果你的 Group 下成员很多，就一定会有这样的痛点。还记得我曾经看过一个博客。有人说他的 Group 下有几百个 Consumer 实例，Rebalance一次要几个小时。在生产环境中相当的致命。
3. Rebalance 效率不高。
当前 Kafka 的设计机制决定了每次 Rebalance 时，Group 下的所有成员都要参与进来，而且通常不会考虑局部性原理，但局部性原理对提升系统性能是特别重要的。
4. Rebalance 条件太容易触发
当组成员数量发生变化，订阅主题数量发生变化，订阅主题的分区数发生变化。 会触发Rebalance 。 然而在生产环境的一个release 的代码修改订阅主题数量 或者调整分区发生的或许比较少。但是组成员数量发生 如有机器宕机，或者网络原因导致心跳超时 对于分布式系统来说是不可避免的。如果每遇到一次就要Rebalance 几个小时那真的是灾难。对于成员数量，可以作为一些适当的优化。对于一些已经挂掉的节点没有什么办法了。但是对于一些情况如网络波动的情况或者GC感觉还是可以抢救一下的。这里主要介绍一下心跳超时的情况。例如由网络波动引起的心跳超时可以合理的设置下面的值session.timeout.ms 和 heartbeat.interval.ms 要保证 Consumer 实例在被判定为“dead”之前，能够发送至少 3 轮的心跳请求，即session.timeout.ms >= 3 * heartbeat.interval.ms.
如果是要 Rebalance 是 Consumer 消费时间过长引起的心跳超时的话可以通过设置max.poll.interval.ms的参数给下游预留充足的时间或许会有帮助。
