接口幂等性

一、幂等性的意义

1、什么是幂等性

看一下维基百科怎么说的：

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用；比如说支付场景，用户购买了商品支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条…，这就没有保证接口的幂等性。

幂等是一个数学与计算机学概念，在数学中某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同。
在计算机中编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

2、什么是接口幂等性

在HTTP/1.1中，对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

3、为什么需要实现幂等性

在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：

前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
用户恶意进行刷单： 例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
接口超时重复提交： 很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。

4、引入幂等性后对系统的影响

幂等性是为了简化客户端逻辑处理，能放置重复提交等操作，但却增加了服务端的逻辑复杂性和成本，其主要是：

把并行执行的功能改为串行执行，降低了执行效率。
增加了额外控制幂等的业务逻辑，复杂化了业务功能；

所以在使用时候需要考虑是否引入幂等性的必要性，根据实际业务场景具体分析，除了业务上的特殊要求外，一般情况下不需要引入的接口幂等性。

二、Restful API 接口的幂等性

现在流行的 Restful 推荐的几种 HTTP 接口方法中，分别存在幂等行与不能保证幂等的方法，如下：

√ 满足幂等
x 不满足幂等
- 可能满足也可能不满足幂等，根据实际业务逻辑有关

Get
√
Get 方法用于获取资源。其一般不会也不应当对系统资源进行改变，所以是幂等的。

Post
×
Post 方法一般用于创建新的资源。其每次执行都会新增数据，所以不是幂等的。

Put
-
Put 方法一般用于修改资源。该操作则分情况来判断是不是满足幂等，更新操作中直接根据某个值进行更新，也能保持幂等。不过执行累加操作的更新是非幂等。

Delete
-
Delete 方法一般用于删除资源。该操作则分情况来判断是不是满足幂等，当根据唯一值进行删除时，删除同一个数据多次执行效果一样。不过需要注意，带查询条件的删除则就不一定满足幂等了。例如在根据条件删除一批数据后，这时候新增加了一条数据也满足条件，然后又执行了一次删除，那么将会导致新增加的这条满足条件数据也被删除。

三、哪些情况需要防止

用户多次点击按钮
用户页面回退再次提交
微服务互相调用，由于网络问题，导致请求失败。feign 触发重试机制其他业务情况

1、前端重复提交

用户注册，用户创建商品等操作，前端都会提交一些数据给后台服务，后台需要根据用户提交的数据在数据库中创建记录。如果用户不小心多点了几次，后端收到了好几次提交，这时就会在数据库中重复创建了多条记录。这就是接口没有幂等性带来的 bug。

2、接口超时重试

对于给第三方调用的接口，有可能会因为网络原因而调用失败，这时，一般在设计的时候会对接口调用加上失败重试的机制。如果第一次调用已经执行了一半时，发生了网络异常。这时再次调用时就会因为脏数据的存在而出现调用异常。

3、消息重复消费

在使用消息中间件来处理消息队列，且手动 ack 确认消息被正常消费时。如果消费者突然断开连接，那么已经执行了一半的消息会重新放回队列。
当消息被其他消费者重新消费时，如果没有幂等性，就会导致消息重复消费时结果异常，如数据库重复数据，数据库数据冲突，资源重复等。

四、什么情况下需要幂等

以 SQL 为例，有些操作是天然幂等的。

SELECT * FROM table WHER id=?，无论执行多少次都不会改变状态，是天然的幂等。
UPDATE tab1 SET col1=1 WHERE col2=2，无论执行成功多少次状态都是一致的，也是幂等操作。
delete from user where userid=1，多次操作，结果一样，具备幂等性
insert into user(userid,name) values(1,'a') 如 userid 为唯一主键，即重复操作上面的业务，只会插入一条用户数据，具备幂等性。

UPDATE tab1 SET col1=col1+1 WHERE col2=2，每次执行的结果都会发生变化，不是幂等的。
insert into user(userid,name) values(1,'a') 如 userid 不是主键，可以重复，那上面业务多次操作，数据都会新增多条，不具备幂等性。

五、幂等解决方案

1、token 机制

