您好,登錄后才能下訂單哦!
歡迎掃碼加入Java高知×××流
漏桶原理是什么呢?我們可以從字面上簡單的理解,就是有一個桶,它的體積是固定的,桶底下有一個小洞會不停的漏水出去,而桶的上方有個水龍頭,也不停的往桶里灌水。
假設(shè)我們這個桶的體積是1L,小洞的口能漏水的最大速率為100ml/s,對以下情況進(jìn)行實驗:
(1)進(jìn)水的速率是50ml/s,這時候?qū)τ谛《磥碚f完全無壓力,那么這個桶里的水就不會溢出,所有的水都會從小洞里漏出來。
(2)接著我們把水龍頭出水的速率調(diào)大到100ml/s,這個時候,和小洞漏水的速率一樣,這個時候桶里的水也不會溢出,桶中的水不會有變化,所有的水都會從小洞里漏出來。
(3)我們再把水龍頭調(diào)大,調(diào)到150m/m,這個時候,進(jìn)水的速率比出水的速率每秒大50ml,經(jīng)過20秒后,桶里的水滿了,會溢出來,之后每秒都會有50ml的水會溢出。
以上的不管哪種情況,相同的一點是,漏水的最大速率是一樣的。當(dāng)進(jìn)水的速率大于漏水的速率,桶滿水之后,將有一部分水會被溢出。
換成我們訪問一臺服務(wù)器也一樣,限制其流量的存儲量和速率,當(dāng)處理不過來的時候會直接廢棄掉一些請求,確保服務(wù)器的正常流量處理。
這就是漏桶原理。
Nginx采用漏桶原理(leaky bucket),對請求的ip進(jìn)行過于頻繁的限制,參考文檔鏈接:https://en.wikipedia.org/wiki/Leaky_bucket
具體的配置如下:
#以用戶二進(jìn)制IP地址,定義三個漏桶,滴落速率1-3req/sec,桶空間1m,1M能保持大約16000個(IP)狀態(tài) limit_req_zone $binary_remote_addr zone=qps1:1m rate=1r/s; limit_req_zone $binary_remote_addr zone=qps2:1m rate=2r/s; limit_req_zone $binary_remote_addr zone=qps3:1m rate=3r/s; server { #速率qps=1,峰值burst=5,延遲請求 #嚴(yán)格按照漏桶速率qps=1處理每秒請求 #在峰值burst=5以內(nèi)的并發(fā)請求,會被掛起,延遲處理 #超出請求數(shù)限制則直接返回503 #客戶端只要控制并發(fā)在峰值[burst]內(nèi),就不會觸發(fā)limit_req_error_log # 例1:發(fā)起一個并發(fā)請求=6,拒絕1個,處理1個,進(jìn)入延遲隊列4個: #time request refuse sucess delay #00:01 6 1 1 4 #00:02 0 0 1 3 #00:03 0 0 1 2 #00:04 0 0 1 1 #00:05 0 0 1 0 location /delay { limit_req zone=qps1 burst=5; } #速率qps=1,峰值burst=5,不延遲請求 #加了nodelay之后,漏桶控制一段時長內(nèi)的平均qps = 漏桶速率,允許瞬時的峰值qps > 漏桶qps #所以峰值時的最高qps=(brust+qps-1)=5 #請求不會被delay,要么處理,要么直接返回503 #客戶端需要控制qps每秒請求數(shù),才不會觸發(fā)limit_req_error_log # 例2:每隔5秒發(fā)起一次達(dá)到峰值的并發(fā)請求,由于時間段內(nèi)平均qps=1 所以仍然符合漏桶速率: #time request refuse sucess #00:01 5 0 5 #00:05 5 0 5 #00:10 5 0 5 # 例3:連續(xù)每秒發(fā)起并發(fā)請求=5,由于時間段內(nèi)平均qps>>1,超出的請求被拒絕: #time request refuse sucess #00:01 5 0 5 #00:02 5 4 1 #00:03 5 4 1 location /nodelay { limit_req zone=qps1 burst=5 nodelay; } }
歡迎掃碼加入Java高知×××流
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。