接口幂等性

一. 什么是幂等性

• 接口幂等性就是用户对于同一操作发起的一次请求或多次请求的结果都是一致的,不会因为多次点击而产生副作用

二. 哪些情况需要防止

• 用户多次点击
• 用户页面回退再次提交
• 微服务互相调用,由于网络问题,导致请求失败,feign触发重试机制

三. 幂等解决方案

token机制

1. 服务端提供发送token的接口,在分析业务的时候,哪些业务是存在幂等问题的,就必须在执行业务前,先去获取token,服务器会把token保存到人redis中

2. 然后调用业务接口请求时,把token携带过去,一般放在请求头

3. 服务器判断token是否存在redis中,存在表示第一次请求,然后删除token,继续执行业务

4. 如果判断token不存在redis中,就表示重复操作,直接返回重复标记给client,这样保证了业务代码,不被重复执行

• 危险性
  1. 先删除token,还是后删除token
     • 先删除可能导致业务确实没有执行,重试还带上之前的token,由于防重设计导致请求还是不能执行
     • 后删除可能导致业务处理成功,但是服务闪断,出现超时,没有删除token,别人继续重试,导致业务执行多次
     • 我们最好的设计为先删除token,如果业务调用失败,就重新获取token再次请求
  2. token获取,比较和删除必须是原子性
     • redis.get(token),token.equals,redis.del(token)如果不是原子操作,高并发环境下可能导致,都get到同样数据,判断都成功,业务都并非执行
     • 可以在redis使用lua脚本完成这个操作
     • if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end

各种锁机制

1. 数据库悲观锁
   • select * from xxx where id = 1 for update 悲观锁使用时一般伴随事务一起使用,数据锁定时间可能会很长,需要根据实际情况选用,另外要注意的是,id字段是主键或者唯一索引,不然可能造成锁表的结果,处理起来会非常麻烦
2. 数据库乐观锁
   • 这种方法适合在更新的场景中 update t_goods set count = count -1 version = version +1 where good_id = 2 and version = 1 根据version版本,也就是在操作库存前,先获取当前商品的version版本号,然后操作的时候带上此version号,乐观锁主要使用于处理读多写少的问题
3. 业务层分布式锁
   • 如果多个机器可能在同一时间处理相同的数据,比如多态机器定时任务都拿到了相同数据处理,我们就可以加分布式锁,锁定此数据,处理完成后释放锁,获取到锁的必须先判断这个数据是否被处理过

各种唯一约束

1. 数据库唯一约束
   • 插入数据,应该按照唯一索引进行插入,比如订单号,相同的订单就不可能有两条插入记录,这样就是在数据库层面防止重复.这个机制是利用了数据库的主键唯一约束的特性,解决了在insert场景时幂等问题,但主键如果是分库分表的场景下,路由规则要保证相同请求下,落地在同一个数据库和同一表中,要不然数据库主键约束就不起效果了,因为是不同的数据库和表主键不相关
2. redis set防重
   • 很多数据需要处理,只能被处理一次,比如我们可以计算数据的MD5值,将其放入redis的set,每次处理数据,先看MD5是已经存在,存在就不处理
3. 防重表
   • 使用订单号orderNo作为去重表的唯一索引,把唯一索引插入去重表,再进行业务操作,且他们在同一个事务中,这个保证了重复请求时,因为去重表有唯一约束,导致请求失败,避免了幂等为题,这里要注意的是,去重表和业务表应该在同一库中,这样保证了在同一个事务,即使业务操作失败了,也会把去重表的数据回滚.
4. 全局请求唯一id
   • 调用接口时,生成一个唯一id,redis,将数据保存到集合中(去重),存在即处理通过,可以使用nginx设置每一个请求的唯一id, proxy_set_header X-Request-id $request_id