我们都都知道kafka的消费组要rebalance，需要触发以下3个条件之一：
- 组成员变更，比如新consumer加入组，或已有consumer主动离开组，再或是已有consumer崩溃时则出发rebalance.
- 组订阅topic数发生变更，比如使用基于正则表达式的订阅，当匹配正则表达式的新topic被创建时则会出发rebalance.
- 组订阅topic的分区数发生变更，如何使用命令行脚本增加了订阅topic的分区数
但是我在学习kafka过程中，看到别人遇到一种情况，也会发生kafka rebalance:
该组下的consumer的要处理消息的逻辑过重。
以下是原话：笔者曾经遇到过一个Kafka的线上环境，发现该环境的consumer group频繁的进行rebalance,但组内所有consumer程序都未出现崩溃的情况，另外消费组的订阅情况也从未发生过变更。经过一番详细的分析，最后笔者定位了原因：该group下的consumer处理消息的逻辑过重，而且时间时间波动很大，非常不稳定，从而导致coordinator会经常性的认为某个consumer已经挂掉，引发rebalance。而consumer程序中包含了错误重试代码，使得落后过多的consumer会不断的申请重新加入组，最后表现为coordinator不停的对group执行rebalance,极大降低了consumer端的吞吐量。鉴于目前一次rebalance操作的开销很大，生产环境中用户一定要结合自身业务特点仔细调优consumer参数request.timeout.ms、max.poll.records、和max.poll.interval.ms，以避免不必要的rebalance出现。
