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