OceanBase設計規范與數據架構指南

版本0.1

文檔修訂歷史

版本號作者備注修訂日期

V0.1哪初稿-06-29

V0.2修正細節-07-13

1OceanBasel.O介紹

自從E.F.Codd于1970年首次提出關系數據庫模型后，關系數據庫便以

其易于使用接口、完善功效和生態而成為了IT領域必需基礎設施，廣泛應用

在各行各業，包含金融、電信、房地產、農林牧漁、制造業等等。關系數據庫

經過了40多年發展，涌現了Oracle、SQLServer,DB2等優異商業數據庫產

品，開源領域也不乏MySQL、PostgreSQL這么精品。

不過，伴隨互聯網行業和大數據興起，數據量和并發訪問量展現指數級增

加，囿于關系數據庫架構，原先運行良好關系數據庫遭遇了嚴峻挑戰：極度高

昂總體擁有成本、捉襟見肘擴展能力、荏弱無力大數據處理性能等等。

于是NoSQL應運而生，Hbase>Cassandra等系統如雨后春筍般冒出，

這些系統多采取分布式架構，易于擴展及容災，結合大數據處理系統如Hadoop

等，能夠很輕易處理量級非常大數據，這一時讓NoSQL風光無兩，大有取

代SQL之勢，讓人看不清NoSQL系統邊界。很多企業嘗試將關鍵系統遷移

到新興NoSQL系統上，比如Facebook就嘗試將部份關鍵系統遷移到

Cassandrao在遷移過程中，人們發覺NoSQL所取得針對SQL優勢其實是

以犧牲一些非常主要功效來獲取，如NoSQL通常不支持事務或只支持非常

有限事務，這極大增加了業務系統復雜度，在傳統OLTP領域采取NoSQL

系統基本上是不能夠接收。

阿里巴巴/螞蟻金股關系數據庫使用場景極其嚴苛，有著全球最大并發量需

求，在可靠性方面需要做到單機、機架、機房甚至是地域級別容災恢復能力。

早期使用共享存放、小型機等高端硬件也只能部分滿足我們在性能和可靠性上

需求，而且伴隨業務發展，這種IOE架構很快就成為瓶頸。

我們能不能結合新興分布式系統和傳統關系型數據庫優點，既擁有傳統關

系型數據庫在功效上優勢，同時具備分布式系統可擴展性、高可靠性等特征？

OceanBase即是以此為出發點，開始打造一個分布式關系型數據庫。

OceanBase從6月份立項開始到今天已經發展了六年多時間，構建在普通服

務器組成分布式集群之上，具備可擴展、高可用、高性能、低成本以及多租戶

等關鍵技術優勢。現在已經成功應用于螞蟻金服會員、交易、支付、賬務、計

費等關鍵系統和網商銀行等業務系統。OceanBase經歷了多年（?）雙十一嚴

格考驗，尤其是在剛才過去雙十一，用戶每一筆支付訂單背后數據和事務處

理都由OceanBase完成，創造了每秒12萬筆支付峰值世界統計。

2OceanBase架構及優勢

互聯網對傳統關系型數據庫挑戰主要有兩個方面：

一是可擴展性。傳統關系型數據庫本質上是單機系統，其擴展方法通常為向

上擴展，即換性能愈加好機器，阿里巴巴/螞蟻金服伴隨業務發展，也一路擴

容到小型機，但這種方式對于互聯網行業來說，其擴容周期短，成本很高。另

外一個方法為水平拆分，即分庫分表，這也是現在廣泛應用擴展方式，這極大

增加了業務復雜度，相當于將數據庫一部份工昨轉嫁到業務方，從各大企業

都有自己中間件來處理這一層業務即可見一斑。

但經過分析，基于控制力、架構等原因，我們最終沒有選擇這條路，而是完全

自主研發。

二是分布式一致性問題。分布式系統往往經過多個副原來實現數據高可靠以

及高可用，怎樣確保多個副本之間數據一致性是一個非常復雜問題。最大保

護模式基礎是高可用硬件及網絡鏈路，這些在OceanBase中都不存在。

三是分布式事務問題。很多分布式系統都弱化了這個功效，只支持單行事務,

這么選擇首先是工程實現難度較高，另外首先是對性能影響較大，OceanBase

