B 站崩了，总结下「高可用」和「异地多活」

你好，我是悟空。

1、背景

不用想象一种异常场景了，这就真实发生了：B 站晚上 11 点忽然挂了，网站主页直接报 404。

手机 APP 端数据加载不出来。

23：30 分，B 站作了降级页面，将 404 页面跳转到了比较友好的异常页面。

可是刷新下页面，又会跳转到 404 页面。

22：35 主页能够加载出数据了，可是点击动态仍是会报 502

点击某个视频，直接报 404。

2021-07-14 02:00 以后 B 站开始逐渐恢复。

2、什么缘由

今日凌晨 2 点，B 站发布公告称，昨晚，B 站的部分服务器机房发生故障，形成没法访问。技术团队随即进行了问题排查和修复，如今服务已经陆续恢复正常。而针对网友传言的 B 站大楼失火一事，上海消防官博进行了辟谣，B 站大楼并未出现火情。

看来 B 站的高可用并不令咱们满意。接下来咱们来探讨下什么是高可用以及跨机房部署的思路。本篇正文内容以下：

3、到底什么是高可用

通过了 2 个小时，B 站才开始逐渐恢复，那 B 站系统到底算不算高可用呢？

首先高可用是个相对的形容词。那什么是高可用呢？

3.1 高可用

高可用性（High Availability，HA）咱们已经耳熟能详，指的时系统具有较高的无端障运行的能力。

B 站针对高可用架构还作过一篇分享：

https://cloud.tencent.com/developer/article/1618923

重点：之后 B 站面试这类题不考，望周知。

常见的高可用的方案就是一主多从，主节点挂了，能够快速切换到从节点，从节点充当主节点，继续提供服务。好比 SQL Server 的主从架构，Redis 的主从架构，它们都是为了达到高可用性，即便某台服务器宕机了，也能继续提供服务。

刚刚提到了快速，这是一个定性词语，那定量的高可用是怎么样的？

3.2 定量分析高可用

有两个相关的概念须要说起：MTBF 和 MTTR。

MTBF：故障间隔时间，能够理解为从上次故障到此次故障，间隔多久，间隔的越长，系统稳定性越高。

MTTR：故障平均恢复时间，能够理解为忽然发生故障了，到系统恢复正常，经历了多长时间，这个时间越短越好，否则用户等着急了，会收到不少投诉。

可用性计算公式：MTBF/（MTBF+MTTR）* 100%，就是用故障的间隔时间除以故障间隔时间+故障平均恢复时间的总和。

一般状况下，咱们使用几个九来表示系统的可用性，以前咱们项目组的系统要求达到年故障时间不超过 5 分钟，也就是五个九的标准。

3.3 定量分析 B 站

来反观下 B 站故障了多久，2021-07-13 23:00 到 2021-07-14 02:00，系统逐渐恢复，若是按照年故障总时间来算的话：B 站故障超过 1 个小时了，只能算达到了三个九的标准。若是按照日故障时间来算，只能达到两个九的标准，也就是 99% 的高可用性，有点惨...

3.4 一个九和两个九

很是容易达到，一个正常的线上系统不会天天宕机 15 分钟吧，否则真用不下去了。

3.5 三个就和四个九

容许故障的时间很短，年故障时间是 1 小时到 8 小时，须要从架构设计、代码质量、运维体系、故障处理手册等入手，其中很是关键的一环是运维体系，若是线上出了问题，第一波收到异常通知的确定是运维团队，根据问题的严重程度，会有不一样的运维人员来处理，像 B 站这种大事故，就得运维负责人亲自上阵了。

另外在紧急故障发生时，是否能够人工手段降级或者加开关，限制部分功能，也是须要考虑的。以前我遇到过一个问题，二维码刷卡功能出现故障，辛亏以前作了一个开关，能够将二维码功能隐藏，若是用户要使用二维码刷卡功能，统一引导用户走线下刷卡功能。

3.6 五个九

年故障时间 5 分钟之内，这个至关短，即便有强大的运维团队天天值班也很难在收到异常报警后，5 分钟内快速恢复，因此只能用自动化运维来解决。也就是服务器本身来保证系统的容灾和自动恢复的能力。

3.7 六个九

这个标准至关苛刻了，年故障时间 32 秒。

