阿里云的 OCS（ memcache）特别不靠谱

[iceiceberg]

以前就经常因为内网 DNS 问题超时。昨天晚上报了两个小时的 Malformed VALUE header (0)，导致我所有的服务都崩溃了。
提工单也是答搭不理，根本不解决问题。
原来我是自己搭的 memcached ，后来切成了 OCS 。现在看来，又得切回去了……大家慎用啊！

[realpg]

以前发生过这种事儿……后来都改自建了……
不过应该吐槽一下，你的程序竟然没有 cache server 崩溃的 failsafe 么？哪怕数据库直读呢

[ixiaozhi]

昨晚挂了啊，我都不知晓呢。。。

[nevernet]

1 楼说的是 failsafe

[Zhongwei]

1. 内网 DNS 的稳定性不能指望，必须上 dnsmasq
2. cache 的理解是否有问题

[beneo]

没事，会赔偿你 memcached 使用费用的 100 倍的，逃

[aliyun123]

抱歉给您带来不便，今天凌晨 OCS 进行升级，升级期间用户 OCS 已建立的连接会出现闪断，自动重连后即可恢复，具体可以参考:http://help.aliyun.com/noticelist/articleid/7596863.html?spm=5176.383338.12398792.3.5TnlH3,如果还有疑问可以在工单中反馈，会有人员及时跟进的。

[iceiceberg]

@beneo 不会的

[cnbiglee]

话说，我也在用，没有任何异常。
memcache 不是数据库，他崩溃了，最多是从数据库等处读取数据，服务慢点而已，怎么会崩溃？
只能说你的代码不够健壮。

[cloudbeyond]

欢迎来 AWS 的 Elasticache

[iceiceberg]

@cnbiglee 确实是……
我 mem 里的东西很多不是数据库的缓存，而是单独存在的。一般都是些不需要长期存的数据。

@realpg
@Zhongwei
我这种设计方式，是完全不可取的么？

[realpg]

@iceiceberg
看你们的可用性要求了……

反正总不能 cache 挂了就直接把乱七八糟的 error 抛给用户了……
我以前给人做东西时候，各种变态测试就是去把数据库内容删了啊，把 cache 弄坏啊什么的，就算没法正常提供数据，服务也不能崩，好歹给友好的错误提示给用户，有条件保证的数据还是要给出的。


从设计方式角度，首先 cache 里一般有这么几种数据：

后面有 backend 的，为了提升性能，这种 cache 的封装访问，一定是自带 cache 不在了，从 backend 读取重建 cache 。
这种基本逻辑就是，首先去 cache 里面 fetch ，如果 fetch 到 false ，那么去 backend 读，然后写 cache ，如果 cache server 不可用，那么记录 warning 给管理员，然后流程继续。

另外一种，纯热数据，属于可以清空不影响逻辑的，后面没有 backend ，比如一个实时热词排序这种，数据如果清空是不影响前台展示，只能导致具体不准确。这种 cache server 挂掉，基本就等于一个无数据的新系统，应该也不会功能错乱。

[fire5]

memcached redis 为什么不自己搭建？ 为什么不自己搭建？ 为什么不自己搭建？

[iceiceberg]

@fire5 最早是自己搭的，因为不能热升级，就改成用 OCS 了。。。

[Had]

@cloudbeyond AWS 的 Redis 升级也不是热升级...

[cnbiglee]

@iceiceberg 当数据不存在时能把服务搞崩了的数据当然不能只在缓存里存在，如果没办法在其它地方存在，那就要做好异常处理，数据不存在时有预备方案，比如友好提示等。

[iceiceberg]

@cnbiglee 明白！受教了！我马上改！