B 站崩了，受害程序員聊聊

非吃瓜，B 站事件始末分析 + 防治技術分享

你們好，我是魚皮，昨天小破站崩了的事情相信不少朋友都據說了。

這要是擱之前，不愛吃瓜的我根本不會去關注這種事，崩了就崩了唄，反正天塌下來有程序員大佬們扛着，很快就會好的。

但此次不太同樣，由於我本身也成爲了本事件的 「受害者」 ！

因此今天以一名程序員的視角，帶你們回顧 B 站崩了事件的始末、理性推測緣由、並分享一些防治技術和收穫感悟。

事件始末

B 站剛剛崩，但尚未徹底崩的時候，我正在直播間寫小代碼、和小夥伴們友好交流。因爲我在寫代碼的時候不會常常看彈幕，沒有注意到彈幕不動了，沒有任何小夥伴發彈幕。

起初我覺得只是本身寫代碼太無聊了，沒人搭理我。而後我就擱哪兒喃喃自語：奇怪了，怎麼沒有小夥伴發彈幕？喂，有人麼？Hello？Hi？歪比八步？

後來我才發現，彈幕區連進房提示都沒了，總不可能幾分鐘沒人進來吧？確定是出事了！

我覺得是彈幕卡了，因而就關閉彈幕再打開，結果仍是同樣。而後我就想着重啓下直播，結果關掉以後再也打不開了，屏幕上直接提示：彷佛已斷開和服務器的連接。

實話說，在此以前，我根本沒想到 B 站這種億級流量的平臺會崩掉。因此第一反應和你們同樣，都懷疑是本身網絡的問題，結果發現網頁能打開，換了網也連不上。因而我忽然細思極恐：握草？B 站居然也把我封了？（老通緝犯了）

就是這樣，我是事故現場的受害人，是倒在地上懵逼的那個，因此直到事故發生十幾分鍾後，我才經過其餘途徑瞭解到，哦，原來是 B 站出事了。

雖然錯過了第一現場，但經過熱搜，也能瞭解到 B 站崩盤的大體過程，簡單地說，就是在 幾個小時 內，用戶沒法正常訪問 B 站的任何功能！

打開 B 站，先是 404 Not Found 找不到資源：

而後是 502 錯誤網關：

1 個小時後，一些小夥伴表示 B 站的部分功能已經可使用了，但仍是沒有徹底恢復，直到 14 日凌晨，B 站官方纔終於迴應，恢復正常了。

緣由猜想

昨晚剪視頻到凌晨 2 點多，原本想直接睡覺，但手賤又打開了知乎，發現 「B 站崩了」 是 Top 1 熱門的問題，出於好奇就點進去想了解下事故背後的真正緣由，看看你們的高見。

原本我一個非 B 站工做的外來人，對它的技術架構沒有深刻了解；再加上缺乏關鍵信息、沒有可靠的推測憑據，因此不許備發表意見的。結果發現前排沒有幾個程序員在從技術的角度推測事故緣由，都是一些幫你們吃瓜更香的小回答。那我不妨根據過往學到的架構知識，作一波推測，萬一推中了感受也挺驚喜的。

其實在 20 年的時候，B 站技術總監毛劍老師就在騰訊雲 + 社區分享過《B 站高可用架構實踐》講座，當時我全程看完了，但沒想到，有一天，高可用的 B 站不可用了。

因此在此次分析前，我先把《B 站高可用架構實踐》文章又讀了一遍，有趣的是，短短半天，這篇文章的閱讀量漲了 15 萬！

並且更有趣的是，文章底下多了很多 「嘲諷」，什麼 「八股文架構師」 之類的：

不過我以爲不必，由於毛劍老師分享的技術確實是很實用的高可用解決方案，只不過仍是缺乏了一些印證吧。

文章地址：cloud.tencent.com/developer/a…

下面說下個人猜想。

猜想 1：網關掛了

首先，此次小破站事故發生時，其餘站點居然也崩了！好比 A 站、晉江、豆瓣，通通都上了熱搜。

這些事故同時發生，說明是這些系統依賴的公共服務出了問題，而惟一有能力致使大規模服務癱瘓的就是 CDN 了。

CDN 是內容分發網絡，提早將源站內容發到各個地區的服務器節點，以後就可讓不一樣地區的用戶就近獲取內容，而不是都到源站獲取，從而起到內容加速、負載均衡的做用。

一旦 CDN 掛了，該地區用戶的流量會所有打到網關上：

網關就像是家族老大，用戶有需求就跟老大說，而後老大再分配需求給弟弟們去完成。

此外，網關一般還承擔起了保護服務弟弟們的使命，統一負載均衡、控制流量、熔斷降級等。

