昨天的大瓜，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 補習課，掌握第一手資料！
如果本篇博客有任何錯誤，請批評指教，不勝感激 ！