设计公司网站需要什么条件,网站建设与管理课程代码,做网站域名起什么作用,如何做自己的小说网站在系统对接过程中#xff0c;当出现接口调用异常的情况时#xff0c;程序员可能会用一些专业术语来答疑......对于0基础同学#xff0c;自然是需要自行百度一番#xff0c;学习一下#xff01;
接下来#xff0c;先学习【幂等】
PS#xff1a; 小白参考1.1~1.4内容即…在系统对接过程中当出现接口调用异常的情况时程序员可能会用一些专业术语来答疑......对于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 幂等性的关键点
核心目标防止重复操作带来坏影响尤其是在会修改数据的操作上。扣钱、下单、改状态核心表现同一个请求通常有唯一标识/主键 来识别eg订单号、流水号等执行多次执行1次的效果。允许重复调用但重复调用时系统能识别出来并确保最终结果正确要么和第一次结果一致要么不作任何修改重要性这个是系统稳定的基准之一。不然系统数据会一团糟。常见需要幂等的操作 支付、创建订单、更新状态如确认收货、退款等常见天生幂等的操作查询、获取信息 1.5 术语版解答
接口幂等性 (Idempotency) 是指
一个操作通常由 HTTP 方法表示被设计成当客户端向服务器发送一次或多次具有相同参数的相同请求时服务器端的最终状态改变或产生的副作用是相同的并且通常返回相同的响应结果。 关键点解析 操作 (Operation) 指通过 API 接口执行的特定动作如创建资源、更新资源、删除资源、支付等。 多次相同请求 (Identical Requests) 请求的语义意图和关键参数通常包括一个唯一的幂等键 Idempotency-Key必须完全相同。这些请求可能因网络问题、客户端重试、超时重发等原因而产生。 最终状态/副作用 (State/Side Effects) 指操作在服务器端数据库、文件系统或其他持久化存储中引起的实际变化以及可能触发的后续流程如发送通知、扣款等。 效果相同 (Same Effect) 对于修改状态的操作PUT, DELETE, 特定 POST执行一次和多次服务器资源最终达到的状态是完全一致的。 对于不修改状态的操作GET, HEAD多次执行总是返回相同的结果假设资源在此期间未被其他操作修改。 响应结果 (Response) 在多次执行中服务器通常应返回相同的 HTTP 状态码和响应体尤其是成功响应。第一次执行成功后后续重复请求应返回成功如 200 OK 或 201 Created并可能包含首次执行的结果而不是报错除非请求本身无效。 实现幂等性的典型技术方案 幂等键 (Idempotency Key) 客户端在发送非幂等操作如创建订单的 POST时在请求头如 Idempotency-Key: unique_value或请求体中提供一个全局唯一的标识符UUID 是最佳选择。 服务端存储该 Key 与首次请求的响应结果。 当收到相同 Key 的请求时 若 Key 存在且对应请求已完成直接返回存储的响应结果不执行实际操作。 若 Key 存在但对应请求仍在处理中返回 409 Conflict 或 425 Too Early提示客户端稍后重试。 若 Key 不存在正常处理请求处理完成后存储 Key 和响应结果。 唯一业务标识 (Unique Business Identifier) 利用业务本身的唯一标识如订单号、交易流水号、用户名作为幂等键。 服务端在处理请求前检查该唯一标识对应的资源是否已存在或操作是否已执行。 若已存在/已执行返回已有资源或成功响应实现幂等。 若不存在/未执行执行操作并创建资源/记录状态。 状态机与乐观锁 (State Machine Optimistic Locking) 定义资源明确的状态如 待支付 - 已支付 - 已完成。 更新操作如 支付需要指定期望的当前状态如 待支付。 服务端检查资源当前状态是否与期望状态一致 一致执行状态转换如 待支付 - 已支付操作成功。 不一致如状态已是 已支付说明操作已执行过返回当前状态实现幂等。常配合版本号ETag或更新时间戳实现乐观锁。
