- 什么是幂等性
- 为什么要保证接口的幂等性呢？
- 如何保证接口的幂等性
我们都知道面试的时候，什么问题，都会有，这个全看面试官想问什么，但是有一些比较专业的术语，可能对于小白来说，就不是很好，一个学妹，面试的时候，就被问到了一个问题，接口的幂等性，你们是怎么保证的？这个问题，学妹可能不知道幂等性是个什么概念，所以，也就没有办法精准的定位，把面试官想要的答案说出来，今天就来说说如何保证接口的幂等性。
什么是幂等性
幂等性就是一个方法短时间内被多次调用，但是产生的结果和只调用一次的结果相同，那么这个操作就是幂等的。比如select操作天然幂等。
为什么说它是天然的幂等呢？
select * from user where id = 2
因为这个查询语句无论执行多少次都不会对资源造成副作用，所以可以说是天然的幂等。
而这也是接口的幂等性，那么为什么接口需要幂等性呢？
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/
为什么要保证接口的幂等性呢？
这就来了，为什么要保证接口的幂等性，这很简单，比如我们在买某些商品的时候，不小心点击了下单的2次按钮，如果不做接口的幂等性，那么付出去的钱，就是双倍了，相同数据，回应两个结果，扣钱直接扣2次，如果你是消费者，你会不会直接就说以后再也不来了。虽然最后会通过各种办法退还给你，但是心里总还是不爽的，不是么？
所以，就得通过开发来保证接口的幂等性。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn/video/
如何保证接口的幂等性
思路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 版本一直是自增的就不会出现这种情况。
所以你对如何保证接口的幂等性了解了么？