微服务环境下,服务间会产生相互调用。那么既然产生了服务调用,就必然会存在服务调用延迟或失败的问题。当出现这种问题,服务端会进行重试或客户端有可能会进行多次提交。如果这样请求多次的话,那最终处理的数据结果就一定要保证统一
幂等的理解
通俗的来讲,就是第一次操作产生影响后,以后多次相同的操作不会再产生影响
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、乐观锁机制:支付成功后修改订单为已支付状态时,在更新条件上加上未支付状态,更新失败则表示重复执行
实际开发环境涉及到的幂等场景不只于此,还需要根据具体场景做出相对应的解决方案,不能一概而论