当今天早上在日志中发现这样的错误之后，对阿里云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. 每次升级都要出点问题：断连接，缓存过期时间丢失，连黑色n秒问题都是在某次OCS升级后出现的。。。这次升级后，又出现了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是因为慢工出细活，现在却成了泡影。