昨天的大瓜，B站蹦了，大夥都跳起來分析了一波異常原因，著實給大夥的秋招準備了一波熱乎乎的素材！在大家都在關注 B站的時候， 我大A站終於要站起來了！！！經過多方網友的極力引流，我A站也蹦了～
緊急通知： B站換域名了！！！
這裡簡單介紹一下 A 站發展史:
A站最初創立於2007年，是國內第一家彈幕視訊網站，而且也曾經輝煌過，事實上A站在2011年之前一直都壓制著B站，是當時國內最大的彈幕視訊網站。
2009 - 2016 混亂的資本和人事鬥爭成為A站發展道路上最大的阻礙，也最終讓A站逐漸走向衰落。
A站最初的“接盤俠”就是邊鋒網路，將“生放送”這塊業務從A站獨立了出來，成立了新的公司，也就是後來的鬥魚TV。
2018 被快手全資收購，苦苦經營。
A站蹦了
在廣大網友的引流下，A站 迎來了一波大流量,成功把服務打掛了。但是和B站 崩潰不一樣 ，大流量導致的雪崩，可以通過快速止血 ， 恢復服務，
A站崩潰分析
貼了那麼多的圖，下面進行一波理性分析：
- 崩潰恢復大概在一個小時（23:15-00:25） 左右
- 崩潰時
頁面顯示正常 - 恢復後，部分能力
熔斷
可以比較直觀的感受，A站蹦了的原因，就是由於大流量打蹦了服務，導致服務異常。
可惜了兄弟們的一波引流
CDN 蹦了
CDN 上快取的資源主要為： H5資源 和視訊. 在一開始的 A站，展示頁面是長這個樣子的：
可以看到， H5 頁面的靜態資源載入沒有問題， 資源還能夠訪問到，這時的 CDN 還是處於正常狀態, 到後面的，整個頁面都蹦了，這個時候 CDN 也被打掛了。
資料庫蹦了
資料庫蹦，是猜測的，大流量衝擊下，新使用者的登入，不同型別資料的訪問，導致快取命中率大大下降，請求直接打到資料庫上。 這裡就會出現雪崩的第一步： DB 處理超時
服務蹦了
上面提到了 資料庫超時 ,引起的服務雪崩。 是其中的一種可能，如果服務的瓶頸並不是 DB ,而是邏輯處理，資料傳輸等，佔用的是機器CPU，IO等資源，隨著流量劇增，導致機器負載過高，無法快速響應業務，也是導致服務雪崩的原因之。
這裡以 A站 的視訊流傳輸為例，OSS 響應緩慢，或者說傳輸頻寬受限，導致請求在視訊服務堆積，最終導致整個鏈路雪崩。 當然，其他鏈路也會有類似的可能。主要指標可以參考，CPU，記憶體和IO 的負載，介面響應耗時。
A站服務恢復
恢復效果差強人意，可以直接明瞭的感受到部分能力被熔斷了，保障基礎能力的提供.
為什麼我能那麼快恢復？
跟 B站 的服務崩潰不同（物理攻擊）， A站 受到的影響主要是由於流量過大，導致機器負載過高，引起的雪崩。目前大部分服務，都已經上雲了，好處就是，根據需求動態擴容（錢能解決的問題，都不是問題）。
1、動態擴容
通過監控可以很快定位到異常服務（負載過高）,通過定向擴容，可以減輕單機負載壓力，提升叢集處理能力。以剛才提到的視訊服務為例, 伺服器負載過高了，加機器！ OSS 頻寬打滿了, 充錢 ，闊大頻寬！
2、限流
處理動態擴容，為了避免服務再次被打掛，很有必要加上限流,高可用三劍客之一，可以通過 閘道器限流，伺服器限流，傳輸限速等多種渠道保障服務。像博主之前介紹到的 Sentinel 也提供,機器負載保護的能力，機器負載過高導致的雪崩。
3、熔斷
服務熔斷，是通過關閉部分能力，以保障整體鏈路的穩定性。下面圖中，推薦系統能力可能暫時沒回復，也可能是被熔斷了。
整體架構可以理解為：
A站獨家，五蕉必吃
好了各位，以上就是這篇文章的全部內容了，我後面會每週都更新幾篇高質量的大廠面試和常用技術棧相關的文章。感謝大夥能看到這裡，如果這個文章寫得還不錯， 求三連！！！ 創作不易，感謝各位的支援和認可，我們下篇文章見！
我是 九靈 ,有需要交流的童鞋可以 加我wx，Jayce-K,關注公眾號：Java 補習課，掌握第一手資料！
如果本篇部落格有任何錯誤，請批評指教，不勝感激 ！