怎樣支持跨機分布式事務并確保性能是一個很大問題。

OceanBase處理這些問題也并非一蹴而就，而是著眼于業務需求，經過六年

發展，才逐步處理了這些問題，OceanBase總體架構:

尸＞5

?002

如上圖所表示，一個OceanBase集群由多臺分布在不一樣機房Observer

組成，每臺Observer都是對等關系，圖中分布在三個IDC,意味著存放了

三個副本，每個IDC是鏡像關系，可抵抗少數派IDC失敗。

每個表能夠以分區表（即createtable中partitionby子句）形式分成多個分

區，圖中一個表被分成了P1-P88個分區，每個分區能夠分布在不一樣

Observer上，每個分區三個副本分布在不一樣IDC不一樣Observer±,

其中一個副本被選舉為Leader,如圖中P2,P3Leader在IDC1第一臺

Observer上。只有分區Leader才能夠對外提供查詢和更新服務。

ObProxy是一個無狀態服務，它接收應用請求并依照應用請求中分區字段來

判斷這個請求屬于哪個分區，然后將其路由到這個分區Leader所在服務器。

讓用戶無需關心數據分片細節，數據所在詳細位置，對外表現依然是一個單

機數據庫。OceanBase兼容MySQL協議，經過ObProxy,用戶能夠使

用任意語言MySQL客戶端來連接OceanBase。

經過六年多發展，OceanBase初步實現了當初定下目標，在架構上具備夕艮多

優勢：

2.1.1高效存放引擎

OceanBase采取是share-nothing分布式架構，每個OBServer都是對等，管

理不一樣數據分區。單機存放引擎采取讀寫分離架構，將當前更新動態數據存

入內存稱為MemTable,存量基線數據存在磁盤，稱為SSTable。一個Partition

全部數據（基線數據+增量數據+事務日志）都放在一個OBServer中，所以皆對

一個Partition讀寫操作不會有跨機操作，數據寫入也分布到多點并行執行。

蹦更新一

—增田數據

O1AF

數據合并

讀寫分離存放結構帶來很多好處，因為有大量靜態基線數據，能夠很方便對?其

進行壓縮，降低存放成本；另外做行級緩存也不月擔心寫入帶來緩存失效問題。

缺點是讀路徑變長，數據需要實時合并可能帶來性能問題，OceanBase采取

了很多優化伎倆，比如bloomfiltercache對不存在行做過濾(insertrow判斷

行是否存在無需10操作)，盡可能優先讀取更新內容(ActiveMemTable),假

如發覺用戶讀取列已經讀取到，則無需深入讀取基線數據進行合并。

因為增量數據寫在內存中，所以內存寫到一定量后需要和基線數據合并而生成

新基線，這個過程我們稱之為合并，合并會造成一些額外壓力，可能對客戶

請求有影響，所以我們采取一個稱之為輪轉合并策略，即將OceanBase多

個IDC中其中一個IDC流量切走，進行合并，待合并完成后再將流量切到己

合并IDC上，這么能夠防止對業務影響，同時這種策略也能夠用在升級維護中,

當需要進行版本升級時候，能夠將其中一臺Observer流量切走進行升級,

升級完成后逐步灰度切流，一旦出現問題即可快速無損回滾。

2.1.2可擴展性

分布式系統經過數據分區來實現可擴展性，主流數據分區方法有兩種：哈希分

區和范圍分區。分布式Key-Value系統、數據庫分庫分表本質上都是哈希分區；

而主流分布式表格系統，如Bigtable、開源HBase往往采取范圍分區。范圍

分布很輕易出現分區不均勻情況，所以，需要支持分區動態分裂與合并。

關系數據庫數據分布方法則更為靈活，以Oracle分區表為例，除了支持簡單

哈希分區、范圍分區，還支持list分區、Interval分區，以及二級組合分區。

另外，關系數據庫還支持單個分區操作，比如刪除某個分區，構建針對單個分

區局部索引、設置壓縮方法，等等。

OceanBase引入了傳統關系型數據庫中數據分區表方法，語法上也兼容傳統

數據庫創建分區表方法，這種設計兼具分布式系統擴展性和關系數據庫易用性

和靈活性，符合DBA使用習慣。

OceanBase支持在線線性擴展，當集群存放容量或是處理能力不足時，能夠

