实战，实现幂等的8种方案！

首席架构师专栏

于 2024-08-29 10:49:54 发布

阅读量736

点赞数 18

分类专栏：架构师基本功文章标签：架构

本文链接：https://blog.csdn.net/u010020088/article/details/141672896

版权

架构师基本功专栏收录该内容

14 篇文章 3 订阅

订阅专栏

1 什么是幂等

幂等的概念来自数学和计算机科学

数学概念：幂等函数 f(x) = f (f(x)) ，如绝对值函数abs(-5) = abs(abs(-5))
计算机科学：多次请求同同一资源与一次请求的影响是一致的

2 为什么要幂等设计

为什么要幂等设计呢？
我们举个例子：

除了转账的例子，我们日常开发中还会遇到许多其他考虑幂等的例子

A.MQ下游消费系统重复消费的问题
B.前端form表单重复提交的问题

3 接口超时了如何设计
我们在调用下游接口超时的时候该如何处理呢？
一般来讲有两种方案：
方案一：下游系统提供一个查询接口，上游调用超时，调用查询接口，根据查询接口返回的结果做相应的处理

方案二：下游支付中心支持幂等，超时之后，发起重试

4 如何设计幂等

这么多场景需要考虑幂等，那如何设计幂等呢
幂等的核心问题是保持请求的唯一性，那首先要解决的问题是全局唯一性ID

如果使用唯一索引控制幂等，那么唯一索引就是唯一的；
如果使用数据库主键控制幂等，那么主键就是唯一的；
如果使用悲观锁控制幂等，那么底层标志还是全局唯一ID

4.1 全局唯一ID
如UUID、雪花算法（snowflake IDs），UUID的方式简单，但是可读性差，

雪花算法是一种生成分布式全局唯一ID的算法，生成的ID称为Snowflake IDs。这种算法由Twitter创建，并用于推文的ID。

一个snowflake是64位

第一位代表正负，1代表负数、0代表整数，一般ID都是整数，所以默认是0；
接下来的41位是时间戳，自选定日期以来的毫秒数；
接下来的10位代表计算机ID；
最后12位代表这个机器生成的ID序列码，允许在同一毫秒内创建多少个snowflake ID

当然，全局唯一ID还可以使用美团的Leaf，百度的Uidgenerator.

4.2 幂等设计的基本流程

**幂等设计归根结底是过滤一下请求，要过滤请求，必须满足两个条件，全局唯一ID，请求记录被保存，当收到请求时，优先查询请求记录，记录存在则返回结果，不存在则处理请求并记录，然后返回结果。

5 实现幂等设计的8中方案
幂等设计的基本流程都一致，简单概括起来有8中实现方案

5.1 select + Insert + 主键/唯一索引冲突

当请求过来，根据唯一流水号查询请求记录
记录存在直接返回结果
记录不存在，插入记录，记录插入成功，返回结果，插入报主键冲突，根据已经插入的记录返回结果。

伪代码如下：
/**

 ** 幂等处理*

  **/*

  Rsp idempotent（Request req）{

   Object requestRecord =selectByBizSeq（bizSeq）;

   if(requestRecord !=null){
        *//拦截是重复请求*
          log.info("重复请求，直接返回成功，流水号：{}",bizSeq);
          return rsp;

    }

try{

    insert(req);

}catch(DuplicateKeyException e){

*//拦截是重复请求，直接返回成功*
   log.info("主键冲突，是重复请求，直接返回成功，流水号：{}",bizSeq);
   return rsp;

}

   *//正常处理请求*

dealRequest(req);

return rsp;

 }

5.2 直接Insert + 主键/唯一索引冲突

5.1 的方案中先判断了请求是否存在，如果并发度不是很高的时候，可以跳过查询，根据主键冲突判重。

伪代码如下：

