Nginx限流

来源：https://www.cnblogs.com/biglittleant/p/8979915.html
作者：biglittleant

nginx限流的作用

一、限制访问频率（正常流量）

Nginx中我们使用 ngx_http_limit_req_module模块来限制请求的访问频率，基于漏桶算法原理实现。接下来我们使用 nginx limit_req_zone 和 limit_req 两个指令，限制单个IP的请求处理速率。

语法：limit_req_zone key zone rate

• key ：定义限流对象，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毫秒内又有请求到达，将拒绝处理该请求。

二、限制访问频率（突发流量）

按上面的配置在流量突然增大时，超出的请求将被拒绝，无法处理突发流量，那么在处理突发流量的时候，该怎么处理呢？Nginx提供了 burst 参数来解决突发流量的问题，并结合 nodelay 参数一起使用。burst 译为突发、爆发，表示在超过设定的处理速率后能额外处理的请求数。

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

三、限制并发连接数
Nginx 的 ngx_http_limit_conn_module模块提供了对资源连接数进行限制的功能，使用 limit_conn_zone 和 limit_conn 两个指令就可以了。

• limit_conn perip 20：对应的key是 $binary_remote_addr，表示限制单个IP同时最多能持有20个连接。
• limit_conn perserver 100：对应的key是 $server_name，表示虚拟主机(server)
  同时能处理并发连接的总数。注意，只有当 request header 被后端server处理后，这个连接才进行计数。

限流算法

令牌桶算法

算法思想是：

• 令牌以固定速率产生，并缓存到令牌桶中；
• 令牌桶放满时，多余的令牌被丢弃；
• 请求要消耗等比例的令牌才能被处理；
• 令牌不够时，请求被缓存。

漏桶算法

算法思想是：

• 水（请求）从上方倒入水桶，从水桶下方流出（被处理）；
• 来不及流出的水存在水桶中（缓冲），以固定速率流出；
• 水桶满后水溢出（丢弃）。
• 这个算法的核心是：缓存请求、匀速处理、多余的请求直接丢弃。
  相比漏桶算法，令牌桶算法不同之处在于它不但有一只“桶”，还有个队列，这个桶是用来存放令牌的，队列才是用来存放请求的。
  从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理，漏桶算法能够强行限制数据的实时传输（处理）速率，对突发流量不做额外处理；而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程度的突发传输。

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

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

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

