當今天早上在日志中發現這樣的錯誤之后，對阿里雲OCS（mecached緩存服務）的積怨傾瀉而出。
2014-06-08 07:15:56,078 [ERROR] Enyim.Caching.Memcached.MemcachedNode System.IO.IOException: Failed to write to the socket '10.160.124.220:11211'. Error: ConnectionReset
這個問題我們4月份發現過，當時給OCS起了個外號叫“會斷連接的memcached”，用了近1個月時間才解決。這次升級后又出現了，雖然不是故意為之，但是如果是淘寶用的memcached，你們敢斷連接嗎？雖然這個問題后來說徹底解決了，以后不會再出現了，但是無法平息我們對OCS的不滿。
細數一下OCS的罪狀：
1. 每次升級都要出點問題：斷連接，緩存過期時間丟失。。。這次升級后，又出現了socket讀取緩存數據有時超過500ms的情況。
2. 單條緩存數據最大限制不是memcached標准的1M，而是1000000字節（比1M少了48576個字節），超過這個限制的內容沒有提供緩存解決方案。
3. 緩存數據不支持壓縮，而且竟然按緩存容量收費（后來我們自己在代碼中壓縮后再寫入OCS，容量省了一半）。
4. 在我們網站的訪問高峰與低峰，緩存容量相差幾倍，可是OCS只能按固定容量購買，結果只好按最高峰的容量購買（最容易實現彈性計算的卻彈不起來）。
5. 20G容量的OCS一個月要1100多元，而8核CPU/32G內存的雲服務器一個月也不過1400多元，性價比一點不高。
6. 沒有命令行接口（telnet不讓連），查看/刪除緩存都得要自己寫代碼操作。
細數之后，我們的怨氣沒了——這么多問題，我們還用它干嗎？自己用ECS（雲服務器）跑memcached也比這靠譜啊。
於是立即動手，買了2台8核16G的ECS。1台用Couchbase跑memcached，緩存除博文內容的數據（單條數據不會超過1M）；1台用Couchbase跑NoSQL，緩存博文內容，超過1M的內容也能緩存（用OCS時，只能用數據庫硬扛）。
部署好之后感覺良好，的確比OCS更靠譜，就連監控也比OCS方便多了。
memcached監控圖：
NoSQL監控圖：
telnet連上去，可以通過命令自如地進行操作。
當初對OCS的美好期待——以為推出比較晚的OCS是因為慢工出細活，現在卻成了泡影。
【更新】
后來，OCS進行了改進。7月9日開始，我們將memcached服務切換回了OCS。