java面试(9)接口的幂等设计

 

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，服务端生成token返回
客户端带着token请求，服务端校验token
幂等处理流程如下：

客户端发起请求，申请获取token。
服务端生成全局唯一的token，保存到redis中（一般会设置一个过期时间），然后返回给客户端。
客户端带着token，发起请求。
服务端去redis确认token是否存在，一般用redis.del(token)的方式，如果存在会删除成功，即处理业务逻辑，如果删除失败不处理业务逻辑，直接返回结果。

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 乐观锁

什么是乐观锁？

乐观锁在操作数据时,则非常乐观，认为别人不会同时在修改数据，因此乐观锁不会上锁。只是在执行更新的时候判断一下，在此期间别人是否修改了数据。

怎样实现乐观锁呢？

就是给表的加多一列version版本号，每次更新记录version都升级一下（version=version+1）。具体流程就是先查出当前的版本号version，然后去更新修改数据时，确认下是不是刚刚查出的版本号，如果是才执行更新

5.8 分布式锁

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

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