人人都能看懂的 6 種限流實現方案！(純乾貨)

時間 2020-05-19

標籤人人看懂限流實現方案乾貨简体版

原文原文鏈接

爲了上班方便，去年我把本身在北郊的房子租出去了，搬到了南郊，這樣離我上班的地方就近了，它爲我節約了不少的時間成本，我能夠用它來作不少有意義的事，最起碼不會由於堵車而鬧心了，幸福感直線上升。html

但即便這樣，生活也有其餘的煩惱。南郊的居住密度比較大，所以停車就成了頭痛的事，我租的是路兩邊的非固定車位，每次只要下班回來，必定是沒有車位停了，所以我只能和別人的車並排停着，但這樣帶來的問題是，我天天早上都要被挪車的電話給叫醒，心情天然就不用說了。java

但後來幾天，我就慢慢變聰明瞭，我頭天晚上停車的時候，會找次日限行的車並排停着，這樣我次日就不用挪車了，這真是限行給我帶來的「巨大紅利」啊。redis

而車輛限行就是一種生活中很常見的限流策略，他除了給我帶來了以上的好處以外，還給咱們美好的生活環境帶來了一絲改善，而且快速增加的私家車已經給咱們的交通帶來了巨大的「負擔」，若是再不限行，可能全部的車都要被堵在路上，這就是限流給咱們的生活帶來的巨大好處。算法

從生活回到程序中，假設一個系統只能爲 10W 人提供服務，忽然有一天由於某個熱點事件，形成了系統短期內的訪問量迅速增長到了 50W，那麼致使的直接結果是系統崩潰，任何人都不能用系統了，顯然只有少人數能用遠比全部人都不能用更符合咱們的預期，所以這個時候咱們要使用「限流」了。後端

限流分類

限流的實現方案有不少種，磊哥這裏稍微理了一下，限流的分類以下所示：bash

合法性驗證限流：好比驗證碼、IP 黑名單等，這些手段能夠有效的防止惡意攻擊和爬蟲採集；
容器限流：好比 Tomcat、Nginx 等限流手段，其中 Tomcat 能夠設置最大線程數（maxThreads），當併發超過最大線程數會排隊等待執行；而 Nginx 提供了兩種限流手段：一是控制速率，二是控制併發鏈接數；
服務端限流：好比咱們在服務器端經過限流算法實現限流，此項也是咱們本文介紹的重點。

合法性驗證限流爲最常規的業務代碼，就是普通的驗證碼和 IP 黑名單系統，本文就不作過多的敘述了，咱們重點來看下後兩種限流的實現方案：容器限流和服務端限流。服務器

容器限流

Tomcat 限流

Tomcat 8.5 版本的最大線程數在 conf/server.xml 配置中，以下所示：併發

<Connector port="8080" protocol="HTTP/1.1"
          connectionTimeout="20000"
          maxThreads="150"
          redirectPort="8443" />
複製代碼

其中 maxThreads 就是 Tomcat 的最大線程數，當請求的併發大於此值（maxThreads）時，請求就會排隊執行，這樣就完成了限流的目的。框架

小貼士：maxThreads 的值能夠適當的調大一些，此值默認爲 150（Tomcat 版本 8.5.42），但這個值也不是越大越好，要看具體的硬件配置，須要注意的是每開啓一個線程須要耗用 1MB 的 JVM 內存空間用於做爲線程棧之用，而且線程越多 GC 的負擔也越重。最後須要注意一下，操做系統對於進程中的線程數有必定的限制，Windows 每一個進程中的線程數不容許超過 2000，Linux 每一個進程中的線程數不容許超過 1000。分佈式

Nginx 限流

Nginx 提供了兩種限流手段：一是控制速率，二是控制併發鏈接數。

控制速率

咱們須要使用 limit_req_zone 用來限制單位時間內的請求數，即速率限制，示例配置以下：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit;
    }
}
複製代碼

