B 站崩了，總結(jié)下「高可用」和「異地多活」

一、背景

不用想象一種異常場景了，這就真實發(fā)生了：B 站昨天晚上 11 點突然掛了，網(wǎng)站主頁直接報 404。

手機(jī) APP 端數(shù)據(jù)加載不出來。

23：30 分，B 站做了降級頁面，將 404 頁面跳轉(zhuǎn)到了比較友好的異常頁面。

但是刷新下頁面，又會跳轉(zhuǎn)到 404 頁面。

22：35 主頁可以加載出數(shù)據(jù)了，但是點擊動態(tài)還是會報 502

點擊某個視頻，直接報 404。

2021-07-14 02:00 之后 B 站開始逐漸恢復(fù)。

二、什么原因

今日凌晨 2 點，B 站發(fā)布公告稱，昨晚，B 站的部分服務(wù)器機(jī)房發(fā)生故障，造成無法訪問。技術(shù)團(tuán)隊隨即進(jìn)行了問題排查和修復(fù)，現(xiàn)在服務(wù)已經(jīng)陸續(xù)恢復(fù)正常。而針對網(wǎng)友傳言的 B 站大樓失火一事，上海消防官博進(jìn)行了辟謠，B 站大樓并未出現(xiàn)火情。

看來 B 站的高可用并不令我們滿意。接下來我們來探討下什么是高可用以及跨機(jī)房部署的思路。本篇正文內(nèi)容如下：

三、到底什么是高可用

經(jīng)過了 2 個小時，B 站才開始逐漸恢復(fù)，那 B 站系統(tǒng)到底算不算高可用呢？

首先高可用是個相對的形容詞。那什么是高可用呢？

3.1 高可用

高可用性（High Availability，HA）我們已經(jīng)耳熟能詳，指的是系統(tǒng)具備較高的無故障運行的能力。

B 站針對高可用架構(gòu)還做過一篇分享：

重點：以后 B 站面試這類題不考，望周知。

常見的高可用的方案就是一主多從，主節(jié)點掛了，可以快速切換到從節(jié)點，從節(jié)點充當(dāng)主節(jié)點，繼續(xù)提供服務(wù)。比如 SQL Server 的主從架構(gòu)，Redis 的主從架構(gòu)，它們都是為了達(dá)到高可用性，即使某臺服務(wù)器宕機(jī)了，也能繼續(xù)提供服務(wù)。

剛剛提到了快速，這是一個定性詞語，那定量的高可用是怎么樣的？

3.2 定量分析高可用

有兩個相關(guān)的概念需要提及：MTBF 和  MTTR。

MTBF：故障間隔時間，可以理解為從上次故障到這次故障，間隔多久，間隔的越長，系統(tǒng)穩(wěn)定性越高。

MTTR：故障平均恢復(fù)時間，可以理解為突然發(fā)生故障了，到系統(tǒng)恢復(fù)正常，經(jīng)歷了多長時間，這個時間越短越好，不然用戶等著急了，會收到很多投訴。

可用性計算公式：MTBF/（MTBF+MTTR）* 100%，就是用故障的間隔時間除以故障間隔時間+故障平均恢復(fù)時間的總和。

通常情況下，我們使用幾個九來表示系統(tǒng)的可用性，之前我們項目組的系統(tǒng)要求達(dá)到年故障時間不超過 5 分鐘，也就是五個九的標(biāo)準(zhǔn)。

3.3 定量分析 B 站

來反觀下 B 站故障了多久，2021-07-13 23:00 到 2021-07-14 02:00，系統(tǒng)逐漸恢復(fù)，如果按照年故障總時間來算的話：B 站故障超過 1 個小時了，只能算達(dá)到了三個九的標(biāo)準(zhǔn)。如果按照日故障時間來算，只能達(dá)到兩個九的標(biāo)準(zhǔn)，也就是 99% 的高可用性，有點慘...

3.4 一個九和兩個九

非常容易達(dá)到，一個正常的線上系統(tǒng)不會每天宕機(jī) 15 分鐘吧，不然真用不下去了。

3.5 三個九和四個九

