最近javaeye发生一起小故障，是robbin自己说的：
XML/HTML代码
- @robbinfan: 昨晚JE所在机房切换电源关机导致网站无法访问。早上恢复后因为数据库和缓存服务器都被清空，巨大流量(QPS将近400，并发连接到1000)直接冲击导致web服务被阻塞，现在正在逐步恢复中。
在mikespook.com看到对待这个问题的分析时，突然想起桔子也遇到过类似的问题，所以把他们两个人的事情贴出来。
先上mikespook的：
XML/HTML代码
- 显然，这是一次运维事故。事故的原因是分流作用的数据库和缓存出现“故障”，导致数据层响应延迟，web 服务器阻塞。这里我没有用“清空”而是用了“故障”来描述分流数据库和缓存，是因为实质上 javaeye 的这次事故虽然是正常维护（电源切换）后发生的，但是其表象跟分流数据库和缓存宕机是一样的。
- 这个故事给我的两个启示：
- 在架构设计上，对于分流数据库或者缓存或许应有一定的持久化能力。比如，在维护时，按照从“外”到“内”的顺序逐步关闭服务。在这个例子里，“外” 就是 web服务，“内”就是数据层。在关闭了“外”服务后，手工或自动将缓存持久化。维护完成，开启顺序从“内”到“外”，并在回复完底层存储后，将持久化数据恢复到缓存。
- 在运维规范上，在维护后应让系统进入一个的磨合期，在合理的时间内通过分流（比如跳转到一个“系统忙”的页面）或者防火墙封锁的方式。让系统保持在比正常负载低一些的水平。持续一段时间（或者维护后累计访问量达到某个值）后再让系统开足马力去运行。
- 这样，应该可以避免空缓存大并发导致的宕机事故。
- 再次感谢 robbin 和 javaeye 为我们带来的启示。
再上桔子的，汗，突然发现桔子的博客上居然没有写，看来是上次在群里看到了，大意如下：
XML/HTML代码
- 某次更新系统，然后需要重启，结果重启后CPU长时间处于100%（？还是死机了？），后来检查发现，原来故障是出在缓存上。
- 因为是采用文件缓存，而又设定了过期时间，重启后，所有的缓存都过期了。然后网站访问量又大，突然而来的访问导致缓存重新生成，差点让机器出故障。
- 所以现在开始要调整缓存架构。
所以，一个好的系统架构也是很需要的，不能因为一次宕机就永远起不来。我个人是偏向于队列生成缓存，这样就不用担心一次写入过多文件引起IO的崩溃。但队列是因为有延迟的，如果控制同样的内容不重复生成文件缓存，则需要另外考虑
#1