一、什么是接口幂等性

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用；比如说支付场景，用户购买了商品支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条．．．,这就没有保证接口的幂等性.

二 、哪些情况需要防止

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

三、什么情况下需要幂等

以 SQL 为例，有些操作是天然幂等的。
SELECT * FROM table WHER 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+1 WHERE col2=2，每次执行的结果都会发生变化，不是幂等的。
insert into user(userid,name) values(1,'a') 如 userid 不是主键，可以重复，那上面业务多次操
作，数据都会新增多条，不具备幂等性

四、幂等解决方案

1、token机制

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

1.1 使用token机制

1、应用场景，是用户提交订单操作，这个操作就需要保证防止订单重复提交。
2、防止订单重复提交策略方法？
1）数据库层面，将订单表中的订单号设置为唯一索引，防止一个订单出现多条记录的情况。
2）使用token令牌机制，即在提交订单时提交一个token令牌（这个token令牌是后端生成传给前端的），与后端的令牌进行比对（后端的令牌存储在redis中）。

1.2 使用token机制存在几个问题

1、如果令牌比对成功并创建完订单后，再删令牌可不可以，会有什么问题？
不可以，如果在创建订单的过程中，第一个请求进来了，正在创建订单，此时第二个请求也进来了，带着同样的token，比对成功，那么就会有两个相同的订单创建了。

2、如果令牌比对成功后就将令牌删除，再去创建订单可不可以，有什么问题？
不可以，在分布式的环境下，同时进来两个请求，同时比对token，并执行删除令牌的操作这样同样会出现创建两个订单的问题。

// serverToken:后端的令牌
// token：是前端传过来的toiken
 if(serverToken == token){
	del(token);
	server();
 } 

3、如何避免上面的两个问题？

	1、获取令牌
	2、对比令牌
	3、删除令牌
	以上三个操作必须保证原子性，不可分割的
	如何保证原子性，使用Redis的Lua脚本

Token 获取、比较和删除必须是原子性
（1）redis.get(token) 、token.equals、redis.del(token)如果这两个操作不是原子，可能导致，高并发下，都 get 到同样的数据，判断都成功，继续业务并发执行。
（2）可以在 redis 使用 lua 脚本完成这个操作

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

2、数据库乐观锁

2.1 数据库乐观锁

这种方法适合在更新的场景中，
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 条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。乐观锁主要使用于处理读多写少的问题

2.2 数据库悲观锁

select * from xxxx where id = 1 for update;

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

3、业务层分布式锁

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

3、各种唯一约束

3.1 数据库唯一约束

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

3.2 redis set 防重

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