服務器維護中處理高併發致使的一些常見問題解決方案

　　這裏仍是按照場景來吧，畢竟場景是最能體驗實用性的。首先說下服務器配置以及環境

　　阿里雲ECS雲主機，8G內存，4核的CPU，20M帶寬，20G系統盤+200G數據盤，CentOS6.564位，安裝的一件集成lnmp環境

　　場景：微信發紅包

　　這個場景是很常見的，通常客戶會在整點的時候進行一次微信公衆號的廣告推送，這兒時候服務器的併發大概在3000到5000左右。提及來這其實並不算是高併發，可是服務器仍是崩了，大概須要等待5分鐘以後才能恢復正常。這有點不該該啊，分析緣由。查看CPU的利用率並不高，內存使用也很正常，在阿里雲控制面板裏面查看網絡出口流量滿載，問題大概是清楚了，網絡緣由致使。

　　首先查看靜態資源，發現圖片大部分沒有優化，因而脫下來進行無損壓縮，大概省略了1M左右的大小，提交上去後依然崩潰，服務器頻繁出現502。

　　再次檢查頁面的靜態資源css和js，把經常使用的js庫替換成CDN以減小請求數，提交後依然沒有多少變化，502依舊。

　　因而查看nginx鏈接數，使用命令

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

結果顯示

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

　　乖乖，TIME_WAITE很高，這裏務必說下TIME_WAITE的含義：TIME_WAIT：另外一邊已初始化一個釋放。這個是啥意思呢？意思就是服務器已經主動關閉了，在等待客戶端給一個迴應，若是客戶端一直沒有迴應就會出現等待，這個值就會增長。很顯然，這個時候咱們須要減小TIME_WAIT的值。

　　這裏只須要修改sysctl.conf的一些參數便可，編輯/etc/sysctl.conf文件，檢查

      是不是這樣的設置，若是找不到對應的，在文件最後加上便可。保存後執行

/sbin/sysctl -p

配置便可生效。

20分鐘後繼續查看nginx鏈接數，結果

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

恢復正常，網絡帶寬也降下來了。

可是好景不長，第二次整點開始搶紅包的時候又出現了502。查看進程發現mysqld的CPU佔用率很高，致使CPU滿載，服務器崩潰。修改mysql配置文件，調整max_connection爲30000。其餘相關參數進行了調整優化，狀況有所緩解，可是短短几分鐘以內CPU又滿載了。

詭異！因而查看mysql中的進程，發現頻繁的sql查詢，而所查詢的幾個表數據量均在10萬左右，判斷是由於沒有設置索引致使。諮詢後端開發，果真是隻設置了主鍵。馬上修改，提交上去五分鐘後CPU降下來，穩定在10%左右，也沒有出現過502了。