kafka消费者在正常使用过程中突然出现了不消费消息的情况项目里是使用了多个消费者消费不同数据按理不会相互影响看日志发现消费者出现了频繁的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。

因此除了使用多个消费者消费单多分区的主题时使用同一个消费者组其它情况一律建议一个消费者对应一个消费者组。

数据重复消费:消费过的数据由于提交offset任务也会失败在partition被分配给其他消费者的时候会造成重复消费数据重复且增加集群压力Rebalance扩散到整个ConsumerGroup的所有消费者因为一个消费者的退出导致整个Group进行了Rebalance并在一个比较慢的时间内达到稳定状态影响面较大频繁的Rebalance反而降低了消息的消费速度大部分时间都在重复消费和Rebalance数据不能及时消费会累积lag在Kafka的TTL之后会丢弃数据

其中第1点由于我们是单分区可以忽略因此主要是2和3我们这次出现不消费消息的情况就是因为频繁Rebalance在Rebalance过程中消费者组内的所有消费者实例都会停止工作等待Rebalance完成。

这里此前我之所以使用同一个消费者组是在另一个功能中为了避免重复消费直接搬过来没修改确实不应该后续应该要引以为戒。

对于使用单个group里的多个消费者消费同一个单分区的主题不是完全一无是处其能一定程度提高系统的高可用性。

当消费者组内的消费者数量超过主题的分区数量时虽然多余的消费者无法直接消费消息但它们可以作为备用消费者存在。

一旦某个正在消费消息的消费者出现故障如宕机、网络问题等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