什么是分布式幂等性
本篇文章为大家展示了什么是分布式幂等性，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
幂等性问题
幂等性问题指的是一个接口多次执行的结果应当与一次执行的结果相同(即重复操作不会对数据准确性造成影响)。 在数据不变的情况下，查询和删除操作天然具备幂等性，而新增和修改操作默认情况下不能保证幂等。
大白话就是：我点了多少次按钮，就给我生成一次。
提交一次和提交100次结果是一样的
1. token机制
服务端提供了发送token的接口。我们在分析业务的时候，哪些业务是存在幂等性问题的。就必须在执行业务之前，先去获取token，服务器会把token保存到redis
然后调用业务接口请求时，将token携带过去，一般放在请求头中
服务器判断token是否存在redis中，存在表示第一次请求，然后删除token，继续执行业务。
危险性
2. 利用redis set防重
很多数据需要处理，只能被处理一次。比如我们可以计算数据的MD5将其加入redis的set，每次处理数据，先看这个MD5是否已经存在，存在就不处理。
3. 防重表
使用订单编号orderNo作为防重表的唯一索引，把唯一索引插入去重表，再进行业务操作，且他们在同一个事务下。这个保证了重复请求时，因为去重表唯一约束导致请求失败，避免了幂等性问题。 注意：去重表和业务表应该在同一个库中，这样就能保证了因为同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性
4. 数据库乐观锁
这种方式适合在更新场景中。
例如：update t_goods set count = count - 1 , version = version + 1 where g_id = 2 and version
根据version版本号，也就是在操作数据库之前先 获取到当前商品的version版本号 ， 然后操作的时候带上此version号。我们梳理下，第一次操作库存时，得到version为1，调用库存服务version变为2；但返回给订单服务出现了问题，订单服务有一次发起调用库存服务，当订单服务传入的version还是1，再执行上面SQL就不会执行。因为version已经变为2了，where条件不成立。这样不管调用几次，只会真正处理一次。
乐观锁主要用于读多写少的问题
5. 业务层分布式锁
调用接口时，生成唯一id，redis将数据保存到集合中（去重），存在即处理过。可以使用ngxin设置每一个请求的唯一id。
proxy_set_header X-Request-Id $request_id;
6. 生成唯一令牌方案
数据提交前向服务获取token,设置有效期；提交后服务校验token，校验通过删除旧值生成新值，等待下次获取。
如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号。 source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
上述内容就是什么是分布式幂等性，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。
