从一次支付重复扣款的线上故障，聊聊 MQ 消费幂等性究竟该如何落地实践

聊个老生常谈但每次上线都让人提心吊胆的话题：MQ 消费幂等到底怎么落地才稳？

早年做支付网关的时候，我踩过一个刻骨铭心的坑： 上游通道网络闪断 -> 消息没收到 ACK 触发重发 -> 两条一模一样的扣款成功消息几乎同时打到两个 Pod 上 -> 当时图省事用了 Redis 的 SETNX 做防重，锁过期时间设了 3s -> 偏偏那天账务服务 GC 卡顿导致业务逻辑跑了 4s -> 锁提前释放，第二条消息再次杀入 -> 最终导致用户账户被双重入账。

那次复盘后，我把因果链理了一下，核心矛盾其实是：高并发吞吐 vs 强一致保证。

目前团队在做交易和订单重构（Golang / Java 混编架构），我们内部有几种解法，各有代价：

1. DB 唯一索引（防重表 / 业务流水号）：最稳妥，因果链闭环（DB 事务兜底），但大促高峰期 TPS 一高，数据库写入压力直接拉满，分库分表下更是头疼。
2. Redis 分布式锁 + 业务状态机：性能极好，但遇到主从切换锁丢失，或者像我上面提到的“执行耗时 > 锁超时时间”，依旧有极低概率击穿。
3. 前置 Redis 防重 + 最终状态机乐观锁限制：比如 UPDATE order SET status = 'PAID' WHERE id = 1001 AND status = 'INIT'，用影响行数来判断是否已经处理过。

想问问社区的各位老兵： 在千万级以上流水或者核心资金链路里，你们是如何权衡防重表落库性能开销和极端场景一致性的？遇到过由于 MQ 乱序导致“后发先至”，直接把状态机打挂的情况吗？大家目前线上最推荐的最佳实践是哪一套？