幂等（idempotent）是一个数学与计算机学概念，常见于抽象代数中。
在我们的开发过程中，保证幂等性就是保证你的程序的无论执行多少次，影响均与第一次执行的影响是一致的，产生的结果也是一样的。而幂等函数(幂等方法)，是指使用相同的参数结构重复执行，产生相同的结果的函数，重复执行幂等函数不会影响系统的状态或者造成改变。
常见幂等性问题
典型的违反幂等原则导致的问题，如：
1.订单处理场景
订单创建：用户提交订单时，可能因网络问题导致请求重复发送，系统需确保同一订单号只创建一次，避免生成多个相同订单。
订单状态变更：订单状态从"待支付"变更为"已支付"是，若客户端重复发送状态变更请求，系统需要保证只变更一次，避免状态不一致。
2.库存扣件场景
高并发抢购：在秒杀、抢购活动中，大量用户同时发起库存扣减请求，系统需保证同一个商品库存只被扣减一次，避免超卖。
分布式库存扣减：在分布式系统中，多个服务节点可能同时处理同一商品的库存扣减请求，需通过幂等设计保证数据一致性。
3.支付与退款场景
支付重复提交：用户在网络波动或前端响应延迟等情况下，可能多次点击支付按钮，导致同一笔订单被多次扣款。
退款操作：在退款接口中，若客户端因超时未收到响应而重试，或恶意用户利用漏洞重复提交退款请求，导致商家资金损失。
4.消息队列场景
消息重复投递：在消息队列中，消息可能因网络问题或消费处理失败而被重复投递。
消息重复消费：消费者在处理消息后，未正确发送确认信号，导致消息被重新投递，系统需要确保消息只被处理一次。
幂等性目标
- 同一请求多次执行 -> 系统状态始终一致
- 不同请求 -> 系统正常处理差异
常见的7种解决方案
方案1:Token令牌机制（防重复提交）
原理：Redis创建Token，客户端先获取唯一Token，后续请求携带Token，服务端校验是否已被使用。
适用场景：订单创建、表单提交等插入类操作。
方案2:唯一ID + 去重表（防重复处理）
原理：为每次请求生成唯一ID（如UUID、雪花算法生成的ID），请求前查询去重表，若存在则直接返回。
适用场景：支付回调、订单状态变更等更新类操作
实现要点：
- 使用学画算法生成分布式唯一ID
- 数据库建立唯一索引保证原子性
缺点： - 需要额外的数据库操作，影响性能
- 防重表可能成为性能瓶颈，需要合理设计索引和分片
方案3:唯一索引或唯一组合索引
原理：唯一索引或唯一组合索引来防止新增数据出现脏数据（当表存在唯一索引，并发执行时，先进入的执行成功，后进入的会执行失败，说明该数据已经存在了，返回结果即可）。
适用场景：订单创建、注册、会议室抢订等插入类操作，避免插入同样信息的脏数据。
典型案例：中秋节到了，淘宝上线某款限量版的月饼，每个用户都只能购买一盒月饼，如何防止用户被创建多条月饼订单数据，可以给月饼销售表中的用户ID加唯一索引，保证一个用户只能创建成功一条月饼订单记录。
方案4:乐观锁（读多写少场景）
原理：通过版本号控制更新，仅当数据版本与当前请求版本一致时执行操作（CAS）。
适用场景：账户余额更新、库存扣减等
方案5:状态机
原理：定义状态转移规则，确保操作只能合法状态跳转。
适用场景：订单生命周期管理（如：已支付 -> 已发货）
典型案例：
在设计单据相关业务，或者任务相关业务时，肯定会涉及到状态机（状态变更），就是业务单据上面有个状态，状态在不同情况下会发生变更，一般情况下存在有限状态机。
这时候，如果状态机已经处于下一个状态，这时候来了一个上一个的变更，理论上是不能够变更的，保证了有限状态机的幂等。
注意：订单等单据类业务，存在很长的状态流程，一定要深刻理解状态机，对业务系统设计能力提高有很大帮助。
方案6:分布式锁（强一致性要求）
原理：通过Redis或Zookeeper实现互斥锁，确保同一时间仅处理一个请求。
使用场景：超卖保护、秒杀库存扣减。
方案7:前后端双重校验
原理：前端防抖（如按钮置灰或者浮起旋转框）+ 后段唯一ID校验
适用场景：低并发场景快速实现（如用户注册等）
方案对比和选型参考
| 方案 | 性能 | 复杂度 | 适用场景 |
|---|---|---|---|
| Token机制 | 高 | 低 | 插入类操作（如：订单创建等） |
| 唯一ID + 去重表 | 中 | 中 | 更新类操作（如：状态变更等） |
| 唯一索引/唯一组合索引 | 中 | 低 | 插入类操作（如：订单创建、注册等） |
| 乐观锁 | 高 | 低 | 读多写少场景（如：余额更新） |
| 状态机 | 中 | 中 | 有状态流转（如：订单生命周期管理） |
| 分布式锁 | 高 | 中 | 强一致性（秒杀库存） |
网友评论