
【干货】如何防止接口重复提交?(下)
一、摘要
在上一篇文章中,我们详细的介绍了随着下单流量逐渐上升,为了降低数据库的访问压力,通过请求唯一ID
+redis分布式锁
来防止接口重复提交,流程图如下!
每次提交的时候,需要先调用后端服务获取请求唯一ID
,然后才能提交。
对于这样的流程,不少的同学可能会感觉到非常鸡肋,尤其是单元测试,需要每次先获取submitToken
值,然后才能提交!
能不能不用这么麻烦,直接服务端通过一些规则组合,生成本次请求唯一ID呢?
答案是可以的!
今天我们就一起来看看,如何通过服务端来完成请求唯一 ID 的生成?
二、方案实践
我们先来看一张图,这张图就是本次方案的核心流程图。
实现的逻辑,流程如下:
- 1.用户点击提交按钮,服务端接受到请求后,通过规则计算出本次请求唯一ID值
- 2.使用
redis
的分布式锁服务,对请求 ID 在限定的时间内尝试进行加锁,如果加锁成功,继续后续流程;如果加锁失败,说明服务正在处理,请勿重复提交 - 3.最后一步,如果加锁成功后,需要将锁手动释放掉,以免再次请求时,提示同样的信息
引入缓存服务后,防止重复提交的大体思路如上,实践代码如下!
2.1、引入 redis 组件
本次 demo 项目是基于SpringBoot
版本进行构建,添加相关的redis
依赖环境如下:
2.2、添加 redis 环境配置
在全局配置application.properties
文件中,添加redis
相关服务配置如下
2.3、编写服务验证逻辑,通过 aop 代理方式实现
首先创建一个@SubmitLimit
注解,通过这个注解来进行方法代理拦截!
编写方法代理服务,增加防止重复提交的验证,实现了逻辑如下!
部分校验逻辑用到了redis
分布式锁,具体实现逻辑如下:
部分代码使用到了序列化相关类JacksonUtils
,源码如下:
2.4、在相关的业务接口上,增加SubmitLimit注解即可
其中最关键的一个步就是将唯一请求 ID 的生成,放在服务端通过组合来实现,在保证防止接口重复提交的效果同时,也可以显著的降低接口测试复杂度!
三、小结
本次方案相比于上一个方案,最大的改进点在于:将接口请求唯一 ID 的生成逻辑,放在服务端通过规则组合来实现,不需要前端提交接口的时候强制带上这个参数,在满足防止接口重复提交的要求同时,又能减少前端和测试提交接口的复杂度!
需要特别注意的是:使用redis
的分布式锁,推荐单机环境,如果redis
是集群环境,可能会导致锁短暂无效!
本文转载自公众号:java极客技术