允許故障的時間很短，年故障時間是 1 小時到 8 小時，需要從架構(gòu)設(shè)計、代碼質(zhì)量、運維體系、故障處理手冊等入手，其中非常關(guān)鍵的一環(huán)是運維體系，如果線上出了問題，第一波收到異常通知的肯定是運維團(tuán)隊，根據(jù)問題的嚴(yán)重程度，會有不同的運維人員來處理，像 B 站這種大事故，就得運維負(fù)責(zé)人親自上陣了。

另外在緊急故障發(fā)生時，是否可以人工手段降級或者加開關(guān)，限制部分功能，也是需要考慮的。之前我遇到過一個問題，二維碼刷卡功能出現(xiàn)故障，辛虧之前做了一個開關(guān)，可以將二維碼功能隱藏，如果用戶要使用二維碼刷卡功能，統(tǒng)一引導(dǎo)用戶走線下刷卡功能。

3.6 五個九

年故障時間 5 分鐘以內(nèi)，這個相當(dāng)短，即使有強大的運維團(tuán)隊每天值班也很難在收到異常報警后，5 分鐘內(nèi)快速恢復(fù)，所以只能用自動化運維來解決。也就是服務(wù)器自己來保證系統(tǒng)的容災(zāi)和自動恢復(fù)的能力。

3.7 六個九

這個標(biāo)準(zhǔn)相當(dāng)苛刻了，年故障時間 32 秒。

針對不同的系統(tǒng)，其實對幾個九也不相同。比如公司內(nèi)部的員工系統(tǒng)，要求四個九就可以，如果是給全國用戶使用，且使用人數(shù)很多，比如某寶、某餓，那么就要求五個九以上了，但是即使是數(shù)一數(shù)二的電商系統(tǒng)，它里面也有非核心的業(yè)務(wù)，其實也可以放寬限制，四個九足以，這個就看各家系統(tǒng)的要求，都是成本、人力、重要程度的權(quán)衡考慮。

四、如何做到高可用

高可用的方案也是很常見，故障轉(zhuǎn)移、超時控制、限流、隔離、熔斷、降級，這里也做個總結(jié)。

也可以看這篇：雙 11 的狂歡，干了這碗「流量防控」湯

4.1 限流

對請求的流量進(jìn)行控制， 只放行部分請求，使服務(wù)能夠承擔(dān)不超過自己能力的流量壓力。

常見限流算法有三種：時間窗口、漏桶算法、令牌桶算法。

4.1.1 時間窗口

時間窗口又分為固定窗口和滑動窗口。具體原理可以看這篇：東漢末年，他們把「服務(wù)雪崩」玩到了極致（干貨）

固定時間窗口：

原理：固定時間內(nèi)統(tǒng)計流量總量，超過閥值則限制流量。

缺陷：無法限制短時間之內(nèi)的集中流量。

滑動窗口原理：

原理：統(tǒng)計的總時間固定，但時間段是滑動的。

缺陷：無法控制流量讓它們更加平滑

時間窗口的原理圖在這里：

4.1.2 漏桶算法。

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

缺陷：面對突發(fā)流量的時候，采用的解決方式是緩存在漏桶中，這樣流量的響應(yīng)時間就會增長，這就與互聯(lián)網(wǎng)業(yè)務(wù)低延遲的要求不符。

4.1.3 令牌桶算法

原理：一秒內(nèi)限制訪問次數(shù)為 N 次。每隔 1/N 的時間，往桶內(nèi)放入一個令牌。分布式環(huán)境下，用 Redis 作為令牌桶。原理圖如下：

總結(jié)的思維導(dǎo)圖在這里：

4.2 隔離

• 每個服務(wù)看作一個獨立運行的系統(tǒng)，即使某一個系統(tǒng)有問題，也不會影響其他服務(wù)。

而常規(guī)的方案是使用兩款組件：Sentinel 和 Hystrix。

4.3 故障轉(zhuǎn)移

故障轉(zhuǎn)移分為兩種：

• 完全對等節(jié)點的故障轉(zhuǎn)移。節(jié)點都是同等性質(zhì)的。
• 不對等節(jié)點的故障轉(zhuǎn)移。不對等就是主備節(jié)點都存在。

