为什么网络请求总是充满不确定性
在分布式系统架构中，客户端与服务器之间的通讯永远无法保证绝对的稳定。当用户点击“付款”按钮时，如果网络发生微小的延迟或中断，客户端往往无法确认请求是否已被服务器成功接收并处理。这时，自动重试机制（Retry）成为了开发者的首选防御策略，但它却同时埋下了“重复执行”的巨大隐忧。
若一个支付请求在服务器端已经处理完成，但回传确认信息的过程中网络断线，客户端因为收不到响应而发起第二次请求，系统若缺乏防御机制，极易导致重复扣款或数据不一致。这种“即使请求执行多次，系统最终状态依然与执行一次相同”的特性，在软件工程中被称为“幂等性（Idempotency）”。
幂等性的底层运作机制
幂等性的核心在于服务器如何识别“同一个请求”。在 HTTP 协议中，GET、PUT 与 DELETE 方法理论上具备天然的幂等性，因为无论查询多少次，资源状态都不应改变；然而，POST 请求则不具备此特性。为了在 POST 请求中实现幂等，我们必须引入“幂等识别码（Idempotency Key）”。
识别码的生成逻辑
识别码通常由客户端在发起请求时生成，这是一个唯一的 UUID 或业务序号。服务器接收到请求后，会先检测该识别码是否存在于缓存（如 Redis）中。若已存在，则直接回传之前存储的处理结果，而不再进行第二次业务逻辑运算。这种机制将“执行”与“查询”分离，确保了交易的安全性。
常见 HTTP 方法的幂等性差异判断
并非所有 API 都需要严格的幂等性设计，开发者应根据业务场景进行评估。以下表格列出了不同 HTTP 方法在幂等性上的表现与适用情境：
| 方法 | 幂等性 | 适用情境 |
|---|---|---|
| GET | 是 | 数据查询、获取资源 |
| PUT | 是 | 资源完全更新或覆盖 |
| DELETE | 是 | 删除特定资源 |
| POST | 否 | 创建新资源、支付交易 |
| PATCH | 否 | 资源的部分更新 |
实现策略：从请求拦截到状态缓存
在正式进入程序开发前，建议建立一套标准的拦截器流程。首先，API Gateway 或 Middleware 层必须能够解析请求标头中的 Idempotency-Key 字段。如果该字段缺失，对于非幂等方法，系统应采取拒绝受理并返回 400 Bad Request 的策略，以防止意外的重复操作。
实现步骤检查清单
- 定义 Idempotency-Key 请求标头格式。
- 在服务器端建立针对 Key 的锁定机制（Distributed Lock）。
- 检查 Redis 是否存在该 Key 的处理状态。
- 若状态为“处理中”，拒绝新请求或等待锁定释放。
- 若状态为“已完成”，直接回传快取结果。
- 若无记录，执行业务逻辑，并存储执行结果与状态。
处理常见的开发误区
许多开发者误以为“只要检查数据库是否重复”就是幂等性，这其实是极大的误区。数据库查询往往伴随高昂的 I/O 成本，在并发量高的场景下，依赖数据库作为幂等判断的唯一依据，会导致严重的性能瓶颈。正确的做法是使用高效的内存数据库（如 Redis）作为第一道防线。
另一个常见错误是将“幂等性”与“事务（Transaction）”混为一谈。事务确保了操作的原子性，而幂等性则确保了操作的重复安全性。两者在分布式系统中应该是互补的关系，而非相互取代。若只做事务处理而忽略幂等，系统在处理网络抖动时仍会暴露于重复交易的风险之下。
例外情境与状态一致性维护
在某些极端情况下，例如服务器在执行业务逻辑过程中崩溃，导致状态记录尚未写入 Redis，这时该如何处理？这涉及到了“重试策略”的设计。我们建议采用“先占位、后更新”的策略：在执行业务前，先将 Key 写入并标记为 `PENDING`。即使后续崩溃，客户端再次重试时，服务器能识别到该任务正在处理中，从而避免资源冲突。
下一步的系统弹性思考
当 API 具备了完善的幂等性，系统的韧性将大幅提升。开发者应开始关注“幂等失败”的错误处理：例如当服务器回传 409 Conflict 告知该 Key 正在处理中时，客户端应如何实现指数退避（Exponential Backoff）算法，以避免在系统负载过高时发起过多的重试请求。这不仅是技术实现的细节，更是构建现代化稳定 API 的核心素养。