1. 摘要

本文介绍Nginx限流算法及限流配置实践及测试验证。

2. 限流算法

高并发系统有三把利器：缓存、降级和限流；

限流的目的是通过对并发访问/请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页）、排队等待（秒杀）、降级（返回兜底数据或默认数据）。
高并发系统常见的限流有：限制总并发数（数据库连接池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（nginx的limit_req模块，用来限制每秒的平均速率）。
另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。

最简单粗暴的限流算法就是计数器法了，而比较常用的有漏桶算法和令牌桶算法。

2.1计数器

计数器法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。

那么我们我们可以设置一个计数器counter，其有效时间为1分钟（即每分钟计数器会被重置为0），每当一个请求过来的时候，counter就加1，如果counter的值大于100，就说明请求数过多；

这个算法虽然简单，但是有一个十分致命的问题，那就是临界问题。

如下图所示，在1:00前一刻到达100个请求，1:00计数器被重置，1:00后一刻又到达100个请求，显然计数器不会超过100，所有请求都不会被拦截；

然而这一时间段内请求数已经达到200，远超100。

image.png

2.2 漏桶算法

如下图所示，有一个固定容量的漏桶，按照常量固定速率流出水滴；如果桶是空的，则不会流出水滴；流入到漏桶的水流速度是随意的；如果流入的水超出了桶的容量，则流入的水会溢出（被丢弃）；

可以看到漏桶算法天生就限制了请求的速度，可以用于流量整形和限流控制；

image.png

2.3 令牌桶算法

令牌桶是一个存放固定容量令牌的桶，按照固定速率r往桶里添加令牌；桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃；

当一个请求达到时，会尝试从桶中获取令牌；如果有，则继续处理请求；如果没有则排队等待或者直接丢弃；

可以发现，漏桶算法的流出速率恒定或者为0，而令牌桶算法的流出速率却有可能大于r；

image.png

从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理，漏桶算法能够强行限制数据的实时传输（处理）速率，对突发流量不做额外处理；而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程度的突发传输。

Nginx按请求速率限速模块使用的是漏桶算法，即能够强行保证请求的实时处理速度不会超过设置的阈值。

Nginx官方版本限制IP的连接和并发分别有两个模块：

limit_req_zone 用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"。
limit_req_conn 用来限制同一时间连接数，即并发限制。

2.4 nginx基础知识

Nginx主要有两种限流方式：按连接数限流(ngx_http_limit_conn_module)、按请求速率限流(ngx_http_limit_req_module)。

ngx_http_limit_req_module模块是对请求进行限流，即限制某一时间段内用户的请求速率，且使用的是令牌桶算法；

3. 限流配置实践

3.1 请求限制

请求限制的功能来自于 ngx_http_limit_req_module 模块。使用它需要首先在 http 配置段中定义限制的参照标准和状态缓存区大小。

• limit_req_zone 只能配置在 http 范围内；
• $binary_remote_addr 表示客户端请求的IP地址；
• mylimit 自己定义的变量名；
• rate 请求频率，每秒允许多少请求；

limit_req 与 limit_req_zone 对应，burst 表示缓存的请求数，也就是任务队列。

下面的配置就是定义了使用客户端的 IP 作为参照依据，并使用一个 10M 大小的状态缓存区。结尾的 rate=1r/s 表示针对每个 IP 的请求每秒只接受一次。

10M 的状态缓存空间够不够用呢？官方给出的答案是 1M 的缓存空间可以在 32 位的系统中服务 3.2 万 IP 地址，在 64 位的系统中可以服务 1.6 万 IP 地址，所以需要自己看情况调整。如果状态缓存耗光，后面所有的请求都会收到 503(Service Temporarily Unavailable) 错误。

# 定义了一个 mylimit 缓冲区（容器），请求频率为每秒 1 个请求（nr/s）
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
    listen  70;
    location / {
        # nodelay 不延迟处理
        # burst 是配置超额处理,可简单理解为队列机制
        # 上面配置同一个 IP 没秒只能发送一次请求（1r/s），这里配置了缓存3个请求，就意味着同一秒内只能允许 4 个任务响应成功，其它任务请求则失败（503错误）
        limit_req zone=mylimit burst=3 nodelay;
        proxy_pass http://localhost:7070;
    }
}

