怎麼讓b站不掛

打開知乎和頭條，b站又衝上了熱榜，此次不是煽情懷舊的跨年晚會，也不是敲鐘上市，而是「掛了」

b站的程序員跟進迅速，問題也獲得了比較快的修復。

哈哈哈，上面是熱點新聞，下面就是知識點了。 最近在學習分佈式架構，恰好看到了「兩地三中心」的高可用架構，咱們雲暢享一下，若是b站也用的是兩地三中心的架構，還會掛掉不？這裏先說明下兩個概念：RPO和RTO

• RTO (Recovery Time Objective，復原時間目標)是指災難發生後，從IT系統故障致使業務停頓之時開始，到IT系統恢復至能夠支持各部門運做、恢復運營之時，此兩點之間的時間段稱爲RTO。好比說災難發生後半天內便須要恢復，RTO值就是十二小時；

• RPO (Recovery Point Objective，復原點目標)是指從系統和應用數據而言，要實現可以恢復至能夠支持各部門業務運做，恢復得來的數據所對應時的間點。若是現時企業天天凌晨零時進行備份一次，當服務恢復後，系統內儲存的只會是最近災難發生前那個凌晨零時的資料。

啥是兩地三中心

兩地三中心架構，即生產數據中心、同城災備中心、異地災備中心的高可用容災方案。在這種模式下，兩個城市的三個數據中心互聯互通，若是一個數據中心發生故障或災難，其餘數據中心能夠正常運行並對關鍵業務或所有業務實現接管。相比同城多中心方案，兩地三中心具備跨城級高可用能力，能夠應對城市級天然災害。

兩地三中心是高可用架構的一種實現方式，它是以整個應用系統爲單位，通常來講會分爲應用和數據庫兩部分。

應用部分一般是無狀態的，這個無狀態就是說應用處理每一個請求時不須要從本地加載上下文數據。這樣啓動多個應用服務器就沒有什麼額外的成本，應用之間沒有上下文依賴，因此很容易作到多活。

數據庫須要最終持久化數據，全部的業務都要基於已有數據，數據內容在不斷髮生變化，數據庫服務有邏輯很重的上下文。所以數據庫的多活難度就大多了。

目前針對數據庫雙活的解決方案有不少種。總的來講分爲兩大類：分佈式數據庫多活方案以及傳統數據庫的雙活方案。

傳統數據庫方案

傳統數據庫如Oracle, DB2，Informix等。因爲這些數據庫自己並無在原生狀態下考慮雙活問題。所以雙活方案都是在原生體系外面經過附加解決方案來構建的。這類解決方案基本上也都是在解決一個問題：就是如何將多塊部署在不一樣數據中心上的數據盤（數據塊）邏輯上merge成一個。 從接替思路上基本上有兩種： 方法1：經過存儲設備層實現。如EMC的vplex解決方案，IBM的SVC解決方案，IBM的HyperSwap解決方案，浪潮存儲雙活方案等。都是經過存儲層來實現的。 方法2：經過分佈式文件系統實現。例如GPFS解決方案，就是屬於這一類。經過GPFS分佈式文件系統的Failure Group功能，將另外一份雙活數據同步地寫到另外一個數據中心去。 更多細節能夠看這裏 www.zhihu.com/question/48…

分佈式數據庫

目前新型的分佈式NewSQL數據庫OceanBase、TiDB、MemFireDB等，在系統設計方面就充分考慮到了多活的需求。所以原生知足。

分佈式數據庫兩地三中心建設架構基於 Raft或Paxos 算法，保證了集羣數據一致性和高可用。raft或paxos算法都是多數派協議，兩地是同城、異地，同城雙中心指在同城或臨近城市創建獨立數據中心，雙中心經過高速鏈路實時同步數據，網絡延遲相對較小，另一個數據中心在異地城市。在這種場景下，同城的兩個中心超過半數完成提交，這樣就不會由於與異地機房通信時間長而推高數據庫的操做延時。

若是同城機房有一個不可用，異地機房節點的投票就會發揮做用，那麼數據庫的服務仍然能夠正常運行，數據也未發生丟失，此時RTO=0，RPO=0。可是若是同城發生了天然災害，兩個機房均不可用，此時數據庫服務沒法提供服務，數據也會丟失，RPO就不爲零了。在此基礎上還能夠升級到三地三中心無副本，提供城市級別容災，在鄰近城市實現RPO爲零。

引用

• community.memfiredb.com/topic/28/me…
• www.zhihu.com/question/48…
• blog.itpub.net/26736162/vi…