面试必问，如何保证接口的幂等性？

我们都知道面试的时候，什么问题，都会有，这个全看面试官想问什么，但是有一些比较专业的术语，可能对于小白来说，就不是很好，阿粉的一个学妹，面试的时候，就被问到了一个问题，接口的幂等性，你们是怎么保证的？这个问题，学妹可能不知道幂等性是个什么概念，所以，也就没有办法精准的定位，把面试官想要的答案说出来，今天阿粉就来说说如何保证接口的幂等性。

什么是幂等性

幂等性就是一个方法短时间内被多次调用，但是产生的结果和只调用一次的结果相同，那么这个操作就是幂等的。比如select操作天然幂等。

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

select * from user where id = 2

因为这个查询语句无论执行多少次都不会对资源造成副作用，所以可以说是天然的幂等。

而这也是接口的幂等性，那么为什么接口需要幂等性呢？

为什么要保证接口的幂等性呢？

这就来了，为什么要保证接口的幂等性，这很简单，比如我们在买某些商品的时候，不小心点击了下单的2次按钮，如果不做接口的幂等性，那么付出去的钱，就是双倍了，相同数据，回应两个结果，扣钱直接扣2次，如果你是消费者，你会不会直接就说以后再也不来了。虽然最后会通过各种办法退还给你，但是心里总还是不爽的，不是么？

所以，就得通过开发来保证接口的幂等性。

如何保证接口的幂等性

思路一：token验证机制

第一步：当客户端请求页面时，服务器会生成一个随机数token，并且将token放置到session当中。

第二步：然后将token发给客户端（一般通过构造hidden表单）。

第三步：下次客户端提交请求时，token会随着表单一起提交到服务器端。服务器端第一次验证相同过后，会将session中的token值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的token没变，但服务器端session中token已经改变了。

但是在高并发的请求中，token的验证机制，是不是线程安全的呢？

如果要是线程不安全的话，我们也没有办法保证这个操作的幂等性吧。于是就有了下面的思路。

思路二：token+分布式锁

分布式锁的实现，可太多，阿粉就举例子实现一种，比如说我们使用 Redis 来实现分布式锁，

咱们也不整那个虚头巴脑的东西，直接上，RedisLockRegistry。

RedisLockRegistry相当于一个锁的管理器，所有的分布式锁都可以从中获取，如上定义，锁的键名为 “redis-lock: 你定义的 key”，超时时间也可以自己设定，默认超时时间是 60s。

实例代码：

// 测试Demo
public void test(String lockKey) {
    // 获取锁
    Lock lock = redisLockRegistry.obtain(lockKey);
    // 加锁
    lock.lock();
    try {
        // 此处是你的代码逻辑，处理需要加锁的一些事务
    } catch (Exception e) {
    } finally {
        // 配合解锁逻辑
        lock.unlock();
    }
}

剩下的阿粉不多说，大家肯定也都知道怎么用，我们说说这个token+Redis 在什么样子的业务场景下经常的会用到的。

其实最简单的，还是我们的支付场景，

●  获取全局唯一的token，接口处理生成唯一标识(token) 存储到redis中，并返回给调用客户端。
●  发起支付操作并附带token

接口处理的内容：

●  获得分布式锁（处理并发情况）
●  判断redis中是否存在token
●  存在 执行支付业务逻辑，否则返回该订单已经支付
●  释放分布式锁

如此使用的情况下，我们就能保证了这个支付场景下的接口幂等性的操作了。

思路三：乐观锁实现幂等性

我们先说说什么是乐观锁，实际上乐观锁可以理解为一个马大哈。总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，只在更新的时候会判断一下在此期间别人有没有去更新这个数据。

而最常用的就是通过版本号或者CAS来实现乐观锁。

就比如我们最常见的：

订单服务 —> 库存服务 （PRC远程调用(服务接口)）

因为分布式部署，很有可能在调用库存服务时，因为网络等原因，订单服务调用失败，但其实库存服务已经处理完成，只是返回给订单服务处理结果时出现了异常。这个时候一般系统会作补偿方案，也就是订单服务再此放起库存服务的调用,库存减1。

update t_goods set count = count -1 where good_id=22

相当于这个时候，库存已经减掉了，但是，因为返回的时候，出现了错误，又减了一次库存，这就离谱了，到时候发现商品库存不够了。那估计就得被领导给优化掉了。

而加入版本号之后怎么实现呢？

update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1

这样更新的时候，根据版本号来更新，如果版本号一致，那才更新，不然的话就获取最新版本号再次更新。

像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能。

既然我们说到了乐观锁，肯定就会有人说，乐观锁不是会出现 ABA 的问题么？

这个就得看你的 version 版本号是什么设计了， 如果你的 version 版本一直是自增的就不会出现这种情况。

所以你对如何保证接口的幂等性了解了么？