如何看待 2021.07.13 B 站崩溃事件

2022-07-15 08:39:10 +08:00
 Stendan

分析报告: https://www.bilibili.com/read/cv17521097

15062 次点击
所在节点    哔哩哔哩
103 条回复
Sixyuan
2022-07-15 17:51:03 +08:00
重点是,op 为什么不发表自己的看法?我认为这是交流的前提。
vision4fun
2022-07-15 17:54:58 +08:00
领导,人不够,加点人吧!
LeegoYih
2022-07-15 17:56:03 +08:00
草台
Tussik
2022-07-15 17:56:09 +08:00
我昨天在哔哩哔哩节点下也发了相关帖子,楼里关于测试的部分讨论我觉得还挺有意思的,大家有兴趣可以看看
https://v2ex.com/t/866226
NiZerin
2022-07-15 17:59:00 +08:00
简单的说就是:弱类型的锅
frostnotfall
2022-07-15 18:01:39 +08:00
根本原因是 lua 传参时传 0 导致异常。

“_gcd 函数对入参没有做类型校验,允许参数 b 传入:"0"。同时因为"0" != 0 ,所以此函数第一次执行后返回是 _gcd("0",nan)。如果传入的是 int 0 ,则会触发[ if b == 0 ]分支逻辑判断,不会死循环。”

说实话,lua 语言欠缺的恰恰就是种种类似这样的小细节,也是服务端没有大规模用起来的原因。比如用默认的排序、遍历这些,都需要额外的逻辑来处理,所用不所见,所见不所得。

openresty 将 lua 集成进 Nginx 无疑是非常方便的,开发速度嘎嘎高。曾经需要在 L7 层做加解密逻辑,一天半的时间,从了解 Lua 到代码完成并测试。速度是真的快。

但是 lua 毕竟是缝合进 Nginx 的,天生就不会 100%完全匹配,再加上 lua 的种种小问题,总有种那着精致的小手枪上战场的赶脚。
salmon5
2022-07-15 18:04:18 +08:00
b 站和美团、58 技术就查很远,渣渣
flyqie
2022-07-15 18:34:35 +08:00
@frostnotfall

B 站的事跟 lua 没太大关系吧。

这个应该属于弱语言通病,真打算扯到 lua 的话。。难道说应该直接报错而不是返回 nan ?
flyqie
2022-07-15 18:38:45 +08:00
@flyqie

弱语言 -> 弱类型语言
frostnotfall
2022-07-15 19:04:17 +08:00
@flyqie #88 不好意思,的确看错了,这里是 lua-resty-balancer 的代码不是 lua 的代码,看的时候跑偏了因为前面说是 jit bug 。
xiangyuecn
2022-07-15 19:05:44 +08:00
跟 弱类型语言 不弱类型语言 的 没有任何关系。该死循环的时候,换什么语言 谁都跑不掉🐶🐶
Pythoner666666
2022-07-15 19:19:17 +08:00
@mmnnyycc “根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据(即 “0”)” 这个如果是真的那么说明 写这段代码的人使用 redis 的经验欠缺,因为从 redis 取值 无论是什么数据类型,取出来的值都是 string 。反之这句话就是假的
evilStart
2022-07-15 19:26:27 +08:00
@shyrock 啊这,b 站也算大厂啊
frostnotfall
2022-07-15 19:30:20 +08:00
@flyqie #90 但紧接而来的问题就是,lua 函数的实现,没有指定传入参数的类型?
Ansen
2022-07-15 20:09:16 +08:00
不看 B 站
jqsl2012
2022-07-15 20:14:09 +08:00
B 站是什么
HankLu
2022-07-15 20:15:12 +08:00
不要递归不要递归不要递归
omnip
2022-07-15 20:55:02 +08:00
没人注意到最后一句话么:多活的高可用容灾架构确实生效了。 [doge]
flyqie
2022-07-15 21:03:42 +08:00
@frostnotfall

没记错的话,貌似是这样的。

好像没办法指定类型。
liuxu
2022-07-15 22:00:17 +08:00
代码出的 bug ,老运维来了也没用,哪怕运维能审核代码,lua 这个 nan 的坑该出问题还是的出

注册中心、自建机房、嫌架构原始的、人员投入不够什么的,这些都是虚的,像 google 、cloudflare 这种不一样该崩还是崩,还有说弱类型语言不行,那强类型语言写的东西不也是 bug 一堆

这个事故只有一个问题,就是拿到 prof 跑的火焰图却不知道怎么分析导致的后面扯的一堆,递归错误从火焰图来看一定是不断重复调用一个方法,哪怕动态解释型语言也会重复一部分代码,对着反推就行了

这个事故出了第一件事应该 top 看哪个进程出了问题,第二件事就是 strace 到进程看看输出,卡到哪里了,然后才会 prof 输出和火焰图,最后再不济 gdb 上去分析,也别说什么生产上 gdb 不合规,生产都崩成这样了,任何能有效恢复服务的分析方式都是正确的方式

看看这报告也说“我们的事件分析平台目前只提供了面向应用的事件查询能力,缺少面向用户、面向平台、面向组件的事件分析能力”,说白了这个事情就是组件底层代码分析能力不够


这也说明了生产环境添加编译调试信息的重要性,像《高性能 mysql 》里面讲的,给生产环境 mysql 添加调试信息,哪怕增加 20%的 cpu 损耗,但是到了出问题分析的时候,绝对会觉得这 20%花的值

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/866300

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX