一、背景
4月18日的訪問高峰扛過去之后，我們和阿里雲一直在努力尋找問題的真正原因。是問題，躲不去的，不找到根源，隨時會突然襲擊。
壓力測試未能重現問題，只能進行大海撈針般的猜測：SLB（均衡均衡）、Web服務器（虛擬機）、應用程序、緩存服務器（虛擬機）、SLB與Web服務器之間的網絡通信，Web服務器與緩存服務器之間的網絡通信、Web服務器與RDS（關系型數據庫服務）之間的網絡通信？
我們懷疑的對象是：SLB（請求分配有問題）、SLB與Web服務器之間的網絡通信（TCP連接）、VM與RDS之間的網絡通信（TCP連接）。
阿里雲懷疑的對象是：我們的應用程序、緩存服務器。
對於我們懷疑的對象，我們沒有任何偵測手段，只能將我們的懷疑拋給阿里雲。
對於阿里雲懷疑的對象，我們一萬個不認同應用程序會引起這個問題（應用程序的問題不會引起SLB中的所有Web服務器同時出問題）。對於緩存服務器，存在可能，但我們沒有特別重視。因為在之前出問題期間，緩存的命中率在正常范圍，即使緩存服務器down掉，也會直接走RDS，訪問速度也不會有大的影響。我們有兩種類型的緩存服務器memcached與NoSQL，都用的是couchbase。阿里雲建議我們memcached與NoSQL都進行負載均衡，昨天我們只對NoSQL進行了負載均衡（負載比較高）。並將memcached與NoSQL客戶端的連接超時設置修改為1秒，也就是說只要緩存服務器有問題，1秒鍾連接超時后就會直接走RDS從數據庫中獲取數據。具體設置如下：
<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。
二、故障經過
上午出現了波動情況，見下圖（負載均衡中波動最嚴重的一台）
（紅色曲線是博客IIS站點的Current Connections，綠色曲線是ASP.NET的Reqeust Execution Time）
下午2點開始，故障開始全面爆發，Windows性能監視器中的表現是Current Connections急劇增加、Reqeust Execution Time嚴重變慢、Requests/s大大減小。
當時采取的解決方法是向負載均衡中增加雲服務器，如果加雲服務器能解決問題，那就說明是雲服務器的負載能力問題。但是加了后發現，剛加之后有些緩解，但很快就故障如初。
后來采取限制每台雲服務器的IIS的並發連接數緩解故障的影響面。如果不限制，大家都無法正常訪問；限制之后，未被拒絕的請求的訪問速度會好些，但被拒絕的請求會出現503錯誤。在正常期間，來自SLB的並發連接在100以內，但故障期間並發連接在1000之上（因為很多請求得不到正常響應，連接越積越多），我們將IIS的最大連接限制在500才緩解了故障。
但后來即使Current Connections在200多，訪問速度也很慢。我們繼續加雲服務器，有1台雲服務器一上去，500的連接限制立即跑滿。我們當時還以為是SLB分配請求有問題，實際是SLB給雲服務器的請求得不到響應，像堵車一樣堵在那，越堵越多。
期間，阿里雲技術人員發現memcached那台雲服務器磁盤IO高（這也是奇怪情況，memcached只在內存中進行緩存），問題可能與memcached服務器有關，但從couchbase控制台看memcached的緩存命中率正常。我們在一台Web服務器上試了不走memcached，但從測試情況看，那台服務器的響應速度還是慢（可能當時是因為很多請求繼續在那堵着）。
后來，阿里雲技術人員發現memcached那台雲服務器內網接口流量波動很大（這個監視數據我們看不到）。
於是，我們想到重啟memcached服務器（操作系統是CentOS 6.2 64位）試試。結果reboot命令發出不久（17:00左右），故障竟然消失了，Current Connections立即下降，打開網站速度飛快（在memcached服務器重啟階段，memcached客戶端連接超時，程序會直接從數據庫取數據）。等memcached服務器啟動好之后，故障又立即出現。
於是，我們關閉那台memcached服務器，故障又立即消失。然后重新購買了一台雲服務器，操作系統是CentOS 6.3 64位，安裝同樣版本的couchbase，切換上去，故障沒有出現。網站就這么恢復了正常。晚上我們又加了一台memcached服務器，用2台組建了負載均衡。
忙完之后，就寫了這篇博客。
我們已經無顏向大家道歉了，我們只有一個選擇：全力以赴徹底解決這個問題，戰勝困難，度過難關！
故障原因分析見：雲計算之路-柳暗花明：為什么memcached會堵車