业务幂等性如何验证和实现？

核心回答

业务幂等指同一业务操作被重复提交或重试时，不产生第二次不应发生的副作用。应先定义“同一个操作”的业务标识和最终不变量，再用原子约束、状态机及结果记录实现，并通过并发、超时和崩溃场景验证。

支付场景的目标通常是同一支付单不会重复记账或扣款，不是让系统保证网络上永远只收到一次请求。

如何实现

客户端或业务入口使用稳定请求键，重试保持同一键；服务端将键与租户、操作类型、关键参数绑定。同键不同参数应拒绝或明确处理，避免误把两笔合法操作合并。不能只用时间很短的请求哈希窗口代替业务定义。

对单数据库业务，可使用唯一约束争抢处理资格，把幂等记录、业务状态变化和结果尽量放在同一事务内完成。并发请求要由数据库原子判定，不能先查“是否处理过”再无保护地插入。

状态可以区分处理中、成功和失败，重复请求按状态返回已有结果、等待或查询。处理中进程崩溃时，要有租约、执行代次或恢复任务，不能永远卡在处理中。幂等记录的保留期应覆盖实际重试与消息重投窗口，过早清理后旧请求可能再次产生副作用。

跨支付渠道、消息系统等外部边界时，本地事务无法覆盖全部动作。调用外部服务使用其支持的幂等标识，超时先识别结果未知，结合状态查询、回调去重与对账恢复；记账和发消息可结合 outbox 等可靠模式。

如何验证

使用能实际观察副作用的测试环境，至少覆盖：

1. 同键顺序重放，以及多线程同时提交同键，最终只出现一份业务结果。
2. 同键不同参数被识别，不同键的合法操作不会被错误合并。
3. 业务提交成功但响应丢失后重试，能返回已完成状态而非再次执行。
4. 执行前、提交中、提交后等故障窗口，以及重复/乱序回调和消息，最终状态可恢复且金额约束成立。
5. 幂等记录到期、任务接管和长时间延迟重试的边界。

断言应检查订单、流水、库存等事实，而不只看接口都返回成功。可用独立汇总或账务不变量作为预期，例如一笔交易只有一个有效记账结果。

常见追问

加 Redis 锁是否就幂等？ 锁主要控制并发进入；锁过期、故障和业务提交后重试仍需幂等记录与原子业务约束。

参考资料