對等節(jié)點的系統(tǒng)中，所有節(jié)點都承擔(dān)讀寫流量，并且節(jié)點不保存狀態(tài)，每個節(jié)點就是另外一個的鏡像。如果某個節(jié)點宕機(jī)了，按照負(fù)載均衡的權(quán)重配置訪問其他節(jié)點就可以了。

不對等的系統(tǒng)中，有一個主節(jié)點，多個備用節(jié)點，可以是熱備（備用節(jié)點也在提供在線服務(wù)），也可以是冷備（只是備份作用）。如果主節(jié)點宕機(jī)了，可以被系統(tǒng)檢測到，立即進(jìn)行主備切換。

而如何檢測主節(jié)點宕機(jī)，就需要用到分布式 Leader 選舉的算法，常見的就有 Paxos 和 Raft 算法，詳細(xì)的選舉算法可以看這兩篇：

4.4 超時控制

超時控制就是模塊與模塊之間的調(diào)用需要限制請求的時間，如果請求超時的設(shè)置得較長，比如 30 s，那么當(dāng)遇到大量請求超時的時候，由于請求線程都阻塞在慢請求上，導(dǎo)致很多請求都沒來得及處理，如果持續(xù)時間足夠長，就會產(chǎn)生級聯(lián)反應(yīng)，形成雪崩。

還是以我們最熟悉的下單場景為例：用戶下單了一個商品，客戶端調(diào)用訂單服務(wù)來生成預(yù)付款訂單，訂單服務(wù)調(diào)用商品服務(wù)查看下單的哪款商品，商品服務(wù)調(diào)用庫存服務(wù)判斷這款商品是否有庫存，如有庫存，則可以生成預(yù)付款訂單。

雪崩如何造成的？

• 第一次滾雪球：庫存服務(wù)不可用（如響應(yīng)超時等），庫存服務(wù)收到的很多請求都未處理完，庫存服務(wù)將無法處理更多請求。
• 第二次滾雪球：因商品服務(wù)的請求都在等庫存服務(wù)返回結(jié)果，導(dǎo)致商品服務(wù)調(diào)用庫存服務(wù)的很多請求未處理完，商品服務(wù)將無法處理其他請求，導(dǎo)致商品服務(wù)不可用
• 第三次滾雪球：因商品服務(wù)不可用，訂單服務(wù)調(diào)用商品服務(wù)的的其他請求無法處理，導(dǎo)致訂單服務(wù)不可用。
• 第四次滾雪球：因訂單服務(wù)不可用，客戶端將不能下單，更多客戶將重試下單，將導(dǎo)致更多下單請求不可用。

所以設(shè)置合理的超時時間非常重要。具體設(shè)置的地方：模塊與模塊之間、請求數(shù)據(jù)庫、緩存處理、調(diào)用第三方服務(wù)。

4.5 熔斷

關(guān)鍵字：斷路保護(hù)。比如 A 服務(wù)調(diào)用 B 服務(wù)，由于網(wǎng)絡(luò)問題或 B 服務(wù)宕機(jī)了或 B 服務(wù)的處理時間長，導(dǎo)致請求的時間超長，如果在一定時間內(nèi)多次出現(xiàn)這種情況，就可以直接將 B 斷路了（A 不再請求B）。而調(diào)用 B 服務(wù)的請求直接返回降級數(shù)據(jù)，不必等待 B 服務(wù)的執(zhí)行。因此 B 服務(wù)的問題，不會級聯(lián)影響到 A 服務(wù)。

熔斷的詳細(xì)原理還是可以上面提到的：東漢末年，他們把「服務(wù)雪崩」玩到了極致（干貨）

4.6 降級

關(guān)鍵字：返回降級數(shù)據(jù)。網(wǎng)站處于流量高峰期，服務(wù)器壓力劇增，根據(jù)當(dāng)前業(yè)務(wù)情況及流量，對一些服務(wù)和頁面進(jìn)行有策略的降級（停止服務(wù)，所有的調(diào)用直接返回降級數(shù)據(jù)）。以此緩解服務(wù)器資源的壓力，保證核心業(yè)務(wù)的正常運行，保持了客戶和大部分客戶得到正確的響應(yīng)。降級數(shù)據(jù)可以簡單理解為快速返回了一個 false，前端頁面告訴用戶“服務(wù)器當(dāng)前正忙，請稍后再試?！?/p>

