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

访问量: 2513

一个教训。

感谢志权的理解。

志权：

    很抱歉, 今天晚上故障是由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