kafka消费者出现频繁Rebalance
kafka消费者在正常使用过程中，突然出现了不消费消息的情况，项目里是使用了多个消费者消费不同数据，按理不会相互影响，看日志，发现消费者出现了频繁的Rebalance。
Rebalance的触发条件
- 组成员发生变更(新consumer加入组、已有consumer主动离开组或已有consumer崩溃)
- 订阅主题数发生变更——这当然是可能的，如果你使用了正则表达式的方式进行订阅，那么新建的匹配正则表达式的topic就会触发rebalance
- 订阅主题的分区数发生变更
经过查找资料和排除发现，我们的项目里多个消费者使用了相同的消费者组，也就是同个消费者组里的多个消费者分别消费不同topic，这种情况会增大发生Rebalance的概率，原因是
消费者在zookeeper中注册中，消费者注册标识符（Consumer Identifiers Registry）是保存在zookeeper的/consumers/[group_id]/ids/[consumer_connector_id]的路径下，这些消费者注册节点形成一棵树，当有消费者加入或离开时，树上所有的消费者都会被通知到，从而进行rebanlance。
消费者在zookeeper注册的路径与topic并没有关系，反而与groupid绑定，这是因为同一个consumer可以消费不同的topic。如果不同的consumer使用同一个groupid消费不同的topic，而任何一个topic的consumer出现加入或离开等变化时，所有groupid组里的consumer都会发生rebalance。
在项目中，我们为了保证消费的有序性，所有主题均使用单分区，消费者组的作用，更多是为了单主题多分区时，使用多个消费者消费此多分区主题可以避免重复消费，我们这里使用一个消费者组里的不同消费者消费不同主题，虽然能用，但是是没有必要的，而且会有风险，就是这些消费者在同一个组时，会出现相互影响的情况，最明显的就是这次出现的频繁rebalance，只要组内有一个消费者加入或者退出，都会触发rebalance。因此，除了使用多个消费者消费单多分区的主题时使用同一个消费者组，其它情况一律建议一个消费者对应一个消费者组。
Rebalance的影响
- 数据重复消费:消费过的数据由于提交offset任务也会失败，在partition被分配给其他消费者的时候，会造成重复消费，数据重复且增加集群压力
- Rebalance扩散到整个ConsumerGroup的所有消费者，因为一个消费者的退出，导致整个Group进行了Rebalance，并在一个比较慢的时间内达到稳定状态，影响面较大
- 频繁的Rebalance反而降低了消息的消费速度，大部分时间都在重复消费和Rebalance
- 数据不能及时消费，会累积lag，在Kafka的TTL之后会丢弃数据
其中第1点由于我们是单分区，可以忽略，因此主要是2和3，我们这次出现不消费消息的情况，就是因为频繁Rebalance，在Rebalance过程中，消费者组内的所有消费者实例都会停止工作，等待Rebalance完成。
这里此前我之所以使用同一个消费者组，是在另一个功能中为了避免重复消费，直接搬过来没修改确实不应该，后续应该要引以为戒。
补充：
对于使用单个group里的多个消费者消费同一个单分区的主题，不是完全一无是处，其能一定程度提高系统的高可用性。
以下为AI的回答：
当消费者组内的消费者数量超过主题的分区数量时，虽然多余的消费者无法直接消费消息，但它们可以作为备用消费者存在。一旦某个正在消费消息的消费者出现故障（如宕机、网络问题等），Kafka的控制器（Controller）可以触发重平衡（Rebalance）操作，将出现故障的消费者所负责的分区重新分配给其他空闲的消费者。这样，即使某个消费者出现故障，也不会导致消息丢失或处理延迟，从而保证了系统的高可用性。
此外，这种配置还可以提供灵活的扩展性。随着业务的发展，消息量可能会逐渐增加，需要更多的消费者来处理。如果预先配置了多余的消费者，那么当需要增加消费能力时，只需要增加主题的分区数量，并触发重平衡操作，就可以将新的分区分配给空闲的消费者，而无需停止和重启消费者组。
然而，需要注意的是，虽然多余的消费者可以提高系统的高可用性和扩展性，但也会增加系统的资源消耗和复杂性。因此，在实际应用中，需要根据具体场景和需求来合理配置消费者数量和分区数量，以实现最佳的平衡。
参考文章
https://www.cnblogs.com/adai-study-1030/p/14793846.html
https://blog.csdn.net/hellozhxy/article/details/114602341
https://blog.csdn.net/u013200380/article/details/87868696
https://blog.csdn.net/lubin2016/article/details/125072753