以上配置表示，限制每一個 IP 訪問的速度爲 2r/s，由於 Nginx 的限流統計是基於毫秒的，咱們設置的速度是 2r/s，轉換一下就是 500ms 內單個 IP 只容許經過 1 個請求，從 501ms 開始才容許經過第 2 個請求。

咱們使用單 IP 在 10ms 內發併發送了 6 個請求的執行結果以下：

從以上結果能夠看出他的執行符合咱們的預期，只有 1 個執行成功了，其餘的 5 個被拒絕了（第 2 個在 501ms 纔會被正常執行）。

速率限制升級版

上面的速率控制雖然很精準可是應用於真實環境未免太苛刻了，真實狀況下咱們應該控制一個 IP 單位總時間內的總訪問次數，而不是像上面那麼精確但毫秒，咱們可使用 burst 關鍵字開啓此設置，示例配置以下：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit burst=4;
    }
}
複製代碼

burst=4 表示每一個 IP 最多容許4個突發請求，若是單個 IP 在 10ms 內發送 6 次請求的結果以下：

從以上結果能夠看出，有 1 個請求被當即處理了，4 個請求被放到 burst 隊列裏排隊執行了，另外 1 個請求被拒絕了。

控制併發數

利用 limit_conn_zone 和 limit_conn 兩個指令便可控制併發數，示例配置以下：

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;
server {
    ...
    limit_conn perip 10;
    limit_conn perserver 100;
}
複製代碼

其中 limit_conn perip 10 表示限制單個 IP 同時最多能持有 10 個鏈接；limit_conn perserver 100 表示 server 同時能處理併發鏈接的總數爲 100 個。

小貼士：只有當 request header 被後端處理後，這個鏈接才進行計數。

服務端限流

服務端限流須要配合限流的算法來執行，而算法至關於執行限流的「大腦」，用於指導限制方案的實現。

有人看到「算法」兩個字可能就暈了，以爲很深奧，其實並非。算法就至關於操做某個事務的具體實現步驟彙總，其實並不難懂，不要被它的表象給嚇到哦~

限流的常見算法有如下三種：

時間窗口算法
漏桶算法
令牌算法

接下來咱們分別看來。

1.時間窗口算法

所謂的滑動時間算法指的是以當前時間爲截止時間，往前取必定的時間，好比往前取 60s 的時間，在這 60s 以內運行最大的訪問數爲 100，此時算法的執行邏輯爲，先清除 60s 以前的全部請求記錄，再計算當前集合內請求數量是否大於設定的最大請求數 100，若是大於則執行限流拒絕策略，不然插入本次請求記錄並返回能夠正常執行的標識給客戶端。

滑動時間窗口以下圖所示：

其中每一小個表示 10s，被紅色虛線包圍的時間段則爲須要判斷的時間間隔，好比 60s 秒容許 100 次請求，那麼紅色虛線部分則爲 60s。

咱們能夠藉助 Redis 的有序集合 ZSet 來實現時間窗口算法限流，實現的過程是先使用 ZSet 的 key 存儲限流的 ID，score 用來存儲請求的時間，每次有請求訪問來了以後，先清空以前時間窗口的訪問量，統計如今時間窗口的個數和最大容許訪問量對比，若是大於等於最大訪問量則返回 false 執行限流操做，負責容許執行業務邏輯，而且在 ZSet 中添加一條有效的訪問記錄，具體實現代碼以下。

咱們藉助 Jedis 包來操做 Redis，實如今 pom.xml 添加 Jedis 框架的引用，配置以下：

<!-- https://mvnrepository.com/artifact/redis.clients/jedis -->
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>3.3.0</version>
</dependency>
複製代碼

具體的 Java 實現代碼以下：

import redis.clients.jedis.Jedis;