1、服务端提供了发送 token 的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取 token，服务器会把 token 保存到 redis 中。
2、然后调用业务接口请求时，把 token 携带过去，一般放在请求头部。
3、服务器判断 token 是否存在 redis 中，存在表示第一次请求，然后删除 token,继续执行业务。
4、如果判断 token 不存在 redis 中，就表示是重复操作，直接返回重复标记给 client，这样就保证了业务代码，不被重复执行。
危险性：
- 1、先删除 token 还是后删除 token；
  - (1)、先删除可能导致，业务确实没有执行，重试还带上之前 token，由于防重设计导致，请求还是不能执行。
  - (2)、后删除可能导致，业务处理成功，但是服务闪断，出现超时，没有删除 token，别人继续重试，导致业务被执行两边
  - (3)、我们最好设计为先删除 token，如果业务调用失败，就重新获取 token 再次请求。
- 2、Token 获取、比较和删除必须是原子性
  - (1)、redis.get(token) 、token.equals、redis.del(token)如果这两个操作不是原子，可能导致，高并发下，都 get 到同样的数据，判断都成功，继续业务并发执行
  - (2)、可以在 redis 使用 lua 脚本完成这个操作
  shell
```
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
```

通过token 机制实现接口的幂等性,这是一种比较通用性的实现方法。
示意图如下：
具体流程步骤：
1客户端会先发送一个请求去获取 token，服务端会生成一个全局唯一的 ID 作为 token 保存在 redis 中，同时把这个 ID 返回给客户端
2客户端第二次调用业务请求的时候必须携带这个 token
3服务端会校验这个 token，如果校验成功，则执行业务，并删除 redis 中的 token
4如果校验失败，说明 redis 中已经没有对应的 token，则表示重复操作，直接返回指定的结果给客户端
注意：
1对 redis 中是否存在 token 以及删除的代码逻辑建议用 Lua 脚本实现，保证原子性
2全局唯一 ID 可以用百度的 uid-generator、美团的 Leaf 去生成

2、各种锁机制

1）、数据库悲观锁

select * from xxxx where id = 1 for update; 悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，需要根据实际情况选用。另外要注意的是，id 字段一定是主键或者唯一索引，不然可能造成锁表的结果，处理起来会非常麻烦。

2）、数据库乐观锁

这种方法适合在更新的场景中：

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

根据 version 版本，也就是在操作库存前先获取当前商品的 version 版本号，然后操作的时候带上此 version 号。我们梳理下，我们第一次操作库存时，得到 version 为 1，调用库存服务version 变成了 2；但返回给订单服务出现了问题，订单服务又一次发起调用库存服务，当订单服务传如的 version 还是 1，再执行上面的 sql 语句时，就不会执行；因为 version 已经变为 2 了，where 条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。
乐观锁主要使用于处理读多写少的问题

3）、业务层分布式锁

如果多个机器可能在同一时间同时处理相同的数据，比如多台机器定时任务都拿到了相同数据处理，我们就可以加分布式锁，锁定此数据，处理完成后释放锁。获取到锁的必须先判断这个数据是否被处理过。

3、各种唯一约束

1）、数据库唯一约束

插入数据，应该按照唯一索引进行插入，比如订单号，相同的订单就不可能有两条记录插入。我们在数据库层面防止重复。
这个机制是利用了数据库的主键唯一约束的特性，解决了在 insert 场景时幂等问题。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键。
如果是分库分表场景下，路由规则要保证相同请求下，落地在同一个数据库和同一表中，要不然数据库主键约束就不起效果了，因为是不同的数据库和表主键不相关。

这种实现方式是利用 mysql 唯一索引的特性。
示意图如下：
具体流程步骤：
1建立一张去重表，其中某个字段需要建立唯一索引
2客户端去请求服务端，服务端会将这次请求的一些信息插入这张去重表中
3因为表中某个字段带有唯一索引，如果插入成功，证明表中没有这次请求的信息，则执行后续的业务逻辑
4如果插入失败，则代表已经执行过当前请求，直接返回

2）、redis set 防重

很多数据需要处理，只能被处理一次，比如我们可以计算数据的 MD5 将其放入 redis 的 set，每次处理数据，先看这个 MD5 是否已经存在，存在就不处理。

这种实现方式是基于 SETNX 命令实现的
SETNX key value：将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作。
该命令在设置成功时返回 1，设置失败时返回 0。
示意图如下：
具体流程步骤：
1客户端先请求服务端，会拿到一个能代表这次请求业务的唯一字段
2将该字段以 SETNX 的方式存入 redis 中，并根据业务设置相应的超时时间
3如果设置成功，证明这是第一次请求，则执行后续的业务逻辑
4如果设置失败，则代表已经执行过当前请求，直接返回

4、防重表

