问题描述： 生产发版后发现控制台在疯狂刷日志：“接收到xxx推送Kafka消息 Topic：xxxxxxxxx” 最后查了下Kibana 。。。。。重复消费数量高达273w+ 这重大生产事故的锅是背定了。。。。 原本生产者是定时任务每天固定时间执行推送Kafka消息，现在怎么会收到Kafka消息？？？ 原因是修改了代码中的Kafka配置类的配置导致，之前不同的Topic使用不同的Consumer Group 为了优化代码，消除代码中冗余的配置类，让类似的业务Topic使用同一个Consumer Group进行消费 现在改为了类似业务的Topic使用同一个Consumer Group，就导致了Kafka重复消费的问题。。。

忽略的一个重点： Kafka中的Consumer Group（消费者组）通过Consumer（消费者）偏移量来跟踪它们在Topic分区中的消费位置。当我们添加一个新的Consumer Group时，它会从Topic的起始位置开始消费消息，而不考虑之前已经被其他消费者组消费过的消息。

配置中的 auto.offset.reset 配置 没有修改为latest auto.offset.reset关乎到 kafka 数据的读取，是一个非常重要的设置。 常用的二个值是latest和earliest，默认是latest。

latest和earliest区别

1、earliest 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费

2、latest 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据

提交过offset，latest和earliest没有区别，但是在没有提交offset情况下，用latest直接会导致无法读取旧数据。

既然事情已经发生了，已经没有回旋的余地，只能吃一堑长一智下次注意了

为了解决Kafka重复消费问题，我们可以采取以下方法：

使用唯一的消费者组ID： 确保每个消费者组都有一个唯一的消费者组ID，这样它们之间不会相互干扰。如果我们使用相同的消费者组ID，Kafka会将新的消费者组视为已经存在的消费者组的一部分，并从之前的消费偏移量位置开始消费。

使用Kafka的消费者组协调器： Kafka的消费者组协调器负责跟踪每个消费者组的消费偏移量，并确保每个消费者组都消费不同的消息。它会为新加入的消费者组分配新的分区，避免重复消费的问题。

手动管理消费者偏移量： 我们可以选择手动管理消费者偏移量，而不是使用Kafka的自动偏移量管理机制。通过手动管理，我们可以更加精确地控制消费者从哪个偏移量开始消费消息，避免重复消费。

在实际应用中，我们可以根据具体的需求和场景选择适合的方法来解决重复消费的问题。无论是使用唯一的消费者组ID、利用 Kafka 的消费者组协调器，还是手动管理消费者偏移量，都需要根据团队的实际情况来进行选择和配置。

总结： Kafka 是一个强大的消息队列系统，但在使用过程中，我们需要注意新消费者组导致的重复消费问题。通过使用唯一的消费者组ID、利用Kafka的消费者组协调器或手动管理消费者偏移量，我们可以避免重复消费并确保消息的正常处理。在使用 Kafka 时，合理配置和管理消费者组是保证消息处理正确性的重要环节。

希望本文能够帮助开发者更好地理解和解决 Kafka 新消费者组导致的重复消费问题，提升Kafka的使用效果和可靠性。

好文链接

评论可见，请评论后查看内容，谢谢！！！
 您阅读本篇文章共花了：