Guava RateLimiter

有沒有搞錯，別人都在提升系統的訪問并發量，你卻在這搞限制？

我們都知道，服務器資源是有限的，當把應用部署在外網環境中，所有人都可以訪問你的應用，如果訪問人數上去了，你的服務器是否能夠支持足夠量的用戶訪問？在系統訪問高峰時期， 僅從代碼層面提供系統并發量，系統真的就能夠支持突然流量的沖擊？顯然是不可能的，如果誰讓你在不改變硬件配置的情況下，無限制的提高系統性能，你可以說他在白日做夢。

簡介

限流器顧名思義，就是對流量的限制，準確的說應該是流量控制，當然并不是無理由的進行流量控制，應該是在計算機硬件能夠承載的范圍內，防止系統突然流量過高導致系統資源耗盡，最終 系統宕機或崩潰，使得服務器上的應用全部掛掉。限流器是在保證應用能夠正常提供服務的前提下，通過流量控制實現對服務的一種保護手段。

當然流量的閾值到底是多少比較合適，這個可能需要根據實際硬件配置、系統環境以前其他相關參數經過各種測試與驗證才能知道...

本篇文章僅討論限流中相關的技術，在實際應用中使用的限流器，除了包含流量限制的作用，為了提高用戶體驗，還需要對流量超出是，做出對應的應對策略，比如直接拒絕服務，讓請求進行排隊 ，或者服務降級都是比較好的處理手段，這樣既能給用戶友好地體驗，又能保證服務正常。

核心

有幾個核心概念需要先了解到：

• 限流的目標對象：請求數量、網絡流量、用戶訪問次數...
• 限流的維度：時間、IP、用戶
• 限流的實現層面：前端頁面、WEB代理、服務接口...

應用場景

1. 防止服務接口短時間涌入大量請求導致服務器資源快速耗盡最終服務無法訪問
2. 突發流量時通過排隊策略實現流量削峰，杜絕對服務器的沖擊
3. 針對ip、或用戶控制對某個資源的訪問次數
4. 針對高頻接口，控制單位時間內允許的請求次數
5. 結合ip或其他因子防爬蟲

限流方法

這里我們主要討論后端基于請求量的限流，限流是一種非常廣泛的應用技術，就比如你在登錄系統時，經常會需要你輸入手機驗證、動態碼或一些奇奇怪怪的驗證方式， 來降低登錄請求的頻次。

• 計數限流

按數量進行控制，達到設置的閾值則進行限流，其中固定窗口，滑動窗口則是通過該方法實現。

• 固定窗口

通過控制時間單元內允許的請求數量，一旦達到閾值，則不會處理該請求后續相關的業務或者直接讓請求快速失敗并給予提示。

比如我們配置10s內允許請求的流量為1000，在第1~9s內請求為0，在第9~10秒內的請求數為1000，這樣一秒內的請求就達到了1000。當然我們可以時間單元劃分成更小粒度， 但是應該多小才合適呢？

問題：只能對時間單元內的總請求數進行控制，當請求集中在較小時間范圍內時，無法達到流量限制的效果，因此這是一種粗粒度的流量限制手段

• 滑動窗口

為了解決固定窗口算法中存在的問題，通過滑動窗口的方法，將上述時間單元劃分成多個細粒度的時間窗口，每個窗口都有自己獨立的請求計數器，這樣就可以讓時間單元內的流量控制均勻地 落在各個時間窗口上，同時滑動的時間窗口可以形成連續時間區間控制，并不像固定窗口那樣只在兩個時間刻度間。

比如時間單元為1s，每個時間窗口為100ms，在1秒內的10個時間窗口可以為09:01:01.000~09:01:02.000、09:01:01.200~09:01:02.800...

問題：滑動窗口的區間劃分的越多，則滑動窗口的滾動就越平滑，限流的統計就會越精確，但也需要更多的資源為窗口時間片段保存計數器，從而耗費系統資源

• 漏桶算法

如果將請求看成水滴，限流器看成一個下面開口的桶（漏桶）。漏桶算法其實就是當水滴（請求）先進入到漏桶里，漏桶以一定的速度出水，當水流入速度過大時則會超過桶的可接納容量， 這時水將直接溢出，漏桶算法能強行限制數據的傳輸速率。使用漏桶算法，可以保證接口會以一個常速速率來處理請求，所以漏桶算法必定不會出現臨界問題。

問題：當短時間內如果有大量的突發請求時，即使服務器負載不高，每個請求也需要等待一段時間（水滴間隔）才能被響應

• 令牌桶算法

令牌桶算法會以一個恒定的速度往桶里放入令牌，而如果請求需要被處理，則需要先從桶里獲取一個令牌，當桶里沒有令牌可取時，則拒絕服務。相比“漏桶算法”，“令牌桶算法”能夠在限制數據的平均傳輸速率的同時，還允許能應對流量突增的情況（允許突發請求，只要有足夠的令牌，支持一次拿多個令牌）。

