消息重复消费

Kafka 消息重复消费的原因及解决方案

在 Kafka 中，消息重复消费是一个常见问题，本质上是 Kafka 的“至少一次”（At Least Once）语义导致的。下面先分析原因，再给出具体解决方案。

消费者提交偏移量失败
消费者拉取消息并处理完成后，在提交 offset 之前发生崩溃、重启或 Rebalance，导致未提交 offset。重新消费时会从上次提交的 offset 之后开始，造成部分消息重复。
生产者重试导致 broker 重复写入
生产者因网络抖动未收到 ACK，触发重试，实际上 broker 已写入成功，导致同一条消息被写入多个副本或同一分区多次（但 Kafka 0.11+ 引入幂等生产者可以避免）。
消费者 Rebalance
当分区被重新分配给其他消费者时，如果当前消费者正在处理消息但还未提交 offset，新消费者会从旧 offset 开始消费，产生重复。
手动提交时未使用事务/幂等
在 enable.auto.commit=false 且业务处理与提交 offset 不是原子操作时，可能出现“消息处理成功但 offset 提交失败”的重复场景。

根本原则：让消费处理操作具备幂等性 —— 无论同一条消息被处理多少次，最终的业务结果与只处理一次完全相同。

数据库唯一键约束
将消息中的唯一标识（如订单号、事务ID）作为数据库表的唯一索引。插入时遇到重复键则忽略或更新，保证业务表不会重复记录。
Redis 原子去重
使用 Redis 的 SETNX 或带 TTL 的 key，在处理消息前先写入去重标记。例如：
```
key = "msg_id:" + messageId
if redis.setnx(key, "1") then
    expire key 60   # 设置合理的过期时间
    process(message)
else
    # 已处理过，跳过
end
```
需注意 Redis 持久化和异常情况下的重复判断。
业务状态机校验
根据业务状态（如订单状态已从“待支付”变为“已支付”），再次收到相同消息时直接忽略或返回成功。

Kafka 从 0.11 版本开始支持幂等生产者 + 事务，可实现端到端的精确一次处理。

幂等生产者 (enable.idempotence=true)
自动去重生产者重试导致的重复写入，每个生产者会生成一个 Producer ID 和序列号，broker 根据序列号判断是否重复。
事务
使用 initTransactions()、beginTransaction()、commitTransaction() 将“消费-处理-提交 offset”作为原子操作。需要消费者设置 isolation.level=read_committed 且配合事务性生产者。
Kafka Streams 或 Kafka Connect 内部支持精确一次语义。

方案	实现复杂度	性能影响	适用场景
业务幂等（唯一键）	中	低	大多数业务场景，如订单、支付、库存
Redis 去重	低	高	高并发、需要快速去重且可容忍极少量漏判
Kafka 事务 + 幂等生产者	高	较高（事务有额外开销）	金融、对账等严格 exactly-once 的场景
修改提交策略	低	无	只减少重复概率，不能根除

默认方案：消费端实现幂等性（例如用数据库唯一键约束）。这是最通用、最可靠的解法，不依赖 Kafka 版本或特殊配置。
配合配置：
- 生产者设置 acks=all、retries=Integer.MAX_VALUE、enable.idempotence=true（Kafka 2.0+ 默认开启）。
- 消费者设置 enable.auto.commit=false，手动提交偏移量。
监控与补偿：
- 记录重复消息的日志和指标，设置告警。
- 对不可幂等的操作（如发送短信、邮件）需额外设计防重机制（如业务流水号+分布式锁）。

消息重复消费无法 100% 避免，但可以通过幂等性设计将重复的影响消除到业务无感知。

面试时回答重点：先解释原因（提交 offset 失败、Rebalance、生产者重试），再给出三个层次解决方案——