public class RedisLimit {
    // Redis 操做客戶端
    static Jedis jedis = new Jedis("127.0.0.1", 6379);

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 15; i++) {
            boolean res = isPeriodLimiting("java", 3, 10);
            if (res) {
                System.out.println("正常執行請求：" + i);
            } else {
                System.out.println("被限流：" + i);
            }
        }
        // 休眠 4s
        Thread.sleep(4000);
        // 超過最大執行時間以後，再從發起請求
        boolean res = isPeriodLimiting("java", 3, 10);
        if (res) {
            System.out.println("休眠後，正常執行請求");
        } else {
            System.out.println("休眠後，被限流");
        }
    }

    /**
     * 限流方法（滑動時間算法）
     * @param key      限流標識
     * @param period   限流時間範圍（單位：秒）
     * @param maxCount 最大運行訪問次數
     * @return
     */
    private static boolean isPeriodLimiting(String key, int period, int maxCount) {
        long nowTs = System.currentTimeMillis(); // 當前時間戳
        // 刪除非時間段內的請求數據（清除老訪問數據，好比 period=60 時，標識清除 60s 之前的請求記錄）
        jedis.zremrangeByScore(key, 0, nowTs - period * 1000);
        long currCount = jedis.zcard(key); // 當前請求次數
        if (currCount >= maxCount) {
            // 超過最大請求次數，執行限流
            return false;
        }
        // 未達到最大請求數，正常執行業務
        jedis.zadd(key, nowTs, "" + nowTs); // 請求記錄 +1
        return true;
    }
}
複製代碼

以上程序的執行結果爲：

正常執行請求：0

正常執行請求：1

正常執行請求：2

正常執行請求：3

正常執行請求：4

正常執行請求：5

正常執行請求：6

正常執行請求：7

正常執行請求：8

正常執行請求：9

被限流：10

被限流：11

被限流：12

被限流：13

被限流：14

休眠後，正常執行請求

此實現方式存在的缺點有兩個：

使用 ZSet 存儲有每次的訪問記錄，若是數據量比較大時會佔用大量的空間，好比 60s 容許 100W 訪問時；
此代碼的執行非原子操做，先判斷後增長，中間空隙可穿插其餘業務邏輯的執行，最終致使結果不許確。

2.漏桶算法

漏桶算法的靈感源於漏斗，以下圖所示：

滑動時間算法有一個問題就是在必定範圍內，好比 60s 內只能有 10 個請求，當第一秒時就到達了 10 個請求，那麼剩下的 59s 只能把全部的請求都給拒絕掉，而漏桶算法能夠解決這個問題。

漏桶算法相似於生活中的漏斗，不管上面的水流倒入漏斗有多大，也就是不管請求有多少，它都是以均勻的速度慢慢流出的。當上面的水流速度大於下面的流出速度時，漏斗會慢慢變滿，當漏斗滿了以後就會丟棄新來的請求;當上面的水流速度小於下面流出的速度的話，漏斗永遠不會被裝滿，而且能夠一直流出。

漏桶算法的實現步驟是，先聲明一個隊列用來保存請求，這個隊列至關於漏斗，當隊列容量滿了以後就放棄新來的請求，而後從新聲明一個線程按期從任務隊列中獲取一個或多個任務進行執行，這樣就實現了漏桶算法。

上面咱們演示 Nginx 的控制速率其實使用的就是漏桶算法，固然咱們也能夠藉助 Redis 很方便的實現漏桶算法。

咱們可使用 Redis 4.0 版本中提供的 Redis-Cell 模塊，該模塊使用的是漏斗算法，而且提供了原子的限流指令，並且依靠 Redis 這個天生的分佈式程序就能夠實現比較完美的限流了。

Redis-Cell 實現限流的方法也很簡單，只須要使用一條指令 cl.throttle 便可，使用示例以下：

