利用nginx做流量限制及集群部署

前段时间公司有个应用做什么营销活动，不知道咋回事，一个平常之后1-2万人在线的应用，突然来了10多万人，然后呢，系统就异常的慢，异常的慢，持续了很长时间，被客户投诉的很惨。就说负责该应用的项目组，几乎取消了当年的奖金。好惨。。。

于是乎，领导就以史为鉴，让我等研究下，怎么才能在这种异常的流量中保证应用不死，我第一个想到的就是，应用不可能突然多出来很多服务能力，那就只有把多出来的流量拦掉呗，应用本身的机制很难做到对整个集群的管理，只能借助Nginx了。

研究了一下nginx的功能，发现对流量的限制本身就是nginx的功能之一，然后动手测试了一下，果然是可行的。

下载一个nginx（不要问我在哪下。。。），然后打开他的配置文件。

#定义每个IP的session空间大小，只能用在http段
limit_conn_zone $binary_remote_addr zone=one:20m;

实际上它的语法是

limit_conn_zone key zone=name:size; 
#key => $binary_remote_addr #二进制的IP地址
#key可以说是一个规则，就是对客服端连接的一个标识，比如上面用的是IP地址
#zone主要用于保存每个key对应的连接数
#name => addr #随便取的一个名字，比如，你可以取成abc
#size => 20m #空间大小，这里是20兆，当这个定义的空间被耗尽的时候，nginx会返回503报错
#大家可以自己算一下，20m的空间可以保存多少个key

#与limit_conn_zone类似，定义每个允许发起的请求速率

 limit_req_zone $binary_remote_addr zone=req_one:20m rate=1r/s; 

#定义每个IP发起的并发连接数，为了测试方便可以先改为1

 limit_conn one 10;

#缓存还没来得及处理的请求，为了测试方便可以先改为1

 limit_req zone=req_one burst=100;

开启Nginx的限流功能，主要是通过前四个参数实现

http {
 limit_conn_zone $binary_remote_addr zone=one:20m;
 limit_req_zone $binary_remote_addr zone=req_one:20m rate=1r/s; 
 limit_conn one 1;
 limit_req zone=req_one burst=1;
 #rewrite_log on;
 #error_log /var/log/nginxrewrite.log notice;
 client_body_buffer_size 256M;
 include mime.types;
 default_type Application/octet-stream;
 log_format main '$remote_addr - $remote_user [$time_local] "$request" '
 '$status $body_bytes_sent "$http_referer" '
 '"$http_user_agent" "$http_x_forwarded_for" "$request_filename"';
 sendfile on;
 keepalive_timeout 65;
 include servers/*.conf;
}

做完这些，启动nginx，简单些一个http客户端来测试一下，如果同时发起两个请求。会提示503错误。

但是干完了这个，感觉单实例下的nginx总是不能让人安心的，即使nginx不会出现故障，也不能排除其所在的服务器不会出现故障吧。

所以准备研究一下nginx怎么集群部署，但是查阅相关资料显示nginx本身不具备集群功能，因为它本身就是为了给集群做负载均衡而实现的，真的要做，可以通过几种方式。

1、利用DNS服务器负载均衡策略。及所以通过一个域名过来的请求，会先到dns服务器，然后dns再通过轮训或者最小连接数等策略，分发至nginx服务器。这样理论上只需要一个公网dns，一个公网ip，nginx服务可以部署在内网ip上。

大概是这样吧

2、nginx+nginx。就是在前端部署一个nginx，在这个nginx上再负载均衡多个nginx，但是我严重怀疑这种方案的科学性，毕竟怎么保证最前面的nginx不死，又是一个问题。

感觉好傻

3、负载均衡硬件在前，nginx在后。这就是传统的负载均衡模式，通过F5的分发，减轻服务压力。

一般够用了

非常奇怪，为什么nginx为什么本身不具备集群功能，经查阅相关资料显示，单个nginx的负载在5w左右，这对于大部分应用应该是足够的，实在不行就在前面搭dns或者用F5，足以解决大部分问题，我司的核心应用并发也才达到10w级别。如果达到阿里巴巴那种程度的话，可以参考阿里的解决方案，前端在请求时，已经拿到了一个ip列表，从前端已经开始分发了，而不是全部送到后端再进行分发。

至此，这个问题应该可以向领导交差了。