线上kafka某个topic的消费组频繁​​​rebalance​​​（每隔5分钟一次，默认配置 ​​max.poll.interval.ms=5分钟​​）,持续时间长达2小时，日志报错如下：

​，并且其Kafka Broker上的​​​Consumer Offset​​​​​一直不变，之前遇到过rebalance问题，Consumer Offset多少会Commit，但是这次完全不Commit，Offset静止了，消费者像死掉一般。该topic因为只有一个partation0，于是给topic多加了两个partation1和parattion2，发现partation0的Consumer Offset还是不变，于是感觉到很奇怪。​​

​​调整前的分区：​​

调整后的分区：

首先想到是消费者是不是有问题，于是重启项目，发现还是不消费消息，于是想到扩充partation，扩到了三个还是不消费，然后尝试往topic上发消息，看看别的分区的消费者是否可以收到，发现别的分区的消费者可以成功消费消息，于是将partation0的消费者偏移量调整到最新，然后继续给该topic发消息，发现新的消息被partation0消费成功了，所以证明消费者本身是没有问题的（错误的结论），然后想到是不是某一条消息导致了，于是将偏移量提交到卡住偏移量的后一个，发现还是不动，然后尝试将“卡住偏移量的消息”发给其他分区，发现其他分区可以消费，然后看了看每个消费者的线程，发现是Runnable， 并没有Waiting或者Blocked住。

于是请教大佬，大佬猜测是拉取消息时候，超时了，于是代码调整了消费者的poll timeout，从100ms改成了10s，发现无效。于是在生产环境将kafka消费者关闭，在物理机起了一台新的服务，用来远程debug消费者，并且将kafka消费者代码改成trace级别，发现kakfa在消费消息，但是5分钟过去了，并没有commit，因为一条消息处理平均1s，kafka消费者一次默认从broker拉取500条(默认配置：​​​max.poll.records=500​​​)消息，而LogSize和ConsumerOffset差值Lag为589，如上图，于是将​​​​max.poll.records​​​调整成为100，然后发现100s之后，LogSize和ConsumerOffset差值Lag变成了为489，于是定位到问题，是由于消费者在5分钟内没有处理完拉取到的500条消息，也即没有commit，平均一条1s多，于是​ConsumerCoordinator心跳发现消费者不响应，于是触发了​rebalance，将分区重新分给别的消费者。最终，将线上​​​max.poll.records​​​​调整为100，至此问题解决。这里也可以调整max.poll.interval.ms时间到10分钟，也能响应解决该问题。​

消费者poll()太多消息，导致处理不过来，指定拉取消息线程超过了最长空闲时间(max.poll.interval.ms)，如果超过了这个时间间隔没有发起poll操作，则​Consumer ​Group Coordination消费组认为该消费者已经离开消费组，认为消费者下线了，将进行rebalance操作。所以建议调优参数：增大 request.timeout.ms，减少 max.poll.records,  增大max.poll.intervals.ms。

kafka rebalance是kafka消费组在保证新加消费者或者移除消费者时候将分区重新分配给可用消费者的方式，该方法保证了集群的成员关系变更的管理，正常情况下，rebalance操作是正常的，应用层无感知，但是如果rebalance导致应用层报错，那么一般是消费者处理消息太慢了，此时可以优化消费者，也可以调整消费者参数，使消费者达到吞吐量和响应的平衡。