隨時加入新OBServer,系統會自動進行數據遷移，依照機器處理能力，將適

宜數據分區遷移到新加入機器上；一樣在系統容量充分和處理能力充裕時，也

能夠將機器下線，降低成本；在類似于雙11大促之類活動中，能夠提供良好

彈性伸縮能力。

對一個數據分區全部讀寫操作都在其所在OBServer完成，包括多個數據分區

事務，會采取兩階段提交方式在多個OBServer上執行。在OceanBase中，

事務分為幾個類型：

?單分區事務。和傳統關系數據庫一樣，屬于單機事務，不需要走兩階段提交協議。

?單機多分區事務。需要走兩階段提交協議，且針對單機做了專門優化。

?多機多分區事務。需要走完整兩階段提交協議。

分布式事務會增加事務延時，OceanBase采取了很多方法來盡可能防止分布

式事務，比如支持表格組(tablegroup)來盡可能地降低分布式事務。表格

組用于聚集經常一起訪問多張表格。比如，有用戶基本信息表(user)和用戶

商品表(userjtem),這兩張表格都按照用戶編號哈希分布，只需要將二者

設置為相同表格組，系統后臺就會自動將同一個用戶所在user表分區和

userjtem表分區調度到同一臺服務器。這么,即使操作某個用戶多張表格，

也不會產生跨機事務。

2.1.3高可靠

OceanBase系統中每個分區都維護了多個副本，通常為三個，且布署到三個

不一樣數據中心(Zone)。整個系統中有成百上千萬個分區，這些分區多個

副本之間經過Paxos協議進行日志同時。每個分區和它副本組成一個獨立

Paxos復制組(PaxosReplicationGroup)，其中一個副本為主(Leader),

其它副本為備(Follower)。每臺Observer服務一部分分區為Leader,一部

分分區為Follower。當Observer出現故障時，Follower分區不受影響，Leader

分區寫服務短時間內會受到影響，直到經過Paxos協議將該分區某個Follower

選為新Leader為止，整個過程大約連續30秒左右。

經過引入Paxos協議，能夠確保在數據強一致情況下，具備極高可用性及性

能。

2.1.4多租戶

OceanBasel.O系統作為一個擴展性很強集群系統，設計目標就包含使用一個

集群支持多個業務系統，也就是通常所說多租戶特征。數據庫多租戶概念，

Oracle是從12c版木開始支持，在Oracle里面，最主要兩個概念是CDB

(ContainerDB)和PDB(PluggableDB)。對于OceanBasel.O來說,多

租戶一樣是一個非常主要特征，是數據庫對象管理和資源管理基礎；對于系統

運維，尤其是對于未來云數據庫運維也有著主要影響。

OceanBasel.O多租戶特征，土要包含以下幾點；

?將多個數據庫實例管理和運維成本和復雜性降低到和一個數據庫實例相當。1.0其中一個

優勢就是大集群規模優勢，取得這個優勢一個主要原因就是原先多個數據庫實例，在1.0

版本中管理成本相當于一個實例。

o充分利用系統資源，使得一樣資源能夠服務更多業務。經過將波峰、波谷期不一樣業務

系統布署到一個集群，以實現對系統資源最大程度使用。

。租戶之間隔離性：在數據安全方面，不允許跨租戶數據訪問，確保用戶數據資產沒有泄

露風險；在資源使用方面表現為租戶“獨占”其資源配額，該租戶對應前端應用，不論是響

應時間還是TPS/QPS都比較平穩，不會受到其余租戶負載輕重影響。

美。OraclePoe^CDB

虛”蟻：Bitfios?a

DB遇程內本

OceanBase所采取隔離方式，既能充分利用資源,又能夠獲取非常高資源整

合度。多租戶特征使得OceanBase非常適合云計算。

2.1.5MySQL兼容

關系數據庫經過多年發展，其周圍生態十分主要，大量現有業務都構建在現有

關系型數據庫上，OceanBase采取和MySQL兼容方式來讓基于MySQL

應用程序能夠不經修改就能運行在OceanBase之上。

OceanBase在兼容性方面做了大量工作：

?接口層面：主流數據庫產品都支持標準接口如JDBC、ODBC,.netProvider。OceanBase

廣泛使用接口主要是JDBC和ODBC。經過不停增強在前后臺協議上和MySQL兼容性,

