手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表Tag:故障

例行维护后引起的故障和桔子的缓存故障

最近javaeye发生一起小故障,是robbin自己说的:

XML/HTML代码
  1. @robbinfan: 昨晚JE所在机房切换电源关机导致网站无法访问。早上恢复后因为数据库和缓存服务器都被清空,巨大流量(QPS将近400,并发连接到1000)直接冲击导致web服务被阻塞,现在正在逐步恢复中。

在mikespook.com看到对待这个问题的分析时,突然想起桔子也遇到过类似的问题,所以把他们两个人的事情贴出来。

先上mikespook的:

XML/HTML代码
  1. 显然,这是一次运维事故。事故的原因是分流作用的数据库和缓存出现“故障”,导致数据层响应延迟,web 服务器阻塞。这里我没有用“清空”而是用了“故障”来描述分流数据库和缓存,是因为实质上 javaeye 的这次事故虽然是正常维护(电源切换)后发生的,但是其表象跟分流数据库和缓存宕机是一样的。  
  2.   
  3. 这个故事给我的两个启示:  
  4.   
  5. 在架构设计上,对于分流数据库或者缓存或许应有一定的持久化能力。比如,在维护时,按照从“外”到“内”的顺序逐步关闭服务。在这个例子里,“外” 就是 web服务,“内”就是数据层。在关闭了“外”服务后,手工或自动将缓存持久化。维护完成,开启顺序从“内”到“外”,并在回复完底层存储后,将持久化数据恢复到缓存。  
  6.   
  7. 在运维规范上,在维护后应让系统进入一个的磨合期,在合理的时间内通过分流(比如跳转到一个“系统忙”的页面)或者防火墙封锁的方式。让系统保持在比正常负载低一些的水平。持续一段时间(或者维护后累计访问量达到某个值)后再让系统开足马力去运行。  
  8.   
  9. 这样,应该可以避免空缓存大并发导致的宕机事故。  
  10.   
  11. 再次感谢 robbin 和 javaeye 为我们带来的启示。  

再上桔子的,汗,突然发现桔子的博客上居然没有写,看来是上次在群里看到了,大意如下:

XML/HTML代码
  1. 某次更新系统,然后需要重启,结果重启后CPU长时间处于100%(?还是死机了?),后来检查发现,原来故障是出在缓存上。  
  2. 因为是采用文件缓存,而又设定了过期时间,重启后,所有的缓存都过期了。然后网站访问量又大,突然而来的访问导致缓存重新生成,差点让机器出故障。  
  3. 所以现在开始要调整缓存架构。  
其实上面两个问题都差不多。都是在访问大的时候,缓存频繁生成造成的故障,这确实不容忽略,但如何解决真的是一个问题。很多时候在访问量不大时,我们都考虑使用文件来作为缓存存储。但真正访问量高了后,文件缓存不可避免的就带来IO的消耗,如何批量生成缓存?还是按次生成缓存?还是定有一定的策略?难道还要采用队列?那就夸张了。

所以,一个好的系统架构也是很需要的,不能因为一次宕机就永远起不来。我个人是偏向于队列生成缓存,这样就不用担心一次写入过多文件引起IO的崩溃。但队列是因为有延迟的,如果控制同样的内容不重复生成文件缓存,则需要另外考虑

Tags: 故障, 缓存, 重启, 维护

下午突然不能访问

下午四五点钟的时候,网站突然不能访问,很紧张,呵呵,PING了一下网址,不通,再PING IP地址仍然不通,不知道怎么回事,可能是机房那边出了问题吧。
看来,我真的是得了那种精神病了,对于网络的故障明显比其他人紧张的多。
不过也难怪,毕竟是自己在做的网站,虽然仅仅是博客,但也是自己的一番心血,总归是显得比别人担心的。。。

晚上回到家访问一下,正常了。oh yeah,很开心啊

Tags: 访问, 故障, 网通