前段時間公司有個應用做什么營銷活動，不知道咋回事，一個平常之后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列表，從前端已經開始分發了，而不是全部送到后端再進行分發。
至此，這個問題應該可以向領導交差了。
