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

文章图片

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

文章图片

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

文章图片

所以咱们小学数学都会学到的。。。把 0 当除数的事情就发生了。这要是古老的大哥 C 语言来干这活，可能直接就给一个 Floating point exception 报错了。但是 Lua 不一样，作为一个新时代的 “ 智慧 ” 的语言，它会优雅的返回一个 nan （Not A Numbewr）。
程序，继续运行。更要命的是，nan 也不会等于0 。。。程序的终止条件无法实现。这样跑几个循环之后，原本用来计算 a 和 b 的最大公约数的函数 _gcd(a,b) 就变成了一个停不下来的函数 _gcd(nan,nan) 。
在停不下来的路上根本停不下来，直接把 CPU 资源给吃满了。

文章图片

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

文章图片

属于是把钥匙断锁眼里，也是崩的理所当然了。崩完之后：最后，如果差友们对相关技术细节更感兴趣的话，世超建议你看看 B 站发布的这篇2021.07.13 我们是这样崩的除了对事故的起承转合，还对未来技术的更进与反思都做了更加专业，全面的总结。
讲道理，这样的机会其实挺难得的。每年崩了的应用何其多，但是愿意发出来给同行学习，给普罗大众看个乐子的寥寥无几。
向上滑动 ▼

文章图片

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

文章图片

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

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

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