一個(gè)小小字符“0”，竟引得B站全面崩潰。

不知你是否還記得那一夜，B站“大樓停電”、“服務(wù)器爆炸”、“程序員刪庫(kù)跑路”的徹夜狂歡。（手動(dòng)狗頭）

時(shí)隔一年，背后“真兇”現(xiàn)在終于被阿B披露出來(lái)——

沒想到吧，就是這么簡(jiǎn)單幾行代碼，直接干趴B站兩三個(gè)小時(shí)，搞得B站程序員徹夜無(wú)眠頭發(fā)狂掉。

你可能會(huì)問，這不就是個(gè)普普通通用來(lái)求最大公約數(shù)的函數(shù)嗎，怎么就有如此大的威力？

背后一樁樁一件件，歸根結(jié)底其實(shí)就一句話：0，它真的不興除啊。

具體詳情，咱們還是一起來(lái)看看“事故報(bào)告”。

字符串“0”引發(fā)的“血案”

先來(lái)說(shuō)道說(shuō)道引發(fā)慘案的根本原因，也就是開頭貼出的這個(gè)gcd函數(shù)。

學(xué)過(guò)一點(diǎn)編程知識(shí)的小伙伴應(yīng)該都知道，這是一種用輾轉(zhuǎn)相除法來(lái)計(jì)算最大公約數(shù)的遞歸函數(shù)。

跟我們手算最大公約數(shù)的方法不同，這個(gè)算法是醬嬸的：

舉個(gè)簡(jiǎn)單的例子，a=24，b=18，求a和b的最大公約數(shù)；

a除以b，得到的余數(shù)是6，那么就讓a=18，b=6，然后接著往下算；

18除以6，這回余數(shù)是0，那么6也就是24和18的最大公約數(shù)了。

也就是說(shuō)，a和b反復(fù)相除取余數(shù)，直到b=0，函數(shù)中：

if b==0 then return a end

這個(gè)判斷語(yǔ)句生效，結(jié)果就算出來(lái)了。

基于這樣的數(shù)學(xué)原理，我們?cè)賮?lái)看這段代碼，似乎沒什么問題：

但如果輸入的b是個(gè)字符串“0”呢？

B站的技術(shù)解析文章中提到，這段出事的代碼是用Lua寫的。Lua具有這么幾個(gè)特點(diǎn)：

• 這是一種動(dòng)態(tài)類型語(yǔ)言，常用習(xí)慣里變量不需要定義類型，直接給變量賦值就行。

• Lua在對(duì)一個(gè)數(shù)字字符串進(jìn)行算術(shù)操作時(shí)，會(huì)嘗試將這個(gè)數(shù)字字符串轉(zhuǎn)成一個(gè)數(shù)字。

• 在Lua語(yǔ)言中，數(shù)學(xué)運(yùn)算n%0的結(jié)果是nan(Not A Number)。

我們來(lái)模擬一下這個(gè)過(guò)程：

1、當(dāng)b是一個(gè)字符串“0”時(shí)，由于這個(gè)gcd函數(shù)沒有對(duì)其進(jìn)行類型校驗(yàn)，因此在碰上判定語(yǔ)句時(shí)，“0”不等于0，代碼中“return _gcd(b, a%b)”觸發(fā)，返回_gcd(“0”, nan)。

2、_gcd(“0”, nan)再次被執(zhí)行，于是返回值變成了_gcd(nan, nan)。

這下就完?duì)僮恿耍卸ㄕZ(yǔ)句中b=0的條件永遠(yuǎn)沒法達(dá)到，于是，死循環(huán)出現(xiàn)了。

也就是說(shuō)，這個(gè)程序開始瘋狂地原地轉(zhuǎn)圈，并且為了一個(gè)永遠(yuǎn)得不到的結(jié)果，把CPU占了個(gè)100%，別的用戶請(qǐng)求自然就處理不了了。

那么問題來(lái)了，這個(gè)“0”它到底是怎么進(jìn)去的呢？

官方說(shuō)法是：

