來自： OceanBase技術閑談

1. 前言

本文總結一下接觸過的關系型數(shù)據(jù)庫常用的幾種架構及其演進歷史。

分析數(shù)據(jù)庫架構方案的幾個視角用發(fā)生故障時的高可用性、切換后的數(shù)據(jù)一致性和擴展性。每個產(chǎn)品都還有自己獨特的優(yōu)勢和功能，這里不一定會提到。

2. Oracle數(shù)據(jù)庫的架構方案

ORACLE數(shù)據(jù)庫既能跑OLTP業(yè)務，也能跑OLAP業(yè)務，能力是商業(yè)數(shù)據(jù)庫中數(shù)一數(shù)二的。支持IBM小機和x86 PC服務器，支持多種OS。同時有多種數(shù)據(jù)庫架構方案供選擇，成本收益風險也各不相同。

A. IBM AIX HACMP + ORACLE9I + EMC

圖 1 ：IBM AIX HACMP + ORACLE9I + EMC

架構說明：

1. 兩臺IBM AIX A和B。AIX A運行Oracle Primary實例，AIX B分出部分資源虛擬一個OS C，運行Oracle Standby實例。AIX B剩余大部分資源空閑，用于未來起另外一個OraclePrimary實例。

2. 兩臺存儲（EMC只是舉例）A和B，分別直連兩臺AIX A和B。存儲A存放Primary實例的日志和數(shù)據(jù)，也存放Standby實例的Redo（圖中未畫出，只有在角色未Primary時有效）。存儲B存放Standby實例的日志和數(shù)據(jù)，也存放Primary實例的Redo文件。

3. AIX也可以換普通的x86_64 PC服務器，HACMP換為支持linux的集群軟件。如Veritas HA。

功能：

1. 高可用：Oracle Primary實例不可用時，HACMP起用AIX B上的Oracle Primary實例。存儲A不可用時，將AIX C上Standby實例Failover為Primary實例。

2. 數(shù)據(jù)一致性：Redo文件在兩個存儲上都有保留，Standby實例在Failover之前應用Primary的Redo，理論上即使是Failover也不丟數(shù)據(jù)。

3. 擴展性：數(shù)據(jù)庫性能由主機aix和存儲能力決定，都可以向上擴展，成本會陡升，且有上限。

B. x86 + ORACLE RAC + EMC

架構說明：

1. 兩臺主機A和B可以是AIX，也可以是x86_64普通PC服務器，彼此網(wǎng)絡直連，同時連接共享的存儲EMCA，A和B分別運行一個RAC Primary實例。

2. 主機C可以是AIX或x86_64普通PC服務器，直連另外一個存儲B，運行Standby實例。也有的架構會有多個Standby實例，其中一個Standby實例也是RAC。

功能：

1. 高可用：Oracle RACPrimary實例無論哪個不可用，另外一個都可以自動接管服務。如果Primary實例的存儲A不可用，則將Standby實例Failover為Primary實例。

2. 數(shù)據(jù)一致性：如果Primary實例也將一組Redo 成員輸出到B存儲，則理論上可以絕對不丟數(shù)據(jù)。否則，極端情況下，F(xiàn)ailover可能會因為缺少Primary的事務日志而失敗，此時直接激活Standby實例為Primary實例，可能會丟失少量數(shù)據(jù)。

3. 擴展性：數(shù)據(jù)庫計算能力不足可以水平擴展（添加RAC節(jié)點），存儲能力不足可以向上擴展（存儲擴容）。

C. Oracle Dataguard 共享Redo

架構說明：

1. 普通x86服務器A和B，分別運行Oracle的Primary和Standby實例。彼此網(wǎng)絡直連，同時連接一個共享存儲。

2. Primary和Standby實例的Redo和控制文件、spfile都放在共享存儲上，所以占用空間非常小。數(shù)據(jù)文件放在本機上，通常是高速存儲（如SSD或者PCIE接口的Flash設備）。

功能：

