今天上午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小時左右的故障給您帶來了很大的麻煩，請您諒解。