如何基於OceanBase構建應用和資料庫的異地多活

前言

OceanBase是一個通用的分散式的關係型資料庫，有很多獨特的特點。比如資料庫的多租戶、高可用、極致彈性伸縮能力。如果把OceanBase當作單庫使用，就沒有把OceanBase的分散式優勢發揮到極致。

本文主要分享一個基於分散式架構的應用把OceanBase資料庫的分散式優勢發揮到極致所需要了解的OceanBase基礎，這也是理解螞蟻金服的基於OceanBase構建的三地五中心異地多活架構的基礎。

分散式資料庫開發相關問題

好的效能首先是設計出來的，應用如果追求極致的效能，就需要關注OceanBase裡資料的相關事情。如：

資料如何分佈？
資料如何讀寫？
儲存容量瓶頸怎麼辦？
訪問效能瓶頸怎麼辦？
資料庫出故障時資料可用性和可靠性具體怎樣？應用需要做什麼特殊處理麼？
資料庫擴充套件時應用需要遷移資料麼？資料遷移的時候對應用有什麼影響？

這些問題對理解OceanBase的分散式特點很有幫助。後面我們逐步看看OceanBase是如何應對。

OceanBase叢集外觀

首先簡介一下OceanBase叢集的外觀。

483dad7d993f799c15d98f9ac0b6671db187b665

圖 1 OceanBase叢集外觀

OceanBase是以叢集形式執行的，由一堆伺服器組成。上圖是「三副本」部署，機器會分為三組，每組一個區域（稱為Zone），各個機器通過網路互相訪問。沒有光纖交換機、共享儲存以及直連網線等。

伺服器通常建議CPU、記憶體和磁碟儘可能的大，磁碟建議用普通SSD盤。普通伺服器的好處是便宜，劣勢是可靠性和效能可能不如小型機那麼高。也就是說OceanBase可以部署在一組可靠性和效能不是特別高的普通伺服器上，卻提供了高效能、高可用和高可靠、彈性伸縮等多項能力。

以上是一個OceanBase叢集的外觀和能力，但是提供給業務的並不是這個叢集的全部資源和能力，而是其子集，即租戶（Tenant）。

OceanBase多租戶特性

OceanBase定義了一些基本的資源規格（Resource unit config，如4CPU8Gmem500Gdisk等），然後選取某類資源規格建立一組資源池（Resource Pool），此時叢集資源就有一部分被分配出去了。最後將這個資源池關聯到一個新建租戶，則租戶就可以使用這個資源池的能力。

OceanBase預設有個sys租戶，管理整個叢集。使用者租戶必須在sys租戶內部建立。

如下示例就是建立租戶的過程。

#sys租戶登入方法

$mysql -hxxx.xx.11.11 [email protected]#obdemo -P2883 -proot oceanbase -A

#資源規格（UnitConfig）
create resourceunit S0_uc max_cpu=2,max_memory='5G',…

資源單元（Unit）
create resourcepool Pool_01 unit='S0_uc',unit_num=2,...

租戶（Tenant）
create tenant test_ins resource_pool_list= ('Pool_01'),...

OceanBase相容了大部分MySQL連線協議和語法，租戶的使用體驗跟MySQL例項很像。研發可以在租戶裡建立資料庫（Database）、表（Table）。還包括分割槽表等。

OceanBase裡描述資料的最小粒度是分割槽。普通的表（非分割槽表）就是一個分割槽，分割槽表則包含多個分割槽。

租戶的示意圖如下。租戶之間資料是絕對隔離，資源有一定程度隔離。研發可以將業務先垂直拆分為多個獨立的子業務，分別使用不同的租戶或者叢集。

69a15e605ffe8227699a9bc2421bd368598f4859

圖2 OceanBase多租戶示意圖

OceanBase資源單元

租戶裡並不知道資料具體在哪個機器上，也可以說沒必要知道。只是租戶的效能還取決於運維為租戶規劃的資源池分佈情況，所以瞭解一下資源單元的分佈特點對效能規劃也是有意義的。

資源池（Resource Pool）是由一組資源單元（Resource Unit）組成。資源單元數量預設跟Zone的數量一致或者是它的倍數（可以配置具體分佈在哪些Zone以及每個Zone裡的Unit數量）。如下圖

0f80e8d2230111cfe38cff029c8be07ec72520ad

圖 3 OceanBase 資源池分配示意圖

資源單元具備一定的資源能力，是資料的容器。租戶擁有的資源單元規格和數量決定了這個租戶最大效能。資源單元可以在同一個Zone的不同節點之間自由遷移，OceanBase藉此來維持各個節點的資源利用率儘可能維持一個均衡狀態。

