今天我們繼續(xù)看看Guava，其中比較常用的限流工具RateLimiter

Guava RateLimiter

有沒有搞錯，別人都在提升系統(tǒng)的訪問并發(fā)量，你卻在這搞限制？

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

簡介

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

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

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

核心

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

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

應用場景

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

限流方法

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

• 計數(shù)限流

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

• 固定窗口

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

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

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

• 滑動窗口

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

比如時間單元為1s，每個時間窗口為100ms，在1秒內(nèi)的10個時間窗口可以為09:01:01.00009:01:02.000、09:01:01.20009:01:02.800...

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

• 漏桶算法

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

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

• 令牌桶算法

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

實現(xiàn)示例

固定窗口

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

    /**
     * 時間單元內(nèi)的閾值
     */
    private long limit;

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

    /**
     * 計數(shù)器
     */
    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;
        }
        // 在一個時間單元內(nèi)
        if(now - startTime <= timeUnit){
            count ++;
            return count <= limit;
        }else{// 超過時間單元、
            startTime = now;
            count = 0;
            return true;
        }
    }

Guava RateLimiter

• 令牌桶算法實現(xiàn)
• 支持預熱
• 支持突發(fā)流量

創(chuàng)建RateLimiter，每秒發(fā)放6個令牌，平均間隔167ms一個，其中有3秒的預熱期

RateLimiter rateLimiter = RateLimiter.create(
            6, // 每秒發(fā)放令牌數(shù)量
            3, // 預熱期，在預熱期后逐步達到配置的令牌發(fā)放數(shù)量
            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));
            }
        }
    }

結(jié)果：大約3秒后進入平穩(wěn)期

第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

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

結(jié)束語

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