• 熔斷和降級的相同點？
• 熔斷和限流都是為了保證集群大部分服務(wù)的可用性和可靠性。防止核心服務(wù)崩潰。
• 給終端用戶的感受就是某個功能不可用。
• 熔斷和降級的不同點？
• 熔斷是被調(diào)用方出現(xiàn)了故障，主動觸發(fā)的操作。
• 降級是基于全局考慮，停止某些正常服務(wù)，釋放資源。

五、異地多活

5.1 多機(jī)房部署

含義：在不同地域的數(shù)據(jù)中心（IDC）部署了多套服務(wù)，而這些服務(wù)又是共享同一份業(yè)務(wù)數(shù)據(jù)的，而且他們都可以處理用戶的流量。

某個服務(wù)掛了，其他服務(wù)隨時切換到其他地域的機(jī)房中。

現(xiàn)在服務(wù)是多套的，那數(shù)據(jù)庫是不是也要多套，無非就兩種方案：共用數(shù)據(jù)庫或不共用。

• 共用一套機(jī)房的數(shù)據(jù)庫。

• 不共用數(shù)據(jù)庫。每個機(jī)房都有自己的數(shù)據(jù)庫，數(shù)據(jù)庫之間做同步。實現(xiàn)起來這個方案更復(fù)雜。

  

不論使用哪種方式，都涉及到跨機(jī)房數(shù)據(jù)傳輸延遲的問題。

• 同地多機(jī)房專線，延遲 1ms~3 ms。
• 異地多機(jī)房專線，延遲 50 ms 左右。
• 跨國多機(jī)房，延遲 200 ms 左右。

5.2 同城雙活

高性能的同城雙活，核心思想就是避免跨機(jī)房調(diào)用：

保證同機(jī)房服務(wù)調(diào)用：不同的 PRC（遠(yuǎn)程調(diào)用） 服務(wù)，向注冊中心注冊不同的服務(wù)組，而 RPC 服務(wù)只訂閱同機(jī)房的 RPC 服務(wù)組，RPC 調(diào)用只存在于本機(jī)房。

保證同機(jī)房緩存調(diào)用：查詢緩存發(fā)生在本機(jī)房，如果沒有，則從數(shù)據(jù)庫加載。緩存也是采用主備的方式，數(shù)據(jù)更新采用多機(jī)房更新的方式。

保證同機(jī)房數(shù)據(jù)庫查詢：和緩存一樣，讀取本機(jī)房的數(shù)據(jù)庫，同樣采用主備方式。

5.3 異地多活

同城雙活無法做到城市級別的容災(zāi)。所以需要考慮異地多活。

比如上海的服務(wù)器宕機(jī)了，還有重慶的服務(wù)器可以頂上來。但兩地距離不要太近，因為發(fā)生自然災(zāi)害時有可能會被另外一地波及到。

和同城雙活的核心思想一樣，避免跨機(jī)房調(diào)用。但是因為異地方案中的調(diào)用延遲遠(yuǎn)大于同機(jī)房的方案，所以數(shù)據(jù)同步是一個非常值得探討的點。提供兩種方案：

• 基于存儲系統(tǒng)的主從復(fù)制，MySQL 和 Redis 天生就具備。但是數(shù)據(jù)量很大的情況下，性能是較差的。
• 異步復(fù)制的方式?；谙㈥犃?，將數(shù)據(jù)操作作為一個消息放到消息隊列，另外的機(jī)房消費這條消息，操作存儲組件。

5.4 兩地三中心

這個概念也被業(yè)界提到過很多次。

兩地：本地和異地。

三中心：本地數(shù)據(jù)中心、同城數(shù)據(jù)中心、異地數(shù)據(jù)中心。

這兩個概念也就是我上面說的同城雙活和異地多活的方式，只是針對的是數(shù)據(jù)中心。原理如下圖所示：

通過 B 站這件事情，我從中也學(xué)到了很多，本篇算是拋磚引玉，歡迎大家留言探討。

巨人的肩膀：

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