前段时间公司有个应用做什么营销活动，不知道咋回事，一个平常之后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列表，从前端已经开始分发了，而不是全部送到后端再进行分发。
