接口幂等性
什么是幂等
数学角度
f(n) = 1^n 。无论n等于多少，f(n)永远值等于1
编程角度
程序无论执行多少次，其产生的结果均与一次执行相同，不会因为重复执行会对系统造成改变
为什么要做幂等
之所以强调幂等，原因在于接口不幂等时，在某些场景下会引发严重的问题：支付、退款、结算等场景时，由于重复点击/操作后，进行了二次处理，导致重复扣款，重复退款，错误结算问题。这时候凡事碰到此问题的用户恐怕心情瞬间崩溃了。
常见的引起幂等问题的原因
引发的原因都有一个共性：短时间内，重复操作。以下场景下可能会发生支付异常导致重复支付：
- 网络延迟。请求到后端服务后，后端处理后返回结果的时候网络抖动/延迟。这时前端超时等待结束后再发起请求会导致重复操作行为。
- 服务异常。后端因各种异常原因导致服务处理缓慢，前端提示超时后再次发起请求，这时两次请求同时受理会导致重复问题。
- 第三方服务异常情况。比如支付场景下，支付时，支付回调超时导致DB没有变，当用户再次发起支付时导致重复支付问题了。
- 其他。所依赖服务不稳定(比如第三方支付接口)、服务超时，这时前端如果再次发起支付请求时会导致重复支付。
业内幂等实现方案
一、哪些用户行为需要特别保证幂等特性
从用户行为来看，操作无外乎增删改查。
- 查询操作具有天然的幂等特性：在数据不变的情况下，查询一次和查询多次，结果都是一样的
- 删除/修改/新增操作需要保证：删除/修改/新增一次和多次删除/修改/新增，除了产生正常的影响外，不应该产生额外的不必要影响
二、实现方案思路
选择方案的原则：任何实现方案根据复杂性都有不同程度的复杂性，因而不是方案越可靠越好，还需要考虑业务需要、实现成本等因素。毕竟适合的才是最好的。具体的实现方案可以考虑：
限制前端重复提交
比如，一个按钮，点击一次后，后端接口返回前不允许按钮点击第二次(如置灰)；不过这种方案虽然简单，但存在一定的风险，如置灰按钮前再次点击，或直接调用接口。
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
接口幂等测试
了解了什么是幂等后，如何测试就一目了然了：短时间内重复执行来模拟多次调用，检查各种信息是否正常。好了，接口幂等保证后，团队成员就可以睡个安稳觉了。
偏执的太偏执、
深藏阁楼爱情的钟![[ansible]-ansible-playbook执行端口健康检查](https://image.dandelioncloud.cn/images/20221120/96d30ae461ed48a58ee018395aba0a40.png "[ansible]-ansible-playbook执行端口健康检查")
还没有评论，来说两句吧...