鱼羊 丰色 发自 凹非寺
来源:量子位 | 公众号 QbitAI
一个小小字符“0”,竟引得B站全面崩溃。
不知你是否还记得那一夜,B站“大楼停电”、“服务器爆炸”、“程序员删库跑路”的彻夜狂欢。(手动狗头)
时隔一年,背后“真凶”现在终于被阿B披露出来——
没想到吧,就是这么简单几行代码,直接干趴B站两三个小时,搞得B站程序员彻夜无眠头发狂掉。
你可能会问,这不就是个普普通通用来求最大公约数的函数吗,怎么就有如此大的威力?
背后一桩桩一件件,归根结底其实就一句话:0,它真的不兴除啊。
具体详情,咱们还是一起来看看“事故报告”。
字符串“0”引发的“血案”
先来说道说道引发惨案的根本原因,也就是开头贴出的这个gcd函数。
学过一点编程知识的小伙伴应该都知道,这是一种用辗转相除法来计算最大公约数的递归函数。
跟我们手算最大公约数的方法不同,这个算法是酱婶的:
举个简单的例子,a=24,b=18,求a和b的最大公约数;
a除以b,得到的余数是6,那么就让a=18,b=6,然后接着往下算;
18除以6,这回余数是0,那么6也就是24和18的最大公约数了。
也就是说,a和b反复相除取余数,直到b=0,函数中:
if b==0 then return a end
这个判断语句生效,结果就算出来了。
基于这样的数学原理,我们再来看这段代码,似乎没什么问题:
但如果输入的b是个字符串“0”呢?
B站的技术解析文章中提到,这段出事的代码是用Lua写的。Lua具有这么几个特点:
这是一种动态类型语言,常用习惯里变量不需要定义类型,直接给变量赋值就行。
Lua在对一个数字字符串进行算术操作时,会尝试将这个数字字符串转成一个数字。
在Lua语言中,数学运算n%0的结果是nan(Not A Number)。
我们来模拟一下这个过程:
1、当b是一个字符串“0”时,由于这个gcd函数没有对其进行类型校验,因此在碰上判定语句时,“0”不等于0,代码中“return _gcd(b, a%b)”触发,返回_gcd(“0”, nan)。
2、_gcd(“0”, nan)再次被执行,于是返回值变成了_gcd(nan, nan)。
这下就完犊子了,判定语句中b=0的条件永远没法达到,于是,死循环出现了。
也就是说,这个程序开始疯狂地原地转圈,并且为了一个永远得不到的结果,把CPU占了个100%,别的用户请求自然就处理不了了。
那么问题来了,这个“0”它到底是怎么进去的呢?
官方说法是:
在某种发布模式中,应用的实例权重会短暂地调整为0,此时注册中心返回给SLB(负载均衡)的权重是字符串类型的“0”。此发布环境只有生产环境会用到,同时使用的频率极低,在SLB前期灰度过程中未触发此问题。
SLB在balance_by_lua阶段,会将共享内存中保存的服务IP、Port、Weight作为参数传给lua-resty-balancer模块用于选择upstream server,在节点weight=“0”时,balancer模块中的_gcd函数收到的入参b可能为“0”。
bug是如何定位的
以“事后诸葛亮”的视角来看,这个引发B站全面崩溃的根本原因多少有点让人直呼“就这”。
但从当事程序员的视角来看,事情确实没有辣么简单。
当天晚上22:52分——大部分程序员才刚下班或者还没下班的节骨眼(doge),B站运维收到服务不可用的报警,第一时间怀疑机房、网络、四层LB、七层SLB等基础设施出现问题。
然后立马和相关技术人员拉了个紧急语音会议开始处理。
5分钟后,运维发现承载全部在线业务的主机房七层SLB的CPU占用率达到了100%,无法处理用户请求,排除其他设施后,锁定故障为该层。
(七层SLB是指基于URL等应用层信息的负载均衡。负载均衡通过算法把客户请求分配到服务器集群,从而减少服务器压力。)
万般紧急之时,小插曲还现了:远程在家的程序员登上VPN却没法进入内网,只好又去call了一遍内网负责人,走了个绿色通道才全部上线(因为其中一个域名是由故障的SLB代理的)。
此时已经过去了25分钟,抢修正式开始。
首先,运维先热重启了一遍SLB,未恢复;然后尝试拒绝用户流量冷重启SLB,CPU依然100%,还是未恢复。
接着,运维发现多活机房SLB请求大量超时,但CPU未过载,正准备重启多活机房SLB时,内部群反应主站服务已恢复,视频播放、推荐、评论、动态等功能已基本正常。
此时是23点23分,距离事故发生31分钟。
值得一提的是,这些功能恢复其实是事发之时被网友们吐槽的“高可用容灾架构”发挥了作用。
至于这道防线为啥一开始没发挥作用,里头可能还有你我一点锅。
简单来说,就是大家伙点不开B站就开始疯狂刷新,CDN流量回源重试 + 用户重试,直接让B站流量突增4倍以上,连接数突增100倍到千万级别,多活SLB就给整过载了。
不过,并不是所有服务都搞了多活架构,至此事情并没完全解决。
接下来的半个小时里,大家做了很多操作,回滚了最近两周左右上线的Lua代码,都没把剩余的服务恢复。
时间来到了12点,没有办法了,“先不管bug是怎么出来的,把服务全恢复了再说”。
简单+粗暴:运维直接耗时一小时重建了一组全新的SLB集群。
凌晨1点,新集群终于建好:
一边,有人负责陆续将直播、电商、漫画、支付等核心业务流量切换到新集群,恢复全部服务(凌晨1点50分全部搞定,暂时结束了崩了逼近3个小时的事故);
另一边,继续分析bug原因。
在他们用分析工具跑出一份详细的火焰图数据后,那个搞事的“0”才终于露出了一点端倪:
CPU热点明显集中在一个对lua-resty-balancer模块的调用中。而该模块的_gcd函数在某次执行后返回了一个预期外的值:NaN。
同时,他们也发现了触发诱因的条件:某个容器IP的weight=0。
他们怀疑是该函数触发了jit编译器的某个bug,运行出错陷入死循环导致SLB CPU 100%。
于是就全局关闭了jit编译,暂时规避了风险。一切都解决完后,已经快4点,大家终于暂时睡了个好觉。
第二天大家也没闲着,马不停蹄地在线下环境复现了bug后,发现并不是jit编译器的问题,而是服务的某种特殊发布模式会出现容器实例权重为0的情况,而这个0是个字符串形式。
正如前面所说,这个字符串“0”在动态语言Lua中的算术操作中,被转成了数字,走到了不该走的分支,造成了死循环,引发了b站此次前所未见的大崩溃事件。
递归的锅还是弱类型语言的锅?
不少网友都还对这次事故记忆犹新,有回想起自己就是以为手机不行换电脑也不行的,也有人还记得当时5分钟后此事就上了热搜。
大家都很诧异,就这么一个简单的死循环就能造成如此大的网站崩服。
不过,有人指出,死循环不罕见,罕见的是在SLB层、在分发过程出问题,它还不像在后台出问题很快能重启解决。
为了避免这种情况发生, 有人认为要慎用递归,硬要用还是设置一个计数器,达到一个业务不太可能达到的值后直接return掉。
还有人认为这不怪递归,主要还是弱类型语言的锅。
以此还导致了“诡计多端的‘0’”这一打趣的说法。
另外,由于事故实在是耽误了太久、太多事儿,当时B站给所有用户补了一天大会员。
有人就在此算了一笔账,称就是这7行代码,让b站老板一下亏了大约1,5750,0000元。(手动狗头)
对于这个bug,你有什么想吐槽的?
参考链接:
[1]《2021.07.13 我们是这样崩的》by 哔哩哔哩技术
https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg
— 完 —
RECOMMEND
推荐阅读
01
深入理解计算机系统(原书第3版)
作者:[美] 兰德尔 E.布莱恩特(Randal E. Bryant)
大卫 R. 奥哈拉伦(David R. O'Hallaron)
译者:龚奕利 贺莲
将所有计算机系统相关知识融会贯通,助你成为凤毛麟角的高级程序员的必备神书。如果你研究和领会了这本书里的概念,你将开始成为极少数的“牛人”!
推荐阅读
本书是一本将计算机软件和硬件理论结合讲述的经典教程,内容覆盖计算机导论、体系结构和处理器设计等多门课程。卡内基-梅隆大学、北京大学、上海交大等国内外众多知名高校选用指定教材。本书的最大优点是为程序员描述计算机系统的实现细节,通过描述程序是如何映射到系统上,以及程序是如何执行的,使读者更好地理解程序的行为,以及造成效率低下的原因。从程序员的角度来学习计算机系统是如何工作的会非常有趣。最理想的学习方法是在真正的系统上解决具体的问题,或是编写和运行程序。这个主题观念贯穿本书始终。
02
计算机系统解密
从理解计算机到编写高效代码
作者:[美]乔纳森·E.斯坦哈特(Jonathan E. Steinhart )
译者:张开元、张淼
计算机程序硬件软件从底层实现到高层展现原理讲解
对底层知识的多个主题进行了公平的覆盖
推荐阅读
计算机编程不是抽象的,程序是在机器上运行的。了解计算机如何工作以及程序如何在计算机上运行是成为一名更好的程序员的必要条件。在本书中,资深工程师Jonathan E. Steinhart深入探讨了计算机背后的基础概念,比如计算机硬件,软件在硬件上的行为,如何编写高效的程序,计算机安全基础知识,以及在编写代码时需要考虑的现实问题。本书对底层知识的多个主题进行了公平的覆盖——介绍有助于提高整个系统质量的许多领域的知识(包括计算机硬件、组合逻辑、时序逻辑、计算机体系结构、计算机组成原理、操作系统、系统程序设计等)。
03
编程原则
来自代码大师Max Kanat-Alexander的建议
作者:[美]马克斯·卡纳特-亚历山大(Max Kanat-Alexander)
译者:李光毅
编程大师向你展示如何让简约设计的思想回归到计算机编程中
推荐阅读
在本书中,富有传奇色彩的编程大师马克斯·卡纳特-亚历山大(Max Kanat-Alexander)将会向你展示如何让简约设计的思想回归到计算机编程中。马克斯会解释程序员为何会感到力不从心,以及应该如何持续改善。世界上存在太多复杂的事物。复杂并不可取,因为它会给我们的工作带来隐患。
马克斯从他久负盛名的技术博客CodeSimplicity中精选了一部分文章,对如何在软件行业工作以及取得成功给出了自己的想法和建议。相信这43篇文章能够让你学会如何在工作中避免复杂,拥抱简约,从而让你的职业生涯更加顺利和成功。
资讯 |《Java核心技术》基于Java 17全面升级!
干货 |再见了Java8,Java17:我要取代你
资讯 | Java核心技术大会2022 · 重磅发布
新书 | 红蓝攻防:构建实战化网络安全防御体系
每周赠书 | 【第112期】一些可以显著提高 Java 启动速度方法
书评 | 运营其实很重要
点击阅读全文购买