接口超时后自动重试，结果对方系统收到两笔相同订单——这是接口对接中最常见的数据重复来源。核心原因在于超时并不代表请求未到达，重试若不携带可识别的幂等标识，接收方就无法判断这是新请求还是重复请求。合理的做法是：先确定重试的发起方与触发条件，再在请求协议层引入幂等键，最后用对账或补偿任务兜底漏处理的数据。
场景一：同步调用超时后的即时重试
调用方在等待响应超时后立即重发，是最直接的补救方式。它链路短、实现成本低，但如果没有幂等约束，每一次重试都可能产生一条新记录。
- 优点：改动局限在调用方，不依赖中间件；对短时抖动（网络闪断、对方瞬时繁忙）恢复快。
- 缺点：只适合短超时场景；链路中任一节点做了重试会放大重复概率；失败原因无法区分是网络问题还是业务拒绝。
- 设计要点：重试次数建议控制在有限范围（如两到三次），采用退避间隔而不是固定间隔；只对可重试的错误码重试，业务校验失败不重试。
幂等键通常由业务主键或「业务类型+单号+操作版本」组合生成。接收方在写库前先落幂等记录，命中已有记录则直接返回成功结果，不再执行二次写入。幂等记录的保存周期至少覆盖业务可能的重复窗口。
场景二：异步消息或任务队列驱动重试
把请求写入队列，由消费者负责投递与重试，是集成规模变大后的常见选择。它把重试从同步链路中剥离，调用方不必长时间等待。
- 优点：重试次数、间隔、死信处理可统一配置；调用方响应快；失败任务可集中查看与人工干预。
- 缺点：需要额外维护队列与消费者；消息可能重复投递，消费端同样要幂等；引入投递延迟，对实时性要求高的流程不适用。
- 设计要点：消费端按幂等键判重，处理完成后再确认消息；设置最大重试次数后转入死信，避免无限循环。
如果系统里已有较多外部接口需要统一管理重试与幂等，建议在设计阶段就把这套约束纳入软件定制开发与系统集成服务的接口规范，而不是每个接口各写一套。具体交付阶段怎么切分，可参考服务范围与交付流程。
场景三：定时对账与补偿任务兜底
不依赖实时重试，而是定时比对双方数据，发现缺口再补发。它针对的是「重试全部失败」和「响应丢失但对方已处理」两类情况。
- 优点：能覆盖跨天、跨批次的数据缺口；不增加主链路耗时；对历史遗留接口改造压力小。
- 缺点：补偿有延迟，不适合强实时场景；对账口径要与业务方确认，否则会反复补发同一条数据；只补结果不补过程，排查问题时信息有限。
- 设计要点：对账任务本身也要幂等，补发时复用原幂等键；记录每次补偿的原因与结果，便于复盘。
在物流与供应链、制造这类单据流转密集的场景中，对账补偿往往和重试一起使用。类似的数据对齐问题我们做过一些项目，可以看物流与供应链案例了解业务形态。
什么情况下不要用重试来解决重复问题
重试是补偿手段，不是数据一致性的根本方案。遇到以下情况，应优先改协议或改流程，而不是堆重试策略：
- 对方接口完全不支持幂等判重且无法改造——此时重试只会制造更多重复，应改为对账补差或人工确认。
- 业务本身要求严格顺序（如状态机流转）——并发重试会打乱顺序，需要改为单线程串行处理或加状态校验。
- 失败原因是参数错误、权限不足、业务规则拒绝——这类错误重试没有意义，应直接失败并告警。
- 链路里已有中间件在做重试——多层重试会成倍放大请求量，需要先收敛到一层。
如果接口方是老系统、短期无法提供幂等支持，可以用调用方生成唯一业务号、接收方以业务号做去重表的方式过渡。具体做法视对方可改造程度而定，拿不准时建议先做小范围 POC 验证。
重试参数与幂等键的设计清单
下面这份清单可以直接用在方案评审和上线验收：
- 是否明确哪些错误码可重试、哪些不可重试，并写在接口文档里。
- 重试次数与退避间隔是否有上限，是否避免固定间隔造成同时冲击。
- 幂等键是否由调用方生成，是否保证同一业务动作在多次重试中保持不变。
- 接收方是否先判重再写库，判重与写入是否在同一事务或同一致机制内。
- 幂等记录的保存周期是否覆盖对账与补偿窗口。
- 是否设置死信或失败队列，是否有告警与人工介入入口。
- 对账任务的口径是否与业务方书面确认，补发是否复用原幂等键。
- 日志中是否记录请求编号、幂等键和重试轮次，便于追查重复来源。
常见问题
重试三次够不够？
次数取决于接口的稳定性与业务容忍度，没有统一标准。常见做法是针对短时抖动设置有限次数并配合退避，真正兜底靠对账补偿。次数过多会拉长响应时间，也增加对方压力。
幂等键用数据库自增主键行不行？
不行。重试时还没拿到对方主键，无法用它判重。幂等键应由调用方在发起前生成并携带，接收方只负责判断是否已处理过。
只做对账不做实时重试可以吗？
可以，前提是业务能接受延迟。对账补偿覆盖度高但时效差，适合批量类、非实时单据。对用户等待结果的场景，仍需要接口层有基本重试。
结束前再核对一遍：重试是否只有一层、幂等键是否全程透传、失败任务是否有归属人。这三项确认下来，重复数据问题基本就收敛了。需要一起梳理接口规范时，可以通过联系我们沟通具体场景。