現在，使用MySQL驅動就能夠無障礙地訪問OceanBase。

?數據模式層面：完整地支持了數據庫（database\表（table）、視圖（view\自增列（auto

increment）等SQL標準以及MySQL專有數據模式，而且在數據庫系統中實現了多租戶

（multi-tenant\原先基于不一樣MySQL實例業務能夠無縫地遷移到一個OceanBase

集群。

?語句層面:現在主流產品在SQL語句層面大多恪守ISO/IEC9075標準定義一系列規范，

最新版本是SQL0對比之前版本,1.0版本大幅度增加了對標準SQL語句支持，同時擴

展了支持了MySQL中有但非標準語句。

?數據類型層面：數據類型是基礎設施，對兼容性影響非常大，包括細節非常多。在1.0

版本開發過程中，為了使得表示式計算表現和MySQL一致，我們在數據類型兼容性方面

投入了大量人力，也幫助MySQL產品糾正了不少錯誤表現。

?事務層面：系統支持事務隔離級別以及并發控制方面表現。OceanBase采取是多版本并

發控制協議，讀寫不等候，支持ReadCommitted隔離級別。

3OceanBasel.O開發設計規約

數據庫開發設計規約在新系統上線早期啟到了舉足輕重作用。正如同制訂交通法規表面

上是要限制行車權，實際上是保障公眾人身安全。試想假如沒有限速，沒有紅綠燈，沒有靠

右行駛條款，誰還敢上路。

OB開發規約目標：

?防患未然，降低故障率和維護成本。

?標準統一，提升協作效率。

?追求卓越工匠精神，打磨精品代碼。

3.1.1建表規約

1.【強制】表示是是否概念字段，數據類型是unsignedtinyint（1表示是，

。表示否），值內容要統一，全部應用值要統一。

正例：表示邏輯刪除字段名is_deleted,1表示刪除，0表示未刪除。

2.【強制】表名、字段名必須使用小寫字母或數字。禁止出現數字開頭，禁

止兩個下劃線中間只出現數字。數據庫字段名修改代價很大，所以字段名

稱需要慎重考慮。

說明：MySQL在Windows下不區分大小馬，但在Linux下默認是區分大

小寫。所以，數據庫名、表名、字段名，都不允許出現任何大寫字母，防

止節外生枝。

正例：getter_admin,task_config,Ievel3_name

反例：GetterAdmin,taskConfig,level_3_name

3.【強制】表名不使用復數名詞。

說明：表名應該僅僅表示表里面實體內容，不應該表示實體數量

4.【強制】禁用保留字，如desc、range>match、delayed等,OB1.0保

留字見

5.【強制】唯一索引名為uk_字段名；普通索引名則為idx_字段名。

說明：uk_即uniquekey；idx_即index簡稱。

6.【強制】小數類型為decimal,禁止使用float和double。

說明：float和double在存放時候，存在精度損失問題，很可能在值比較

時，得到不正確結果。

7.【強制】varchar是可變長字符串，不預先分配存放空間，長度不要超出

256K,假如存放長度大于此值，現在OB1.0暫不支持。需要考慮字段拆

分方案。一張表列總長度（rowsize）不能超出512K

8.【強制】表必備兩字段：gmt_create,gmt_modifiedo

說明：gmt_create,gmt_modified類型均為datetime（6）類型。（最好實

踐記到微秒）

9.【強制】表命名最好是加上“業務名稱—表作用”。

正例：tiger_task/tiger_reader/mpp_config

10.【推薦】庫名與應用名稱盡可能一致。

11.【推薦】假如修改字段含義或對字段表示狀態追加時.，需要及時更新字段

注釋。

12.【推薦】字段允許適當冗余，以提升性能，不過必須考慮數據同時情況。

冗余字段應遵照：

1）不是頻繁修改字段。

2）不是varchar超長字段。

13.【強制】單分表行數可能超出10億行或者單分表容量超出GB,才推薦

進行分區表。

說明：假如預計三年后數據量根本達不到這個級別，請不要在創建表時使

用分區表。

反例：某業務三年總數據量才2萬行，卻在上線早期就規劃使用分區表，

因為業務模型改變，很可能面臨需要調整分區鍵問題，這個需要等業務穩

