如何保证接口的幂等性？

1.什么是接口的幂等性？

幂等性就是一个接口在短时间内被多次调用，产生的结果和只调用一次的结果相同。比如查询操作就天然幂等。

为什么说它是天然的幂等呢？

select * from staff where id = 1;

因为这个查询语句不管执行多少次都不会对资源造成修改，所以说是天然幂等的操作。

2.为什么要保证幂等性呢？

比如我们在给老婆转账一万块钱的时候不小心点击了 2 次支付按钮，这个时候如果支付接口没有幂等性，那么转出去的钱就是两万了。

所以，必须得通过一定手段来保证接口的幂等性

3.那么如何保证接口的幂等性呢？

3.1 乐观锁

乐观锁就是非常乐观，每次查询数据的时候并不会上锁，认为别人不会修改数据。只有在自己修改数据的时候会判断在此期间内数据有没有被人修改。

乐观锁最常见的手段就是通过增加数据库表字段（版本号）来实现，如下：

update stock set count = count-1 , version = version + 1 where id=1 and version = 1
1

这样根据之前的版本号为条件来更新数据库，只有版本号没变才会更新成功。

但是乐观锁适用于读多写少的场景，这样冲突的情况可以大大减少进而省去了锁的开销，提高了系统的吞吐量。如果是写比较多的场景则会经常发生冲突导致失败，从而程序不断的进行重试，这样反倒是降低了系统的性能。

3.2 利用 token 来验证

来看看用唯一性 token 如何实现接口的幂等：

1. 当客户端请求页面时，服务器会生成一个随机令牌 token，并且将 token 暂存到 redis 当中，然后将 token 下发给客户端

2. 下次客户端发起请求时，token 会带着一起提交到服务端。服务端第一次验证相同过后，会将 redis 中的 token 值更新。此时如果用户进行重复提交，第二次的 token 验证将失败，因为用户提交的 token 还是旧的，但服务端 redis 中 token 已经更新了。

但是需要注意的是在并发场景下，上述方法并不是线程安全的。

3.3 token + 分布式锁

分布式锁的实现我们可以采用 redisson 来实现，如下：

 RLock lock = null;
        try {
            lock = redissonClient.getLock(lockKey);
            // 自旋等待时间,默认2S
            int waitTime = 2;
            if (!lock.tryLock(waitTime, 5, TimeUnit.SECONDS)) {
                throw new RuntimeException("重复操作！");
            }
            // 执行业务操作
        } finally {
            // 释放锁
            if (lock != null && lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

这样我们就可以保证并发场景下的接口幂等性了。
说说你们是用的什么方式来保证接口的幂等性呢？