SpringBoot 如何進行限流?老鳥們都這麼玩的!

語言: CN / TW / HK

大家好,我是飄渺。SpringBoot老鳥系列的文章已經寫了四篇,每篇的閱讀反響都還不錯,那今天繼續給大家帶來老鳥系列的第五篇,來聊聊在SpringBoot專案中如何對介面進行限流,有哪些常見的限流演算法,如何優雅的進行限流(基於AOP)。

首先就讓我們來看看為什麼需要對介面進行限流?

為什麼要進行限流?

因為網際網路系統通常都要面對大併發大流量的請求,在突發情況下(最常見的場景就是秒殺、搶購),瞬時大流量會直接將系統打垮,無法對外提供服務。那為了防止出現這種情況最常見的解決方案之一就是限流,當請求達到一定的併發數或速率,就進行等待、排隊、降級、拒絕服務等。

例如,12306購票系統,在面對高併發的情況下,就是採用了限流。 在流量高峰期間經常會出現提示語;"當前排隊人數較多,請稍後再試!"

什麼是限流?有哪些限流演算法?

限流是對某一時間視窗內的請求數進行限制,保持系統的可用性和穩定性,防止因流量暴增而導致的系統執行緩慢或宕機。

常見的限流演算法有三種:

1. 計數器限流

計數器限流演算法是最為簡單粗暴的解決方案,主要用來限制總併發數,比如資料庫連線池大小、執行緒池大小、介面訪問併發數等都是使用計數器演算法。

如:使用 AomicInteger 來進行統計當前正在併發執行的次數,如果超過域值就直接拒絕請求,提示系統繁忙。

2. 漏桶演算法

image-20210925212319319

漏桶演算法思路很簡單,我們把水比作是請求,漏桶比作是系統處理能力極限,水先進入到漏桶裡,漏桶裡的水按一定速率流出,當流出的速率小於流入的速率時,由於漏桶容量有限,後續進入的水直接溢位(拒絕請求),以此實現限流。

3. 令牌桶演算法

image-20210925212233334

令牌桶演算法的原理也比較簡單,我們可以理解成醫院的掛號看病,只有拿到號以後才可以進行診病。

系統會維護一個令牌(token)桶,以一個恆定的速度往桶裡放入令牌(token),這時如果有請求進來想要被處理,則需要先從桶裡獲取一個令牌(token),當桶裡沒有令牌(token)可取時,則該請求將被拒絕服務。令牌桶演算法通過控制桶的容量、發放令牌的速率,來達到對請求的限制。

基於Guava工具類實現限流

Google開源工具包Guava提供了限流工具類RateLimiter,該類基於令牌桶演算法實現流量限制,使用十分方便,而且十分高效,實現步驟如下:

第一步:引入guava依賴包

<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>30.1-jre</version> </dependency>

第二步:給介面加上限流邏輯

``` @Slf4j @RestController @RequestMapping("/limit") public class LimitController { /* * 限流策略 : 1秒鐘2個請求 / private final RateLimiter limiter = RateLimiter.create(2.0);

private DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");

@GetMapping("/test1")
public String testLimiter() {
    //500毫秒內,沒拿到令牌,就直接進入服務降級
    boolean tryAcquire = limiter.tryAcquire(500, TimeUnit.MILLISECONDS);

    if (!tryAcquire) {
        log.warn("進入服務降級,時間{}", LocalDateTime.now().format(dtf));
        return "當前排隊人數較多,請稍後再試!";
    }

    log.info("獲取令牌成功,時間{}", LocalDateTime.now().format(dtf));
    return "請求成功";
}

} ```

以上用到了RateLimiter的2個核心方法:create()tryAcquire(),以下為詳細說明

  • acquire() 獲取一個令牌, 改方法會阻塞直到獲取到這一個令牌, 返回值為獲取到這個令牌花費的時間
  • acquire(int permits) 獲取指定數量的令牌, 該方法也會阻塞, 返回值為獲取到這 N 個令牌花費的時間
  • tryAcquire() 判斷時候能獲取到令牌, 如果不能獲取立即返回 false
  • tryAcquire(int permits) 獲取指定數量的令牌, 如果不能獲取立即返回 false
  • tryAcquire(long timeout, TimeUnit unit) 判斷能否在指定時間內獲取到令牌, 如果不能獲取立即返回 false
  • tryAcquire(int permits, long timeout, TimeUnit unit) 同上

第三步:體驗效果

通過訪問測試地址: http://127.0.0.1:8080/limit/test1,反覆重新整理並觀察後端日誌

```java WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37 WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37 INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:37 WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37 WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:37 INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:37

WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:38 INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:38 WARN LimitController:35 - 進入服務降級,時間2021-09-25 21:39:38 INFO LimitController:39 - 獲取令牌成功,時間2021-09-25 21:39:38 ```

從以上日誌可以看出,1秒鐘內只有2次成功,其他都失敗降級了,說明我們已經成功給介面加上了限流功能。

