接口幂等性的解决方案【通俗易懂，方案全面】

一、前言

• 接口幂等性是指无论调用多少次同一个接口，对系统资源的影响都与第一次调用一致。
• 这在分布式系统、网络重试、用户误操作等场景中尤为重要。

---

二、问题场景

• 重复提交：用户快速点击提交按钮多次。
• 网络重试：客户端因超时自动重发请求。
• 消息重复消费：MQ消息因ACK失败被重复投递。
• 服务间重试：RPC调用失败后触发自动重试。

---

三、主流 / 核心解决方案

1.Token机制（唯一标识符）

• 原理：客户端提交请求前先获取唯一Token（如UUID），后续请求必须携带此Token，服务端验证后删除Token，确保仅一次有效。
• 实现步骤：
  • 1.客户端请求服务端生成Token并存储至Redis（例如order:token:用户ID）。
  • 2.客户端提交业务请求时携带Token。
  • 3.服务端通过Redis原子性验证并删除Token（如Lua脚本：if redis.call(‘get’, KEY) == ARGV then return redis.call(‘del’, KEY) else return 0 end）。 适用场景：前端表单提交、支付订单等高频操作。
• 优点：简单高效，天然防重。
• 缺点：需维护Token生命周期，需处理Redis异常。

2.唯一约束（数据库唯一索引）

• 原理：利用数据库唯一索引或主键约束，防止重复数据插入。
• 实现方式：
  • 业务字段唯一性：例如订单号（order_no）设为唯一索引。
  • 防重表：单独建表记录唯一请求ID（如request_id），插入失败即判重。
• 示例：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  order_no VARCHAR(64) UNIQUE, -- 唯一索引
  amount DECIMAL
);

• 适用场景：数据插入类操作（如创建订单、支付流水）。
• 优点：数据库层直接拦截，无需额外代码。
• 缺点：仅适用于插入场景，无法覆盖更新操作。

3.乐观锁（版本号控制）

• 原理：通过版本号（或时间戳）实现原子性更新，仅当版本匹配时才执行。
• 实现方式：
  • 表中增加version字段，初始值为0。
  • 更新时检查版本号是否一致，成功后自增。

UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE id = 1 AND version = 1;

• 适用场景：库存扣减、账户余额更新等并发写操作。
• 优点：轻量级，无需锁竞争。
• 缺点：需业务逻辑处理版本号，高并发场景可能频繁失败。

4.分布式锁（分布式系统）

• 原理：通过Redis或ZooKeeper等中间件实现互斥锁，确保同一时刻仅一个请求能执行业务。
• 实现步骤：
  • 1.请求进入时尝试获取锁（如Redis的SET key value NX EX 30）。
  • 2.获锁后执行业务逻辑，完成后释放锁。
  • 3.未获锁则直接返回或等待重试。
• 示例（Redisson）：

RLock lock = redissonClient.getLock("order:lock:" + orderId);
if (lock.tryLock()) {
    try {
        // 业务逻辑
    } finally {
        lock.unlock();
    }
}

• 适用场景：分布式环境下的全局唯一操作（如秒杀）。
• 优点：强一致性保证。
• 缺点：增加系统复杂度，需处理锁超时和死锁。

5.状态机幂等

• 原理：通过业务状态流转控制，仅允许状态单向变更。
• 实现方式：
  • 定义状态流转规则（如订单状态：待支付 → 已支付 → 已完成）。
  • 更新时检查当前状态是否允许变更。

UPDATE orders 
SET status = 'paid' 
WHERE id = 1 AND status = 'unpaid';

• 适用场景：订单、工单等有明确状态流转的业务。
• 优点：逻辑清晰，天然防重。
• 缺点：需设计严谨的状态机模型。

6.缓冲队列

• 原理：将请求异步化，通过队列消费去重。
• 实现步骤：
  • 请求快速写入消息队列（如RabbitMQ）。
  • 消费者从队列拉取消息，通过唯一标识去重后处理。
• 适用场景：高并发写入（如日志上报、批量处理）。
• 优点：削峰填谷，提升吞吐量。
• 缺点：实时性低，需额外维护消费逻辑。

7.其他方案（如前端层面、网关层面）

• 前端层面：当用户点击相关请求按钮后，在服务器端未响应结果前都将按钮置灰，即设置为【不可再点击】状态。
• 网关层面：拦截所有相关请求【如支付、下单】，检验请求id【Request ID】的唯一性，唯一则放行，反之拒绝请求。

---

四、方案选型建议

---

五、注意事项

• 原子性操作：如Token验证与删除、乐观锁更新需保证原子性（可用Lua脚本或数据库事务）。
• 超时与重试：分布式锁需设置合理超时时间，避免死锁；重试机制需结合业务降级。
• 异常处理：网络抖动可能导致Token失效或锁释放失败，需设计补偿机制（如异步对账）。

---

六、总结

• 通过合理组合以上方案，可有效解决接口幂等性问题，保障系统数据一致性和稳定性。