当前位置: 首页 > news >正文

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

文章目录

  • 六大方案解决接口幂等问题
    • 什么是接口幂等?
    • 天然幂等
    • 不做幂等会怎么样?
  • 解决方案
    • 1)insert前先select
    • 2)使用唯一索引
    • 3)去重表加悲观锁
    • 4)加乐观锁之版本号机制
    • 5)使用 Redisson 分布式锁
    • 6)Token 机制

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

什么是接口幂等?

幂等(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前,先根据namecode字段select一下数据。如果该数据已存在,则执行update操作,如果不存在,才执行 insert操作。

在这里插入图片描述

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

2)使用唯一索引

通过在表中加上唯一索引,保证数据的唯一性。如果有重复的数据插入,会抛出DuplicateKeyException异常,程序可以捕获异常并处理。不过,这种方法只适用于插入数据的场景。

create table t_order(id int unsigned PRIMARY KEY AUTO_INCREMENT COMMENT "主键",code varchar(200) not null COMMENT "流水号",user_id  int unsigned COMMENT "用户id",amount decimal(10,2) unsigned not null COMMENT "总金额",UNIQUE unq_code(code)
) COMMENT="订单表";

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

伪代码如下:

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

3)去重表加悲观锁

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

CREATE TABLE deduplication_table (id int unsigned PRIMARY KEY AUTO_INCREMENT COMMENT "主键",processed_code varchar(200) not null COMMENT "已处理的订单流水号",-- 省略其他字段UNIQUE unq_processed_code(processed_code)
) COMMENT="去重表";

使用for update加锁每次查询到都是最新的数据

select * from deduplication_table where processed_code = 'xxx' for update

伪代码如下:

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

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

既然悲观锁有性能问题,为了提升接口性能,我们可以使用乐观锁。需要在表中增加一个timestamp或者version字段,这里以version字段为例。

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

select id,amount,version from user id=123;

如果数据存在,假设查到的version等于1,再使用idversion字段作为查询条件更新数据:

update user set amount = amount + 100, version = version + 1 where id = 123 and version = 1;

更新数据的同时version+1,然后判断本次update操作的影响行数,如果大于0,则说明本次更新成功,如果等于0,则说明本次更新没有让数据变更。

由于第一次请求version等于1是可以成功的,操作成功后version变成2了。这时如果并发的请求过来,再执行相同的sql:

update user set amount = amount + 100,version = version + 1 where id = 123 and 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,防止重复提交;如果无效,拒绝请求,返回提示信息。

// 获取token
public String getToken(Long busId, Long userId){String UUID = UUID.randomUUID().toString();stringRedisTemplate.opsForValue().set(busId+userId, UUID, 20, TimeUnit.SECONDS)return UUID;
}
// 发起业务请求携带token
public void doSomeBusiness(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. 如果删除成功,说明是重复请求,不做任何操作。
http://www.lryc.cn/news/457364.html

相关文章:

  • 代码随想录算法训练营第二十九天| 93. 复原 IP 地址,78. 子集, 90. 子集 II
  • 【WebGis开发 - Cesium】三维可视化项目教程---初始化场景
  • 点云中ICP算法的详解
  • 抽象类Abstart Class
  • Redis:通用命令 数据类型
  • 【Python高级编程】探索Python库:创建引人入胜的交互界面
  • OpenCV Canny()函数
  • Java基础(3)
  • 【C语言】VS调试技巧
  • 【华为HCIP实战课程七】OSPF邻居关系排错MTU问题,网络工程师
  • 速盾:休闲类游戏如何选择高防cdn?
  • 电脑插上U盘不显示怎么回事?怎么解决?
  • Python 如何使用 SQLAlchemy 进行复杂查询
  • nginx主配置文件
  • 使用数据库:
  • python list, tuple dict,set的区别 以及**kwargs 的基本用法
  • 实用生活英语口语学习成人零基础入门柯桥专业外语培训
  • FLINK SQL数据类型
  • 汇编语言教程:打造你的第一款汇编语言小游戏 汇编语言教程攻略
  • 白色简洁大方公司企业网站源码 WordPress主题2款
  • MinIO分片上传超大文件(纯服务端)
  • leetcode链表(一)-移除链表元素
  • python的特殊方法——魔术方法
  • 深入浅出理解TCP三次握手与四次挥手
  • 如何在Windows和Linux查看正在监听的端口和绑定的进程
  • 如何用深度神经网络预测潜在消费者
  • 基于opencv答题卡识别判卷
  • ShardingSphere分库分表产品介绍
  • Java经典面试题-多线程打印
  • FireFox简单设置设置