不會高并發系統限流，肯定進不了大廠！
開濤大神在博客中說過：在開發高并發系統時有三把利器用來保護系統：緩存、降級和限流。本文結合作者的一些經驗介紹限流的相關概念、算法和常規的實現方式。
圖片來自 Pexel
緩存
緩存比較好理解，在大型高并發系統中，如果沒有緩存數據庫將分分鐘被爆，系統也會瞬間癱瘓。
使用緩存不單單能夠提升系統訪問速度、提高并發訪問量，也是保護數據庫、保護系統的有效方式。大型網站一般主要是“讀”，緩存的使用很容易被想到。
在大型“寫”系統中，緩存也常常扮演著非常重要的角色。比如累積一些數據批量寫入，內存里面的緩存隊列(生產消費)，以及 HBase 寫數據的機制等等也都是通過緩存提升系統的吞吐量或者實現系統的保護措施。
甚至消息中間件，你也可以認為是一種分布式的數據緩存。
降級
服務降級是當服務器壓力劇增的情況下，根據當前業務情況及流量對一些服務和頁面有策略的降級，以此釋放服務器資源以保證核心任務的正常運行。
降級往往會指定不同的級別，面臨不同的異常等級執行不同的處理。根據服務方式：可以拒接服務，可以延遲服務，也有時候可以隨機服務。
根據服務范圍：可以砍掉某個功能，也可以砍掉某些模塊。總之服務降級需要根據不同的業務需求采用不同的降級策略。主要的目的就是服務雖然有損但是總比沒有好。
限流
限流可以認為是服務降級的一種，限流就是限制系統的輸入和輸出流量以達到保護系統的目的。
一般來說，系統的吞吐量是可以被測算的，為了保證系統的穩定運行，一旦達到需要限制的閾值，就需要限制流量并采取一些措施以完成限制流量的目的。
比如：延遲處理，拒絕處理，或者部分拒絕處理等等。
限流的算法
常見的限流算法有：計數器、漏桶和令牌桶算法。
計數器
計數器是最簡單粗暴的算法。比如某個服務最多只能每秒鐘處理 100 個請求。
我們可以設置一個 1 秒鐘的滑動窗口，窗口中有 10 個格子，每個格子 100 毫秒，每 100 毫秒移動一次，每次移動都需要記錄當前服務請求的次數。
內存中需要保存 10 次的次數，可以用數據結構 LinkedList 來實現。格子每次移動的時候判斷一次，當前訪問次數和 LinkedList 中最后一個相差是否超過 100，如果超過就需要限流了。
很明顯，當滑動窗口的格子劃分的越多，那么滑動窗口的滾動就越平滑，限流的統計就會越精確。
示例代碼如下：
- //服務訪問次數，可以放在Redis中，實現分布式系統的訪問計數
- Long counter = 0L;
- //使用LinkedList來記錄滑動窗口的10個格子。
- LinkedList<Long> ll = new LinkedList<Long>();
- public static void main(String[] args)
- {
- Counter counter = new Counter();
- counter.doCheck();
- }
- private void doCheck()
- {
- while (true)
- {
- ll.addLast(counter);
- if (ll.size() > 10)
- {
- ll.removeFirst();
- }
- //比較最后一個和第一個，兩者相差一秒
- if ((ll.peekLast() - ll.peekFirst()) > 100)
- {
- //To limit rate
- }
- Thread.sleep(100);
- }
- }
漏桶算法
漏桶算法即 leaky bucket 是一種非常常用的限流算法，可以用來實現流量整形(Traffic Shaping)和流量控制(Traffic Policing)。
貼了一張維基百科上示意圖幫助大家理解：
漏桶算法的主要概念如下：
- 一個固定容量的漏桶，按照常量固定速率流出水滴。
- 如果桶是空的，則不需流出水滴。
- 可以以任意速率流入水滴到漏桶。
- 如果流入水滴超出了桶的容量，則流入的水滴溢出了(被丟棄)，而漏桶容量是不變的。
漏桶算法比較好實現，在單機系統中可以使用隊列來實現(.Net 中 TPL DataFlow 可以較好的處理類似的問題，你可以在這里找到相關的介紹)，在分布式環境中消息中間件或者 Redis 都是可選的方案。
令牌桶算法
令牌桶算法是一個存放固定容量令牌(token)的桶，按照固定速率往桶里添加令牌。
令牌桶算法基本可以用下面的幾個概念來描述：
- 令牌將按照固定的速率被放入令牌桶中。比如每秒放 10 個。
- 桶中最多存放 b 個令牌，當桶滿時，新添加的令牌被丟棄或拒絕。
- 當一個 n 個字節大小的數據包到達，將從桶中刪除 n 個令牌，接著數據包被發送到網絡上。
- 如果桶中的令牌不足 n 個，則不會刪除令牌，且該數據包將被限流(要么丟棄，要么緩沖區等待)。
如下圖：
令牌算法是根據放令牌的速率去控制輸出的速率，也就是上圖的 to network 的速率。to network 我們可以理解為消息的處理程序，執行某段業務或者調用某個 RPC。
漏桶和令牌桶的比較
令牌桶可以在運行時控制和調整數據處理的速率，處理某時的突發流量。
放令牌的頻率增加可以提升整體數據處理的速度，而通過每次獲取令牌的個數增加或者放慢令牌的發放速度可以降低整體數據處理速度。
而漏桶不行，因為它的流出速率是固定的，程序處理速度也是固定的。整體而言，令牌桶算法更優，但是實現更為復雜一些。
限流算法實現
Guava
Guava 是一個 Google 開源項目，包含了若干被 Google 的 Java 項目廣泛依賴的核心庫，其中的 RateLimiter 提供了令牌桶算法實現：平滑突發限流(SmoothBursty)和平滑預熱限流(SmoothWarmingUp)實現。
①常規速率：創建一個限流器，設置每秒放置的令牌數：2 個。
返回的 RateLimiter 對象可以保證 1 秒內不會給超過 2 個令牌，并且是固定速率的放置。達到平滑輸出的效果：
- public void test()
- {
- /**
- * 創建一個限流器，設置每秒放置的令牌數：2個。速率是每秒可以2個的消息。
- * 返回的RateLimiter對象可以保證1秒內不會給超過2個令牌，并且是固定速率的放置。達到平滑輸出的效果
- */
- RateLimiter r = RateLimiter.create(2);
- while (true)
- {
- /**
- * acquire()獲取一個令牌，并且返回這個獲取這個令牌所需要的時間。如果桶里沒有令牌則等待，直到有令牌。
- * acquire(N)可以獲取多個令牌。
- */
- System.out.println(r.acquire());
- }
- }
上面代碼執行的結果如下圖，基本是 0.5 秒一個數據。拿到令牌后才能處理數據，達到輸出數據或者調用接口的平滑效果。
acquire() 的返回值是等待令牌的時間，如果需要對某些突發的流量進行處理的話，可以對這個返回值設置一個閾值，根據不同的情況進行處理，比如過期丟棄。
②突發流量：突發流量可以是突發的多，也可以是突發的少。首先來看個突發多的例子。還是上面例子的流量，每秒 2 個數據令牌。
如下代碼使用 acquire 方法，指定參數：
- System.out.println(r.acquire(2));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
得到如下類似的輸出。
如果要一次新處理更多的數據，則需要更多的令牌。代碼首先獲取 2 個令牌，那么下一個令牌就不是 0.5 秒之后獲得了，還是 1 秒以后，之后又恢復常規速度。
這是一個突發多的例子，如果是突發沒有流量，如下代碼：
- System.out.println(r.acquire(1));
- Thread.sleep(2000);
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
得到如下類似的結果：
等了兩秒鐘之后，令牌桶里面就積累了 3 個令牌，可以連續不花時間的獲取出來。處理突發其實也就是在單位時間內輸出恒定。
這兩種方式都是使用的 RateLimiter 的子類 SmoothBursty。另一個子類是 SmoothWarmingUp，它提供的有一定緩沖的流量輸出方案。
- /**
- * 創建一個限流器，設置每秒放置的令牌數：2個。速率是每秒可以210的消息。
- * 返回的RateLimiter對象可以保證1秒內不會給超過2個令牌，并且是固定速率的放置。達到平滑輸出的效果
- * 設置緩沖時間為3秒
- */
- RateLimiter r = RateLimiter.create(2,3,TimeUnit.SECONDS);
- while (true) {
- /**
- * acquire()獲取一個令牌，并且返回這個獲取這個令牌所需要的時間。如果桶里沒有令牌則等待，直到有令牌。
- * acquire(N)可以獲取多個令牌。
- */
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- }
輸出結果如下圖，由于設置了緩沖的時間是 3 秒，令牌桶一開始并不會 0.5 秒給一個消息，而是形成一個平滑線性下降的坡度，頻率越來越高，在 3 秒鐘之內達到原本設置的頻率，以后就以固定的頻率輸出。
圖中紅線圈出來的 3 次累加起來正好是 3 秒左右。這種功能適合系統剛啟動需要一點時間來“熱身”的場景。
Nginx
對于 Nginx 接入層限流可以使用 Nginx 自帶的兩個模塊：
- 連接數限流模塊：ngx_http_limit_conn_module
- 漏桶算法實現的請求限流模塊：ngx_http_limit_req_module
①ngx_http_limit_conn_module
我們經常會遇到這種情況，服務器流量異常，負載過大等等。對于大流量惡意的攻擊訪問，會帶來帶寬的浪費，服務器壓力，影響業務，往往考慮對同一個 IP 的連接數，并發數進行限制。
ngx_http_limit_conn_module 模塊來實現該需求。該模塊可以根據定義的鍵來限制每個鍵值的連接數，如同一個 IP 來源的連接數。
并不是所有的連接都會被該模塊計數，只有那些正在被處理的請求(這些請求的頭信息已被完全讀入)所在的連接才會被計數。
我們可以在 nginx_conf 的 http{} 中加上如下配置實現限制：
- #限制每個用戶的并發連接數，取名one
- limit_conn_zone $binary_remote_addr zone=one:10m;
- #配置記錄被限流后的日志級別，默認error級別
- limit_conn_log_level error;
- #配置被限流后返回的狀態碼，默認返回503
- limit_conn_status 503;
然后在 server{} 里加上如下代碼：
- #限制用戶并發連接數為1
- limit_conn one 1;
然后我們是使用 ab 測試來模擬并發請求：
ab -n 5 -c 5 http://10.23.22.239/index.html
得到下面的結果，很明顯并發被限制住了，超過閾值的都顯示 503：
另外剛才是配置針對單個 IP 的并發限制，還是可以針對域名進行并發限制，配置和客戶端 IP 類似。
- #http{}段配置
- limit_conn_zone $ server_name zone=perserver:10m;
- #server{}段配置
- limit_conn perserver 1;
②ngx_http_limit_req_module
上面我們使用到了 ngx_http_limit_conn_module 模塊，來限制連接數。那么請求數的限制該怎么做呢?
這就需要通過 ngx_http_limit_req_module 模塊來實現，該模塊可以通過定義的鍵值來限制請求處理的頻率。
特別的，可以限制來自單個 IP 地址的請求處理頻率。限制的方法是使用了漏斗算法，每秒固定處理請求數，推遲過多請求。
如果請求的頻率超過了限制域配置的值，請求處理會被延遲或被丟棄，所以所有的請求都是以定義的頻率被處理的。
在 http{} 中配置，#區域名稱為 one，大小為 10m，平均處理的請求頻率不能超過每秒一次。
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
在 server{} 中配置：
- 設置每個IP桶的數量為5
- limit_req zone=one burst=5;
上面設置定義了每個 IP 的請求處理只能限制在每秒 1 個。并且服務端可以為每個 IP 緩存 5 個請求，如果操作了 5 個請求，請求就會被丟棄。
使用 ab 測試模擬客戶端連續訪問 10 次：
ab -n 10 -c 10 http://10.23.22.239/index.html
如下圖，設置了桶的個數為 5 個。一共 10 個請求，第一個請求馬上被處理。第 2-6 個被存放在桶中。
由于桶滿了，沒有設置 nodelay 因此，余下的 4 個請求被丟棄：