1. 高可用：當Primary實例不可用時，將Standby實例Failover為Primary實例。如果共享存儲不可用，則兩個實例都不可用。通常會有第三個Standby實例。

2. 數(shù)據(jù)一致性：Standby實例在Failover之前應用Primary實例的Redo文件，不丟失事務日志，數(shù)據(jù)強一致。

3. 擴展性：無。

3. MySQL數(shù)據(jù)庫的架構方案

A. ADHA （Alibaba Database High Availability）

架構說明：

1. 使用MySQL Master-Master架構，雙向同步，Slave只讀。

2. 使用Zookeeper集群做實例不可用監(jiān)測和防止腦裂。

功能：

1. 高可用：Master實例不可用后，將Slave激活。可用性優(yōu)先。如果Slave延時超出一定閥值，放棄切換。zk集群三節(jié)點部署，可以防止腦裂。

2. 數(shù)據(jù)一致性：為盡可能少的減少數(shù)據(jù)丟失，推薦開啟單向半同步技術。同時在老Master恢復后會盡可能的彌補未及時同步到新Master的數(shù)據(jù)。由于同步依賴Binlog，理論上也是無法保證主從數(shù)據(jù)絕對一致。

3. 擴展性：可以做讀寫分離，可以新增slave擴展讀服務能力。

B. MHA （Master High Availability）

架構說明：

1. 從MySQL主從同步架構衍生出來的，使用半同步技術，所以至少有兩個從實例（Slave）。所以整體架構為一主兩從，兩個從庫不是級聯(lián)關系。

功能：

1. 高可用：Master不可用時，自動從兩個Slave里選出包含Binlog最多的Slave，并提升為Master。同時更改另外一個Slave的Master為新的Master。Master異常時，Slave上的拉取的Binlog如果有丟失(master或者slave故障時)，很容易出現(xiàn)復制中斷，因此這種高可用機制并不總是有效。

2. 數(shù)據(jù)一致性：為了盡可能少的丟失Binlog，主從同步推薦使用半同步技術。在網(wǎng)絡異常的情況下，半同步有可能降級為異步同步。MHA只是盡最大程度保證數(shù)據(jù)不丟失。且由于同步依賴的是Binlog，主從的數(shù)據(jù)理論上也并不能保證嚴格一致。

3. 擴展性：可以提供讀寫分離服務，可以新增slave節(jié)點擴展讀服務能力。

C. PXC （Percona XtraDB Cluster）

架構說明：

1. 可以兩個節(jié)點，推薦三個節(jié)點（防腦裂），組成一個Cluster。三節(jié)點同時提供讀寫服務。數(shù)據(jù)是獨立的三份，不是共享存儲。

2. 事務提交是同步復制，在所有從節(jié)點都同步提交。

功能：

1. 高可用：三節(jié)點同時提供讀寫服務，掛任意一個節(jié)點都沒有影響。

2. 數(shù)據(jù)一致性：數(shù)據(jù)強同步到所有節(jié)點，不丟數(shù)據(jù)。要求有主鍵，某些SQL不支持同步。

3. 擴展性：事務提交是同步復制，性能受限于最差的那個節(jié)點。

4. 其他：多主復制，但不能同時寫同一行數(shù)據(jù)（樂觀鎖，會報死鎖類錯誤）。另外，有寫放大弊端。

4. 分布式數(shù)據(jù)庫中間件的架構方案

A. 分布式數(shù)據(jù)庫DRDS

架構說明：

1. DRDS Server節(jié)點是一組無狀態(tài)的程序，響應SQL請求并做分庫分表路由轉換和SQL改寫、聚合計算等。支持庫和表兩級維度拆分，支持多種靈活的拆分策略，支持分布式事務。

2. MySQL節(jié)點主要是存儲數(shù)據(jù)、主備雙向同步架構，外加MySQL的PaaS平臺提供高可用切換、自動化運維能力。

3. 圍繞這個架構的還有數(shù)據(jù)同步組件（精衛(wèi)），實現(xiàn)小表廣播、異構索引表等能力。