使用订单号 orderNo 做为去重表的唯一索引，把唯一索引插入去重表，再进行业务操作，且他们在同一个事务中。这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。这里要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性。
之前说的 redis 防重也算

5、全局请求唯一 id

调用接口时，生成一个唯一 id，redis 将数据保存到集合中（去重），存在即处理过。
可以使用 nginx 设置每一个请求的唯一 id；
proxy_set_header X-Request-Id $request_id;

6、总结

这几种实现幂等的方式其实都是大同小异的，类似的还有使用状态机、悲观锁、乐观锁的方式来实现，都是比较简单的。
总之，当你去设计一个接口的时候，幂等都是首要考虑的问题，特别是当你负责设计转账、支付这种涉及到 money 的接口，你要格外注意喽！

六、如何实现幂等性

方案一：数据库唯一主键

方案描述

数据库唯一主键的实现主要是利用数据库中主键唯一约束的特性，一般来说唯一主键比较适用于“插入”时的幂等性，其能保证一张表中只能存在一条带该唯一主键的记录。

使用数据库唯一主键完成幂等性时需要注意的是，该主键一般来说并不是使用数据库中自增主键，而是使用分布式 ID 充当主键（可以参考 Java 中分布式 ID 的设计方案这篇文章），这样才能能保证在分布式环境下 ID 的全局唯一性。

适用操作：

插入操作
删除操作

使用限制：

需要生成全局唯一主键 ID；

主要流程：

主要流程：

① 客户端执行创建请求，调用服务端接口。
② 服务端执行业务逻辑，生成一个分布式 ID，将该 ID 充当待插入数据的主键，然后执数据插入操作，运行对应的 SQL 语句。
③ 服务端将该条数据插入数据库中，如果插入成功则表示没有重复调用接口。如果抛出主键重复异常，则表示数据库中已经存在该条记录，返回错误信息到客户端。

方案二：数据库乐观锁

方案描述：

数据库乐观锁方案一般只能适用于执行“更新操作”的过程，我们可以提前在对应的数据表中多添加一个字段，充当当前数据的版本标识。这样每次对该数据库该表的这条数据执行更新时，都会将该版本标识作为一个条件，值为上次待更新数据中的版本标识的值。

适用操作：

更新操作

使用限制：

需要数据库对应业务表中添加额外字段；

描述示例：

例如，存在如下的数据表中：

小米手机

1000

苹果手机

2500

华为手机

1600

为了每次执行更新时防止重复更新，确定更新的一定是要更新的内容，我们通常都会添加一个 version 字段记录当前的记录版本，这样在更新时候将该值带上，那么只要执行更新操作就能确定一定更新的是某个对应版本下的信息。

小米手机

1000

苹果手机

2500

华为手机

1600

这样每次执行更新时候，都要指定要更新的版本号，如下操作就能准确更新 version=5 的信息：
UPDATE my_table SET price=price+50,version=version+1 WHERE id=1 AND version=5
上面 WHERE 后面跟着条件 id=1 AND version=5 被执行后，id=1 的 version 被更新为 6，所以如果重复执行该条 SQL 语句将不生效，因为 id=1 AND version=5 的数据已经不存在，这样就能保住更新的幂等，多次更新对结果不会产生影响。

方案三：防重 Token 令牌

方案描述：

针对客户端连续点击或者调用方的超时重试等情况，例如提交订单，此种操作就可以用 Token 的机制实现防止重复提交。简单的说就是调用方在调用接口的时候先向后端请求一个全局 ID（Token），请求的时候携带这个全局 ID 一起请求（Token 最好将其放到 Headers 中），后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息，这样来保证幂等操作。

适用操作：

插入操作
更新操作
删除操作

使用限制：

需要生成全局唯一 Token 串；
需要使用第三方组件 Redis 进行数据效验；

主要流程：

① 服务端提供获取 Token 的接口，该 Token 可以是一个序列号，也可以是一个分布式 ID 或者 UUID 串。
② 客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。
③ 然后将该串存入 Redis 数据库中，以该 Token 作为 Redis 的键（注意设置过期时间）。
④ 将 Token 返回到客户端，客户端拿到后应存到表单隐藏域中。
⑤ 客户端在执行提交表单时，把 Token 存入到 Headers 中，执行业务请求带上该 Headers。
⑥ 服务端接收到请求后从 Headers 中拿到 Token，然后根据 Token 到 Redis 中查找该 key 是否存在。
⑦ 服务端根据 Redis 中是否存该 key 进行判断，如果存在就将该 key 删除，然后正常执行业务逻辑。如果不存在就抛异常，返回重复提交的错误信息。

