接口防刷方案

1、前言

本文为描述通过Interceptor以及Redis实现接口访问防刷Demo

2、原理

通过ip地址+uri拼接用以作为访问者访问接口区分
通过在Interceptor中拦截请求，从Redis中统计用户访问接口次数从而达到接口防刷目的

如下图所示

3、案例工程

项目地址：

https://github.com/Tonciy/interface-brush-protection

Apifox地址：Apifox 密码：Lyh3j2Rv

其中，Interceptor处代码处理逻辑最为重要

/**  * @description: 接口防刷拦截处理  */  
@Slf4j  
public class AccessLimintInterceptor  implements HandlerInterceptor {  @Resource  private RedisTemplate<String, Object> redisTemplate;  /**  * 多长时间内  */  @Value("${interfaceAccess.second}")  private Long second = 10L;  /**  * 访问次数  */  @Value("${interfaceAccess.time}")  private Long time = 3L;  /**  * 禁用时长--单位/秒  */  @Value("${interfaceAccess.lockTime}")  private Long lockTime = 60L;  /**  * 锁住时的key前缀  */  public static final String LOCK_PREFIX = "LOCK";  /**  * 统计次数时的key前缀  */  public static final String COUNT_PREFIX = "COUNT";  public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {  String uri = request.getRequestURI();  String ip = request.getRemoteAddr(); // 这里忽略代理软件方式访问，默认直接访问，也就是获取得到的就是访问者真实ip地址  String lockKey = LOCK_PREFIX + ip + uri;  Object isLock = redisTemplate.opsForValue().get(lockKey);  if(Objects.isNull(isLock)){  // 还未被禁用  String countKey = COUNT_PREFIX + ip + uri;  Object count = redisTemplate.opsForValue().get(countKey);  if(Objects.isNull(count)){  // 首次访问  log.info("首次访问");  redisTemplate.opsForValue().set(countKey,1,second, TimeUnit.SECONDS);  }else{  // 此用户前一点时间就访问过该接口  if((Integer)count < time){  // 放行，访问次数 + 1  redisTemplate.opsForValue().increment(countKey);  }else{  log.info("{}禁用访问{}",ip, uri);  // 禁用  redisTemplate.opsForValue().set(lockKey, 1,lockTime, TimeUnit.SECONDS);  // 删除统计  redisTemplate.delete(countKey);  throw new CommonException(ResultCode.ACCESS_FREQUENT);  }  }  }else{  // 此用户访问此接口已被禁用  throw new CommonException(ResultCode.ACCESS_FREQUENT);  }  return true;  }  
}

在多长时间内访问接口多少次，以及禁用的时长，则是通过与配置文件配合动态设置

当处于禁用时直接抛异常则是通过在ControllerAdvice处统一处理（这里代码写的有点丑陋）

下面是一些测试（可以把项目通过Git还原到“【初始化】”状态进行测试）

正常访问时

访问次数过于频繁时

4、自我提问

上述实现就好像就已经达到了我们的接口防刷目的了

但是，还不够

为方便后续描述，项目中新增补充Controller，如下所示

简单来说就是

PassCotroller和RefuseController
每个Controller分别有对应的get，post，put，delete类型的方法，其映射路径与方法名称一致

接口问题

对于上述实现，不知道你们有没有发现一个问题
对于上述实现问题比如现在我们的接口防刷处理，针对是所有的接口（项目案例中我只是写的接口比较少）
而在实际开发中，说对于所有的接口都要做防刷处理，感觉上也不太可能（写此文时目前大四，实际工作经验较少，这里不敢肯定）
那么问题有了，该如何解决呢？目前来说想到两个解决方案

拦截器映射规则

项目通过Git还原到"【Interceptor设置映射规则实现接口自由】"版本即可得到此案例实现

我们都知道拦截器是可以设置拦截规则的，从而达到拦截处理目的

1.这个AccessInterfaceInterceptor是专门用来进行防刷处理的，那么实际上我们可以通过设置它的映射规则去匹配需要进行【接口防刷】的接口即可

2.比如说下面的映射配置

3.这样就初步达到了我们的目的，通过映射规则的配置，只针对那些需要进行【接口防刷】的接口才会进行处理

4.至于为啥说是初步呢？下面我就说说目前我想到的使用这种方式进行【接口防刷】的不足点：

所有要进行防刷处理的接口统一都是配置成了 x 秒内 y 次访问次数，禁用时长为 z 秒

要知道就是要进行防刷处理的接口，其 x, y, z的值也是并不一定会统一的
某些防刷接口处理比较消耗性能的，我就把x, y, z设置的紧一点
而某些防刷接口处理相对来说比较快，我就把x, y, z 设置的松一点
这没问题吧
但是现在呢？x, y, z值全都一致了，这就不行了
这就是其中一个不足点
当然，其实针对当前这种情况也有解决方案
那就是弄多个拦截器
每个拦截器的【接口防刷】处理逻辑跟上述一致，并去映射对应要处理的防刷接口
唯一不同的就是在每个拦截器内部，去修改对应防刷接口需要的x, y, z值
这样就是感觉会比较麻烦

防刷接口映射路径修改后维护问题

虽然说防刷接口的映射路径基本上定下来后就不会改变
但实际上前后端联调开发项目时，不会有那么严谨的Api文档给我们用（这个在实习中倒是碰到过，公司不是很大，开发起来也就不那么严谨，啥都要自己搞，功能能实现就好）
也就是说还是会有那种要修改接口的映射路径需求
当防刷接口数量特别多，后面的接手人员就很痛苦了
就算是项目是自己从0到1实现的，其实有时候项目开发到后面，自己也会忘记自己前面是如何设计的
而使用当前这种方式的话，谁维护谁蛋疼

自定义注解 + 反射

咋说呢

就是通过自定义注解中定义 x 秒内 y 次访问次数，禁用时长为 z 秒
自定义注解 + 在需要进行防刷处理的各个接口方法上
在拦截器中通过反射获取到各个接口中的x, y, z值即可达到我们想要的接口自由目的

下面做个实现

声明自定义注解

Controlller中方法中使用

Interceptor处逻辑修改（最重要是通过反射判断此接口是否需要进行防刷处理，以及获取到x, y, z的值）

/**   * @description: 接口防刷拦截处理  */  
@Slf4j  
public class AccessLimintInterceptor  implements HandlerInterceptor {  @Resource  private RedisTemplate<String, Object> redisTemplate;  /**  * 锁住时的key前缀  */  public static final String LOCK_PREFIX = "LOCK";  /**  * 统计次数时的key前缀  */  public static final String COUNT_PREFIX = "COUNT";  public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {  
//        自定义注解 + 反射 实现  // 判断访问的是否是接口方法  if(handler instanceof HandlerMethod){  // 访问的是接口方法，转化为待访问的目标方法对象  HandlerMethod targetMethod = (HandlerMethod) handler;  // 取出目标方法中的 AccessLimit 注解  AccessLimit accessLimit = targetMethod.getMethodAnnotation(AccessLimit.class);  // 判断此方法接口是否要进行防刷处理（方法上没有对应注解就代表不需要，不需要的话进行放行）  if(!Objects.isNull(accessLimit)){  // 需要进行防刷处理，接下来是处理逻辑  String ip = request.getRemoteAddr();  String uri = request.getRequestURI();  String lockKey = LOCK_PREFIX + ip + uri;  Object isLock = redisTemplate.opsForValue().get(lockKey);  // 判断此ip用户访问此接口是否已经被禁用  if (Objects.isNull(isLock)) {  // 还未被禁用  String countKey = COUNT_PREFIX + ip + uri;  Object count = redisTemplate.opsForValue().get(countKey);  long second = accessLimit.second();  long maxTime = accessLimit.maxTime();  if (Objects.isNull(count)) {  // 首次访问  log.info("首次访问");  redisTemplate.opsForValue().set(countKey, 1, second, TimeUnit.SECONDS);  } else {  // 此用户前一点时间就访问过该接口，且频率没超过设置  if ((Integer) count < maxTime) {  redisTemplate.opsForValue().increment(countKey);  } else {  log.info("{}禁用访问{}", ip, uri);  long forbiddenTime = accessLimit.forbiddenTime();  // 禁用  redisTemplate.opsForValue().set(lockKey, 1, forbiddenTime, TimeUnit.SECONDS);  // 删除统计--已经禁用了就没必要存在了  redisTemplate.delete(countKey);  throw new CommonException(ResultCode.ACCESS_FREQUENT);  }  }  } else {  // 此用户访问此接口已被禁用  throw new CommonException(ResultCode.ACCESS_FREQUENT);  }  }  }  return  true;  }  
}

由于不好演示效果，这里就不贴测试结果图片了

项目通过Git还原到"【自定义主键+反射实现接口自由"版本即可得到此案例实现，后面自己可以针对接口做下测试看看是否如同我所说的那样实现自定义x, y, z 的效果

嗯，现在看起来，可以针对每个要进行防刷处理的接口进行针对性自定义多长时间内的最大访问次数，以及禁用时长，哪个接口需要，就直接+在那个接口方法出即可

感觉还不错的样子，现在网上挺多资料也都是这样实现的

但是还是可以有改善的地方

先举一个例子，以我们的PassController为例，如下是其实现

下图是其映射路径关系

同一个Controller的所有接口方法映射路径的前缀都包含了/pass

我们在类上通过注解@ReqeustMapping标记映射路径/pass，这样所有的接口方法前缀都包含了/pass，并且以致于后面要修改映射路径前缀时只需改这一块地方即可

这也是我们使用SpringMVC最常见的用法

那么，我们的自定义注解也可不可以这样做呢？先无中生有个需求

假设PassController中所有接口都是要进行防刷处理的，并且他们的x, y, z值就一样

如果我们的自定义注解还是只能加载方法上的话，一个一个接口加，那么无疑这是一种很呆的做法

要改的话，其实也很简单，首先是修改自定义注解，让其可以作用在类上

接着就是修改AccessLimitInterceptor的处理逻辑

AccessLimitInterceptor中代码修改的有点多，主要逻辑如下

与之前实现比较，不同点在于x, y, z的值要首先尝试在目标类中获取

其次，一旦类中标有此注解，即代表此类下所有接口方法都要进行防刷处理

如果其接口方法同样也标有此注解，根据就近优先原则，以接口方法中的注解标明的值为准

/**  * @description: 接口防刷拦截处理  */  
@Slf4j  
public class AccessLimintInterceptor implements HandlerInterceptor {  @Resource  private RedisTemplate<String, Object> redisTemplate;  /**  * 锁住时的key前缀  */  public static final String LOCK_PREFIX = "LOCK";  /**  * 统计次数时的key前缀  */  public static final String COUNT_PREFIX = "COUNT";  public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {  //      自定义注解 + 反射 实现， 版本 2.0  if (handler instanceof HandlerMethod) {  // 访问的是接口方法，转化为待访问的目标方法对象  HandlerMethod targetMethod = (HandlerMethod) handler;  // 获取目标接口方法所在类的注解@AccessLimit  AccessLimit targetClassAnnotation = targetMethod.getMethod().getDeclaringClass().getAnnotation(AccessLimit.class);  // 特别注意不能采用下面这条语句来获取，因为 Spring 采用的代理方式来代理目标方法  //  也就是说targetMethod.getClass()获得是class org.springframework.web.method.HandlerMethod ,而不知我们真正想要的 Controller  
//            AccessLimit targetClassAnnotation = targetMethod.getClass().getAnnotation(AccessLimit.class);  // 定义标记位，标记此类是否加了@AccessLimit注解  boolean isBrushForAllInterface = false;  String ip = request.getRemoteAddr();  String uri = request.getRequestURI();  long second = 0L;  long maxTime = 0L;  long forbiddenTime = 0L;  if (!Objects.isNull(targetClassAnnotation)) {  log.info("目标接口方法所在类上有@AccessLimit注解");  isBrushForAllInterface = true;  second = targetClassAnnotation.second();  maxTime = targetClassAnnotation.maxTime();  forbiddenTime = targetClassAnnotation.forbiddenTime();  }  // 取出目标方法中的 AccessLimit 注解  AccessLimit accessLimit = targetMethod.getMethodAnnotation(AccessLimit.class);  // 判断此方法接口是否要进行防刷处理  if (!Objects.isNull(accessLimit)) {  // 需要进行防刷处理，接下来是处理逻辑  second = accessLimit.second();  maxTime = accessLimit.maxTime();  forbiddenTime = accessLimit.forbiddenTime();  if (isForbindden(second, maxTime, forbiddenTime, ip, uri)) {  throw new CommonException(ResultCode.ACCESS_FREQUENT);  }  } else {  // 目标接口方法处无@AccessLimit注解，但还要看看其类上是否加了(类上有加，代表针对此类下所有接口方法都要进行防刷处理)  if (isBrushForAllInterface && isForbindden(second, maxTime, forbiddenTime, ip, uri)) {  throw new CommonException(ResultCode.ACCESS_FREQUENT);  }  }  }  return true;  }  /**  * 判断某用户访问某接口是否已经被禁用/是否需要禁用  *  * @param second        多长时间  单位/秒  * @param maxTime       最大访问次数  * @param forbiddenTime 禁用时长 单位/秒  * @param ip            访问者ip地址  * @param uri           访问的uri  * @return ture为需要禁用  */  private boolean isForbindden(long second, long maxTime, long forbiddenTime, String ip, String uri) {  String lockKey = LOCK_PREFIX + ip + uri; //如果此ip访问此uri被禁用时的存在Redis中的 key  Object isLock = redisTemplate.opsForValue().get(lockKey);  // 判断此ip用户访问此接口是否已经被禁用  if (Objects.isNull(isLock)) {  // 还未被禁用  String countKey = COUNT_PREFIX + ip + uri;  Object count = redisTemplate.opsForValue().get(countKey);  if (Objects.isNull(count)) {  // 首次访问  log.info("首次访问");  redisTemplate.opsForValue().set(countKey, 1, second, TimeUnit.SECONDS);  } else {  // 此用户前一点时间就访问过该接口，且频率没超过设置  if ((Integer) count < maxTime) {  redisTemplate.opsForValue().increment(countKey);  } else {  log.info("{}禁用访问{}", ip, uri);  // 禁用  redisTemplate.opsForValue().set(lockKey, 1, forbiddenTime, TimeUnit.SECONDS);  // 删除统计--已经禁用了就没必要存在了  redisTemplate.delete(countKey);  return true;  }  }  } else {  // 此用户访问此接口已被禁用  return true;  }  return false;  }  
}

好了，这样就达到我们想要的效果了