第55篇 怎样保证接口的幂等性题目

1.接口幂等性定义

接口幂等性这一概念源于数学，原意是指一个操作假如连续实行多次所产生的效果与仅实行一次的效果相同，那么我们就称这个操作是幂等的。在互联网领域，特别是在Web服务、API设计和分布式体系中，接口幂等性具有非常重要的意义。
具体到HTTP接口或者服务间的API调用，接口幂等性就可以明白为当客户端对同一接口发起多次相同的哀求时，服务端体系也应该确保只实行一次相应的操作，而且不论接收到了多少次哀求，体系的状态变动始终是一致的，不会由于重复的哀求而导致数据的错误。
比如我们经常遇到的订单创建，付出等业务。
假如一个“创建订单”接口实现了幂等性，当收到两次同样的创建哀求时，体系应该要么拒绝第二个哀求（由于它已经是重复哀求），要么确保只有一个订单被创建，而不是两个完全一样的订单。
对于一个“付出”接口，幂等性要求即便用户由于网络原因反复点击付出按钮，服务端也只会扣除用户账户一次金额，避免重复扣费。
2.导致接口幂等性题目的原因

• 网络波动不稳定：
  网络通讯中的丢包、延迟等情况大概导致客户端未收到服务端的响应或服务端未收到客户端的哀求，此时客户端大概会重试发送哀求，导致接口被重复调用。
  
• 用户操作：
  用户快速重复点击导致，例如用户在等待响应时，由于不确定是否操作乐成，大概会多次点击提交按钮，进而发送多次相同的哀求。再比如页用户频仍刷新页面，尤其是在某些提交操作尚未完成时，刷新页面大概会重新发送哀求。还有效户大概在浏览器上点击回退然后再重复之间的提交操作，这都大概会导致重新发送哀求。
  
• 重试机制：
  在高可用性设计中，客户端经常设置有重试机制，当哀求失败或超时时会主动重新发起哀求。而在分布式体系中，服务间调用也大概有重试策略，以应对暂时故障。比如Nginx重试，RPC重试，或者调用方业务层中进行重试。
  
• 定时使命或异步处理：
  在定时使命中假如定时使命调度或逻辑设计不当，大概会导致同一使命被实行多次。或者在消息队列中，消息大概会由于非常等原因被重复消费。
  
• 并发控制：
  缺乏有效的并发控制手段，导致在并发环境下，针对同一资源的操作被多次实行。
  

3.怎样保证接口幂等？

3.1 前端调用

3.1.1 页面控制

• 页面调用接口时可以通过禁用（如按钮置灰或显示加载状态）防止用户在哀求未完成前重复点击，从而减少不须要的重复哀求和大概的数据冲突。固然在前端进行按钮置灰等操作可以辅助进步体系的幂等性体现，但是这个方式只是从用户体验和用户行为控制的角度来避免重复提交的一种方法，并没有从体系设计层面完全解决接口本身的幂等性题目。
  

3.1.2 使用RPG模式

• PRG（POST/Redirect/GET）模式是一种前端交互策略，旨在解决用户刷新页面时大概导致表单数据重复提交的题目。它奇妙地利用了HTTP协议的特性，具体的交互流程如下：
  用户在网页表单中填写数据，并通过POST哀求将其发送至服务器进行处理，例如创建新资源或更新现有数据。
  服务器接收到POST哀求后，对提交的数据进行有效处理和持久化存储，并在操作乐成后不直接返回处理效果，而是通过HTTP响应码302或303实现重定向，指示客户端发起一个新的GET哀求去访问一个特定的URL。
  客户端依照服务器的重定向指示，主动发送GET哀求访问新的URL，此时返回的页面将展示之前POST操作处理完毕的效果。
  当用户在此后刷新页面时，浏览器只会按照常规方式重新发起GET哀求，而非重新提交POST数据，因此有效地避免了重复提交引发的潜在题目
  

3.1.3Token机制

• Token机制是一种广泛应用互联网领域的认证与授权方法，特别是Web服务体系。token可以明白为一种安全凭证，它是由服务端生成并颁发给客户端的一段经过加密处理的字符串或数据结构，用来代表用户的某种状态或权限。
  
• 通过Token机制，我们可以解决接口幂等性题目。在接口中，我们允许重复提交，但是要保证重复提交不产生副作用，比如点击n次只产生一条记载，客户端每次哀求都必要携带一个唯一的Token，而服务器则验证这个Token的有效性。假如服务器收到了一个已经使用过的Token就会认为这是一个重复哀求并拒绝处理，从而确保接口的幂等性具体流握如下Token机制是一种常用的方法，用于确保接口的幂等性和防止重复哀求。具体流程如下：
  
