B站自曝去年服务器大崩溃原因 就因为这？

　　来源：差评

　　不知道差友们还记不记得，去年的7月13日，B站发生了一件大事。它毫无征兆的崩了。。。（如果忘了的小伙伴，可以看 这篇文章 ）

　　至于为啥崩了，当时大家谁也心里没个底。不过吹起水来可是一套一套的，什么停电啊，起火啊，程序员rm-rf/*跑路啊。。。说的是个天马行空。

　　后来呢，随着B站在凌晨两点一顿修仙，把服务器问题给慢慢解决，这件事情也算是告一段落了。

　　本以为这次B站崩了会和微博上无数崩了的网站一样，成为我们冲浪生活中的一个笑谈，仅留下一个大会员给我们 “缅怀”。

　　没想到在今年的7月13日，B站特意发了一篇文章，刨开心窝子来给我们讲了一讲，那个晚上，到底发生了什么。

　　咱也看了一下这篇文章，好家伙，让整个B站崩溃的原因，竟然只是一行代码没写好？？？借着这篇文章，世超准备带大家从 B站的角度来回顾一下这件事情。放心，不会有生涩难懂的名词，不会有犀利糊涂的黑话，保证小白也能看明白。  案情回溯：  意外，发生在2021年7月13日的22时52分。

　　负责搞定站点可靠性的工程师（SRE）和B站的客服都收到了大量网站打不开的报警。

　　而负责处理这些事故的同事已经下班了，当即准备在家里通过VPN来登录公司内网处理这些问题。

　　结果发现VPN 也崩了。。。压根进不去系统。最后，还是在公司的整了个“绿色通道”才成功进去。你说这绿色通道不会是向日葵吧（一种远程桌面软件）

　　而在绿色通道成功打通，负责各种业务的团队就位之后，B站也开始对问题进行分析定位。出问题的模块也很明显，在线业务主机房的7层SLB（负载均衡服务器，用来处理多用户，多业务的情况）的CPU跑满了100%。

　　简单来说，就是CPU被不知道哪里来的刺客给占用光了算力，没法处理业务了。

　　系统未响应。exe ▼

　　B站最开始的尝试方法呢，和咱们平时手机电脑卡机后做的操作一样。

　　重启就完事了，要相信重启能解决90%的问题！

　　但很可惜，B站这次是那个10.5%。

　　说业务恢复了嘛，也没有，主机房重启后还是出现了CPU跑满100%的问题。不过别的机房好起来了，虽然会卡，但是没出现CPU跑满的问题。

　　有一部分做了多活的业务（多站点同时提供服务）开始慢慢恢复。所以。。。重启不能完全解决问题，但是这个问题既然过去没出现过。

　　那会不会是新加入的代码问题呢？随着时间在一分一秒的过去，借助分析工具的帮助，问题被定位到了最近新上线的Lua （一种编程语言，类似Python，Java这些） 函数上。

　　随后，B站开始进行了一波波紧张的回滚操作。

　　这一通工作弄下来，虽然好像找到几个疑似出问题的部位，但服务器还是该挂挂，距离“康复”还有那么一些距离。

　　没办法，总得让业务先跑起来吧。于是团队开始兵分两路。一队继续坚持排查问题，寻找原因，另一队则是开始重建一个新的SLB服务。

　　在紧张刺激的一小时后，新的SLB配置成功，原本导向主站的流量也慢慢的开始迁移过去。

　　好在这次行了。

　　凌晨两点，在崩溃了三小时之后，B站的业务总算得到了恢复。   罪魁祸首：  上面这些，就是那个晚上B站发生的故事，虽然解决了表面问题，让业务恢复了。

　　可是最根本的原因是啥呢？如果不找到根因，那迟早会二度暴雷。

　　负责排查问题的同学也没让人失望，在时间压力大大放缓之后，找出了真相。没有外星人，没有起火，没有断电，和网友们想象的大相径庭。B站这次崩的根因，仅仅是因为一个求最大公约数的函数没写好。。。

　　咱先盘一下这个“万恶之源”哈。

　　这是一个典型的“ 自己调用自己”的递归函数。ab两数字辗转求余，直到 b等于0 的时候函数终止。不然这个函数就会自己调用自己，重新再跑一遍。

　　看上去好像是一点点问题都没有，既明确了递归的终止条件（b=0），也没有太多复杂的逻辑处理。但是既然事情能发展到这地步。。。那就说明是出大问题了。对编程有些了解的差友可能发现了不对：

　　你传进去的0，是个什么0？没错，在编程语言里，数字0和字符串‘0’ 并不算是一个东西。为了防止呆呆的计算机语言把事情给搞混，像C语言，Java这些静态语言都会要求我们在创建新变量的时候声明这个变量的类型。

　　搞清楚它到底是整数，还是小数，或者是一个字符。然而Lua是个非常智慧的语言，它没有这个要求。麻烦的脏活累活让它自动来做就好了，Lua会根据程序的需求自动分配变量类型。

　　C语言示例：#定义一个整型数据a，为它赋值1#定义一个字符串数据b，为它赋值‘1’inta=0；chara=‘0’；Lua示例：--定义a为数字0，b为字符串‘0’a=0b=‘0’

　　所以，我们给参数b传进去的数值，是数字0 呢，还是字符‘0’ ？一旦前面数据验证没把好关，在执行某个功能的时候，把字符‘0’ 给传到了这个函数里。

　　地雷就被引爆了。字符串 ‘ 0 ’ 不会等于数字0，函数的终止条件判断不通过。

　　所以程序进入递归模式，再次调用自己。在后续进行求余预算的时候，Lua的“智慧”又突然起到了作用。Lua一拍脑袋，咋会有人把字符‘0’拿来做计算啊，肯定是想把这个参数当数字用。

　　于是发生了强制类型转换。

　　所以咱们小学数学都会学到的。。。 把0当除数的事情就发生了。这要是古老的大哥C语言来干这活，可能直接就给一个Floatingpointexception报错了。但是Lua不一样，作为一个新时代的“智慧”的语言，它会优雅的返回一个nan （NotANumbewr）。

　　程序，继续运行。更要命的是，nan也不会等于0。。。程序的终止条件无法实现。这样跑几个循环之后，原本用来计算a和b的最大公约数的函数_gcd（a，b）就变成了一个停不下来的函数_gcd（nan，nan）。

　　在停不下来的路上根本停不下来，直接把CPU资源给吃满了。

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

　　就这样，被占满的CPU一口气把别的业务也带崩了。还得前面提到的在家的B站程序员没法在家通过VPN来抢救网络么？没错，他们登录内网的时候，其中有部分服务也需要通过内网来处理。。。

　　属于是把钥匙断锁眼里，也是崩的理所当然了。   崩完之后：  最后，如果差友们对相关技术细节更感兴趣的话，世超建议你看看B站发布的这篇2021.07.13我们是这样崩的除了对事故的起承转合，还对未来技术的更进与反思都做了更加专业，全面的总结。

　　讲道理，这样的机会其实挺难得的。每年崩了的应用何其多，但是愿意发出来给同行学习，给普罗大众看个乐子的寥寥无几。

　　向上滑动 ▼

　　B站这次愿意分享，直面自己的“伤疤”。也让我们看到了互联网运维上最真实的一面。这些经验，可不会写在任何教科书上。哦对，这篇文章发出来的晚上，B站其实又偷偷小崩了一次。。。

　　不知道是不是团队好好总结了去年经验的缘故。这回还没等大部分人反应过来。。。B站已经把问题给解决了。