针对不一样的系统，其实对几个九也不相同。好比公司内部的员工系统，要求四个九组以，若是是给全国用户使用，且使用人数不少，好比某宝、某饿，那么就要求五个九以上了，可是即便是首屈一指的电商系统，它里面也有非核心的业务，其实也能够放宽限制，四个九足以，这个就看各家系统的要求，都是成本、人力、重要程度的权衡考虑。

4、如何作到高可用

高可用的方案也是很常见，故障转移、超时控制、限流、隔离、熔断、降级，这里也作个总结。

也能够看这篇：双 11 的狂欢，干了这碗「流量防控」汤

4.1 限流

对请求的流量进行控制， 只放行部分请求，使服务可以承担不超过本身能力的流量压力。

常见限流算法有三种：时间窗口、漏桶算法、令牌桶算法。

4.1.1 时间窗口

时间窗口又分为固定窗口和滑动窗口。具体原理能够看这篇：东汉末年，他们把「服务雪崩」玩到了极致（干货）

固定时间窗口：

原理：固定时间内统计流量总量，超过阀值则限制流量。

缺陷：没法限制短期以内的集中流量。

滑动窗口原理：

原理：统计的总时间固定，但时间段是滑动的。

缺陷：没法控制流量让它们更加平滑

时间窗口的原理图在这里：

4.1.2 漏桶算法。

原理：按照一个固定的速率将流量露出到接收端。

缺陷：面对突发流量的时候，采用的解决方式是缓存在漏桶中，这样流量的响应时间就会增加，这就与互联网业务低延迟的要求不符。

4.1.3 令牌桶算法

原理：一秒内限制访问次数为 N 次。每隔 1/N 的时间，往桶内放入一个令牌。分布式环境下，用 Redis 做为令牌桶。原理图以下：

总结的思惟导图在这里：

4.2 隔离

• 每一个服务看做一个独立运行的系统，即便某一个系统有问题，也不会影响其余服务。

而常规的方案是使用两款组件：Sentinel 和 Hystrix。

4.3 故障转移

故障转移分为两种：

• 彻底对等节点的故障转移。节点都是同等性质的。
• 不对等节点的故障转移。不对等就是主备节点都存在。

对等节点的系统中，全部节点都承担读写流量，而且节点不保存状态，每一个节点就是另一个的镜像。若是某个节点宕机了，按照负载均衡的权重配置访问其余节点就能够了。

不对等的系统中，有一个主节点，多个备用节点，能够是热备（备用节点也在提供在线服务），也能够是冷备（只是备份做用）。若是主节点宕机了，能够被系统检测到，当即进行主备切换。

而如何检测主节点宕机，就须要用到分布式 Leader 选举的算法，常见的就有 Paxos 和 Raft 算法，详细的选举算法能够看这两篇：

诸葛亮 VS 庞统，拿下分布式 Paxos

用动图讲解分布式 Raft

4.4 超时控制

超时控制就是模块与模块之间的调用须要限制请求的时间，若是请求超时的设置得较长，好比 30 s，那么当遇到大量请求超时的时候，因为请求线程都阻塞在慢请求上，致使不少请求都没来得及处理，若是持续时间足够长，就会产生级联反应，造成雪崩。

仍是以咱们最熟悉的下单场景为例：用户下单了一个商品，客户端调用订单服务来生成预付款订单，订单服务调用商品服务查看下单的哪款商品，商品服务调用库存服务判断这款商品是否有库存，若有库存，则能够生成预付款订单。

雪崩如何形成的？

• 第一次滚雪球：库存服务不可用（如响应超时等），库存服务收到的不少请求都未处理完，库存服务将没法处理更多请求。
• 第二次滚雪球：因商品服务的请求都在等库存服务返回结果，致使商品服务调用库存服务的不少请求未处理完，商品服务将没法处理其余请求，致使商品服务不可用
• 第三次滚雪球：因商品服务不可用，订单服务调用商品服务的的其余请求没法处理，致使订单服务不可用。
• 第四次滚雪球：因订单服务不可用，客户端将不能下单，更多客户将重试下单，将致使更多下单请求不可用。

因此设置合理的超时时间很是重要。具体设置的地方：模块与模块之间、请求数据库、缓存处理、调用第三方服务。

