如何看待 2021.07.13 B 站崩溃事件

[Stendan]

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

[Zerek]

7 月 13 ？定眼一看哦。。。2021

[wanacry]

昨天我家里的洗衣机修好了

[wangyzj]

这个文章就说明 B 站最基本的运维流程都没有，还是几个关键人物在支持，核心组件没有冗余，问题还很多

但归根结底，搞运维嘛
没事的时候你是成本
有事的时候是你的责任
给运维花钱总觉得亏得慌
又让马儿跑，又不给吃草
做得好是让自己失业，做的不好就得背锅一样失业

总之，运维，都这个 B 样

[abuabu]

为什么一个很好能够讨论技术的帖子会被冷嘲热讽？

[lookStupiToForce]

v2 上还有玩鄙视链的
真是有人的地方就有恶臭的圈子习气

[nyakoy]

堪称精彩，但是代码得防御边界做的如此弱确实没想到

[Baloneo]

要么用电脑看 要么手机看

[crazytudou]

逼乎：你怎么看？

[mmnnyycc]

@qping #18 openresty 商业公司，春哥说的 100%无侵入式的

[mmnnyycc]

几分钟前章亦春说的原话：
B 站这两天发表了一篇总结去年那场大事故的文章： https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg 当时我们 OpenResty Inc 公司团队帮助 B 站在线上快速定位了导致 CPU 100% 的 Lua 代码路径。B 站是我们的 OpenResty XRay 产品的商业客户。

文中提到的 Lua 火焰图就是 OpenResty XRay 在 B 站生产服务器上采样有问题的 OpenResty 服务进程得到的。生成火焰图也就花了几分钟的时间，因为使用 100% 非侵入的动态追踪技术，并不需要对 B 站的进程进行任何修改。根据 Lua 火焰图最终确认根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据（即 “0”），而 Lua 代码期望的是数值类型的权重值，从而导致了无限递归和无限循环。文中提到的 LuaJIT 的 JIT 编译器的问题其实并不存在； JIT 编译器在这里并没有 bug 。

感谢 Bilibili 对我们公司产品和技术的信任和支持！当然，B 站线上系统使用的也是我们的开源 OpenResty 软件。OpenResty XRay 产品主页： https://openresty.com.cn/cn/xray/

[Morii]

@shyrock #24

要分锅的，开复盘大会。

[dxppp]

官方微信公众号也发了相同的文章
https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg

[VZXXBACQ]

技术讨论文章为什么会有这么多莫名奇妙的回复？怎么看待不是很正常吗？

弱类型真不行。

[Huelse]

LUA 这种弱类型语言在这种地方真的要命

[siweipancc]

草，又是弱类型

[edward1987]

主题值得讨论，但是能别用逼乎标题吗。。。不喜欢

[edward1987]

只要有无限递归的可能，我觉得最好都打个日志，配个上限。。。曾经也遇到过😂

[zapper]

@VZXXBACQ #52 没看出来哪里讨论技术，lz 甚至没有自己的观点。

[maguowei]

@mmnnyycc 这个有原文出处么？还是来自非公开的信息源？

[VZXXBACQ]

@zapper LZ 附上的文章是很不错的一线技术讨论，分享出来问大家如何看待有什么问题吗😂