不过，

真实线上事故案例

上个月。我们线上的支付回调接口发生了一个 P1 事故。事故的根因很简单：接口不具备幂等性。

原因是第三方支付网站采用“如果没收到响应就重试”的机制。当我们的服务在处理回调时业务逻辑已成功执行。但在返回响应前发生 GC 停顿，导致第三方网站未收到响应。怎么说呢，随后几秒后第三方 重发同一条回调。

第二次回调到达时由于没有幂等校验。程序 执领域务逻辑——库存被重复扣减，使用者被多扣了一次钱。事后排查、对账和退款花了两天。

什么是幂等性

幂等来自数学定义：对同一个操作执行一次或多次结果相同。在接口设计中，即：同一个请求。无论被服务端处理一次还是多次对程序状态的影响是一致的。

// 幂等接口
process → 程序状态变为 S
// 非幂等接口
process → 程序状态变为 S1 →
调用 → S2

哪些场景必须实现幂等

• 支付回调第三方可能重复推送成功通知。
• 消息队列消费at-least-once 保证至少消费一次但不保证只消费一次。
• 使用者重复提交快速双击按钮、网络超时后手动重试。
• 接口超时重试调用方在超时后自动重试，而服务端已处理成功。
• 分布式事务补偿补偿操作可能被多次触发。

幂等 vs 防重：两个容易混淆的概念

再看方案一。数据库唯一约束

至于原理，

利用数据库的唯一索引保证同一条业务数据不会被重复插入。说起来，例如用第三方支付流水号作为唯一键。

CREATE TABLE payment_record (
id BIGINT PRIMARY KEY AUTO_INCREMENT,trade_no VARCHAR NOT NULL。order_id BIGINT NOT NULL,amount DECIMAL NOT NULL,status TINYINT NOT NULL,UNIQUE KEY uk_trade_no
);-- 当 trade_no 重复时 INSERT 会触发唯一约束冲突，数据库直接拒绝。

代码实现这方面，

@Transactional
public void handlePayCallback {
try {
PaymentRecord record = new PaymentRecord;record.setTradeNo);record.setOrderId);record.setAmount);record.setStatus;paymentRecordMapper.insert;// 首次处理
orderService.completeOrder);// 后续业务
} catch {
// 唯一约束冲突 = 重复请求，直接返回成功
log.info);}
}

适用场景的观点是。

• 业务天然有唯一标识，如支付流水号、订单号。
• ID 或流水号可以作为主键或唯一键。

从局限性来看，

• 仅适用于“插入”类操作；对于“更新”类操作需要配合其它手段。
• 高并发下大量冲突会导致数据库压力增大、事务吞吐下降。话说回来，

---

再看方案二。状态机 + 乐观锁

原理的观点是，

通过定义清晰的状态流转规则，并使用乐观锁确保每个状态变更只执行一次。典型如订单从待支付到已支付再到已发货的流程。按理说，

CREATE TABLE orders (
id BIGINT PRIMARY KEY,status TINYINT NOT NULL。-- 0:待支付 1:已支付 2:已发货 3:已完成
version INT NOT NULL DEFAULT 0,updated_at DATETIME NOT NULL
);不过，-- 状态流转规则示例：
-- 待支付 → 已支付 → 已发货 → 已完成
-- 不允许逆向流转。

代码实现 ：

@Transactional
public void handlePayCallback{
Order order = orderMapper.selectById;

if!= OrderStatus.PENDING){ log.info。skip",order.getStatus);return，}

int rows = orderMapper.updateStatus( orderId。OrderStatus.PAID.ordinal,OrderStatus.PENDING.ordinal,order.getVersion);

if{ log.info;return，}

inventoryService.deduct;notificationService.sendPaySuccess;}

对应 SQL：

sql UPDATE orders SET status = #{targetStatus}。version = version + 1,updated_at = NOW WHERE id = #{orderId} AND status = #{expectedStatus} AND version = #{version};

适用场景的观点是。

• 存在明确且不可逆的状态流转，例如订单生命周期、审批流程等。其实，
• 需要防止并发修改同一资源导致的数据不一致。怎么说呢，

  ---

  再看方案三。Token机制

  服务器生成唯一 Token，下发给客户端；客户端提交请求时携带该 Token；服务器通过 Redis 的原子删除校验是否已经使用过。若删除失败则视为重复请求，拒绝继续处理。

  java @GetMapping public String generateToken { String token = UUID.randomUUID.toString.replace;redisTemplate.opsForValue.set( "idempotent:token:" + token。"",TimeUnit.MINUTES.toSeconds);// 有效期10分钟 return token;}

  @PostMapping public Result create(@RequestBody OrderRequest req,@RequestHeader String token){ Boolean deleted = redisTemplate.delete;if){ return Result.fail;} return orderService.create;说起来，}

  适用场景这方面。

  • 使用者主动提交表单，如创建订单、审批申请；防止前端双击导致重复请求是必须的。怎么说呢，
  • 没有天然业务唯一标识时可与其他方案组合使用。

  ---