一、背景

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

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

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

阿里云懷疑的對(duì)象是：我們的應(yīng)用程序、緩存服務(wù)器。

對(duì)于我們懷疑的對(duì)象，我們沒(méi)有任何偵測(cè)手段，只能將我們的懷疑拋給阿里云。

對(duì)于阿里云懷疑的對(duì)象，我們一萬(wàn)個(gè)不認(rèn)同應(yīng)用程序會(huì)引起這個(gè)問(wèn)題（應(yīng)用程序的問(wèn)題不會(huì)引起SLB中的所有Web服務(wù)器同時(shí)出問(wèn)題）。對(duì)于緩存服務(wù)器，存在可能，但我們沒(méi)有特別重視。因?yàn)樵谥俺鰡?wèn)題期間，緩存的命中率在正常范圍，即使緩存服務(wù)器down掉，也會(huì)直接走RDS，訪問(wèn)速度也不會(huì)有大的影響。我們有兩種類型的緩存服務(wù)器memcached與NoSQL，都用的是couchbase。阿里云建議我們memcached與NoSQL都進(jìn)行負(fù)載均衡，昨天我們只對(duì)NoSQL進(jìn)行了負(fù)載均衡（負(fù)載比較高）。并將memcached與NoSQL客戶端的連接超時(shí)設(shè)置修改為1秒，也就是說(shuō)只要緩存服務(wù)器有問(wèn)題，1秒鐘連接超時(shí)后就會(huì)直接走RDS從數(shù)據(jù)庫(kù)中獲取數(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>

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

二、故障經(jīng)過(guò)

上午出現(xiàn)了波動(dòng)情況，見(jiàn)下圖（負(fù)載均衡中波動(dòng)最嚴(yán)重的一臺(tái)）

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

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

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

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

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

期間，阿里云技術(shù)人員發(fā)現(xiàn)memcached那臺(tái)云服務(wù)器磁盤(pán)IO高（這也是奇怪情況，memcached只在內(nèi)存中進(jìn)行緩存），問(wèn)題可能與memcached服務(wù)器有關(guān)，但從couchbase控制臺(tái)看memcached的緩存命中率正常。我們?cè)谝慌_(tái)Web服務(wù)器上試了不走memcached，但從測(cè)試情況看，那臺(tái)服務(wù)器的響應(yīng)速度還是慢（可能當(dāng)時(shí)是因?yàn)楹芏嗾?qǐng)求繼續(xù)在那堵著）。

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

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

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

忙完之后，就寫(xiě)了這篇博客。

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

故障原因分析見(jiàn)：云計(jì)算之路-柳暗花明：為什么memcached會(huì)堵車(chē)

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

總結(jié)

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

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