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

常见的谬误设计

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

1. 固定窗口

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

2. 缓存工夫更新谬误

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

// core logicint 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。

为什么抉择Redis zset ?

为了统计固定工夫区间内的拜访频率,如果是单机程序,可能采纳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一样的数值即可。

限流过程是怎么样的?

整个流程如下:

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

基于SpringBoot和AOP的限流

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

定义注解和解决逻辑

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

/**   * 接口拜访频率注解,默认一分钟只能拜访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@Log4j2public 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 20232023-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 20232023-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 20232023-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:12023-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:12023-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 20232023-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 20232023-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 20232023-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.1142023-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.1142023-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

欢送关注公众号【码老思】,只讲最通俗易懂的原创技术干货。