常见的错误设计
在开始介绍具体实现之前,我先列举几种我在网上找到的几种常见错误设计。
1. 固定窗口
2. 缓存时间更新错误
// 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次访问的时候返回错误,但这样是有问题的,因为用户确实在两分钟内都没有超过对应的访问频率阈值。
基于滑动窗口的正确设计
为什么选择Redis zset ?
为了统计固定时间区间内的访问频率,如果是单机程序,可能采用concurrentHashMap就够了,但是如果是分布式的程序,我们需要引入相应的分布式组件来进行计数统计,而Redis zset刚好能够满足我们的需求。
Redis 使用以下命令创建一个有序集合:
ZADD key score member [score member ...]
这里面有三个重要参数,
- key:指定一个键名;
- score:分数值,用来描述 member,它是实现排序的关键;
- member:要添加的成员(元素)。
在我们这个场景里面,key就是用户ip+request uri
,score直接用当前时间的毫秒数表示,至于member不重要,可以也采用和score一样的数值即可。
限流过程是怎么样的?
- 首先用户的请求进来,将用户ip和uri组成key,timestamp为value,放入zset
- 更新当前key的缓存过期时间,这一步主要是为了定期清理掉冷数据,和上面我提到的常见错误设计2中的意义不同。
- 删除窗口之外的数据记录。
- 统计当前窗口中的总记录数。
- 如果记录数大于阈值,则直接返回错误,否则正常处理用户请求。
基于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
@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
欢迎关注公众号【码老思】,只讲最通俗易懂的原创技术干货。