世界領先！一文詳解螞蟻金服自研資料庫OceanBase的高可用及容災方案
小螞蟻說：
關於螞蟻金服自研的金融級分散式關係型資料庫OceanBase的故事相信大家已經不再陌生了（新來的同學可以移步《厲害了，螞蟻金服！創造了中國自己的資料庫OceanBase》了解更多~）。其中OceanBase的大規模金融級的高可用及容災能力深入人心，那麼它究竟是怎麼做到的呢？
本文用較為詳盡的篇幅分別為大家總結和回顧了傳統資料庫產品常用的高可用及容災方案，並以此為基礎深度解讀了基於OceanBase最佳實踐的分散式資料庫的高可用及容災方案。一起來學習一下吧~！
此外，歡迎關注螞蟻金服自研的金融級分散式關係型資料庫OceanBase的獨家微信公眾號，了解更多信息！▼▼
前言
眾所周知，作為生產系統中極為關鍵的核心軟體，資料庫產品的高可用性一直是使用者極為關注的功能點。尤其是在金融這樣一個特殊的領域裡，無論是從監管的要求來看，還是從業務需求本身來看，都需要提供24*7持續不間斷的服務，這就對金融行業中資料庫產品的高可用性提出了很高的要求，不但需要應對個別硬體故障的情況，還必須能夠應對機房整體故障和城市災難等極端情況，保證資料庫在各種意外情況下都能持續提供服務，即具備機房級容災能力和城市級容災能力。
本文的主要目的，是總結和回顧一下傳統資料庫產品常用的高可用及容災方案，並向讀者介紹一下以OceanBase為代表的分散式資料庫常用的方案，希望能夠起到拋磚引玉的作用，引發讀者關於新型分散式架構下高可用及容災方案的思考。
傳統商業資料庫的高可用方案
首先，我們回顧一下傳統的關係型資料庫產品（如Oracle、DB2等）常用的高可用及容災技術。我們知道，傳統資料庫產品最初都是單點架構，並不具備高可用設計，更多的是基於高端硬體產品滿足「硬體可靠」的假設。隨著時間的推移，傳統資料庫產品先後推出了採用「主從複製」架構的高可用方案，比如Oracle的Data Guard技術和DB2的HADR技術，其主要思路是：在原有的單資料庫節點（主節點）之外再增加一個對等的資料庫節點（從節點），通過資料庫層面的複製技術（通常是日誌複製）將主節點產生的數據實時複製到從節點；正常情況下從節點不提供對外服務，當主節點發生故障時，在從節點上執行「切主」動作將從節點變成主節點，繼續提供服務。
在主從節點的部署方式上，除了本地單機房部署外，往往也支持同城災備部署和異地災備部署，因此也就具備了機房級容災和城市級容災的能力。很多新興的資料庫產品（如MySQL）也是採用「主從複製」模式來實現高可用及容災特性。
除了資料庫層面的主從複製技術之外，還有一些在底層硬體上實現的高可用方案，比如在主機層面用HACMP技術以應對主機故障，或者在存儲層面採取複製技術（比如FlashCopy）來提供數據冗餘等。這些技術雖然也可以用來實現高可用和容災能力，但和應用的整合度不高，會使災難切換方案變得很複雜，並且會有相對較長的故障恢復時間（RTO），所以通常不是資料庫用戶的首選。
最後，近些年還出現了一些支持異種資料庫之間相互複製數據的產品，比如IBM CDC和Oracle Golden Gate（OGG）。這些產品的特點是比較靈活，可以支持異種資料庫之間的數據複製，也可以指定只複製資料庫中的部分對象（比如只複製指定幾張數據表的數據）。但這些產品的缺點也很明顯：首先相對於資料庫主從複製來說時延偏大，通常會達到秒級以上，而且往往做不到資料庫層面100%的完全複製。因此，這種方式通常作為不同資料庫產品之間做數據「准」實時同步的手段，而不會作為資料庫產品實現高可用及容災的手段。
稍微總結一下，傳統的資料庫產品通常會採用下面的方法實現高可用：
在主機層面實施高可用（HACMP）架構，以應對主機故障所帶來的影響（非首選方案）。
在存儲層面採用數據複製技術（比如FlashCopy）來提供數據冗餘，以應對存儲損壞所帶來的影響（非首選方案）。
在資料庫層面提供「主從複製」技術（首選方案）。
第三方數據複製產品，如CDC、OGG等（很少採用）。
通過上述的各種技術，尤其是資料庫「主從複製」技術，使得意外發生時資料庫可以在一定時間內恢復服務，並且大部分數據不會丟失，具備了一定的高可用及容災能力。但是，上面這些技術也有一些難以克服的缺點，以「主從複製」技術為例，雖然它是傳統資料庫里最先進也是最常用的高可用及容災技術，但還是有一些無法解決的問題：
通常情況下無法做到RPO=0，即主節點發生故障或者災難時有交易數據的損失。
可能有的讀者會說：你說錯了！主從複製技術也能實現RPO=0。
是的，理論上講主從複製技術是可以利用強同步模式（比如Oracle Data Guard中採用Max Protection模式，或者DB2 HADR中採用Sync模式）做到RPO=0，但實際應用中，像銀行核心系統這樣的關鍵業務里卻不會採用。為什麼呢？因為這種模式將主節點和從節點以及主從節點之間的網路環境緊緊地綁在了一起，主節點的穩定性將不再由它自己決定，而要同時看從節點和網路環境的臉色：一旦從節點或者網路環境稍微抖動一下，主節點的性能就會受到直接影響。如果主節點和從節點之間是跨機房甚至跨城市部署，發生這種問題的概率會更大，影響也會變得更加顯著。從某種程度上講，和單節點模式相比，這種模式下主節點的穩定性不但沒有增加，反而是降低了。如果有銀行的朋友在關鍵業務中應用過Oracle Data Guard或者DB2 HADR，對強同步模式所帶來的問題應該是深有體會的。
RTO相對較大，通常以十分鐘甚至小時為計算單位，會給業務帶來比較大的損失。
造成這一情況的根本原因，是「主從複製」模式下從節點不具備自動切主的能力。
由於「主從複製「模式中缺少第三方仲裁者的角色，當主從節點之間的心跳信號異常時，從節點無法靠自己判斷到底是主點故障了，還是主從之間的網路故障了。此時，如果從節點認為是主節點故障而將自己自動切換成主節點，就極容易導致「雙主」、「腦裂」（brain-split）的局面，對用戶來說這是絕對無法接受的結果。所以資料庫「主從複製」技術從來不會提供「從節點自動切換為主節點」的功能，一定要由「人」來確認主節點確實故障了，並手工發起從節點的切主動作，這就大大增加了系統恢復的時間（RTO）。
聊完了傳統資料庫的高可用技術，我們再來看看另一種逐漸被越來越多的技術廠商所採用的技術，那就是分散式多副本數據一致性技術，通常是基於Paxos協議或者Raft協議來實現。這種技術會將數據保存在多份副本上，每一次對數據的修改操作都會強同步到多數派副本上，在保證了數據冗餘的同時，不再像「主從複製」技術那樣依賴某個數據節點的穩定性，從而消除了傳統主從複製技術下從節點給主節點帶來的風險。同時，在主節點故障的情況下，其餘節點會自動選舉出新的主節點以實現高可用（個別從節點故障則完全不影響服務），整個過程非常快速且完全無需人工干預。因此，這種技術不僅能保證RPO=0，而且大大減小了RTO，相比傳統「主從複製」技術來說可以提供更強大的高可用能力。
此外，為了抵禦機房級災難和城市級災難，可以將多份副本分散部署在多個機房裡甚至多個城市中，以避免機房級災難或者城市級災難損毀多數派副本。這樣就具備了機房級容災和城市級容災的能力，進一步加強了高可用的能力。
（P.S. 關於傳統數據技術和分散式技術在高可用方面的對比，我強烈推薦OceanBase創始人陽振坤老師的兩篇文章：《傳統關係資料庫高可用的缺失》和《大師專欄 | 如何在「不可靠」硬體上實現金融級高可用？》。這兩篇文章裡面有非常精闢的論述，相信大家讀完之後肯定會有更全面的認識。）
OceanBase常用的高可用及容災方案
OceanBase資料庫從誕生之初，就利用Paxos協議在底層實現了多副本數據一致性，具有上述「RPO=0、低RTO（通常在30s以下）、故障時自動切換」的優勢。而經過多年實際應用場景的歷練後，尤其是像支付寶、淘寶、網商銀行這種高並發、高訪問量、24*7持續交易場景的磨練，OceanBase資料庫已經摸索出一套完整的、經過實踐檢驗的高可用及容災方案。下面我們就結合OceanBase資料庫的實踐經驗，向大家介紹一下分散式數據常用的一些高可用及容災方案。
特別說明一下，在後文的示意圖中會有一些經常用到的名詞，在此先做個簡單的說明，以方便大家理解：
OBServer
一個OBServer指的是一個獨立提供服務（share-nothing）的OceanBase資料庫節點，這是一個軟體層面的定義。但通常一台物理伺服器上只有一個OBServer，因此也可以認為一個OBServer等同於OceanBase資料庫集群的一個物理節點。
Zone
這是OceanBase資料庫的一個內部概念。一個Zone是一個或者一些OBServer組成的邏輯集合，一個Zone里的所有OBServer都在一個機房內。
從分散式多副本數據一致性協議的角度來看，可以認為一個Zone就是OceanBase資料庫集群的一個「副本」，如果是三副本架構那就會有三個Zone。
IDC
IDC就是大家通常理解的「機房」的概念，一個IDC就代表一個機房。
1.1單機房3副本
這是最簡單的一種方案，在一個機房內找足夠多的機器，把它們劃分成3個Zone，每個Zone里一份副本。
這種方案具備一定程度的高可用能力，可抵禦個別硬體故障，比如在個別伺服器宕機、個別硬碟損壞等情況下，資料庫集群還能持續提供服務。此外，這種方案具有部署方便，成本低的特點，只要有一個機房，機房內有足夠多的聯網機器，就可以部署了。
但這種方案也有一個非常明顯的劣勢：不具備容災能力。如果發生機房級災難或者城市級災難，首先會導致交易停止，而極端情況下（比如機房所有機器損毀）甚至會導致數據丟失。
綜合來看，這種方案雖然部署方便，也具備高可用特性，但其容災的能力卻是最低的，對於具有容災要求的系統來說顯然是不適合的。如果用戶的硬體條件有限，只能提供一個機房，並且用戶對系統的容災能力沒有要求，那麼這種方案是一個非常合適的選擇。
1.2 同城3機房3副本
同樣是一個城市內部署3副本，這種方案相對於「單機房3副本」來說就更進了一步：在同一城市內找3個不同的機房，每個機房內部署1個Zone（1份副本），形成一個跨機房部署的資料庫集群。
由於分散式多副本數據一致性協議要將每一個事務的數據強同步到多數派副本中，這種部署模式下必然導致頻繁的跨機房同步操作。為了保證資料庫的寫性能，對機房之間的網路質量有比較高的要求，通常要求任何兩個機房之間的網路時延不超過2毫秒（ms）。（P.S. 後面所有關於「同城機房」的描述中，默認都有類似的網路要求，後文就不再贅述了）
相對於「單機房3副本」來說，這種方案的優勢是很明顯的：除了可以抵禦個別硬體故障，還可以抵禦機房級災難：任何一個機房遇到災難，都不會導致交易停止或者數據丟失。
不過，並不是每一個用戶都能夠提供「同城三機房」的部署條件。即使是高端企業級用戶，往往也只具備同城2機房（主機房+同城災備機房）的條件，因此3機房對用戶的基礎設施來說提出了一定的挑戰，也增加了用戶的部署成本。如果考慮到上面說的任意2個機房之間都要做到「網路低延時」，那成本會進一步增加。因此，在考慮這種部署方案時，要事先和用戶做好充分的溝通，確保用戶能提供符合要求的基礎設施。最後還要指出的一點就是，這種方案仍然不具備城市級容災的能力，如果發生城市級災難，還是會導致交易停止，甚至有數據丟失的風險。
綜合來看，如果用戶能夠提供同城3機房的硬體設施，並且沒有城市級容災的要求，那麼推薦使用這種方案，可以在城市內提供非常好的高可用及容災能力。事實上，OceanBase資料庫的一些外部企業級客戶就是採用了這種部署方式，收到了很好的效果。
如果用戶暫時只具備同城2機房的條件，那麼可以考慮在城市內租借一個機房以滿足「同城3機房」的條件，其成本相對於建設一個全新IDC來說還是低了很多。甚至可以只為個別資料庫集群租借一個同城機房內的部分機櫃，這樣就進一步降低了成本，對企業級用戶來說這個成本應該還是在可接受範圍內的。
1.3 3地3機房5副本
前面介紹的幾種方案中，提到了機房內高可用能力和機房級容災能力，但是都無法抵禦城市級災難。下面向大家介紹一種具備城市級容災能力的方案：3地3機房5副本方案。
這種方案相對來說要複雜一些。首先需要有3個城市，每個城市各有1個機房，利用這3個機房組成一個跨機房部署的OB集群。其次，和前面「同城3機房3副本」的方案類似，這種方案對不同機房間的網路質量是有一定要求的，通常來說需要滿足下面的條件：
1）有2個城市的距離相對較近（比如杭州和上海），它們之間的網路時延低於10毫秒（ms）。這2個城市的機房中各部署2個Zone（副本）。
2）第3個城市和前兩個城市的距離相對較遠（比如深圳），它和前2個城市之間的網路時延應保證在30毫秒（ms）內。這個城市的機房內部署1個Zone（副本）。
在這種部署模式中，距離較近的2個城市有2個IDC，合計4份副本，構成了Paxos協議要求的多數派，因此日常寫交易中的強同步操作會集中在這2個城市中，不會涉及到距離較遠的第3個城市，有效避免了遠距離RPC對交易性能帶來的影響。如果2個距離較近的城市中有任何一個Zone發生故障，剩下的3個Zone依舊構成多數派，還是不會涉及到距離較遠的第3個城市，性能不會受到影響。如果這2個城市中有1個城市發生了機房級災難或者城市級災難，剩下的1個城市和距離較遠的第3個城市合在一起還有3個Zone，依舊構成多數派，還是可以繼續提供服務，但此時遠距離RPC操作將不可避免，性能也會因此而受到影響。因此，這種方案可以全方位抵禦個別硬體故障、機房級災難和城市級災難，提供最高級別的高可用性，使數據安全性得到了最大程度的保障。
不過，這種方案雖然能夠提供全面的數據安全性保護，在實際部署中也會面臨一些問題和挑戰。首先，需要在3個城市內各有一個機房，3個城市之間要滿足「2近1遠」，而且相互之間的網路時延也要滿足一定條件（詳見前文描述），可以說這對用戶的基礎設施條件提出了非常大的挑戰，即使對高端企業級用戶來說，也很難滿足這個條件，最多只具備2地3機房的條件。另外，5副本相對於3副本來說增加了2個副本，進一步提高了硬體成本，也加大了這個方案的難度。
在實際應用中，如果用戶對SLA提出了最高要求，需要抵禦機房級災難和城市級災難，並且希望做到「RPO=0、低RTO、故障時自動切換」，那麼此方案將是不二之選。事實上，網商銀行的資料庫集群部署就是採用這種架構，支付寶中的部分核心數據也是採用了這種架構，它們為業務提供了最佳的數據安全性保障。
對國內的企業級用戶來說，在短期內恐怕還很難滿足這種方案的基礎設施要求。但目前只有3城市的部署架構才能在城市級災難時做到「RPO=0、低RTO、故障時自動切換」，因此從長遠考慮可以在基礎設施層面提前有所規劃。
1.4 同城2機房3副本
前面介紹過，如果只需滿足機房級容災的要求，那麼可以考慮「同城3機房3副本」的方案，以抵禦個別硬體故障和機房級災難。但由於歷史原因，很多企業用戶都建設了「同城2機房（主機房+同城災備機房）」的基礎設施，卻很少有用戶具備「同城3機房」的條件。此時雖然可以租用一個同城機房來滿足3機房條件，但如果用戶真的找不到合適的第3機房，是否就不能在2機房中部署OceanBase資料庫集群了呢？
其實，這種情況下還是可以利用2機房來完成部署的，只要在主機房中部署2個Zone，同城災備機房中部署1個Zone，就構成了一個跨機房部署的資料庫集群。
這種部署模式下，主機房內的2個Zone構成了多數派，因此日常的寫交易都會在主機房內部完成數據強同步，可以保證最佳性能。同時，這種方案也可抵抗個別硬體故障，如個別伺服器宕機、個別硬碟損壞等情況。
但如果主機房發生機房級災難，那麼整個資料庫集群只剩下同城災備機房的1個Zone，不再滿足多數派條件，無法繼續提供服務。因此這種方案是不能抵禦機房級災難的，只是在同城災備機房中保留了一份數據，以後可以將數據恢復出來（但RPO>0，數據會有少量丟失），避免了數據全部丟失的情況。
綜合來看，「同城2機房」的條件下，如果擁有多數派副本的機房（通常是主機房）發生災難，剩下的一個機房無法單獨提供服務（這是由分散式多副本數據一致性協議的理論所決定的）。從高可用的角度來看，這種方案不具備機房級容災的能力，只是避免了數據全部丟失的風險，這個結果大大降低了同城災備機房的實際意義。
在實際應用中，OceanBase資料庫基本不會採用這種方案。相比之下，「同城3機房3副本」方案具備提供機房級容災的能力，能提供更強的高可用性，是一個更好的選擇。考慮到增加第3個機房為用戶帶來的額外成本，OceanBase資料庫還提供了「日誌副本」技術：用戶可以在已有的2個機房中各部署1個普通副本，在第3個（新增加的）機房中部署1個日誌副本。相對於普通副本來說，日誌副本可以顯著降低存儲成本，這樣可以在完全不影響RPO的情況下降低第3個機房的擁有成本，減小了用戶部署第3個機房的難度。
1.5 2地3機房5副本
前面介紹過，「3地3機房5副本」的方案可以提供最高級別的高可用性，可以抵禦個別硬體故障、機房級災難和城市級災難等各種情況。但我們同時也提到了，傳統企業用戶很少能滿足「3地3機房」的要求，很多企業用戶只具備 「2地3機房（主機房+同城災備機房+異地災備機房）」的條件。那麼這種情況下，分散式資料庫是否能利用「2地3機房」完成部署呢？
事實上，這種情況下OceanBase也可以完成資料庫集群的部署，只要在主機房和同城災備機房中各部署2個Zone，在異地災備機房中部署1個Zone，就構成了一個跨機房部署的資料庫集群。
從架構上看，這種部署方案和「3地3機房5副本」方案有類似之處，可以抵禦個別硬體故障和機房級災難（讀者可參照前面「3地3機房5副本」方案的描述做推理，具體過程這裡就不詳述了）。
但是和「3地3機房5副本」相比，這種方案缺少了城市級容災的能力：一旦主機房和同城災備機房所在的城市發生災難，剩下的異地災備機房只有1個Zone，不再滿足多數派條件，無法繼續提供服務，只是在異地災備機房中保留了一份數據，以後可以將數據恢復出來（但RPO>0，數據會有少量丟失），避免了數據全部丟失的情況。
綜合來看，「2地3機房」的條件下，如果擁有主機房和同城災備機房的城市發生災難，剩下的一個城市無法單獨提供服務。從高可用的角度來看，這種方案不具備城市級容災的能力，只是避免了數據全部丟失的風險，這個結果大大降低了異地災備機房的實際意義。
在實際應用中，OceanBase資料庫基本不會採用這種方案。相比之下，「3地3機房5副本」方案具備城市級容災的能力，能提供更強的高可用性，是一個更好的選擇。此外，還可以進一步利用前文提到的「日誌副本」技術：用戶可以在已有的2個城市中各部署2個普通副本，在第3個（新增加的）城市中部署1個日誌副本，這樣可以在完全不影響RPO的情況下降低第3個城市中機房的擁有成本，減小了用戶在第3個城市中部署機房的難度。
最後，如果用戶實在無法找到第3個城市來部署機房，但同時可以接受「發生城市級災難時RPO>0」的代價，那麼可以在兩個城市之間採取「集群間數據複製」的方法（後文有詳細的介紹）。這種方式的弊端很明顯，遇到城市級災難時會有「RPO>0，不能自動切主導致RTO較長」的問題，但它可以利用2個城市實現城市級（有損）容災，減小了部署的難度。如果採用此方案的話，「主」城市應該採用「同城3機房3副本」的架構，以提供機房級容災的能力。
1.6 集群間數據複製
這種方案類似傳統資料庫的「主從複製」方案，通過數據複製軟體將一個OceanBase資料庫集群的數據複製到另一個（或者多個）OceanBase資料庫集群，以應對單個OceanBase資料庫集群的故障。通常來說，不同的OceanBase資料庫集群會部署在不同的IDC中，以應對機房級災難和城市級災難。
這種方式主要是為了應對以下幾種情況：
只有2個機房的條件下，希望能夠具備機房級容災的能力。
只有2個城市有機房的條件下，希望能夠具備城市級容災的能力。
此時，分散式多副本數據一致性協議便無法滿足需求，比如前面提到過的：「同城2機房3副本」的方案無法抵禦機房級災難，「2地3機房5副本」的方案無法抵禦城市級災難。而採用傳統資料庫的「主從複製」模式（準確地說，是它的一個變種），則能滿足這類需求。
不過，這種方案的弊端也是很明顯的。首先，和傳統資料庫一樣，具有「RPO>0，不能自動切主導致RTO較長」的問題，其次這種部署方式下數據的副本數達到了6個，成本也比較高。
綜合來看，這種模式只適用在「用戶實在無法滿足機房配置要求，但又希望具備機房級容災和城市級容災能力」的特殊場景下。我們前面提到過，由於歷史原因，不少企業級用戶恰恰是有這種需求：希望用同城2機房的部署實現機房級容災能力，用2地3機房的部署實現城市級容災能力。因此，如果用戶能接受此方案的各種弊端（RPO>0，RTO較長，副本數過多），就可以用這種方案實現高可用及（有損）容災能力。
總結
通過前面對幾種方案的詳細闡述，相信大家已經對OceanBase及分散式資料庫的高可用和容災方案有了大致的了解。說來說去，核心思想就是要充分利用分散式多副本數據一致性協議的原理，並結合各種意外情況的具體特點（個別硬體故障？機房級災難？還是城市級災難？），找到對應的解決之道。如果客戶的基礎設施條件有限，不能滿足分散式多副本數據一致性協議的部署要求，那麼可以考慮引入其它方式，比如集群間數據複製。
下面的表格中，將上面幾種方案做了一個總結，方便讀者參考：
大體來講，針對不同的具體情況，下面幾種方案都滿足了「RPO=0、低RTO、故障時自動切換」的要求，而且在技術上沒有明顯的缺陷，應該作為高可用及容災方案的首選：
單機房3副本方案
如果沒有任何機房級容災或者城市級容災的要求，只有最簡單的高可用要求，那麼這種簡單易行的部署方案是再好不過了。
同城3機房3副本方案
如果有機房級容災的要求，但沒有城市級容災的要求，那麼這種方案是最佳選擇。
如果用戶只有同城2機房而沒有建設第3機房，可以考慮在同城內租借一個機房（甚至只租借部分機櫃）來滿足3機房的條件，並可以利用OceanBase的「日誌副本」技術降低部署難度。
3地3機房5副本方案
如果既有機房級容災的要求，也有城市級容災的要求，那麼這種方案能全部滿足，提供最高級別的高可用性。
如果用戶的基礎設施條件有限，無法滿足上面幾種方案的要求，但同時又要求機房級容災能力或者城市級容災能力，應考慮「集群間數據複製」方案。
最後，也必須意識到技術在不斷進步，OceanBase在不斷進步，用戶的IT建設也在不斷進步。今天的最佳方案也許明天就能找到更好的替代者，因此我們必須以發展的眼光持續進化我們的技術方案，才能讓OceanBase的用戶在未來有更多更好的選擇。在這個過程中，我們也非常希望和業界的朋友及廣大用戶有更多的技術交流和思想碰撞，共同推進分散式資料庫技術下高可用及容災方案的發展，謝謝！
交流社區
TAG:螞蟻金服科技 |