幂等性解决方案

幂等性：订单提交一次和提交多次结果是一致的

哪些情况要防止：

用户多次点击按钮
用户页面回退再次提交
服务相互调用，由于网络间题，导致请求失败。feign触发重试机制
其他业务情况

解决方案

(1)、token机制

如12306选中座位后提交，带上验证码与后台该token对应的验证码一致才通过。如果通过了就删除，第二个即使带着验证码也匹配不到

前面我们返回订单页面时也在redis中设置了用户的uuid

服务端提供了发送token的接囗。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。

然后调用业务接囗请求时，把token携带过去，一般放在请求头部。

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

但要保证只能有一个去redis看，否则就可能都看到redis中有，删除两次

【对比+删除】得是原子性的，所以就想到了用redis-luna脚本分布式锁

if redis.call('get',KEYS[1])==ARGV[1]
then return redis.call('del',KEYS[1])
else return 0
end
如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不重复执行。

(2)、各种锁

a、数据库悲观锁

select * from ×× where id=1 for update;

悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，需要根据实际情况选用。
另外要注意的是，id字段一定是主键或者唯一幸引，不然可能造成锁表的结果，处理起来会非常麻烦。

b、数据库乐观锁

这种方法适合在更新的场景中，

updatet _goods set count=count-1，version=version+1 where good_id=2 and version=1

根据version版本，也就是在操作库存前先获取当前商品的version版本号，然后操作的时候带上此version号。我们梳理下，我们第一次操作库存时，得到version为1，调用库存服务version变成了2；但返回给订单服务出现了间题，订单服务又一次发起调用库存，服务，当订单服务传如的version还是1，再执行上面的四!v语句时，就不会执行；因为version已经变为2了，where条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。

乐观锁主要使用于处理读多写少的问题

c、业务层分布式锁

(3)、各种唯一约束

a、数据库唯一约束
插入数据，应该按照唯一索引进行插入，比如订单号，相同的订单就不可能有两条记录插入。
我们在数据库层面防止重复。
这个机制是利用了数据库的主键唯一约束的特性，解决了在insert场景时幂等问题。但主键的要求不是自增的主，这样就需要业务生成全局唯一的主键。
如果是分库分表场景下，路由规则要保证相同请求下，落地在同一个数据库和同一表中，要不然数据库主键约束就不起效果了，因为是不同的数据库和表主键不相关。

b、redis set防重

很多数据需要处理，只能被处理一次，比如我们可以计算数据的MD5将其放入redis的set，每次处理数据，先看这个MD5是否已经存在，存在就不处理。

(4)、防重表

使用订单号orderNo做为去重表的唯一索引，把唯一幸引插入去重表，再进行业务操作，且他们在同一个事务中。这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。这里要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性。

之前说的redis防重也算

(5)、全局请求唯一id

调用接口时，生成一个唯一id，redis将数据保存到集合（去重），存在即处理过。

可以使用nginx设置每一个请求的唯一id

proxy_set_header X-Request-id $request_id;