确保接口安全：六大方案有效解决幂等性问题

文章目录

六大方案解决接口幂等问题

什么是接口幂等？

幂等（idempotency）本身是一个数学概念，常见与抽象代数中，代表一个函数或操作的结果不受其输入或者执行次数的影响，例如，f(n) = 1^n，无论 n 为多少，f(n)的值永远为 1 。

在软件开发领域，幂等对请求执行结果的一个描述，这个描述就是无论执行多少次相同的请求，产生的效果和返回的结果和发出单个请求是一样的。

举个例子🌰：

• 有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。
• 我们在项目中为了解决接口超时问题，通常会引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果（此时有可能已经成功了），为了避免返回错误的结果（这种情况不可能直接返回失败吧？），于是会对该请求重试几次，这样也会产生重复的数据。

天然幂等

那有没有有些情况是天然支持幂等的呢？当然有！比如说我要更新一个某记录的状态

status = 1

具体的 sql 为

update table set status = 1 where id = 1 

这种情况，无论我执行多少次这条 sql 他的效果是一样的，这就是天然支持幂等的。

不做幂等会怎么样？

比如说用户在付款的时候，同时点击多次付款按钮，后端处理了多次扣款请求，结果导致用户的账户扣了多次钱。妥妥 p0 事故呀！

到这你又会说，前端做个置灰按钮不就行了吗，第一次付款完毕后，那用户或者恶意攻击你服务器的人直接用脚本搞你不走前端，你是防止不了的。

那接下来，我将介绍六大解决接口幂等的方案，速速点赞上车！！！

解决方案

1）insert前先select

通常情况下，在保存数据的接口中，我们为了防止产生重复数据，一般会在

insert

前，先根据

name

或

code

字段

select

一下数据。如果该数据已存在，则执行

update

操作，如果不存在，才执行

insert

操作。

该方案可能是我们平时在防止产生重复数据时，使用最多的方案。但是该方案不适用于并发场景，在并发场景中，要配合其他方案一起使用，否则同样会产生重复数据。

2）使用唯一索引

通过在表中加上唯一索引，保证数据的唯一性。如果有重复的数据插入，会抛出

DuplicateKeyException

异常，程序可以捕获异常并处理。不过，这种方法只适用于插入数据的场景。

createtable t_order(
    id intunsignedPRIMARYKEYAUTO_INCREMENTCOMMENT"主键",
    code varchar(200)notnullCOMMENT"流水号",
    user_id  intunsignedCOMMENT"用户id",
    amount decimal(10,2)unsignednotnullCOMMENT"总金额",UNIQUE unq_code(code))COMMENT="订单表";

不要依靠唯一索引来保证接口幂等，但建议使用唯一索引作为兜底，避免产生脏数据。

伪代码如下：

