接口幂等性

微服务环境下，服务间会产生相互调用。那么既然产生了服务调用，就必然会存在服务调用延迟或失败的问题。当出现这种问题，服务端会进行重试或客户端有可能会进行多次提交。如果这样请求多次的话，那最终处理的数据结果就一定要保证统一

幂等的理解

通俗的来讲，就是第一次操作产生影响后，以后多次相同的操作不会再产生影响

select * from table	where id = 1; 无论执行多少次，结果有可能不同，但不会对数据造成改变，具备幂等
update table set score=100 where id = 1; 无论执行多少次，对数据造成的影响都是相同的，具备幂等
update table score=score+1 where id = 1; 每执行一次，score都会改变，不具备幂等
delete from table where id = 1; 无论执行多少次，对数据造成的影响都是相同的，具备幂等
insert into table(id,score) value(1,100); 如果id和name具有唯一约束， 多少次操作只能插入一条，则具备幂等；

场景介绍

• 场景1：用户在客户端提交表单后没有在第一时间内感知到服务端的响应（1、客户端网络原因，导致没有将请求发送出去 2、服务器端自身原因，接收到客户端的请求后没有及时对客户端做出响应），于是客户又在短时间内重复提交表单
• 场景2：客户端提交表单后且在第一时间内获取到了服务端的响应，但是由于前端脚本的原因没有及时刷新页面，导致页面还停留在原始的提交页面，此时用户又提交了表单
• 场景3：支付成功的情况下，微信/支付宝服务重复调用我方回调接口

解决方案

1、前端防重机制：通常前端页面是要对相关按钮做防重操作的，考虑到浏览器脚本会被禁用的情况，这里我们不考虑前端的处理内容
2、服务端锁机制：通过Redssion实现分布式锁，有效的避免客户端在短时间内重复提交表单
3、防重表机制：创建防重表（包含一个或多个字段的唯一索引作为约束），插入数据时先向防重表插入数据，插入失败则表示重复执行
4、乐观锁机制：支付成功后修改订单为已支付状态时，在更新条件上加上未支付状态，更新失败则表示重复执行
实际开发环境涉及到的幂等场景不只于此，还需要根据具体场景做出相对应的解决方案，不能一概而论