limit_req_zone 参数配置

  Syntax:    limit_req zone=name [burst=number] [nodelay];
    Default:    —
    Context:    http, server, location

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=one burst=5 nodelay;

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

    http {
        limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
        server {
            location /search/ {
                limit_req zone=one burst=5 nodelay;
            }
    }  

下面配置可以限制特定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 之间。

ngx_http_limit_conn_module 参数配置

这个模块用来限制单个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地址作为关键。请注意，不是 $ remote_addr ，而是使用 $ binary_remote_addr 变量。$ remote_addr
变量的大小可以从7到15个字节不等。存储的状态在32位平台上占用32或64字节的内存，在64位平台上总是占用64字节。对于IPv4地址， $ binary_remote_addr
变量的大小始终为4个字节，对于IPv6地址则为16个字节。存储状态在32位平台上始终占用32或64个字节，在64位平台上占用64个字节。一个兆字节的区域可以保持大约32000个32字节的状态或大约16000个64字节的状态。如果区域存储耗尽，服务器会将错误返回给所有其他请求。

    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

设置拒绝请求的返回值。

实战

实例一 限制访问速率

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

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

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

实例二 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个请求，结果会怎样呢？
设置burst

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

但是请注意：burst的作用是让多余的请求可以先放到队列里，慢慢处理。如果不加nodelay参数，队列里的请求不会立即处理，而是按照rate设置的速度，以毫秒级精确的速度慢慢处理。

实例三 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个请求，结果如下：
加粗样式

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

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

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

示例四 自定义返回值

    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 返回值的状态： **
没有配置 status

自定义 status 返回值的状态：

参考文档

Nginx限制访问速率和最大并发连接数模块--limit (防止DDOS攻击)  
Nginx 限流   
关于nginx的限速模块   
[ Nginx 源代码笔记 - HTTP 模块 - 流控 ](http://ialloc.org/posts/2014/07/26/ngx-notes-
module-http-limit/)  
Module ngx_http_limit_conn_module  
Module ngx_http_limit_req_module  
Nginx限速模块初探 

实战：使用Nginx限流

Nginx不仅可以做Web服务器、做反向代理、负载均衡，还可以做限流系统。此处我们就Nginx为例，介绍一下如何配置一个限流系统。
Nginx使用的限流算法是漏桶算法。
（1）是安装Nginx。Nginx的安装我们在8.5.7中已经详细叙述过，此处简单再提一下：
如果你的Linux是Ubuntu或Debian，使用apt-get安装，在命令行中输入以下命令：

$ sudo apt-get update
$ sudo apt-get install nginx

如果是CentOS，使用yum安装，在命令行中输入以下命令：

$ sudo yum install epel-release
$ sudo yum update
$ sudo yum install nginx

（2）找到Nginx所使用的配置文件所在的位置。在Ubuntu和Debian是在如下位置：

$ cd /etc/nginx/sites-available/

而CentOS则是在如下位置：

$ cd /etc/nginx/conf.d/

（3）在http块中，配置基础的限流配置：

 http 
{     limit_req_zone$binary_remote_addr zone=mylimit:10m rate=10r/s;
   
     server {
         location /test/ {
             limit_reqzone=mylimit;
    
             proxy_passhttp://backend;
         }
     }
 }

其中4到8行定义的是一个服务器接口。而第2行和第6行配合完成了一个限流设置，下面解释一下这两行做的事情：
limit_req_zone命令在Nginx的配置文件中专门用于定义限流，它必须被放在http块中，否则无法生效，因为该命令只在http中被定义。
该字段包含三个参数：
第一个参数，就是键（key），即值$binar{y}_{r}emot{e}_{a}ddr所在的位置，它代表的是我们的限流系统限制请求所用的键。此处，我们使用了$binary_remote_addr，它是Nginx内置的一个值，代表的是客户端的IP地址的二进制表示。因此换言之，我们的示例配置，是希望限流系统以客户端的IP地址为键进行限流。
对Nginx有经验的读者可能还知道有一个Nginx内置值为$remot{e}_{a}ddr，它同样表示客户端的IP地址，因此我们也可以使用这个值。$binary_remote_addr是Nginx的社区推荐用值，因为它是二进制表达，占用的空间一般比字符串表达的$remote_addr要短一些，在寸土寸金的限流系统中尤为重要。
第二个参数是限流配置的共享内存占用（zone）。为了性能优势，Nginx将限流配置放在共享内存中，供所有Nginx的进程使用，因为它占用的是内存，所以我们希望开发者能够指定一个合理的、既不浪费又能存储足够信息的空间大小。根据实践经验，1MB的空间可以储存16000个IP地址。
该参数的语法是用冒号隔开的两个部分，第一部分是给该部分申请的内存一个名字，第二部分是我们希望申请的内存大小。
因此，在该声明中，我们声明了一个名叫mylimit（我的限制）的内存空间，然后它的大小是10M，即可以存储160000个IP地址，对于实验来说足够了。
第三个配置就是访问速率（rate）了，格式是用左斜杠隔开的请求数和时间单位。这里的访问速率就是最大速率，因此10r/s就是每秒10个请求。通过这台Nginx服务器访问后端服务器的请求速率无法超过每秒10个请求。
注意到第5行声明了一个资源位置/test/，因此我们第6行的配置就是针对这个资源的，通俗地说，我们在第6行的配置是针对特定API的，这个API就是路径为/test/的API，而其真正路径就是第8行声明的http://backend。注意，这个URL是不存在的，实际操作中，读者需要将它换成你已经开发好的业务逻辑所在的位置，Nginx在这里的作用只是一个反向代理，它自己本身没有资源。
第6行中，我们使用limit_req命令，声明该API需要一个限流配置，而该限流配置所在位置（zone）就是mylimit。
这样一来，所有发往该API的请求会先读到第6行的限流配置，然后根据该限流配置mylimit的名称找到声明在第2行的参数，然后决定该请求是否应该被拒绝。
但是这样还不够。不要忘了，Nginx使用的漏桶算法，不是时间窗口算法，我们前文介绍中说过，漏桶算法是有两个参数可以配置的！
（4）配置峰值。Nginx漏桶算法的峰值属性在API中设置。参数名为burst。如下：

01 http {
02     limit_req_zone$binary_remote_addr zone=mylimit:10m rate=10r/s;
03
04     server {
05         location /test/ {
06             limit_reqzone=mylimit burst=20;
07
08             proxy_passhttp://backend;
09         }
10     }
11 }

在第6行中，我们只需要在声明limit_req的同时，指定burst就可以了，此处我们指定burst为20，即漏桶算法中我们的“桶”最多可以接受20个请求。
这样一个Nginx的限流系统就配置完毕了，但实际操作中，我们还可能需要很多别的功能，下面笔者就介绍几个很有用的配置技巧。

1.加快Nginx转发速度

相对于传统的漏桶算法慢吞吞地转发请求的缺陷，Nginx实现了一种漏桶算法的优化版，允许开发者指定快速转发，而且还不影响正常的限流功能。开发者只需要在指定limit_req的一行中指定burst之后指定另一个参数nodelay，就可以在请求总数没有超过burst指定值的情况下，迅速转发所有请求了。如下所示：

01 http {
02     limit_req_zone$binary_remote_addr zone=mylimit:10m rate=10r/s;
03
04     server {
05         location /test/ {
06             limit_reqzone=mylimit burst=20 nodelay;
07
08             proxy_passhttp://backend;
09         }
10     }
11 }

读者可能会担忧：这种情况下，会不会出现所有请求都被快速转发，然后接下来又有没有超过burst数量的请求出现，再次被快速转发，就好像固定窗口算法的漏洞一样，从而超过我们本来希望它能限制到的上限数量呢？答案是不会。Nginx的快速转发是这样实现的：
· 当有没有超过burst上限的请求数量进入系统时，快速转发，然后将当前桶中可以填充的数量标为0；
· 按照我们设置的rate在1秒中内缓慢增加桶中余额，以我们的配置为例，每隔100毫秒，增加1个空位；
· 在增加空位的过程中，进来超过空位数量的请求，直接拒绝。

举例而言，配置如上所示，假如在某个瞬时有25个请求进入系统，Nginx会先转发20个（或21个，取决于瞬时情况），然后拒绝剩下的4个请求，并将当前桶中数量标为0，然后接下来的每100毫秒，缓慢恢复1个空位。
这样我们可以看到，Nginx既做到了快速转发消息，又不会让后端服务器承担过多的流量。

2.为限流系统配置日志级别

限流系统会提前拒绝请求，因此，我们在业务服务器上是肯定看不到这些请求的。假如我们收到一个报告说某用户在使用网站的时候出现错误，但是我们在业务服务器上又找不到相关的日志，我们如何确定是不是限流造成的呢？
只有限流系统的日志才能说明问题。因此，我们需要Nginx打印出它拒绝掉的请求的信息。但同时，Nginx打印的限流日志默认是错误（error），如果我们设置了一个基于日志错误扫描的警报，它扫到的限流错误，真的是我们希望给自己发警报的情况吗？
配置请求的位置就在资源中，使用的命令是limit_req_log_level，如下：

01 http {
02     limit_req_zone$binary_remote_addr zone=mylimit:10m rate=10r/s;
03
04     server {
05         location /test/ {
06             limit_reqzone=mylimit burst=20;
07            limit_req_log_level warn;
08
09             proxy_passhttp://backend;
10         }
11     }
12 }

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

3.更换Nginx的限流响应状态码

前文我们就说过，从语义上来说，限流的HTTP标准响应状态码是429，但是如果读者拿上述的配置文件直接去测试，会发现Nginx返回的是503（服务不可用）。到底应该返回什么状态码，是一个偏程序哲学的问题，此处我们不讨论，我们只讨论：如何让Nginx返回我们指定的状态码？
答案也是在同一个资源中，它的配置命令是limit_req_status，然后我们指定它为429即可：

01 http {
02     limit_req_zone$binary_remote_addr zone=mylimit:10m rate=10r/s;
03
04     server {
05         location /test/ {
06             limit_reqzone=mylimit burst=20;
07            limit_req_log_level warn;
08            limit_req_status 429;
09
10             proxy_passhttp://backend;
11         }
12     }
13 }

参考链接 ：

如何使用 Nginx 优雅的限流 ： https://mp.weixin.qq.com/s/54L8M3bpCJqEZy5t35H6ig

实战：使用Nginx限流 ： https://mp.weixin.qq.com/s/T6pdpJq6U8llgKKUkz-hgw

https://baijiahao.baidu.com/s?id=1634400719648980722&wfr=spider&for=pc