Nginx限流应用 & 漏桶/令牌桶算法原理

梦飞

发布于 2022-06-23 13:16:12

8690

发布于 2022-06-23 13:16:12

文章目录

1. 前言

限流是一个后台服务的重要组成部分，尤其是在应对大量并发请求时，将流量限制到系统能够承受的范围内，才能保证系统安全高效运行。本文从nginx配置入手，先列举限流的几种场景和nginx限流配置的用法，结合实验验证，再详细分析nginx中的漏桶算法原理。

2. 限流场景

2.1 简单限流

最简单的限流，严格按照固定速率限流，超出的请求直接拒绝。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=12r/m;
    limit_req_status 429;
    server {
        location / {
            limit_req zone=one;
        }
}

limit_req_zone 定义了共享内存空间（用于存储请求数量等状态）和请求速率
$binary_remote_addr表示按照请求的ip地址限流
rate=12r/m表示限定速率为12r/m（12个请求每分钟），即每5s放行一个请求
zone=one:10m表示该空间容量为10M，名称为"one"
server下可以对每个服务路径指定 limit_req。如上面的配置zone=one指定了使用"one"这个空间做限流

实验验证：

10.99.16.41 - - [18/Feb/2022:17:04:45 +0800.1645175085.926] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:45 +0800.1645175085.926] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:45 +0800.1645175085.928] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.646] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.648] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.648] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.648] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.649] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.649] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:17:04:46 +0800.1645175086.653] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

其中两个中括号的内容分别表示访问时间和处理耗时。我们在5s内发送10个请求，只有一个请求成功了，其他请求都被拒绝（状态码为limit_req_status配置的429）。

2.2 削峰填谷

在实际的场景中，可能存在突发流量的情况，在短时间内请求速率高于限定速率，但从较大时间范围看，总速率在限定的范围之内。在这种情况下，直接拒绝超额的突发流量可能不是最好的策略，更好的策略是可以接受突发请求，并以限定的速率对请求进行处理（平滑流量），这样既不会超过限定速率，又可以尽可能地处理突发流量。在nginx中，这可以通过指定burst参数实现，如当burst=5，表示当请求超过限定速率时，允许超出的请求数量为5，这5个请求会阻塞等待，以限定速率依次通过。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=12r/m;
    server {
        location / {
            limit_req zone=one burst=10;
        }
}

这个配置仅在上文配置基础上，增加burst=10，表示在速率为12r/m（每5s放行一个请求）的基础上，允许超过限定速率的请求数量为10。

实验验证：

10.99.16.41 - - [18/Feb/2022:18:39:13 +0800.1645180753.117] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:13 +0800.1645180753.789] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:18 +0800.1645180758.124] [5.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:23 +0800.1645180763.119] [9.977s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:28 +0800.1645180768.139] [14.356s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:33 +0800.1645180773.144] [19.360s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:38 +0800.1645180778.131] [24.347s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:43 +0800.1645180783.148] [29.363s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:48 +0800.1645180788.135] [34.349s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:53 +0800.1645180793.130] [39.344s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:39:58 +0800.1645180798.167] [44.381s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:18:40:03 +0800.1645180803.146] [49.358s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

我们在5s内发了12个请求（超出请求数为11）时，第1个请求直接通过，第2~11个请求阻塞并每5s通过一个（耗时递增5s），第12个请求直接被拒绝（第二行日志）。注：nginx的访问日志是在实际放行请求时打印，不是在请求到达时打印，所以可以看到第12个请求的日志早于第2～11个请求，因为第12个请求直接被拒绝，耗时为0，而第2～11个请求阻塞在等待队列中，耗时较长。

Note: 这种策略也常用于“流量整形(Traffic Shaping)”

2.3 峰值快速处理

在上一个示例中，我们将峰值进行了平滑处理，以处理一定程度的突发流量，但我们可以看到，当请求队列较大时，排在后面的阻塞请求会有较大的延时，这无疑降低了用户体验。假如我们的服务本身就可以处理一定程度的突发流量（瞬间QPS高于平均水平），那我们就没必要将突发的流量阻塞，只要在burst允许范围内的流量就可以直接放行，这可以通过设置nodelay参数来实现。

配置示例：

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

实验验证：

10.99.16.41 - - [18/Feb/2022:19:05:00 +0800.1645182300.171] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:00 +0800.1645182300.173] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:00 +0800.1645182300.173] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.002] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.002] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.003] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.004] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.004] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.004] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.005] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.005] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.99.16.41 - - [18/Feb/2022:19:05:01 +0800.1645182301.007] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