说明：

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

• 第一个参数：$binary_remote_addr 表示通过remote_addr这个标识来做限制，“binary_”的目的是缩写内存占用量，是限制同一客户端ip地址。
• 第二个参数：zone=one:10m表示生成一个大小为10M，名字为one的内存区域，用来存储访问的频次信息。
• 第三个参数：rate=1r/s表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，还可以有比如30r/m的

limit_req zone=mylimit burst=3 nodelay;

• 第一个参数：zone=one 设置使用哪个配置区域来做限制，与上面limit_req_zone 里的name对应。
• 第二个参数：burst=5，重点说明一下这个配置，burst爆发的意思，这个配置的意思是设置一个大小为5（个）的缓冲区当有大量请求（爆发）过来时，超过了访问频次限制的请求可以先放到这个缓冲区内。
• 第三个参数：nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回503，如果没有设置，则所有请求会等待排队。

另外，下面配置可以限制特定UA（比如搜索引擎）的访问：

limit_req_zone  $anti_spider  zone=one:10m   rate=10r/s;
limit_req zone=one burst=100 nodelay;
if ($http_user_agent ~* "googlebot|bingbot|Feedfetcher-Google") {
    set $anti_spider $http_user_agent;
}

其他参数:

Syntax: limit_req_log_level info | notice | warn | error;
Default:    
limit_req_log_level error;
Context:    http, server, location

当服务器由于limit被限速或缓存时，配置写入日志。延迟的记录比拒绝的记录低一个级别。例子：limit_req_log_level notice延迟的的基本是info。

Syntax: limit_req_status code;
Default:    
limit_req_status 503;
Context:    http, server, location

设置拒绝请求的返回值。值只能设置 400 到 599 之间。

3.1.1 实战

（1）限制访问速率

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit;
    }
}

上述规则限制了每个IP访问的速度为2r/s，并将该规则作用于根目录。如果单个IP在非常短的时间内并发发送多个请求，结果会怎样呢？

image.png

我们使用单个IP在10ms内发并发送了6个请求，只有1个成功，剩下的5个都被拒绝。我们设置的速度是2r/s，为什么只有1个成功呢，是不是Nginx限制错了？当然不是，是因为Nginx的限流统计是基于毫秒的，我们设置的速度是2r/s，转换一下就是500ms内单个IP只允许通过1个请求，从501ms开始才允许通过第二个请求。

（2）BURST缓存处理

我们看到，我们短时间内发送了大量请求，Nginx按照毫秒级精度统计，超出限制的请求直接拒绝。这在实际场景中未免过于苛刻，真实网络环境中请求到来不是匀速的，很可能有请求“突发”的情况，也就是“一股子一股子”的。Nginx考虑到了这种情况，可以通过burst关键字开启对突发请求的缓存处理，而不是直接拒绝。
来看我们的配置：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit burst=4;
    }
}

我们加入了burst=4，意思是每个key(此处是每个IP)最多允许4个突发请求的到来。如果单个IP在10ms内发送6个请求，结果会怎样呢？

image.png

相比实例一成功数增加了4个，这个我们设置的burst数目是一致的。具体处理流程是：1个请求被立即处理，4个请求被放到burst队列里，另外一个请求被拒绝。通过burst参数，我们使得Nginx限流具备了缓存处理突发流量的能力。

但是请注意：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 { 
    location / { 
        limit_req zone=mylimit burst=4 nodelay;
    }
}

单个IP 10ms内并发发送6个请求，结果如下：

image.png

跟实例二相比，请求成功率没变化，但是总体耗时变短了。这怎么解释呢？实例二中，有4个请求被放到burst队列当中，工作进程每隔500ms(rate=2r/s)取一个请求进行处理，最后一个请求要排队2s才会被处理；实例三中，请求放入队列跟实例二是一样的，但不同的是，队列中的请求同时具有了被处理的资格，所以实例三中的5个请求可以说是同时开始被处理的，花费时间自然变短了。

