<ul id="qxxfc"><fieldset id="qxxfc"><tr id="qxxfc"></tr></fieldset></ul>


      本文以示例的形式,由淺入深講解Nginx限流相關(guān)配置,是對(duì)簡(jiǎn)略的官方文檔
      <http://nginx.org/en/docs/http/ngx_http_limit_req_module.html>的積極補(bǔ)充。

      Nginx限流使用的是leaky bucket算法,如對(duì)算法感興趣,可移步維基百科
      <https://en.wikipedia.org/wiki/Leaky_bucket>先行閱讀。不過(guò)不了解此算法,不影響閱讀本文。

      空桶

      我們從最簡(jiǎn)單的限流配置開(kāi)始:
      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 針對(duì)客戶端ip限流;
      * zone=ip_limit:10m 限流規(guī)則名稱(chēng)為ip_limit,允許使用10MB的內(nèi)存空間來(lái)記錄ip對(duì)應(yīng)的限流狀態(tài);
      * rate=10r/s 限流速度為每秒10次請(qǐng)求
      * location /login/ 對(duì)登錄進(jìn)行限流
      限流速度為每秒10次請(qǐng)求,如果有10次請(qǐng)求同時(shí)到達(dá)一個(gè)空閑的nginx,他們都能得到執(zhí)行嗎?



      漏桶漏出請(qǐng)求是勻速的。10r/s是怎樣勻速的呢?每100ms漏出一個(gè)請(qǐng)求。

      在這樣的配置下,桶是空的,所有不能實(shí)時(shí)漏出的請(qǐng)求,都會(huì)被拒絕掉。

      所以如果10次請(qǐng)求同時(shí)到達(dá),那么只有一個(gè)請(qǐng)求能夠得到執(zhí)行,其它的,都會(huì)被拒絕。

      這不太友好,大部分業(yè)務(wù)場(chǎng)景下我們希望這10個(gè)請(qǐng)求都能得到執(zhí)行。

      Burst

      我們把配置改一下,解決上一節(jié)的問(wèn)題
      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)起來(lái)是FIFO隊(duì)列,把得不到執(zhí)行的請(qǐng)求暫時(shí)緩存起來(lái)。

      這樣漏出的速度仍然是100ms一個(gè)請(qǐng)求,但并發(fā)而來(lái),暫時(shí)得不到執(zhí)行的請(qǐng)求,可以先緩存起來(lái)。只有當(dāng)隊(duì)列滿了的時(shí)候,才會(huì)拒絕接受新請(qǐng)求。

      這樣漏桶在限流的同時(shí),也起到了削峰填谷的作用。

      在這樣的配置下,如果有10次請(qǐng)求同時(shí)到達(dá),它們會(huì)依次執(zhí)行,每100ms執(zhí)行1個(gè)。

      雖然得到執(zhí)行了,但因?yàn)榕抨?duì)執(zhí)行,延遲大大增加,在很多場(chǎng)景下仍然是不能接受的。

      NoDelay

      繼續(xù)修改配置,解決Delay太久導(dǎo)致延遲增加的問(wèn)題
      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 把開(kāi)始執(zhí)行請(qǐng)求的時(shí)間提前,以前是delay到從桶里漏出來(lái)才執(zhí)行,現(xiàn)在不delay了,只要入桶就開(kāi)始執(zhí)行


      要么立刻執(zhí)行,要么被拒絕,請(qǐng)求不會(huì)因?yàn)橄蘖鞫黾友舆t了。

      因?yàn)檎?qǐng)求從桶里漏出來(lái)還是勻速的,桶的空間又是固定的,最終平均下來(lái),還是每秒執(zhí)行了5次請(qǐng)求,限流的目的還是達(dá)到了。


      但這樣也有缺點(diǎn),限流是限了,但是限得不那么勻速。以上面的配置舉例,如果有12個(gè)請(qǐng)求同時(shí)到達(dá),那么這12個(gè)請(qǐng)求都能夠立刻執(zhí)行,然后后面的請(qǐng)求只能勻速進(jìn)桶,100ms執(zhí)行1個(gè)。如果有一段時(shí)間沒(méi)有請(qǐng)求,桶空了,那么又可能出現(xiàn)并發(fā)的12個(gè)請(qǐng)求一起執(zhí)行。

      大部分情況下,這種限流不勻速,不算是大問(wèn)題。不過(guò)nginx也提供了一個(gè)參數(shù)才控制并發(fā)執(zhí)行也就是nodelay的請(qǐng)求的數(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è)請(qǐng)求開(kāi)始delay


      這樣通過(guò)控制delay參數(shù)的值,可以調(diào)整允許并發(fā)執(zhí)行的請(qǐng)求的數(shù)量,使得請(qǐng)求變的均勻起來(lái),在有些耗資源的服務(wù)上控制這個(gè)數(shù)量,還是有必要的。

      Reference

      http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
      <http://nginx.org/en/docs/http/ngx_http_limit_req_module.html>
      https://www.nginx.com/blog/rate-limiting-nginx/
      <https://www.nginx.com/blog/rate-limiting-nginx/>

      友情鏈接
      ioDraw流程圖
      API參考文檔
      OK工具箱
      云服務(wù)器優(yōu)惠
      阿里云優(yōu)惠券
      騰訊云優(yōu)惠券
      京東云優(yōu)惠券
      站點(diǎn)信息
      問(wèn)題反饋
      郵箱:[email protected]
      QQ群:637538335
      關(guān)注微信

        <ul id="qxxfc"><fieldset id="qxxfc"><tr id="qxxfc"></tr></fieldset></ul>
          羞羞色视频 | 操处女视频 | 操逼五月天 | 美女被异性狂揉下部羞羞视频 | 西装男正装泄欲h文gay | 久操性爱在线视频 | 一级特黄AAAAAA级大仟 | 国产一区二区在线免费观看 | bl高h车文双龙触手play | 加勒比HEZYO黑人专区 |