2013年黑色圣诞节 - 晚上故障的情况和反思

访问量: 698

一个教训。

感谢志权的理解。

志权:

    很抱歉, 今天晚上故障是由CMS的“客户端子系统”引起的。

    最初的原因是 我和cj在 5:12 做了 “客户端”子系统的部署。  5:20 发 
现有问题。 5: 40查到了原因并且重启生效。但是这个时候服务器已经恢复不过来 
了(无线API获取的请求结果都是499错误)。然后 6:02 做了回滚。可是基本没有 
效果。(很小部分设备有内容)
    后来无线API 使用了 静态的json 文件,不把请求发给CMS, 问题很快得到 
解决了。 7点左右恢复了正常。

    原因:因为CMS 的“开关接口” 大约有40分钟的时间出错,没有返回数据给无 
线API,而这个接口是客户端打开时所必须访问的接口,所以无线API 的缓存一旦 
过期, 就会有超过平时的很大数量的请求发给CMS。

    经过分析日志,发现17:00 ~ 18:00 之间的服务器负载情况是:
1. 缓存app 的请求数是 每秒 1000个。
2. 应用app 的请求数是 每秒 200 个,    (达到了 目前CMS 处理的峰值,平时最 
忙时段的访问量 平均每秒50个)

   所以 大约有80%的请求会被忽略,而剩下的20%的请求 也是响应的比较慢。

   后来经过对无线API 访问CMS的”限流“, 问题得到了解决。 7点左右恢复了正常。

   反思:  这个情况的原因是:
1. 代码质量问题。这个BUG 在小数据量的访问下没有表现出来,但是上线了后果 
很严重。
2. CMS 的服务器承受能力不强。 峰值是200个请求每秒。 面对海量请求无法很快 
的处理。

   我会尽快解决这次暴露的问题。

   再次致歉!

订阅/RSS Feed

Subscribe

分类/category