Nginx 限速模塊大揭秘
共 4596字，需瀏覽 10分鐘
·
2024-08-15 10:30
來源：cnblogs.com/xinzhao/p/11465297.html
?? 歡迎加入小哈的星球，你將獲得: 專屬的項(xiàng)目實(shí)戰(zhàn) / 1v1 提問 / Java 學(xué)習(xí)路線 / 學(xué)習(xí)打卡 / 每月贈書 / 社群討論
新項(xiàng)目:《從零手?jǐn)]：仿小紅書（微服務(wù)架構(gòu)）》 正在持續(xù)爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17..., 點(diǎn)擊查看項(xiàng)目介紹； 《從零手?jǐn)]：前后端分離博客項(xiàng)目（全棧開發(fā)）》 2期已完結(jié),演示鏈接：http://116.62.199.48/; 截止目前，累計(jì)輸出 53w+ 字，講解圖 2330+ 張，還在持續(xù)爆肝中.. 后續(xù)還會上新更多項(xiàng)目，目標(biāo)是將 Java 領(lǐng)域典型的項(xiàng)目都整一波，如秒殺系統(tǒng), 在線商城, IM 即時(shí)通訊，Spring Cloud Alibaba 等等，戳我加入學(xué)習(xí)，解鎖全部項(xiàng)目，已有1900+小伙伴加入
-
空桶 -
Burst -
NoDelay
本文以示例的形式，由淺入深講解Nginx限流相關(guān)配置，是對簡略的官方文檔的積極補(bǔ)充。
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限流規(guī)則名稱為ip_limit，允許使用10MB的內(nèi)存空間來記錄ip對應(yīng)的限流狀態(tài)； -
rate=10r/s限流速度為每秒10次請求 -
location /login/對登錄進(jìn)行限流
限流速度為每秒10次請求，如果有10次請求同時(shí)到達(dá)一個(gè)空閑的nginx，他們都能得到執(zhí)行嗎？
漏桶漏出請求是勻速的。10r/s是怎樣勻速的呢？每100ms漏出一個(gè)請求。
在這樣的配置下，桶是空的，所有不能實(shí)時(shí)漏出的請求，都會被拒絕掉。
所以如果10次請求同時(shí)到達(dá)，那么只有一個(gè)請求能夠得到執(zhí)行，其它的，都會被拒絕。
這不太友好，大部分業(yè)務(wù)場景下我們希望這10個(gè)請求都能得到執(zhí)行。
Burst
我們把配置改一下，解決上一節(jié)的問題
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 漏桶的大小設(shè)置為12
邏輯上叫漏桶，實(shí)現(xiàn)起來是FIFO隊(duì)列，把得不到執(zhí)行的請求暫時(shí)緩存起來。
這樣漏出的速度仍然是100ms一個(gè)請求，但并發(fā)而來，暫時(shí)得不到執(zhí)行的請求，可以先緩存起來。只有當(dāng)隊(duì)列滿了的時(shí)候，才會拒絕接受新請求。
這樣漏桶在限流的同時(shí)，也起到了削峰填谷的作用。
在這樣的配置下，如果有10次請求同時(shí)到達(dá)，它們會依次執(zhí)行，每100ms執(zhí)行1個(gè)。
雖然得到執(zhí)行了，但因?yàn)榕抨?duì)執(zhí)行，延遲大大增加，在很多場景下仍然是不能接受的。
NoDelay
繼續(xù)修改配置，解決Delay太久導(dǎo)致延遲增加的問題
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 把開始執(zhí)行請求的時(shí)間提前，以前是delay到從桶里漏出來才執(zhí)行，現(xiàn)在不delay了，只要入桶就開始執(zhí)行
要么立刻執(zhí)行，要么被拒絕，請求不會因?yàn)橄蘖鞫黾友舆t了。
因?yàn)檎埱髲耐袄锫┏鰜磉€是勻速的，桶的空間又是固定的，最終平均下來，還是每秒執(zhí)行了5次請求，限流的目的還是達(dá)到了。
但這樣也有缺點(diǎn)，限流是限了，但是限得不那么勻速。以上面的配置舉例，如果有12個(gè)請求同時(shí)到達(dá)，那么這12個(gè)請求都能夠立刻執(zhí)行，然后后面的請求只能勻速進(jìn)桶，100ms執(zhí)行1個(gè)。如果有一段時(shí)間沒有請求，桶空了，那么又可能出現(xiàn)并發(fā)的12個(gè)請求一起執(zhí)行。
大部分情況下，這種限流不勻速，不算是大問題。不過nginx也提供了一個(gè)參數(shù)才控制并發(fā)執(zhí)行也就是nodelay的請求的數(shù)量。
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 從桶內(nèi)第5個(gè)請求開始delay
這樣通過控制delay參數(shù)的值，可以調(diào)整允許并發(fā)執(zhí)行的請求的數(shù)量，使得請求變的均勻起來，在有些耗資源的服務(wù)上控制這個(gè)數(shù)量，還是有必要的。
?? 歡迎加入小哈的星球，你將獲得: 專屬的項(xiàng)目實(shí)戰(zhàn) / 1v1 提問 / Java 學(xué)習(xí)路線 / 學(xué)習(xí)打卡 / 每月贈書 / 社群討論
新項(xiàng)目:《從零手?jǐn)]：仿小紅書（微服務(wù)架構(gòu)）》 正在持續(xù)爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17..., 點(diǎn)擊查看項(xiàng)目介紹； 《從零手?jǐn)]：前后端分離博客項(xiàng)目（全棧開發(fā)）》 2期已完結(jié),演示鏈接：http://116.62.199.48/; 截止目前，累計(jì)輸出 53w+ 字，講解圖 2330+ 張，還在持續(xù)爆肝中.. 后續(xù)還會上新更多項(xiàng)目，目標(biāo)是將 Java 領(lǐng)域典型的項(xiàng)目都整一波，如秒殺系統(tǒng), 在線商城, IM 即時(shí)通訊，Spring Cloud Alibaba 等等，戳我加入學(xué)習(xí)，解鎖全部項(xiàng)目，已有1900+小伙伴加入
2. 為何 JetBrains 公司做 IDE 就可以養(yǎng)活自己，而國內(nèi)公司卻很難做到？
3. 秒懂雙親委派機(jī)制
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號并回復(fù) Java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
PS：因公眾號平臺更改了推送規(guī)則，如果不想錯(cuò)過內(nèi)容，記得讀完點(diǎn)一下“在看”，加個(gè)“星標(biāo)”，這樣每次新文章推送才會第一時(shí)間出現(xiàn)在你的訂閱列表里。
點(diǎn)“在看”支持小哈呀，謝謝啦