按道理來說，一般網關不只要保護下游的服務，自身也是須要安全保護的。但爲何網關沒有保護好本身呢？

個人猜想是：網關尚未來的及開啓保護措施（自身的熔斷降級等），就被流量瞬狙了。

網關一掛，服務沒爹，服務缺乏了調用入口，天然就不可用了，未必全部網關後的服務都處於癱瘓狀態。

猜想 2：服務雪崩

還有一種猜想是 B 站系統存在不少服務的 調用鏈 。因爲 CDN 或者部分機器掛掉，致使某個下游服務 A 的執行耗時增長，從而致使上游調用服務 A 的服務 B 執行耗時也增長，讓系統單位時間的處理能力變差。再加上上游不斷積壓請求，最終致使整個調用鏈雪崩，全部鏈上服務從兒子到爸爸所有滅門。

舉個通俗的例子就是家裏的馬桶堵了，桶裏的還沒充下去，上面卻還在不斷 「送貨」，最終下場就是你不能再 「送貨」 了，馬桶爆了！

官方解釋

在官方解釋是服務器機房發生故障以後，又看了其餘老師的分析，感受官方的解釋還說的過去。

的確以前 B 站在對外分享高可用架構時幾乎沒有提到 災備 和 多活 方面的設計，更多的是在本地服務層和應用層去處理，好比限流、降級、熔斷、重試、超時處理等，因此在設計大規模分佈式系統時仍是要考慮更全面一些，引覺得戒~

直到發文前，知乎 Top 1 的回答者又很用心地整理了線索：

爲何其餘兩家很快就恢復了，B 站卻花了幾個小時才恢復正常呢？

感受多少和 B 站自研組件有關係，一方面受到雲服務商的影響，致使下游的服務連鎖掛掉了，故障面積大 ；另外一方面重啓也須要時間，並且重啓過程當中，上游的負載均衡也未必能承受住流量高峯，因此想要恢復到正常水平，至少要等待不少容器副本徹底重啓。

另外昨天 23 點半左右，我打開 B 站時，看到的內容是幾個小時前的老數據，說明這個時候 B 站已經重啓了部分服務副本，而且開啓了降級措施，並無查詢真實數據。

沒想到本身的這個回答還在知乎小火了一把，第一次成爲了 千萬瀏覽量 問題的 Top 2，受寵若驚，受寵若驚。。。

保命：以上自己就是個人猜想哈哈，專業度有限，歡迎你們評論區討論，輕噴輕噴。

防治技術

再簡單聊一下服務故障的防治技術，就是如何保證服務的高可用性，儘可能持續爲用戶提供服務而不宕機。

我將瞭解到的技術簡單分類，整理成了一張思惟導圖：

暫時想到這麼多，固然還有其餘的技術。

時間有限，就先不對這些技術展開去講了。關於如何減小系統出現的 Bug、保證服務高可用，歡迎你們閱讀個人歷史文章：揭祕軟件開發的達摩克利斯之劍，以上不少技術也都有講解。

收穫感悟

關於此次事故，我做爲受害者之一，也有一些收穫和感悟，而不是吃瓜吃了個寂寞。

首先是要有 質疑精神 ，咱們在寫程序出現問題時，習慣性地先從本身身上找緣由沒有任何問題，但本身排查沒有發現 Bug 後，應該大膽推測是咱們用到的類庫、組件、或者依賴服務、甚至有多是編輯器出了問題，而不是認爲知名的東西必定正確。像小破站出了問題後，我居然懷疑是本身的直播被封了哈哈，差點想找到管理去跪了。

在編程方面，咱們不能只去背知識、聽別人講，作 八股文架構師；而是要作實踐經驗豐富的工程師，不盲目相信、不想固然，而是在實踐中積累經驗、結合實際去優化系統。

經過此次結合實際故障過程的分析，我也複習了一遍以前學到的架構知識，對一些高可用的設計有了更深的理解。有朝一日，儘可能不讓 編程導航（www.code-nav.cn） 成爲下一個 B 站（狗頭）。

還有就是上面提到的，要時刻居安思危，養成防護性編程的好習慣，而不是出了問題再去補救。像 B 站這種知名平臺，出一點小問題，對用戶、對企業帶來的損失都是難以估量的。

感謝 B 站爸爸送來的一天大會員補償 ❤️

---

最後再送你們一些 幫助我拿到大廠 offer 的學習資料：

跑了，留下 6T 的資源！

我是如何從零開始經過自學，拿到騰訊、字節等大廠 offer 的，能夠看這篇文章，再也不迷茫！

我學計算機的四年，共勉！

我是魚皮，點贊 仍是要求一下的，祝你們都能心想事成、發大財、行大運。