但是请注意，虽然设置burst和nodelay能够降低突发请求的处理时间，但是长期来看并不会提高吞吐量的上限，长期吞吐量的上限是由rate决定的，因为nodelay只能保证burst的请求被立即处理，但Nginx会限制队列元素释放的速度，就像是限制了令牌桶中令牌产生的速度。

看到这里你可能会问，加入了nodelay参数之后的限速算法，到底算是哪一个“桶”，是漏桶算法还是令牌桶算法？当然还算是漏桶算法。考虑一种情况，令牌桶算法的token为耗尽时会怎么做呢？由于它有一个请求队列，所以会把接下来的请求缓存下来，缓存多少受限于队列大小。但此时缓存这些请求还有意义吗？如果server已经过载，缓存队列越来越长，RT越来越高，即使过了很久请求被处理了，对用户来说也没什么价值了。所以当token不够用时，最明智的做法就是直接拒绝用户的请求，这就成了漏桶算法。

（4）自定义返回值

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server { 
    location / { 
        limit_req zone=mylimit burst=4 nodelay;
        limit_req_status 598;
    }
}

默认情况下 没有配置 status 返回值的状态：

image.png

自定义 status 返回值的状态：

image.png

limit_req_zone  $anti_spider  zone=one:10m   rate=10r/s;
limit_req zone=one burst=100 nodelay;
if ($http_user_agent ~* "googlebot|bingbot|Feedfetcher-Google") {
    set $anti_spider $http_user_agent;
}

（2）BURST缓存处理

3.2 并发限制

这个模块用来限制单个IP的请求数。并非所有的连接都被计数。只有在服务器处理了请求并且已经读取了整个请求头时，连接才被计数。

Syntax: limit_conn zone number;
Default: —
Context: http, server, location

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    location /download/ {
        limit_conn addr 1;
    }

一次只允许每个IP地址一个连接。

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;

server {
    ...
    limit_conn perip 10;
    limit_conn perserver 100;
}

可以配置多个limit_conn指令。例如，以上配置将限制每个客户端IP连接到服务器的数量，同时限制连接到虚拟服务器的总数。

Syntax: limit_conn_zone key zone=name:size;
Default: —
Context: http

limit_conn_zone $binary_remote_addr zone=addr:10m;

这里，客户端IP地址作为关键。请注意，不是 binary_remote_addr变量。 binary_remote_addr变量的大小始终为4个字节，对于IPv6地址则为16个字节。存储状态在32位平台上始终占用32或64个字节，在64位平台上占用64个字节。一个兆字节的区域可以保持大约32000个32字节的状态或大约16000个64字节的状态。如果区域存储耗尽，服务器会将错误返回给所有其他请求。

• $binary_remote_addr：定义限流对象，binary_remote_addr 是一种 key，表示基于 remote_addr(客户端 IP) 来做限流，binary_ 的目的是压缩内存占用量。
• zone：定义共享内存区来存储访问信息， myRateLimit:10m 表示一个大小为10M，名字为myRateLimit的内存区域。1M 内存能存储16000个 IP 地址的访问信息，10M 内存可以存储 16W个 IP地址访问信息。
• rate：用于设置最大访问速率，rate=10r/s 表示每秒最多处理10个请求。Nginx 实际上以毫秒为粒度来跟踪请求信息，因此 10r/s 实际上是限制：每100毫秒处理一个请求。这意味着，自上一个请求处理完后，若后续100毫秒内又有请求到达，将拒绝处理该请求。
• zone=myRateLimit 设置使用哪个配置区域来做限制，与 limit_req_zone 里的配置对应

处理突发流量
上面例子限制 10r/s，正常流量稍微增大，请求就会被拒绝，面对突发流量，可以结合 burst 参数使用来解决该问题。

server {
    location / {
        limit_req zone=myRateLimit burst=20;
        proxy_pass http://my_upstream;
    }
}