定成熟后考慮分區表模式。后續OB也會支持非分區表轉換成份區表功效。

14.【參考】適宜字符存放長度，不但節約數據庫表空間、節約索引存放，更

主要是提升檢索速度。

正例：無符號值能夠防止誤存負數，且擴大了表示范圍：

對象年紀區間類型表示范圍

人150歲之內unsignedtinyin無符號值：0到255

t

龜數百歲unsignedsmal1i無符號值:0到65535

nt

恐龍化約數千萬unsignedint無符號值：0到約43億

石年

太陽約50億年unsignedbigint無符號值：0到約1019次

方

3.1.2索引規約

SQL開發完成后，需要聚集全部語句提交給DBA進行sqlreview

1.【強制】業務上具備唯一特征字段，即使是組合字段，也必須建成唯一索

引。

說明：不要認為唯一索引影響了insert速度，這個速度損耗能夠忽略，但

提升查找速度是顯著；另外，即使在應用層做了非常完善校驗和控制，只

要沒有唯一索引，依照墨菲定律，必定有臟數據產生。

2.【強制】超出三個表禁止join。需要join字段，數據類型保持絕對一致;

多表關聯杳詢時，確保被關聯字段需要有索引。

說明：即使雙表join也要注意表索引、SQL性能。

3.【強制】頁面搜索禁止左含糊或者全含糊，假如需要請走搜索引擎來史理。

說明：索引文件具備B-Tree最左前綴匹配特征，假如左邊值未確定，那

么無法使用此索引。

4.【推薦】假如有orderby場景，請注意利用索引有序性。orderby最終

字段是組合索引一部分，而且放在索引組合次序最終，防止出現file_sort

情況，影響查詢性能。

正例：wherea=?andb=?orderbyc;索弓I：a_b_c

反例：索引中有范圍查找，那么索引有序性無法利用，如：WHEREa>10

ORDERBYb;索引a_b無法排序。

5.【強制】利用覆蓋索引來進行查詢操作，來防止回表操作。

說明：假如一本書需要知道第11章是什么標題，會翻開第11章對應那

一頁嗎？目錄瀏覽一下就好，這個目錄就是起到覆蓋索引作用。

6.【強制】利用延遲關聯或者子查詢優化超多分頁場景。

說明：OB1.0并不是跳過offset行，而是取offset+N行，然后返回放棄

前.offset行，返回N行，那當。ffset尤其大時候，效率就非常低下，要

么控制返回總頁數，要么對超出特定閾值頁數進行SQL改寫。

正例：先快速定位需要獲取id段，然后再關聯：

SELECTa.*FROM表1a,（selectidfrom表1where條件LIMIT

100000,20）bwherea.id=b.id

反例：“服務市場”某交易分頁超出1000頁，用戶點擊最終一頁時，數據

庫基本處于半癱瘓狀態。

7.【推薦】建組合索引時候，區分度最高在最左邊。

正例：假如wherea=?andb=?,a列幾乎靠近于唯一值，那么只需要

單建idx_a索引即可。

說明：存在非等號和等號混合判斷條件時，在建索引時，請把等號條件列

前置。如：wherea>?andb=?那么即使a區分度更高，也必須把b放

在索引最前列。

8.【參考】創建索引時防止有以下極端誤解：

1）索引寧濫勿缺

誤認為一個查詢就需要建一個索引。

2）吝尚索中創注

誤認為索引會消耗空間、嚴重拖慢更新和新增速度。

3）抵制唯一索出

誤認為唯一索引一律需要在應用層經過“先查后插”方式處理。

3.1.3SQL規約

1.【強制】不要使用count（列名）或count（常量）來代替count（*）,count（*）

就是SQL92定義標準統計行數語法，跟數據庫無關，跟NULL和非NULL

無關。

說明：count（*）會統計值為NULL行，而count例名）不會統計此歹U為NULL

值行。

2.【強制】不得使用外鍵與級聯，一切外鍵概念必須在應用層處理。

說明：（概念解釋）學生表中studentJd是主鍵，那么成績表中studentjd

則為外鍵。假如更新學生表中studentjd,同時觸發成績表中studentjd

更新，則為級聯更新。外鍵與級聯更新適適用于單機低并發，不適合分布

式、高并發集群；級聯更新是強阻塞，存在數據庫更新風暴風險；外健影

