SpringBoot限制接口訪問頻率 - 這些錯誤千萬不能犯

最近在基於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次,很顯然這種設計是錯誤的。

jm36ts

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的過期時間。
EEB8ry

基於滑動窗口的正確設計

指定時間T內,只允許發生N次。我們可以將這個指定時間T,看成一個滑動時間窗口(定寬)。我們採用Redis的zset基本數據類型的score來圈出這個滑動時間窗口。在實際操作zset的過程中,我們只需要保留在這個滑動時間窗口以內的數據,其他的數據不處理即可。

WKdTZ9

比如在上面的例子裏面,假設用戶的要求是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. 如果記錄數大於閾值,則直接返回錯誤,否則正常處理用戶請求。

e0tcMj

基於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

歡迎關注公衆號【碼老思】,只講最通俗易懂的原創技術乾貨。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章