什么是幂等性、为什么要做幂等性、有哪些方式就可以实现幂等性？
场景：以淘宝提交订单为例，用户在“同一个订单”页面多次提交：用户在这个“同一页面”不管是提交一百还是一次，最后的数据库里面都只能有一个订单数据。这个就是幂等性，防提重复提交。
简单理解为同一事件多次操作只能被正确的消费一次。数据防重复消费。
一、什么是幂等性
接口幂等性就是用户对于同一操作发送一次或者多次请求的结果是一致的，不会因为多次点击而产生了副作用；比如说支付场景，用户购买了商品支付和扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条，这就是没有保住接口幂等性。
二、那些情况下需要处理幂等性
用户多次点击按钮
用户页面回退再次提交
微服务互相调用，由于网络问题，导致请求失败，feign触发重试机制
其他业务情况
三：幂什么情况下需要幂等
以SQL为例，有些操作是天然幂等的。
SELECT * FROM table WHERE id = ?, 无论执行多少次都不会改变状态，是天然的幂等。
UPDATE tab1 set col1 = 1 where col2 = 2,无论执行成功多少次状态都是一致的，也是幂等操作。
delete from user where userid = 1,多次操作，结果一样，具备幂等性
insert into user(userId,name) values(1,’a’)如userId为唯一主键，即重复操作上面的业务，只会插入一条用户数据，具备幂等性。
————————————————————————————————————————————————
update tab1 set col1 = col1 + 1where col2 = 2,每次执行的结果都会发生变化，不是幂等的。
insert into user(userId,name) valeus(1,’a’)如userid不是主键，可以重复，那上面业务多次操作，数据都会新增多条，不具备幂等性。
四、幂等解决方案
1、token机制
1、服务端提供了发送token的接口。我们在分析业务的时候，那些业务是存在幂等问题的就必须在执行业务前，先去获取token，服务器会把token保存在redis中。
危险性：
1.先删除token还是后删除token;
(1)、先删除可能导致，业务确实没有执行，重试还带上之前token，由于防重设计导致请求还是不能执行
(2）后删除可能导致，业务处理成功，但是服务闪断，出现超时，没有删除token别人继续重试，导致业务被执行两边
(3)我们最好设计为先删除token，如果业务调用失败，就重新获取token再次请求。
2、Token获取、比较和删除必须要原子性的
(1)redis.get(token)、token.equals、redis.del(token)如果这两个操作不是原子，可能导致高并发性
都get到同样的数据、判断都成功、继续业务并发执行
(2)可以在redis使用lua脚本完成这个操作。
2、各种锁机制
1、数据库悲观锁
select * from xxxx 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号。。我们梳理下，我们第一次操作库存时，得到version为1，调用库存服务version变成了2,；但是返回给订单服务出现了问题，订单服务又一次发送掉用库存服务，当订单服务传入的version还是1，在执行上面的sql语句时，就不会执行了；因为version已经变为2了，where条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。乐观锁主要使用与处理读多写少的问题。
3、业务层分布式锁
如果多个机器可能在同一时间同时处理相同的数据，比如多台机器定时任务都拿到了相同数据处理。我们就可以加分布式锁，锁定此数据。处理完成后释放锁。获取到锁的必须先判断这个数据是否被处理过。
3、各种唯一约束
1、数据库唯一约束
插入数据，应该按照唯一索引进行插入，比如订单号，相同的订单就不可能有两条记录插入。
我们在数据库层面防止重复。
这个机制是利用了数据库的主键唯一约束的特性，解决了在Insert场景是幂等问题。但是主键的要求不是自增的主键，这样就需要业务生成一个全局唯一的主键。
如果是分库分表场景下，路由规则要保证相同的请求，落在同一个数据库和同一表中，要不然数据库主键约束就不去效果了，因为市不同的数据库和表主键不相关。
2、redis set防重
很多数据需要处理，只能被处理一次，比如我们可以计算数据的md5将其放入redis的set中，每次处理数据先看看这个md5是否已经存在，存在就不处理
4、防重表
使用订单号orderNo做为去重表的唯一索引，把唯一索引插入去重表，在进行业务操作，且他们在同一个事物中，这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题，这里要注意的是，去重表和业务表应该在同一个库中，这样就保证了在同一个事务，即使业务操作失败，也会把去重表的数据回滚，这个很好的保证了数据一致性。
5、全局请求唯一id
调用接口时，生成一个唯一id，redis将数据保存到集合中（去重）,存在即处理过。
可以使用nginx设置每一个请求的唯一id，
proxy_set_header X-Request-id $request_id