響數據庫插入速度。

3.［強制】0B1.0現在不支持存放過程

4.【推薦】in操作能防止則防止，若實在防止不了，需要仔細評定in后邊

集合元素數量，控制在1000個之內。

5.【參考】全部字符存放與表示，均以utf-8mb4編碼，

6.【推薦】在業務cache表場景中，比如頻繁insert/delete,數據生命周期

較短場景，需要添加HINT指定查詢。

說明：OB對于這種場景做了rowpurge優化，能夠回收delete節點，提升

查詢性能；考慮業務場景多樣性，為預防存在rowpurge無法回收場景造成

性能下降，所以推薦業務方指定HINT查詢。

7.【推薦】有時間精度要求業務，能夠使用datetime(6);對精度沒要求，

設置為datetime即可。

3.1.4ORM規約

1.【強制】在表杳詢中，一律不要使用*作為杳詢字段列表，需要哪止烏字

段必須明確寫明。

說明：1)增加查詢分析器解析成本。2)增減字段輕易與residtMap配置

不一致。

2.【強制】更新數據表統計時，必須同時更新統計對應gmt_mod由ed字段

值為當前時間。

3.【推薦】不要寫一個大而全數據更新接口，傳入為POJO類，不論是不

是自己目標更新字段，都進行updatetableset

c1=value1,c2=value2,c3=value3;這是不正確。執行SQL時，不要更新

無改動字段，一是易犯錯；二是效率低；三是binlog增加存放。

4OceanBasel.O高可用方案

4.1集群物理布署高可用

對于金融關鍵業務系統，需要確保能夠伴隨業務量發展，進行水平擴展，而且沒有系統

單點，不會因為某一臺機器或某一個服務不可用，而造成整個系統服務能力癱瘓。應用服務

器是很輕易支持水平擴展和負載均衡，而往往數據庫都是單點。

傳統Mysql/Oracle數據庫經過主備鏡像方案進行容災

傳統關系數據庫：主備庫OceanBase:分布式投票

MYSQLHA:

Mysql主備之間，數據同時有秒級延遲，因為有秒級延遲，當主庫宕機自動切到備庫后，

這部分延遲數據在備庫是缺失。RPO>0

OracleDataGuard:

OracleDataGuard包含三種同時模式:

?最大保護模式：事務在主庫執行成功而且強同時到備庫后才能應答客戶端

?最大性能模式：事務在主庫執行成功后就應答客戶端，由后臺線程異步復

制到備庫；

?最大可用模式：當主、備庫數據同時鏈路正常時，采取最大保護模式；不

然，退化為最大性能模式；

不論采取OracleGuard/Mysql,傳統關系數據庫要么選擇強一致，要么選擇高可用，

二者不可兼得。

OceanBase1.0采取分布式投票，即Paxos算法來處理這個問題。Paxos算法最少要

求三個副本，一個為主副本，另外兩個為備副本，事務要求在主庫執行成功而且最少同時到

一個副本才能夠組成多數派，從而應答客戶端。當某個副本出現故障時，分為兩種情況。假

如是備副本，對系統沒有影響；假如是主副本，Paxos協議會自動從兩個備副本中選擇一個

作為新主副本繼續提供服務，并經過協商來確保完全不丟失數據。

假如將Paxos需要三個副本都布署到一個機房，能夠容忍單臺服務器故障；假如想要

容忍機房整體故障，最少需要將副本布署到三個機房。為何呢？假設只將服務布署到兩個機

房，一個為主，一個為備，不論怎樣也無法擺脫傳統關系數據庫困境。假如每次事務都強同

時到備機房，那么各機房故障將無法提供服務假如事務只在主庫執行成功就應答客戶端，

那么，當主機房出現故障而將服務切到備機房時，將去矢數據。這就意味著，要么選擇強一

致，要么選擇高可用。

在OceanBase1.0版本，我們提出了一系列布署模式，包含：

4.1.1兩地三中心五副本

兩個城市，一個城市為主城市，另外一個城市為備城市。主城市包含兩個機房，每個機房兩

個副本；備城市只包含一個機房，這個機房只有一個副本

主城市災箸城市

主副本在主城市數據中心1。假如數據中心2整體故障那么，Paxos協議會將數據中心2

