关于后端:一口气说出四种幂等性解决方案面试官露出了姨母笑

47次阅读

共计 6841 个字符，预计需要花费 18 分钟才能阅读完成。

什么是幂等性？
幂等是一个数学与计算机学概念，在数学中某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的后果雷同。

在计算机中编程中，一个幂等操作的特点是其任意屡次执行所产生的影响均与一次执行的影响雷同。

幂等函数或幂等办法是指能够应用雷同参数反复执行，并能取得雷同后果的函数。这些函数不会影响零碎状态，也不必放心反复执行会对系统造成扭转。
什么是接口幂等性？
在 HTTP/1.1 中，对幂等性进行了定义。它形容了一次和屡次申请某一个资源对于资源自身应该具备同样的后果（网络超时等问题除外），即第一次申请的时候对资源产生了副作用，然而当前的屡次申请都不会再对资源产生副作用。
这里的副作用是不会对后果产生毁坏或者产生不可意料的后果。也就是说，其任意屡次执行对资源自身所产生的影响均与一次执行的影响雷同。
为什么须要实现幂等性？
在接口调用时个别状况下都能失常返回信息不会反复提交，不过在遇见以下状况时能够就会呈现问题，如：

前端反复提交表单：在填写一些表格时候，用户填写实现提交，很多时候会因网络稳定没有及时对用户做出提交胜利响应，以致用户认为没有胜利提交，而后始终点提交按钮，这时就会产生反复提交表单申请。

用户歹意进行刷单：例如在实现用户投票这种性能时，如果用户针对一个用户进行反复提交投票，这样会导致接口接管到用户反复提交的投票信息，这样会使投票后果与事实重大不符。

接口超时反复提交：很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络稳定超时等造成的申请失败，都会增加重试机制，导致一个申请提交屡次。

音讯进行反复生产：当应用 MQ 消息中间件时候，如果产生消息中间件呈现谬误未及时提交生产信息，导致产生反复生产。

应用幂等性最大的劣势在于使接口保障任何幂等性操作，免去因重试等造成零碎产生的未知的问题。

引入幂等性后对系统有什么影响？
幂等性是为了简化客户端逻辑解决，能搁置反复提交等操作，但却减少了服务端的逻辑复杂性和老本，其次要是：

把并行执行的性能改为串行执行，升高了执行效率。

减少了额定管制幂等的业务逻辑，复杂化了业务性能；

所以在应用时候须要思考是否引入幂等性的必要性，依据理论业务场景具体分析，除了业务上的特殊要求外，个别状况下不须要引入的接口幂等性。
Restful API 接口幂等性如何？
当初风行的 Restful 举荐的几种 HTTP 接口办法中，别离存在幂等行与不能保障幂等的办法，如下：

√ 满足幂等
x 不满足幂等

  • 可能满足也可能不满足幂等，依据理论业务逻辑无关

计划一：数据库惟一主键如何实现幂等性？
数据库惟一主键的实现次要是利用数据库中主键惟一束缚的个性，一般来说惟一主键比拟实用于“插入”时的幂等性，其能保障一张表中只能存在一条带该惟一主键的记录。
应用数据库惟一主键实现幂等性时须要留神的是，该主键一般来说并不是应用数据库中自增主键，而是应用分布式 ID 充当主键，这样能力能保障在分布式环境下 ID 的全局唯一性。
实用操作

插入操作
删除操作

应用限度

须要生成全局惟一主键 ID；

次要流程

次要流程如下：

客户端执行创立申请，调用服务端接口。

服务端执行业务逻辑，生成一个分布式 ID，将该 ID 充当待插入数据的主键，然
后执数据插入操作，运行对应的 SQL 语句。

服务端将该条数据插入数据库中，如果插入胜利则示意没有反复调用接口。如果抛出主键反复异样，则示意数据库中曾经存在该条记录，返回错误信息到客户端。

计划二：数据库乐观锁如何实现幂等性？
数据库乐观锁计划个别只能实用于执行更新操作的过程，咱们能够提前在对应的数据表中多增加一个字段，充当以后数据的版本标识。
这样每次对该数据库该表的这条数据执行更新时，都会将该版本标识作为一个条件，值为上次待更新数据中的版本标识的值。
实用操作

更新操作

应用限度

须要数据库对应业务表中增加额定字段

形容示例

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

为了每次执行更新时避免反复更新，确定更新的肯定是要更新的内容，咱们通常都会增加一个 version 字段记录以后的记录版本，这样在更新时候将该值带上，那么只有执行更新操作就能确定肯定更新的是某个对应版本下的信息。

这样每次执行更新时候，都要指定要更新的版本号，如下操作就能精确更新 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 相干依赖。
    <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>
    复制代码

  2. 配置连贯 Redis 的参数
    在 application 配置文件中配置连贯 Redis 的参数，如下:
    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，则验证胜利，否则失败。

@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 与测试接口幂等性的接口，内容如下：
@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 ? "失常调用" : "反复调用";
}

}
复制代码
最初总结
幂等性是开发当中很常见也很重要的一个需要，尤其是领取、订单等与金钱挂钩的服务，保障接口幂等性尤其重要。在理论开发中，咱们须要针对不同的业务场景咱们须要灵便的抉择幂等性的实现形式：

对于下单等存在惟一主键的，能够应用“惟一主键计划”的形式实现。

对于更新订单状态等相干的更新场景操作，应用“乐观锁计划”实现更为简略。

对于上下游这种，上游申请上游，上游服务能够应用“上游传递惟一序列号计划”更为正当。

相似于前端反复提交、反复下单、没有惟一 ID 号的场景，能够通过 Token 与 Redis 配合的“防重 Token 计划”实现更为快捷。

下面只是给与一些倡议，再次强调一下，实现幂等性须要先了解本身业务需要，依据业务逻辑来实现这样才正当，解决好其中的每一个结点细节，欠缺整体的业务流程设计，能力更好的保证系统的失常运行。最初做一个简略总结，而后本博文到此结束，如下：

正文完
后端
发表至： 后端
2022-12-28
 0
关于后端:proto32语法
关于后端:无需手动输入命令简单3步即可在K8S集群中启用GPU
关于后端:简化你的代码提高生产力这10个Lambda表达式必须掌握
关于后端:量化交易投顾系统源码搭建