⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处网络「网络」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

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

什么是幂等性

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

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

select * from user where id = 2

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

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

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

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

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

如何保证接口的幂等性

思路1：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 版本一直是自增的就不会出现这种情况。

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

芋道源码 —— 纯源码解析博客

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

什么是幂等性

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

如何保证接口的幂等性