关于java:SpringBoot限制接口访问频率-这些错误千万不能犯

6次阅读

共计 5880 个字符，预计需要花费 15 分钟才能阅读完成。

最近在基于 SpringBoot 做一个面向普通用户的零碎，为了保证系统的稳定性，避免被歹意攻打，我想管制用户拜访每个接口的频率。为了实现这个性能，能够设计一个 annotation，而后借助 AOP 在调用办法之前查看以后 ip 的拜访频率，如果超过设定频率，间接返回错误信息。

在开始介绍具体实现之前，我先列举几种我在网上找到的几种常见谬误设计。

有人设计了一个在每分钟内只容许拜访 1000 次的限流计划，如下图 01:00s-02:00s 之间只容许拜访 1000 次，这种设计最大的问题在于，申请可能在 01:59s-02:00s 之间被申请 1000 次，02:00s-02:01s 之间被申请了 1000 次，这种状况下 01:59s-02:01s 距离 0.02s 之间被申请 2000 次，很显然这种设计是谬误的。

我在钻研这个问题的时候，发现网上有一种很常见的形式来进行限流，思路是基于 redis，每次有用户的 request 进来，就会去以用户的 ip 和 request 的 url 为 key 去判断拜访次数是否超标，如果有就返回谬误，否则就把 redis 中的 key 对应的 value 加 1，并从新设置 key 的过期工夫为用户指定的拜访周期。外围代码如下：

// core logic
int limit = accessLimit.limit();
long sec = accessLimit.sec();
String key = IPUtils.getIpAddr(request) + request.getRequestURI();
Integer maxLimit =null;
Object value =redisService.get(key);
if(value!=null && !value.equals("")) {maxLimit = Integer.valueOf(String.valueOf(value));
}
if (maxLimit == null) {redisService.set(key, "1", sec);
} else if (maxLimit < limit) {
    Integer i = maxLimit+1;
    redisService.set(key, i.toString(), sec);
} else {throw new BusinessException(500,"申请太频繁!");
}

// redis related
    public boolean set(final String key, Object value, Long expireTime) {
        boolean result = false;
        try {ValueOperations<Serializable, Object> operations = redisTemplate.opsForValue();
            operations.set(key, value);
            redisTemplate.expire(key, expireTime, TimeUnit.SECONDS);
            result = true;
        } catch (Exception e) {e.printStackTrace();
        }
        return result;
    }

这外面很大的问题，就是 每次都会更新 key 的缓存过期工夫，这样相当于变相缩短了每个计数周期， 可能咱们想管制用户一分钟内只能拜访 5 次，然而如果用户在前一分钟只拜访了三次，后一分钟拜访了三次，在下面的实现外面，很可能在第 6 次访问的时候返回谬误，但这样是有问题的，因为用户的确在两分钟内都没有超过对应的拜访频率阈值。

对于 key 的刷新这块，能够参看 redis 官网文档，每次 refreh 都会更新 key 的过期工夫。

指定工夫 T 内，只容许产生 N 次。咱们能够将这个指定工夫 T，看成一个滑动工夫窗口（定宽）。咱们采纳 Redis 的 zset 根本数据类型的 score 来圈出这个滑动工夫窗口。在实际操作 zset 的过程中，咱们只须要保留在这个滑动工夫窗口以内的数据，其余的数据不解决即可。

比方在下面的例子外面，假如用户的要求是 60s 内拜访频率管制为 3 次。那么我永远只会统计以后工夫往前倒数 60s 之内的拜访次数，随着工夫的推移，整个窗口会一直向前挪动，窗口外的申请不会计算在内，保障了永远只统计以后 60s 内的 request。

为了统计固定工夫区间内的拜访频率，如果是单机程序，可能采纳 concurrentHashMap 就够了，然而如果是分布式的程序，咱们须要引入相应的分布式组件来进行计数统计，而 Redis zset 刚好可能满足咱们的需要。

Redis zset（有序汇合）中的成员是有序排列的，它和 set 汇合的相同之处在于，汇合中的每一个成员都是字符串类型，并且不容许反复；而它们最大区别是，有序汇合是有序的，set 是无序的，这是因为有序汇合中每个成员都会关联一个 double（双精度浮点数）类型的 score (分数值)，Redis 正是通过 score 实现了对汇合成员的排序。

Redis 应用以下命令创立一个有序汇合：

ZADD key score member [score member ...]

这外面有三个重要参数，

key：指定一个键名；
score：分数值，用来形容 member，它是实现排序的要害；
member：要增加的成员（元素）。

当 key 不存在时，将会创立一个新的有序汇合，并把分数 / 成员（score/member）增加到有序汇合中；当 key 存在时，但 key 并非 zset 类型，此时就不能实现增加成员的操作，同时会返回一个谬误提醒。

在咱们这个场景外面，key 就是 用户 ip+request uri，score 间接用以后工夫的毫秒数示意，至于 member 不重要，能够也采纳和 score 一样的数值即可。

整个流程如下：

首先用户的申请进来，将用户 ip 和 uri 组成 key，timestamp 为 value，放入 zset
更新以后 key 的缓存过期工夫，这一步次要是为了定期清理掉冷数据，和下面我提到的常见谬误设计 2 中的意义不同。
删除窗口之外的数据记录。
统计以后窗口中的总记录数。
如果记录数大于阈值，则间接返回谬误，否则失常解决用户申请。

