SpringBoot实现接口幂等性的4种方案

一、什么是幂等性

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

二、什么是接口幂等性

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

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

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

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

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

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

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

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

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

五、Restful API 接口的幂等性

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

  • √满足幂等
  • x不满足幂等
  • -可能满足也可能不满足幂等,根据实际业务逻辑有关
方法类型 是否幂等 描述
Get Get 方法用于获取资源。其一般不会也不应当对系统资源进行改变,所以是幂等的。
Post × Post 方法一般用于创建新的资源。其每次执行都会新增数据,所以不是幂等的。
Put - Put 方法一般用于修改资源。该操作则分情况来判断是不是满足幂等,更新操作中直接根据某个值进行更新,也能保持幂等。不过执行累加操作的更新是非幂等。
Delete - Delete 方法一般用于删除资源。该操作则分情况来判断是不是满足幂等,当根据唯一值进行删除时,删除同一个数据多次执行效果一样。不过需要注意,带查询条件的删除则就不一定满足幂等了。例如在根据条件删除一批数据后,这时候新增加了一条数据也满足条件,然后又执行了一次删除,那么将会导致新增加的这条满足条件数据也被删除。

六、如何实现幂等性

方案一:数据库唯一主键

方案描述

数据库唯一主键的实现主要是利用数据库中主键唯一约束的特性,一般来说唯一主键比较适用于“插入”时的幂等性,其能保证一张表中只能存在一条带该唯一主键的记录。
使用数据库唯一主键完成幂等性时需要注意的是,该主键一般来说并不是使用数据库中自增主键,而是使用分布式 ID 充当主键(可以参考 Java 中分布式 ID 的设计方案 这篇文章),这样才能能保证在分布式环境下 ID 的全局唯一性。
适用操作:

  • 插入操作
  • 删除操作

使用限制:

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

主要流程:

主要流程:

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

方案二:数据库乐观锁

方案描述:

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

适用操作:

  • 更新操作

使用限制:

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

描述示例:

例如,存在如下的数据表中:

id name price
1 小米手机 1000
2 苹果手机 2500
3 华为手机 1600

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

id name price version
1 小米手机 1000 10
2 苹果手机 2500 21
3 华为手机 1600 5

这样每次执行更新时候,都要指定要更新的版本号,如下操作就能准确更新 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 的键值对,根据其结果:

  • 如果存在,就说明已经对该下游的该序列号的请求进行了业务处理,这时可以直接响应重复请求的错误信息。
  • 如果不存在,就以该 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 version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.3.4.RELEASE</version>
 </parent>

 <groupId>mydlq.club</groupId>
 <artifactId>springboot-idempotent-token</artifactId>
 <version>0.0.1</version>
 <name>springboot-idempotent-token</name>
 <description>Idempotent Demo</description>

 <properties>
  <java.version>1.8</java.version>
 </properties>

 <dependencies>
  <!--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>
  <dependency>
   <groupId>org.apache.commons</groupId>
   <artifactId>commons-pool2</artifactId>
  </dependency>
  <!--lombok-->
  <dependency>
   <groupId>org.projectlombok</groupId>
   <artifactId>lombok</artifactId>
  </dependency>
 </dependencies>

 <build>
  <plugins>
   <plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
   </plugin>
  </plugins>
 </build>
</project>

2、配置连接 Redis 的参数

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

如下:

spring:
 redis:
 ssl: false
 host: 127.0.0.1
 port: 6379
 database: 0
 timeout: 1000
 password:
 lettuce:
  pool:
  max-active: 100
  max-wait: -1
  min-idle: 0
  max-idle: 20

3、创建与验证 Token 工具类

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

  • Token 创建方法: 使用 UUID 工具创建 Token 串,设置以 “idempotent_token:“+“Token串” 作为 Key,以用户信息当成 Value,将信息存入 Redis 中。
  • Token 验证方法: 接收 Token 串参数,加上 Key 前缀形成 Key,再传入 value 值,执行 Lua 表达式(Lua 表达式能保证命令执行的原子性)进行查找对应 Key 与删除操作。执行完成后验证命令的返回结果,如果结果不为空且非0,则验证成功,否则失败。
import java.util.Arrays;
import java.util.UUID;
import java.util.concurrent.TimeUnit;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.data.redis.core.script.RedisScript;
import org.springframework.stereotype.Service;

@Slf4j
@Service
public class TokenUtilService {

 @Autowired
 private StringRedisTemplate redisTemplate;

 /**
  * 存入 Redis 的 Token 键的前缀
  */
 private static final String IDEMPOTENT_TOKEN_PREFIX = "idempotent_token:";

