聊聊高并發系統之限流特技-2

作者：張開濤 2016-11-28 08:58:43

上一篇《聊聊高并發系統限流特技-1》講了限流算法、應用級限流、分布式限流;本篇將介紹接入層限流實現。

接入層限流

接入層通常指請求流量的入口，該層的主要目的有：負載均衡、非法請求過濾、請求聚合、緩存、降級、限流、A/B測試、服務質量監控等等，可以參考筆者寫的《使用Nginx+Lua(OpenResty)開發高性能Web應用》。

對于Nginx接入層限流可以使用Nginx自帶了兩個模塊：連接數限流模塊ngx_http_limit_conn_module和漏桶算法實現的請求限流模塊ngx_http_limit_req_module。還可以使用OpenResty提供的Lua限流模塊lua-resty-limit-traffic進行更復雜的限流場景。

limit_conn用來對某個KEY對應的總的網絡連接數進行限流，可以按照如IP、域名維度進行限流。limit_req用來對某個KEY對應的請求的平均速率進行限流，并有兩種用法：平滑模式(delay)和允許突發模式(nodelay)。

ngx_http_limit_conn_module

limit_conn是對某個KEY對應的總的網絡連接數進行限流。可以按照IP來限制IP維度的總連接數，或者按照服務域名來限制某個域名的總連接數。但是記住不是每一個請求連接都會被計數器統計，只有那些被Nginx處理的且已經讀取了整個請求頭的請求連接才會被計數器統計。

配置示例：

