Kafka 重复消费导致账务重复入账：幂等表唯一索引为什么必须建在业务库而不是 Redis

作者沈寒山-376

Kafka幂等消息队列重复消费账务系统

结论先行："消费成功才提交 offset" 在 Kafka 里是 at-least-once，不是 exactly-once。重复消费是必然会发生的事，你的系统必须在业务层幂等。而幂等表放 Redis 是我最常看到的一个错误设计——它把幂等键的生命周期和一台会丢数据的中间件绑定了。

一、现象：一笔 317 单的重复入账

我负责一条支付清算链路：上游交易服务把「订单支付成功」事件写入 Kafka（Kafka 3.5，3 副本，min.insync.replicas=2，acks=all），下游账务服务 4 个消费者并发消费，日增量约 4200 万条。

某日凌晨 03:12，账务服务一个 pod 在 GC 后 OOM 被 K8s 杀掉重启。重启后 40 分钟内，对账系统发现 317 笔订单重复入账，涉及金额 84.6 万元，全部是「原账 + 一笔完全相同的重复账」。资金侧当天走应急冲正，但影响面是：对账延迟 3 小时、37 个用户收到重复到账短信、值班同学被拉了 4 小时故障会。

事后还原：OOM 发生时，消费者已经完成了「记账 + 发通知」，但 commitSync 还没执行（它在事务提交后、方法返回前的最后一步）。pod 重启后从旧 offset 重新消费，业务代码里 insert 幂等记录时用的是 SELECT 有没有 → 没有就 insert 的非原子写法，并发窗口里两条消息各查了一次「没有」，于是各记了一笔。

二、根因：三层防线，每一层都有洞

第一层：Kafka 的投递语义。 只要你的 handler 不是「原子地完成业务 + 提交 offset」，at-least-once 就一定会在崩溃、rebalance、网络抖动的时刻变成「重复消费」。这不是 bug，是设计。很多人以为用事务（Kafka transactions）就能解决——它解决的是「多个 topic 原子写」，不解决「Kafka 写入 + 你的 MySQL 业务」这两个系统之间的一致性问题。跨系统的 exactly-once 只有 outbox / 幂等两条路。

第二层：幂等检查的原子性。 SELECT count(*) FROM idempotent WHERE biz_key = ? 然后 INSERT，这在单机串行下没问题，在「同 partition 消息重试 + 多消费者」下必炸。两个线程都查到了 0，都插入成功。

第三层：幂等存储的可靠性。 我们当时的幂等键是 Redis SET biz:pay:{orderId} 1 EX 86400。Redis 7 主从 + 哨兵，异步复制。Redis 主节点宕机切主时，还没同步到从节点的 SET 会丢——丢一次，幂等键就失效一次，等于给重复消费开了门。而且 86400 秒的 TTL 意味着超过 24 小时的迟重放直接绕过检查。

三、具体做法：把幂等做进业务库

改造后是这套，可以直接抄：

1. 幂等表放业务库，靠唯一索引兜底：

CREATE TABLE t_pay_idempotent (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  biz_key VARCHAR(64) NOT NULL,          -- 业务唯一键，如 pay:20260101:orderId
  status TINYINT NOT NULL DEFAULT 0,     -- 0=处理中 1=成功 2=失败
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  UNIQUE KEY uk_biz_key (biz_key)        -- 关键：唯一索引，不是普通索引
) ENGINE=InnoDB;

2. 处理流程改为「先占坑，后干活，占坑靠 DB 原子性」：

// 第一步：INSERT，唯一索引冲突就抛 DuplicateKeyException —— 这一步是原子的
try {
    jdbc.update("INSERT INTO t_pay_idempotent(biz_key, status) VALUES(?, 0)", bizKey);
} catch (DuplicateKeyException e) {
    // 已经处理过 / 正在处理：直接返回成功，幂等命中
    return Ok.idempotentHit();
}
// 第二步：记账（同一个本地事务）
ledgerService.credit(order);
// 第三步：标记成功
jdbc.update("UPDATE t_pay_idempotent SET status=1 WHERE biz_key=?", bizKey);
// 第四步：提交 offset（消费框架层）

注意顺序：占坑和记账要放进同一个数据库事务里（先 INSERT 幂等行、再写账、一起 commit），这样不会出现「占坑成功但没记账」的悬挂状态——崩溃后重放会走 DuplicateKey 分支直接跳过，账没记，这就是对的（宁可不记，不能重复记，漏账靠上游 outbox 补偿）。

3. 对账兜底（不能省）： T+1 对账任务里加一条「按 orderId 聚合账表，count > 1 即告警」的 SQL，把重复入账的发现时间从「用户投诉」压到「小时级」：

SELECT order_id, COUNT(*) c
FROM t_ledger
WHERE dt = CURDATE() AND biz_type = 'PAY_CREDIT'
GROUP BY order_id HAVING c > 1;

上线后 6 个月，重复入账为 0，幂等命中（重放被正确拦截）累计 214 次——也就是说这套防线真的在每天干活，只是不再产生故障。

四、踩过的坑 / 反直觉之处

Redis 幂等键不是「快」，是「脆」。 省下的那次 SELECT（约 0.3ms）换来的是主从切换丢键 + TTL 边界失效，账目系统里这笔交易永远不划算。Redis 适合做「防刷」，不适合做「账务幂等」。
DuplicateKeyException 是特性不是异常。 很多团队把唯一键冲突当错误打 ERROR 日志 + 告警，结果重放高峰时告警风暴。正确姿势：捕获后按「幂等命中」打 INFO，单独计数。
TTL 该多长？答案是：幂等表不该有过期。 账务幂等键要留至少和账期一致（我们保留 2 年），用归档任务迁历史表，而不是靠 TTL 自动清。
rebalance 不是故障，是常态。 我们 4 消费者每天平均发生 6 次 rebalance（pod 扩缩容、GC 停顿超过 session.timeout.ms=45s 都可能触发），每次都伴随至少一次重复消费。把它当成「每天必发生 6 次」来设计，而不是当成异常。
min.insync.replicas=2 + acks=all 只保证消息不丢，不保证消息不重复——这两个「不」经常被混淆。

五、结论与可复用清单

[ ] 任何「消费 MQ → 写业务库」的链路，默认按 at-least-once 设计，幂等键 + 唯一索引是标配；
[ ] 幂等表放业务库（与业务写同事务），Redis 只做旁路加速（可选）；
[ ] 占坑必须 INSERT 靠唯一索引判重，禁止 SELECT 再 INSERT；
[ ] 占坑与业务写放同一个数据库事务，宁可漏记（靠 outbox 补偿）不可重复记；
[ ] DuplicateKeyException 按幂等命中处理，打 INFO 不打 ERROR；
[ ] 对账任务里加「同一业务键多行」的聚合告警，发现时间压到小时级；
[ ] 幂等键保留期 ≥ 账期，归档而不 TTL；
[ ] 把 rebalance / 重放当常态流量，监控里单独给「幂等命中率」一个指标，命中率突然飙高 = 上游在批量重发。

一句话总结：Kafka 负责让你「不丢」，你的业务库负责让你「不重」——这两件事谁也不能替谁做。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。