如何实现接口防抖功能，杜绝重复提交

文章目录

前言

作为一名老码农，在开发后端Java业务系统，包括各种管理后台和小程序等。在这些项目中，我设计过单/多租户体系系统，对接过许多开放平台，也搞过消息中心这类较为复杂的应用，但幸运的是，我至今还没有遇到过线上系统由于代码崩溃导致资损的情况。

这其中的原因有三点：

一是业务系统本身并不复杂；

二是我一直遵循某大厂代码规约，在开发过程中尽可能按规约编写代码；

三是经过多年的开发经验积累，我成为了一名熟练工，掌握了一些实用的技巧；

啥是防抖

所谓防抖，一是防用户手抖，二是防网络抖动。在Web系统中，表单提交是一个非常常见的功能，如果不加控制，容易因为用户的误操作或网络延迟导致同一请求被发送多次，进而生成重复的数据记录。要针对用户的误操作，前端通常会实现按钮的loading状态，阻止用户进行多次点击。而对于网络波动造成的请求重发问题，仅靠前端是不行的。为此，后端也应实施相应的防抖逻辑，确保在网络波动的情况下不会接收并处理同一请求多次。

一个理想的防抖组件或机制，我觉得应该具备以下特点：

逻辑正确，也就是不能误判；
响应迅速，不能太慢；
易于集成，逻辑与业务解耦；
良好的用户反馈机制，比如提示“您点击的太快了”；

思路解析

前面讲了那么多，我们已经知道接口的防抖是很有必要的了，但是在开发之前，我们需要捋清楚几个问题。

哪一类接口需要防抖?

接口防抖也不是每个接口都需要加，一般需要加防抖的接口有这几类：

用户输入类接口：比如搜索框输入、表单输入等，用户输入往往会频繁触发接口请求，但是每次触发并不一定需要立即发送请求，可以等待用户完成输入一段时间后再发送请求。
按钮点击类接口：比如提交表单、保存设置等，用户可能会频繁点击按钮，但是每次点击并不一定需要立即发送请求，可以等待用户停止点击一段时间后再发送请求。
滚动加载类接口：比如下拉刷新、上拉加载更多等，用户可能在滚动过程中频繁触发接口请求，但是每次触发并不一定需要立即发送请求，可以等待用户停止滚动一段时间后再发送请求。

如何确定接口是重复的？

防抖也即防重复提交，那么如何确定两次接口就是重复的呢？首先，我们需要给这两次接口的调用加一个时间间隔，大于这个时间间隔的一定不是重复提交；其次，两次请求提交的参数比对，不一定要全部参数，选择标识性强的参数即可；最后，如果想做的更好一点，还可以加一个请求地址的对比。

分布式部署下如何做接口防抖？

有两个方案：

使用共享缓存

流程图如下：

使用分布式锁

流程图如下：

常见的分布式组件有Redis、Zookeeper等，但结合实际业务来看，一般都会选择Redis，因为Redis一般都是Web系统必备的组件，不需要额外搭建。

具体实现

现在有一个保存用户的接口：

@PostMapping("/add")  
@RequiresPermissions(value = "add")  
@Log(methodDesc = "添加用户")  
public ResponseEntity<String> add(@RequestBody AddReq addReq) {  
        return userService.add(addReq);  
}

AddReq.java

import java.util.List;  
import lombok.Data;  
@Data
public class AddReq {
   
     
    /**     * 用户名称     */    private String userName;  
    /**     * 用户手机号     */    private String userPhone;  
    /**     * 角色ID列表     */    private List<Long> roleIdList;
}

目前数据库表中没有对userPhone字段做UK索引，这就会导致每调用一次add就会创建一个用户，即使userPhone相同。

请求锁

根据上面的要求，我定了一个注解 @RequestLock ，使用方式很简单，把这个注解打在接口方法上即可。

RequestLock.java

import java.util.List;   
import lombok.Data;  
  
@Data  
public class AddReq {  
  
    /**  
     * 用户名称  
     */  
    private String userName;  
  
    /**  
     * 用户手机号  
     */  
    private String userPhone;  
  
    /**  
     * 角色ID列表  
     */  
    private List<Long> roleIdList;  
}

@RequestLock注解定义了几个基础的属性，redis锁前缀、redis锁时间、redis锁时间单位、key分隔符。其中前面三个参数比较好理解，都是一个锁的基本信息。key分隔符是用来将多个参数合并在一起的，比如userName是张三，userPhone是123456，那么完整的key就是"张三&123456"，最后再加上redis锁前缀，就组成了一个唯一key。

唯一key生成

这里有些同学可能就要说了，直接拿参数来生成key不就行了吗？额，不是不行，但我想问一个问题：如果这个接口是文章发布的接口，你也打算把内容当做key吗？要知道，Redis的效率跟key的大小息息相关。所以，我的建议是选取合适的字段作为key就行了，没必要全都加上 。

要做到参数可选，那么用注解的方式最好了，注解如下：

RequestKeyParam.java

import java.lang.annotation.*;  
  
/**  
 * @description 加上这个注解可以将参数设置为key  
 */  
@Target({
   
   ElementType.METHOD, ElementType.PARAMETER, ElementType.FIELD})  
@Retention(RetentionPolicy.RUNTIME)  
@Documented  
@Inherited  
public @interface RequestKeyParam {
   
     
  
}

注：这个注解加到参数上就行，没有多余的属性。

接下来就是lockKey的生成了，代码如下:

RequestKeyGenerator.java

import java.lang.annotation.Annotation;  
import java.lang.reflect.Field;  
import java.lang.reflect.Method;  
import java.lang.reflect.Parameter;  
  
import org.aspectj.lang.ProceedingJoinPoint;  
import org.aspectj.lang.reflect.MethodSignature;  
import org.springframework.util.ReflectionUtils;  
import org.springframework.util.StringUtils;  
  
public class RequestKeyGenerator {
   
     
    /**  
     * 获取LockKey  
     *  
     * @param joinPoint 切入点  
     * @return  
     */  
    public static String getLockKey(ProceedingJoinPoint joinPoint) {
   
     
        //获取连接点的方法签名对象  
        MethodSignature methodSignature = (MethodSignature)joinPoint.getSignature();  
        //Method对象  
        Method method = methodSignature.getMethod();  
        //获取Method对象上的注解对象  
        RequestLock requestLock = method.getAnnotation(RequestLock.class)