http { 
    limit_conn_zone$binary_remote_addr zone=addr:10m;  
    limit_conn_log_level error; 
    limit_conn_status 503; 
   ... 
   server { 
       ... 
       location /limit { 
           limit_conn addr 1; 
       }

limit_conn：要配置存放KEY和計數器的共享內存區域和指定KEY的最大連接數;此處指定的最大連接數是1，表示Nginx最多同時并發處理1個連接;

limit_conn_zone：用來配置限流KEY、及存放KEY對應信息的共享內存區域大小;此處的KEY是“$binary_remote_addr”其表示IP地址，也可以使用如$server_name作為KEY來限制域名級別的最大連接數;

limit_conn_status：配置被限流后返回的狀態碼，默認返回503;

limit_conn_log_level：配置記錄被限流后的日志級別，默認error級別。

limit_conn的主要執行過程如下所示：

1、請求進入后首先判斷當前limit_conn_zone中相應KEY的連接數是否超出了配置的最大連接數;

2.1、如果超過了配置的最大大小，則被限流，返回limit_conn_status定義的錯誤狀態碼;

2.2、否則相應KEY的連接數加1，并注冊請求處理完成的回調函數;

3、進行請求處理;

4、在結束請求階段會調用注冊的回調函數對相應KEY的連接數減1。

limt_conn可以限流某個KEY的總并發/請求數，KEY可以根據需要變化。

按照IP限制并發連接數配置示例：

首先定義IP維度的限流區域：

limit_conn_zone $binary_remote_addrzone=perip:10m;

接著在要限流的location中添加限流邏輯：

location /limit { 
    limit_conn perip 2; 
    echo "123"; 
}

即允許每個IP最大并發連接數為2。

使用AB測試工具進行測試，并發數為5個，總的請求數為5個：

ab -n 5 -c 5 http://localhost/limit

將得到如下access.log輸出：

[08/Jun/2016:20:10:51+0800] [1465373451.802] 200

[08/Jun/2016:20:10:51+0800] [1465373451.803] 200

[08/Jun/2016:20:10:51 +0800][1465373451.803] 503

此處我們把access log格式設置為log_format main '[$time_local] [$msec] $status';分別是“日期日期秒/毫秒值響應狀態碼”。

如果被限流了，則在error.log中會看到類似如下的內容：

2016/06/08 20:10:51 [error] 5662#0: *5limiting connections by zone "perip", client: 127.0.0.1, server: _,request: "GET /limit HTTP/1.0", host: "localhost"

按照域名限制并發連接數配置示例：

首先定義域名維度的限流區域：

limit_conn_zone $ server_name zone=perserver:10m;

接著在要限流的location中添加限流邏輯：

location /limit { 
    limit_conn perserver 2; 
    echo "123"; 
}

即允許每個域名最大并發請求連接數為2;這樣配置可以實現服務器最大連接數限制。

ngx_http_limit_req_module

limit_req是令牌桶算法實現，用于對指定KEY對應的請求進行限流，比如按照IP維度限制請求速率。

配置示例：

http { 
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; 
    limit_conn_log_level error; 
    limit_conn_status 503; 
    ... 
    server { 
       ... 
       location /limit { 
            limit_req zone=one burst=5 nodelay; 
    }

limit_req：配置限流區域、桶容量(突發容量，默認0)、是否延遲模式(默認延遲);

limit_req_zone：配置限流KEY、及存放KEY對應信息的共享內存區域大小、固定請求速率;此處指定的KEY是“$binary_remote_addr”表示IP地址;固定請求速率使用rate參數配置，支持10r/s和60r/m，即每秒10個請求和每分鐘60個請求，不過最終都會轉換為每秒的固定請求速率(10r/s為每100毫秒處理一個請求;60r/m，即每1000毫秒處理一個請求)。

limit_conn_status：配置被限流后返回的狀態碼，默認返回503;

limit_conn_log_level：配置記錄被限流后的日志級別，默認error級別。

limit_req的主要執行過程如下所示：

1、請求進入后首先判斷最后一次請求時間相對于當前時間(第一次是0)是否需要限流，如果需要限流則執行步驟2，否則執行步驟3;

2.1、如果沒有配置桶容量(burst)，則桶容量為0;按照固定速率處理請求;如果請求被限流，則直接返回相應的錯誤碼(默認503);

2.2、如果配置了桶容量(burst>0)且延遲模式(沒有配置nodelay);如果桶滿了，則新進入的請求被限流;如果沒有滿則請求會以固定平均速率被處理(按照固定速率并根據需要延遲處理請求，延遲使用休眠實現);

2.3、如果配置了桶容量(burst>0)且非延遲模式(配置了nodelay);不會按照固定速率處理請求，而是允許突發處理請求;如果桶滿了，則請求被限流，直接返回相應的錯誤碼;

3、如果沒有被限流，則正常處理請求;

4、Nginx會在相應時機進行選擇一些(3個節點)限流KEY進行過期處理，進行內存回收。

場景2.1測試

首先定義IP維度的限流區域：

limit_req_zone $binary_remote_addrzone=test:10m rate=500r/s;

限制為每秒500個請求，固定平均速率為2毫秒一個請求。

接著在要限流的location中添加限流邏輯：

location /limit { 
    limit_req zone=test; 
    echo "123"; 
}

即桶容量為0(burst默認為0)，且延遲模式。

使用AB測試工具進行測試，并發數為2個，總的請求數為10個：

ab -n 10 -c 2 http://localhost/limit

將得到如下access.log輸出：

[08/Jun/2016:20:25:56+0800] [1465381556.410] 200

[08/Jun/2016:20:25:56 +0800][1465381556.410] 503

[08/Jun/2016:20:25:56 +0800][1465381556.411] 503

[08/Jun/2016:20:25:56+0800] [1465381556.411] 200

[08/Jun/2016:20:25:56 +0800][1465381556.412] 503

雖然每秒允許500個請求，但是因為桶容量為0，所以流入的請求要么被處理要么被限流，無法延遲處理;另外平均速率在2毫秒左右，比如1465381556.410和1465381556.411被處理了;有朋友會說這固定平均速率不是1毫秒嘛，其實這是因為實現算法沒那么精準造成的。

如果被限流在error.log中會看到如下內容：

2016/06/08 20:25:56 [error] 6130#0: *1962limiting requests, excess: 1.000 by zone "test", client: 127.0.0.1,server: _, request: "GET /limit HTTP/1.0", host:"localhost"

如果被延遲了在error.log(日志級別要INFO級別)中會看到如下內容：

2016/06/10 09:05:23 [warn] 9766#0: *97021delaying request, excess: 0.368, by zone "test", client: 127.0.0.1,server: _, request: "GET /limit HTTP/1.0", host:"localhost"

場景2.2測試

首先定義IP維度的限流區域：

limit_req_zone $binary_remote_addr    zone=test:10m rate=2r/s;

為了方便測試設置速率為每秒2個請求，即固定平均速率是500毫秒一個請求。

接著在要限流的location中添加限流邏輯：

location /limit { 
    limit_req zone=test burst=3; 
    echo "123"; 
}

固定平均速率為500毫秒一個請求，通容量為3，如果桶滿了新的請求被限流，否則可以進入桶中排隊并等待(實現延遲模式)。

為了看出限流效果我們寫了一個req.sh腳本：

ab -c 6 -n 6 http://localhost/limit 
sleep 0.3 
ab -c 6 -n 6 http://localhost/limit

首先進行6個并發請求6次URL，然后休眠300毫秒，然后再進行6個并發請求6次URL;中間休眠目的是為了能跨越2秒看到效果，如果看不到如下的效果可以調節休眠時間。

將得到如下access.log輸出：

[09/Jun/2016:08:46:43+0800] [1465433203.959] 200

[09/Jun/2016:08:46:43 +0800][1465433203.959] 503

[09/Jun/2016:08:46:43 +0800][1465433203.960] 503

[09/Jun/2016:08:46:44+0800] [1465433204.450] 200

[09/Jun/2016:08:46:44+0800] [1465433204.950] 200

[09/Jun/2016:08:46:45 +0800][1465433205.453] 200

[09/Jun/2016:08:46:45 +0800][1465433205.766] 503

[09/Jun/2016:08:46:45 +0800][1465433205.767] 503

[09/Jun/2016:08:46:45+0800] [1465433205.950] 200

[09/Jun/2016:08:46:46+0800] [1465433206.451] 200

[09/Jun/2016:08:46:46+0800] [1465433206.952] 200

桶容量為3，即桶中在時間窗口內最多流入3個請求，且按照2r/s的固定速率處理請求(即每隔500毫秒處理一個請求);桶計算時間窗口(1.5秒)=速率(2r/s)/桶容量(3)，也就是說在這個時間窗口內桶最多暫存3個請求。因此我們要以當前時間往前推1.5秒和1秒來計算時間窗口內的總請求數;另外因為默認是延遲模式，所以時間窗內的請求要被暫存到桶中，并以固定平均速率處理請求：

第一輪：有4個請求處理成功了，按照漏桶桶容量應該最多3個才對;這是因為計算算法的問題，第一次計算因沒有參考值，所以第一次計算后，后續的計算才能有參考值，因此第一次成功可以忽略;這個問題影響很小可以忽略;而且按照固定500毫秒的速率處理請求。

第二輪：因為第一輪請求是突發來的，差不多都在1465433203.959時間點，只是因為漏桶將速率進行了平滑變成了固定平均速率(每500毫秒一個請求);而第二輪計算時間應基于1465433203.959;而第二輪突發請求差不多都在1465433205.766時間點，因此計算桶容量的時間窗口應基于1465433203.959和1465433205.766來計算，計算結果為1465433205.766這個時間點漏桶為空了，可以流入桶中3個請求，其他請求被拒絕;又因為第一輪最后一次處理時間是1465433205.453，所以第二輪第一個請求被延遲到了1465433205.950。這里也要注意固定平均速率只是在配置的速率左右，存在計算精度問題，會有一些偏差。

如果桶容量改為1(burst=1)，執行req.sh腳本可以看到如下輸出：

[09/Jun/2016:09:04:30+0800] [1465434270.362] 200

[09/Jun/2016:09:04:30 +0800][1465434270.371] 503

[09/Jun/2016:09:04:30 +0800] [1465434270.372]503

[09/Jun/2016:09:04:30 +0800][1465434270.372] 503

[09/Jun/2016:09:04:30+0800] [1465434270.864] 200

[09/Jun/2016:09:04:31 +0800][1465434271.178] 503

[09/Jun/2016:09:04:31 +0800][1465434271.179] 503

[09/Jun/2016:09:04:31+0800] [1465434271.366] 200

桶容量為1，按照每1000毫秒一個請求的固定平均速率處理請求。

場景2.3測試

首先定義IP維度的限流區域：

limit_req_zone $binary_remote_addrzone=test:10m rate=2r/s;

為了方便測試配置為每秒2個請求，固定平均速率是500毫秒一個請求。

接著在要限流的location中添加限流邏輯：

location /limit { 
         limit_req zone=test burst=3 nodelay; 
         echo "123"; 
     }

桶容量為3，如果桶滿了直接拒絕新請求，且每秒2最多兩個請求，桶按照固定500毫秒的速率以nodelay模式處理請求。

為了看到限流效果我們寫了一個req.sh腳本：

ab -c 6 -n 6 http://localhost/limit 
sleep 1 
ab -c 6 -n 6 http://localhost/limit 
sleep 0.3 
ab -c 6 -n 6 http://localhost/limit 
sleep 0.3 
ab -c 6 -n 6 http://localhost/limit 
sleep 0.3 
ab -c 6 -n 6 http://localhost/limit 
sleep 2 
ab -c 6 -n 6 http://localhost/limit

將得到類似如下access.log輸出：

================================

[09/Jun/2016:14:30:11+0800] [1465453811.754] 200

[09/Jun/2016:14:30:11+0800] [1465453811.755] 200

[09/Jun/2016:14:30:11+0800] [1465453811.759] 200

[09/Jun/2016:14:30:11 +0800][1465453811.759] 503

[09/Jun/2016:14:30:12+0800] [1465453812.776] 200

[09/Jun/2016:14:30:12 +0800][1465453812.776] 503

[09/Jun/2016:14:30:12 +0800][1465453812.777] 503

[09/Jun/2016:14:30:13 +0800] [1465453813.095]503

[09/Jun/2016:14:30:13 +0800][1465453813.097] 503

[09/Jun/2016:14:30:13 +0800][1465453813.098] 503

[09/Jun/2016:14:30:13+0800] [1465453813.425] 200

[09/Jun/2016:14:30:13 +0800][1465453813.425] 503

[09/Jun/2016:14:30:13 +0800][1465453813.426] 503

[09/Jun/2016:14:30:13+0800] [1465453813.754] 200

[09/Jun/2016:14:30:13 +0800][1465453813.755] 503

[09/Jun/2016:14:30:13 +0800][1465453813.756] 503

[09/Jun/2016:14:30:15+0800] [1465453815.278] 200

[09/Jun/2016:14:30:15 +0800][1465453815.278] 503

[09/Jun/2016:14:30:15 +0800][1465453815.279] 503

[09/Jun/2016:14:30:17+0800] [1465453817.300] 200

[09/Jun/2016:14:30:17+0800] [1465453817.301] 200

[09/Jun/2016:14:30:17 +0800][1465453817.301] 503

桶容量為3(，即桶中在時間窗口內最多流入3個請求，且按照2r/s的固定速率處理請求(即每隔500毫秒處理一個請求);桶計算時間窗口(1.5秒)=速率(2r/s)/桶容量(3)，也就是說在這個時間窗口內桶最多暫存3個請求。因此我們要以當前時間往前推1.5秒和1秒來計算時間窗口內的總請求數;另外因為配置了nodelay，是非延遲模式，所以允許時間窗內突發請求的;另外從本示例會看出兩個問題：

第一輪和第七輪：有4個請求處理成功了;這是因為計算算法的問題，本示例是如果2秒內沒有請求，然后接著突然來了很多請求，第一次計算的結果將是不正確的;這個問題影響很小可以忽略;

第五輪：1.0秒計算出來是3個請求;此處也是因計算精度的問題，也就是說limit_req實現的算法不是非常精準的，假設此處看成相對于2.75的話，1.0秒內只有1次請求，所以還是允許1次請求的。

如果限流出錯了，可以配置錯誤頁面：

proxy_intercept_errors on; 
recursive_error_pages on; 
error_page 503 //www.jd.com/error.aspx;

limit_conn_zone/limit_req_zone定義的內存不足，則后續的請求將一直被限流，所以需要根據需求設置好相應的內存大小。

此處的限流都是單Nginx的，假設我們接入層有多個nginx，此處就存在和應用級限流相同的問題;那如何處理呢?一種解決辦法：建立一個負載均衡層將按照限流KEY進行一致性哈希算法將請求哈希到接入層Nginx上，從而相同KEY的將打到同一臺接入層Nginx上;另一種解決方案就是使用Nginx+Lua(OpenResty)調用分布式限流邏輯實現。

lua-resty-limit-traffic

之前介紹的兩個模塊使用上比較簡單，指定KEY、指定限流速率等就可以了，如果我們想根據實際情況變化KEY、變化速率、變化桶大小等這種動態特性，使用標準模塊就很難去實現了，因此我們需要一種可編程來解決我們問題;而OpenResty提供了lua限流模塊lua-resty-limit-traffic，通過它可以按照更復雜的業務邏輯進行動態限流處理了。其提供了limit.conn和limit.req實現，算法與nginx limit_conn和limit_req是一樣的。

此處我們來實現ngx_http_limit_req_module中的【場景2.2測試】，不要忘記下載lua-resty-limit-traffic模塊并添加到OpenResty的lualib中。

配置用來存放限流用的共享字典：

lua_shared_dict limit_req_store 100m;

以下是實現【場景2.2測試】的限流代碼limit_req.lua：

local limit_req = require "resty.limit.req" 
local rate = 2 --固定平均速率 2r/s 
local burst = 3  --桶容量 
local error_status = 503 
local nodelay = false --是否需要不延遲處理 
local lim, err = limit_req.new("limit_req_store", rate, burst) 
if not lim then --沒定義共享字典 
    ngx.exit(error_status) 
end 
local key = ngx.var.binary_remote_addr --IP維度的限流 
--流入請求，如果請求需要被延遲則delay > 0 
local delay, err = lim:incoming(key, true) 
if not delay and err == "rejected" then --超出桶大小了 
    ngx.exit(error_status) 
end 
if delay > 0 then  --根據需要決定是延遲或者不延遲處理 
    if nodelay then 
        --直接突發處理了 
    else 
        ngx.sleep(delay) --延遲處理 
    end 
end

即限流邏輯再nginx access階段被訪問，如果不被限流繼續后續流程;如果需要被限流要么sleep一段時間繼續后續流程，要么返回相應的狀態碼拒絕請求。

在分布式限流中我們使用了簡單的Nginx+Lua進行分布式限流，有了這個模塊也可以使用這個模塊來實現分布式限流。

另外在使用Nginx+Lua時也可以獲取ngx.var.connections_active進行過載保護，即如果當前活躍連接數超過閾值進行限流保護。

if tonumber(ngx.var.connections_active) >= tonumber(limit) then 
    //限流 
end

nginx也提供了limit_rate用來對流量限速，如limit_rate 50k，表示限制下載速度為50k。

到此筆者在工作中涉及的限流用法就介紹完，這些算法中有些允許突發，有些會整形為平滑，有些計算算法簡單粗暴;其中令牌桶算法和漏桶算法實現上是類似的，只是表述的方向不太一樣，對于業務來說不必刻意去區分它們;因此需要根據實際場景來決定如何限流，最好的算法不一定是最適用的。

參考資料

https://en.wikipedia.org/wiki/Token_bucket

https://en.wikipedia.org/wiki/Leaky_bucket

http://redis.io/commands/incr

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

https://github.com/openresty/lua-resty-limit-traffic

http://nginx.org/en/docs/http/ngx_http_core_module.html#limit_rate

【本文是51CTO專欄作者張開濤的原創文章，作者微信公眾號：開濤的博客( kaitao-1234567)】

責任編輯：趙寧寧來源：開濤的博客

系統限流