官方自爆了！去年的B站原来是这样崩溃的……
点击蓝字
关注我们
前言
2021年7月13日晚，B站宕机的事件引起了很多人的关注，该消息迅速刷屏，甚至空降微博热搜第一。而后，许多真真假假的网传信息冒了出来，有的网友说是因为火情，有的网友则说是因为停电，最后，B站官方发布消息称，7月13日晚造成网站无法访问的原因是服务器机房发生故障。
时隔一年，官方自爆了，去年B站崩溃原来是这样的......
1.原因说明
背景
B站在19年9月份从Tengine迁移到了OpenResty，基于其丰富的Lua能力开发了一个服务发现模块，从自研的注册中心同步服务注册信息到Nginx共享内存中，SLB在请求转发时，通过Lua从共享内存中选择节点处理请求，用到了OpenResty的lua-resty-balancer模块。到发生故障时已稳定运行快两年时间。
在故障发生的前两个月，有业务提出想通过服务在注册中心的权重变更来实现SLB的动态调权，从而实现更精细的灰度能力。SLB团队评估了此需求后认为可以支持，开发完成后灰度上线。
诱因
在某种发布模式中，应用的实例权重会短暂的调整为0，此时注册中心返回给SLB的权重是字符串类型的"0"。此发布模式只有生产环境会用到，同时使用的频率极低，在SLB前期灰度过程中未触发此问题。
SLB 在balance_by_lua阶段，会将共享内存中保存的服务IP、Port、Weight 作为参数传给lua-resty-balancer模块用于选择upstream server，在节点 weight = "0" 时，balancer 模块中的 _gcd 函数收到的入参 b 可能为 "0"。
根因
Lua 是动态类型语言，常用习惯里变量不需要定义类型，只需要为变量赋值即可。
Lua在对一个数字字符串进行算术操作时，会尝试将这个数字字符串转成一个数字。
在 Lua 语言中，如果执行数学运算 n % 0，则结果会变为 nan（Not A Number）。
_gcd函数对入参没有做类型校验，允许参数b传入："0"。同时因为"0" != 0，所以此函数第一次执行后返回是 _gcd("0",nan)。如果传入的是int 0，则会触发[ if b == 0 ]分支逻辑判断，不会死循环。
_gcd("0",nan)函数再次执行时返回值是 _gcd(nan,nan)，然后Nginx worker开始陷入死循环，进程 CPU 100%。
2.问题分析
1）为何故障刚发生时无法登陆内网后台？
事后复盘发现，用户在登录内网鉴权系统时，鉴权系统会跳转到多个域名下种登录的Cookie，其中一个域名是由故障的SLB代理的，受SLB故障影响当时此域名无法处理请求，导致用户登录失败。流程如下：
事后梳理了办公网系统的访问链路，跟用户链路隔离开，办公网链路不再依赖用户访问链路。
2）为何多活SLB在故障开始阶段也不可用？
多活SLB在故障时因CDN流量回源重试和用户重试，流量突增4倍以上，连接数突增100倍到1000W级别，导致这组SLB过载。后因流量下降和重启，逐渐恢复。此SLB集群日常晚高峰CPU使用率30%左右，剩余Buffer不足两倍。如果多活SLB容量充足，理论上可承载住突发流量， 多活业务可立即恢复正常。此处也可以看到，在发生机房级别故障时，多活是业务容灾止损最快的方案，这也是故障后我们重点投入治理的一个方向。
3）为何在回滚SLB变更无效后才选择新建源站切量，而不是并行？
SLB团队规模较小，当时只有一位平台开发和一位组件运维。在出现故障时，虽有其他同学协助，但SLB组件的核心变更需要组件运维同学执行或review，所以无法并行。
4）为何新建源站切流耗时这么久？
公网架构如下：
此处涉及三个团队：
SLB团队：选择SLB机器、SLB机器初始化、SLB配置初始化
四层LB团队：SLB四层LB公网IP配置
CDN团队：CDN更新回源公网IP、CDN切量
SLB的预案中只演练过SLB机器初始化、配置初始化，但和四层LB公网IP配置、CDN之间的协作并没有做过全链路演练，元信息在平台之间也没有联动，比如四层LB的Real Server信息提供、公网运营商线路、CDN回源IP的更新等。所以一次完整的新建源站耗时非常久。在事故后这一块的联动和自动化也是我们的重点优化方向，目前一次新集群创建、初始化、四层LB公网IP配置已经能优化到5分钟以内。
5）后续根因定位后证明关闭jit编译并没有解决问题，那当晚故障的SLB是如何恢复的？
当晚已定位到诱因是某个容器IP的weight="0"。此应用在1:45时发布完成，weight="0"的诱因已消除。所以后续关闭jit虽然无效，但因为诱因消失，所以重启SLB后恢复正常。
如果当时诱因未消失，SLB关闭jit编译后未恢复，基于定位到的诱因信息：某个容器IP的weight=0，也能定位到此服务和其发布模式，快速定位根因。
3.总结
此次事故发生时，B站挂了迅速登上全网热搜，作为技术人员，身上的压力可想而知。事故已经发生，我们能做的就是深刻反思，吸取教训，总结经验，砥砺前行。
来源：哔哩哔哩技术
THE END
推荐阅读
点赞+在看 ，关注公众号回复“666”领取福利