拉卡拉开放平台

同一笔业务被处理两次，表面看是个小概率事件，一旦发生却是实打实的资金差错。理解重复的来源，才能防得住。

重复的四条来源

从三个角度定位

1. 日志角度：找出相同单号的多条处理记录，看它们的触发入口是否相同；
2. 单号角度：确认两次处理使用的是同一个业务单号还是不同单号；
3. 时间角度：看两次发生的时间间隔，据此判断属于哪一类来源。

三个角度交叉起来，来源基本就能确定，后续防护也就有了针对性。

同一个单号还是不同单号

这一点非常关键：

• 同一单号被处理两次：说明幂等保护缺失或失效；
• 不同单号各处理一次：说明单号生成环节出了问题。

前者是防重复机制的问题，后者是单号设计的问题，修法完全不同。

幂等应该加在哪几层

• 入口层：拦截用户重复提交，通常用前端禁用加后端校验；
• 服务层：用业务唯一键保证重复请求只生效一次；
• 消息层：消费通知时用幂等键保证重复消费无副作用。

只做第一层是不够的——它能拦住用户，拦不住网络重发与消息重投。

为什么并发下容易失效

两个相同请求同时到达时，如果采用先查询再写入的方式，两边都会查不到记录，于是都继续往下执行。

正确做法是把判定与写入合并成一个不可分割的动作，例如利用唯一约束或原子操作。

发现重复之后怎么办

1. 先止损：确认影响范围，必要时暂停相关流程；
2. 再核对：逐笔比对，列出重复处理的明细；
3. 后纠正：按既定规则处理多出的部分；
4. 补防护：把缺失的幂等保护补上。

第四步不能省略，否则同样的问题还会再发生。

把重复当成常态

设计时应默认「任何请求都可能来第二次」。有了这个前提，幂等就不是补丁，而是设计的一部分。

退款与分账环节更敏感

下单环节的重复还有机会通过后续对账发现并纠正，而退款与分账的重复会直接造成资金差错，且往往要等到对账时才被发现。

因此这两处的幂等要求，应当比下单环节更严格，而不是沿用同一套标准。

给重复加一个监控

第二项尤其有用：拦截次数上升，通常意味着上游出现了异常，值得提前关注。

幂等记录的清理

幂等记录会不断累积，需要有清理策略：保留时间应覆盖可能出现的重复窗口，过期后可安全删除。清理动作本身不应影响正在进行的判定。

让重复可观测

重复不可能被完全消灭，但可以让它变得可见。只要能观测到，它就不至于悄悄造成损失。

• 记录每次拦截，形成可查询的台账；
• 定期统计拦截次数，观察变化趋势；
• 拦截次数突增时，主动向上游追查原因。

第三点是从被动防守转向主动治理的关键一步。

重复处理这件事，防胜于查。把幂等当作设计前提而非补救措施，是最省力的做法。

从这个角度看，幂等保护的收益不在于技术优雅，而在于它把一类高风险差错变成了低风险的重复拦截。