💥 前言:那个让公司损失 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("订单状态异常");}}🔒 方案三:数据库唯一键 (去重表)
虽然被大厂嫌弃性能低,但在并发不高或者数据极其重要的场景(如金融账务流水),它依然是兜底的神。
核心思路:
建立一张uniq_request表,对biz_id+source建立唯一索引。
业务执行前,先往这张表 insert。
- Insert 成功 -> 执行业务。
- Insert 失败 (Duplicate Key) -> 说明重复,直接返回。
优点:绝对可靠,不依赖 Redis。
缺点:数据库写瓶颈,分库分表后处理麻烦。
📝 总结:大厂的“组合拳”
在真实的亿级系统中,我们从不依赖单一方案,而是采用漏斗式防御:
- 第一层(前端):按钮点击后 Disable,防止帕金森式手抖。
- 第二层(网关/API):Redis Token 机制。拦截 99% 的重复请求,减轻数据库压力。
- 第三层(Service/DAO):状态机 (CAS)或唯一索引。作为最后一道防线,保证数据绝对一致。
没有最好的方案,只有最适合场景的方案。
博主留言:
你在生产环境遇到过“重复扣款”的事故吗?
在评论区回复“幂等”,我发给你一份《Redis Lua 脚本通用工具类 + 状态机引擎源码》,直接复制到项目里就能用!