接口幂等性

接口幂等性

接口幂等性

什么业务需要幂等性

天然幂等的环境

天然幂等操作： 查询，不论查询多少次都不会改变，固定值更新，删除幂等，按照指定主键插入幂等。

幂等解决方案：

1.令牌机制：给页面带着令牌。

token机制流程

1、服务端提供发送token的接口，在执行业务前，先去获取token，服务器会把token保存到redis中。2.然后调用业务接口请求时，把token携带过去，一般放在请求头部。3.如果判断token是否存在redis中，存在表示第一次请求，然后删除token继续执行业务。4.如果判断token不在redis中，表示重复操作，直接返回重复标记给client，这样保证业务代码不会被重复执行。

操作不当的危险性：

先删除token还是后删除token:1.先删除可能导致，业务确实没有执行，重试还带上之前的token，由于防止重复设计，请求还是不能执行。2.删除可能导致，业务处理成功，但是服务闪断，出现超时，没有删除token，别人重试，导致业务被执行两遍3.我们最好设置先删除token如果业务失败，重新获取token再次请求。

token获取比较和删除必须保证原子性：

1.redis的get,eq,del，如果不是原子性，可能导致高并发场景下都get到同样的数据，判断都成功，继续业务并发执行 2.可以在redis使用lua脚本完成这个操作。 if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1])else return 0 end

2.各种锁机制

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

乐观锁更适合更新场景：update t1 set count=count-1 ,version=version+1 where good_id-2 and version=1根据version版本，也就是操作库存前先获取当前商品的version版本号，然后操作的时候带上verson版本，也就是操作库存前先获取当前商品的version版本号，然后操作的时候，带上此版本号，我们梳理一下，第一次操作库存的时候，得到version为1，调用库存服务version变成了2，但是返回给订单服务出现了问题，订单服务又一次发起了调用库存服务，当订单服务传的version还是1，再执行上面的语句时，就不会执行，因为version已经变成了2，where条件不会成立，不管调用几次，只会真正处理一次，乐观锁主要处理读多写少的问题

业务层分布式锁

如果多个机器可能同一时间处理相同的书，比如多台机器定时任务都拿到相同数据处理，就可以加分布式锁，锁定此数据，处理完成后释放锁，获取到锁的必须先判断这个数据是否处理过。

3.各种唯一约束

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

redis set防重复

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

4.防重表

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

5.全局请求唯一id

调用接口时，生成一个唯一id,redis将数据保存到集合中(去重)，存在即处理过，可以使用nginx设置每次请求的唯一id， proxy_set_header X_Request-id $request_id;

作者：三号小玩家

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。