OceanBase拆分設計

資料庫拆分

資料庫拆分有兩種。

一是垂直拆分。即按業務模組拆分到不同的例項或庫裡。為了模組之間互不影響，拆分到不同的例項比較好。在OceanBase裡實現時可以是拆分到同一個叢集裡不同租戶或者不同叢集裡的租戶都可以，取決於業務規模和資料庫叢集規模。垂直拆分很好理解，後面不再贅述。

一是水平拆分。即按某個業務維度將資料拆分到多個分片。這些分片可以是在一個庫或者不同庫或者不同例項的不同庫下。水平拆分實現又有兩類常用的選擇。如下：

分庫分表。將一個業務表拆分到N個相同結構的物理表中。中介軟體做業務表（邏輯表）到分表（物理表）的對映路由以及其他相關操作（如結果聚合計算）等。這個N個物理表可以在不同例項的不同分庫中。分庫的維度和分表的維度可以不一樣，比較靈活。
分割槽表。將一個物理表設計為分割槽表，拆分到N個分割槽。分割槽表的各個分割槽結構是資料庫內部保證一致。OceanBase選擇的是分割槽表的水平拆分方式，並且支援二級分割槽表（即有2個不同的拆分維度疊加使用）。

水平拆分示意圖如下：

31c4a85a1c4bcb39a85f9bb4c71eeab17c6c4116

圖 4 水平拆分的分庫分表和分割槽表

上圖是分庫分表和分割槽表同時結合使用。業務表order先經過中介軟體拆分為100個分表（存在10個分庫裡），每個分表在OceanBase內部又是一個分割槽表（100個分割槽）。分庫分表的維度和分割槽表分割槽的維度都是一致的，根據使用者ID。

分庫分表和分割槽各有利弊。

分庫分表的好處是各個分表的結構一致性是在中介軟體層保證，比較好控制，比較適合灰度變更（允許部分分表結構不一致，最終必須全部一致）。此外更大的好處是，分庫分表是實現異地多活單元話架構的必不可少的條件。缺點是中介軟體的SQL支援範圍有限。

分割槽的好處是在資料庫內部解決了拆分問題。針對分割槽表的SQL功能是資料庫SQL引擎的本質工作，相關特性（全域性索引、二級分割槽等）會持續開發完善。

分割槽

分庫分表架構設計，需要確定機器數、例項數、分庫數和分表數的拓撲，效能理論上限取決於主例項所處的機器節點數。此後要做擴充套件就要調整這四個元素的數目及其聯絡。這種擴充套件很可能涉及到分表資料的遷移，需要藉助外部工具或產品實現。

分割槽架構設計，研發確定分割槽策略和分割槽數，運維確定租戶的資源單元數量，OceanBase確定資源單元（Unit）在哪些機器節點上以及分割槽（Partition）在哪些資源單元裡。同一個分割槽不能跨節點儲存。如下圖。此後要做擴充套件就是調整資源單元的規格、數量。

OceanBase在確定Unit裡的分割槽的位置時會盡量讓每個節點的負載維持均衡。這個負載的計算方式比較複雜，會綜合考慮OB節點內部CPU、記憶體和空間利用率等。分割槽隨意分佈對應用效能很可能有負面影響。當業務上有聯絡的兩個表的分割槽分佈在不同的資源單元裡（同時也分佈在不同的節點裡），這兩個表的連線就難以避免跨節點請求資料，網路上的延時會影響這個連線的效能。

d4c886723b0450a368a7539747422df80f65820b

圖5 分割槽在資源單元中的位置

注： t1(p0) 表示表t1的0號分割槽。

每個分割槽在叢集裡資料實際有三份，即三副本（Replica）。圖中忽略了Zone2和Zone3的細節。三副本之間的資料同步靠把Leader副本的事務日誌同步到其他Follower副本中。Paxos協議會保障這個事務日誌傳輸的可靠性（事務日誌在一半以上成員裡落盤，剩餘成員最終也會落盤），同時還有個以分割槽為粒度的選舉機制，保障Leader副本不可用的時候，能快速從現有兩個Follower副本里選舉出新的Leader副本，並且資料還絕對不丟。這裡就體現了故障切換時兩個重要指標：RPO=0， RTO<30s。

Locality

