什么是 Kafka 重复消费消息？
Kafka 的消费语义是 “At-Least-Once”（至少一次），意味着消息有可能被消费多次，但不会丢失，这就带来了重复消费的可能性。
重复消费可能会对业务系统造成多种负面影响，具体取决于消息所承载的业务逻辑。
如果消息的处理逻辑是将数据写入数据库，重复消费可能导致在数据库中创建重复的记录。
比如：如果消息用于更新系统状态（例如，订单状态、库存数量），重复处理可能会导致状态发生错误或不一致。
再比如：重复支付的场景， 如果消息触发支付操作，重复消费可能导致用户被多次扣款。
总而言之，重复消费如果不加以妥善处理，可能会严重影响业务的正确性、数据的可靠性和系统的稳定性。
如何处理消费者重复消费问题？
针对 Kafka 消费者重复消费的问题，可以从多个层面采取措施，核心思想是使消息的处理过程具有幂等性。
1. 确保消息处理的幂等性 (Idempotency) – 最根本的解决方案
这是解决重复消费问题的核心和最有效的方法。
无论消息被消费多少次，其处理结果都应该是一致的，不会对系统产生额外的副作用。
实现幂等性的常见策略包括：
唯一标识符机制：
Producer 端生成唯一 ID： 在 Producer 发送每条消息时，为其生成一个全局唯一的 ID（例如，UUID）。
Consumer 端记录已处理的 ID： Consumer 在处理消息时，首先检查该唯一 ID 是否已经被处理过。
可以使用数据库、Redis 等外部存储来记录已处理的 ID。
处理前判断： 如果该 ID 已经存在于已处理记录中，则直接忽略该消息，不再进行业务逻辑处理。
IF NOT EXISTS (SELECT 1 FROM processed_log WHERE msg_id = ?) THEN -- 执行业务逻辑 INSERT INTO processed_log (msg_id) VALUES (?); END IF
数据库唯一约束：
如果消息的处理结果需要写入数据库，可以利用数据库的唯一约束（例如，唯一索引或主键）来防止插入重复的记录。
当尝试插入已存在的记录时，数据库会抛出异常，Consumer 可以捕获该异常并忽略该消息。
2. 手动提交 Offset (Manual Offset Commit) – 减少重复消费的概率
offset 只有在消息成功处理之后才提交，避免“先提交、后失败”的问题。
props.put("enable.auto.commit", "false");
...
try {
// 消费逻辑
consumer.commitSync(); // 成功后提交 offset
} catch (Exception e) {
// 不提交，留给下次处理
}
精准控制 offset，失败不会误提交。
但需要，配合重试逻辑、死信队列机制避免无限重试。
3. 精确一次处理 (Exactly-Once Semantics) – 更高级的保障
Kafka 从 0.11 版本开始引入了事务 API，结合幂等 Producer，可以实现端到端的精确一次处理语义。
props.put("enable.idempotence", "true");
可实现端到端 Exactly Once。
4. 死信队列 (Dead Letter Queue – DLQ)
对于那些经过多次重试仍然无法成功处理（包括因非幂等性问题导致的处理失败）的消息，可以将其发送到死信队列。
死信队列中的消息可以被后续的独立流程进行分析、诊断和人工处理。
以便找出问题的原因并进行修复，同时避免这些失败的消息一直阻塞正常的消费流程。
mikechen
mikechen睿哥，10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【架构】即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》