中兩個副本從組員列表中剔除，組員組由5個副本降級為3個副本，以后只需要強同時3

個副本中2個即可。大部分情況下，強同時操作能夠在數據中心1內完成，防止跨城市同

時。類似地，假如數據中心1整體故障，那么，Paxos協議需要首先將主副本切到數據中

心2，接著再將組員組由5個副本降級為3個副本，以后強同時操作能夠在數據中心2內完

成，防止跨城市同時。

4.1.2三地三中心五副本與三地五中心五副本

兩地三中心布署方案問題在于不支持異地容災。為了支持地域級無損容災，經過

Paxos協議原理能夠證實，最少需要3個地域。OceanBase采取是兩地三中心

變種方案：三地三中心五副本。該方案包含三個城市，每個城市一個機房，前兩

個城市機房各有兩個副本，第三個城市機房只有一個副本。和兩地三中心不一樣

點在于，每次執行事務最少需要同時到兩個城市，需要業務容忍異地復制延時。

假如僅限于杭州和上海這兩個地域之間強同時，邦么，需要容忍大約8毫秒左右

延時；假如包括到長傳鏈路，比如上海和深圳，那么，需要容忍30毫秒左右延

時。三地五中心和三地三中心五副本類似，不一樣點在于，會把每個副本布署到

不一樣機房，深入強化機房容災能力。

上圖為網商銀行OB1.0物理布署拓撲實例，整個OB大集群布署在三個城市5個機房內，

同時具備了server級別，機房級別,城市級別故障無損自動容災能力。

4.2應用高可用-Sharding技術

4.2.1分庫分表

當業務最低時，我們DB設計往往是單庫，甚至于多個業務共同便用一個數據庫，它方

便快捷，帶來運維成本低。但同時,當單個數據庫故障時，影響面廣。

舉個例子，早期支付寶全部系統，只有一臺Oracle數據庫，承載著交易、支付、賬務、

會員等等全部系統，而當DB故障，100%服務不可用。于是將每個業務單獨拆分,單獨數

據庫。再日后,trade單獨拆分一臺DB,而當tradeDB異常，一樣100%不可用。

淘寶TDDL,支付寶zdal這類中間件問世，徹底改變了這個現實狀況，將數

據基于一定規則進行拆分，將單庫單表拆分為了多庫多表，分片之間數據互不影

響。比如trade拆分100份，將這些數據均勻分布在50臺機器，則單個實例故

障只影響2%業務，降低業務影響.

Sharding作用，在于將單點拆分為多個分片

1、降低了單個實例故障影響面

2、提升了單機容量

但sharding并沒有處理業務快速恢復問題,單個實例故障還是影響了部

分業務，這部分業務也只能在DB得以恢復后才能恢復業務。

ApplicationServers

將某個訪問極其平

凡的表，按照某

個字段的某種規則

來分放到多個表之

中，誨個表中包含

一部分數據

horizontal

sharding

已網商銀行業務流水號為例：

萼體為：18位固定位+34位擴展位（可選）+12位圖定位，總長度＜=".

于展位

1

位S5123456789101112131415161718???121110987654321

示例20I70618101I000001???010011213690

碼段一二三四五六±

長度8位1位1位8位最長34位4位

固定位同定位

說明

四正序第1業堯事件臺

正序箕19M

第疚篁12-%2數5湮由馀識.JflSR分大100費.繆由則網flipid（對應支付至W）或者iproleid（燈應支付至uld）的物效2、3位（lpld/lpfoleld初始化時院確保翎K2.3

位一致）,3E水總使用例數12一11蔭位.戶kJ的例數2.迎.衰喑名稱的畬名視這S例為deb_a?ount_0【00-99】：KJ里分10唳.路由現。援用5附至數篇3Q,X*

號使用力數12位.表名稱的命名或花型%f_aw?t_09-9】0;倒數第10.9謂位為?1機分表位.業務JK蛻自行決定.歌汰停留埴零后除可用亍自所SWFaibsr量計.具

體彩5見.jKig分裳雙酉http：//doj3nluwt/pa9”A?ewpageXion?pagad=12lS067*id4JR3gje構分析與設計-分裳方jg.

倒數笏8-1位.SwpencW間,可以支持霍天母個分表TZS立靂.■環使用

彳融口分為100表，路由規則采取ipid（對