前文中介绍了系统限流的原理和基础的使用场景,本篇将介绍应用接入层(Nginx)、分布式应用如何限流。
应用接入层限流(Nginx/OpenResty)
接入层通常是指流量的入口,主要的目的有:负载均衡、非法请求过滤、请求聚合、缓存、降级、限流、A/B测试、服务质量监控等。对于流量接入层所使用的中间件一般都是:Nginx(OpenResty)。下面将分别介绍一下如何进行限流操作。
Nginx
Nginx限流可以使用其自带的2个模块:连接数限流模块(ngx_http_limit_conn_module)和漏桶算法实现的请求限流模块(ngx_http_limit_req_module)。
ngx_http_limit_conn_module
limit_conn是用来对某个key对应的总的网络连接数进行限流,可以按照IP、host维度进行限流。不是每个请求都会被计数器统计,只有被Nginx处理并且已经读取了整个请求头的连接才会被计数。下面给出一个Demo(按照IP限流):
也可以按照host进行限流,Demo如下:
流程如下所示:
ngx_http_limit_req_module
limit_req是漏桶算法,对于指定key对应的请求进行限流。配置Demo如下:
limit_req的主要执行过程如下:
1、请求进入后首先判断上一次请求时间相对于当前时间是否需要限流,如果需要则执行步骤2,否则执行步骤3.
2、如果没有配置桶容量(burst=0),按照固定速率处理请求。如果请求被限流了,直接返回503;
如果配置了桶容量(burst>0),及延迟模式(没有配置nodelay)。如果桶满了,则新进入的请求被限流。如果没有满,则会以固定速率被处理;
如果配置了桶容量(burst>0),及非延迟模式(配置了nodelay)。则不会按照固定速率处理请求,而是允许突发处理请求。如果桶满了,直接返回503.
3、如果没有被限流,则正常处理请求。
4、Nginx会在响应时间选择一些(3个节点)限流key进行过期处理,进行内存回收。
OpenResty
Openresty提供了Lua限流模块lua-resty-limit-traffic,通过它可以按照更为复杂的业务逻辑进行动态限流处理。它也提供了limit.conn和limit.req的实现,算法与Nginx的limit_conn和limit_req是一样的。其下载地址为:lua-resty-limit-traffic,下载后,将其limit文件夹中的内容覆盖掉OpenResty安装目录中的resty中的limit文件夹即可。
lua-resty-limit-traffic
OpenResty中的限速,可以分为以下三种:limit_rate(限制响应速度)、limit_conn(限制连接数)、limit_req(限制请求数)。下面将分别介绍一下它们的用法。
limit_rate(限制响应速度)
Nginx有个$limit_rate,这个变量反映的是当前请求每秒能响应的字节数。该字节数默认为配置文件中 limit_rate指令的设值。 通过 OpenResty,我们可以直接在 Lua 代码中动态设置它。
limit_conn(限制连接数)
对于限制连接数,连接数限制并不是1S内的连接数限制,而是同一时刻的连接数限制。下面给出一个Demo:
nginx.conf
然后封装一个队req.conn的工具:limit_conn.lua
然后是接收到请求时的处理代码:access.lua
对于内容生成:content.lua,这里我们就简单的处理一下:
然后是内容生成后的后置代码:log.lua
笔者在MAC系统下使用webbench对接口进行测试,过程如下:
这里面-c表示10个并发,执行10S的压力测试。笔者从实验结果看来:
1、当设置limit_conn.new("limit_conn_store", 2, 2, 0.05)这个条件时,从第1S开始,200的响应结果为34个;后面的每一秒200的响应结果都维持在60个左右。
2、当设置limit_conn.new("limit_conn_store", 2, 2, 0.01)这个条件时,从第1S开始,200的响应结果为44个;后面的每一秒200的响应结果都维持在160个左右。
3、当设置limit_conn.new("limit_conn_store", 2, 2, 0.05)这个条件时,从第1S开始,200的响应结果为82个;后面的每一秒200的响应结果都维持在224个左右。
4、当设置limit_conn.new("limit_conn_store", 2, 2, 0.001)这个条件时,从第1S开始,200的响应结果为131个;后面的每一秒200的响应结果都维持在223个左右。
5、当设置limit_conn.new("limit_conn_store", 2, 2, 0.0001)这个条件时,从第1S开始,200的响应结果为171个;后面的每一秒200的响应结果都维持在300个左右。
从上面的结果看来,对于每个请求的执行时间预估越接近实际值或者时间略小于实际的平均值,最后榨取机器的剩余价值会越多。
limit_req(限制请求数)
对于限制请求数,下面给出一个Demo:
limit_req.lua的内容如下:
笔者使用如下命令进行测试:
结果是每秒的200的结果为20个。
limit_traffic
limit_traffic可以聚合上面多种请求限流策略,这里不再说明。后续会在OpenResty的专题单独说明。
分布式应用限流
分布式应用限流指的是,在应用服务器上面进行限流操作,如Tomcat等。分布式限流最关键的是要将限流服务做成原子化,而解决方案可以使使用redis+lua进行实现,在Java开发语言中,Jedis可以支持原子性的Lua脚本。下面介绍一下Redis+Lua的实现。
Redis+Lua的实现
Lua脚本
Java调用代码如下:
因为Redis的限制(Lua中有写操作不能使用带随机性质的读操作,如TIME)不能在Redis Lua中使用TIME获取时间戳,因此只好从应用获取然后传入,在某些极端情况下(机器时钟不准的情况下),限流会存在一些小问题。
参考:《亿级流量网站架构核心技术》、https://github.com/openresty/lua-resty-limit-traffic