我们同样在5s内发送了12个请求，可以看到第2～11个请求并没有被阻塞，而是被立即处理了，第12个请求由于超出了burst，所以直接被拒绝了。

2.4 削峰填谷+峰值快速处理

在峰值快速处理的例子中，当接收到超出限定速率的请求时，可以一定程度上快速处理，但系统的承受能力毕竟是有限的，所以burst的大小会受限于系统的承受能力。假如系统能承受的最大瞬间并发量为2000，但外部短时间内请求峰值为3000，那么这多出的这1000个请求就必须丢弃吗？有没有可能快速处理2000个请求，剩下1000个堵塞等待后续处理呢？答案是肯定的，这可以通过Nginx的delay=?配置来实现。这个配置表示在超出限定速率的请求中，超过多少个请求之后需要被延时处理，没有超过delay值的请求，无需等待。nodelay其实是delay的一种特殊情况，表示所有请求都无需等待，相当于delay的值等于burst。

配置示例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=12r/m;
    server {
        location / {
            limit_req zone=one burst=10 delay=8;
        }
}

delay=8表示超出限定速率的8个请求可以被快速处理，再超过的（当然也必须小于burst）就必须阻塞等待。

图0. rate=5r/s burst=12 delay=8 时的限流说明实验验证：

10.28.2.18 - - [21/Feb/2022:19:12:39 +0800.1645441959.522] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:39 +0800.1645441959.522] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:39 +0800.1645441959.523] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.194] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.195] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.196] [0.000s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:40 +0800.1645441960.197] [0.000s] "GET / HTTP/1.1" 429 169 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:44 +0800.1645441964.535] [4.339s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"
10.28.2.18 - - [21/Feb/2022:19:12:49 +0800.1645441969.539] [9.342s] "GET / HTTP/1.1" 200 4833 "-" "apifox/1.0.0 (https://www.apifox.cn)" "10.40.166.63"

同样在5s内发送12个请求，可以看到，第2~9个请求立即被处理，第10～11个请求被阻塞并以限定速率依次处理（最后两行），第12个请求（倒数第三行）直接被拒绝。

3. 漏桶原理

3.1 算法介绍

Nginx的流量控制其实是通过漏桶原理实现的，在网络上有许多关于漏桶算法的描述，与此相关的另一个算法——令牌桶算法也常常被提及，并且这两者容易引起混淆。但通过下文的分析，我们将看到这两个算法其实本质上是等价的。

我们先通过一个图来理解漏桶算法：

图1. 使用漏桶做流量监管

漏桶有固定容量（图中为T + τ），并以固定速率往外漏水
如果漏桶为空，停止泄漏
请求到达时，需要能够往桶中加入特定量的水。这个量可以每个请求都一样，也可以与请求报文的长度成比例
如果加入的水会导致桶溢出，那么请求被认为超出了限制，并且桶的水量保持不变

图1中小人就是负责监控桶中水量，当请求需要往桶中加入的水量为T，而当前水量已经超过τ时（也就是如果加入T，桶会溢出），小人会采取行动：

在流量监管（Traffic Policing）中（图1的情况），小人会打开陷阱的门，导致请求包被丢弃，并使水无法流入到桶中；
在流量整形（Traffic Shaping）中（如图2），小人会推起挡板，使得阻塞了请求的通过，直到水位降到τ或以下才放行请求。

图2.使用漏桶做流量整形

不难看出，在上面的情况中，当流量整形的队列长度为0时，就相当于流量监管，所以流量监管是流量整形的一种特殊情况。另外，漏桶算法的核心在于判断请求是否以特定速率通过，至于超出的请求，并没有统一的处理方式，可以是直接拒绝，也可以是阻塞等待等等，这由实现方或使用方决定。

需要指出的是，在上面的描述中，流量并没有以水的形式流过漏桶，桶只是作为一个标尺，用于判断请求是否能够通过。也有另外一种描述漏桶算法的版本，在这个版本中，桶中的水直接模拟流量以固定的速率流过漏桶。但是通过分析我们会发现后者是前者的一种特殊情况，这里不做详述，有兴趣的可以参考wikipedia对这两个版本的比较，有问题也欢迎随时交流。

3.2 与Nginx参数对应关系

通过对Nginx- Github源码的分析，以及实验验证，我们可以把nginx配置的参数对应到图2中。直接给结论：

将图2中的队列长度记为Q，桶容量记为C：

rate 对应漏桶往外漏水的速率
burst = τ+Q
T = 1，即每个请求往漏桶加一个单元的水量，且C=τ+1
delay = τ；若配置了nodelay则表示Q=0，即burst= τ；若delay和nodelay都没有配置，则τ=0，即burst=Q 且 C=1

有了这个对应关系，再去理解nginx的参数，就更加明了了。

3.3 与令牌桶比较

令牌桶算法描述如下：

每隔1/r秒一个令牌被加入到桶中（r为平均发送速率）
桶最多可以容纳b个令牌。如果令牌到达时桶已经满了，那么丢弃该令牌
当一个n个字节的报文到达时，就从令牌桶中删除n个令牌（如果有），并且将报文发送到网络
如果令牌桶中少于n个令牌，那么令牌不会被删除，并且认为这个报文在流量限制之外

把这个描述和漏桶的做对比，我们会发现，其实这是同一个算法思想的两种不同描述：

漏桶以固定速率往外漏水直到桶为空，并在报文到达时往内加水（要求不溢出）
令牌桶以固定速率往内加令牌直到加满，并在报文到达时往外取令牌（要求有足够令牌）

所以只要给定等价的参数，这两个算法的对外表现是一致的，性质上的差别只会来自具体实现的不同，底层逻辑是完全一样的。

3.4 代码实现

虽然漏桶或令牌桶在描述中都存在一个定时时钟，但实际实现其实基本都不是使用时钟来实现的，而是使用懒惰计算的方式，即在请求到达时才根据当前时间和预设的速率计算出当前桶内应有的水/令牌量，这样可以避免时钟的使用，提升性能的同时也使得算法可以在不支持时钟的系统中使用。另外，算法中的队列也基本上不会显式体现在代码中，基本是以sleep延时的方式把请求阻塞在内存中，隐式表示队列，并且队列的大小往往也需要由使用方自己维护。

Golang官方实现了一个基于令牌桶的限流器，另一个使用较多的令牌桶第三方库是 juju/ratelimit，而漏桶算法的代表库是 uber 在 Github 上开源的 go 语言库 ratelimit。

代码的详解待后续有机会再补充，可以先参考这几篇文章：

参考：

wikipedia - Leaky bucket 漏桶算法
wikipedia - Token bucket 令牌桶算法
Nginx - ngx_http_limit_req_module配置官方说明文档
官方文档 Rate Limiting with NGINX and NGINX Plus
Nginx - Github源码 ngx_http_limit_req_module
Nginx限制请求数(ngx_http_limit_req_module)实现详解（文中代码版本与最新版有些差别，请参考最新源码）
Golang 标准库限流器 time/rate 实现剖析
uber-go 漏桶限流器使用与原理分析
juju/ratelimit 令牌桶实现

本文参与腾讯云自媒体分享计划，分享自作者个人站点/博客。

原始发表：2022-06-21，如有侵权请联系 cloudcommunity@tencent.com 删除

编程算法

nginx

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！

编程算法

nginx

登录后参与评论

0 条评论

热度