圖5中t0和t1業務上是有聯絡的表（如主表和詳情表），兩者都是分割槽表，分割槽策略和分片數都相同，OceanBase提供了一個表屬性“表分組”（TableGroup）。設定為同一個表分組的不同表的分割槽數一定一樣，並且同號分割槽組成一個“分割槽分組”（PartitionGroup）。同一個分割槽分組的分割槽一定會分配在同一個資源單元（Unit）內部（也就是會在同一個節點內部），彼此的連線邏輯就避免了跨節點請求。另外一個效果是如果一個事務同時修改兩個有業務關聯的分割槽，使用分割槽分組也可以規避跨節點的分散式事務。這個表分組屬性的設定就是OceanBase的Locality特性之一——影響相關分割槽的分佈。

實際上每個分割槽都有三副本（Replica, 本文例子），圖5中省略了t0(p0)和t1(p0)的其他兩個副本都分別會在同一個Unit裡分配。不僅如此，每個分割槽的三副本里都會有leader副本預設提供讀寫服務。leader副本是選舉出來的。t0(p0)和t1(p0)的leader副本也一定會在同一個Unit裡（即在同一個Zone裡）。這樣才徹底的避免了連線的時候跨節點請求。

OceanBase的Locality特性還可以指定租戶/資料庫/表的預設Zone，這樣下面的表的leader副本會優先被選舉為這個Zone裡副本。

如下面例子，資料庫和表會繼承租戶的預設設定，當然也可以自己修改primary_zone或者locality屬性覆蓋上層設定。：

create tenant obtrans0primary_zone='hz1';

create table item (…)locality = '[email protected], [email protected], [email protected],R{all_server}@hz1, R{all_server}@hz2, R{all_server}@hz3'

注：F表示全功能副本，R表示只讀副本。

設定primary_zone後單個租戶的所有表的讀寫都集中到一個Zone裡，該租戶在其他zone裡的Unit就沒有讀寫壓力。通常這樣做是源於業務應用的要求。如應用的請求都是來自於這個Zone，為了規避應用跨Zone讀寫資料效能下降。不過primary_zone更大的意義在於當叢集裡有很多租戶的時候，可以將不同業務租戶的讀寫壓力分攤到不同Zone的機器，這樣叢集整體資源利用率提升，所有應用的總體效能也得到提升。後面要介紹的異地多活架構就充分利用OceanBase這個特性，在資料庫層面將拆分的表的業務讀寫點儘可能分散到所有Zone的所有機器上。

除了表與表之間可能有聯絡，業務模組之間也可能有聯絡。一個業務過程可能會橫跨多個業務模組，前面這些模組的資料被垂直拆分到多個租戶裡。OceanBase的Locality特性“租戶分組”（TenantGroup）還可以設定不同租戶之間的聯絡。如下租戶交易訂單和支付訂單在業務上是先後發生。

create tenantgroup tgtrade tenant_array=('obtrade0', 'obpay0');

租戶分組的意義依然是為了在分散式架構下儘可能將一個業務流程內多次資料庫請求都約束在同一個Zone或者Region（注：OceanBase將地域相鄰的Zone定義為一個Region）裡。

OceanBase異地多活架構

異地多活概念

異地多活的概念一直都有，只是內涵不斷變化。以雙機房多活為例，應用通常都是無狀態的，可以多地部署。資料庫有狀態，傳統資料庫只有主庫可以提供讀寫，備庫最多隻能提供只讀服務（如ORACLE的Active Dataguard）：

1. 應用雙活，資料庫A地讀寫，B地不可讀寫。這種只有應用多活，資料庫是異地備份容災（無併發）。
2. 應用雙活，資料庫A地讀寫，B地只讀。這種也是應用雙活，資料庫讀寫分離（例項級併發）。
3. 應用雙活，資料庫雙活，兩地應用同時讀寫不同表。這種資料庫雙向同步，應用同時錯開寫不同的資料（表級併發）。
4. 應用雙活，資料庫雙活，兩地應用同時讀寫相同表不同記錄。這種資料庫雙向同步，應用同時錯開寫不同的資料（行級併發）。
5. 應用雙活，資料庫雙活，兩地應用同時讀寫相同表相同記錄。這種資料庫雙向同步，應用同時寫相同的資料，最終會因為衝突一方事務回滾（行級併發寫衝突）

上面第1種情形，B地應用是跨地域遠端讀寫資料庫。兩地距離較大的時候效能會很不好。2的B地應用是本地訪問資料庫。3，4，5三種情形兩地資料庫都提供讀寫服務，對應用而言是本地訪問資料庫，但到分散式資料庫內部，其要讀寫的資料是否正好在本地就取決於業務和資料庫的拆分設計。有這麼一種情形，B地應用訪問B地資料庫例項，請求的資料的寫入點恰好是A地，這樣會走分散式資料庫內部路由遠端A地例項中拿到資料，效能上會有些下降，而業務可能不知道為什麼。

OceanBase水平拆分方案