/**幂等处理 */*/Rsp idempotent（Request req）{    try{        insert(req);    }catch(DuplicateKeyException e){    //拦截是重复请求，直接返回成功        log.info("主键冲突，是重复请求，直接返回成功，流水号：{}",bizSeq);      return rsp;    }    //正常处理请求    dealRequest(req);    return rsp;}

5.3 状态机

很多业务表都是有状态，如转账流水表，状态一般有0：待处理；1：处理中；2：成功；3：失败，转账流水的更新一般都会有状态的变更，即状态机（状态变更图）。
比如转账成功后，把处理中的转账流水更新为成功状态，SQL这么写：

update transfr_flow set status=2 where biz_seq=‘666’ and status=1;

伪代码如下：

Rsp idempotentTransfer（Request req）{String bizSeq = req.getBizSeq();int rows= "update transfr_flow set status=2 where biz_seq=#{bizSeq} and status=1;"
if(rows==1){  log.info(“更新成功,可以处理该请求”);  //其他业务逻辑处理  return rsp;}else if(rows==0){  log.info(“更新不成功，不处理该请求”);  //不处理，直接返回  return rsp;}  log.warn("数据异常")  return rsp：
}

5.4 抽取防重表

5.1和5.2的方案，都是建立在业务流水表上bizSeq的唯一性上。很多时候，我们业务表唯一流水号希望后端系统生成，又或者我们希望防重功能与业务表分隔开来，这时候我们可以单独搞个防重表。当然防重表也是利用主键/索引的唯一性，如果插入防重表冲突即直接返回成功，如果插入成功，即去处理请求。

5.5 token令牌

为每个请求生成一个唯一的Token，并在服务端进行校验，一旦处理了对应的请求，就丢弃该Token，避免重复处理。具体步骤：

1、服务端提供了发送 token 的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取 token，服务器会把 token 保存到 redis 中。

2、然后调用业务接口请求时，把 token 携带过去，一般放在请求头部。

3、服务器判断 token 是否存在 redis 中，存在表示第一次请求，然后删除 token,继续执行业务。

4、如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给 client，这样就保证了业务代码，不被重复执行。

核心逻辑：

// 服务端接口，接收请求并处理token
void do(String token) {
    if (Redis.exists(token)) {
       // 删除token，确保不会重复处理
        Redis.del(token); 
        // 执行具体的业务操作
        doSometing(); 
    } else {
        log.info(token); 
    }
}

注意：最好设计为先删除 token，如果业务调用失败，就重新获取 token 再次请求。可以在 redis 使用 lua 脚本完成这个操作

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

5.6 悲观锁

通俗点讲就是很悲观，每次去操作数据时，都觉得别人中途会修改，所以每次在拿数据的时候都会上锁。官方点讲就是，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

悲观锁如何控制幂等的呢？就是加锁呀，一般配合事务来实现。

伪代码如下：

begin;  # 1.开始事务select * from order where order_id='666' # 查询订单，判断状态if（status !=处理中）{//非处理中状态，直接返回；return ;}## 处理业务逻辑update order set status='完成' where order_id='666' # 更新完成commit; # 5.提交事务

这里面order_id需要是索引或主键哈，要锁住这条记录就好，如果不是索引或者主键，会锁表的！
悲观锁在同一事务操作过程中，锁住了一行数据。别的请求过来只能等待，如果当前事务耗时比较长，就很影响接口性能。所以一般不建议用悲观锁做这个事情。

5.7 乐观锁

通过记录数据的版本号或时间戳，仅当数据未被其他事务修改时，才允许更新操作执行。每次更新数据时，版本号都会递增。

UPDATE orders
SET
  quantity = 1,
  order_status = 1,
  pay_time = '2024-04-30 10:20:00',
  version = version + 1
WHERE
  order_id = 'ORD-20231023-0001' AND
  version = 1;

效果演示：

如果 Session-01 已经提交了事务，Session-02 的更新操作将不会影响任何行，因为 version 已经从 1 增加到了 2。

5.8 分布式锁

分布式锁实现幂等性的逻辑就是，请求过来时，先去尝试获得分布式锁，如果获得成功，就执行业务逻辑，反之获取失败的话，就舍弃请求直接返回成功。执行流程如下图所示：

分布式锁可以使用Redis，也可以使用ZooKeeper，不过还是Redis相对好点，因为较轻量级。
Redis分布式锁，可以使用命令SET EX PX NX + 唯一流水号实现，分布式锁的key必须为业务的唯一标识哈
Redis执行设置key的动作时，要设置过期时间哈，这个过期时间不能太短，太短拦截不了重复请求，也不能设置太长，会占存储空间，处理完成，要在finally中删除锁。

                   🔥免费学习编程的网站  热门推荐🔥

[我爱编程网（www.love-coding.com），程序员免费学习的编程网站](https://www.love-coding.com)
在这里插入图片描述

首席架构师专栏

关注

18
点赞
踩
16

收藏

觉得还不错? 一键收藏
打赏
0
评论
实战，实现幂等的8种方案！

幂等的概念来自数学和计算机科学数学概念：幂等函数 f(x) = f (f(x)) ，如绝对值函数abs(-5) = abs(abs(-5))计算机科学：多次请求同同一资源与一次请求的影响是一致的。
复制链接

扫一扫