A、幂等详解
一、什么是幂等性
接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用；比如说支付场景，用户购买了商品支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条．．．. 这就没有保证接口的幂等性。
二、哪些情况需要防止
1.用户多次点击按钮;
2.用户页面回退再次提交;
3.微服务互相调用，由于网络问题，导致请求失败。feign触发重试机制;
4.其他业务情况;
三、什么情况下需要幂等
- 以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+1 WHERE col2=2，每次执行的结果都会发生变化，不是幂等的。
- insert into user(userid,name) values(1,‘a’) 如 userid 不是主键，可以重复，那上面业务多次操作，数据都会新增多条，不具备幂等性
四、幂等解决方案
- 一、token机制
- 服务端提供了发送token的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。
- 然后调用业务接口请求时，把token携带过去，一般放在请求头部。
- 服务器判断token是否存在redis中，存在表示第一次请求，然后删除token,继续执行业务。
- 如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行。
不得不提到的危险性：
-
先删除token还是后删除token；
(1). 先删除可能导致，业务确实没有执行，重试还带上之前token，由于防重设计导致，请求还是不能执行。
(2). 后删除可能导致，业务处理成功，但是服务闪断，出现超时，没有删除token，别人继续重试，导致业务被执行两边
(3). 我们最好设计为先删除token，如果业务调用失败，就重新获取token再次请求。 -
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
- 二、各种锁机制
1、数据库悲观锁
select * from order 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、业务层分布式锁
如果多个机器可能在同一时间同时处理相同的数据，比如多台机器定时任务都拿到了相同数据处理，我们就可以加分布式锁，锁定此数据，处理完成后释放锁。获取到锁的必须先判断这个数据是否被处理过。
- 三、各种唯一约束
1、数据库唯一约束
插入数据，应该按照唯一索引进行插入，比如订单号，相同的订单就不可能有两条记录插入。我们在数据库层面防止重复。这个机制是利用了数据库的主键唯一约束的特性，解决了在insert场景时幂等问题。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键。如果是分库分表场景下，路由规则要保证相同请求下，落地在同一个数据库和同一表中，要不然数据库主键约束就不起效果了，因为是不同的数据库和表主键不相关。
2、redis set 防重
很多数据需要处理，只能被处理一次，比如我们可以计算数据的MD5将其放入redis的set，每次处理数据，先看这个MD5是否已经存在，存在就不处理。
- 四、防重表
使用订单号orderNo做为去重表的唯一索引，把唯一索引插入去重表，再进行业务操作，且他们在同一个事务中。这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。这里要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性。
之前说的redis防重也算
- 五、全局请求唯一id
调用接口时，生成一个唯一id，redis将数据保存到集合中（去重），存在即处理过。可以使用nginx设置每一个请求的唯一id；
# nginx 中的配置
proxy_set_header X-Request-Id $request_id;
B、实际项目中的方案
介绍一下业务场景，我们从购物车页面点击结算开始到订单页面，然后在订单页面点击“提交订单”按钮后来生成订单。我们就以这个实际项目中的流程为例子，用伪代码的形式来说明。
我们选用token的方式来做验证订单重复提交的幂等性问题。
- 在生成订单的页面我们会生成一个tooken放入到redis 中，并将它传递给前台页面，让他提交订单的时候携带tooken ，并将tooken的过期时间设置为30秒
//你可以把这个前缀做到一个常量类里面去
String USER_ORDER_TOKEN_PREFIX = "order:token";
//获取当前用户登录的信息
MemberResponseVo memberResponseVo = LoginUserInterceptor.loginUser.get();
//TODO 5、防重令牌(防止表单重复提交)
//为用户设置一个token，三十分钟过期时间（存在redis）
String token = UUID.randomUUID().toString().replace("-", "");
// memberResponseVo.getId() 为用户ID
redisTemplate.opsForValue().set(USER_ORDER_TOKEN_PREFIX+memberResponseVo.getId(),token,30, TimeUnit.MINUTES);
- 前端的订单页面提交订单时候会携带着：tooken、下单商品信息和数量、发票信息、地址信息、金豆实用信息、支付类型ID 来到我们的订单创建逻辑，这里面我们的任务就是先检查tooken
//1、验证令牌是否合法【令牌的对比和删除必须保证原子性】
//这就是lua脚本
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
//获取我们前台下单时传过来的tooken
String orderToken = vo.getOrderToken();
//通过lure脚本原子验证令牌和删除令牌。并在最终返回 0 或 1
Long result = redisTemplate.execute(
new DefaultRedisScript<Long>(script, Long.class),//传递一个lua脚本+返回值类型
Arrays.asList(USER_ORDER_TOKEN_PREFIX + memberResponseVo.getId()),//因为我们可以看到，lua脚本里面是用的KEYS[1] 来接收的，所以我们需要传入一个Array类型，然后lua脚本会去取第一个值作为key去查询
orderToken//这是我们要对照的值（前台下单时传过来的tooken）
);
//验证
if (result == 0L) {
//令牌验证失败
responseVo.setCode(1);
return responseVo;
} else {
//这里继续执行后续的业务，省略...........
}
这样，经过tooken验证之后我们就完美的解决了幂等问题，并且不会对数据库服务器造成压力。