幂等性：保障系统稳定的关键设计

幂等性（Idempotence） 是计算机科学和分布式系统中的核心概念，指同一操作重复执行多次所产生的效果与执行一次的效果相同。这一特性对系统容错性、数据一致性至关重要，尤其在网络通信（如HTTP）和数据库设计中广泛应用。

一、核心定义

• 数学起源：源自拉丁语 idem（相同）+ potent（能力），数学中定义为 f(f(x)) = f(x)（如 abs(abs(-5)) = abs(-5)）。
• 工程实践：在分布式系统中，无论请求被重复发送一次还是多次，只要参数相同，最终的系统状态都保持一致。

二、关键场景解析

1. HTTP方法的幂等性

注：幂等性仅关注资源状态结果，不关注响应内容（如DELETE返回200或404均不影响幂等性）。

2. 数据库操作

• 幂等操作：

  UPDATE users SET balance = 100 WHERE id = 1;  -- 无论执行多少次，余额最终均为100
  

• 非幂等操作：

  UPDATE users SET balance = balance - 10 WHERE id = 1;  -- 重复执行导致余额持续减少
  

三、为什么需要幂等性？

1. 网络不可靠场景：
   • 客户端超时重试（如支付接口重复提交）
   • 消息队列重复投递（RabbitMQ/Kafka等中间件可能重复发送）
2. 分布式事务：
   • 服务调用失败后重试需确保数据不被破坏（如库存扣减）

四、实现幂等性的常见方案

1. Token 机制（防重令牌）

特点：适用于前端表单防重复提交（如订单创建）。

2. 唯一标识（IDEMPOTENCY-KEY）

客户端生成唯一请求ID（如UUID），服务端校验：

def handle_request(request_id, data):
    if redis.exists(request_id):  # 已处理过相同ID的请求
        return cached_response   # 返回之前的结果
    else:
        process(data)            # 执行业务逻辑
        redis.set(request_id, result) # 存储结果

适用场景：API设计（如Stripe支付API要求客户端传Idempotency-Key头）。

3. 乐观锁（数据库层面）

UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE id = 100 AND version = 5; -- 基于版本号控制

作用：防止并发场景下库存超扣。

4. 状态机约束

限定操作允许的状态流转（如订单状态仅允许待支付→已支付）：

if (order.getStatus() != PENDING_PAYMENT) {
    throw new IllegalStateException("订单无法重复支付");
}

五、幂等性与并发安全的区别

幂等性可降低并发冲突概率，但不能替代并发控制（如秒杀场景需同时使用幂等+分布式锁）。

六、实际应用建议

1. 读操作：天然幂等（GET/HEAD），无需额外处理。
2. 写操作：
   • 更新资源（PUT）应通过全量替换实现幂等。
   • 创建资源（POST）需借助Token/唯一ID。
3. 删除操作（DELETE）：设计为幂等（删除不存在的资源返回200/404均可）。
4. 接口设计：公开API必须声明幂等性（如RESTful规范），避免客户端重试引发数据错误。

总结：幂等性是保障分布式系统可靠性的基石，在重试、异步消息、微服务调用等场景中不可或缺。设计时应根据业务需求选择Token、唯一ID或乐观锁等方案，从源头规避数据不一致风险。