在我们平时使用kafka的过程中，consumer偶尔会出现TPS大幅降低的情况，可能会出现这样的日志:
究其原因是发生了Rebalance。Rebalance是消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。换句话说，它也是一种分配一个Consumer Group中所有的Consumer订阅Topic(主题)下所有Partition(分区)的协议。当发生Rebalance时，Consumer Group中所有的Consumer全部停止消费，等待Rebalance结束后重新消费，类似JVM中的Stop The World。除了Stop The World以外，Rebalance的效率也很低。举个例子，我们的Consumer Group中有四个Consumer，分别为ConsumerA，ConsumerB，ConsumerC，ConsumerD,分别消费Topic A 下的 8个分区，ConsumerA:P1、P2，ConsumerB:P3、P4，ConsumerC:P5、P6，ConsumerD:P7、P8,当ConsumerD因为挂掉触发Rebalance后，所有的Consumer重新分配Partition，而不是ConsumerA,ConsumerB,ConsumerC接管ConsumerD之前消费的Partition。当我们的Consumer Group中Consumer实例比较多的时候，Rebalance将极其耗费时间。
那么在什么条件下会触发Coordinator的Rebalance呢?当满足以下3个条件之一后，会触发Rebalance。
1.当Consumer Group中Consumer实例数量发生变化:无论实例是增加、减少还是崩溃都会触发Rebalance。
2.当Consumer Group订阅的Topic数量发生变更:在大部分时候我们都是订阅一个Topic，并消费其中的消息。但是也可以通过正则的方式订阅多个满足正则规则的Topic，如果此时新增一个满足要求的Topic，同样也会触发Rebalance。
3.当订阅的Topic下面的Partition数量发生变更时，也会触发Rebalance。
第2、3种情况其实都是在我们的控制之中的情况，在这里就不继续讨论了，只讨论Consumer实例数量发生变化导致的Rebalance。新增Consumer实例这种情况比较好理解，当我们新启动一个已有的group.id的Consumer时，就相当于向该Consumer Group中添加了一个Consumer实例。同理，当我们停掉某个Consumer实例时，该实例也会自动从Consumer Group中退出。
以上两种情况都是Consumer实例正常增减，由此导致的Rebalance都是在意料之中的。但是还有一种情况也会导致Rebalance，那就是Consumer被Coordinator踢出消费组。和Redis一样，Kafka的Consumer实例也会向Coordinator定期发送心跳，如果在指定时间内Consumer没有向Coordinator发送心跳，Coordinator就会认为该Consumer实例已经死亡，然后将其踢出消费组。上面提到的指定时间由session.timeout.ms参数控制，默认值为10s,即Coordinator在10s内没有收到Consumer实例的心跳，则会认为该实例不可用，但是session.timeout.ms这个值不宜设置过大，因为这样会影响Coordinator快速发现不可用的Consumer实例。除了session.timeout.ms参数，还有一个参数与心跳紧密相关，那就是heartbeat.interval.ms，该参数的意思是实例在多少秒内发出一次心跳，该参数控制着实例发送心跳的频率，默认值为3s。一般默认session.timeout.ms >= 3*heartbeat.interval.ms，之所以这么设置是因为我们需要在一次heartbeat.interval.ms中尽可能的多发出心跳，使得实例能够尽早的发现当前是否开启了Rebalance(如果开启了Rebalance，Coordinator会在心跳请求的响应中放入REBALANCE_NEEDED标识)以及在被Coordinator判定为死亡之前尽量告知Coordinator实例还活着，但是心跳也不宜频繁发送，毕竟发送心跳需要占用带宽资源，因此我们采用一个默认的取值方法，即session.timeout.ms >= 3*heartbeat.interval.ms。
除了上面提到的两个参数，Consumer端还有一个参数用来控制实例的实际消费能力对于Rebalance的影响，那就是max.poll.interval.ms，该参数规定了Consumer每隔多久才能poll一批消息，默认值为5min。如果Consumer在设定的max.poll.interval.ms的时间限制内没有消费完这批消息，那么Consumer会主动离开当前的Consumer Group，继而引发新的一轮Rebalance。
另外，如果Consumer使用的语言是Java，那么GC的问题同样需要考虑。如果使用的是CMS垃圾回收器，可能会出现最终标记阶段停顿时间过长的问题，在这一阶段是会Stop The World的，这同样会导致Rebalance的发生。
说到这里，我们可以总结一下，到底什么情况导致的Rebalance是我们不希望发生的:
1.Consumer实例没有及时向Coordinator发送它的心跳，导致被Coordinator认为实例死亡，从而被移出消费组，导致Rebalance。在这种情况下我们可以通过设置session.timeout.ms 和heartbeat.interval.ms两个参数进行控制。
2.Consumer实例消费时间过长，超过了max.poll.interval.ms设置的时间限制，导致实例主动离开消费组，进而导致Rebalance。这种情况如何优化会在后面进行分析。
3.Consumer实例使用的垃圾回收器不合适同样可能会导致Rebalance，如果你使用的JDK版本在1.8以上，还是建议你使用G1垃圾回收器。
回到我们第一张图中的日志:Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. You can address this either by increasing max.poll.interval.ms or by reducing the maximum size of batches returned in poll() with max.poll.records.这段话的意思是由于发生了rebalance，分区已经被分配给其他成员，当前Consumer实例无法提交offset。这标识两次调用poll()方法的时间超过了默认的max.poll.interval.ms，这表明实例花费了太多时间用户处理消息。你可以通过增加max.poll.interval.ms参数的值或者降低max.poll.records参数的值。
除去Kafka官方提示我们的这两种解决办法之外，还有其他两种解决办法：一是缩短单条消息的处理时间，增加消费者的吞吐量；二是使用线程池等方案，使用多线程加速消息的消费速率，同样可以提升消费者的吞吐量。
