图解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参数的值，能够调整容许并发执行的请求的数量，使得请求变的均匀起来，在有些耗资源的服务上控制这个数量，仍是有必要的。