在某種發(fā)布模式中，應(yīng)用的實(shí)例權(quán)重會(huì)短暫地調(diào)整為0，此時(shí)注冊(cè)中心返回給SLB（負(fù)載均衡）的權(quán)重是字符串類型的“0”。此發(fā)布環(huán)境只有生產(chǎn)環(huán)境會(huì)用到，同時(shí)使用的頻率極低，在SLB前期灰度過(guò)程中未觸發(fā)此問題。

SLB在balance_by_lua階段，會(huì)將共享內(nèi)存中保存的服務(wù)IP、Port、Weight作為參數(shù)傳給lua-resty-balancer模塊用于選擇upstream server，在節(jié)點(diǎn)weight=“0”時(shí)，balancer模塊中的_gcd函數(shù)收到的入?yún)可能為“0”。

bug是如何定位的

以“事后諸葛亮”的視角來(lái)看，這個(gè)引發(fā)B站全面崩潰的根本原因多少有點(diǎn)讓人直呼“就這”。

但從當(dāng)事程序員的視角來(lái)看，事情確實(shí)沒有辣么簡(jiǎn)單。

當(dāng)天晚上22:52分——大部分程序員才剛下班或者還沒下班的節(jié)骨眼（doge），B站運(yùn)維收到服務(wù)不可用的報(bào)警，第一時(shí)間懷疑機(jī)房、網(wǎng)絡(luò)、四層LB、七層SLB等基礎(chǔ)設(shè)施出現(xiàn)問題。

然后立馬和相關(guān)技術(shù)人員拉了個(gè)緊急語(yǔ)音會(huì)議開始處理。

5分鐘后，運(yùn)維發(fā)現(xiàn)承載全部在線業(yè)務(wù)的主機(jī)房七層SLB的CPU占用率達(dá)到了100%，無(wú)法處理用戶請(qǐng)求，排除其他設(shè)施后，鎖定故障為該層。

（七層SLB是指基于URL等應(yīng)用層信息的負(fù)載均衡。負(fù)載均衡通過(guò)算法把客戶請(qǐng)求分配到服務(wù)器集群，從而減少服務(wù)器壓力。）

萬(wàn)般緊急之時(shí)，小插曲還現(xiàn)了：遠(yuǎn)程在家的程序員登上VPN卻沒法進(jìn)入內(nèi)網(wǎng)，只好又去call了一遍內(nèi)網(wǎng)負(fù)責(zé)人，走了個(gè)綠色通道才全部上線（因?yàn)槠渲幸粋€(gè)域名是由故障的SLB代理的）。

此時(shí)已經(jīng)過(guò)去了25分鐘，搶修正式開始。

首先，運(yùn)維先熱重啟了一遍SLB，未恢復(fù)；然后嘗試拒絕用戶流量冷重啟SLB，CPU依然100%，還是未恢復(fù)。

接著，運(yùn)維發(fā)現(xiàn)多活機(jī)房SLB請(qǐng)求大量超時(shí)，但CPU未過(guò)載，正準(zhǔn)備重啟多活機(jī)房SLB時(shí)，內(nèi)部群反應(yīng)主站服務(wù)已恢復(fù)，視頻播放、推薦、評(píng)論、動(dòng)態(tài)等功能已基本正常。

此時(shí)是23點(diǎn)23分，距離事故發(fā)生31分鐘。

值得一提的是，這些功能恢復(fù)其實(shí)是事發(fā)之時(shí)被網(wǎng)友們吐槽的“高可用容災(zāi)架構(gòu)”發(fā)揮了作用。

至于這道防線為啥一開始沒發(fā)揮作用，里頭可能還有你我一點(diǎn)鍋。

簡(jiǎn)單來(lái)說(shuō)，就是大家伙點(diǎn)不開B站就開始瘋狂刷新，CDN流量回源重試 + 用戶重試，直接讓B站流量突增4倍以上，連接數(shù)突增100倍到千萬(wàn)級(jí)別，多活SLB就給整過(guò)載了。

不過(guò)，并不是所有服務(wù)都搞了多活架構(gòu)，至此事情并沒完全解決。

接下來(lái)的半個(gè)小時(shí)里，大家做了很多操作，回滾了最近兩周左右上線的Lua代碼，都沒把剩余的服務(wù)恢復(fù)。

