世界領先！詳解螞蟻金服自研資料庫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的使用者在未來有更多更好的選擇。在這個過程中，我們也非常希望和業界的朋友及廣大使用者有更多的技術交流和思想碰撞，共同推進分布式資料庫技術下高可用及容災方案的發展，謝謝！

交流社群

掃描下方二維碼聯系螞蟻金服加群小助手，快速加入OceanBase資料庫技術交流群，來和螞蟻金服一線OceanBase技術人員還有其他小夥伴們一起讨論交流~！