這里還是按照?qǐng)鼍皝?lái)吧，畢竟場(chǎng)景是最能體驗(yàn)實(shí)用性的。首先說(shuō)下服務(wù)器配置以及環(huán)境

阿里云ECS云主機(jī)，8G內(nèi)存，4核的CPU，20M帶寬，20G系統(tǒng)盤+200G數(shù)據(jù)盤，CentOS 6.5 64位，安裝的一件集成lnmp環(huán)境

場(chǎng)景：微信發(fā)紅包

這個(gè)場(chǎng)景是很常見(jiàn)的，一般客戶會(huì)在整點(diǎn)的時(shí)候進(jìn)行一次微信公眾號(hào)的廣告推送，這兒時(shí)候服務(wù)器的并發(fā)大概在3000到5000左右。說(shuō)起來(lái)這其實(shí)并不算是高并發(fā)，但是服務(wù)器還是崩了，大概需要等待5分鐘之后才能恢復(fù)正常。這有點(diǎn)不應(yīng)該啊，分析原因。查看CPU的利用率并不高，內(nèi)存使用也很正常，在阿里云控制面板里面查看網(wǎng)絡(luò)出口流量滿載，問(wèn)題大概是清楚了，網(wǎng)絡(luò)原因?qū)е隆?/p>

首先查看靜態(tài)資源，發(fā)現(xiàn)圖片大部分沒(méi)有優(yōu)化，于是脫下來(lái)進(jìn)行無(wú)損壓縮，大概省略了1M左右的大小，提交上去后依然崩潰，服務(wù)器頻繁出現(xiàn)502。

再次檢查頁(yè)面的靜態(tài)資源css和js，把常用的js庫(kù)替換成CDN以減少請(qǐng)求數(shù)，提交后依然沒(méi)有多少變化，502依舊。

于是查看nginx連接數(shù)，使用命令

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

結(jié)果顯示

TIME_WAIT 3828
SYN_SENT 1
FIN_WAIT1 107
FIN_WAIT2 27
ESTABLISHED 661
SYN_RECV 23
CLOSING 15
LAST_ACK 284

乖乖，TIME_WAITE很高，這里務(wù)必說(shuō)下TIME_WAITE的含義：TIME_WAIT：另一邊已初始化一個(gè)釋放。這個(gè)是啥意思呢？意思就是服務(wù)器已經(jīng)主動(dòng)關(guān)閉了，在等待客戶端給一個(gè)回應(yīng)，如果客戶端一直沒(méi)有回應(yīng)就會(huì)出現(xiàn)等待，這個(gè)值就會(huì)增加。很顯然，這個(gè)時(shí)候我們需要減少TIME_WAIT的值。

這里只需要修改sysctl.conf的一些參數(shù)即可，編輯/etc/sysctl.conf文件，檢查

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse=1 #讓TIME_WAIT狀態(tài)可以重用，這樣即使TIME_WAIT占滿了所有端口，也不會(huì)拒絕新的請(qǐng)求造成障礙 默認(rèn)是0
net.ipv4.tcp_tw_recycle=1 #讓TIME_WAIT盡快回收 默認(rèn)0
net.ipv4.tcp_fin_timeout=30

是否是這樣的設(shè)置，如果找不到對(duì)應(yīng)的，在文件最后加上即可。保存后執(zhí)行

/sbin/sysctl -p

配置即可生效。

20分鐘后繼續(xù)查看nginx連接數(shù)，結(jié)果

TIME_WAIT 87
SYN_SENT 1
FIN_WAIT1 60
FIN_WAIT2 19
ESTABLISHED 477
SYN_RECV 12
CLOSING 2
LAST_ACK 100

恢復(fù)正常，網(wǎng)絡(luò)帶寬也降下來(lái)了。

但是好景不長(zhǎng)，第二次整點(diǎn)開始搶紅包的時(shí)候又出現(xiàn)了502。查看進(jìn)程發(fā)現(xiàn)mysqld的CPU占用率很高，導(dǎo)致CPU滿載，服務(wù)器崩潰。修改mysql配置文件，調(diào)整max_connection為30000。其他相關(guān)參數(shù)進(jìn)行了調(diào)整優(yōu)化，情況有所緩解，但是短短幾分鐘之內(nèi)CPU又滿載了。