今天上午11:10,我们又中“奖”了,我们使用的阿里云 RDS 实例(SQL Server 2016 标准版,16核32G)突发出现 CPU 100%,引发全站故障,直到 12:15 才完全恢复,由此给您带来很大的麻烦,请您谅解。

这是我们今年的第3次中“奖”,前2次分别发生在 2020-06-24 3:20~8:30 (详见故障公告)与 2020-08-20 20:55~21:14(详见故障公告)。

相比前2次,这次中了一个大“奖”,发生在访问高峰中的高峰,高峰时期DB宕机如山倒,即使数据库服务器后来恢复也无济于事,只能苦等高峰过去。

这次故障,我们快速发现,快速定位,快速采取最有效的措施(主备切换),但是在大“奖”之下,我们回天无力。

11:10 发生故障,11:11 发现故障,11:14 进行主备切换

和以往一样,第1次切换总是失败,11:21 进行第2次主备切换

11:22 主备切换成功,CPU 立马降了下来

此时如释重负,坐等园子重归风平浪静,博客之外的应用的确恢复了平静,但并发量最大的博客站点依然访问缓慢,我们使劲九牛二虎之力也无法让其恢复,一直等到午饭时间访问高峰过去,才自然恢复。

再一次“领略”了高并发下的雪崩效应,数据库服务器宕机超过一定时间,大量热点缓存失效,即使后来数据库恢复,巨量请求涌向数据库,大量 SQL 执行超时,缓存服务器面临巨大写入数据压力,写缓存又会占用更长时间的 tcp 连接,大量缓存无法有效建立导致并发请求持续不断地涌向数据库。

(memcached 服务器 tcp 连接监控)

再一次为代码功力不过硬付出了代价,由于我们没有在代码中采取限流措施,造成系统无法应对这种不堪重负的异常情况。

我们会吸引教训,努力改造博客系统,提高系统对高并发的应对能力,不能给 .NET 社区丢脸。

非常抱歉!这次长达1小时左右的故障给您带来了很大的麻烦,请您谅解。

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/cmt/p/13919666.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!