【故障公告】訪問高峯數據庫服務器 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小時左右的故障給您帶來了很大的麻煩，請您諒解。