接口的幂等性如何设计？
前言
所谓幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。
我们在开发中主要操作也就是CURD,其中读取操作和删除操作是天然幂等的，我们所关心的就是创建操作、更新操作。
创建操作一定是非幂等的因为要涉及到新数据的产生，而更新操作有可能幂等有可能非幂等，这个要看具体业务场景。
一、幂等性的使用场景
1、前端重复提交
就好比有个新增商品的功能，有个保存按钮，如果前端连续多次点击保存，后端就会收到多次请求接口，如果没做好幂等就会重复创建了多条记录,
就会出现脏数据。
这个也就是我们所说的如何防止前端重复提交的问题。
2、接口超时重试
当我们调取第三方接口的时候,有可能会因为网络等原因导致调用失败，所以我们会对接口调用添加失败重试的机制,Spring可以通过@Retryable注解实现重试机制。
既然重试就可能出现重复调用接口。这时再次调用时如果没有做好幂等,就可能出现脏数据。
3、消息重复消费
这个是无法避免的，因为我们说MQ在生产端和消费端都有重试机制，也就是同一消息很可能会被重复消费。
如果业务保证多次消费的结果是一样的那没问题，但是如果业务无法满足那就需要通过其它方式来保证消费端的幂等。
二、初级方式来保证尽量幂等
1、插入前先判断数据是否存在
这种是最基础的，也是我们在开发中必须要做的。我们会在插入或者更新前先判断下,当前这个数据数据库中是否已经存在，如果不存在则不允许重复插入，不存在则可插入。
代码示例如下:
public void save(Goods goods) {
// 1、先通过商品唯一code，查询数据库属否存在
Goods goods = findGoods(goods.getCode);
// 2、如果这条数据在db里已经存在了，此时就直接返回了
if (goods != null) {
return;
}
// 3、如果要是这条数据在db里不存在，此时就会执行数据插入逻辑了
insertGoods(goods);
}
2、前端做一些交互控制
好比有个新增商品的功能，有个保存按钮,用户点击保存按钮后，立马按钮置灰，或者页面跳转到商品列表页面，这样可以防止很大部分的前端重复提交。
三、高并发下如何保证幂等？
上面两种初级方法，在高并发下显然是无法保证接口幂等的，所以在高并发下，我们来如何保证接口的幂等呢，这里整理几种常见的解决办法。
1、基于悲观锁
定义: 当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。
这里以更新商品订单状态来举例：一般订单有订单创建、订单确认、订单支付、订单完成、取消订单等订单流程。
当我更新订单状态为订单完成的时候，我们首先通过判断该订单的状态是否是订单支付，如果是不是则直接返回，否则更新状态为已完成。
伪代码示例如下
begin; -- 1.开始事务
-- 查询订单，判断状态
select order_no,status from order where order_no='20200524-1'
if（status !=订单支付状态）{
-- 非订单支付状态，不能更新为已完成；
return ;
}
-- 更新完成
update order set status='订单完成' order_no='20200524-1'
commit; -- 2.提交事务
这是我们常见的一种写法，但这种写法在高并发环境下，可能会造成一个业务被执行两次的情况发生：
同时有两个请求过来,大家几乎同时查数据库订单状态，都是订单支付状态，然后就支持接下来一系列操作，这就导致一个业务被执行了两次，如果接下来一系列操作不是幂等的
那么就会出现脏数据。这里我们就可以通过悲观锁实现，也就是添加for update字段。
伪代码示例如下
begin; -- 1.开始事务
-- 查询订单，判断状态
select order_no,status from order where order_no='20200524-1' for update
if（status !=订单支付状态）{
-- 非订单状态，不能更新为已完成；
return ;
}
-- 更新完成
update order set status='完成' order_no='20200524-1'
commit; -- 2.提交事务
1）这里order_no需要添加索引，否则会锁表。
2） 悲观锁在同一事务操作过程中，锁住了一行数据。悲观锁性能不佳所以一般不建议用悲观锁做这个事情。
2、基于乐观锁
定义:乐观锁就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号机制。
所谓的乐观锁就是在表中新增一个version(版本号)字段。
通过版本号的方式，来控制update的操作的幂等性，用户查询出要修改的数据，系统将数据返回给页面，将数据版本号放入隐藏域，用户修改数据，点击提交，将版本号一同提交
给后台，后台使用版本号作为更新条件。
update set version = version +1 ,count=count+1 where id =xxx and version = ${version};
注意:乐观锁能够保证的是update的操作的幂等性,如果你的update本身就是幂等操作，或者install操作那就不能用乐观锁了。
3、基于状态码
很多业务表，都是有状态的，比如订单表,一般订单有1-订单创建、2-订单确认、3-订单支付、 4-订单完成、5-取消订单等订单流程，当我们更新订单状态
update order_table set status=3 where order_no='20200524-1' and status=2;
第一个请求时，成功把 订单确认 状态修改成 订单支付,sql执行结果的影响行数是1。
第二个请求时，同样想把 订单确认 状态修改成 订单支付,但是sql执行结果的影响行数为0。如果是0，那么我们直接可以返回成功了。而不需要做接下来的业务操作，以此来保证保证
接口的幂等性。
4、基于唯一索引
一般来讲悲观锁、乐观锁、状态码作用于update操作来实现幂等，而唯一索引是针对install操作来保证幂等。
1） 创建订单时，前端先通过接口获取订单号,再请求后端时带入订单号,订单表中订单号添加唯一索引，如果存在插入相同订单号则直接报错。
2） 消费MQ消息时，messageId是唯一的，我们可以新添加一种消费记录表，将messageId作为主键，如果重复消费那么就会存在相同的messageId，插入直接报错。
5、基于分布式锁
分布式锁实现幂等性的逻辑就是，请求过来时，先去尝试获得分布式锁，如果获得成功，就执行业务逻辑，反之获取失败的话，就舍弃请求直接返回成功。
其实前面介绍过的悲观锁，本质是使用了数据库的分布式锁，都是将多个操作打包成一个原子操作，保证幂等。但由于数据库分布式锁的性能不太好，
我们可以改用：redis或zookeeper来实现分布式锁。
6、基于 Token
token方案的特点就是:需要两次请求才能完成一次业务的操作。
一般包括两个请求阶段：
1）客户端请求申请获取token，服务端生成token返回。
2）第二次请求带着这个token，服务端验证token，完成业务操作。
注意:，在验证token是否存在，不要用redis.get(token)之后，在用redis.del(token)，这样不是原子操作在高并发情况下依然会存在幂等问题。
我们可以直接用redis.del(token)的方式：
redis> SET key1 "Hello"
OK
redis> SET key2 "World"
OK
redis> DEL key1 key2 key3
(integer) 2
redis>
我们看返回是否大于0，就知道是否有数据了，而且因为redis命令操作是单线程的，所以不会出现同时返回1，所以是能够保证幂等的。
这种方式最大的缺点需要两次请求，其实简单点我们可以进行一次请求，那就是前端生成唯一token，而不通过后端获取。
Setnx 命令
在指定的 key 不存在时，为 key 设置指定的值。设置成功，返回1。 设置失败，返回 0。
实例
redis> EXISTS job -- job 不存在
(integer) 0
redis> SETNX job "programmer" -- job 设置成功
(integer) 1
redis> SETNX job "code-farmer" -- 尝试覆盖 job ，失败
(integer) 0
redis> GET job -- 没有被覆盖
"programmer"
如果返回1则说明第一次请求，如果返回0则说明不是第一次请求，直接返回。
这里需要注意的是Setnx命令key值不会自动过期的，所以不清除会一直占用内存，我们可以借助Expire命令来设置有效时间。
redis> SETNX mykey "programmer" -- job 设置成功
(integer) 1
-- 如果设置成功，那么设置将该键的超时设置为 10 秒
redis> expire mykey 10
声明: 公众号如需转载该篇文章,发表文章的头部一定要 告知是转至公众号: 后端元宇宙。同时也可以问本人要markdown原稿和原图片。其它情况一律禁止转载！
