前言

分散式環境下應對高併發保證服務穩定幾招，按照個人理解，優先順序從高到低分別為快取、限流、降級、熔斷，每招都有它的作用，本文重點就講講限流這部分。

坦白講，其實上面的說法也不準確，因為服務降級、熔斷本身也是限流的一種，因為它們本質上也是阻斷了流量進來，但是本文希望大家可以把限流當做一個單純的名詞來理解，看一下對請求做流控的幾種演算法及具體實現方式。

為什麼要限流

其實很好理解的一個問題，為什麼要限流，自然就流量過大了唄，一個對外服務有很多場景都會流量增大：

• 業務使用者量不斷攀升
• 各種促銷
• 網路爬蟲
• 惡意刷單

注意這個"大"，1000QPS大嗎？5000QPS大嗎？10000QPS大麼？沒有答案，因為沒有標準，因此，"大"一定是和正常流量相比的大。流量一大，伺服器扛不住，扛不住就掛了，掛了沒法提供對外服務導致業務直接熔斷。怎麼辦，最直接的辦法就是從源頭把流量限制下來，例如伺服器只有支撐1000QPS的處理能力，那就每秒放1000個請求，自然保證了伺服器的穩定，這就是限流。

下面看一下常見的兩種限流演算法。

漏桶演算法

漏桶演算法的原理比較簡單，水（請求）先進入到漏桶裡，人為設定一個最大出水速率，漏桶以<=出水速率的速度出水，當水流入速度過大會直接溢位（拒絕服務）：

因此，這個演算法的核心為：

• 存下請求
• 勻速處理
• 多於丟棄

因此這是一種強行限制請求速率的方式，但是缺點非常明顯，主要有兩點：

• 無法面對突發的大流量----比如請求處理速率為1000，容量為5000，來了一波2000/s的請求持續10s，那麼後5s的請求將全部直接被丟棄，伺服器拒絕服務，但是實際上網路中突發一波大流量尤其是短時間的大流量是非常正常的，超過容量就拒絕，非常簡單粗暴
• 無法有效利用網路資源----比如雖然伺服器的處理能力是1000/s，但這不是絕對的，這個1000只是一個巨集觀伺服器處理能力的數字，實際上一共5秒，每秒請求量分別為1200、1300、1200、500、800，平均下來qps也是1000/s，但是這個量對伺服器來說完全是可以接受的，但是因為限制了速率是1000/s，因此前面的三秒，每秒只能處理掉1000個請求而一共打回了700個請求，白白浪費了伺服器資源

所以，通常來說利用漏桶演算法來限流，實際場景下用得不多。

令牌桶演算法

令牌桶演算法是網路流量整形（Traffic Shaping）和限流（Rate Limiting）中最常使用的一種演算法，它可用於控制傳送到網路上資料的數量並允許突發資料的傳送。

從某種意義上來說，令牌桶演算法是對漏桶演算法的一種改進，主要在於令牌桶演算法能夠在限制呼叫的平均速率的同時還允許一定程度的突發呼叫，來看下令牌桶演算法的實現原理：

整個的過程是這樣的：

• 系統以恆定的速率產生令牌，然後將令牌放入令牌桶中
• 令牌桶有一個容量，當令牌桶滿了的時候，再向其中放入的令牌就會被丟棄
• 每次一個請求過來，需要從令牌桶中獲取一個令牌，假設有令牌，那麼提供服務；假設沒有令牌，那麼拒絕服務

那麼，我們再看一下，為什麼令牌桶演算法可以防止一定程度的突發流量呢？可以這麼理解，假設我們想要的速率是1000QPS，那麼往桶中放令牌的速度就是1000個/s，假設第1秒只有800個請求，那意味著第2秒可以容許1200個請求，這就是一定程度突發流量的意思，反之我們看漏桶演算法，第一秒只有800個請求，那麼全部放過，第二秒這1200個請求將會被打回200個。

注意上面多次提到一定程度這四個字，這也是我認為令牌桶演算法最需要注意的一個點。假設還是1000QPS的速率，那麼5秒鐘放1000個令牌，第1秒鐘800個請求過來，第2~4秒沒有請求，那麼按照令牌桶演算法，第5秒鐘可以接受4200個請求，但是實際上這已經遠遠超出了系統的承載能力，因此使用令牌桶演算法特別注意設定桶中令牌的上限即可。

總而言之，作為對漏桶演算法的改進，令牌桶演算法在限流場景下被使用更加廣泛。

RateLimiter使用

上面說了令牌桶演算法在限流場景下被使用更加廣泛，接下來我們看一下程式碼示例，模擬一下每秒最多過五個請求：

public class RateLimiterTest {

    private static final SimpleDateFormat FORMATTER = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    
    private static final int THREAD_COUNT = 25;
    
