聊聊如何防止接口重复提交？

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