最近在基於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 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。
爲什麼選擇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一樣的數值即可。
限流過程是怎麼樣的?
整個流程如下:
- 首先用戶的請求進來,將用戶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
歡迎關注公衆號【碼老思】,只講最通俗易懂的原創技術乾貨。