接口幂等性介绍 SpringCloud下接口幂等性的解决方案 Token
场景:在分布式系统之间,当给表单提交数据或分布式系统之间的相互调用,一个方法可能会执行多次(用户重复提交),需要保证执行多次(提交多次)和执行一次的结果相同,保证接口的幂等性
什么是接口幂等性?
接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的.不会因为多次点击而产生了副作用.
举例:比如说支付场景,用户购买了商品支付扣款成功,但是返回结果的时候网络异常,此时钱已经扣了,用户再次点击按钮,此时会进行第二次扣款,流水记录也变成了两条.此时就没有保证接口的幂等性.
哪些情况下需要保证接口幂等性 防止流水错误
- 用户多次点击提交按钮
- 用户页面回退再次提交
- 微服务之间互相调用,由于网络问题,导致请求失败.feign触发重试机制
- 其他业务情况
幂等解决方案
1.数据库层面
1.1 添加UNIQUE索引
将数据库中的字段添加索引,设置为唯一字段,实现幂等
1.2 数据库的悲观锁
select * from xxx where id = 1 for update
- 悲观锁使用时一般伴随事务一起使用, 数据锁定时间可能会很长,需要根据实际情况选用
- 另外要注意的是,id字段一定是主键或者唯一索引,不然可能造成锁表的结果,处理起来非常麻烦
1.3 数据库的乐观锁 (更新场景中适用)
update table set field=field+1 , version = version+1 where id=1 and version = 1
- 根据version版本,也就是在操作库存前先获取当前商品的version版本号,然后操作的时候带上此version号。
- 我们第一次操作库存时,得到version为1,调用库存服务version变成了2
- 当返回给订单服务出现了问题,订单服务又一次发起调用库存服务,当订单服务传如的version还是1,再执行上面的sgl语句时,就不会执行
- 乐观锁主要使用于处理读多写少的问题
2.后端业务层面实现
2.1token机制
实现原理:
-
服务端提供发送token的接口.在需要幂等问题的业务执行前,先去获取token,服务器会把token保存在redis中.(原子性)
-
//TODO 放重复提交令牌 幂等性 String token = UUID.randomUUID().toString().replace("-", ""); stringRedisTemplate.opsForValue().set(OrderConstant.USER_ORDER_TOKEN_PREFIX+memberResVo.getId(),token,30, TimeUnit.MINUTES);
-
-
然后调用业务接口请求时,把token携带过去,一般放在请求的头部.
-
<input type="hidden" th:value="${orderConfirmData.getOrderToken()}" name="orderToken"> <button class="tijiao">提交订单</button>
-
-
服务器判断tiken是否存在redis中,存在表示第一次请求,然后删除token,继续执行业务.(使用lua脚本保证原子性)
-
//1.验证令牌[令牌的对比和删除必须原子性] String orderToken = vo.getOrderToken(); String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] " + "then " + " return redis.call('del', KEYS[1])" + "else " + " return 0 " + "end"; /** * 使用lua脚本原子验证和删除令牌 判断参数key[1]的值和传入的参数avg[1]是否相等,相等则删除 * execute(RedisScript<T> script, List<K> keys, Object... args) * keys: redis中的键名 * args: 对比的参数 * 返回类型为Long * 返回 0:表示失败 * 1:表示成功 */ Long result = stringRedisTemplate.execute(new DefaultRedisScript<Long>(luaScript, Long.class), Arrays.asList(OrderConstant.USER_ORDER_TOKEN_PREFIX + memberResVo.getId()), orderToken); if(result == 1){ //验证成功,处理业务 return orderSubmitResVo; }else { //验证失败 return null; }
-
-
如果判断token不存在redis中,即表示为重复操作,直接返回重复标记给客户端,保证业务代码不被重复执行.
缺点:
-
先删除token还是后删除token;
- 先删除可能导致,业务还没执行就闪断,后面的请求任然无法执行
- 后删除也可能出现业务成功后再删除前闪断.
-
token的获取,比较和删除必须是原子的(lua脚本实现)
-
如果操作不原子,高并发下可能多个业务同时判断成功,都执行
-
String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] " + "then " + " return redis.call('del', KEYS[1])" + "else " + " return 0 " + "end";
-
2.2 分布式锁(影响性能)
如果多个机器可能在同一时间同时处理相同的数据,比如多台机器定时任务都拿到了相同数据处理,我们就可以加分布式锁,锁定此数据,处理完成后释放锁。获取到锁的必须先判断这个数据是否被处理过。
分布式锁+分布式下的缓存问题 使用redis(redisson) 实现分布式锁
2.3 全局请求唯一id
调用接口时,生成一个唯一的id,redis将数据保存到集合中(去重),存在即处理过.可以使用nginx设置每一个请求的唯一id
proxy_set_header X-Request-Id $request_id;