接口幂等性

什么是幂等

    数学角度

•  f(n) = 1^n 。无论n等于多少，f(n)永远值等于1

    编程角度

• 程序无论执行多少次，其产生的结果均与一次执行相同，不会因为重复执行会对系统造成改变

为什么要做幂等

      之所以强调幂等，原因在于接口不幂等时，在某些场景下会引发严重的问题：支付、退款、结算等场景时，由于重复点击/操作后，进行了二次处理，导致重复扣款，重复退款，错误结算问题。这时候凡事碰到此问题的用户恐怕心情瞬间崩溃了。  

常见的引起幂等问题的原因

         引发的原因都有一个共性：短时间内，重复操作。以下场景下可能会发生支付异常导致重复支付：

1. 网络延迟。请求到后端服务后，后端处理后返回结果的时候网络抖动/延迟。这时前端超时等待结束后再发起请求会导致重复操作行为。
2. 服务异常。后端因各种异常原因导致服务处理缓慢，前端提示超时后再次发起请求，这时两次请求同时受理会导致重复问题。
3. 第三方服务异常情况。比如支付场景下，支付时，支付回调超时导致DB没有变，当用户再次发起支付时导致重复支付问题了。
4. 其他。所依赖服务不稳定(比如第三方支付接口)、服务超时，这时前端如果再次发起支付请求时会导致重复支付。

业内幂等实现方案

一、哪些用户行为需要特别保证幂等特性

       从用户行为来看，操作无外乎增删改查。

1. 查询操作具有天然的幂等特性：在数据不变的情况下，查询一次和查询多次，结果都是一样的
2. 删除/修改/新增操作需要保证：删除/修改/新增一次和多次删除/修改/新增，除了产生正常的影响外，不应该产生额外的不必要影响

二、实现方案思路

        选择方案的原则：任何实现方案根据复杂性都有不同程度的复杂性，因而不是方案越可靠越好，还需要考虑业务需要、实现成本等因素。毕竟适合的才是最好的。

        具体的实现方案可以考虑：

 限制前端重复提交

比如，一个按钮，点击一次后，后端接口返回前不允许按钮点击第二次(如置灰)；不过这种方案虽然简单，但存在一定的风险，如置灰按钮前再次点击，或直接调用接口。

 token机制

（1）前端提交数据前，先和后端服务申请一个token

（2）提交数据时连同token一起提交

（3）下次提交新数据时重复（1）（2）步骤

实现token要求：唯一性，不重复，并重点实现token的产生、存储机制。

唯一索引，防止新增脏数据

当表存在唯一索引，并发时新增报错时，再查询一次如果数据存在旧不用新增了。

悲观锁

获取数据的时候加锁获取

select * from table_xxx where id='xxx' for update;

注意：id字段一定是主键或者唯一索引，不然是锁表。

悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用。

其他方法

分布式锁、或其他逻辑层限制方案：https://blog.csdn.net/qq_16605855/article/details/80192762

接口幂等测试

     了解了什么是幂等后，如何测试就一目了然了：短时间内重复执行来模拟多次调用，检查各种信息是否正常。好了，接口幂等保证后，团队成员就可以睡个安稳觉了。