    @Test
    public void testRateLimiter1() {
        RateLimiter rateLimiter = RateLimiter.create(5);
        
        Thread[] ts = new Thread[THREAD_COUNT];
        for (int i = 0; i < THREAD_COUNT; i++) {
            ts[i] = new Thread(new RateLimiterThread(rateLimiter), "RateLimiterThread-" + i);
        }
        
        for (int i = 0; i < THREAD_COUNT; i++) {
            ts[i].start();
        }
        
        for (;;);
    }
    
    public class RateLimiterThread implements Runnable {
        
        private RateLimiter rateLimiter;
        
        public RateLimiterThread(RateLimiter rateLimiter) {
            this.rateLimiter = rateLimiter;
        }
        
        @Override
        public void run() {
            rateLimiter.acquire(1);
            
            System.out.println(Thread.currentThread().getName() + "獲取到了令牌，時間 = " + FORMATTER.format(new Date()));
        }
        
    }
    
}

利用RateLimiter.create這個構造方法可以指定每秒向桶中放幾個令牌，比方說上面的程式碼create(5)，那麼每秒放置5個令牌，即200ms會向令牌桶中放置一個令牌。這邊程式碼寫了一條執行緒模擬實際場景，拿到令牌那麼就能執行下面邏輯，看一下程式碼執行結果：

RateLimiterThread-0獲取到了令牌，時間 = 2019-08-25 20:58:53
RateLimiterThread-23獲取到了令牌，時間 = 2019-08-25 20:58:54
RateLimiterThread-21獲取到了令牌，時間 = 2019-08-25 20:58:54
RateLimiterThread-19獲取到了令牌，時間 = 2019-08-25 20:58:54
RateLimiterThread-17獲取到了令牌，時間 = 2019-08-25 20:58:54
RateLimiterThread-13獲取到了令牌，時間 = 2019-08-25 20:58:54
RateLimiterThread-9獲取到了令牌，時間 = 2019-08-25 20:58:55
RateLimiterThread-15獲取到了令牌，時間 = 2019-08-25 20:58:55
RateLimiterThread-5獲取到了令牌，時間 = 2019-08-25 20:58:55
RateLimiterThread-1獲取到了令牌，時間 = 2019-08-25 20:58:55
RateLimiterThread-11獲取到了令牌，時間 = 2019-08-25 20:58:55
RateLimiterThread-7獲取到了令牌，時間 = 2019-08-25 20:58:56
RateLimiterThread-3獲取到了令牌，時間 = 2019-08-25 20:58:56
RateLimiterThread-4獲取到了令牌，時間 = 2019-08-25 20:58:56
RateLimiterThread-8獲取到了令牌，時間 = 2019-08-25 20:58:56
RateLimiterThread-12獲取到了令牌，時間 = 2019-08-25 20:58:56
RateLimiterThread-16獲取到了令牌，時間 = 2019-08-25 20:58:57
RateLimiterThread-20獲取到了令牌，時間 = 2019-08-25 20:58:57
RateLimiterThread-24獲取到了令牌，時間 = 2019-08-25 20:58:57
RateLimiterThread-2獲取到了令牌，時間 = 2019-08-25 20:58:57
RateLimiterThread-6獲取到了令牌，時間 = 2019-08-25 20:58:57
RateLimiterThread-10獲取到了令牌，時間 = 2019-08-25 20:58:58
RateLimiterThread-14獲取到了令牌，時間 = 2019-08-25 20:58:58
RateLimiterThread-18獲取到了令牌，時間 = 2019-08-25 20:58:58
RateLimiterThread-22獲取到了令牌，時間 = 2019-08-25 20:58:58

看到，非常標準，在每次消耗一個令牌的情況下，RateLimiter可以保證每一秒內最多隻有5個執行緒獲取到令牌，使用這種方式可以很好的做單機對請求的QPS數控制。

至於為什麼2019-08-25 20:58:53這個時間點只有1條執行緒獲取到了令牌而不是有5條執行緒獲取到令牌，因為RateLimiter是按照秒計數的，可能第一個執行緒是2019-08-25 20:58:53.999秒來的，算在2019-08-25 20:58:53這一秒內；下一個執行緒2019-08-25 20:58:54.001秒來，自然就算到2019-08-25 20:58:54這一秒去了。

上面的寫法是RateLimiter最常用的寫法，注意：

• acquire是阻塞的且會一直等待到獲取令牌為止，它有一個返回值為double型，意思是從阻塞開始到獲取到令牌的等待時間，單位為秒
• tryAcquire是另外一個方法，它可以指定超時時間，返回值為boolean型，即假設執行緒等待了指定時間後仍然沒有獲取到令牌，那麼就會返回給客戶端false，客戶端根據自身情況是打回給前臺錯誤還是定時重試

RateLimiter預消費

處理請求，每次來一個請求就acquire一把是RateLimiter最常見的用法，但是我們看acquire還有個acquire(int permits)的過載方法，即允許每次獲取多個令牌數。這也是有可能的，請求數是一個大維度每次扣減1，有可能伺服器按照位元組數來進行限流，例如每秒最多處理10000位元組的資料，那每次扣減的就不止1了。

