采用Nginx的limit模块实现限流

先说一下背景，为什么要做限流？ 一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

也就是并发越高，系统的处理能力就会越低，TPS也就越低，这样对于用户体验来讲是十分不友好的，随着并发升高系统处理能力变低，响应时间变长，很多用户可能都处于空白页面的等待中，而且最崩溃的是等待很长时间之后，又超时了。

所以应对这种情况，我们需要评估出我们系统的一个最优处理能力(通过压测的手段，评估出多少并发量下的TPS是最高的)，然后根据最优处理能力来做适当的限流操作，那么我们的需求就是，保证我们的系统始终处于最优并发量的处理状态，进而保证最高的TPS，超过最优的状态的请求让他去排个队，等一会，超出队列长度就直接告诉他超时了！请稍后再试！

基于上面的需求我们可以借用Nginx的limit模块提供的能力

// 配置在http模块中
http{
        limit_req_zone all_request_limit_key zone=all_request_limit_config:10m rate=400r/s;
}

all_request_limit_key：可随便定义，也就是limit模块用这个key作为限流的依据，我这边是对全场景的请求统一做限流，如果要对不同的URl做限流可以配置多个limit_req_zone。
all_request_limit_config：可随便定义，也就是这个limit模块的变量名，使用的时候，他唯一标识一个配置
10m：limit模块在做限流时也肯定也要存储key之类的做统计，这边是设置这个占用的区域大小
rate=400r/s：表示每秒能放400个请求进来，也就是每2.5ms放过一个请求

// 配置在location模块中
location / {
        limit_req zone=all_request_limit burst=2000;
        proxy_pass http://api.xxxxx.cn;
        proxy_set_header   Host             $http_host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout invalid_header http_502 http_504;
}

burst=2000：表示队列长度是2000，每个请求进来都在队列里排着，按照2.5ms每个的速度消耗着，队列如果是满了的状态，那么后面的请求都会直接拒绝返回503，因为这个是配置在location中的，也如果要区分请求的优先级，比如有的请求特别重要无论如何都不用限流，那么就另外配置个location，写好需要限流的location的url的规则，然后配上限流，或者不同的location的限流规则不同都可以实现。

那么我们来分析下上面的这套限流配置效果是什么，由于配置了rate=400r/s，所以也就是说每2.5ms放一个请求到应用也就是到我们的tomcat，那么如果同时，注意这里是同时！，也就是同一毫秒有3000个人过来，那么在2.5ms内，会有1个请求被转发到了tomcat，然后有2000个请求在队列中等待被转发，有999个请求直接返回503。

队列中的2000个请求会以400/s的速度被消耗，也就是5s后全部处理完毕，也就是按照这个配置，如果队列排在最后的那个人也就是第2000的那个人，他的请求响应时间应该等于5s+tomcat处理请求的时间。

这样我们就达到了一个限流的目的，能够保证我的系统时刻都处在最优的处理性能。

可能有的同学不理解为什么并发量高的情况下TPS(每秒请求响应数量)就会下降，这里解释一下，举个例子，你的团队在做一个项目的时候，你作为负责人，可能需要负责，需求分析、功能设计、任务拆分、任务分配，任务验收等，然后会有一群人帮你实施具体的工作，他们做的事情是并行去做的，但是如果同时并发的人特别多，你又吃不消一个人的精力是有限的，你不能同时管理几百个人，即使有人帮你分担也总会达到一个极限，无法无限的并行下去，因此当到达极限后，如果还要继续并发，那么你的处理能力一定会下降，甚至可能累瘫，也就是所谓的宕机了。

这也是为什么我们说项目工期紧情况下我们不会疯狂铺人的原因，因为铺的人太多，额外增加了很多管理成本和各个成员之间的沟通协调成本，反而有可能会入不敷出。

这里采用Nginx做限流只是一种方式，也可以通过购买WAF(防火墙)，CDN等这类服务，也会提供一些限流的能力。

另外这边也稍微讲一下，limit模块还有另一个配置属性，这个大家可以跟进自己的需求场景评估是否要使用。

location / {
        limit_req zone=all_request_limit burst=2000 nodelay;
        proxy_pass http://api.xxxxx.cn;
        proxy_set_header   Host             $http_host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout invalid_header http_502 http_504;
}

可以看到这端配置中limit_req的配置后面多了一个nodelay，那么这个参数时什么意思呢？

nodelay：高并发场景应用，会将队列中的请求全部转发到应用，但并不释放队列，也就是此刻队列还是满的，新的请求过来是直接拒绝的，然后会按照（rate=400r/s）也就是2.5ms每个的速度逐渐释放队列空间，放后面的请求进来。

加不加这个参数的效果就是，“同时” 一堆请求过来如果不加这个参数，这些请求都在队列里排着以2.5ms的速度消耗，也就是第2000个人的响应时间一定是5s+tomcat处理请求的时间，而加了nodelay的话第2000个人的响应时间跟第一个人的响应时间都是tomcat的真实响应时间，因为，他们会被同时转发到tomcat，不会等待，只是后面队列释放时时按照2.5ms的速度来释放的。