欧美日韩在线成人免费-欧美日韩在线成人看片a-欧美日韩在线不卡-欧美日韩在线播放-自拍偷拍三级-自拍偷拍欧美亚洲

網(wǎng)絡(luò)消費網(wǎng) >  IT > > 正文
每日快播:B站自曝去年服務(wù)器大崩潰原因 就因為這?
時間:2022-07-20 05:34:04

不知道差友們還記不記得,去年的 7 月 13 日,B 站發(fā)生了一件大事。它毫無征兆的崩了。。。( 如果忘了的小伙伴,可以看這篇文章)

至于為啥崩了,當(dāng)時大家誰也心里沒個底。不過吹起水來可是一套一套的,什么停電啊,起火啊,程序員 rm -rf /* 跑路啊。。。說的是個天馬行空。

后來呢,隨著 B 站在凌晨兩點一頓修仙,把服務(wù)器問題給慢慢解決,這件事情也算是告一段落了。


【資料圖】

本以為這次 B 站崩了會和微博上無數(shù)崩了的網(wǎng)站一樣,成為我們沖浪生活中的一個笑談,僅留下一個大會員給我們“ 緬懷 ”。

沒想到在今年的 7 月 13 日,B 站特意發(fā)了一篇文章,刨開心窩子來給我們講了一講,那個晚上,到底發(fā)生了什么。

咱也看了一下這篇文章,好家伙,讓整個 B 站崩潰的原因,竟然只是一行代碼沒寫好???借著這篇文章,世超準(zhǔn)備帶大家從B 站的角度來回顧一下這件事情。放心,不會有生澀難懂的名詞,不會有犀利糊涂的黑話,保證小白也能看明白。 案情回溯:意外,發(fā)生在 2021 年 7 月 13 日的 22 時 52 分。

負(fù)責(zé)搞定站點可靠性的工程師(SRE)和B站的客服都收到了大量網(wǎng)站打不開的報警。

而負(fù)責(zé)處理這些事故的同事已經(jīng)下班了,當(dāng)即準(zhǔn)備在家里通過 VPN 來登錄公司內(nèi)網(wǎng)處理這些問題。

結(jié)果發(fā)現(xiàn)VPN也崩了。。。壓根進(jìn)不去系統(tǒng)。最后,還是在公司的整了個 “ 綠色通道 ” 才成功進(jìn)去。你說這綠色通道不會是向日葵吧(一種遠(yuǎn)程桌面軟件)

而在綠色通道成功打通,負(fù)責(zé)各種業(yè)務(wù)的團(tuán)隊就位之后,B 站也開始對問題進(jìn)行分析定位。出問題的模塊也很明顯,在線業(yè)務(wù)主機(jī)房的7層 SLB(負(fù)載均衡服務(wù)器,用來處理多用戶,多業(yè)務(wù)的情況)的 CPU 跑滿了 100%。

簡單來說,就是 CPU 被不知道哪里來的刺客給占用光了算力,沒法處理業(yè)務(wù)了。

系統(tǒng)未響應(yīng).exe▼

B 站最開始的嘗試方法呢,和咱們平時手機(jī)電腦卡機(jī)后做的操作一樣。

重啟就完事了,要相信重啟能解決 90% 的問題!

但很可惜,B 站這次是那個 10.5%。

說業(yè)務(wù)恢復(fù)了嘛,也沒有,主機(jī)房重啟后還是出現(xiàn)了CPU 跑滿 100%的問題。不過別的機(jī)房好起來了,雖然會卡,但是沒出現(xiàn) CPU 跑滿的問題。

有一部分做了多活的業(yè)務(wù)(多站點同時提供服務(wù))開始慢慢恢復(fù)。所以。。。重啟不能完全解決問題,但是這個問題既然過去沒出現(xiàn)過。

那會不會是新加入的代碼問題呢?隨著時間在一分一秒的過去,借助分析工具的幫助,問題被定位到了最近新上線的 Lua(一種編程語言,類似 Python,Java 這些)函數(shù)上。

隨后,B 站開始進(jìn)行了一波波緊張的回滾操作。

這一通工作弄下來,雖然好像找到幾個疑似出問題的部位,但服務(wù)器還是該掛掛,距離 “ 康復(fù) ” 還有那么一些距離。

沒辦法,總得讓業(yè)務(wù)先跑起來吧。于是團(tuán)隊開始兵分兩路。一隊繼續(xù)堅持排查問題,尋找原因,另一隊則是開始重建一個新的 SLB 服務(wù)。

在緊張刺激的一小時后,新的 SLB 配置成功,原本導(dǎo)向主站的流量也慢慢的開始遷移過去。

好在這次行了。

凌晨兩點,在崩潰了三小時之后,B 站的業(yè)務(wù)總算得到了恢復(fù)。罪魁禍?zhǔn)祝荷厦孢@些,就是那個晚上 B 站發(fā)生的故事,雖然解決了表面問題,讓業(yè)務(wù)恢復(fù)了。

可是最根本的原因是啥呢?如果不找到根因,那遲早會二度暴雷。

負(fù)責(zé)排查問題的同學(xué)也沒讓人失望,在時間壓力大大放緩之后,找出了真相。沒有外星人,沒有起火,沒有斷電,和網(wǎng)友們想象的大相徑庭。B 站這次崩的根因,僅僅是因為一個求最大公約數(shù)的函數(shù)沒寫好。。。

咱先盤一下這個 “ 萬惡之源 ” 哈。

這是一個典型的 “自己調(diào)用自己 ” 的遞歸函數(shù)。a b兩數(shù)字輾轉(zhuǎn)求余,直到b 等于 0的時候函數(shù)終止。不然這個函數(shù)就會自己調(diào)用自己,重新再跑一遍。

看上去好像是一點點問題都沒有,既明確了遞歸的終止條件(b = 0),也沒有太多復(fù)雜的邏輯處理。但是既然事情能發(fā)展到這地步。。。那就說明是出大問題了。對編程有些了解的差友可能發(fā)現(xiàn)了不對:

你傳進(jìn)去的 0,是個什么 0?沒錯,在編程語言里,數(shù)字 0 和字符串 ‘ 0 ’并不算是一個東西。為了防止呆呆的計算機(jī)語言把事情給搞混,像 C 語言,Java 這些靜態(tài)語言都會要求我們在創(chuàng)建新變量的時候聲明這個變量的類型。

搞清楚它到底是整數(shù),還是小數(shù),或者是一個字符。然而 Lua 是個非常智慧的語言,它沒有這個要求。麻煩的臟活累活讓它自動來做就好了,Lua 會根據(jù)程序的需求自動分配變量類型。

C語言示例:# 定義一個整型數(shù)據(jù)a,為它賦值1# 定義一個字符串?dāng)?shù)據(jù)b,為它賦值‘1’int a = 0;char a = "0";Lua示例:--定義 a 為數(shù)字0,b為字符串‘0’a = 0b = "0"

所以,我們給參數(shù) b 傳進(jìn)去的數(shù)值,是數(shù)字 0呢,還是字符 ‘ 0 ’?一旦前面數(shù)據(jù)驗證沒把好關(guān),在執(zhí)行某個功能的時候,把字符 ‘ 0 ’給傳到了這個函數(shù)里。

地雷就被引爆了。字符串‘0’不會等于數(shù)字 0,函數(shù)的終止條件判斷不通過。

所以程序進(jìn)入遞歸模式,再次調(diào)用自己。在后續(xù)進(jìn)行求余預(yù)算的時候,Lua 的 “ 智慧 ” 又突然起到了作用。Lua 一拍腦袋,咋會有人把字符 ‘ 0 ’ 拿來做計算啊,肯定是想把這個參數(shù)當(dāng)數(shù)字用。

于是發(fā)生了強(qiáng)制類型轉(zhuǎn)換。

所以咱們小學(xué)數(shù)學(xué)都會學(xué)到的。。。把 0 當(dāng)除數(shù)的事情就發(fā)生了。這要是古老的大哥 C 語言來干這活,可能直接就給一個 Floating point exception 報錯了。但是 Lua 不一樣,作為一個新時代的 “ 智慧 ” 的語言,它會優(yōu)雅的返回一個 nan(Not A Numbewr)。

程序,繼續(xù)運行。更要命的是,nan 也不會等于0。。。程序的終止條件無法實現(xiàn)。這樣跑幾個循環(huán)之后,原本用來計算 a 和 b 的最大公約數(shù)的函數(shù) _gcd(a,b) 就變成了一個停不下來的函數(shù) _gcd(nan,nan)。

在停不下來的路上根本停不下來,直接把 CPU 資源給吃滿了。

太聰明也不是一件好事啊。。。

就這樣,被占滿的 CPU 一口氣把別的業(yè)務(wù)也帶崩了。還得前面提到的在家的 B 站程序員沒法在家通過 VPN 來搶救網(wǎng)絡(luò)么?沒錯,他們登錄內(nèi)網(wǎng)的時候,其中有部分服務(wù)也需要通過內(nèi)網(wǎng)來處理。。。

屬于是把鑰匙斷鎖眼里,也是崩的理所當(dāng)然了。崩完之后:最后,如果差友們對相關(guān)技術(shù)細(xì)節(jié)更感興趣的話,世超建議你看看 B 站發(fā)布的這篇2021.07.13 我們是這樣崩的除了對事故的起承轉(zhuǎn)合,還對未來技術(shù)的更進(jìn)與反思都做了更加專業(yè),全面的總結(jié)。

講道理,這樣的機(jī)會其實挺難得的。每年崩了的應(yīng)用何其多,但是愿意發(fā)出來給同行學(xué)習(xí),給普羅大眾看個樂子的寥寥無幾。

向上滑動▼

B 站這次愿意分享,直面自己的 “ 傷疤 ” 。也讓我們看到了互聯(lián)網(wǎng)運維上最真實的一面。這些經(jīng)驗,可不會寫在任何教科書上。哦對,這篇文章發(fā)出來的晚上,B 站其實又偷偷小崩了一次。。。

不知道是不是團(tuán)隊好好總結(jié)了去年經(jīng)驗的緣故。這回還沒等大部分人反應(yīng)過來。。。B 站已經(jīng)把問題給解決了。

關(guān)鍵詞: B站自曝去年服務(wù)器大崩潰原因 就因為這

版權(quán)聲明:
    凡注明來網(wǎng)絡(luò)消費網(wǎng)的作品,版權(quán)均屬網(wǎng)絡(luò)消費網(wǎng)所有,未經(jīng)授權(quán)不得轉(zhuǎn)載、摘編或利用其它方式使用上述作品。已經(jīng)本網(wǎng)授權(quán)使用作品的,應(yīng)在授權(quán)范圍內(nèi)使用,并注明"來源:網(wǎng)絡(luò)消費網(wǎng)"。違反上述聲明者,本網(wǎng)將追究其相關(guān)法律責(zé)任。
    除來源署名為網(wǎng)絡(luò)消費網(wǎng)稿件外,其他所轉(zhuǎn)載內(nèi)容之原創(chuàng)性、真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考并自行核實。
熱文

網(wǎng)站首頁 |網(wǎng)站簡介 | 關(guān)于我們 | 廣告業(yè)務(wù) | 投稿信箱
 

Copyright © 2000-2020 www.xnbt.net All Rights Reserved.
 

中國網(wǎng)絡(luò)消費網(wǎng) 版權(quán)所有 未經(jīng)書面授權(quán) 不得復(fù)制或建立鏡像
 

聯(lián)系郵箱:920 891 263@qq.com

備案號:京ICP備2022016840號-15

營業(yè)執(zhí)照公示信息

主站蜘蛛池模板: 毛片免费观看网址| 北条麻妃大战黑人| 一级电影毛片| 欧美日韩中文字幕在线| 韩国三级中文字幕| 岛国免费v片在线播放| 一级毛片免费播放男男| 精品国产不卡一区二区三区| 狠狠色狠狠色综合网| 亚洲日本乱码在线观看| 女生张开腿让男生通| 动漫乱理伦片在线观看| 久久国产精品久久| 四虎色姝姝影院www| 一个人看的www日本高清视频| 午夜性爽快| 91caoprom| 日b视频免费看| 波多野结衣bt| 国产**aa全黄毛片| 久久er国产精品免费观看2| 扒开末成年粉嫩的小缝视频| 亚洲福利精品一区二区三区| 精品无人区麻豆乱码1区2区 | 久久国产精品二国产精品| 久久电影网午夜鲁丝片免费| 午夜精品久久久久久| 国产青草视频免费观看97| 欧美日韩大片在线观看| 成人毛片在线观看| 久久国产精品免费一区二区三区| 男女无遮挡猛进猛出免费观看视频| 爱我久久国产精品| 美国式禁忌矿桥矿17集| 久久伊人精品| 亚洲精品aaa揭晓| 再深一点灬舒服灬太大了| 日本护士恋夜视频免费列表| 久久久久久久综合狠狠综合| 新木乃伊电影免费观看完整版| 美女主动张腿让男人桶|