真沒想到雲計算之路上的天氣如此糟糕，比杭州的交通還要糟糕；今天上海晴空萬里，希望從今天開始“雲”上的天氣也一直晴空萬里。
昨天發布了博文雲計算之路-柳暗花明：為什么memcached會堵車之后，去參加了阿里雲客戶交流會，哪知14:00左右會議剛開始，網站又出現訪問速度慢的問題。。。
立即采取前天的措施，關閉memcached服務器，立即恢復正常。。。但是，沒過多久問題又出現。。。
同樣的方法，為什么前天能解決問題而昨天不能？這里的不同之處是前天關閉memcached服務器之后，正在走出訪問高峰期，而昨天正在走入訪問高峰期。
那為什么關閉memcached服務器之后會立即恢復正常？我們的猜測是：在關閉memcached服務器之前，所有web服務器都與memcached服務器之間保持着很多TCP連接進行大量網絡通信，memcached服務器的網絡處理能力很可能是瓶頸。關閉memcached服務器之后，直接走數據庫（RDS），網絡瓶頸不存在了。
但是關閉memcached服務器之后，壓力會轉嫁給數據庫服務器與web服務器的CPU。數據庫服務器用的是RDS，剛剛的，這點轉嫁過來的壓力小case。怎么會轉嫁給CPU呢，因為memcached緩存的不是直接數據庫查詢結果，而是實體對象，這些實體對象不僅包含數據庫查詢結果，還包含對數據庫查詢結果的處理，比如一些正則表達式處理。而跑web服務器的雲服務器CPU一直是瓶頸，在出問題的期間都伴隨着CPU占用大、波動大，所以我們才用了4台4核做負載均衡。我們猜測關閉memcached服務器之后請求處理速度慢可能是CPU處理能力的原因。
於是，我們進行了這樣的假設：把雲服務器想像成一個黑盒子，黑盒包裝着印着“CPU占用不得高於某值，TCP連接數不得高於某值”。（注：這只是假設，不代表虛擬機有這樣的限制。這是一種解決問題的手段，做科學研究有時也會先提出假設再證明這個假設）
然后，我們的解決思路就圍繞這個假設展開——1. 如何提高單台web服務器的CPU處理能力/減少CPU處理壓力；2. 如何減少單台雲服務器的網絡連接負載（TCP連接數）？
解決方法一
之前，我們有個非常錯誤的想法——以為通過負載均衡（阿里雲SLB）可以減少單台web服務器的CPU處理壓力。所以也嘗試過在出問題時向負載均衡添加更多雲服務器，結果證明解決不了問題。
而事實可能是，對於瞬間的並發請求，SLB無用武之地。我們對SLB的工作方式是這樣猜測的：SLB只轉發請求，並不拆分請求。假如4台web服務器每台能支撐的並發請求數是500，SLB一次收到了800的並發請求，一股腦兒轉發給其中一台web服務器，這台web服務器趴下了（扛不住）；SLB下一次收到了1000的並發請求，一股腦兒轉發給另一台web服務器，那台也趴下了；接下來SLB收到了1200的並發請求，第3台web服務器也趴下了。如果把這4台web服務器合並為1台，能支撐的並發請求數是2000，就能輕松應對。
於是，我們把4台web服務器中的2台由4核4G升級為8核8G，把另外2台從SLB中摘掉。負載均衡由原來的4台4核4G變為2台8核8G。
解決方法二
在所有雲服務器（虛擬機）中，memcached服務器是網絡連接負載最高的，因為所有web服務器都與之通信。數據庫用的是RDS，是物理機，不在考慮范圍。
我們想到了一個終極方法，將couchbase直接安裝在兩台web服務器上，web服務器與memcached服務器之間通過127.0.0.1接口進行本地通信，通過couchbase的集群功能讓兩台memcached服務器的數據保持同步。
web.config中memcached客戶端配置變為這樣：
<enyim.com> <memcached protocol="Binary"> <servers> <add address="127.0.0.1" port="11211" /> </servers> <socketPool minPoolSize="10" maxPoolSize="300" connectionTimeout="00:00:01" deadTimeout="00:00:01" /> </memcached> </enyim.com>
以前我們自己托管服務器時，也是這樣部署的，單台8核8G既跑web又跑memcached。
這兩個方法是在今天早上睡醒后想到的，然后一躍而起，在早上8點之前完成了部署。
正因為有了這兩個解決措施，才敢展望：希望從今天開始烏雲變藍天！