我是小 R，天天晚上我都會去逛 B 站。前端
看可愛的貝貝子吃播。git
因爲來來回回千百次了，對於去 B 站的路，我很是熟悉。面試
說到去 B 站的路，我依稀記得第一次去的時候，那拐的山路十八彎都給我繞暈了。算法
首先我從瀏覽器出發，通過域名解析(DNS)，拿到了一個 CNAME ，我一看 xxx.cdn.ababa就知道 B 站是上了 CDN 啦，很正常這麼大的網站不上 CDN 是不可能的。瀏覽器
拿到這個 CDN 的網址後，我就去訪問了這個 CDN 服務商的權威 DNS，CDN 廠商根據個人地理位置等其餘負載策略返回了一個 最合適個人 CDN 緩存節點的 IP，以後我就一直去請求這個 IP 啦。緩存
固然，我是一個有學問的小 R ，我知道若是個人訪問不命中 CDN 緩存的話，CDN 服務器就會去源站(B站)請求獲得響應，而後緩存並返回。服務器
因此本質上 CDN 節點就是一個緩存，它減輕了源站(B站)的負載，而且因爲 CDN 節點遍及全國，因此挑選距離咱們最近、最佳的節點供咱們服務，也提升了響應速度。網絡
不扯 CDN 了，我們繼續說說去 B 站的路。架構
B 站固然不會只有一個數據中心，根據前端負載均衡我被劃到了上海的數據中心。併發
而數據中心內部，又有一個負載均衡器，它的做用主要是均勻的將請求分發給後面的服務、而且識別異常的服務、進行節點的擴容，減小錯誤，提升可用性。
據我所知，這個負載均衡的算法，B站也很有研究。
他們發現 CPU 忙時、閒時佔用率過大，對每一個請求來講，不一樣請求的成本是不同的，有些請求耗時，有些請求很輕量，因此即使作了均衡的流量分發，可是從負載的角度來看，實際上仍是不均勻的。
而且又有物理機環境上的差別，由於 B 站一般都是分年採購服務器，新買的服務器一般主頻 CPU 會更強一些，因此服務器本質上很難作到強同質。
畫外音：別問我爲何知道，這是B站總監和我說的，嘻嘻。
因此 B 站使用 the choice-of-2 算法，隨機選取的兩個節點進行打分，選擇更優的節點：
就這樣經過負載均衡算法的分配，我來到了一個服務裏，我發現它們還實現了一個叫quota-server的分佈式限流！
這個服務的負責人跟我說，「不管負載均衡策略如何高效，系統某個部分總會過載，因此他們會先考慮優雅降級，返回低質量的結果，提供有損服務。在最差的狀況，妥善的限流來保證服務自己穩定。」
我想了想，確實有道理！這個負責人還說，他們這個分佈式限流服務是基於過去時間的滑動窗口內的 inflight (就理解爲最近的請求量歷史值)來作配額，每次服務會向 quota-server 申請一批配額到本地，這樣客戶端請求的時候能夠直接消費服務本地的配額，而不用每次都去 quota-server 申請。而且在算法層面，採用了最大最小公平算法，解決某個大消耗者致使的飢餓。
我聽了直呼666，心中默默的給 B 站比了個大拇指。
沒想到這個服務的負責人好像一會兒打開了話匣子。
「咱們客戶端還作了截流，由於當服務出現限流的時候，客戶端可能會一直請求，使得服務端還得忙着返回限流啦，限流啦。因此爲了進一步減輕服務端的負載，咱們對客戶端截流，使之在限流時請求發不到網絡層，具體是參考 Google SRE裏一個有意思的公式，max(0, (requests- K*accepts) / (requests + 1))，客戶端直接發生請求，當達到限制，直接進行機率截流，怎麼樣是否是很厲害？」
此次，我直接給了他兩個大拇指。
「想必你還不知道咱們是如何開啓限流的吧？咱們是基於 CPU 的負載來判斷壓力的，咱們將 CPU的滑動均值（CPU > 800 ）做爲啓發閾值，一旦觸發就進入到過載保護階段。算法爲：(MaxPass * AvgRT) < InFlight。其中MaxPass、AvgRT都爲觸發前的滑動時間窗口的統計值。」
「咱們還使用了冷卻時間，防止限流生效短期內的CPU降低，致使大量請求被放行，瞬間又打滿CPU的狀況。」
此次，我直接給了他兩個大拇指，外加一個腳拇指，考慮的真周到！
「固然，基於限流或者其餘錯誤，咱們仍是有重試的，爲了防止重試對已通過載的服務形成更大的壓力，咱們限制重試的次數，並採用週期性的重試時間，逐漸遞增。好比100ms重試一次不行，等300ms再重試一次，仍是不行再等500ms重試一次這樣。」
「對了，還有服務間的超時也很重要。特別是高併發下，若是有高延遲服務，由於下游延時長，致使請求堆積，引起線程阻塞，而請求流量還在不斷涌入，最終引起故障，致使雪崩，而後服務全面崩盤，3.25打在公屏上。」
「因此出現這種狀況，應該要採用 Fail-fast，不要拖着等待，直接快速失敗，這樣請求就不會堆積，保證了總體服務的穩定。」
「因此能夠定義一個全局的時間，而後每一個服務調用前判斷一下剩餘的時候夠不夠消費，若是不夠直接返回，切斷下游的繼續調用，節省資源。」
說了以後，負責人看了我一眼。我心照不宣，直接給了他兩個大拇指，外加兩個腳拇指！
負責人滿意的點了點頭，我再給你彙總一下咯。
第一次去B站，負責人就給我盤了這麼多。你看，B站的路確實很差走吧，須要經歷這麼多管制，B站不愧是個大公司呢！
好了，不跟大家說了，我要去看貝貝子吃播啦~
我去也！！
？？？
我去也！！！
怎麼回事，我家網絡壞了？等我重啓下電腦！
好了，路由器從新插拔了，電腦也重啓了，我去也！！！！！
wtf？？？那個負責人，你說說到底咋回事？不是完美無缺了嘛！！
還我一天大會員！！！
這篇文章於7.14號午休期間匆忙BB而出，若有錯誤還請包涵和指正。
本人不是B站員工，也不瞭解 B 站的架構，以上故事，參考 B 站技術總監毛劍老師在「雲加社區沙龍online」的分享整理。
網址以下：https://cloud.tencent.com/developer/article/1618923
故事瞎編，若有雷同，純屬你抄我。其中的調侃也是爲了劇情須要，我仍是很熱愛 B 站的，天天都看。
故事說完了，我再來瞎分析一波。
一開始是 502 錯誤，我估計是 CDN 廠商出了問題，致使流量都打到 B 站去，這時候網關攔了，開始降級限流等。
可是晚上那個時候應該是流量高峯期，你們都下班回家看視頻，致使一會兒流量洪峯太高，而且因爲 B 站掛了，你們都想去瞅一瞅，這下更雪上加霜，B站一會兒 hold 不足，而後瞬間網關也掛了，產生雪崩，後面都掛了，因而致使了後面的404，服務直接找不到了。
因爲級聯掛的太多，服務又不少，盤子太大，因此啓動沒這麼快，因此致使好久都沒恢復，期間我估計事情擴散，又有不少人去訪問...因此就比較難。
至於火災的話，上海消防局闢謠了，沒有發生火災。
說斷電的，機房不可能沒備用電源（發電機）。
據網友反饋，國外的也看不了，我以爲很奇怪。
異地多活，我以爲 B 站應該有的，可是好像此次是全國各地都訪問不了？我也不知道具體的....
官方的是這樣回覆的，因此啥都看不出來，坐等着 B站的技術人員來一波分析？
我估計這個事情一出，又會有大廠面試題：你如何看待7.13日晚 B 站掛了的狀況？
因此下篇我再借着 B 站掛了的狀況，從面試的角度來說講，關注我等着哈。
關於面試題，這裏推薦有個倉庫，彙總了好多面試題
歡迎關注個人公衆號【yes的練級攻略】，更多硬核文章等你來讀。
我是yes，咱們下篇見。