注意，在并发情况下，执行 Redis 查找数据与删除需要保证原子性，否则很可能在并发下无法保证幂等性。其实现方法可以使用分布式锁或者使用 Lua 表达式来注销查询与删除操作。

方案四、下游传递唯一序列号

方案描述：

所谓请求序列号，其实就是每次向服务端请求时候附带一个短时间内唯一不重复的序列号，该序列号可以是一个有序 ID，也可以是一个订单号，一般由下游生成，在调用上游服务端接口时附加该序列号和用于认证的 ID。
当上游服务器收到请求信息后拿取该序列号和下游认证ID 进行组合，形成用于操作 Redis 的 Key，然后到 Redis 中查询是否存在对应的 Key 的键值对，根据其结果：
1. 如果存在，就说明已经对该下游的该序列号的请求进行了业务处理，这时可以直接响应重复请求的错误信息。
2. 如果不存在，就以该 Key 作为 Redis 的键，以下游关键信息作为存储的值（例如下游商传递的一些业务逻辑信息），将该键值对存储到 Redis 中，然后再正常执行对应的业务逻辑即可。

适用操作：

插入操作
更新操作
删除操作

使用限制：

要求第三方传递唯一序列号；
需要使用第三方组件 Redis 进行数据效验；

主要流程：

主要步骤：

① 下游服务生成分布式 ID 作为序列号，然后执行请求调用上游接口，并附带“唯一序列号”与请求的“认证凭据ID”。
② 上游服务进行安全效验，检测下游传递的参数中是否存在“序列号”和“凭据ID”。
③ 上游服务到 Redis 中检测是否存在对应的“序列号”与“认证ID”组成的 Key，如果存在就抛出重复执行的异常信息，然后响应下游对应的错误信息。如果不存在就以该“序列号”和“认证ID”组合作为 Key，以下游关键信息作为 Value，进而存储到 Redis 中，然后正常执行接来来的业务逻辑。

上面步骤中插入数据到 Redis 一定要设置过期时间。这样能保证在这个时间范围内，如果重复调用接口，则能够进行判断识别。如果不设置过期时间，很可能导致数据无限量的存入 Redis，致使 Redis 不能正常工作。

七、在项目中实现接口幂等

这里使用防重 Token 令牌方案，该方案能保证在不同请求动作下的幂等性，实现逻辑可以看上面写的”防重 Token 令牌”方案，接下来写下实现这个逻辑的代码。

1、Maven 引入相关依赖

这里使用 Maven 工具管理依赖，这里在 pom.xml 中引入 SpringBoot、Redis、lombok 相关依赖。

xml

	<!--springboot web-->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <!--springboot data redis-->
    <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>

	<!--lombok-->
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
    </dependency>

2、配置连接 Redis 的参数

在 application 配置文件中配置连接 Redis 的参数。Spring Boot 基础就不介绍了，最新教程推荐看下面的教程。

properties

spring.redis.host=192.168.10.103
spring.redis.port=6379

3、创建与验证 Token

创建用于操作 Token 相关的 Service 类，里面存在 Token 创建与验证方法，其中：

Token 创建方法： 使用 UUID 工具创建 Token 串，设置以 “order:token:“+“Token串” 作为 Key，以用户id当成 Value，将信息存入 Redis 中。
Token 验证方法： 接收 Token 串参数，加上 Key 前缀形成 Key，再传入 value 值，执行 Lua 表达式（Lua 表达式能保证命令执行的原子性）进行查找对应 Key 与删除操作。执行完成后验证命令的返回结果，如果结果不为空且非0，则验证成功，否则失败。

java

/**
 * 订单确认页返回需要用到的数据
 *
 * @return
 */
@Override
public OrderConfirmVo confirmOrder() throws ExecutionException, InterruptedException {
    ...
    //todo 5、防重令牌
    String token = UUID.randomUUID().toString().replace("-", "");
    //给服务器一个令牌
    redisTemplate.opsForValue().set(OrderConstant.USER_ORDER_TOKEN_PREFIX + 		             memberRespVo.getId(), token, 30, TimeUnit.MINUTES);
    //给页面一个令牌
    confirmVo.setOrderToken(token);
    ...
}

java

/**
 * 下单
 */
