圖解Nginx限流配置

 

做者：程序員趙鑫

本文以示例的形式，由淺入深講解Nginx限流相關配置，是對簡略的官方文檔的積極補充。

Nginx限流使用的是leaky bucket算法，如對算法感興趣，可移步維基百科先行閱讀。不過不了解此算法，不影響閱讀本文。

空桶

咱們從最簡單的限流配置開始：

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

server {
location /login/ {
limit_req zone=ip_limit;
proxy_pass http://login_upstream;
    }
}

• $binary_remote_addr 針對客戶端ip限流；

• zone=ip_limit:10m 限流規則名稱爲ip_limit，容許使用10MB的內存空間來記錄ip對應的限流狀態；

• rate=10r/s 限流速度爲每秒10次請求

• location /login/ 對登陸進行限流

限流速度爲每秒10次請求，若是有10次請求同時到達一個空閒的nginx，他們都能獲得執行嗎？

 

漏桶漏出請求是勻速的。10r/s是怎樣勻速的呢？每100ms漏出一個請求。

在這樣的配置下，桶是空的，全部不能實時漏出的請求，都會被拒絕掉。

因此若是10次請求同時到達，那麼只有一個請求可以獲得執行，其它的，都會被拒絕。

這不太友好，大部分業務場景下咱們但願這10個請求都能獲得執行。

Burst

咱們把配置改一下，解決上一節的問題

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

server {
location /login/ {
limit_req zone=ip_limit burst=12;
proxy_pass http://login_upstream;
    }
}

• burst=12 漏桶的大小設置爲12

邏輯上叫漏桶，實現起來是FIFO隊列，把得不到執行的請求暫時緩存起來。

這樣漏出的速度仍然是100ms一個請求，但併發而來，暫時得不到執行的請求，能夠先緩存起來。只有當隊列滿了的時候，纔會拒絕接受新請求。

這樣漏桶在限流的同時，也起到了削峯填谷的做用。

在這樣的配置下，若是有10次請求同時到達，它們會依次執行，每100ms執行1個。

雖然獲得執行了，但由於排隊執行，延遲大大增長，在不少場景下仍然是不能接受的。

NoDelay

繼續修改配置，解決Delay過久致使延遲增長的問題

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

server {
location /login/ {
limit_req zone=ip_limit burst=12 nodelay;
proxy_pass http://login_upstream;
    }
}

• nodelay 把開始執行請求的時間提早，之前是delay到從桶裏漏出來才執行，如今不delay了，只要入桶就開始執行

   

要麼馬上執行，要麼被拒絕，請求不會由於限流而增長延遲了。

由於請求從桶裏漏出來仍是勻速的，桶的空間又是固定的，最終平均下來，仍是每秒執行了5次請求，限流的目的仍是達到了。

但這樣也有缺點，限流是限了，可是限得不那麼勻速。以上面的配置舉例，若是有12個請求同時到達，那麼這12個請求都可以馬上執行，而後後面的請求只能勻速進桶，100ms執行1個。若是有一段時間沒有請求，桶空了，那麼又可能出現併發的12個請求一塊兒執行。

大部分狀況下，這種限流不勻速，不算是大問題。不過nginx也提供了一個參數才控制併發執行也就是nodelay的請求的數量。

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

server {
location /login/ {
limit_req zone=ip_limit burst=12 delay=4;
proxy_pass http://login_upstream;
    }
}

• delay=4 從桶內第5個請求開始delay

這樣經過控制delay參數的值，能夠調整容許併發執行的請求的數量，使得請求變的均勻起來，在有些耗資源的服務上控制這個數量，仍是有必要的。