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