【故障公告】访问高峰数据库服务器 CPU 100% 引起全站故障

今天上午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小时左右的故障给您带来了很大的麻烦，请您谅解。