SpringBoot - 如何实现接口幂等性？

以你之姓@ 2023-10-08 15:47 24阅读 0赞

#### 1. 什么是幂等性？ ####

幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

1.  幂等不仅仅只是一次请求对资源没有副作用（如查询操作，对数据没有增删改，因此没有对数据库有任何影响）；
2.  幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用；
3.  幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。

#### 2. 什么是接口幂等性？ ####

幂等性的定义:HTTP/1.1中对幂等性的定义是：Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.  
它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。这里的副作用是不会对结果产生破坏或不可预料的结果，也就是说，其任意多次请求对资源本身所产生的影响均与一次执行的影响相同。

#### 3. 防重和幂等的区别？ ####

重复，重复提交是在第一次请求已经成功的情况下，人为的进行多次操作，导致不满足幂等要求的服务多次改变状态的现象。  
幂等，幂等是第一次请求并不知道结果的情况下，发起多次请求却不会因多次请求而出现多次改变状态的现象。

#### 4. 什么场景应该保证幂等性？ ####

以SQL为例进行说明：

SELECT * FROM USER WHER ID = 1；            // 无论执行多少次重复请求，都不会改变状态，是天然的幂等。
    UPDATE USER SET STATE =  1 WHERE ID = 1；   // 无论执行多少次重复请求，都不会改变状态，也是幂等操作。
    UPDATE USER SET AGE = AGE + 1 WHERE ID = 1；// 每次执行的结果都会发生变化，这种就不是幂等的。

#### 5. 为什么要保证幂等？ ####

1.  防止前端重复提交表单；
2.  防止用户恶意发送请求；
3.  防止接口超时重复提交；
4.  防止消息出现重复消费。

#### 6. 幂等有什么的不足? ####

幂等是为了简化客户端逻辑处理，却增加了服务提供者的逻辑和成本，因此除了业务上的特殊要求外，尽量不提供幂等的接口，主要原因如下：

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

#### 7. 如何保证幂等？ ####

幂等，可以通过唯一的业务单号来保证。也就是说相同的业务单号，无论请求多少次认为是同一笔业务，相同的业务单号的处理逻辑和执行效果是一致的。

#### 8. RESTful API 接口的幂等性 ####

<table> 
 <thead> 
  <tr> 
   <th>HTTP动词</th> 
   <th>是否幂等</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>GET</td> 
   <td>是</td> 
   <td>一般用于查询，每个请求都不会改变状态，是幂等的</td> 
  </tr> 
  <tr> 
   <td>POST</td> 
   <td>否</td> 
   <td>一般用于新增，在DB没有主键校验的情况下，每个请求都会新增数据，不是幂等的</td> 
  </tr> 
  <tr> 
   <td>PUT</td> 
   <td>/</td> 
   <td>一般用于修改操作，需要根据具体的业务判断</td> 
  </tr> 
  <tr> 
   <td>PATCH</td> 
   <td>/</td> 
   <td>一般用于修改操作，需要根据具体的业务判断</td> 
  </tr> 
  <tr> 
   <td>DELETE</td> 
   <td>/</td> 
   <td>一般用于删除操作，需要根据具体的业务判断</td> 
  </tr> 
 </tbody> 
</table>

#### 9. 幂等方案(防重令牌)的原理 ####

![在这里插入图片描述][6c47e4a2132643bf81a8a706dbf7911f.png]

###### ①. 服务端提供获取TOKEN的接口； ######

###### ②. 客户端向服务端发起请求前，第一步先获取TOKEN，将该TOKEN存入REDIS后并将TOKEN返回给客户端； ######

###### ③. 第二步，客户端在HEADER中携带该TOKEN向服务端发起业务请求； ######

###### ④. 服务端接收请求从HEADER中解析TOKEN，并在REDIS中查找该TOKEN； ######

###### ⑤. 如果TOKEN存在，则删掉该TOKEN，继续执行下面的业务操作； ######

###### ⑥. 如果TOKEN不存在，说明第一次请求已将TOKEN删除，当前的请求并不是第一次请求，则返回重复操作的信息。 ######

[6c47e4a2132643bf81a8a706dbf7911f.png]: https://img-blog.csdnimg.cn/6c47e4a2132643bf81a8a706dbf7911f.png