【编程开发】之接口的幂等性

拼搏现实的明天。 2022-12-17 08:41 93阅读 0赞

# 一、什么是幂等性 #

--------------------

**接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的接口的结果是一致的**，不会因为多次请求操作而产生了副作用。比如说支付场景，用户购买了商品支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，如果用户再次点击支付按钮并返回结果成功，用户的余额应该只扣取一次，流水记录也应该只有一条，这就是接口的幂等性。

# 二、什么情况下需要幂等 #

--------------------

以SQL为例：

*  `SELECT col1 FROM tab1 WHER col2=2`，无论执行多少次都不会改变状态，是天然的幂等。
 *  `UPDATE tab1 SET col1=1 WHERE col2=2`，无论执行成功多少次状态都是一致的，因此也是幂等操作。
 *  `PDATE tab1 SET col1=col1+1 WHERE col2=2`，每次执行的结果都会发生变化，这种不是幂等的。
 *  `INSERT INTO user(userid, name) VALUES (1,'a') 如 userid` 为唯一主键，即重复操作上面的业务，只会插入一条用户数据，具备幂等性；如userid不是主键，可以重复，那上面业务多次操作，数据都会新增多条，不具备幂等性。
 *  `ELETE FROM user WHERE userid=1`，多次操作，结果一样，具备幂等性.

# 三、如何保证幂等 #

--------------------

### 1、token 机制 ###

*  1、服务端提供了发送 token 的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取 token，服务器会把 token 保存到 redis 中。
 *  2、然后调用业务接口请求时，把 token 携带过去，一般放在请求头部。
 *  3、服务器判断 token 是否存在 redis 中，存在表示第一次请求，然后删除 token,继续执行业务。
 *  4、如果判断 token 不存在 redis 中，就表示是重复操作，直接返回重复标记给 client，这样就保证了业务代码，不被重复执行。

**关键点**：先删除 token，还是后删除 token

*  先删除token：如果系统出现问题导致业务处理出现异常，业务处理没有成功，接口调用方也没有获取到明确的结果，然后进行重试，但token已经删除掉了，服务端判断token不存在，认为是重复请求，就直接返回了，无法进行业务处理了。
 *  后删除token：如果进行业务处理成功后，删除redis中的token失败了，这样就导致了有可能会发生重复请求，因为token没有被删除。这个问题其实是数据库和缓存redis数据不一致问题，后续会写文章进行讲解。

从分析可以看出，只有先删 token 才可以保证不会出现重复请求操作问题。如果删除 token 后出现了业务异常，可以让调用方配合处理一下，重新获取新的 token，再次由业务调用方发起重试请求就 ok 了。

**重点**：因为我们的 token 是保存在 Redis 中的，所以在分布式并发情况下我们要保证：获取 token、比较 token 和删除 token 这三个操作是原子操作，否则就会出现问题。而 Redis 的原子性操作可以使用 lua 脚本实现。

**token 令牌验证实例代码如下**：

// 原子操作的 lua 脚本，KEYS[1] 传 Redis 中保存的数据的 key，以数组的形式提供
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    
    // 客户端传回来的 token
    String orderToken = vo.getOrderToken();
    
    // 执行lua脚本进行原子验证令牌和删除令牌
    Long result = redisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class),
                    Arrays.asList(USER_ORDER_TOKEN), // 保存在 redis 中 token 的 key
                    orderToken);
    
    if (result == 0L) { 
        //令牌验证失败
    } else { 
        //令牌验证成功
    }

**token机制缺点**

业务请求每次请求，都会有额外的请求（一次获取token请求、判断token是否存在的业务）。其实真实的生产环境中，1万请求也许只会存在10个左右的请求会发生重试，为了这10个请求，我们让9990个请求都发生了额外的请求。

### 2、乐观锁机制 ###

这种方法适合在**数据库更新的场景**中：

update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1

根据 `version` 版本，也就是在操作库存前先获取当前商品的 version 版本号，然后操作的时候带上此 version 号，具体流程大概如下：

*  我们第一次操作库存时，得到 version 为 1，调用库存服务 version 变成了 2；
 *  但返回给订单服务出现了问题，订单服务又一次发起调用库存服务，当订单服务传如的 version 还是1，再执行上面的 sql 语句时，就不会执行；
 *  因为 version 已经变为2了，where 条件就不成立，这样就保证了不管调用几次，只会真正的处理一次。

乐观锁主要使用于处理读多写少的问题。

### 3、唯一主键 ###

这个机制是利用了数据库的主键唯一约束的特性，解决了**在 insert 场景**时幂等问题。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键。

**注意**：如果是分库分表场景下，路由规则要保证相同请求下，落地在同一个数据库和同一表中，要不然数据库主键约束就不起效果了，因为是不同的数据库和表主键不相关。

### 4、防重表 ###

使用订单号 orderNo 做为去重表的唯一索引，把唯一索引插入去重表，再进行业务操作，且他们在同一个事务中。这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。

这里要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一个事务，即使业务操作失败了，也会把去重表的数据回滚。这个很好的保证了数据一致性。

### 5、全局唯一 ID ###

生成全局唯一 ID，并配合 Redis 一起使用，如果已经处理过了就保存相应数据记录到 Redis 中，能够在 Redis 中找到记录则表示已经处理过了。

**以消息队列的重复消费场景为例**：

首先，给每个消息分配一个全局唯一 ID，在消费者开始消费消息之前，先去 Redis 中查找有没有相应的数据记录，如果没有则以 `id: message` 的形式保存到 Redis 中，数据类型使用集合（去重）；如果消费之前查询到 Redis 中有相应的消费记录消息则表示已经消费成功了。