接著我們再看一段程式碼示例：

@Test
public void testRateLimiter2() {
    RateLimiter rateLimiter = RateLimiter.create(1);
        
    System.out.println("獲取1個令牌開始，時間為" + FORMATTER.format(new Date()));
    double cost = rateLimiter.acquire(1);
    System.out.println("獲取1個令牌結束，時間為" + FORMATTER.format(new Date()) + ", 耗時" + cost + "ms");
    System.out.println("獲取5個令牌開始，時間為" + FORMATTER.format(new Date()));
    cost = rateLimiter.acquire(5);
    System.out.println("獲取5個令牌結束，時間為" + FORMATTER.format(new Date()) + ", 耗時" + cost + "ms");
    System.out.println("獲取3個令牌開始，時間為" + FORMATTER.format(new Date()));
    cost = rateLimiter.acquire(3);
    System.out.println("獲取3個令牌結束，時間為" + FORMATTER.format(new Date()) + ", 耗時" + cost + "ms");
}

程式碼執行結果為：

獲取1個令牌開始，時間為2019-08-25 21:21:09.973
獲取1個令牌結束，時間為2019-08-25 21:21:09.976, 耗時0.0ms
獲取5個令牌開始，時間為2019-08-25 21:21:09.976
獲取5個令牌結束，時間為2019-08-25 21:21:10.974, 耗時0.997237ms
獲取3個令牌開始，時間為2019-08-25 21:21:10.976
獲取3個令牌結束，時間為2019-08-25 21:21:15.974, 耗時4.996529ms

看到這就是標題所說的預消費能力，也是RateLimiter中允許一定程度突發流量的實現方式。第二次需要獲取5個令牌，指定的是每秒放1個令牌到桶中，我們發現實際上並沒有等5秒鐘等桶中積累了5個令牌才能讓第二次acquire成功，而是直接等了1秒鐘就成功了。我們可以捋一捋這個邏輯：

• 第一次請求過來需要獲取1個令牌，直接拿到
• RateLimiter在1秒鐘後放一個令牌，第一次請求預支的1個令牌還上了
• 1秒鐘之後第二次請求過來需要獲得5個令牌，直接拿到
• RateLimiter在花了5秒鐘放了5個令牌，還上了第二次請求預支的5個令牌
• 第三個請求在5秒鐘之後拿到3個令牌

也就是說，前面的請求如果流量大於每秒放置令牌的數量，那麼允許處理，但是帶來的結果就是後面的請求延後處理，從而在整體上達到一個平衡整體處理速率的效果。

突發流量的處理，在令牌桶演算法中有兩種方式，一種是有足夠的令牌才能消費，一種是先消費後還令牌。後者就像我們0首付買車似的，30萬的車很少有等攢到30萬才全款買的，先簽了相關合同把車子給你，然後貸款慢慢還，這樣就爽了。RateLimiter也是同樣的道理，先讓請求得到處理，再慢慢還上預支的令牌，客戶端同樣也爽了，否則我假設預支60個令牌，1分鐘之後才能處理我的請求，不合理也不人性化。

RateLimiter的限制

特別注意RateLimiter是單機的，也就是說它無法跨JVM使用，設定的1000QPS，那也在單機中保證平均1000QPS的流量。

假設叢集中部署了10臺伺服器，想要保證叢集1000QPS的介面呼叫量，那麼RateLimiter就不適用了，叢集流控最常見的方法是使用強大的Redis：

• 一種是固定視窗的計數，例如當前是2019/8/26 20:05:00，就往這個"2019/8/26 20:05:00"這個key進行incr，當前是2019/8/26 20:05:01，就往"2019/8/26 20:05:01"這個key進行incr，incr後的結果只要大於我們設定的值，那麼就打回去，小於就相當於獲取到了執行許可權
• 一種是結合lua指令碼，實現分散式的令牌桶演算法，網上實現還是比較多的，可以參考https://blog.csdn.net/sunlihuo/article/details/79700225這篇文章

總得來說，叢集限流的實現也比較簡單。

總結

本文主要寫了常見的兩種限流演算法漏桶演算法與令牌桶演算法，並且演示了Guava中RateLimiter的實現，相信看到這裡的朋友一定都懂了，恭喜你們！

令牌桶演算法是最常用的限流演算法，它最大的特點就是容許一定程度的突發流量。

漏桶演算法同樣也有自己的應用之處，例如Nginx的限流模組就是基於漏桶演算法的，它最大的特點就是強行限制流量按照指定的比例下發，適合那種對流量有絕對要求的場景，就是流量可以容許在我指定的值之下，可以被多次打回，但是無論如何決不能超過指定的。

雖然令牌桶演算法相對更好，但是還是我經常說的，使用哪種完全就看大家各自的場景，適合的才是最好的。

&n