接口幂等性 (Idempotency) 终极方案：除了“去重表”，大厂都在用的 Token 机制与状态机实战-深圳市維司達科技有限公司

💥 前言：那个让公司损失 50 万的“双击”

场景还原：
双十一零点，用户手抖，对着“立即支付”按钮连点了两下。
由于网络抖动，前端的防抖失效了，两个 HTTP 请求几乎同时打到了后端。
结果：订单被支付了两次，库存扣了两份，用户发飙，财务对账对到崩溃。

这就是典型的幂等性丢失事故。
在分布式系统中，网络超时是常态。我们无法控制请求会重复发送，但我们必须保证：同一个请求，无论执行多少次，产生的效果是一样的。

很多初级开发者的反应是：“在数据库建个唯一索引（去重表）不就行了？”
Too Young.在高并发大流量下，数据库的唯一索引会成为最大的性能瓶颈，甚至引发死锁。

今天，我们就来拆解大厂都在用的**“Token 机制 + 状态机”**组合方案，彻底终结重复提交！

🛡️ 方案一：Redis Token 机制 (防抖神器)

这是目前互联网大厂最通用的方案，主要用于解决**“用户重复提交”和“前端重试”**。

核心原理：

申请令牌：客户端在进入提交页面时，先调用后端接口获取一个全局唯一的 Token，后端将其存入 Redis。
携带提交：客户端发起业务请求时（如“提交订单”），必须在 Header 中带上这个 Token。
核销令牌：后端收到请求，去 Redis 检查 Token 是否存在。
- 如果存在 ->删除 Token-> 执行业务。
- 如果不存在 -> 报错“请勿重复提交”。

流程图解：

⚠️ 致命坑点：先 Check 再 Delete？

很多新手会写出这样的代码：

// 错误示范！！！if(redis.hasKey(token)){redis.delete(token);// 假如这行代码执行前，并发请求刚好进来了怎么办？executeBusiness();}

在高并发下，这有“竞态条件” (Race Condition)！两个线程可能同时判断hasKey为真，然后都去执行业务。

正确姿势：原子性操作
必须使用Lua 脚本保证“检查+删除”是原子性的。

// Redis Lua 脚本Stringscript="if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";// Java 调用Longresult=redisTemplate.execute(newDefaultRedisScript<>(script,Long.class),Collections.singletonList(tokenKey),tokenValue);if(result==0){thrownewIdempotencyException("请勿重复提交");}// 继续执行业务...

⚙️ 方案二：状态机幂等 (业务层的最后防线)

Token 机制能挡住 99% 的用户手抖，但挡不住MQ 消息重试或者恶意攻击。
对于订单支付这类核心业务，我们必须利用业务本身的状态流转来实现天然幂等。

核心原理：
订单状态流转是有序的：待支付->支付中->已支付。
我们只需要在 SQL 更新时，带上**“前置状态”**作为条件（乐观锁思想）。

SQL 实战：

-- 场景：处理支付成功回调-- 错误写法：直接更新UPDATEorderSETstatus='PAID'WHEREorder_id=123;-- 正确写法：状态机控制 (CAS)UPDATEorderSETstatus='PAID',pay_time=NOW()WHEREorder_id=123ANDstatus='paying';-- 关键在这里！

分析：

第一次请求：当前状态是paying，匹配成功，更新为PAID，返回影响行数 1。
第二次请求（重复）：当前状态已经是PAID了，条件status = 'paying'不成立，返回影响行数 0。
代码判断影响行数为 0，直接返回“处理成功”（幂等成功），而不需要报错。

Java 代码示例：

intupdateCount=orderMapper.updateStatus(orderId,OrderStatus.PAID,OrderStatus.PAYING);if(updateCount==0){// 没更新到，说明已经支付过了，或者是状态不对// 此时应查询最新状态，如果是 PAID 则直接返回成功（幂等）Orderorder=orderMapper.selectById(orderId);if(order.getStatus()==OrderStatus.PAID){return"success";// 幂等处理}else{thrownewBizException("订单状态异常");}}