為了避免在分散式資料庫OceanBase內部發生跨Zone請求，應用的請求流量的水平拆分規則和資料的水平拆分規則要保持一致並聯動，就可以實現真正的應用向本地例項請求讀寫的資料恰好就是在本地例項種。這就是Locality的用途所在。

47cb773fee77822dc9ab69f9cb9ffdcb9bc74886

圖 6 OceanBase叢集異地多活水平拆分示意圖

首先業務架構層面能根據使用者ID（uid）做拆分，將使用者拆分為100分。x和y是使用者直接相關的表，都根據uid拆分為100個分表，分佈在5個不同的租戶裡。x[00-19]表示20個分表。每個租戶的Leader分別分佈在不同的Zone。uid:00-19表示分到這20個分片的使用者資料和使用者流量。

應用層面在某個環節能根據UID將使用者請求轉發到對應的機房（Zone），應用服務之間的請求資訊都有這個UID資訊，後面應用請求都在本機房流轉，並且訪問資料庫時通過分庫分表中介軟體（DBP）和OceanBase的反向代理（OBProxy）就路由到本機房的業務租戶上。

實際使用這個架構時，有幾個隱含的前提，Zone1和Zone2是同城雙機房，Zone3和Zone4是同城雙機房，兩個城市靠的比較近，Zone5 實際很遠，所以一般不提供寫入。為節省空間，Zone5裡的副本放的是日誌副本。

應用異地多活架構

上面要實現OceanBase在每個Zone的應用寫入都是恰好是本地訪問，關鍵點就是應用流量水平拆分規則跟資料水平拆分規則保持一致。而應用要維持這樣一個規則，需要很多產品都要支援水平拆分等。如下圖

b44c3d260db547150ede25a2f3bcb0247a77d921

圖 7 應用三地五中心多活解決方案

圖中流量接入層的“負載均衡”環節負責調整使用者流量到對應的機房（Zone），此後的應用之間的請求就都是本地訪問。

能使用這個解決方案的業務都是能按使用者維度做水平拆分。有些業務的拆分維度跟使用者維度是衝突的，或者有些業務的資料只支援集中寫入等，不能做到上面這種多活，但也可以使用OceanBase，實現單點寫入，多點讀取的功能。

OceanBase在異地容災和多活架構方案中的價值就是支援水平拆分規則的定義、解決了多個機房間資料同步和一致性問題、始終具備高可用和彈性伸縮能力等。

如何基於OceanBase構建應用和資料庫的異地多活

如何基於OceanBase構建應用和資料庫的異地多活

前言

分散式資料庫開發相關問題

OceanBase叢集外觀

OceanBase多租戶特性

OceanBase資源單元

OceanBase拆分設計

資料庫拆分

分割槽

Locality

OceanBase異地多活架構

異地多活概念

OceanBase水平拆分方案

應用異地多活架構

參考

如何基於OceanBase構建應用和資料庫的異地多活

資料庫-異地多活多中心概念

基於jenkins構建應用的docker映象做持續整合和部署

基於極數雲舟Arkgate跨雲資料庫異地雙活實戰

阿里和微博的異地多活方案

不理解Zookeeper一致性原理，談何異地多活改造

從github超24小時的故障看異地多活全域性設計的重要性

專訪阿里巴巴畢玄：異地多活資料中心專案的來龍去脈

專訪阿裏巴巴畢玄：異地多活數據中心項目的來龍去脈

螞蟻金服異地多活的微服務體系

異地多活架構設計系列(一): Why and How

分散式多活的異地多活設計四大誤區

分散式系統技術難題--異地多活

異地多活場景下的資料同步之道

使用基於 GraphQL 的實時和離線功能構建資料驅動型應用程式

基於執行緒池和NIO技術構建高效的多協議Android通訊框架

BEGINNING SHAREPOINT® 2013 DEVELOPMENT 第6章節--在SharePoint2013中開發、集成和構建應用程序總結

CentOS7基於FPM模式編譯LAMP，實現多虛擬主機應用wordpress

基於Spring Boot構建應用開發規範

新思科技釋出Seeker最新版本可針對基於 Web 的應用進行主動驗證和敏感資料跟蹤

如何基於OceanBase構建應用和資料庫的異地多活

如何基於OceanBase構建應用和資料庫的異地多活

前言

分散式資料庫開發相關問題

OceanBase叢集外觀

OceanBase多租戶特性

OceanBase資源單元

OceanBase拆分設計

資料庫拆分

分割槽

Locality

OceanBase異地多活架構

異地多活概念

OceanBase水平拆分方案

應用異地多活架構

參考

相關推薦