在系统对接过程中，当出现接口调用异常的情况时，程序员可能会用一些专业术语来答疑......对于0基础同学，自然是需要自行百度一番，学习一下！ 

接下来，先学习【幂等】

PS： 小白参考1.1~1.4内容即可，达到基本理解。

1.1 幂等是什么

简单讲，就是同一个操作，不管执行多少次（1次或者N次），最终产生的效果都和只执行1次的效果一样。

即 “做一次”和“做N次”的效果是等价的。

1.2 幂等的重要性

在网络世界，特别涉及到订单、支付、重要状态变更时，因为未知因素“不小心重复执行”是非常非常常见的事情。如：

• 做了触发按钮，不小心点击了多次；
• 网络信号不好，请求发送了2次
• 系统在处理时 卡顿崩溃了，恢复后重新处理了一次等等

如果没有幂等处理，那这些重复操作会导致各种后果：重复扣钱；重复创建订单（只要1个，但是生成了多个）；状态错乱（已发货变成待发货）等

1.3 如何实现幂等 

通过具体的场景示例

1.扣款接口（需要幂等性）——钱不能多扣！

• 操作： 你用手机支付买一杯奶茶，点击“确认支付”按钮。

• 幂等要求： 无论这个“确认支付”的指令因为网络卡顿、手抖等原因被系统收到了1次还是100次，你的账户应该只被扣一次奶茶的钱（比如20元），奶茶店也只收到一次20元。

• 非幂等的可怕后果： 如果接口不幂等，系统收到两次“确认支付”指令，就可能扣你40元！奶茶店也可能收到40元或者系统混乱。这绝对不行！

如何实现？

系统设计扣款接口时，需要有个机制 可识别到 “这是同一个订单/交易”

• 给每个支付请求一个唯一“订单号” (ID)：就像快递单号。

• 系统记录处理过的订单号：系统收到支付请求，先查这个订单号是否处理过。

  • 如果没处理过：执行扣款、记录状态（已支付）、记下这个订单号。

  • 如果已经处理过：直接返回上次支付成功的结果（比如“支付成功，已扣款20元”），不再执行实际扣款操作！

• 结果： 用户点了N次，只要订单号一样，系统只扣一次钱，每次都告诉你支付成功（效果等同于只执行一次）。

场景二：查询余额接口 (天生幂等) - 查多少次都行！

• • 操作： 你打开手机银行APP，点击“查询余额”。

  • 幂等体现： 你点1次，显示余额是1000元。你手快点错了，连续狂点10次“查询余额”，每次返回的结果都还是显示1000元（假设期间没有其他交易）。查询这个操作本身不会改变你的余额。做一次和做十次，结果都一样（余额显示1000元），没有额外副作用。

  • 为什么天生幂等？ 因为这个操作只是“读”数据，不“写”（修改）数据。读操作通常不会改变系统状态。

1.4 幂等性的关键点

1. 核心目标：防止重复操作带来坏影响，尤其是在会修改数据的操作上。（扣钱、下单、改状态）
2. 核心表现：同一个请求（通常有唯一标识/主键 来识别，eg：订单号、流水号等），执行多次==执行1次的效果。
3. 允许重复调用：但重复调用时，系统能识别出来并确保最终结果正确（要么和第一次结果一致要么不作任何修改）
4. 重要性：这个是系统稳定的基准之一。不然系统数据会一团糟。
5. 常见需要幂等的操作： 支付、创建订单、更新状态（如确认收货）、退款等
6. 常见天生幂等的操作：查询、获取信息

1.5 术语版解答

接口幂等性 (Idempotency) 是指：

一个操作（通常由 HTTP 方法表示）被设计成：当客户端向服务器发送一次或多次具有相同参数的相同请求时，服务器端的最终状态改变（或产生的副作用）是相同的，并且通常返回相同的响应结果。

关键点解析：

1. 操作 (Operation)： 指通过 API 接口执行的特定动作，如创建资源、更新资源、删除资源、支付等。

2. 多次相同请求 (Identical Requests)： 请求的语义（意图）和关键参数（通常包括一个唯一的幂等键 Idempotency-Key）必须完全相同。这些请求可能因网络问题、客户端重试、超时重发等原因而产生。

3. 最终状态/副作用 (State/Side Effects)： 指操作在服务器端数据库、文件系统或其他持久化存储中引起的实际变化，以及可能触发的后续流程（如发送通知、扣款等）。

4. 效果相同 (Same Effect)：

   • 对于修改状态的操作（PUT, DELETE, 特定 POST）：执行一次和多次，服务器资源最终达到的状态是完全一致的。

   • 对于不修改状态的操作（GET, HEAD）：多次执行总是返回相同的结果（假设资源在此期间未被其他操作修改）。

5. 响应结果 (Response)： 在多次执行中，服务器通常应返回相同的 HTTP 状态码和响应体（尤其是成功响应）。第一次执行成功后，后续重复请求应返回成功（如 200 OK 或 201 Created）并可能包含首次执行的结果，而不是报错（除非请求本身无效）。

实现幂等性的典型技术方案：

1. 幂等键 (Idempotency Key)：

   • 客户端在发送非幂等操作（如创建订单的 POST）时，在请求头（如 Idempotency-Key: <unique_value>）或请求体中提供一个全局唯一的标识符（UUID 是最佳选择）。

   • 服务端存储该 Key 与首次请求的响应结果。

   • 当收到相同 Key 的请求时：

     • 若 Key 存在且对应请求已完成：直接返回存储的响应结果，不执行实际操作。

     • 若 Key 存在但对应请求仍在处理中：返回 409 Conflict 或 425 Too Early，提示客户端稍后重试。

     • 若 Key 不存在：正常处理请求，处理完成后存储 Key 和响应结果。

2. 唯一业务标识 (Unique Business Identifier)：

   • 利用业务本身的唯一标识（如订单号、交易流水号、用户名）作为幂等键。

   • 服务端在处理请求前，检查该唯一标识对应的资源是否已存在或操作是否已执行。

   • 若已存在/已执行：返回已有资源或成功响应（实现幂等）。

   • 若不存在/未执行：执行操作并创建资源/记录状态。

3. 状态机与乐观锁 (State Machine & Optimistic Locking)：

   • 定义资源明确的状态（如 待支付 -> 已支付 -> 已完成）。

   • 更新操作（如 支付）需要指定期望的当前状态（如 待支付）。

   • 服务端检查资源当前状态是否与期望状态一致：

     • 一致：执行状态转换（如 待支付 -> 已支付），操作成功。

     • 不一致（如状态已是 已支付）：说明操作已执行过，返回当前状态（实现幂等）。常配合版本号（ETag）或更新时间戳实现乐观锁。