Nginx限流配置記錄

2021-10-25 18:58:32 字數 1794 閱讀 2923

nginx限流配置

nginx限流演算法

令牌桶演算法

令牌以固定速率產生,並快取到令牌桶中;

令牌桶放滿時,多餘的令牌被丟棄;

請求要消耗等比例的令牌才能被處理;

令牌不夠時,請求被快取

漏桶演算法

水(請求)從上方倒入水桶,從水桶下方流出(被處理);

來不及流出的水存在水桶中(緩衝),以固定速率流出;

水桶滿後水溢位(丟棄)。

這個演算法的核心是:快取請求、勻速處理、多餘的請求直接丟棄。

相比漏桶演算法,令牌桶演算法不同之處在於它不但有乙隻「桶」,還有個佇列,這個桶是用來存放令牌的,佇列才是用來存放請求的。

兩者區別:

從作用上來說,漏桶和令牌桶演算法最明顯的區別就是是否允許突發流量(burst)的處理,漏桶演算法能夠強行限制資料的實時傳輸(處理)速率,對突發流量不做額外處理;而令牌桶演算法能夠在限制資料的平均傳輸速率的同時允許某種程度的突發傳輸。

拿進火車站的示例來講:

令牌桶演算法是出火車票的速度是固定的,所有人只有拿到票後才可以進行候車大廳。候車大廳人滿了,直接拒絕。(出票速度是一定的,如1分鐘出10張票。旅客上車的速度不進行限制)

漏桶演算法是進行候車大廳不需要票,旅客上車的速度是一定。候車大廳人滿了,直接拒絕。

實戰配置

限制訪問速率

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

server

}

我們使用單個ip在10ms內發並傳送了6個請求,只有1個成功,剩下的5個都被拒絕。我們設定的速度是2r/s,為什麼只有1個成功呢,是不是nginx限制錯了?當然不是,是因為nginx的限流統計是基於毫秒的,我們設定的速度是2r/s,轉換一下就是500ms內單個ip只允許通過1個請求,從501ms開始才允許通過第二個請求。

2. burst快取處理

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

server

}

nginx按照毫秒級精度統計,超出限制的請求直接拒絕。這在實際場景中未免過於苛刻,真實網路環境中請求到來不是勻速的,很可能有請求「突發」的情況,也就是「一股子一股子」的。nginx考慮到了這種情況,可以通過burst關鍵字開啟對突發請求的快取處理,而不是直接拒絕。

但是請注意:burst的作用是讓多餘的請求可以先放到佇列裡,慢慢處理。如果不加nodelay引數,佇列裡的請求不會立即處理,而是按照rate設定的速度,以毫秒級精確的速度慢慢處理。

3. nodelay降低排隊時間

例項二中我們看到,通過設定burst引數,我們可以允許nginx快取處理一定程度的突發,多餘的請求可以先放到佇列裡,慢慢處理,這起到了平滑流量的作用。但是如果佇列設定的比較大,請求排隊的時間就會比較長,使用者角度看來就是rt變長了,這對使用者很不友好。有什麼解決辦法呢?nodelay引數允許請求在排隊的時候就立即被處理,也就是說只要請求能夠進入burst佇列,就會立即被後台worker處理,請注意,這意味著burst設定了nodelay時,系統瞬間的qps可能會超過rate設定的閾值。nodelay引數要跟burst一起使用才有作用。

延續例項二的配置,我們加入nodelay選項:

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

server

}

Nginx限流配置

nginx限流配置 編輯 1 限制域宣告 以下配置建議統一在http域中進行配置 定義乙個名為perip req的limit req zone用來儲存session,大小是10m記憶體,以 binary remote addr 為key,限制平均每分鐘的請求為30個,1m能儲存16000個狀態 以下...

nginx限流配置

表示處理請求的平均速度 每個請求之間至少要間隔 1000 60 16.7ms 超出的請求將會進入令牌桶中,例如在10ms內發出5個請求則只有乙個能得到處理,其餘4個會進入令牌桶 令牌桶內的令牌可以滿足這4個額外請求的時候,如果不滿足將會返回503或者自定義的status server locatio...

Nginx搶購限流配置

因業務需求經常會有搶購業務,因此需要在負載均衡前端進行限流錯誤。本文同樣也適用於防止cc.limit req zone server name zone sname 10m rate 1r s 限 務器每秒只能有一次訪問成功 limit req zone binary remote addr zon...