博主简介CSDN博客专家「历代文学网」PC端可以访问https://lidaiwenxue.com/#/?__c1000移动端可关注服务号 “心海云图” WX小程序搜索“历代文学”总架构师首席架构师也是联合创始人16年工作经验精通Java编程高并发设计分布式系统架构设计Springboot和微服务熟悉LinuxESXI虚拟化以及云原生Docker和K8s热衷于探索科技的边界并将理论知识转化为实际应用。保持对新技术的好奇心乐于分享所学希望通过我的实践经历和见解启发他人的创新思维。在这里我希望能与志同道合的朋友交流探讨共同进步一起在技术的世界里不断学习成长。电商幂等设计全解析从下单到支付如何为系统“防重放”别让用户的“手抖”和网络的“重试”变成你系统的“资损”事故一、引言什么是幂等为什么电商离不开它在软件开发中幂等Idempotence指的是一个操作无论执行一次还是执行多次所产生的副作用如数据变更、资金扣减是完全相同的。对于电商系统而言幂等不是“可选项”而是“必选项”。一次网络抖动、一次按钮误触、一次支付回调的重试如果系统没有幂等保护就可能产生两笔重复订单、两次库存扣减、两笔重复扣款——每一个错误都直接指向“资损”或“客诉”。本文将结合订单创建、支付回调、库存扣减三大核心场景从原理到代码详解电商幂等设计的完整方案。二、一个最常见的认知误区误解幂等设计就是“防止用户短时间内下两单”。正解幂等设计是**“防止同一个业务请求因网络重发而被重复执行”**。场景还原用户点击“提交订单”前端生成唯一请求令牌T-20260824-001并提交。服务器处理成功库存扣减订单生成。但网络异常导致响应未返回前端。前端超时后自动重试带着相同的令牌T-20260824-001再次发起请求。服务器识别出令牌已使用不再执行业务直接返回上一次的成功结果。用户最终只生成1 笔订单扣了1 次库存。如果用户真的想买两单他需要手动点击两次“提交”。前端每次点击会生成不同的令牌如T-001和T-002系统会分别处理生成两笔独立订单。幂等不会拦截合法的新请求。三、核心场景一订单创建 —— 最经典的幂等战场1. 方案选型前端生成 UUID 后端 Redis 缓存这是业界最通用、最干净的方案。前端每次点击提交调用crypto.randomUUID()生成全局唯一 ID放入请求头如Idempotent-Token。后端接收请求后以该 UUID 为 Key利用 Redis 的SET NX命令进行原子性判断Key 不存在 → 设置成功 → 执行业务创建订单、扣库存Key 已存在 → 直接返回“重复请求”不执行任何业务2. 缓存时长设计黄金法则建议值订单未支付超时时间 1~2 分钟。例如订单有效期 30 分钟则令牌缓存15~30 分钟。下限必须覆盖网络重试的最长时间通常 3~5 分钟上限必须短于订单有效期否则订单超时取消后用户重新下单会因旧令牌被拦截而无法购买3. 关于“垃圾 Key”的释怀一个 UUID Key 约占用100 字节内存。日均 100 万订单同时存活的 Key 仅约 2 万个总内存占用约2MB。Redis 自带过期删除机制这笔“保险”成本几乎可以忽略不计。四、核心场景二支付回调 —— 直接涉及资金安全的防线支付幂等的核心是防止同一笔支付流水被重复处理。1. 第一道防线数据库唯一约束在支付记录表中为第三方交易流水号Transaction ID设置唯一索引。第一次回调插入成功更新订单状态为“已支付”第二次重复回调插入时触发唯一键冲突捕获异常后直接返回成功响应告知支付平台已处理这是最硬核、最可靠的兜底方案。2. 第二道防线状态机更新订单状态是单向流转的待支付 → 支付中 → 已支付 → 已发货。更新 SQL 示例UPDATEordersSETstatus已支付WHEREorder_id?ANDstatus待支付;如果订单已经不是“待支付”状态更新影响行数为 0程序即可判断“已处理过”安全返回。3. 终极保障日终对账即使前述环节出现 Bug每日凌晨的对账系统会自动比对支付平台账单与本地记录发现差异自动告警或补单保证最终一致性。五、核心场景三秒杀扣库存 —— 高并发下的双重保障秒杀场景的特点是流量巨大、竞争激烈。库存幂等需要同时解决两个问题防超卖库存不能扣成负数防重复同一个请求不能重复扣库存1. 防超卖乐观锁 SQLUPDATEgoodsSETstockstock-1WHEREid?ANDstock0;只要库存 0 才扣减确保库存永不为负。2. 防重复Redis Lua 脚本原子操作Lua 脚本逻辑检查请求令牌或用户ID 商品ID是否已在 Redis 中标记为“已扣”若未标记则执行stock - 1并设置标记若已标记直接返回成功不扣库存将上述逻辑封装在 Lua 脚本中利用 Redis 的单线程特性保证原子性。3. 异步落库 对账秒杀订单先记录在 Redis后续异步批量写入数据库。即便极端情况下缓存丢失日终对账仍能发现并修复数据差异。六、幂等标记的三种来源并不是所有场景都需要前端传 UUID根据业务性质我们可以灵活选择来源适用场景示例前端生成下单、秒杀、领券crypto.randomUUID()后端业务组合支付回调、同步通知订单号 支付状态或第三方流水号状态机判断取消、收货、退款UPDATE ... WHERE status 待支付七、扩展场景MQ 消费与表单重复提交消息队列消费MQ 的“至少一次”语义会导致重复消费。消费者必须根据消息中的唯一业务 ID如订单号进行幂等判断或利用数据库唯一键防重。表单重复提交用户刷新或后退可能导致重复提交。同样适用“前端令牌 后端缓存”方案提交后立即失效。八、总结一句口诀 一张表判断原则如果某个功能重复执行会导致数据重复、资金损失或状态混乱那么它就必须做幂等设计。场景核心方案关键点创建订单前端 UUID Redis SET NX缓存时长 订单有效期支付回调第三方流水号唯一索引配合状态机更新扣减库存乐观锁 SQL Redis Lua 脚本防超卖 防重复MQ 消费业务唯一 ID 去重消费方自己保证幂等幂等设计本质上是用可控的存储成本如 2MB 的 Redis 内存去交换不可控的资金风险。这笔投资对于任何一个电商系统而言都是最值得的。最后送大家一句话宁可多做一次判断也不给资损留一丝机会。