分布式系统中的幂等性设计

描述
在分布式系统中，幂等性（Idempotency）指一个操作被执行一次或多次所产生的结果完全相同。例如，在支付系统中，重复提交同一笔支付请求应只扣款一次。幂等性设计是保障系统可靠性的核心机制，尤其在网络超时、服务重试、消息重复等场景下，能避免数据不一致或资源重复消耗问题。

为什么需要幂等性

1. 网络不可靠性：客户端可能因超时重发请求，导致服务端多次接收相同操作。
2. 服务重试机制：中间件（如消息队列）或负载均衡器可能自动重试失败请求。
3. 用户行为：用户可能多次点击提交按钮。
   若无幂等性设计，重复操作可能引发资金损失、订单重复或状态混乱。

幂等性实现方案

步骤1：识别幂等操作类型

• 天然幂等操作：查询、删除（多次删除结果一致）、部分更新（如set status=paid）。
• 非幂等操作：创建、累加（如balance=balance+100）、状态转移（如unpaid→paid）。
  设计时需重点处理非幂等操作。

步骤2：幂等性核心实现机制
机制1：唯一标识符（ID）去重

• 为每个客户端请求分配唯一ID（如UUID、业务ID+序列号）。
• 服务端存储已处理ID，重复ID直接返回原有结果。
• 示例：
  • 支付请求携带order_id，服务端检查order_id是否已处理：

    -- 数据库去重表  
    INSERT INTO idempotency_keys (request_id, result) VALUES ('req_123', 'success')  
    ON DUPLICATE KEY SELECT result; -- 存在则直接返回结果  
    

• 注意点：
  • 存储需设置过期时间，避免长期累积。
  • 高并发下需用数据库唯一索引或分布式锁防并发冲突。

机制2：状态机与乐观锁

• 将业务状态设计为状态机（如待支付→已支付），确保状态转移仅发生一次。
• 通过乐观锁（如版本号）阻止重复更新：

  UPDATE orders SET status='paid', version=version+1  
  WHERE order_id='123' AND version=10; -- 仅当版本匹配时更新  
  

• 若更新影响行数为0，说明请求已被处理，直接返回成功。

机制3：令牌机制（Token）

• 客户端先申请临时令牌，服务端缓存令牌状态（未使用/已使用）。
• 操作时携带令牌，服务端校验后标记为已使用。
• 适用场景：防止表单重复提交。

步骤3：分层幂等性设计

1. 协议层：HTTP协议中，GET、PUT、DELETE是幂等的，POST非幂等。可改用PUT替代POST进行创建（如指定资源ID）。
2. 业务层：
   • 将非幂等操作转化为幂等操作，例如用“设置绝对值”替代“累加”（如set balance=200而非balance+=100）。
   • 通过日志或事件溯源重建状态，确保重复事件应用后结果不变。
3. 数据层：利用数据库唯一约束或幂等写入接口（如Redis的SET key value NX）。

步骤4：边界情况处理

• 并发请求：多个相同请求同时到达时，需加分布式锁或依赖数据库唯一约束。
• 部分失败：若保存幂等标识后业务处理失败，需结合事务或补偿机制（如删除标识）。
• 存储选择：
  • 高频场景用Redis存储请求ID（高效过期）；
  • 关键业务用数据库保证持久化。

总结
幂等性设计需结合业务场景选择方案，核心是唯一标识符+状态校验。通过去重表、状态机、乐观锁等机制，可有效应对分布式系统中的重复请求问题，提升系统容错性。