實現示例

固定窗口

public class FixedWindowLimiter {
    /**
     * 時間單元 ms
     */
    private long timeUnit;

    /**
     * 時間單元內的閾值
     */
    private long limit;

    /**
     * 開始時間
     */
    private long startTime;

    /**
     * 計數器
     */
    private long count;

    public FixedWindowLimiter(long timeUnit, long limit) {
        this.timeUnit = timeUnit;
        this.limit = limit;
    }

    /**
     *
     * @return
     */
    public synchronized boolean acquire(){
        long now = System.currentTimeMillis();
        // 開始
        if( startTime == 0 ){
            startTime = now;
            count ++;
            return true;
        }
        // 在一個時間單元內
        if(now - startTime <= timeUnit){
            count ++;
            return count <= limit;
        }else{// 超過時間單元、
            startTime = now;
            count = 0;
            return true;
        }
    }

Guava RateLimiter

• 令牌桶算法實現
• 支持預熱
• 支持突發流量

創建RateLimiter，每秒發放6個令牌，平均間隔167ms一個，其中有3秒的預熱期

    RateLimiter rateLimiter = RateLimiter.create(
            6, // 每秒發放令牌數量
            3, // 預熱期，在預熱期后逐步達到配置的令牌發放數量
            TimeUnit.SECONDS // 時間單位
    );

使用RateLimiter

    @Test
    public void limit() throws InterruptedException {
        Stopwatch stopwatch = Stopwatch.createStarted();
        long last;
        for (int i=0; i < 100; i++){
            last = stopwatch.elapsed(TimeUnit.MILLISECONDS);
            rateLimiter.acquire();
            long duration = stopwatch.elapsed(TimeUnit.MILLISECONDS);
            System.out.println( String.format("第%s次，距離開始的時間：%sms，間隔時間：%sms", i, duration, duration-last));

            if( i == 20 ){
                // 中間暫停5秒，看看申請令牌的時間間隔變化
                TimeUnit.SECONDS.sleep(5);
                System.out.println("暫停5秒后...");
                long last2 = stopwatch.elapsed(TimeUnit.MILLISECONDS);
                rateLimiter.acquire(10);
                long duration2 = stopwatch.elapsed(TimeUnit.MILLISECONDS);
                System.out.println( String.format("第%s次，距離開始的時間：%sms，間隔時間：%sms", i, duration2, duration2-last2));
            }
        }
    }

結果：大約3秒后進入平穩期

第0次，距離開始的時間：0ms，間隔時間：0ms
第1次，距離開始的時間：483ms，間隔時間：483ms
第2次，距離開始的時間：926ms，間隔時間：443ms
第3次，距離開始的時間：1334ms，間隔時間：408ms
第4次，距離開始的時間：1703ms，間隔時間：369ms
第5次，距離開始的時間：2036ms，間隔時間：333ms
第6次，距離開始的時間：2333ms，間隔時間：297ms
第7次，距離開始的時間：2592ms，間隔時間：259ms
第8次，距離開始的時間：2815ms，間隔時間：223ms
第9次，距離開始的時間：2999ms，間隔時間：184ms
第10次，距離開始的時間：3166ms，間隔時間：167ms
第11次，距離開始的時間：3333ms，間隔時間：167ms
第12次，距離開始的時間：3500ms，間隔時間：167ms
第13次，距離開始的時間：3666ms，間隔時間：166ms
...
暫停5秒后...
第20次，距離開始的時間：9842ms，間隔時間：0ms
第21次，距離開始的時間：13009ms，間隔時間：3166ms
第22次，距離開始的時間：13176ms，間隔時間：167ms
第23次，距離開始的時間：13342ms，間隔時間：166ms
第24次，距離開始的時間：13510ms，間隔時間：168ms
第25次，距離開始的時間：13676ms，間隔時間：166ms
第26次，距離開始的時間：13843ms，間隔時間：167ms
第27次，距離開始的時間：14009ms，間隔時間：166ms

• 預熱期 系統剛啟動或者長時間沒有收到請求時，限流器處于冷卻狀態,在預熱期間獲取令牌的時間會比平穩期獲取令牌的時間要長，隨著令牌的減少，獲取單個令牌的時間會慢慢變短，最終到達一個穩定值
• acquire acquire是一個阻塞方法，通過RateLimiter會得到一個阻塞時間值
• tryAcquire 非阻塞方法，快速返回令牌申請結果

結束語

作為微服務服務保證的三大利器，限流、熔斷、降級，了解其大概的大概的含義是非常有必要的，雖然現在有很多封裝好的限流框架，比如Sentinel、Resilience4j等，但技術是沒有止境的，當你往下探索 時，更多不可思議的知識，后面有機會我們從源碼，更底層來認識這些技術與設計思想。