一、背景

4月18日的訪問高峰扛過去之后，我們和阿里云一直在努力尋找問題的真正原因。是問題，躲不去的，不找到根源，隨時會突然襲擊。

壓力測試未能重現(xiàn)問題，只能進行大海撈針般的猜測：SLB（均衡均衡）、Web服務器（虛擬機）、應用程序、緩存服務器（虛擬機）、SLB與Web服務器之間的網(wǎng)絡(luò)通信，Web服務器與緩存服務器之間的網(wǎng)絡(luò)通信、Web服務器與RDS（關(guān)系型數(shù)據(jù)庫服務）之間的網(wǎng)絡(luò)通信？

我們懷疑的對象是：SLB（請求分配有問題）、SLB與Web服務器之間的網(wǎng)絡(luò)通信（TCP連接）、VM與RDS之間的網(wǎng)絡(luò)通信（TCP連接）。

阿里云懷疑的對象是：我們的應用程序、緩存服務器。

對于我們懷疑的對象，我們沒有任何偵測手段，只能將我們的懷疑拋給阿里云。

對于阿里云懷疑的對象，我們一萬個不認同應用程序會引起這個問題（應用程序的問題不會引起SLB中的所有Web服務器同時出問題）。對于緩存服務器，存在可能，但我們沒有特別重視。因為在之前出問題期間，緩存的命中率在正常范圍，即使緩存服務器down掉，也會直接走RDS，訪問速度也不會有大的影響。我們有兩種類型的緩存服務器memcached與NoSQL，都用的是couchbase。阿里云建議我們memcached與NoSQL都進行負載均衡，昨天我們只對NoSQL進行了負載均衡（負載比較高）。并將memcached與NoSQL客戶端的連接超時設(shè)置修改為1秒，也就是說只要緩存服務器有問題，1秒鐘連接超時后就會直接走RDS從數(shù)據(jù)庫中獲取數(shù)據(jù)。具體設(shè)置如下：

<couchbase><servers bucket="default"><add uri="http://ip1:8091/pools" /><add uri="http://ip2:8091/pools" /> </servers><socketPool minPoolSize="20" maxPoolSize="200" connectionTimeout="00:00:01" deadTimeout="00:00:02" /> </couchbase> <enyim.com><memcached protocol="Binary"><servers><add address="ip1" port="11211" /> </servers><socketPool minPoolSize="20" maxPoolSize="200" connectionTimeout="00:00:01" deadTimeout="00:00:02" /></memcached> </enyim.com>

今天出故障之前，服務器的部署情況是：SLB+4臺Web服務器+1臺Memcached服務器+2臺NoSQL服務器+RDS。

二、故障經(jīng)過

上午出現(xiàn)了波動情況，見下圖（負載均衡中波動最嚴重的一臺）

（紅色曲線是博客IIS站點的Current Connections，綠色曲線是ASP.NET的Reqeust Execution Time）

下午2點開始，故障開始全面爆發(fā)，Windows性能監(jiān)視器中的表現(xiàn)是Current Connections急劇增加、Reqeust Execution Time嚴重變慢、Requests/s大大減小。

當時采取的解決方法是向負載均衡中增加云服務器，如果加云服務器能解決問題，那就說明是云服務器的負載能力問題。但是加了后發(fā)現(xiàn)，剛加之后有些緩解，但很快就故障如初。

后來采取限制每臺云服務器的IIS的并發(fā)連接數(shù)緩解故障的影響面。如果不限制，大家都無法正常訪問；限制之后，未被拒絕的請求的訪問速度會好些，但被拒絕的請求會出現(xiàn)503錯誤。在正常期間，來自SLB的并發(fā)連接在100以內(nèi)，但故障期間并發(fā)連接在1000之上（因為很多請求得不到正常響應，連接越積越多），我們將IIS的最大連接限制在500才緩解了故障。

但后來即使Current Connections在200多，訪問速度也很慢。我們繼續(xù)加云服務器，有1臺云服務器一上去，500的連接限制立即跑滿。我們當時還以為是SLB分配請求有問題，實際是SLB給云服務器的請求得不到響應，像堵車一樣堵在那，越堵越多。

期間，阿里云技術(shù)人員發(fā)現(xiàn)memcached那臺云服務器磁盤IO高（這也是奇怪情況，memcached只在內(nèi)存中進行緩存），問題可能與memcached服務器有關(guān)，但從couchbase控制臺看memcached的緩存命中率正常。我們在一臺Web服務器上試了不走memcached，但從測試情況看，那臺服務器的響應速度還是慢（可能當時是因為很多請求繼續(xù)在那堵著）。

后來，阿里云技術(shù)人員發(fā)現(xiàn)memcached那臺云服務器內(nèi)網(wǎng)接口流量波動很大（這個監(jiān)視數(shù)據(jù)我們看不到）。

于是，我們想到重啟memcached服務器（操作系統(tǒng)是CentOS 6.2 64位）試試。結(jié)果reboot命令發(fā)出不久（17:00左右），故障竟然消失了，Current Connections立即下降，打開網(wǎng)站速度飛快（在memcached服務器重啟階段，memcached客戶端連接超時，程序會直接從數(shù)據(jù)庫取數(shù)據(jù)）。等memcached服務器啟動好之后，故障又立即出現(xiàn)。

于是，我們關(guān)閉那臺memcached服務器，故障又立即消失。然后重新購買了一臺云服務器，操作系統(tǒng)是CentOS 6.3 64位，安裝同樣版本的couchbase，切換上去，故障沒有出現(xiàn)。網(wǎng)站就這么恢復了正常。晚上我們又加了一臺memcached服務器，用2臺組建了負載均衡。

忙完之后，就寫了這篇博客。

我們已經(jīng)無顏向大家道歉了，我們只有一個選擇：全力以赴徹底解決這個問題，戰(zhàn)勝困難，度過難關(guān)！

故障原因分析見：云計算之路-柳暗花明：為什么memcached會堵車

轉(zhuǎn)載于:https://www.cnblogs.com/cmt/archive/2013/04/24/3041368.html

總結(jié)

以上是生活随笔為你收集整理的云计算之路-黎明前的黑暗：20130424网站故障经过的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。