B 站崩了,总结下「高可用」和「异地多活」
共 4882字,需浏览 10分钟
·
2021-07-16 20:26
一、背景
不用想象一种异常场景了,这就真实发生了:B 站昨天晚上 11 点突然挂了,网站主页直接报 404。
![](https://filescdn.proginn.com/c7438fbbe9048cfe8a6d9afba4fc4971/43b25a7d591862c18ddae3f2fa9c1c9a.webp)
手机 APP 端数据加载不出来。
![](https://filescdn.proginn.com/179c750abdfda739a5d9d4058c762072/2ce529ce758893f8998e352aa85d6a47.webp)
23:30 分,B 站做了降级页面,将 404 页面跳转到了比较友好的异常页面。
![](https://filescdn.proginn.com/47fc8c850a389c745c8a575571be9b0b/711c8897616d70b8306bdee980b622be.webp)
但是刷新下页面,又会跳转到 404 页面。
22:35 主页可以加载出数据了,但是点击动态
还是会报 502
![](https://filescdn.proginn.com/c62c0e2d989573156303d31c2fe4ac10/b5dc7c152d21d372bfbeaa103a413e10.webp)
点击某个视频,直接报 404。
2021-07-14 02:00 之后 B 站开始逐渐恢复。
二、什么原因
今日凌晨 2 点,B 站发布公告称,昨晚,B 站的部分服务器机房发生故障,造成无法访问。技术团队随即进行了问题排查和修复,现在服务已经陆续恢复正常。而针对网友传言的 B 站大楼失火一事,上海消防官博进行了辟谣,B 站大楼并未出现火情。
![](https://filescdn.proginn.com/07d4d069fdcb9ed4c3c21982b14b42e7/694ea2d220847fe2f984b3e36cac6440.webp)
看来 B 站的高可用并不令我们满意。接下来我们来探讨下什么是高可用以及跨机房部署的思路。本篇正文内容如下:
![](https://filescdn.proginn.com/6abebcb85721e37da3ee35bb1946d051/8fdeacba9b408ef489bcdeb162423c5e.webp)
三、到底什么是高可用
经过了 2 个小时,B 站才开始逐渐恢复,那 B 站系统到底算不算高可用呢?
首先高可用是个相对的形容词。那什么是高可用呢?
3.1 高可用
高可用性(High Availability,HA)我们已经耳熟能详,指的是系统具备较高的无故障运行的能力。
B 站针对高可用架构还做过一篇分享:
![](https://filescdn.proginn.com/4150b8f460ea4cc4411062797805f50d/699154403155633497bad8e51ab7a06b.webp)
重点:以后 B 站面试这类题不考,望周知。
常见的高可用的方案就是一主多从,主节点挂了,可以快速
切换到从节点,从节点充当主节点,继续提供服务。比如 SQL Server 的主从架构,Redis 的主从架构,它们都是为了达到高可用性,即使某台服务器宕机了,也能继续提供服务。
刚刚提到了快速,这是一个定性词语,那定量
的高可用是怎么样的?
3.2 定量分析高可用
有两个相关的概念需要提及:MTBF 和 MTTR。
MTBF:故障间隔时间,可以理解为从上次故障到这次故障,间隔多久,间隔的越长,系统稳定性越高。
MTTR:故障平均恢复时间,可以理解为突然发生故障了,到系统恢复正常,经历了多长时间,这个时间越短越好,不然用户等着急了,会收到很多投诉。
可用性计算公式:MTBF/(MTBF+MTTR)* 100%,就是用故障的间隔时间除以故障间隔时间+故障平均恢复时间的总和。
通常情况下,我们使用几个九来表示系统的可用性,之前我们项目组的系统要求达到年故障时间不超过 5 分钟,也就是五个九的标准。
![](https://filescdn.proginn.com/5d40d401c424e3f6bec713c08d13c718/14baf491423ed900cf2eea9c3379bd32.webp)
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 秒。
针对不同的系统,其实对几个九也不相同。比如公司内部的员工系统,要求四个九就可以,如果是给全国用户使用,且使用人数很多,比如某宝、某饿,那么就要求五个九以上了,但是即使是数一数二的电商系统,它里面也有非核心的业务,其实也可以放宽限制,四个九足以,这个就看各家系统的要求,都是成本、人力、重要程度的权衡考虑。
四、如何做到高可用
高可用的方案也是很常见,故障转移、超时控制、限流、隔离、熔断、降级,这里也做个总结。
也可以看这篇:双 11 的狂欢,干了这碗「流量防控」汤
4.1 限流
![](https://filescdn.proginn.com/6299402937852b4e75011f7109e1e2af/c1964229befa5152b01b88eeaf5bb379.webp)
对请求的流量进行控制, 只放行部分请求
,使服务能够承担不超过自己能力的流量压力。
常见限流算法有三种:时间窗口、漏桶算法、令牌桶算法。
4.1.1 时间窗口
时间窗口又分为固定窗口和滑动窗口。具体原理可以看这篇:东汉末年,他们把「服务雪崩」玩到了极致(干货)
固定时间窗口:
原理:固定时间内统计流量总量,超过阀值则限制流量。
缺陷:无法限制短时间之内的集中流量。
滑动窗口原理:
原理:统计的总时间固定,但时间段是滑动的。
缺陷:无法控制流量让它们更加平滑
时间窗口的原理图在这里:
![](https://filescdn.proginn.com/c46e7f61d10a0e0a7dd95503a0ad6ba2/46989280259b47696bc786a300f00cbc.webp)
![](https://filescdn.proginn.com/055c678f90c81718c3af49348a3fcea7/d03df12b7ca8a6eb855d11723ff93719.webp)
4.1.2 漏桶算法。
原理:按照一个固定的速率将流量露出到接收端。
缺陷:面对突发流量的时候,采用的解决方式是缓存在漏桶中,这样流量的响应时间就会增长,这就与互联网业务低延迟的要求不符。
![](https://filescdn.proginn.com/6601a4971e40babbeaee1c5e532da34d/50af068819828936606801a6fece6ff1.webp)
4.1.3 令牌桶算法
原理:一秒内限制访问次数为 N 次。每隔 1/N 的时间,往桶内放入一个令牌。分布式环境下,用 Redis 作为令牌桶。原理图如下:
![](https://filescdn.proginn.com/947fa395f7d6e3d56624b56f97f54855/dc1dbb39aa31548781418f9029ca1caf.webp)
总结的思维导图在这里:
![](https://filescdn.proginn.com/4b51cc411308ea11742edf72fe552397/3b05b795cc4812b8af878fc9af6d4a56.webp)
4.2 隔离
每个服务看作一个独立运行的系统,即使某一个系统有问题,也不会影响其他服务。
而常规的方案是使用两款组件:Sentinel 和 Hystrix。
![](https://filescdn.proginn.com/8f8558715cb2014b215327af188aefc7/0e56a394aa94ac5615c709f6d7d11721.webp)
4.3 故障转移
故障转移分为两种:
完全对等节点的故障转移。节点都是同等性质的。 不对等节点的故障转移。不对等就是主备节点都存在。
对等节点的系统中,所有节点都承担读写流量,并且节点不保存状态,每个节点就是另外一个的镜像。如果某个节点宕机了,按照负载均衡的权重配置访问其他节点就可以了。
不对等的系统中,有一个主节点,多个备用节点,可以是热备(备用节点也在提供在线服务),也可以是冷备(只是备份作用)。如果主节点宕机了,可以被系统检测到,立即进行主备切换。
而如何检测主节点宕机,就需要用到分布式 Leader 选举的算法,常见的就有 Paxos 和 Raft 算法,详细的选举算法可以看这两篇:
4.4 超时控制
超时控制就是模块与模块之间的调用需要限制请求的时间,如果请求超时的设置得较长,比如 30 s,那么当遇到大量请求超时的时候,由于请求线程都阻塞在慢请求上,导致很多请求都没来得及处理,如果持续时间足够长,就会产生级联反应,形成雪崩
。
还是以我们最熟悉的下单场景为例:用户下单了一个商品,客户端调用订单服务来生成预付款订单,订单服务调用商品服务查看下单的哪款商品,商品服务调用库存服务判断这款商品是否有库存,如有库存,则可以生成预付款订单。
雪崩如何造成的?
![](https://filescdn.proginn.com/4d4af5abe83c85a3757b33c095156a06/38b617c8424d9174fd5f67e1938d9812.webp)
第一次滚雪球:库存服务不可用(如响应超时等),库存服务收到的很多请求都未处理完,库存服务将无法处理更多请求。 第二次滚雪球:因商品服务的请求都在等库存服务返回结果,导致商品服务调用库存服务的很多请求未处理完,商品服务将无法处理其他请求,导致商品服务不可用 第三次滚雪球:因商品服务不可用,订单服务调用商品服务的的其他请求无法处理,导致订单服务不可用。 第四次滚雪球:因订单服务不可用,客户端将不能下单,更多客户将重试下单,将导致更多下单请求不可用。
所以设置合理的超时时间非常重要。具体设置的地方:模块与模块之间、请求数据库、缓存处理、调用第三方服务。
4.5 熔断
![](https://filescdn.proginn.com/f5c596d341fc55664b8dd512652f3cc8/5c2bc2783eeb2d247c44c59c5141b846.webp)
关键字:断路保护
。比如 A 服务调用 B 服务,由于网络问题或 B 服务宕机了或 B 服务的处理时间长,导致请求的时间超长,如果在一定时间内多次出现这种情况,就可以直接将 B 断路了(A 不再请求B)。而调用 B 服务的请求直接返回降级数据,不必等待 B 服务的执行。因此 B 服务的问题,不会级联影响到 A 服务。
熔断的详细原理还是可以上面提到的:东汉末年,他们把「服务雪崩」玩到了极致(干货)
4.6 降级
![](https://filescdn.proginn.com/e7e47c16cc965d4d8f242063e3bec343/edf5f309d683527e900967a5b8966236.webp)
关键字:返回降级数据
。网站处于流量高峰期,服务器压力剧增,根据当前业务情况及流量,对一些服务和页面进行有策略的降级(停止服务,所有的调用直接返回降级数据)。以此缓解服务器资源的压力,保证核心业务的正常运行,保持了客户和大部分客户得到正确的响应。降级数据可以简单理解为快速返回了一个 false,前端页面告诉用户“服务器当前正忙,请稍后再试。”
熔断和降级的相同点? 熔断和限流都是为了保证集群大部分服务的可用性和可靠性。防止核心服务崩溃。 给终端用户的感受就是某个功能不可用。 熔断和降级的不同点? 熔断是被调用方出现了故障,主动触发的操作。 降级是基于全局考虑,停止某些正常服务,释放资源。
五、异地多活
5.1 多机房部署
含义:在不同地域的数据中心(IDC)部署了多套服务,而这些服务又是共享同一份业务数据的,而且他们都可以处理用户的流量。
某个服务挂了,其他服务随时切换到其他地域的机房中。
现在服务是多套的,那数据库是不是也要多套,无非就两种方案:共用数据库或不共用。
共用一套机房的数据库。
![](https://filescdn.proginn.com/b43409335cef66d9d3ffdc9d474ba6dd/a88d7c0f2d3404800b0634f80877b3c7.webp)
不共用数据库。每个机房都有自己的数据库,数据库之间做同步。实现起来这个方案更复杂。
不论使用哪种方式,都涉及到跨机房数据传输延迟的问题。
同地多机房专线,延迟 1ms~3 ms。 异地多机房专线,延迟 50 ms 左右。 跨国多机房,延迟 200 ms 左右。
5.2 同城双活
高性能的同城双活,核心思想就是避免跨机房调用:
保证同机房服务调用:不同的 PRC(远程调用) 服务,向注册中心注册不同的服务组,而 RPC 服务只订阅同机房的 RPC 服务组,RPC 调用只存在于本机房。
保证同机房缓存调用:查询缓存发生在本机房,如果没有,则从数据库加载。缓存也是采用主备的方式,数据更新采用多机房更新的方式。
保证同机房数据库查询:和缓存一样,读取本机房的数据库,同样采用主备方式。
5.3 异地多活
同城双活无法做到城市级别的容灾。所以需要考虑异地多活。
比如上海的服务器宕机了,还有重庆的服务器可以顶上来。但两地距离不要太近,因为发生自然灾害时有可能会被另外一地波及到。
和同城双活的核心思想一样,避免跨机房调用。但是因为异地方案中的调用延迟远大于同机房的方案,所以数据同步是一个非常值得探讨的点。提供两种方案:
基于存储系统的主从复制,MySQL 和 Redis 天生就具备。但是数据量很大的情况下,性能是较差的。 异步复制的方式。基于消息队列,将数据操作作为一个消息放到消息队列,另外的机房消费这条消息,操作存储组件。
5.4 两地三中心
这个概念也被业界提到过很多次。
两地:本地和异地。
三中心:本地数据中心、同城数据中心、异地数据中心。
这两个概念也就是我上面说的同城双活和异地多活的方式,只是针对的是数据中心。原理如下图所示:
![](https://filescdn.proginn.com/1477150ba4aab5b9dc54540eb953ed8d/0327f27f94534066c34c87df165ae3f5.webp)
通过 B 站这件事情,我从中也学到了很多,本篇算是抛砖引玉,欢迎大家留言探讨。
巨人的肩膀:
https://cloud.tencent.com/developer/article/1618923
https://mp.weixin.qq.com/s/Vc4N5RcsN-K45o3VaRT4rA
https://time.geekbang.org/column/article/171115
https://time.geekbang.org/column/article/140763
www.passjava.cn
- END -
如果文章对你有帮助,请各位同学 点赞 转发 收藏 三连,你的支持是对我莫大的鼓励~