• 生成Token
  当用户开始实行一个必要确保幂等性的操作（如付出、下单、更新用户信息等）时，服务端会生成一个唯一的、有时效性的token。这个token可以是一个随机字符串或者带有时间戳和其他相关信息的哈希值，确保其唯一性。
  
• 存储Token
  生成的token会被存储在服务端的一个暂时存储介质中，如Redis、Memcached或数据库，同时设置一个公道的逾期时间（例如15分钟）。
  
• 传递Token
  将生成的token返回给客户端，客户端在进行后续的API调用时，需将此token作为哀求参数或放在哀求头中一并发送给服务端。
  
• 验证Token
  服务端在接收到带有token的哀求时，首先检查token是否存在而且有效（未逾期且未被使用过）。假如token有效且未被使用，则实行相应的业务逻辑，并在实行完成后立即从存储介质中移除或标记为已使用。若token已失效或已被使用，则拒绝此次哀求，返回相应的错误提示，确保同一个操作不会被实行两次。
  
• 限制并发
  在并发场景下，通过原子操作（如Redis的SETNX下令）确保在验证token有效的同时，将其删除或更新状态，避免多个哀求同时通过验证。
  

3.2 服务端控制

在服务端接口处理逻辑时，可以通过通过一些特定的标识符或哀求参数来校验哀求的幂等性，以确保同样的哀求不会被重复处理。
3.2.1 唯一标识符

客户端每次发起哀求会携带一个全局唯一的标识符。服务器接收到哀求后就会对这个标识符进行检查，若服务器发现该标识符已经在体系中存在，表明这是一个重复哀求，此时服务器可以选择忽略该哀求，或者向客户端返回已处理过相同哀求的效果信息。若服务器未找到该标识符存在于体系内，则认定该哀求为新哀求，服务器将继续对其进行正常处理，并将此唯一标识符保存至体系中，以便于后续对接收的哀求进行有效性校验，防止同一哀求的重复处理。比如我们在要求上游ERP体系对接订单平台时就会要求上游传递一个账号下全局唯一的一个参考单号，这个参考单号一个很重要的作用就是保证接口幂等性。
3.2.2 哀求参数

某些哀求参数确实可以用来辅助校验哀求的幂等性。例如，时间戳可以作为一种大概的哀求参数，在处理哀求时，服务器可以通过比较时间戳与服务器当前时间来判断哀求的有效性。若时间戳与当前时间之间的差异超出预设的公道范围（如几秒钟到几分钟不等，具体阈值视业务场景而定），服务器可以推测该哀求大概是由于网络延迟或者其他原因导致的重复提交。
3.2.3 状态机设计

对于状态转移类的操作范例的业务，可采用状态机设计，每次哀求只允许合法的状态变迁，非法状态变迁（如已经完成的订单不允许再次付出）将被拒绝。
3.2.4 乐观锁

在更新数据时，可以通过版本号或时间戳等机制判断数据是否已被修改，防止因并发哀求导致的多次更新题目。具体做法：

• 在数据库表中增加一个版本号字段（version）或者时间戳字段（timestamp）。
  
• 客户端第一次哀求时获取数据的版本号或时间戳。
  
• 客户端发起更新操作时，将上次读取的版本号或时间戳一起发送回服务器。
  
• 服务器在实行更新操作前，首先检查当前数据库中的版本号或时间戳是否与客户端提交的一致。
  
• 假如一致，说明在这期间数据没有被其他事务修改过，于是更新数据并递增版本号或更新时间戳。
  
• 假如不一致，说明数据已经被修改过，此时服务器拒绝本次更新哀求，返回错误提示，客户端可以根据错误信息决定是否重新获取最新数据再尝试更新。
  通过这种方式，即使客户端由于网络原因或其他因素导致同一哀求被多次发送，乐观锁机制能确保只有在数据未被其他事务修改的前提下，才会实行更新操作，从而到达接口幂等的效果。
  

4 总结

幂等性是开发当中很常见也很重要的一个需求，尤其是订单，付出以及与款项挂钩的服务，保证接口幂等性尤其重要。在实际开发中，我们必要针对不同的业务场景我们必要机动的选择幂等性的实现方式：
假如是web服务，客户端可以采取在页面上使用按钮置灰禁用，使用PRG模式，或者搭配后端的Token令牌进行解决。
在服务端，我们可以采取唯一标识符，乐观锁，Token令牌，状态机等校验方式。
本漫笔借鉴或转载自：https://www.coderacademy.online/article/springbootidempotent.html

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。