> cl.throttle mylimit 15 30 60
1）（integer）0 # 0 表示獲取成功，1 表示拒絕
2）（integer）15 # 漏斗容量
3）（integer）14 # 漏斗剩餘容量
4）（integer）-1 # 被拒絕以後，多長時間以後再試（單位：秒）-1 表示無需重試
5）（integer）2 # 多久以後漏斗徹底空出來
複製代碼

其中 15 爲漏斗的容量，30 / 60s 爲漏斗的速率。

3.令牌算法

在令牌桶算法中有一個程序以某種恆定的速度生成令牌，並存入令牌桶中，而每一個請求須要先獲取令牌才能執行，若是沒有獲取到令牌的請求能夠選擇等待或者放棄執行，以下圖所示：

咱們可使用 Google 開源的 guava 包，很方便的實現令牌桶算法，首先在 pom.xml 添加 guava 引用，配置以下：

<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>28.2-jre</version>
</dependency>
複製代碼

具體實現代碼以下：

import com.google.common.util.concurrent.RateLimiter;

import java.time.Instant;

/**
 * Guava 實現限流
 */
public class RateLimiterExample {
    public static void main(String[] args) {
        // 每秒產生 10 個令牌（每 100 ms 產生一個）
        RateLimiter rt = RateLimiter.create(10);
        for (int i = 0; i < 11; i++) {
            new Thread(() -> {
                // 獲取 1 個令牌
                rt.acquire();
                System.out.println("正常執行方法，ts:" + Instant.now());
            }).start();
        }
    }
}
複製代碼

以上程序的執行結果爲：

正常執行方法，ts:2020-05-15T14:46:37.175Z

正常執行方法，ts:2020-05-15T14:46:37.237Z

正常執行方法，ts:2020-05-15T14:46:37.339Z

正常執行方法，ts:2020-05-15T14:46:37.442Z

正常執行方法，ts:2020-05-15T14:46:37.542Z

正常執行方法，ts:2020-05-15T14:46:37.640Z

正常執行方法，ts:2020-05-15T14:46:37.741Z

正常執行方法，ts:2020-05-15T14:46:37.840Z

正常執行方法，ts:2020-05-15T14:46:37.942Z

正常執行方法，ts:2020-05-15T14:46:38.042Z

正常執行方法，ts:2020-05-15T14:46:38.142Z

從以上結果能夠看出令牌確實是每 100ms 產生一個，而 acquire() 方法爲阻塞等待獲取令牌，它能夠傳遞一個 int 類型的參數，用於指定獲取令牌的個數。它的替代方法還有 tryAcquire()，此方法在沒有可用令牌時就會返回 false 這樣就不會阻塞等待了。固然 tryAcquire() 方法也能夠設置超時時間，未超過最大等待時間會阻塞等待獲取令牌，若是超過了最大等待時間，尚未可用的令牌就會返回 false。

注意：使用 guava 實現的令牌算法屬於程序級別的單機限流方案，而上面使用 Redis-Cell 的是分佈式的限流方案。

總結

本文提供了 6 種具體的實現限流的手段，他們分別是：Tomcat 使用 maxThreads 來實現限流；Nginx 提供了兩種限流方式，一是經過 limit_req_zone 和 burst 來實現速率限流，二是經過 limit_conn_zone 和 limit_conn 兩個指令控制併發鏈接的總數。最後咱們講了時間窗口算法藉助 Redis 的有序集合能夠實現，還有漏桶算法可使用 Redis-Cell 來實現，以及令牌算法能夠解決 Google 的 guava 包來實現。

須要注意的是藉助 Redis 實現的限流方案可用於分佈式系統，而 guava 實現的限流只能應用於單機環境。若是你嫌棄服務器端限流麻煩，甚至能夠在不改代碼的狀況下直接使用容器限流（Nginx 或 Tomcat），但前提是能知足你的業務需求。

好了，文章到這裏就結束了，期待咱們下期再會~

最後的話

原創不易，若是以爲本文對你有用，請隨手點擊一個「贊」，這是對做者最大的支持與鼓勵，謝謝你！