背景：

某天公司突然發(fā)現(xiàn)整個網(wǎng)站訪問很慢，請求大部分報502，基本處于宕機狀態(tài)....時間大概持續(xù)一整晚,導致公司大量的投訴直接造成經(jīng)濟損失...

網(wǎng)站主要使用的技術棧：

nginx+php+mysql+redis

阿里云ecs

定位問題過程：

第一步就去查看mysql服務器狀況，是否有慢查詢導致，結果是mysql運行良好

第二步查看web服務器服務器情況，內(nèi)存使用偏高，但整體負載并沒有過紅線

第三步查看redis服務器，服務器負載“運行良好”(這里先打個引號后面詳細說明)

以上我把它稱為排查問題的前置3部曲，檢查問題的基本操作。

結果運維工程師告訴我3步完成后竟然一點問題都沒有,我當時就有點蒙....

開始檢查當天發(fā)布的代碼是否有可能出現(xiàn)問題，但當時思緒是沒有目標的，我們就像無頭蒼蠅一樣掃代碼(可想而知沒有大概的范圍是很難解決的，你得告訴開發(fā)工程師大概的方向才能定位問題)...

再次督促運維工程師繼續(xù)排查...

二次定位問題過程：

檢查nginx訪問日志，全是60秒超時，查看高峰日志最高約1800/秒左右，這時突然想到我們的php-fpm是靜態(tài)部署，每臺設置260左右的數(shù)量(也就是并發(fā)最多260個訪問左右)，我們有6臺web 也就是1560(260*6)左右

得出第一結論：我們的web服務器訪問數(shù)滿負荷了，吞吐量很低，也就是訪問要排隊了

第一結論的疑問1：為什么訪問接滿負荷web服務器負載沒有超紅線？

原因：260靜態(tài)常駐fpm是我們相對服務器內(nèi)存保守計算得出的值，這個值并沒有超載

第一結論的疑問2：為什么吞吐量很低呢，第一想到的是否mysql慢查詢問題(工程師最容易犯錯的地方)，但前面提到我們排查了mysql慢查詢并沒有，那是什么原因照成的呢？

這時運維同學發(fā)現(xiàn)新的問題，細化查詢服務器性能發(fā)現(xiàn)redis服務器單個cpu100%了，那之前為什么沒查出來服務器有問題呢？原來之前查看的是阿里云的監(jiān)控界面，該界面是根據(jù)平均負載來給出的實時分析，而這臺服務器是雙核服務器，平均一下是正常的....掉坑了！大家都知道redis是單核的，還有一個cpu是空閑的。

終于定位到問題”來源“了：redis服務器cpu100%。

我們緊接著查看redis的當前狀態(tài)，發(fā)現(xiàn)key的數(shù)量有500萬+，日常我們只有30W左右，雖然如此但是內(nèi)存其實并沒有超過境界線

引發(fā)了我們新的一輪思考，是什么引起cpu100%的？為什么內(nèi)存沒有超標而是cpu超了？

為了先快速解決當前的窘境我們決定先嘗試清空redis看是否能恢復網(wǎng)站(因為我們的業(yè)務代碼對redis并沒有很強的依賴)，畢竟快1分鐘解決就是少損失一分錢，運維執(zhí)行清空后，網(wǎng)站恢復了正常。

臨時解決方案：備份redis，清空redis(flushall)

雖然問題”解決“了，但是我們還沒有找到問題的根源，于是下定決心必須搞清楚，接下來就是探索和試驗，時間和篇幅長度問題準備再下一篇中具體說明。

redis服務器cpu100%的原因和解決方案