限流算法和nginx请求限流
一、限流算法
常见的限流算法有计数器（固定窗口）、滑动窗口、漏桶、令牌桶
1、计数器（固定窗口）
最简单的限流算法，计数器限制每一分钟或者每一秒钟内请求不能超过一定的次数，在下一秒钟计数器清零重新计算
计数器限流存在一个缺陷，比如限制每分钟访问不能超过100次，客户端在第一分钟的59秒请求100次，在第二分钟的第1秒又请求了100次，那么在这2秒内后端会受到200次请求的压力，形成了流量突刺
2、滑动窗口
滑动窗口其实是细分后的计数器，它将每个时间窗口又细分成若干个时间片段，每过一个时间片段，整个时间窗口就会往右移动一格
比如限制每分钟访问不能超过100次，如图每分钟被分成了4个时间片段，每个时间片段15秒，假设客户端在第一分钟的50秒请求了100次，时间到了第二分钟的10秒，时间窗口向右滑动一格，这时这个时间窗口其实已经打满了100次，客户端将被拒绝访问
时间窗口划分的越细，滑动窗口的滚动就越平滑，限流的效果就会越精确
3、漏桶
漏桶算法类似一个限制出水速度的水桶，通过一个固定大小FIFO队列+定时取队列元素的方式实现，请求进入队列后会被匀速的取出处理（桶底部开口匀速出水），当队列被占满后后来的请求会直接拒绝（水倒的太快从桶中溢出来）
漏桶桶的优点是可以削峰填谷，不论请求多大多快，都只会匀速发给后端，不会出现突刺现象，保证下游服务正常运行
缺点就是在桶队列中的请求会排队，响应时间拉长
4、令牌桶
令牌桶算法是以一个恒定的速度往桶里放置令牌（如果桶里的令牌满了就废弃），每进来一个请求去桶里找令牌，有的话就拿走令牌继续处理，没有就拒绝请求
令牌桶的优点是可以应对突发流量，当桶里有令牌时请求可以快速的响应，也不会产生漏桶队列中的等待时间
缺点就是相对漏桶一定程度上减小了对下游服务的保护
二、nginx请求限流（ngx_http_limit_req_module）
对于nginx接入层限流可以使用nginx自带的两个模块：连接数限流模块ngx_http_limit_conn_module和漏桶算法实现的请求限流模块ngx_http_limit_req_module，还可以使用OpenResty提供的Lua限流模块lua-resty-limit-traffic进行更复杂的限流场景
本文只介绍请求限流模块ngx_http_limit_req_module，主要的指令是limit_req_zone和limit_req
1、指令介绍
（1）limit_req_zone
设置共享内存区域的大小和请求的速率
语法：limit_req_zone key zone=name:size rate=rate; 位置：http 版本：1.7.6之前key只可包含一个变量 示例：limit_req_zone $binary_remote_addr zone=test123:10m rate=10r/s;
key：
定义要限流的对象，通常是nginx内置变量，多个key可以用逗号分隔，示例中$binary_remote_addr是限制每个ip的请求速率
一般有$binary_remote_addr（客户的ip）、$server_name（服务器名称）、$uri（不带参数的请求地址）、$request_uri（带参数的请求地址），更多变量可以在nginx包的"\src\http\ngx_http_variables.c"文件中查看，或者查看本文的最后
zone：
定义存放限流信息的共享内存区域，记录每类客户端的访问频率，在worker进程间共享，size表示区域大小
比如使用$binary_remote_addr的情况，“binary_”表示内存占用量经过缩减，IPv4固定占用4字节、IPv6固定占用16字节，在32位系统，每一个IP在32位系统将占用64字节、在64位系统将占用128字节来保存状态，1m空间在32位系统能保存1w6多个IP的状态，在64位系统能保存8k多个IP的状态
当内存空间耗尽时nginx使用lru算法淘汰最长时间未使用的key，如果释放的空间仍不足以容纳新记录，nginx将直接限制请求返回状态码，所以需要提前预估key的数量分配合理的内存空间，避免指定的内存空间被耗尽
rate：
设置最大请求速率，在示例中速率不能超过每秒10个请求，nginx以毫秒粒度跟踪请求，因此实际上是限制每100ms1个请求
如果希望限制每分钟可以指定“r/m”
limit_req_zone指令只是定义了共享区域和速率的参数，实际并没有限制请求，需要在server或者location中设置limit_req来搭配使用
（2）limit_req
设置所属共享区域名称和请求最大突发大小，并在指令出现的上下文中启用速率限制
语法：limit_req zone=name [burst=number] [nodelay | delay=number]; 位置：http, server, location 版本：1.15.7后可以使用delay参数 示例：limit_req zone=test123 burst=5;
zone：和需要对应的limit_req_zone内存区域名称一致
burst：可选参数，设置允许突发请求的数量
nodelay：无延迟排队
delay：分段限速
burst、nodelay、delay参数不同的组合可以产生4种限流效果，在下一节限流效果演示中会逐一说明
指令可以叠加使用，示例中配置了单个ip地址的处理速度，同时限制了整个服务的处理速度
limit_req_zone $binary_remote_addr zone=perip:10m rate=1r/s;
limit_req_zone $server_name zone=perserver:10m rate=10r/s;
server {
...
limit_req zone=perip burst=5 nodelay;
limit_req zone=perserver burst=10;
}
将基本速率限制与其他nginx功能结合使用，可以实现更细微的流量限制，比如搭配geo和map指令可以实现对来自不在“白名单”上的任何人的请求施加速率限制：
geo $limit {
default 1;
10.0.0.0/8 0;
192.168.0.0/24 0;
}
map $limit $limit_key {
0 "";
1 $binary_remote_addr;
}
limit_req_zone $limit_key zone=req_zone:10m rate=5r/s;
server {
location / {
limit_req zone=req_zone burst=10 nodelay;
# ...
}
}
（3）limit_req_log_level
设置速率超出而拒绝请求或延迟请求处理的日志记录级别
语法：limit_req_log_level info | notice | warn | error; 默认：error 位置：http, server, location 版本：该指令出现在版本0.8.18以后
延迟请求比拒绝请求第一个等级，比如配置的是error，拒绝请求日志记录为error，延迟请求日志记录为warn
（4）limit_req_status
设置响应被拒绝请求的状态码
语法：limit_req_status code; 默认：503 位置：http, server, location 版本：该指令出现在1.3.15版以后
（5）limit_req_dry_run
启用空运行模式，开启后请求速率不受限制，但在共享内存区域中请求的数量将照常计算
语法：limit_req_dry_run on | off; 默认：off 位置：http, server, location 版本：该指令出现在1.17.1版以后
2、限流效果演示
（1）无burst的情况
没有配置burst桶容量，桶容量为0，按照固定速率处理请求，如果请求被限流，直接返回503
limit_req_zone $server_name zone=test123:10m rate=50r/s; limit_req zone=test123; jmeter线程数1，次数20
可以看到请求每隔20ms成功一次
（2）burst的情况
配置了burst桶容量，没有配置nodelay就是延迟模式，来不及处理的请求会进入桶中，桶内的请求会以固定速率被处理，如果桶满了，新进入的请求被限流
limit_req_zone $server_name zone=test123:10m rate=2r/s; limit_req zone=test123 burst=3; jmeter线程数6，一起请求2次，2批间隔300ms
速率为500ms成功一次，设置了burst桶容量为3，相当于一个长度3的缓冲队列
我们的预期是当同时有6个请求到达时，nginx将第1个请求立即处理，并将其余3个请求放入桶队列，然后它每500毫秒处理一个排队的请求，在请求使排队请求的数量超过3时返回503到客户端
第一次6个请求进入后，请求1-1第一个被执行，请求1-6、1-3、1-4幸运的进入桶队列中等待匀速执行，看到这4个请求间隔500ms，请求1-5、1-2因为来不及处理且桶满了被限流
第二次6个请求在最后一个请求1-4执行完后间隔300ms进入，这时距离下一次还不到500ms，所以新的请求得先进入桶队列中等待，看到请求1-3、1-5、1-6幸运的进入桶队列中，请求1-4、1-2被限流
如果2批请求间隔600ms呢？
那第二批请求将会成功4个，和第一批的情况一样
（3）burst+nodelay的情况
配置了burst桶容量，同时配置了nodelay就是非延迟模式，桶队列是一个有状态的插槽队列，当请求“过早”到达时，只要桶队列中有可用的插槽，nginx就会立即处理请求，并将该插槽标记为“已占用”，当某一次限流间隔过后没有请求时，该插槽就会被标记为“可用”
这种逻辑和令牌桶非常像，只要桶的插槽没有被占用完，突发的请求就能迅速被处理，不用像延迟模式一样需要进入队列排队等待，在流量洪峰过去后插槽可以慢慢被恢复，类似令牌慢慢被填充满桶
limit_req_zone $server_name zone=test123:10m rate=2r/s; limit_req zone=test123 burst=3 nodelay; jmeter线程数6，一起请求2次，2批间隔600ms
速率为500ms成功一次，设置了burst桶容量为3，相当于有3个插槽可用
我们的预期是当同时有6个请求到达时，nginx将第1个请求立即处理，同时也立即处理之后3个请求，同时将桶中的3个插槽标记占用，将其他2个请求限流，在第二批请求间隔600ms到达后，有一个请求被处理
第一次6个请求进入后，请求1-6第一个被执行，请求1-4、1-1、1-5幸运的使用了桶队列中的插槽被执行，看到这4个请求没有等待时间都是立即执行，请求1-3、1-2因为来不及处理且桶插槽用完被限流
第二次6个请求在第一批请求执行完后间隔600ms进入，这时距离下一次间隔超过了500ms，一个插槽被重置，请求1-5进入后幸运的使用了这个插槽被执行，其他5个请求因为来不及处理且桶插槽用完被限流
再看一下复杂一点的情况：
limit_req_zone $server_name zone=test123:10m rate=2r/s; limit_req zone=test123 burst=3 nodelay; jmeter线程数6，一起请求7次，分别间隔1000ms、300ms、300ms、300ms、1500ms、2000ms
一样的参数，线程请求7次，每批分别间隔1000ms、300ms、300ms、300ms、1500ms、2000ms
第一批序号1-6同第一个例子
第二批序号7-12，因为这次间隔是1000ms，所以有2个插槽被重置，成功了2个请求
第三批序号12-18，因为间隔300ms太短，没有到500ms间隔，请求全部限流
第四批序号19-24，序号1的第一个请求是51.815执行的，每隔500ms恢复一个插槽的话，第3次恢复是在53.315，刚好53.447序号19的请求1-1拿到了这个插槽，之后其他请求被限流
第五批序号25-30，间隔300ms，因为上一批53.447刚用掉插槽，下一个插槽恢复是在53.815（51.815+4*500ms），这一批是53.754没有到时间，所以请求全部被限流
第六批序号31-36，间隔了1500ms，到55.261已经恢复了3个插槽了（53.815，54.315，54.815），所以成功了3个请求
第七批序号37-42，间隔了2000ms，到57.307恢复了4个插槽（55.315，55.815，56.315，56.815），所以成功了4个请求
（4）burst+delay的情况
配置了burst桶容量和delay参数后，就是部分延迟模式，比如burst=12，delay=8，则桶的前8位是插槽队列，后4位是缓冲队列
假设有这样的配置：
limit_req_zone $server_namezone=test123:10m rate=5r/s; limit_req zone=test123 burst=12 delay=8;
该配置最多允许12个突发请求，其中前8个突发请求将被立即处理，后4个请求被强制以5 r / s的匀速执行，在缓冲队列空出之前多于12个的请求被限流
使用此配置后，以8 r / s连续发出请求流的客户端将表现为图中的情况
通过测试可以发现nginx会先等待缓冲队列清空后再恢复插槽队列
limit_req_zone $server_name zone=test123:10m rate=2r/s; limit_req zone=test123 burst=6 delay=4; jmeter线程数10，一起请求2次，2批间隔300ms
速率为500ms成功一次，设置了burst桶容量为6，delay为4，相当于有4个插槽可用，附带一个长度为2的缓冲队列
我们的预期是第一批10个请求进来立即执行1+4个请求，有2个请求进入队列缓慢执行，执行完后间隔300ms，第二批10个请求进来，有2个请求进入空出的缓冲队列，其他8个请求限流（因为300ms，没有到500ms的间隔，插槽没有来得及恢复）
第一批10个请求进入后，前5个请求立即被执行（4个使用了插槽），请求1-10、1-1进入缓冲队列匀速执行，可以看到请求间隔了500ms，其他3个请求既没有使用插槽，也没有进缓冲队列，被限流
第二批10个请求间隔300ms进入，这时虽然缓冲队列是空的，但是插槽来不及恢复，所以只有2个缓冲队列的位置可用，所以看到请求1-6、1-8进入了队列匀速执行
如果把两批请求的间隔延长一些呢？
limit_req_zone $server_name zone=test123:10m rate=2r/s; limit_req zone=test123 burst=6 delay=4; jmeter线程数10，一起请求2次，2批间隔1600ms
间隔改为1600ms，足够3个插槽恢复了
可以看到表现和预期的一样，和间隔300ms的图唯一区别，序号11-13的3个请求拿到了恢复的3个插槽，立刻被执行了
3、附nginx内置变量
$args 请求中的参数; $binary_remote_addr 远程地址的二进制表示 $body_bytes_sent 已发送的消息体字节数 $content_length HTTP请求信息里的"Content-Length" $content_type 请求信息里的"Content-Type" $document_root 针对当前请求的根路径设置值 $document_uri 与$uri相同 $host 请求信息中的"Host"，如果请求中没有Host行，则等于设置的服务器名; $http_cookie cookie 信息 $http_referer 来源地址 $http_user_agent 客户端代理信息 $http_via 最后一个访问服务器的Ip地址 $http_x_forwarded_for 相当于网络访问路径。 $limit_rate 对连接速率的限制 $remote_addr 客户端地址 $remote_port 客户端端口号 $remote_user 客户端用户名，认证用 $request 用户请求信息 $request_body 用户请求主体 $request_body_file 发往后端的本地文件名称 $request_filename 当前请求的文件路径名 $request_method 请求的方法，比如"GET"、"POST"等 $request_uri 请求的URI，带参数 $server_addr 服务器地址，如果没有用listen指明服务器地址，使用这个变量将发起一次系统调用以取得地址(造成资源浪费) $server_name 请求到达的服务器名 $server_port 请求到达的服务器端口号 $server_protocol 请求的协议版本，"HTTP/1.0"或"HTTP/1.1" $uri 请求的URI，可能和最初的值有不同，比如经过重定向之类的
