视频加载中...

一个6年工作经验的小伙伴，被问到这样一个问题，说Kafka是如何避免消息重复消费的？面试完之后，这位小伙伴来找到我，希望我能给一个思路。今天，我给大家分享一下我的思路。

另外，我花了1个多星期，准备了一份500页的PDF面试题解析配套文档，想获取的小伙伴可以S信我【666】免费领取！

（附赠10万字大厂内部面试资料！）

1、原因分析

我认为，导致Kafka消息重复消费有以下两个原因：

第1个原因是：Kafka消费端重复提交导致消息重复消费。

如图所示，在Broker上存储的消息，都有一个Offset标记，用来记录消费者消费消息的位置。Kafka的消费者是通过offSet标记来维护当 前已经消费的数据，每消费一批数据，Broker就会更新offSet的值，避免重复消费。

而默认情况下，消息消费完以后，会自动提交Offset的值，避免重复消费。

但是Kafka消费端的自动提交，会有一个默认的5秒间隔，也就是说在5秒之后的下一次向Broker拉取消息的时候才提交上一批消费的offset。

所以在消费者消费的过程中，如果遇到应用程序被强制kill掉或者宕机的情况，可能会导致Offset没有及时提交，从而产生重复提交的问题。

第2个原因是：Kafka服务端的Partition再均衡机制导致消息重复消费。

如图所示，在Kafka中有一个Partition Balance机制，就是把多个Partition均衡的分配给多个消费者。消费端会从分配到的Partition里面去消费消息，如果消费者在默认的5分钟内没有处理完这一批消息。就会触发Kafka的Rebalance机制，从而导致offset自动提交失败。而Rebalance之后，消费者还是会从之前没提交的offset位置开始消费，从而导致消息重复消费。

2、解决方案

基于对Kafka消息重复消费的原因分析，我认为可以通过以下两个方法来解决这个问题：

基于这样的背景下，我认为解决重复消费消息问题的方法有几个。

提高消费端的处理性能避免触发Balance，比如可以用多线程的方式来处理消息，缩短单个消息消费的时长。或者还可以调整消息处理的超时时间，也还可以减少一次性从Broker上拉取数据的条数。使用ConsumerRebalanceListener，再均衡监听器，它可以用来设定发生再均衡动作前后的一些准备或者收尾工作。开启Kafka的冥等性功能prop.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG,true);

或者将消息生成md5然后保存到MySQL或者Redis中，在处理消息之前先查MySQL或者Redis，进行判断看是否已经消费过。

以上就是我对Kafka避免消息重复消费的解决思路，小伙伴如果更好的思路也可以在评论区讨论一下。

我是被编程耽误的文艺Tom，最新一期500页PDF面试资料文档，S信我【666】拿（附赠10万字的某里内部Java面试资料！），我把之前分享的视频全部整理成了文字，希望能够以此来提高各位粉丝的通过率。关注我，面试不再难！