當然了,我們在實際開發中並不能直接這樣用。至於原因嘛,你想呀,你每個介面都需要手動給其加上tryAcquire(),業務程式碼和限流程式碼混在一起,而且明顯違背了DRY原則,程式碼冗餘,重複勞動。程式碼評審時肯定會被老鳥們給嘲笑一番,啥破玩意兒!

image-20210716084136689

所以,我們這裡需要想辦法將其優化 - 藉助自定義註解+AOP實現介面限流。

基於AOP實現介面限流

基於AOP的實現方式也非常簡單,實現過程如下:

第一步:加入AOP依賴

xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency>

第二步:自定義限流注解

```java @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.METHOD}) @Documented public @interface Limit { /* * 資源的key,唯一 * 作用:不同的介面,不同的流量控制 / String key() default "";

/**
 * 最多的訪問限制次數
 */
double permitsPerSecond () ;

/**
 * 獲取令牌最大等待時間
 */
long timeout();

/**
 * 獲取令牌最大等待時間,單位(例:分鐘/秒/毫秒) 預設:毫秒
 */
TimeUnit timeunit() default TimeUnit.MILLISECONDS;

/**
 * 得不到令牌的提示語
 */
String msg() default "系統繁忙,請稍後再試.";

} ```

第三步:使用AOP切面攔截限流注解

```java @Slf4j @Aspect @Component public class LimitAop { /* * 不同的介面,不同的流量控制 * map的key為 Limiter.key / private final Map limitMap = Maps.newConcurrentMap();

@Around("@annotation(com.jianzh5.blog.limit.Limit)")
public Object around(ProceedingJoinPoint joinPoint) throws Throwable{
    MethodSignature signature = (MethodSignature) joinPoint.getSignature();
    Method method = signature.getMethod();
    //拿limit的註解
    Limit limit = method.getAnnotation(Limit.class);
    if (limit != null) {
        //key作用:不同的介面,不同的流量控制
        String key=limit.key();
        RateLimiter rateLimiter = null;
        //驗證快取是否有命中key
        if (!limitMap.containsKey(key)) {
            // 建立令牌桶
            rateLimiter = RateLimiter.create(limit.permitsPerSecond());
            limitMap.put(key, rateLimiter);
            log.info("新建了令牌桶={},容量={}",key,limit.permitsPerSecond());
        }
        rateLimiter = limitMap.get(key);
        // 拿令牌
        boolean acquire = rateLimiter.tryAcquire(limit.timeout(), limit.timeunit());
        // 拿不到命令,直接返回異常提示
        if (!acquire) {
            log.debug("令牌桶={},獲取令牌失敗",key);
            this.responseFail(limit.msg());
            return null;
        }
    }
    return joinPoint.proceed();
}

/**
 * 直接向前端丟擲異常
 * @param msg 提示資訊
 */
private void responseFail(String msg)  {
    HttpServletResponse response=((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getResponse();
    ResultData<Object> resultData = ResultData.fail(ReturnCode.LIMIT_ERROR.getCode(), msg);
    WebUtils.writeJson(response,resultData);
}

} ```

第四步:給需要限流的介面加上註解

```java @Slf4j @RestController @RequestMapping("/limit") public class LimitController {

@GetMapping("/test2")
@Limit(key = "limit2", permitsPerSecond = 1, timeout = 500, timeunit = TimeUnit.MILLISECONDS,msg = "當前排隊人數較多,請稍後再試!")
public String limit2() {
    log.info("令牌桶limit2獲取令牌成功");
    return "ok";
}


@GetMapping("/test3")
@Limit(key = "limit3", permitsPerSecond = 2, timeout = 500, timeunit = TimeUnit.MILLISECONDS,msg = "系統繁忙,請稍後再試!")
public String limit3() {
    log.info("令牌桶limit3獲取令牌成功");
    return "ok";
}

} ```

第五步:體驗效果

通過訪問測試地址: http://127.0.0.1:8080/limit/test2,反覆重新整理並觀察輸出結果:

正常響應時:

json {"status":100,"message":"操作成功","data":"ok","timestamp":1632579377104}

觸發限流時:

json {"status":2001,"message":"系統繁忙,請稍後再試!","data":null,"timestamp":1632579332177}

通過觀察得之,基於自定義註解同樣實現了介面限流的效果。

小結

一般在系統上線時我們通過對系統壓測可以評估出系統的效能閥值,然後給介面加上合理的限流引數,防止出現大流量請求時直接壓垮系統。今天我們介紹了幾種常見的限流演算法(重點關注令牌桶演算法),基於Guava工具類實現了介面限流並利用AOP完成了對限流程式碼的優化。

在完成優化後業務程式碼和限流程式碼解耦,開發人員只要一個註解,不用關心限流的實現邏輯,而且減少了程式碼冗餘大大提高了程式碼可讀性,程式碼評審時誰還能再笑話你?

好了,今天的文章到此就結束了,最後,我是飄渺Jam,一名寫程式碼的架構師,做架構的程式設計師,期待您的轉發與關注,當然也歡迎通過下方二維碼新增我的個人微信,咱們一起聊技術!

老鳥系列原始碼已經上傳至GitHub,需要的在公號【JAVA日知錄】回覆關鍵字 0923 獲取原始碼地址。