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