并发场景——接口幂等性设计

什么是接口幂等性？

用数学公式表达就是。用人话说就是同一个接口，发起一次请求和多次请求，对服务端资源产生的影响是一致的。

为什么需要幂等？（常见场景）

1. 前端重复提交：用户手抖，连续点击多次提交按钮
2. 网络超时重试（核心原因）
   1. 客户端发起请求------>服务端处理成功------>返回结果时网络断了
   2. 客户端以为服务端处理失败，触发重试
   3. 如果不做幂等，用户就被扣了两次钱
3. MQ消息重复：消息队列为了保证消息不丢失，通常采用 At-least-once机制，这导致消费会拉取到重复消息。

解决方案

面试中不要只说一种，而是要根据操作类型（更新与新增）来分类回答。

方案一：数据库唯一索引------适用于新增

实现：

• 建立表时，给核心字段（如order_id、user_id+activity_id）加上唯一索引
• 业务代码执行INSERT
• 如果抛出DuplicateKeyException（唯一键冲突异常），直接捕获，并告诉前端"已经处理成功"或"重复提交"。

优点：简单易实现

缺点：只能用于新增，不能用于更新

---

方案二：状态机幂等------适用于更新

场景：订单支付、订单发货、订单关闭

原理：利用状态流转的单向性

-- 只有当状态是"待支付"时，才允许更新为"已支付"
UPDATE orders 
SET status = 'PAID', update_time = NOW() 
WHERE id = 123456 AND status = 'UNPAID';

逻辑：

• 第一次请求：找到status='UNPAID' 的记录，更新成功，返回 1。
• 第二次请求：因为状态已经设为PAID，因此WHERE条件不满足，更行行数为0
• 代码逻辑：如果更新行数为0，说明已经处理过了，直接返回成功

---

方案三：乐观锁------适用于累加/扣减

场景：库存扣减、更新余额

原理：加上版本号version

-- 1. 先查出来 version = 1
SELECT amount, version FROM account WHERE id = 1;

-- 2. 更新时带上 version
UPDATE account 
SET amount = amount - 100, version = version + 1 
WHERE id = 1 AND version = 1;

逻辑：如果并发重复请求，第二个请求带的version还是1，而数据库里的已经是2了，说明重复了，更新失败

---

方案四：Token令牌制------最终大招

如果上述方案都用不了（比如复杂表单提交、涉及多个微服务），就需要使用Token机制，这也是分布式解决方案

核心流程：

1、获取令牌：

• 用户进入提交页面前，先调用后端接口getToken()
• 后端生成一个全局的Token（如uuid），存入Redis，并返回给前端

2、提交请求：

• 前端提交表单时，把这个Token放入Header传给后端

3、验证并删除：

• 后端接受到这个请求，去Redis查这个Token是否存在，如果存在就删除（必须是原子操作，用Lua）