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

题目描述

在分布式系统（尤其是微服务架构）中，网络延迟、故障和重试机制可能导致同一个操作被多次调用。幂等性设计是指一个操作无论被执行一次还是多次，其产生的结果都是一致的。例如，支付系统中重复的扣款请求应该只扣一次钱。面试中常要求理解幂等性的概念、常见场景，并设计具体的实现方案。

详细讲解

1. 为什么需要幂等性？

• 网络问题：客户端发送请求后未及时收到响应，可能触发重试。
• 超时重试：服务端处理超时，客户端或网关自动重发请求。
• 消息队列重复消费：如 Kafka 的至少一次投递语义可能导致消费者重复处理。
• 用户误操作：用户多次点击提交按钮。

例子：用户购买商品点击“支付”时网络卡顿，连续点了三次。如果没有幂等性，可能扣款三次。

2. 什么操作天然是幂等的？

• 查询操作（GET）：多次查询不影响数据状态。
• 删除操作（DELETE）：删除同一资源多次，结果仍是删除（第一次删除后资源已不存在，后续删除仍返回成功）。
• 部分更新操作（PUT）：用完整新数据替换资源，多次替换结果一致。

非幂等操作示例：

• 创建（POST）：多次调用可能创建多个资源。
• 部分更新（PATCH）：基于当前状态的更新（如 amount = amount - 10），多次执行会导致多次减扣。

3. 如何设计幂等性？

步骤1：识别需要幂等的操作

通常对写操作（如支付、下单、状态更新）需要保证幂等。

步骤2：生成唯一请求标识（Idempotency Key）

• 客户端在第一次请求时生成一个全局唯一的 idempotency_key（如 UUID），并在后续重试时携带同一个 key。
• 服务端根据该 key 判断请求是否已处理过。

步骤3：服务端存储处理状态

服务端需要存储 idempotency_key 对应的处理结果。常见方案：

方案A：基于数据库的唯一索引

1. 设计表 idempotency_record，包含字段：idempotency_key（唯一索引）、request_hash（请求内容哈希，可选）、response、status（如 processing/completed）、created_at。
2. 处理流程：
   • 收到请求后，尝试插入 idempotency_key。如果插入失败（唯一冲突），说明是重复请求。
   • 若插入成功，执行业务逻辑，完成后更新 status 和 response。
   • 若重复请求到达，直接返回已存储的 response。

方案B：基于 Redis 的原子操作

1. 使用 SET key value NX EX 过期时间 命令（NX 表示仅当 key 不存在时才设置）。
2. 处理流程：
   • 先执行 SET idempotency_key "processing" NX EX 60。若返回 nil，说明 key 已存在，是重复请求。
   • 若设置成功，执行业务逻辑，完成后将结果存入 Redis（如 SET idempotency_key "response_json" EX 3600）。
   • 重复请求到达时，从 Redis 中直接返回结果。

步骤4：处理中的请求去重

如果同一个 idempotency_key 的多个请求同时到达：

• 第一个请求获取锁并开始处理。
• 后续请求等待或直接返回“处理中”状态（可通过轮询或 WebSocket 通知最终结果）。

步骤5：请求内容一致性校验

• 相同 idempotency_key 可能被误用于不同请求（如用户两次不同订单用了相同 key）。
• 可在存储 idempotency_key 时同时存储请求内容的哈希值（如 SHA256），重复请求到达时校验哈希是否一致，不一致则返回错误。

4. 具体例子：支付接口幂等设计

请求参数：

{
  "order_id": "12345",
  "amount": 100.00,
  "idempotency_key": "550e8400-e29b-41d4-a716-446655440000"
}

服务端处理伪代码（使用 Redis）：

def handle_payment(request):
    key = f"idempotent:{request.idempotency_key}"
    
    # 1. 尝试原子性设置 key，标记处理中
    if not redis.set(key, "processing", ex=60, nx=True):
        # key 已存在，检查是处理中还是已完成
        cached = redis.get(key)
        if cached == "processing":
            return {"status": "retry_later", "message": "请求正在处理中"}
        else:
            return json.loads(cached)  # 直接返回之前的响应
    
    try:
        # 2. 执行业务逻辑（检查订单状态、扣款等）
        result = process_payment(request.order_id, request.amount)
        response = {"status": "success", "payment_id": result.id}
        
        # 3. 存储最终响应，设置较长过期时间（如 24 小时）
        redis.set(key, json.dumps(response), ex=86400)
        
        return response
    except Exception as e:
        # 失败时删除 key，允许重试
        redis.delete(key)
        raise e

5. 注意事项与优化

• 过期时间：根据业务设置合理过期时间，避免存储无限增长。
• 存储选择：高并发场景可用 Redis；需要持久化则用数据库。
• 分布式锁：如果业务处理非原子，可能需要分布式锁保证同一 key 同时只有一个请求在处理。
• 与业务事务结合：可将幂等记录与业务数据放在同一个数据库事务中，保证一致性。

6. 常见面试问题

• Q：幂等性和防重提交（Duplicate Submission）有什么区别？
  • 防重提交侧重于前端防止用户重复点击，如按钮置灰；幂等性是服务端保证多次请求结果一致。
• Q：如果请求中途失败，key 被锁定怎么办？
  • 设置合理的超时时间，超时后 key 自动释放，允许重试。
• Q：如何保证全局唯一 idempotency_key？
  • 客户端用 UUID；或由服务端提供一次性 token（如支付宝的支付 token）。

总结

幂等性设计是分布式系统容错的基本要求，核心是 唯一请求标识 + 状态存储。实现时需考虑并发控制、一致性、存储开销和清理策略。在实际系统中，通常结合消息队列的去重、数据库的唯一约束共同实现。