《高可用实战》-A站大流量导致服务崩溃异常云分析

昨天的大瓜，B站蹦了，大伙都跳起来分析了一波异常原因，着实给大伙的秋招准备了一波热乎乎的素材！在大家都在关注 B站的时候， 我大A站终于要站起来了！！！经过多方网友的极力引流，我A站也蹦了～

紧急通知： B站换域名了！！！

这里简单介绍一下 A 站发展史:

A站最初创立于2007年，是国内第一家弹幕视频网站，而且也曾经辉煌过，事实上A站在2011年之前一直都压制着B站，是当时国内最大的弹幕视频网站。

2009 - 2016 混乱的资本和人事斗争成为A站发展道路上最大的阻碍，也最终让A站逐渐走向衰落。

A站最初的“接盘侠”就是边锋网络，将“生放送”这块业务从A站独立了出来，成立了新的公司，也就是后来的斗鱼TV。

2018 被快手全资收购，苦苦经营。

A站蹦了

在广大网友的引流下，A站 迎来了一波大流量,成功把服务打挂了。但是和B站 崩溃不一样 ，大流量导致的雪崩，可以通过快速止血 ， 恢复服务，

A站崩溃分析

贴了那么多的图，下面进行一波理性分析：

• 崩溃恢复大概在一个小时（23:15-00:25） 左右
• 崩溃时页面显示正常
• 恢复后，部分能力熔断

可以比较直观的感受，A站蹦了的原因，就是由于大流量打蹦了服务，导致服务异常。

可惜了兄弟们的一波引流

CDN 蹦了

CDN 上缓存的资源主要为： H5资源 和视频. 在一开始的 A站，展示页面是长这个样子的：

可以看到， H5 页面的静态资源加载没有问题， 资源还能够访问到，这时的 CDN 还是处于正常状态, 到后面的，整个页面都蹦了，这个时候 CDN 也被打挂了。

数据库蹦了

数据库蹦，是猜测的，大流量冲击下，新用户的登录，不同类型数据的访问，导致缓存命中率大大下降，请求直接打到数据库上。 这里就会出现雪崩的第一步： DB 处理超时

服务蹦了

上面提到了 数据库超时 ,引起的服务雪崩。 是其中的一种可能，如果服务的瓶颈并不是 DB ,而是逻辑处理，数据传输等，占用的是机器CPU，IO等资源，随着流量剧增，导致机器负载过高，无法快速响应业务，也是导致服务雪崩的原因之。

这里以 A站 的视频流传输为例，OSS 响应缓慢，或者说传输带宽受限，导致请求在视频服务堆积，最终导致整个链路雪崩。 当然，其他链路也会有类似的可能。主要指标可以参考，CPU，内存和IO 的负载，接口响应耗时。

A站服务恢复

恢复效果差强人意，可以直接明了的感受到部分能力被熔断了，保障基础能力的提供.

为什么我能那么快恢复？

跟 B站 的服务崩溃不同（物理攻击）， A站 受到的影响主要是由于流量过大，导致机器负载过高，引起的雪崩。目前大部分服务，都已经上云了，好处就是，根据需求动态扩容（钱能解决的问题，都不是问题）。

1、动态扩容

通过监控可以很快定位到异常服务（负载过高）,通过定向扩容，可以减轻单机负载压力，提升集群处理能力。以刚才提到的视频服务为例, 服务器负载过高了，加机器！ OSS 带宽打满了, 充钱 ，阔大带宽！

2、限流

处理动态扩容，为了避免服务再次被打挂，很有必要加上限流,高可用三剑客之一，可以通过 网关限流，服务器限流，传输限速等多种渠道保障服务。像博主之前介绍到的 Sentinel 也提供,机器负载保护的能力，机器负载过高导致的雪崩。

3、熔断

服务熔断，是通过关闭部分能力，以保障整体链路的稳定性。下面图中，推荐系统能力可能暂时没回复，也可能是被熔断了。

整体架构可以理解为：

A站独家，五蕉必吃

好了各位，以上就是这篇文章的全部内容了，我后面会每周都更新几篇高质量的大厂面试和常用技术栈相关的文章。感谢大伙能看到这里，如果这个文章写得还不错， 求三连！！！ 创作不易，感谢各位的支持和认可，我们下篇文章见！

我是 九灵 ,有需要交流的童鞋可以 加我wx，Jayce-K,关注公众号：Java 补习课，掌握第一手资料！
如果本篇博客有任何错误，请批评指教，不胜感激 ！