 /**
  * 创建 Token 存入 Redis,并返回该 Token
  *
  * @param value 用于辅助验证的 value 值
  * @return 生成的 Token 串
  */
 public String generateToken(String value) {
  // 实例化生成 ID 工具对象
  String token = UUID.randomUUID().toString();
  // 设置存入 Redis 的 Key
  String key = IDEMPOTENT_TOKEN_PREFIX + token;
  // 存储 Token 到 Redis,且设置过期时间为5分钟
  redisTemplate.opsForValue().set(key, value, 5, TimeUnit.MINUTES);
  // 返回 Token
  return token;
 }

 /**
  * 验证 Token 正确性
  *
  * @param token token 字符串
  * @param value value 存储在Redis中的辅助验证信息
  * @return 验证结果
  */
 public boolean validToken(String token, String value) {
  // 设置 Lua 脚本,其中 KEYS[1] 是 key,KEYS[2] 是 value
  String script = "if redis.call('get', KEYS[1]) == KEYS[2] then return redis.call('del', KEYS[1]) else return 0 end";
  RedisScript<Long> redisScript = new DefaultRedisScript<>(script, Long.class);
  // 根据 Key 前缀拼接 Key
  String key = IDEMPOTENT_TOKEN_PREFIX + token;
  // 执行 Lua 脚本
  Long result = redisTemplate.execute(redisScript, Arrays.asList(key, value));
  // 根据返回结果判断是否成功成功匹配并删除 Redis 键值对,若果结果不为空和0,则验证通过
  if (result != null && result != 0L) {
   log.info("验证 token={},key={},value={} 成功", token, key, value);
   return true;
  }
  log.info("验证 token={},key={},value={} 失败", token, key, value);
  return false;
 }
}

4、创建测试的 Controller 类

创建用于测试的 Controller 类,里面有获取 Token 与测试接口幂等性的接口,内容如下:

import lombok.extern.slf4j.Slf4j;
import mydlq.club.example.service.TokenUtilService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

@Slf4j
@RestController
public class TokenController {

 @Autowired
 private TokenUtilService tokenService;

 /**
  * 获取 Token 接口
  *
  * @return Token 串
  */
 @GetMapping("/token")
 public String getToken() {
  // 获取用户信息(这里使用模拟数据)
  // 注:这里存储该内容只是举例,其作用为辅助验证,使其验证逻辑更安全,如这里存储用户信息,其目的为:
  // - 1)、使用"token"验证 Redis 中是否存在对应的 Key
  // - 2)、使用"用户信息"验证 Redis 的 Value 是否匹配。
  String userInfo = "mydlq";
  // 获取 Token 字符串,并返回
  return tokenService.generateToken(userInfo);
 }

 /**
  * 接口幂等性测试接口
  *
  * @param token 幂等 Token 串
  * @return 执行结果
  */
 @PostMapping("/test")
 public String test(@RequestHeader(value = "token") String token) {
  // 获取用户信息(这里使用模拟数据)
  String userInfo = "mydlq";
  // 根据 Token 和与用户相关的信息到 Redis 验证是否存在对应的信息
  boolean result = tokenService.validToken(token, userInfo);
  // 根据验证结果响应不同信息
  return result ? "正常调用" : "重复调用";
 }
}

5、创建 SpringBoot 启动类

创建启动类,用于启动 SpringBoot 应用。基础教程就不介绍了,建议看下下面的教程,很全了。

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {

 public static void main(String[] args) {
  SpringApplication.run(Application.class, args);
 }

}

6、写测试类进行测试

写个测试类进行测试,多次访问同一个接口,测试是否只有第一次能否执行成功。

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.MediaType;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.request.MockMvcRequestBuilders;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;

@Slf4j
@SpringBootTest
@RunWith(SpringRunner.class)
public class IdempotenceTest {

 @Autowired
 private WebApplicationContext webApplicationContext;

 @Test
 public void interfaceIdempotenceTest() throws Exception {
  // 初始化 MockMvc
  MockMvc mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();
  // 调用获取 Token 接口
  String token = mockMvc.perform(MockMvcRequestBuilders.get("/token")
    .accept(MediaType.TEXT_HTML))
    .andReturn()
    .getResponse().getContentAsString();
  log.info("获取的 Token 串:{}", token);
  // 循环调用 5 次进行测试
  for (int i = 1; i <= 5; i++) {
   log.info("第{}次调用测试接口", i);
   // 调用验证接口并打印结果
   String result = mockMvc.perform(MockMvcRequestBuilders.post("/test")
     .header("token", token)
     .accept(MediaType.TEXT_HTML))
     .andReturn().getResponse().getContentAsString();
   log.info(result);
   // 结果断言
   if (i == 0) {
    Assert.assertEquals(result, "正常调用");
   } else {
    Assert.assertEquals(result, "重复调用");
   }
  }
 }

}

