接口幂等性(演示：防止商品重复下单操作)

业务场景

• 用户多次点击按钮

• 用户页面回退再次提交

• 微服务互相调用，由于网络问题，导致请求失败。feign 触发重试机制
  其他业务情況

幂等性解决方案

• 1、token机制（令牌机制）此处采用令牌机制

• 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、数据库表各种唯一性约束

1-数据库唯一约束

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

• 4、数据库建立防重表

• 5、全局请求唯一id

调用接口时，生成一个唯一 id，redis 将数据保存到集合中（去重），存在即处理过。 可以使用 nginx 设置每一个请求的唯一 id； proxy_set_header X-Request-Id $request_id

token 演示列：

场景 用户重复提交创建订单:

1-进入结算页生成token

 //第一步：在redis中放置令牌 为用户设置一个token，三十分钟过期时间（存在redis）
        String token = UUID.randomUUID().toString().replace("-", "");
        redisTemplate.opsForValue().set(USER_ORDER_TOKEN_PREFIX+memberResponseVo.getId(),token,30, TimeUnit.MINUTES);

2- 点击结算按钮 带上token令牌 验证

//第二步：lure 脚本验证并且删除令牌（返回 0 ：不存在 1：存在） 验证令牌是否合法【令牌的对比和删除必须保证原子性】
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        String orderToken = vo.getOrderToken();

        //调用execute方法执行脚本：通过lure脚本原子验证令牌和删除令牌
        Long result = redisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class),
                Arrays.asList(USER_ORDER_TOKEN_PREFIX + memberResponseVo.getId()),
                orderToken);

//result 验证失败
        if (result == 0L) {
            //令牌验证失败
            responseVo.setCode(1);
            return responseVo;
        } else {
            //令牌验证成功 创建订单
  }