4. 該架構最新版本在只讀實例基礎上實現(xiàn)了MPP并行計算引擎，支持部分OLAP查詢場景。

功能：

1. 高可用：計算節(jié)點（DRDS Server節(jié)點）的高可用通過前端負載均衡設備實現(xiàn)，存儲節(jié)點（MySQL）的高可用靠ADHA實現(xiàn)。RTO在40s左右，RPO>=0。

2. 數(shù)據(jù)一致性：MySQL主備同步是半同步或者異步。ADHA最大可能的降低MySQL故障切換時的主備不一致概率，理論上無法保證絕對強一致，RPO>=0。

3. 擴展性：計算和存儲節(jié)點都可以分別擴容。存儲的擴容通過MySQL實例的增加以及數(shù)據(jù)的遷移和重分布等。

4. 運維：故障時，主備強切后，會有一定概率出現(xiàn)主備同步因為數(shù)據(jù)不一致而中斷。

B. 分布式數(shù)據(jù)庫TDSQL

架構說明：

1. 計算節(jié)點：由一組無狀態(tài)的網(wǎng)關節(jié)點組成，負責SQL路由、MySQL主故障時的路由切換等。

2. 調度系統(tǒng)：用zk集群做元數(shù)據(jù)管理、監(jiān)測故障和做數(shù)據(jù)庫故障切換、彈性伸縮任務等。

3. 存儲節(jié)點：MySQL主備架構，一主兩從，做強同步或者異步同步。

4. 支持全時態(tài)數(shù)據(jù)模型

功能：

1. 高可用：網(wǎng)關前端推測也有負載均衡，MySQL主備切換依賴zk判斷，RTO在40s左右

2. 數(shù)據(jù)一致性：一主兩備使用強同步的時候，基本可以保證RPO=0. 如果是異步，可能切換時會有延遲。

3. 擴展性：通過提升網(wǎng)關能力或者個數(shù)來提升計算能力，增加MySQL節(jié)點數(shù)然后調整數(shù)據(jù)分布來提升計算和存儲能力。

4. 運維：異常時，可能出現(xiàn)主備由于數(shù)據(jù)不一致導致同步服務中斷，需要修復。

C. 分布式數(shù)據(jù)庫 GoldenDB

架構上也是分庫分表，跟DRDS原理基本相同。

D. 分布式數(shù)據(jù)庫 MyCat

架構原理和功能跟前面兩類基本相同。底層存儲節(jié)點還支持Oracle和Hive。

E. 分布式數(shù)據(jù)庫 HotDB

5. 分布式數(shù)據(jù)庫

A. google的F1

說明：

1. F1支持sql，底層可以支持MySQL和Spanner。選擇Spanner原因主要是Spanner不需要手動分區(qū)、使用Paxos協(xié)議同步數(shù)據(jù)并保證強一致以及高可用。

2. Spanner分為多個Zone部署。每個zone有一個zonemaster（管理元數(shù)據(jù)和spannerserver）、多個spannerserver。

3. Spanner的數(shù)據(jù)存儲在tablet里，每個tablet按固定大小切分為多個directory。Spanner以directory為單位做負載均衡和高可用，paxos group是對應到directory的。

4. Spanner的TrueTime 設計為分布式事務實現(xiàn)方案提供了一個新的方向（分布式MVCC）。

B. PingCap的TiDB

TiDB主要是參考Google的Spanner和F1的設計，架構上有很多相似的地方。

架構說明：

1. TiDB server負責處理SQL并做路由。無狀態(tài)，可以部署多個節(jié)點，結合負載均衡設計對外提供統(tǒng)一的接入地址。

2. PD Server 是集群的管理模塊，存儲元數(shù)據(jù)和對TiKV做任務調度和負載均衡，以及分配全局唯一遞增的事務ID。

3. TiKV Server 是存儲節(jié)點，外部看是Key-Value存儲引擎，表數(shù)據(jù)自動按固定大小（如20M，可配置）切分為多個Region分散在多臺TiKV Server上。Region是數(shù)據(jù)遷移和高可用的最小單位，Region的內容有三副本，分布在三個區(qū)域，由Raft協(xié)議做數(shù)據(jù)同步和保證強一致。