显示如下:
[main] IdempotenceTest:  获取的 Token 串:980ea707-ce2e-456e-a059-0a03332110b4
[main] IdempotenceTest:  第1次调用测试接口
[main] IdempotenceTest:  正常调用
[main] IdempotenceTest:  第2次调用测试接口
[main] IdempotenceTest:  重复调用
[main] IdempotenceTest:  第3次调用测试接口
[main] IdempotenceTest:  重复调用
[main] IdempotenceTest:  第4次调用测试接口
[main] IdempotenceTest:  重复调用
[main] IdempotenceTest:  第5次调用测试接口
[main] IdempotenceTest:  重复调用

八、最后总结

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

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

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

方案名称 适用方法 实现复杂度 方案缺点
数据库唯一主键 插入操作 删除操作 简单 只能用于插入操作;- 只能用于存在唯一主键场景;
数据库乐观锁 更新操作 简单 只能用于更新操作;- 表中需要额外添加字段;
请求序列号 插入操作 更新操作 删除操作 简单 需要保证下游生成唯一序列号;- 需要 Redis 第三方存储已经请求的序列号;
防重 Token 令牌 插入操作 更新操作 删除操作 适中 需要 Redis 第三方存储生成的 Token 串;

到此这篇关于SpringBoot实现接口幂等性的4种方案的文章就介绍到这了,更多相关SpringBoot 接口幂等性内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Springboot+redis+Interceptor+自定义annotation实现接口自动幂等

    前言: 在实际的开发项目中,一个对外暴露的接口往往会面临很多次请求,我们来解释一下幂等的概念:任意多次执行所产生的影响均与一次执行的影响相同.按照这个含义,最终的含义就是对数据库的影响只能是一次性的,不能重复处理.如何保证其幂等性,通常有以下手段: 1:数据库建立唯一性索引,可以保证最终插入数据库的只有一条数据 2:token机制,每次接口请求前先获取一个token,然后再下次请求的时候在请求的header体中加上这个token,后台进行验证,如果验证通过删除token,下次请求再次判断toke

  • Spring Boot接口幂等插件用法示例解析

    幂等概述 幂等性原本是数学上的概念,即使公式:f(x)=f(f(x)) 能够成立的数学性质.用在编程领域,则意为对同一个系统,使用同样的条件,一次请求和重复的多次请求对系统资源的影响是一致的. 幂等性是分布式系统设计中十分重要的概念,具有这一性质的接口在设计时总是秉持这样的一种理念:调用接口发生异常并且重复尝试时,总是会造成系统所无法承受的损失,所以必须阻止这种现象的发生. 实现幂等的方式很多,目前基于请求令牌机制适用范围较广.其核心思想是为每一次操作生成一个唯一性的凭证,也就是 token.一

  • SpringBoot实现接口幂等性的4种方案

    一.什么是幂等性 幂等是一个数学与计算机学概念,在数学中某一元运算为幂等时,其作用在任一元素两次后会和其作用一次的结果相同. 在计算机中编程中,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同.幂等函数或幂等方法是指可以使用相同参数重复执行,并能获得相同结果的函数.这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变. 二.什么是接口幂等性 在HTTP/1.1中,对幂等性进行了定义.它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外),

  • SpringBoot处理接口幂等性的两种方法详解

    目录 1. 接口幂等性实现方案梳理 1.1 基于 Token 1.2 基于请求参数校验 2. 基于请求参数的校验 在上周发布的 TienChin 项目视频中,我和大家一共梳理了六种幂等性解决方案,接口幂等性处理算是一个非常常见的需求了,我们在很多项目中其实都会遇到.今天我们来看看两种比较简单的实现思路. 1. 接口幂等性实现方案梳理 其实接口幂等性的实现方案还是蛮多的,我这里和小伙伴们分享两种比较常见的方案. 1.1 基于 Token 基于 Token 这种方案的实现思路很简单,整个流程分两步:

  • 浅谈Redis处理接口幂等性的两种方案

    目录 一.接口幂等性 1.1.什么是接口幂等性 1.2.为什么需要实现幂等性 1.3.引入幂等性后对系统的影响 二.如何设计幂等 2.1.全局的唯一性ID 2.2.幂等设计的基本流程 三.接口幂等性常见解决方案 3.1.下游传递唯一请求编号 3.2.防重 Token 令牌 参考链接: 前言:接口幂等性问题,对于开发人员来说,是一个跟语言无关的公共问题.对于一些用户请求,在某些情况下是可能重复发送的,如果是查询类操作并无大碍,但其中有些是涉及写入操作的,一旦重复了,可能会导致很严重的后果,例如交易

  • SpringBoot结合Redis实现接口幂等性的示例代码

    目录 介绍 实现过程 引入 maven 依赖 spring 配置文件写入 引入 Redis 自定义注解 token 的创建和实现 拦截器的配置 测试用例 介绍 幂等性的概念是,任意多次执行所产生的影响都与一次执行产生的影响相同,按照这个含义,最终的解释是对数据库的影响只能是一次性的,不能重复处理.手段如下 数据库建立唯一索引 token机制 悲观锁或者是乐观锁 先查询后判断 小小主要带你们介绍Redis实现自动幂等性.其原理如下图所示. 实现过程 引入 maven 依赖 <dependency>

  • Springboot Druid 自定义加密数据库密码的几种方案

    前言 开发过程中,配置的数据库密码通常是明文形式,这样首先第一个安全性不好(相对来说),不符合一个开发规范(如项目中不能出现明文账号密码),其实就是当出现特殊需求时,比如要对非运维人员开方服务器部分权限,但是又涉及项目部署的目录时,容易泄漏数据库密码,虽然一般生产环境中,数据库往往放入内网,访问只能通过内网访问,但是不管怎么说账号密码直接让人知道总归不好,甚至有些项目需要部署到客户环境中,但是可能共用一个公共数据库(数据库只向指定服务器开放外网端口或组建内网环境),这样的情况下,如果数据库密码再

  • Springboot利用Redis实现接口幂等性拦截

    目录 前言 正文 实战开始 核心三件套 工具类三件套 REDIS配置类 前言 近期一个老项目出现了接口幂等性 校验问题,前端加了按钮置灰, 依然被人拉着接口参数一顿输出,还是重复调用了接口,小陈及时赶到现场,通过复制粘贴,完成了后端接口幂等性调用校验. 以前写过一篇关于接口简单限流防止重复调用的,但是跟该篇还是不一样的,该篇的角度是接口和参数整体一致才当做重复. 简单限流:Springboot使用redis实现接口Api限流的实例 该篇内容: 实现接口调用的幂等性校验 方案 :自定义注解+red

  • SpringBoot配置文件中数据库密码加密两种方案(推荐)

    SpringBoot项目经常将连接数据库的密码明文放在配置文件里,安全性就比较低一些,尤其在一些企业对安全性要求很高,因此我们就考虑如何对密码进行加密. 介绍两种加密方式:jasypt 可加密配置文件中所有属性值; druid 自带了加解密,可对数据库密码进行加密. jasypt 加解密 jasypt 是一个简单易用的加解密Java库,可以快速集成到 Spring 项目中.可以快速集成到 Spring Boot 项目中,并提供了自动配置,使用非常简单. 步骤如下: 1)引入maven依赖 <de

  • SpringBoot+Mybatis使用Mapper接口注册的几种方式

    目录 I. 环境准备 1. 数据库准备 2. 项目环境 II. 实例演示 1. 实体类,Mapper类 2. 注册方式 2.1 @MapperScan注册方式 2.2 @Mapper 注册方式 2.3 MapperScannerConfigurer注册方式 3. 小结 III. 不能错过的源码和相关知识点 SpringBoot项目中借助Mybatis来操作数据库,对大部分java技术栈的小伙伴来说,并不会陌生:我们知道,使用mybatis,一般会有下面几个 Entity: 数据库实体类 Mapp

  • Springboot打印接口的三种方式分享

    目录 1 aop切面的方式 1.1 实现思路 1.2 代码实现 1.3 功能测试 2 过滤器的方式 3 拦截器的方式 1 aop切面的方式 1.1 实现思路 引入aop依赖 自定义注解 定义切面,采用环绕通知 1.2 代码实现 1)引入依赖 xml <!--aop--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-

  • SpringBoot父子线程数据传递的五种方案介绍

    目录 方案1.ThreadLocal+TaskDecorator 方案2.RequestContextHolder+TaskDecorator 方案3.MDC+TaskDecorator 方案4.InheritableThreadLocal 方案5.TransmittableThreadLocal 方案对比 简答说一下InheritableThreadLocal 总结 方案1.ThreadLocal+TaskDecorator 用户工具类 UserUtils /** *使用ThreadLocal

随机推荐