4.5 熔断

关键字：断路保护。好比 A 服务调用 B 服务，因为网络问题或 B 服务宕机了或 B 服务的处理时间长，致使请求的时间超长，若是在必定时间内屡次出现这种状况，就能够直接将 B 断路了（A 再也不请求B）。而调用 B 服务的请求直接返回降级数据，没必要等待 B 服务的执行。所以 B 服务的问题，不会级联影响到 A 服务。

熔断的详细原理能够看这篇：东汉末年，他们把「服务雪崩」玩到了极致（干货）

4.6 降级

关键字：返回降级数据。网站处于流量高峰期，服务器压力剧增，根据当前业务状况及流量，对一些服务和页面进行有策略的降级（中止服务，全部的调用直接返回降级数据）。以此缓解服务器资源的压力，保证核心业务的正常运行，保持了客户和大部分客户获得正确的响应。降级数据能够简单理解为快速返回了一个 false，前端页面告诉用户“服务器当前正忙，请稍后再试。”

• 熔断和降级的相同点？
  • 熔断和限流都是为了保证集群大部分服务的可用性和可靠性。防止核心服务崩溃。
  • 给终端用户的感觉就是某个功能不可用。
• 熔断和降级的不一样点？
  • 熔断是被调用放出现了故障，主动触发的操做。
  • 降级是基于全局考虑，中止某些正常服务，释放资源。

5、异地多活

5.1 多机房部署

含义：在不一样地域的数据中心（IDC）部署了多套服务，而这些服务又是共享同一份业务数据的，并且他们均可以处理用户的流量。

某个服务挂了，其余服务随时切换到其余地域的机房中。

如今服务是多套的，那数据库是否是也要多套，无非就两种方案：共用数据库或不共用。

• 共用一套机房的数据库。

• 不共用数据库。每一个机房都有本身的数据库，数据库之间作同步。实现起来这个方案更复杂。

不论使用哪一种方式，都涉及到跨机房数据传输延迟的问题。

• 同地多机房专线，延迟 1ms~3 ms。
• 异地多机房专线，延迟 50 ms 左右。
• 跨国多机房，延迟 200 ms 左右。

5.2 同城双活

高性能的同城双活，核心思想就是避免跨机房调用：

保证同机房服务调用：不一样的 PRC（远程调用） 服务，向注册中心注册不一样的服务组，而 RPC 服务只订阅同机房的 RPC 服务组，RPC 调用只存在于本机房。

保证同机房缓存调用：查询缓存发生在本机房，若是没有，则从数据库加载。缓存也是采用主备的方式，数据更新采用多机房更新的方式。

保证同机房数据库查询：和缓存同样，读取本机房的数据库，一样采用主备方式。

5.3 异地多活

同城双活没法作到城市级别的容灾。因此须要考虑异地多活。

好比上海的服务器宕机了，还有重庆的服务器能够顶上来。但两地距离不要太近，由于发生自燃灾害时有可能会被另一地波及到。

和同城双活的核心思想同样，避免跨机房调用。可是由于异地方案中的调用延迟远大于同机房的方案，因此数据同步是一个很是值得探讨的点。提供两种方案：

• 基于存储系统的主从复制，MySQL 和 Redis 天生就具有。可是数据量很大的状况下，性能是较差的。
• 异步复制的方式。基于消息队列，将数据操做做为一个消息放到消息队列，另外的机房消费这条消息，操做存储组件。

5.4 两地三中心

这个概念也被业界提到过不少次。

两地：本地和异地。

三中心：本地数据中心、同城数据中心、异地数据中心。

这两个概念也就是我上面说的同城双活和异地多活的方式，只是针对的是数据中心。原理以下图所示：

经过 B 站这件事情，我从中也学到了不少，本篇算是抛砖引玉，欢迎你们留言探讨。

做者简介：悟空，8年一线互联网开发和架构经验，用故事讲解分布式、架构设计、Java 核心技术。《JVM性能优化实战》专栏做者，开源了《Spring Cloud 实战 PassJava》项目，自主开发了一个 PMP 刷题小程序。

我是悟空，努力变强，变身超级赛亚人！

巨人的肩膀：

http://www.passjava.cn

https://time.geekbang.org/column/article/171115

https://time.geekbang.org/column/article/140763