burst 译为突发、爆发，表示在超过设定的处理速率后能额外处理的请求数。当 rate=10r/s 时，将1s拆成10份，即每100ms可处理1个请求。此处，burst=20，若同时有20个请求到达，Nginx 会处理第一个请求，剩余19个请求将放入队列，然后每隔100ms从队列中获取一个请求进行处理。若请求数大于20，将拒绝处理多余的请求，直接返回 503

不过，单独使用 burst 参数并不实用。假设 burst=50，rate依然为10r/s，排队中的50个请求虽然每100ms会处理一个，但第50个请求却需要等待 50 * 100ms即 5s，这么长的处理时间自然难以接受。因此，burst 往往结合 nodelay 一起使用。

server {
    location / {
        limit_req zone=myRateLimit burst=20 nodelay;
        proxy_pass http://my_upstream;
    }
}

nodelay 针对的是 burst 参数，burst=20 nodelay 表示这20个请求立马处理，不能延迟，相当于特事特办。不过，即使这20个突发请求立马处理结束，后续来了请求也不会立马处理。burst=20 相当于缓存队列中占了20个坑，即使请求被处理了，这20个位置这只能按 100ms 一个来释放。
这就达到了速率稳定，但突然流量也能正常处理的效果。

链接：https://www.jianshu.com/p/f3cd441e119a

Syntax: limit_conn_log_level info | notice | warn | error;
Default:
limit_conn_log_level error;
Context: http, server, location

当服务器限制连接数时，设置所需的日志记录级别。

Syntax: limit_conn_status code;
Default:
limit_conn_status 503;
Context: http, server, location

设置拒绝请求的返回值。

4参考

（1）高并发下的Nginx限流实战 https://zhuanlan.zhihu.com/p/78113920

（2）nginx 限流配置 https://www.cnblogs.com/biglittleant/p/8979915.html

（3）【Nginx源码研究】nginx限流模块详解 https://www.imooc.com/article/91383

（4）Nginx 限流 https://colobu.com/2015/10/26/nginx-limit-modules/

（5） 死磕nginx系列--nginx 限流配置https://www.cnblogs.com/biglittleant/p/8979915.html

（6）性能测试网站
http://www.fairytest.com/newversion/apiTool

5、为限流系统配置日志级别

限流系统会提前拒绝请求，因此，我们在业务服务器上是肯定看不到这些请求的。假如我们收到一个报告说某用户在使用网站的时候出现错误，但是我们在业务服务器上又找不到相关的日志，我们如何确定是不是限流造成的呢？

只有限流系统的日志才能说明问题。因此，我们需要Nginx打印出它拒绝掉的请求的信息。但同时，Nginx打印的限流日志默认是错误（error），如果我们设置了一个基于日志错误扫描的警报，它扫到的限流错误，真的是我们希望给自己发警报的情况吗？

配置请求的位置就在资源中，使用的命令是limit_req_log_level，如下：

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

     server {
         location /test/ {
             limit_reqzone=mylimit burst=20;
             limit_req_log_level warn;

             proxy_passhttp://backend;
         }
     }
 }

在第7行中，我们将Nginx的日志改为了警告（warn）。

6、修改Nginx的限流响应状态码

限流的HTTP标准响应状态码是429，但是如果读者拿上述的配置文件直接去测试，会发现Nginx返回的是503（服务不可用）。到底应该返回什么状态码，是一个偏程序哲学的问题，此处我们不讨论，我们只讨论：如何让Nginx返回我们指定的状态码？

答案也是在同一个资源中，它的配置命令是limit_req_status，然后我们指定它为429即可：

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

     server {
         location /test/ {
             limit_reqzone=mylimit burst=20;
            limit_req_log_level warn;
            limit_req_status 429;

             proxy_passhttp://backend;
         }
     }
 }

除了以上功能以外，Nginx还支持很多复杂先进的限流功能，可以访问https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/作进一步的了解。

参考：
链接：https://www.jianshu.com/p/e8092c35e4b2

作者：笔名辉哥
链接：https://www.jianshu.com/p/93e2790a6817
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

使用JMeter压力测试工具测试NGINX限流配置实践
https://www.jianshu.com/p/e813d71bd9a4