publicvoididempotent(OrderDO orderDO){try{// 执行核心业务...
       orderMapper.insert(orderDO);}catch(DuplicateKeyException e){// 有重复的数据插入}}

3）去重表加悲观锁

去重表本质上也是一种唯一索引方案。去重表是一张专门用于记录请求信息的表，其中某个字段需要建立唯一索引，用于标识请求的唯一性当客户端发出请求时，服务端会将这次请求的一些信息（如订单号、交易流水号等）插入到去重表中，如果插入成功，说明这是第一次请求，可以执行后续的业务逻辑；如果插入失败，说明这是重复请求，可以直接返回或者忽略。

CREATETABLE deduplication_table (
    id intunsignedPRIMARYKEYAUTO_INCREMENTCOMMENT"主键",
    processed_code varchar(200)notnullCOMMENT"已处理的订单流水号",-- 省略其他字段UNIQUE unq_processed_code(processed_code))COMMENT="去重表";

使用

for update

加锁每次查询到都是最新的数据

select*from deduplication_table where processed_code ='xxx'forupdate

伪代码如下：

publicbooleanidempotent(OrderDO orderDO){// 执行核心业务之前DoMain domain = deduplicationMapper.selectForUpdate(orderDO.getProcessedCode);if(doamin !=null){// 订单已经支付}}

4）加乐观锁之版本号机制

既然悲观锁有性能问题，为了提升接口性能，我们可以使用乐观锁。需要在表中增加一个

timestamp

或者

version

字段，这里以

version

字段为例。

在更新数据之前先查询一下数据：

select id,amount,version fromuser id=123;

如果数据存在，假设查到的

version

等于

1

，再使用

id

和

version

字段作为查询条件更新数据：

updateuserset amount = amount +100, version = version +1where id =123and version =1;

更新数据的同时

version+1

，然后判断本次

update

操作的影响行数，如果大于0，则说明本次更新成功，如果等于0，则说明本次更新没有让数据变更。

由于第一次请求

version

等于

1

是可以成功的，操作成功后

version

变成

2

了。这时如果并发的请求过来，再执行相同的sql：

updateuserset amount = amount +100,version = version +1where id =123and version =1;

该

update

操作不会真正更新数据，最终sql的执行结果影响行数是

0

，因为

version

已经变成

2

了，

where

中的

version=1

肯定无法满足条件。但为了保证接口幂等性，接口可以直接返回成功，因为

version

值已经修改了，那么前面必定已经成功过一次，后面都是重复的请求。

具体流程如下：

具体步骤：

1. 先根据id查询用户信息，包含version字段
2. 根据id和version字段值作为where条件的参数，更新用户信息，同时version+1
3. 判断操作影响行数，如果影响1行，则说明是一次请求，可以做其他数据操作。
4. 如果影响0行，说明是重复请求，则直接返回成功。

5）使用 Redisson 分布式锁

基于 MySQL 也可以实现分布式锁，但一般我们不会采用这种方式。

通常情况下，我们一般会选择基于 Redis 或者 ZooKeeper 实现分布式锁，Redis 用的要更多一点。

// 唯一标识String uniqueId ="orderId123";// 1. 根据唯一标识生成分布式锁对象RLock lock = redisson.getLock("lock:"+ uniqueId);try{// 2. 尝试获取锁(Watch Dog 自动续期机制) if(lock.tryLock()){// 3. 如果成功获取到锁，说明请求还没有被处理，执行业务逻辑}else{// 请求已经被处理，直接返回}}finally{// 4. 释放锁
    lock.unlock();}

6）Token 机制

Token 机制的核心思想是为每一次操作生成一个唯一性的凭证 token。这个 token 需要由服务端生成的，因为服务端可以对 token 进行签名和加密，防止篡改和泄露。如果由客户端生成 token，可能会存在安全隐患，比如客户端伪造或重复 token，导致服务端无法识别和校验。

这样的话，就需要两次请求才能完成一次业务操作：

1. 请求获取服务器端 token，token 需要设置有效时间（可以设置短一点），服务端将该 token 保存起来。
2. 执行真正的请求，将上一步获取到的 token 放到 header 或者作为请求参数。服务端验证 token 的有效性，如果有效（一般是通过删除 token 的方式来验证，删除成功则有效），执行业务逻辑，并删除 token，防止重复提交；如果无效，拒绝请求，返回提示信息。

// 获取tokenpublicStringgetToken(Long busId,Long userId){String UUID = UUID.randomUUID().toString();
    stringRedisTemplate.opsForValue().set(busId+userId, UUID,20,TimeUnit.SECONDS)return UUID;}// 发起业务请求携带tokenpublicvoiddoSomeBusiness(Parameter parameter){Long busId = parameter.getBusId;Long userId =UserContext.getUserId();// 判断token是否存在Boolean deleted = stringRedisTemplate.delete(busId+userId);if(deleted){// 删除成功,代表重复请求不进行操作，直接返回return;}// doSomeBusiness...}

具体步骤：

1. 用户访问页面时，浏览器自动发起获取 token 请求。
2. 服务端生成 token，保存到 redis 中，然后返回给浏览器。
3. 用户通过浏览器发起请求时，携带该 token。
4. 从 redis 中尝试删除 token 如果删除失败，说明是第一次请求，做则后续的数据操作。
5. 如果删除成功，说明是重复请求，不做任何操作。