4. 支持分布式事務，最早實現(xiàn)全局一致性快照。支持全局一致性備份。

5. 兼容MySQL主要語法。

功能：

1. 可用性：計算節(jié)點無狀態(tài)部署，結合負載均衡設計保證高可用和負載均衡。存儲節(jié)點是三副本部署，使用Raft協(xié)議維持三副本數(shù)據(jù)一致性和同步，有故障時自動選舉（高可用）。

2. 擴展性：計算和存儲分離，可以單獨擴展。存儲節(jié)點擴展后，數(shù)據(jù)會重新分布，應該是后臺異步任務完成，不影響業(yè)務讀寫，可以在線擴容。可以用于做異地容災，兩地三中心異地多活（三機房之間網(wǎng)絡延時很小）

3. 數(shù)據(jù)一致性：計算節(jié)點故障不會導致數(shù)據(jù)丟失，存儲節(jié)點故障會自動選舉，新的leader跟老的leader數(shù)據(jù)是強一致的。

C. Alipay的OceanBase

OceanBase的設計思路跟Spanner類似，但在SQL、存儲、事務方面都有自己的創(chuàng)新。

架構說明：

1. 目前版本計算和存儲都集中在一個節(jié)點上（PC，OBServer）上，單進程程序，進程包括SQL引擎和存儲引擎功能。

2. 表數(shù)據(jù)存在一個或多個分區(qū)（使用分區(qū)表），需要業(yè)務指定分區(qū)規(guī)則。分區(qū)是數(shù)據(jù)遷移和高可用的最小單位。分區(qū)之間的一致性是通過MultiPaxos保證。

3. 支持分布式事務、2.x版本支持全局一致性快照。支持全局一致性備份。

4. 兼容MySQL主要用法和Oracle標準SQL用法，目前正在逐步兼容Oracle更多功能。如存儲過程、游標和Package等。目標是兼容Oracle常用功能以實現(xiàn)去IOE時應用不修改代碼的目標。

5. 有多租戶管理能力，租戶彈性擴容，租戶之間有一定資源隔離機制。

6. 應用可以通過一個反向代理obproxy或者ob提供的connector-JAVA訪問OceanBase集群。

跟Spanner的關系和區(qū)別：

1. Spanner大概2008年開始研發(fā)，2012年通過論文對外公開。首次跨地域實現(xiàn)水平擴展，并基于普通PC服務器實現(xiàn)自動高可用和數(shù)據(jù)強一致。OceanBase在2010年開始立項研發(fā)，也是基于普通PC服務器，發(fā)展出自己獨特的ACID特性和高可用技術以及拆分技術。

2. Spanner對標準SQL支持不好，不是真正的關系型數(shù)據(jù)庫，定位于內部應用。OceanBase定位于通用的分布式關系型數(shù)據(jù)庫，支持標準SQL和關系模型。基本兼容MySQL功能，逐步兼容Oracle功能。

3. Spanner借助原子鐘硬件和TrueTime設計支持全局一致性快照，提供快照讀隔離級別，對節(jié)點間網(wǎng)絡延時要求比較高。OceanBase使用軟件提供全局時間服務，實現(xiàn)了全局一致性快照功能。

4. Spanner的內部診斷跟蹤機制很欠缺，OceanBase的內部診斷分析機制功能很完善，是瞄準商業(yè)軟件標準去做的。

功能：

1. 擴展性：租戶和集群的彈性伸縮非常方便，可以在線進行，對業(yè)務寫影響可控。可以用于兩地三中心異地容災和多活（結合業(yè)務做單元化設計）。

2. 可用性：單個或多個observer不可用時，只要分區(qū)的絕大部分成員存活，則可以迅速選舉恢復服務（RTO=20s）。

3. 數(shù)據(jù)一致性：故障恢復后，數(shù)據(jù)庫數(shù)據(jù)絕對不丟。RPO=0。