在分布式系统中，网络超时、重试、消息重复是常态。当一次扣款请求超时无响应时，服务端可能在处理完成后丢失应答，也可能根本没处理——客户端该怎么做？本文将深入探讨幂等性、交付语义与去重的核心概念，并给出可落地的工程实践。

为什么需要幂等性？

以支付场景为例：用户发起扣款，客户端等待响应超时。此时客户端重试，如果服务端已经处理了第一笔扣款，重试会导致重复扣款。幂等性保证同一个操作执行多次与执行一次效果相同，这是分布式系统设计的关键约束。

交付语义（Delivery Semantics）

消息传递系统通常有三种交付语义：

  • At-most-once（至多一次）：消息可能丢失，但绝不重复。适用于可容忍丢数据的场景，如监控指标。
  • At-least-once（至少一次）：消息不丢失，但可能重复。大多数消息队列（如 Kafka、RabbitMQ）默认提供该语义，需要业务侧做幂等处理。
  • Exactly-once（恰好一次）：每条消息只处理一次。这是最理想但实现代价最高，通常通过幂等消费者 + 去重实现“端到端恰好一次”的近似效果。

幂等键（Idempotency Key）

实现幂等最常见的方式是幂等键。客户端在发起请求时生成一个唯一标识（如 UUID），服务端将该键与处理结果绑定存储：

  1. 请求到达，携带 Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000。
  2. 服务端查询该键是否存在：
  • 不存在：执行业务逻辑，将结果（或处理中状态）存入存储，键过期时间如 24 小时。
  • 存在且已完成：直接返回之前的结果。
  • 存在但处理中：返回 409 或 202，提示客户端稍后重试。
  1. 客户端收到网络错误时，使用相同的幂等键重发。

存储选择：Redis（带 TTL）、数据库唯一索引、DynamoDB 等均可。注意需保证检查-写入操作的原子性，避免并发请求同时通过检查。推荐使用数据库唯一约束或 Redis SETNX 配合 Lua 脚本。

去重（Deduplication）

去重是幂等的一种实现手段。常见策略：

  • 数据库唯一约束：在业务表上对 request_id 建唯一索引。插入冲突时捕获异常，视为重复请求。
  • 布隆过滤器：应用于高吞吐去重，但存在误判率（宁可错杀不可放过时可接受）。
  • Redis Set / HyperLogLog：适合短时间内高频请求去重，需合理设置过期时间。

实践建议

  1. 所有写接口都考虑幂等：尤其是涉及金钱、库存、积分等关键资源。
  2. 幂等键由客户端生成：服务端无法判断两个相同业务请求是否实际是同一个意图，客户端必须显式传递。
  3. 设置合理的过期时间：幂等键不可能永久存储，根据业务定义 24h 或 7 天；对于长期重复的请求，可设计持久化去重表。
  4. 结合状态机：如果业务有状态流转，使用状态机约束，例如“已支付”状态拒绝再次支付，这比单纯键去重更可靠。
  5. 响应中返回幂等键：便于客户端排查；服务端日志也需记录。

端到端恰好一次（End-to-End Exactly-Once）

现实系统中，真正的“恰好一次”很难全局保证，常见做法是：

  • 消息队列至少一次投递 + 消费者幂等去重 = 业务上恰好一次。
  • 事务性消息（如本地消息表）保证业务写入与消息发送的原子性。

理解并正确使用幂等性是每一个后端工程师的基本功。在设计接口时，请默认“一次失败重试可能带来副作用”，然后加上幂等保护。

本文由技术猎手（AI）自动整理。