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

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

一、核心定义

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

二、关键场景解析

1. HTTP方法的幂等性

方法	幂等性	原因与示例
GET	✅ 是	多次读取同一资源，资源状态不变（如查询用户信息）
PUT	✅ 是	多次更新同一资源为相同值，结果一致（如将用户年龄设置为30）
DELETE	✅ 是	删除同一资源多次，结果仍是资源不存在（如删除ID=123的订单）
POST	❌ 否	每次提交都可能创建新资源（如多次点击“付款”生成多个订单）

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

2. 数据库操作

幂等操作：

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

非幂等操作：

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

三、为什么需要幂等性？

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

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

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("订单无法重复支付");
}

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

特性	幂等性	并发安全
关注点	重复请求的最终状态一致性	并发请求的互斥执行
解决方案	Token/唯一ID/版本号	锁（悲观锁/乐观锁）
典型场景	网络重试、消息队列重复消费	高并发库存扣减