-
同一个接口，多次发出同一个请求，必须保证操作只执行一次
-
调用接口发生异常并且重复尝试时，总是会造成系统所无法承受的损失，所以必须阻止这种现象的发生。
-
比如支付接口，重复支付会导致多次扣钱；订单接口，同一个订单可能会多次创建
-
网络波动，可能会引起重复请求
-
用户重复操作，用户在操作时候可能会无意触发多次下单交易
-
使用了失效或超时重试机制
-
页面重复刷新
-
使用浏览器后退按钮重复之前的操作，导致重复提交表单
-
使用浏览器历史记录重复提交表单
-
浏览器重复的HTTP请求
-
定时任务重复执行
-
按钮只操作一次
一般是提交后把按钮置灰或loading状态，消除用户因为重复点击而产生的重复记录，比如添加操作，由于点击两次而产生两条记录
-
token机制
功能上允许重复提交，但要保证重复提交不产生副作用
比如点击n次只能产生一条记录，具体实现就是进入页面时申请一个token，然后后面所有的请求都带上这个token，后端根据token来避免重复请求
具体步骤：
-
用户访问页面时，浏览器自动发起获取token请求。
-
服务端生成token，保存到redis中，然后返回给浏览器。
-
用户通过浏览器发起请求时，携带该token。
-
在redis中查询该token是否存在，如果不存在，说明是第一次请求，做则后续的数据操作。
-
如果存在，说明是重复请求，则直接返回成功。
-
在redis中token会在过期时间之后，被自动删除。
-
-
使用Post/Redirect/Get模式
在提交后执行页面重定向
当用户提交连表单后，跳转到一个重定向的信息页面
避免用户按F5刷新导致的重复提交，而且也不会出现浏览器表单重复提交的警告，也能消除按浏览器前进和后退导致同样重复提交的问题。
-
在session存放特殊标志
在服务端生成一个唯一的标识符，将它存入session
同时前端获取这个标识符的值将它写入表单的隐藏中，用于用户输入信息后点击一起提交
在服务端，获取表单中隐藏字段的值，与session中的唯一标识符比较，相等说明时首次提交，就将处理本次请求，然后将session中的唯一标识符移除，不相等则表示是重复提交，不再做处理。
-
使用唯一索引放置新增脏数据
利用数据库唯一索引机制，当数据重复时，插入数据库会抛出异常，保证不会出现脏数据
-
具体步骤：
用户通过浏览器发起请求，服务端收集数据。
将该数据插入mysql
判断是否执行成功，如果成功，则操作其他数据（可能还有其他的业务逻辑）。
如果执行失败，捕获唯一索引冲突异常，直接返回成功。
-
乐观锁
如果更新已有数据，可以进行加锁更新，也可以设计表结构时使用乐观锁，通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。
具体步骤
-
先根据id查询用户信息，包含version字段
-
根据id和version字段值作为where条件的参数，更新用户信息，同时version+1
-
判断操作影响行数，如果影响1行，则说明是一次请求，可以做其他数据操作。
-
如果影响0行，说明是重复请求，则直接返回成功。
-
分布式锁
通过第三方系统（redis或zookeeper），在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁
3种实现redis的分布式锁
-
setNx命令
-
set命令
-
Redission框架
-
-
具体步骤：
用户通过浏览器发起请求，服务端会收集数据，并且生成订单号code作为唯一业务字段。
使用redis的set命令，将该订单code设置到redis中，同时设置超时时间。
判断是否设置成功，如果设置成功，说明是第一次请求，则进行数据操作。
如果设置失败，说明是重复请求，则直接返回成功。
-
状态机幂等
在设计单据相关业务，或者任务相关的业务，会涉及到状态机
业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。
具体步骤：
-
用户通过浏览器发起请求，服务端收集数据。
-
根据id和当前状态作为条件，更新成下一个状态
-
判断操作影响行数，如果影响了1行，说明当前操作成功，可以进行其他数据操作。
-
如果影响了0行，说明是重复请求，直接返回成功。
该方案仅限于要更新的表有状态字段，并且刚好要更新状态字段的这种特殊情况，并非所有场景都适用。
-
防重表
以支付为例：使用唯一主键去做防重表的唯一索引，比如使用订单号作为防重表的唯一索引，每一次请求都根据订单号向防重表中插入一条数据，插入成功说明可以处理后面的业务，当处理完业务逻辑之后删除防重表中的订单号数据，后续如果有重复请求，则会因为防重表唯一索引原因导致插入失败，直接返回操作失败，直到第一请求返回结果，可以看出防重表作用就是加锁的功能。
具体步骤：
-
用户通过浏览器发起请求，服务端收集数据。
-
将该数据插入mysql防重表
-
判断是否执行成功，如果成功，则做mysql其他的数据操作（可能还有其他的业务逻辑）。
-
如果执行失败，捕获唯一索引冲突异常，直接返回成功。
需要特别注意的点：防重表和业务表必须在同一个数据库中，并且操作要在同一个事务中。
缓冲队列
将请求都快速地接受下来后放入缓冲队列中，后续使用异步任务处理队列中的数据，过滤掉重复的请求。
优点：同步处理改成异步处理、高吞吐量。
缺点：不能及时返回请求结果，需要后续轮询得处理结果。
全局唯一ID
通过source来源+唯一序列号传入给后端，后端来判断请求是否重复，在并发时只能处理一个请求，其他相同并发请求要么返回请求重复，要么等待前面请求执行完后再执行。
绵薄之力最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走
这些资料，对于想进阶【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助，需要的小伙伴点击下方插件进群免费领取：
