分布式幂等性：30字讲透核心要点

幂等性处理是分布式系统和微服务架构中保证数据一致性与系统健壮性的核心概念。我们来系统性地梳理一下。

一、什么是幂等性？

定义 ：一个操作（或接口）被重复执行多次所产生的效果，与仅执行一次所产生的效果完全相同。

核心思想 ：无论调用一次还是多次，系统的最终状态都是一样的。这强调的是"结果"的等价，而不是"响应"必须一模一样（响应体可以不同，例如第一次返回"创建成功"，第二次返回"已存在"）。

常见例子：

• GET /user/{id}：查询操作天生幂等。

• PUT /user/{id}：用完整新数据更新资源，多次调用结果相同。

• DELETE /user/{id}：删除后资源不存在，再删结果还是不存在。

• 支付系统中的"订单支付"接口：必须幂等，防止重复扣款。

非幂等的例子：

• POST /user：通常每次调用都会创建一个新用户，产生多个资源。

• POST /order：通常每次调用都会生成一个新订单。

二、为什么需要幂等性？

在分布式环境下，网络问题无处不在：

1. 客户端重试：请求超时后，客户端可能自动重试。

2. 网络抖动：请求已处理，但响应失败，导致客户端重新发送。

3. 消息队列重试：消费端处理失败，消息被重新投递。

4. 前端防抖/重复提交：用户多次点击提交按钮。

如果没有幂等性保护，会导致：

• 重复创建订单/支付：用户被多次扣款，重大资损。

• 数据不一致：同一数据被多次更新，产生脏数据。

• 业务流程错乱：优惠券被重复核销、库存被多扣。

三、实现幂等性的常用方案

核心思路：在服务端识别出重复的请求并使其"失效"，只执行业务逻辑一次。

方案1：Token机制（适用于新增/创建类接口，如表单提交）

1. 客户端在执行业务前，先向服务端申请一个全局唯一的"幂等Token"。

2. 服务端生成Token（如UUID）并存储（可存Redis，设置较短过期时间），然后返回给客户端。

3. 客户端发起业务请求时，携带此Token。

4. 服务端收到请求后：

   • 检查Token是否存在。

   • 如果不存在 → 返回错误（"请勿重复提交"）。

   • 如果存在 → 删除Token，继续执行业务。

   • 如果执行业务失败，不能将Token加回去（否则会导致重试失效）。

5. 优点：实现简单，对业务入侵小。

6. 缺点：需多一次交互；强依赖Token存储（如Redis）的可用性。

方案2：唯一索引约束（适用于数据库插入场景）

1. 业务逻辑：通常用于防止重复插入，如订单号、流水号。

2. 实现：在数据库表中，为某个或某几个字段建立唯一索引。

3. 处理流程：

   • 客户端在请求中携带一个业务主键（如order_id）。

   • 服务端直接执行插入操作。

   • 如果因唯一索引冲突导致插入失败，则捕获异常，可认为是重复请求，直接返回成功或查询已存在的数据。

4. 优点：实现极其简单，利用数据库能力，可靠。

5. 缺点：仅适用于插入场景；数据库压力。

方案3：状态机机制（适用于有状态流转的业务，如订单）

1. 业务逻辑：很多业务对象有明确的状态，且状态不可逆（如：订单状态：待支付 -> 已支付 -> 已完成）。

2. 实现：

   • 在执行状态变更操作时，先判断当前状态是否允许变更。

   • 例如，支付成功后，订单状态从"待支付"改为"已支付"。当重复的支付请求到来时，发现状态已是"已支付"，则直接返回成功，不再执行扣款等后续逻辑。

3. 优点：贴合业务，逻辑清晰，无需额外存储。

4. 缺点：需要精心设计状态流转；只适用于有状态模型。

方案4：分布式锁机制

1. 思路：在执行业务前，先获取一个与本次请求相关的锁，确保同时只有一个请求能进入核心逻辑。

2. 实现：

   • 使用Redis的SET key value NX PX timeout命令，key由业务标识构成（如order_pay_{orderId}）。

   • 获取到锁的请求继续执行业务，执行业务完成后释放锁（或等待自动过期）。

   • 未获取到锁的请求，直接返回"请求处理中"或等待。

3. 优点：能保证强一致性，防止并发问题。

4. 缺点：性能有损耗；锁的粒度、超时时间需仔细设计。

方案5：乐观锁机制（适用于更新场景）

1. 思路：基于数据版本（Version）或条件（如库存数）。

2. 实现：

   • 在数据表中增加一个version字段。

   • 更新时，带上这个版本号：UPDATE table SET field= new_value, version=version+1 WHERE id=#{id} AND version=#{old_version}。

   • 检查影响行数，如果为0，说明数据已被其他请求修改过，本次请求可视为过期或重复，进行相应处理（如返回错误或重试）。

3. 优点：避免使用锁，提高并发性能。

4. 缺点：需要修改表结构；在频繁冲突的场景下，重试次数多。

四、幂等性处理的最佳实践与流程

标准处理流程（以支付接口为例，结合Token或唯一ID）

1. 定义幂等键：确定请求的唯一标识。例如：
   - 订单号 + 业务类型 (`orderId:pay`)
   - 客户端生成的唯一请求ID (`requestId`)
   - 服务端颁发的Token

2. 请求入口拦截：
   - 请求到达时，首先提取幂等键。
   - 查询"幂等记录存储"（如Redis）中该键的状态。
      状态可能为：
        a) 不存在 -> 新请求
        b) 存在，且状态为`处理中` -> 返回"处理中，请稍后查询"
        c) 存在，且状态为`成功` -> 直接返回上次成功的结果（需缓存结果）

3. 处理新请求：
   a) 在"幂等记录存储"中，将键的状态设置为`处理中`（设置合理的超时时间）。
   b) 开始执行业务逻辑（如扣款、更新订单状态）。
   c) 业务逻辑执行完毕：
        - 成功：将键的状态更新为`成功`，并可选地存储处理结果。
        - 失败：删除`处理中`的状态（或标记为`失败`），允许重试。

4. 返回结果。

关键决策点：

• 幂等键的生成：客户端生成（需保证全局唯一） vs 服务端生成（多一次交互）。

• 存储的选择：Redis（高性能，可设置TTL） vs 数据库（可靠，但性能稍差）。

• 结果缓存：对于读多写少的场景，可以缓存成功结果，直接返回，减轻数据库压力。

• 处理中状态：防止接口超时重试时，多个请求同时执行业务逻辑（"防并发"）。

五、总结与选型建议

场景	推荐方案	原因
表单提交、创建请求​	Token机制 ​ 或 唯一索引​	防止用户重复点击，简单有效。
订单支付、交易核心​	唯一ID + 状态机​	订单号唯一，且状态流转明确，结合数据库事务最可靠。
库存扣减、余额更新​	乐观锁 ​ 或 分布式锁​	在高并发下保证数据准确，乐观锁性能更优，锁更安全。
消息队列消费​	消息唯一ID + 存储去重​	利用消息中间件的重试机制，在消费端做幂等判断。
简单的更新操作​	状态机 ​ 或 乐观锁​	利用现有业务状态或版本号，无侵入。

最终原则 ：没有银弹。在实现时，需要根据具体的业务场景、并发量、数据一致性要求，选择一种或多种组合方案。

核心永远是：识别出重复的请求，并确保其不产生副作用。