時(shí)間來(lái)到了12點(diǎn)，沒有辦法了，“先不管bug是怎么出來(lái)的，把服務(wù)全恢復(fù)了再說(shuō)”。

簡(jiǎn)單+粗暴：運(yùn)維直接耗時(shí)一小時(shí)重建了一組全新的SLB集群。

凌晨1點(diǎn)，新集群終于建好：

一邊，有人負(fù)責(zé)陸續(xù)將直播、電商、漫畫、支付等核心業(yè)務(wù)流量切換到新集群，恢復(fù)全部服務(wù)（凌晨1點(diǎn)50分全部搞定，暫時(shí)結(jié)束了崩了逼近3個(gè)小時(shí)的事故）；

另一邊，繼續(xù)分析bug原因。

在他們用分析工具跑出一份詳細(xì)的火焰圖數(shù)據(jù)后，那個(gè)搞事的“0”才終于露出了一點(diǎn)端倪：

CPU熱點(diǎn)明顯集中在一個(gè)對(duì)lua-resty-balancer模塊的調(diào)用中。而該模塊的_gcd函數(shù)在某次執(zhí)行后返回了一個(gè)預(yù)期外的值：NaN。

同時(shí)，他們也發(fā)現(xiàn)了觸發(fā)誘因的條件：某個(gè)容器IP的weight=0。

他們懷疑是該函數(shù)觸發(fā)了jit編譯器的某個(gè)bug，運(yùn)行出錯(cuò)陷入死循環(huán)導(dǎo)致SLB CPU 100%。

于是就全局關(guān)閉了jit編譯，暫時(shí)規(guī)避了風(fēng)險(xiǎn)。一切都解決完后，已經(jīng)快4點(diǎn)，大家終于暫時(shí)睡了個(gè)好覺。

第二天大家也沒閑著，馬不停蹄地在線下環(huán)境復(fù)現(xiàn)了bug后，發(fā)現(xiàn)并不是jit編譯器的問題，而是服務(wù)的某種特殊發(fā)布模式會(huì)出現(xiàn)容器實(shí)例權(quán)重為0的情況，而這個(gè)0是個(gè)字符串形式。

正如前面所說(shuō)，這個(gè)字符串“0”在動(dòng)態(tài)語(yǔ)言Lua中的算術(shù)操作中，被轉(zhuǎn)成了數(shù)字，走到了不該走的分支，造成了死循環(huán)，引發(fā)了b站此次前所未見的大崩潰事件。

遞歸的鍋還是弱類型語(yǔ)言的鍋？

不少網(wǎng)友都還對(duì)這次事故記憶猶新，有回想起自己就是以為手機(jī)不行換電腦也不行的，也有人還記得當(dāng)時(shí)5分鐘后此事就上了熱搜。

大家都很詫異，就這么一個(gè)簡(jiǎn)單的死循環(huán)就能造成如此大的網(wǎng)站崩服。

不過(guò)，有人指出，死循環(huán)不罕見，罕見的是在SLB層、在分發(fā)過(guò)程出問題，它還不像在后臺(tái)出問題很快能重啟解決。

為了避免這種情況發(fā)生， 有人認(rèn)為要慎用遞歸，硬要用還是設(shè)置一個(gè)計(jì)數(shù)器，達(dá)到一個(gè)業(yè)務(wù)不太可能達(dá)到的值后直接return掉。

還有人認(rèn)為這不怪遞歸，主要還是弱類型語(yǔ)言的鍋。

以此還導(dǎo)致了“詭計(jì)多端的‘0’”這一打趣的說(shuō)法。

另外，由于事故實(shí)在是耽誤了太久、太多事兒，當(dāng)時(shí)B站給所有用戶補(bǔ)了一天大會(huì)員。

有人就在此算了一筆賬，稱就是這7行代碼，讓b站老板一下虧了大約1，5750，0000元。（手動(dòng)狗頭）

對(duì)于這個(gè)bug，你有什么想吐槽的？

參考鏈接：

[1]《2021.07.13 我們是這樣崩的》by 嗶哩嗶哩技術(shù)
https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Q