@Transactional
@Override
public SubmitOrderResponseVo submitOrder(OrderSubmitVo vo) {
    ...
    //1、验证令牌【令牌的对比和删除必须保证原子性】
    //0令牌失败 - 1删除成功(校验成功)
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    String orderToken = vo.getOrderToken();
    //原子验证令牌和删除令牌
    Long result = redisTemplate.execute(
                //脚本返回类型->0,1
                new DefaultRedisScript<Long>(script, Long.class),
                //将缓存中将要比对的key转为集合
                Arrays.asList(OrderConstant.USER_ORDER_TOKEN_PREFIX + memberRespVo.getId()),
                //传入要校验的值
                orderToken);
    if (result == 0L) {
        //验证失败，设置错误状态码为1，key过期等情况
        responseVo.setCode(1);
        return responseVo;
    } else {
        //验证成功
        ...
    }
}

八、最后总结

幂等性是开发当中很常见也很重要的一个需求，尤其是支付、订单等与金钱挂钩的服务，保证接口幂等性尤其重要。在实际开发中，我们需要针对不同的业务场景我们需要灵活的选择幂等性的实现方式：

对于下单等存在唯一主键的，可以使用“唯一主键方案”的方式实现。
对于更新订单状态等相关的更新场景操作，使用“乐观锁方案”实现更为简单。
对于上下游这种，下游请求上游，上游服务可以使用“下游传递唯一序列号方案”更为合理。
类似于前端重复提交、重复下单、没有唯一ID号的场景，可以通过 Token 与 Redis 配合的“防重 Token 方案”实现更为快捷。

上面只是给与一些建议，再次强调一下，实现幂等性需要先理解自身业务需求，根据业务逻辑来实现这样才合理，处理好其中的每一个结点细节，完善整体的业务流程设计，才能更好的保证系统的正常运行。最后做一个简单总结

数据库唯一主键
插入操作删除操作
简单
- 只能用于插入操作；- 只能用于存在唯一主键场景；

数据库乐观锁
更新操作
简单
- 只能用于更新操作；- 表中需要额外添加字段；

请求序列号
插入操作更新操作删除操作
简单
- 需要保证下游生成唯一序列号；- 需要 Redis 第三方存储已经请求的序列号；

防重 Token 令牌
插入操作更新操作删除操作
适中
- 需要 Redis 第三方存储生成的 Token 串；

To Be Continued.

一、幂等性的意义 ​

1、什么是幂等性 ​

2、什么是接口幂等性 ​

3、为什么需要实现幂等性 ​

4、引入幂等性后对系统的影响 ​

二、Restful API 接口的幂等性 ​

三、哪些情况需要防止 ​

1、前端重复提交 ​

2、接口超时重试 ​

3、消息重复消费 ​

四、什么情况下需要幂等 ​

五、幂等解决方案 ​

1、token 机制 ​

2、各种锁机制 ​

1）、数据库悲观锁 ​

2）、数据库乐观锁 ​

3）、业务层分布式锁 ​

3、各种唯一约束 ​

1）、数据库唯一约束 ​

2）、redis set 防重 ​

4、防重表 ​

5、全局请求唯一 id ​

6、总结 ​

六、如何实现幂等性 ​

方案一：数据库唯一主键 ​

方案二：数据库乐观锁 ​

方案三：防重 Token 令牌 ​

方案四、下游传递唯一序列号 ​

七、在项目中实现接口幂等 ​

1、Maven 引入相关依赖 ​

2、配置连接 Redis 的参数 ​

3、创建与验证 Token ​

八、最后总结 ​

一、幂等性的意义

1、什么是幂等性

2、什么是接口幂等性

3、为什么需要实现幂等性

4、引入幂等性后对系统的影响

二、Restful API 接口的幂等性

三、哪些情况需要防止

1、前端重复提交

2、接口超时重试

3、消息重复消费

四、什么情况下需要幂等

五、幂等解决方案

1、token 机制

2、各种锁机制

1）、数据库悲观锁

2）、数据库乐观锁

3）、业务层分布式锁

3、各种唯一约束

1）、数据库唯一约束

2）、redis set 防重

4、防重表

5、全局请求唯一 id

6、总结

六、如何实现幂等性

方案一：数据库唯一主键

方案二：数据库乐观锁

方案三：防重 Token 令牌

方案四、下游传递唯一序列号

七、在项目中实现接口幂等

1、Maven 引入相关依赖

2、配置连接 Redis 的参数

3、创建与验证 Token

八、最后总结