大家好，我是工作5年的Mic迷，找到我。他说：“麦克老师，如果你能回答这个问题，我就佩服你。”我当场就愣住了，现在赌注都这么随便了？我问他是什么问题，他说：“Kafka是怎么避免重复消费的问题的！”来看看普通人和专家的回答吧！普通人：Kafka如何避免重复消费就是我们可以使用它。我们可以在消息消费结束时使用类似于分布式锁的设计。我在消费一条消息的时候，可以直接在redis中使用setNx之类的命令，然后将消息保存在redis中，以后如果重复发送的话，只需要判断redis中是否存在即可。好吧。师父：那我从几个方面来回答这个问题。首先，存储在KafkaBroker上的消息都有一个Offset标记。然后Kafka消费者通过offSet标记维护当前消费的数据。每消费一批数据，KafkaBroker都会更新OffSet的值，避免重复消费。默认情况下，消息被消费后，会自动提交Offset的值，避免重复消费。Kafka消费者的自动提交逻辑有一个默认的5秒间隔，也就是说5秒后从Broker拉取下一条消息时才会提交。所以在consumer消费的过程中，如果应用被强行杀掉或者关闭，offset可能会提交不上去，造成重复提交的问题。另外还有一种情况会出现重复消费。Kafka中有一个PartitionBalance机制，就是将多个Partition均衡的分配给多个消费者。如果消费者无法在默认的5分钟内处理该批消息，则消费者端将从分配的Partition中消费消息。会触发Kafka的Rebalance机制，导致Offset自动提交失败。再平衡之后，消费者还是会从之前没有提交的offset位置开始消费，这样也会造成消息重复消费的问题。基于这样的背景，我认为有几种方法可以解决消息的重复消费问题。提高消费者的处理性能，避免触发Balance。例如，可以异步处理消息，缩短单条消息消费的市场。或者您也可以调整消息处理的超时时间。也可以减少一次从Broker拉取的数据条数。可以为消息生成md5，保存在mysql或者redis中。在处理消息之前，先去mysql或者redis判断是否已经被消费。这个方案其实是用到了幂等性的思想。以上是我对这个问题的理解。总结重复消费的问题很重要。如果不考虑，就会出现在线数据问题。因此，在面试的时候，这些问题也可以考察求职者的技术能力和实践能力。另外，我在之前的视频中讲到了幂等性的问题，大家可以自行查找。喜欢我作品的朋友记得点赞收藏关注。版权声明：除特别声明外，本博客所有文章均采用CCBY-NC-SA4.0许可协议。转载请注明来自Mic带你学建筑！如果本文对您有帮助，请给个关注和点赞。您的坚持是我不断创作的动力。欢迎关注同名微信公众号获取更多技术干货！
