再续如何防止接口重复提交？

在上一篇文章中，我们详细的介绍了对于下单流量不算高的系统，可以通过​请求唯一ID​+​数据表增加唯一索引约束​这种方案来实现防止接口重复提交！,随着业务的快速增长，每一秒的下单请求次数，可能从几十上升到几百甚至几千。,面对这种下单流量越来越高的场景，此时数据库的访问压力会急剧上升，上面这套方案全靠数据库来解决，会特别吃力！,对于这样的场景，我们可以选择引入缓存中间件来解决，可选的组件有 redis、memcache 等。,下面，我们以引入redis缓存数据库服务器，向大家介绍具体的解决方案！,我们先来看一张图，这张图就是本次方案的核心流程图。,,实现的逻辑，流程如下：,1.当用户进入订单提交界面的时候，调用后端获取请求唯一 ID，同时后端将请求唯一ID存储到redis中再返回给前端，前端将唯一 ID 值埋点在页面里面,2.当用户点击提交按钮时，后端检查这个请求唯一 ID 是否存在，如果不存在，提示错误信息；如果存在，继续后续检查流程,3.使用redis的分布式锁服务，对请求 ID 在限定的时间内进行加锁，如果加锁成功，继续后续流程；如果加锁失败，说明服务正在处理，请勿重复提交,4.最后一步，如果加锁成功后，需要将锁手动释放掉，以免再次请求时，提示同样的信息；同时如果任务执行成功，需要将redis中的请求唯一 ID 清理掉,5.至于数据库是否需要增加字段唯一索引，理论上可以不用加，如果加了更保险,引入缓存服务，防止重复提交的大体思路如上，实践代码如下！,2.1、引入 redis 组件,小编的项目是基于SpringBoot​版本进行构建，添加相关的redis依赖环境如下：,特别注意：由于每个项目环境不一样，具体的依赖包需要和工程版本号匹配！,2.2、添加 redis 环境配置,在全局配置application.properties​文件中，添加redis相关服务配置如下,在使用redis​之前，请确保redis服务器是启动状态，并且能正常访问！,2.3、编写获取请求唯一ID的接口，同时将唯一ID存入redis,2.4、编写服务验证逻辑，通过 aop 代理方式实现,首先创建一个@SubmitToken注解，通过这个注解来进行方法代理拦截！,编写方法代理服务，增加防止重复提交的验证，实现了逻辑如下！,部分校验逻辑用到了redis分布式锁，具体实现逻辑如下：,2.5、在相关的业务接口上，增加SubmitToken注解即可,整套方案完全基于​redis​来实现，同时结合​redis​的分布式锁来实现请求限流，之所以选择​redis​，是因为它是一个内存数据库，性能比关系型数据库强太多，即使每秒的下单请求量在几千，也能很好的应对，为关系型数据库起到降压作用！,特别注意的地方：使用​redis​的分布式锁，推荐单机环境，如果​redis​是集群环境，可能会导致锁短暂无效！,随着下单流量逐渐上升，通过查询数据库来检查当前服务请求是否重复提交这种方式，可能会让数据库的请求查询频率变得非常高，数据库的压力会倍增。,此时我们可以引入redis缓存，将通过查询数据库来检查当前请求是否重复提交这种方式，转移到通过查询缓存来检查当前请求是否重复提交，可以很好的给数据库降压！