Writes concise ADRs with probl…

# ADR：订单支付回调幂等消费方案

背景与问题

第三方支付渠道的回调通知存在至少一次投递特性，同一笔支付可能重复通知，导致订单重复扣款/重复发货。现状依赖数据库唯一索引兜底，存在以下问题：

• 高并发下唯一索引冲突抛异常，事务回滚粒度粗，业务代码充斥异常处理逻辑
• 唯一索引仅能防“插入重复”，无法覆盖“状态机推进”类操作（如多次回调触发多次发货）
• 频繁冲突写入造成锁等待，影响下单主链路性能

决策

采用 MQ 幂等消费 作为核心防重手段：消费端在处理前先做幂等校验（基于业务单号 + 支付流水号的幂等键），处理成功后写入幂等记录，重复消息直接 ACK 丢弃或走对账补偿。

方案要点

• 生产端：回调入口先落回调流水表（记录渠道通知原始报文），再投递 MQ
• 消费端：按“订单号 + 支付流水号”生成幂等键，处理前查重、处理后落库，两步需在同一事务或用原子操作保证
• 兜底：保留数据库唯一索引与定时对账任务作为最后防线，形成多层防御

方案对比

方案A：数据库唯一索引（现状）

• ✅ 实现简单，强一致，无额外组件
• ❌ 防重能力有限（仅限插入），冲突处理侵入业务代码，高并发下性能差

方案B：Redis 分布式锁

• ✅ 实现直观，并发拦截效果好
• ❌ 锁存在过期与续期问题，Redis 故障时锁失效，可靠性依赖基础设施
• ❌ 锁只在“处理中”互斥，无法覆盖“处理完成后重复通知”场景，需配合幂等记录，本质仍要做持久化幂等

方案C：MQ 幂等消费（选定）

• ✅ 拦截点前置，重复消息不进入业务逻辑，性能与解耦更好
• ✅ 幂等记录持久化，覆盖处理前/中/后全周期
• ❌ 引入“查重+落库”需保证原子性，需处理消息乱序与延迟投递

结论

选方案C，保留唯一索引作兜底。理由：唯一索引只能被动防插入，Redis 锁只解决并发窗口互斥，均无法完整覆盖重复通知场景；MQ 幂等消费从消息入口统一拦截，可靠性、可维护性和扩展性最优。

风险与后续

• 幂等记录表需设置 TTL/归档策略，避免无限膨胀
• 消费失败的消息进死信队列，配合对账任务补偿
• 评审待定项：幂等键粒度（订单级 vs 流水级）需结合业务确认