实际开发中在接口设计的时候对于接口的幂等性问题一定要进行考虑的，现对这部分内容做一个梳理
什么是幂等性
英文单词：Idempotence，来源于数学，表达的是N次变换与一次变换的结果相同，简单来说就是一个接口多次调用没有副作用，它就具有幂等性
产生幂等性的场景
❇️如网络波动引起重复请求
❇️如用户误操作导致的重复操作
❇️应用使用了失败或超时的重试机制(如Nginx重试、RPC重试等)
❇️第三方平台的接口(如支付成功回调接口)，因为异常导致多次异步回调
❇️用户双击提交按钮
❇️页面重复刷新
❇️使用浏览器后退按钮重复之前的操作，导致重复提交表单
❇️浏览器重复的http请求
❇️定时任务重复执行
幂等性应该在哪一层实现
我们现在都是分布式、微服务架构，在哪一层进行幂等设计，在哪一层解决幂等性问题呢？
🚩在数据访问层实现是比较合适的
读请求(查询，不做幂等)
写请求(增删改)
insert操作:这种情况下多次请求，可能会产生重复数据(如有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样)
update操作:如果只是单纯的更新数据，比如：update user set status=1 where id=1，是没有问题的。如果还有计算，比如：update user set status=status+1 where id=1，这种情况下多次请求，可能会导致数据错误
如何保证接口幂等性
📌前端实现(不可靠)
- 提交后把按钮置为灰色或loading状态，这种情况不可靠，因为用户可以通过工具绕过js来访问 接口
- token机制(防止重复提交)：提交时提交时带上token，后台判断如果这个token是后台生成的则让提交，如果不是就不让提交，相当于是一个重复的请求
📌后端实现
唯一索引去重，Token+Redis，乐观锁，分布式锁，全局唯一号等
这个部分需要展开学习说明
问题
常用的http请求它的幂等性是怎样的
- Get请求是幂等性，
它不会对数据产生副作用 - delete请求用于删除资源，有副作用，但它应该满足幂等性(定位在某个资源)
- post请求，不具备幂等性
- put方法用于更新资源
评论区