正文

最近在基于SpringBoot做一個面向普通用戶的系統(tǒng)，為了保證系統(tǒng)的穩(wěn)定性，防止被惡意攻擊，我想控制用戶訪問每個接口的頻率。為了實現(xiàn)這個功能，可以設(shè)計一個annotation，然后借助AOP在調(diào)用方法之前檢查當(dāng)前ip的訪問頻率，如果超過設(shè)定頻率，直接返回錯誤信息。

常見的錯誤設(shè)計

在開始介紹具體實現(xiàn)之前，我先列舉幾種我在網(wǎng)上找到的幾種常見錯誤設(shè)計。

1. 固定窗口

有人設(shè)計了一個在每分鐘內(nèi)只允許訪問1000次的限流方案，如下圖01:00s-02:00s之間只允許訪問1000次，這種設(shè)計最大的問題在于，請求可能在01:59s-02:00s之間被請求1000次，02:00s-02:01s之間被請求了1000次，這種情況下01:59s-02:01s間隔0.02s之間被請求2000次，很顯然這種設(shè)計是錯誤的。

2. 緩存時間更新錯誤

我在研究這個問題的時候，發(fā)現(xiàn)網(wǎng)上有一種很常見的方式來進行限流，思路是基于redis，每次有用戶的request進來，就會去以用戶的ip和request的url為key去判斷訪問次數(shù)是否超標，如果有就返回錯誤，否則就把redis中的key對應(yīng)的value加1，并重新設(shè)置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的緩存過期時間，這樣相當(dāng)于變相延長了每個計數(shù)周期， 可能我們想控制用戶一分鐘內(nèi)只能訪問5次，但是如果用戶在前一分鐘只訪問了三次，后一分鐘訪問了三次，在上面的實現(xiàn)里面，很可能在第6次訪問的時候返回錯誤，但這樣是有問題的，因為用戶確實在兩分鐘內(nèi)都沒有超過對應(yīng)的訪問頻率閾值。

關(guān)于key的刷新這塊，可以參看redis官方文檔，每次refreh都會更新key的過期時間。

基于滑動窗口的正確設(shè)計

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

比如在上面的例子里面，假設(shè)用戶的要求是60s內(nèi)訪問頻率控制為3次。那么我永遠只會統(tǒng)計當(dāng)前時間往前倒數(shù)60s之內(nèi)的訪問次數(shù)，隨著時間的推移，整個窗口會不斷向前移動，窗口外的請求不會計算在內(nèi)，保證了永遠只統(tǒng)計當(dāng)前60s內(nèi)的request。

為什么選擇Redis zset ？

為了統(tǒng)計固定時間區(qū)間內(nèi)的訪問頻率，如果是單機程序，可能采用concurrentHashMap就夠了，但是如果是分布式的程序，我們需要引入相應(yīng)的分布式組件來進行計數(shù)統(tǒng)計，而Redis zset剛好能夠滿足我們的需求。

Redis zset（有序集合）中的成員是有序排列的，它和 set 集合的相同之處在于，集合中的每一個成員都是字符串類型，并且不允許重復(fù)；而它們最大區(qū)別是，有序集合是有序的，set 是無序的，這是因為有序集合中每個成員都會關(guān)聯(lián)一個 double（雙精度浮點數(shù)）類型的 score (分數(shù)值)，Redis 正是通過 score 實現(xiàn)了對集合成員的排序。

Redis 使用以下命令創(chuàng)建一個有序集合：

ZADD key score member [score member ...]

這里面有三個重要參數(shù)，

• key：指定一個鍵名；
• score：分數(shù)值，用來描述  member，它是實現(xiàn)排序的關(guān)鍵；
• member：要添加的成員（元素）。

當(dāng) key 不存在時，將會創(chuàng)建一個新的有序集合，并把分數(shù)/成員（score/member）添加到有序集合中；當(dāng) key 存在時，但 key 并非 zset 類型，此時就不能完成添加成員的操作，同時會返回一個錯誤提示。

在我們這個場景里面，key就是用戶ip+request uri，score直接用當(dāng)前時間的毫秒數(shù)表示，至于member不重要，可以也采用和score一樣的數(shù)值即可。

限流過程是怎么樣的？

整個流程如下：

• 首先用戶的請求進來，將用戶ip和uri組成key，timestamp為value，放入zset
• 更新當(dāng)前key的緩存過期時間，這一步主要是為了定期清理掉冷數(shù)據(jù)，和上面我提到的常見錯誤設(shè)計2中的意義不同。
• 刪除窗口之外的數(shù)據(jù)記錄。
• 統(tǒng)計當(dāng)前窗口中的總記錄數(shù)。
• 如果記錄數(shù)大于閾值，則直接返回錯誤，否則正常處理用戶請求。

基于SpringBoot和AOP的限流

這一部分主要介紹具體的實現(xiàn)邏輯。

定義注解和處理邏輯

首先是定義一個注解，方便后續(xù)對不同接口使用不同的限制頻率。

/**  
 * 接口訪問頻率注解，默認一分鐘只能訪問5次  
 */  
@Documented  
@Target(ElementType.METHOD)  
@Retention(RetentionPolicy.RUNTIME)  
public @interface RequestLimit {  
    // 限制時間 單位：秒(默認值：一分鐘）  
    long period() default 60;  
    // 允許請求的次數(shù)(默認值：5次）  
    long count() default 5;  
}

在實現(xiàn)邏輯這塊，我們定義一個切面函數(shù)，攔截用戶的request，具體實現(xiàn)流程和上面介紹的限流流程一致，主要涉及到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);  
    }  
}

我接著在不同機器上，訪問該接口，可以看到不同機器的限流是隔離的，并且每臺機器在周期之內(nèi)只能訪問三次，超過后，需要等待一定時間才能繼續(xù)訪問，達到了我們預(yù)期的效果。

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

以上就是SpringBoot限制接口訪問頻率避坑的詳細內(nèi)容，更多關(guān)于SpringBoot接口訪問限制的資料請關(guān)注腳本之家其它相關(guān)文章！