这一部分次要介绍具体的实现逻辑。

首先是定义一个注解，不便后续对不同接口应用不同的限度频率。

/**  
 * 接口拜访频率注解，默认一分钟只能拜访 5 次  
 */  
@Documented  
@Target(ElementType.METHOD)  
@Retention(RetentionPolicy.RUNTIME)  
public @interface RequestLimit {  
  
    // 限度工夫 单位：秒(默认值：一分钟）long period() default 60;  
  
    // 容许申请的次数(默认值：5 次）long count() default 5;}

在实现逻辑这块，咱们定义一个切面函数，拦挡用户的 request，具体实现流程和下面介绍的限流流程统一，次要波及到 redis zset 的操作。


@Aspect
@Component
@Log4j2
public class RequestLimitAspect {

    @Autowired
    RedisTemplate redisTemplate;

    // 切点
    @Pointcut("@annotation(requestLimit)")
    public void controllerAspect(RequestLimit requestLimit) {}

    @Around("controllerAspect(requestLimit)")
    public Object doAround(ProceedingJoinPoint joinPoint, RequestLimit requestLimit) throws Throwable {
        // get parameter from annotation
        long period = requestLimit.period();
        long limitCount = requestLimit.count();

        // request info
        String ip = RequestUtil.getClientIpAddress();
        String uri = RequestUtil.getRequestUri();
        String key = "req_limit_".concat(uri).concat(ip);

        ZSetOperations zSetOperations = redisTemplate.opsForZSet();

        // add current timestamp
        long currentMs = System.currentTimeMillis();
        zSetOperations.add(key, currentMs, currentMs);

        // set the expiration time for the code user
        redisTemplate.expire(key, period, TimeUnit.SECONDS);

        // remove the value that out of current window
        zSetOperations.removeRangeByScore(key, 0, currentMs - period * 1000);

        // check all available count
        Long count = zSetOperations.zCard(key);

        if (count > limitCount) {log.error("接口拦挡：{} 申请超过限度频率【{}次 /{}s】,IP 为{}", uri, limitCount, period, ip);
            throw new AuroraRuntimeException(ResponseCode.TOO_FREQUENT_VISIT);
        }

        // execute the user request
        return  joinPoint.proceed();}

}

这里我定义了一个接口类来做测试，应用下面的 annotation 来实现限流，每分钟容许用户拜访 3 次。

@Log4j2  
@RestController  
@RequestMapping("/user")  
public class UserController {@GetMapping("/test")  
    @RequestLimit(count = 3)  
    public GenericResponse<String> testRequestLimit() {log.info("current time:" + new Date());  
        return new GenericResponse<>(ResponseCode.SUCCESS);  
    }  
  
}

我接着在不同机器上，拜访该接口，能够看到不同机器的限流是隔离的，并且每台机器在周期之内只能拜访三次，超过后，须要期待肯定工夫能力持续拜访，达到了咱们预期的成果。

2023-05-21 11:23:15.733  INFO 99636 --- [nio-8080-exec-1] c.v.c.a.api.controller.UserController    : current time: Sun May 21 11:23:15 CST 2023
2023-05-21 11:23:21.848  INFO 99636 --- [nio-8080-exec-3] c.v.c.a.api.controller.UserController    : current time: Sun May 21 11:23:21 CST 2023
2023-05-21 11:23:23.044  INFO 99636 --- [nio-8080-exec-4] c.v.c.a.api.controller.UserController    : current time: Sun May 21 11:23:23 CST 2023
2023-05-21 11:23:25.920 ERROR 99636 --- [nio-8080-exec-5] c.v.c.a.annotation.RequestLimitAspect    : 接口拦挡：/user/test 申请超过限度频率【3 次 /60s】,IP 为 0:0:0:0:0:0:0:1
2023-05-21 11:23:28.761 ERROR 99636 --- [nio-8080-exec-6] c.v.c.a.annotation.RequestLimitAspect    : 接口拦挡：/user/test 申请超过限度频率【3 次 /60s】,IP 为 0:0:0:0:0:0:0:1
2023-05-21 11:24:12.207  INFO 99636 --- [io-8080-exec-10] c.v.c.a.api.controller.UserController    : current time: Sun May 21 11:24:12 CST 2023
2023-05-21 11:24:19.100  INFO 99636 --- [nio-8080-exec-2] c.v.c.a.api.controller.UserController    : current time: Sun May 21 11:24:19 CST 2023
2023-05-21 11:24:20.117  INFO 99636 --- [nio-8080-exec-1] c.v.c.a.api.controller.UserController    : current time: Sun May 21 11:24:20 CST 2023
2023-05-21 11:24:21.146 ERROR 99636 --- [nio-8080-exec-3] c.v.c.a.annotation.RequestLimitAspect    : 接口拦挡：/user/test 申请超过限度频率【3 次 /60s】,IP 为 192.168.31.114
2023-05-21 11:24:26.779 ERROR 99636 --- [nio-8080-exec-4] c.v.c.a.annotation.RequestLimitAspect    : 接口拦挡：/user/test 申请超过限度频率【3 次 /60s】,IP 为 192.168.31.114
2023-05-21 11:24:29.344 ERROR 99636 --- [nio-8080-exec-5] c.v.c.a.annotation.RequestLimitAspect    : 接口拦挡：/user/test 申请超过限度频率【3 次 /60s】,IP 为 192.168.31.114