幂等（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校验
 适用场景：低并发场景快速实现（如用户注册等）

 方案对比和选型参考