接口的幂等性

接口的幂等性

1. 接口调用存在的问题
   现如今我们的系统大多拆分为分布式SOA，或者微服务，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者restful，既然是通信，那么就有可能在服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，那么处理数据的结果是否要统一呢？那是肯定的！尤其在支付场景。

2. 什么是接口幂等性
   接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

3. 什么情况下需要保证接口的幂等性

   在增删改查4个操作中，尤为注意就是增加或者修改，

A: 查询操作

查询对于结果是不会有改变的，查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作

B: 删除操作

删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个,在不考虑返回结果的情况下,删除操作也是具有幂等性的)

C: 更新操作

修改在大多场景下结果一样,单纯的赋值基本没问题，对于一些金额的累计修改可能会造成问题

D: 新增操作

增加在重复提交的场景下会出现幂等性问题,如以上的支付问题

4. 那么如何设计接口才能做到幂等呢？

   常见的两种实现方案: 1. 通过代码逻辑判断实现 2. 使用token机制实现 下面以支付系统为例,分别对接口的幂等性进行说明与实现

   A: 通过代码逻辑判断实现接口幂等性,只能针对一些满足判断的逻辑实现,具有一定局限性
   如果支付系统已经扣款，但是订单系统因为网络原因，没有获取到确切的结果，因此订单系统需要重试，可能会重复付款
   新增逻辑：
   通过orderId来标定订单的唯一性，付款系统只要检测到订单已经支付过，则第二次调用不会扣款而会直接返回结果：

B: 使用token机制实现接口幂等性,通用性强的实现方法

token机制实现步骤:
1. 生成全局唯一的token,token放到redis，发送请求提交先获取token
2. 提交后后台校验token，执行提交逻辑,提交成功同时删除token，生成新的token更新redis ,这样当第一次提交后token更新了,页面再次提交携带的token是已删除的token后台验证会失败不让提交

token特点： 要申请，一次有效性，可以限流

希望对你们有所帮助。