楊傳輝

(阿里巴巴集團(tuán)，北京 100020)

?

OceanBase高可用方案

楊傳輝

(阿里巴巴集團(tuán)，北京 100020)

傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)基于共享存儲(chǔ)或者主備同步的方式實(shí)現(xiàn)高可用.這些方案要么依賴(lài)硬件的高可用，但成本高昂；要么無(wú)法同時(shí)滿(mǎn)足強(qiáng)一致性和高可用性.OceanBase將云計(jì)算和數(shù)據(jù)庫(kù)兩種技術(shù)有機(jī)地融合起來(lái)，實(shí)現(xiàn)了基于Paxos協(xié)議的高可用方案.該方案構(gòu)建在普通服務(wù)器上，成本低廉，且同時(shí)滿(mǎn)足強(qiáng)一致性和高可用性.

共享存儲(chǔ)； 主備同步； 高可用； 強(qiáng)一致； Paxos

0 引 言

數(shù)據(jù)庫(kù)管理系統(tǒng)廣泛應(yīng)用于銀行、信用卡交易、商品銷(xiāo)售、航空與鐵路運(yùn)輸、電信、電力系統(tǒng)、教育、醫(yī)療與健康、電子商務(wù)等各個(gè)領(lǐng)域.數(shù)據(jù)庫(kù)管理系統(tǒng)已經(jīng)成為訂票、金融、電子商務(wù)等應(yīng)用所不可缺失的核心信息系統(tǒng)[1].以“天貓雙十一”購(gòu)物節(jié)為例，開(kāi)始搶購(gòu)的1分鐘內(nèi)有1千萬(wàn)買(mǎi)家登錄天貓系統(tǒng).系統(tǒng)1個(gè)小時(shí)之內(nèi)的成交金額達(dá)到67億元，支付寶支付2 500萬(wàn)筆[2].以此推算，如果支撐交易的數(shù)據(jù)庫(kù)系統(tǒng)出現(xiàn)5分鐘不可用，將會(huì)損失成交金額約5.6億元，并損害成百上千萬(wàn)用戶(hù)的體驗(yàn).因此，持續(xù)可用是數(shù)據(jù)庫(kù)管理系統(tǒng)的核心目標(biāo).

傳統(tǒng)數(shù)據(jù)庫(kù)的高可用依賴(lài)于底層的高可用硬件，如高端服務(wù)器和高端存儲(chǔ)等.雖然這些方案部分滿(mǎn)足了高可用需求，然而它們成本高昂，且不可擴(kuò)展，無(wú)法滿(mǎn)足互聯(lián)網(wǎng)業(yè)務(wù)應(yīng)用的需要.互聯(lián)網(wǎng)業(yè)務(wù)要求底層的數(shù)據(jù)庫(kù)系統(tǒng)構(gòu)建在普通的服務(wù)器上，并假設(shè)故障不可避免.這些故障可能是硬件故障，如硬盤(pán)故障；也可能是天災(zāi)，如地震、火災(zāi)等.

OceanBase[3]高可用方案構(gòu)建在不可靠的主流PC服務(wù)器上，通過(guò)軟件實(shí)現(xiàn)自動(dòng)容錯(cuò)，使得系統(tǒng)內(nèi)部故障對(duì)外部使用者不可見(jiàn).這種方案成本低廉，且同時(shí)滿(mǎn)足強(qiáng)一致性和高可用性.OceanBase的高可用方案使得它能夠被廣泛應(yīng)用在淘寶、天貓、支付寶等多個(gè)阿里巴巴集團(tuán)核心業(yè)務(wù)的生產(chǎn)環(huán)境中.

1 傳統(tǒng)數(shù)據(jù)庫(kù)高可用方案

1.1 高可用集群

Oracle的集群方案[4]如圖1所示.多個(gè)數(shù)據(jù)庫(kù)實(shí)例(Node1-Node3)通過(guò)高端的存儲(chǔ)區(qū)域網(wǎng)(SAN，Storage Area Network)訪問(wèn)共享存儲(chǔ).數(shù)據(jù)庫(kù)的數(shù)據(jù)文件和操作日志都需要持久化到共享存儲(chǔ).當(dāng)某個(gè)數(shù)據(jù)庫(kù)實(shí)例出現(xiàn)故障時(shí)，集群中的其它數(shù)據(jù)庫(kù)實(shí)例能通過(guò)共享存儲(chǔ)來(lái)恢復(fù)服務(wù).可以看到，數(shù)據(jù)庫(kù)的整體可用性取決于共享存儲(chǔ)的可用性.

圖1 Oracle集群方案

為了保證性能，數(shù)據(jù)庫(kù)實(shí)例和共享存儲(chǔ)之間一般采用專(zhuān)用的InfiniBand網(wǎng)絡(luò)，其帶寬可達(dá)40 Gbit/s，延遲為1 μs.與之對(duì)比，普通的局域網(wǎng)之間的網(wǎng)絡(luò)延遲一般為250 μs左右.因此，數(shù)據(jù)庫(kù)實(shí)例和共享存儲(chǔ)必須部署在同一個(gè)數(shù)據(jù)中心內(nèi)，無(wú)法容忍單個(gè)數(shù)據(jù)中心整體故障.另外，InfiniBand網(wǎng)絡(luò)和共享存儲(chǔ)價(jià)格高昂，且容量不夠時(shí)很難擴(kuò)展.

1.2 主備同步

另外一種常見(jiàn)的數(shù)據(jù)庫(kù)高可用方案為主備同步[5].

如圖2所示，數(shù)據(jù)庫(kù)主機(jī)(Primary DataBase)將重做日志(Redo Log)同步到備機(jī)(Standby DataBase).主機(jī)提供服務(wù)，執(zhí)行讀寫(xiě)事務(wù)，備機(jī)可以執(zhí)行不要求讀到最新數(shù)據(jù)的讀事務(wù).當(dāng)主機(jī)出現(xiàn)故障時(shí)，備機(jī)可以替換為主機(jī)繼續(xù)提供服務(wù).

主備同步往往分為3種模式：

圖2 Oracle主備同步

? 最大保護(hù)模式：任何一個(gè)事務(wù)必須首先同步到備機(jī)，接著在主機(jī)執(zhí)行成功，才能應(yīng)答客戶(hù)端成功；

? 最大性能模式：事務(wù)只需要在主機(jī)執(zhí)行成功，就可以應(yīng)答客戶(hù)端成功；

? 最大可用模式：當(dāng)備機(jī)以及主備之間網(wǎng)絡(luò)正常時(shí)，采用最大保護(hù)模式，即任何一個(gè)事務(wù)都需要首先同步到備機(jī)；當(dāng)備機(jī)或者主備之間網(wǎng)絡(luò)出現(xiàn)故障時(shí)，退化到最大性能模式，即只需要在主機(jī)執(zhí)行成功.

假設(shè)采用最大保護(hù)模式，當(dāng)備機(jī)或者主備之間網(wǎng)絡(luò)出現(xiàn)故障時(shí)，無(wú)法提供服務(wù)，系統(tǒng)的可用性受到影響.假設(shè)采用最大性能模式，當(dāng)主機(jī)出現(xiàn)故障時(shí)，備機(jī)的數(shù)據(jù)往往落后于主機(jī)，如果將服務(wù)切到備機(jī)，可能丟失最后提交的一部分事務(wù)，出現(xiàn)數(shù)據(jù)不一致.最大可用模式也有類(lèi)似的問(wèn)題，當(dāng)主機(jī)出現(xiàn)時(shí)，備機(jī)無(wú)法知道是否和主機(jī)完全一致，如果要求強(qiáng)一致性，也無(wú)法將服務(wù)切到備機(jī).

1.3 最高可用性

傳統(tǒng)數(shù)據(jù)庫(kù)中，可以將高可用集群和主備同步2種方案組合起來(lái)，實(shí)現(xiàn)最高可用性(MAA，Maximum Availability Architecture)體系結(jié)構(gòu)[6].圖3中有2個(gè)數(shù)據(jù)中心，IDC-1為主，IDC-2為備.IDC-1和IDC-2內(nèi)部通過(guò)共享存儲(chǔ)實(shí)現(xiàn)高可用集群，IDC-1和IDC-2之間通過(guò)主備同步的方式同步操作日志.可以看到，只要IDC-1內(nèi)部的共享存儲(chǔ)不出現(xiàn)問(wèn)題，系統(tǒng)都能正常服務(wù).當(dāng)IDC-1內(nèi)部的共享存儲(chǔ)出現(xiàn)問(wèn)題或者IDC-1整體故障，IDC-2和IDC-1之間雖然可能不一致，不過(guò)相差不會(huì)太多，如果IDC-1永遠(yuǎn)無(wú)法恢復(fù)，可以忍受損失一部分?jǐn)?shù)據(jù)的代價(jià)把IDC-2強(qiáng)制切為主后繼續(xù)提供服務(wù).

總而言之，即使通過(guò)高昂的成本實(shí)現(xiàn)了最高可用性，當(dāng)整個(gè)數(shù)據(jù)中心或者共享存儲(chǔ)出現(xiàn)故障時(shí)，都無(wú)法將服務(wù)無(wú)損地切換到備份的數(shù)據(jù)中心.也就是說(shuō)，只要保證強(qiáng)一致性，就無(wú)法做到數(shù)據(jù)中心容災(zāi)；只要實(shí)現(xiàn)數(shù)據(jù)中心容災(zāi)，就無(wú)法做到強(qiáng)一致性.

2 OceanBase高可用方案

OceanBase高可用方案構(gòu)建在普通的PC服務(wù)器之上，假設(shè)硬件故障是常態(tài)，實(shí)現(xiàn)時(shí)使用了主備強(qiáng)同步策略和分布式選舉協(xié)議.當(dāng)主機(jī)出現(xiàn)問(wèn)題時(shí)，它保證至少有一個(gè)備機(jī)和主機(jī)完全同步，并通過(guò)分布式選舉協(xié)議選出唯一的總控節(jié)點(diǎn)執(zhí)行主備切換，既保證了強(qiáng)一致性，又實(shí)現(xiàn)了高可用性.

圖3 最高可用性體系結(jié)構(gòu)

2.1 3機(jī)房架構(gòu)

如圖4，OceanBase部署為3個(gè)集群，每個(gè)集群包含如下4種角色：

圖4 OceanBase 3集群架構(gòu)

(1) MergeServer：OceanBase的應(yīng)用接口，支持JDBC/ODBC協(xié)議，負(fù)責(zé)進(jìn)行SQL解析并生成執(zhí)行計(jì)劃.

(2) ChunkServer：保存存儲(chǔ)于sstable的基線(xiàn)數(shù)據(jù)，并提供讀訪問(wèn).為了防止由于ChunkServer故障導(dǎo)致服務(wù)不可用甚至數(shù)據(jù)丟失，每個(gè)sstable保存了多個(gè)副本并分布在不同的ChunkServer上.

(3) RootServer：OceanBase的總控中心，負(fù)責(zé)ChunkServer/MergeServer的上線(xiàn)、下線(xiàn)管理以及sstable的負(fù)載均衡.

(4) UpdateServer：執(zhí)行寫(xiě)事務(wù)、保存修改增量(到內(nèi)存)、寫(xiě)重做日志(redo log)(到磁盤(pán))并提供讀服務(wù).

其中，RootServer以及UpdateServer和本文闡述的高可用性方案有關(guān).UpdateServer分為主UpdateServer和備UpdateServer 2種角色.同一時(shí)刻，只有一個(gè)UpdateServer為主UpdateServer.每個(gè)寫(xiě)事務(wù)都需要在主UpdateServer執(zhí)行成功并且同步到至少一臺(tái)備UpdateServer，才可以應(yīng)答客戶(hù)端.當(dāng)主UpdateServer出現(xiàn)故障時(shí)，至少有一臺(tái)備UpdateServer和主UpdateServer完全同步，可以切換為主UpdateServer繼續(xù)提供服務(wù).

UpdateServer主備切換操作由RootServer來(lái)執(zhí)行，同一時(shí)刻只有一臺(tái)RootServer為主機(jī).當(dāng)主RootServer出現(xiàn)故障時(shí)，需要通過(guò)基于Paxos的分布式選舉協(xié)議保證有且只有一臺(tái)備RootServer被選為主RootServer繼續(xù)提供服務(wù)，從而保證強(qiáng)一致性和高可用性.

2.2 主備強(qiáng)同步

UpdateServer每次執(zhí)行一個(gè)寫(xiě)事務(wù)時(shí)，都會(huì)生成一條操作日志，同步到備機(jī)并寫(xiě)入到本地磁盤(pán)，接著在內(nèi)存中應(yīng)用事務(wù)的修改操作.OceanBase的強(qiáng)同步策略要求至少同步成功一臺(tái)備機(jī)，才可以應(yīng)答客戶(hù)端.

如圖5，假設(shè)DB1為主機(jī)，DB2和DB3為備機(jī)，DB1包含8個(gè)事務(wù)，其中，DB2已經(jīng)收到前6個(gè)事務(wù)，DB3只收到前4個(gè)事務(wù).由于前6個(gè)事務(wù)已經(jīng)同步到DB2，因此認(rèn)為事務(wù)“已提交”，可以應(yīng)答客戶(hù)端；而后面2個(gè)事務(wù)沒(méi)有同步到任何備機(jī)，處于“未決”狀態(tài).當(dāng)DB1出現(xiàn)故障時(shí)，OceanBase會(huì)選擇日志號(hào)最大的備機(jī)切換為主機(jī).假設(shè)DB2切換為主機(jī)，那么，前6個(gè)已經(jīng)提交的事務(wù)將恢復(fù)，后面2個(gè)“未決”事務(wù)將被回滾；假設(shè)DB1再次參與到故障恢復(fù)過(guò)程并且重新選為主機(jī)，那么，后面2個(gè)“未決”事務(wù)將會(huì)被最終提交.

為了提高主備同步的性能，UpdateServer實(shí)現(xiàn)了一些優(yōu)化措施，包括：

圖5 OceanBase主備日志同步

(1) 成組提交(group commit)：每次執(zhí)行寫(xiě)事務(wù)都需要將對(duì)應(yīng)的操作日志寫(xiě)磁盤(pán)并同步到備機(jī).成組提交技術(shù)將正在并發(fā)執(zhí)行的事務(wù)的操作日志打包到一個(gè)緩沖區(qū)中，一次性刷盤(pán)并同步備機(jī)，從而提升數(shù)據(jù)庫(kù)系統(tǒng)的整體吞吐量.

(2) 異步化：UpdateServer執(zhí)行寫(xiě)事務(wù)時(shí)，除了寫(xiě)磁盤(pán)，還需要同步到多個(gè)備機(jī).實(shí)現(xiàn)時(shí)將寫(xiě)磁盤(pán)以及同步備機(jī)操作完全異步化，從而降低事務(wù)延時(shí).

(3) 降低鎖粒度：UpdateServer提交事務(wù)時(shí)需要將并發(fā)執(zhí)行的事務(wù)的操作日志拷貝到日志緩沖區(qū)并且保證順序，當(dāng)海量事務(wù)并發(fā)執(zhí)行時(shí)，日志緩沖區(qū)的鎖沖突非常嚴(yán)重.UpdateServer實(shí)現(xiàn)時(shí)盡可能降低拷貝日志的鎖粒度，在保證順序的前提下，允許將多個(gè)并發(fā)事務(wù)的操作日志同時(shí)拷貝到日志緩沖區(qū).

2.3 分布式選舉

OceanBase包含多個(gè)RootServer，同一個(gè)時(shí)刻只允許有一個(gè)RootServer作為主RootServer提供服務(wù).當(dāng)主RootServer出現(xiàn)故障或者整個(gè)集群重新啟動(dòng)時(shí)，OceanBase通過(guò)分布式選舉協(xié)議選出唯一的主RootServer.

分布式選舉協(xié)議往往基于Lamport提出的Paxos協(xié)議[7].Paxos協(xié)議假設(shè)：

1. 成員不說(shuō)假話(huà)(非拜占庭式).

2. 單個(gè)成員說(shuō)話(huà)不自相矛盾.

3. 任何決議需要“多數(shù)派”同意.

假設(shè)有2N+1個(gè)成員，那么，N+1個(gè)成員構(gòu)成“多數(shù)派”.如果某個(gè)決議得到了“多數(shù)派”的同意，且任何一個(gè)成員說(shuō)話(huà)不自相矛盾，那么，顯然不會(huì)存在另外一個(gè)“多數(shù)派”同意其他的決議.因此，可以證明協(xié)議的正確性.然而，協(xié)議的可終止性無(wú)法得到證明，可能出現(xiàn)永遠(yuǎn)無(wú)法達(dá)成一致的情況.另外，Paxos協(xié)議，尤其是多輪Paxos協(xié)議(Multi Paxos)非常復(fù)雜，工程上更是難以實(shí)現(xiàn).目前已經(jīng)有一些開(kāi)源的工程實(shí)現(xiàn)對(duì)Paxos協(xié)議做了很大的簡(jiǎn)化，例如Raft[8]，而OceanBase則做得更加徹底.

OceanBase將Paxos協(xié)議改造成如下的“同步模式”.

如圖6，所有成員在同一時(shí)刻(T1)“同時(shí)”發(fā)起選舉，執(zhí)行步驟如下：

圖6 OceanBase選舉協(xié)議

1. T1時(shí)刻：預(yù)投票，即每個(gè)成員廣播自己的“投票權(quán)重”；

2. T2(>T1)時(shí)刻：投票，即每個(gè)成員向收到的“投票權(quán)重”最大者投票；

3. T3(>T2)時(shí)刻：計(jì)票并廣播，即統(tǒng)計(jì)投票，得票過(guò)半者當(dāng)選新主并向所有成員廣播；

4. T4(>T3)時(shí)刻：選舉結(jié)束，成員接收到新主當(dāng)選的廣播.

與Paxos協(xié)議類(lèi)似，新主當(dāng)選要求獲得“多數(shù)派”同意，因此，最多選出一個(gè)新主，協(xié)議的正確性得到證明.另外，由于所有成員“同時(shí)”發(fā)起選舉，只要成員之間時(shí)鐘偏差不會(huì)太大，且“多數(shù)派”工作正常，都能夠選出新主.OceanBase集群采用ntp協(xié)議來(lái)做時(shí)鐘同步，大部分情況下成員之間的時(shí)鐘偏差都在幾毫秒之內(nèi)，最壞情況下也不會(huì)超過(guò)100 ms，從而保證選舉協(xié)議是可終止的.

新主當(dāng)選后，允許在租約有效期內(nèi)提供服務(wù).當(dāng)租約快到期時(shí)，主機(jī)可以發(fā)起“有主選舉”來(lái)續(xù)約，使自己再次被選為主.如果主機(jī)出現(xiàn)故障，那么，OceanBase會(huì)在它的租約過(guò)期后發(fā)起新的分布式選舉過(guò)程，其他成員可以被選為新主繼續(xù)提供服務(wù).

下面分析協(xié)議的選舉時(shí)間.假設(shè)成員之間的時(shí)鐘偏差最大為T(mén)diff，網(wǎng)絡(luò)來(lái)回最大延遲為T(mén)st.那么，某個(gè)成員在T1時(shí)刻發(fā)送預(yù)投票后，其他成員最晚在T1+2*Tdiff+Tst時(shí)刻收到預(yù)投票. 也就是說(shuō)，T2等于T1+2*Tdiff+Tst，每個(gè)成員收到所有其他在線(xiàn)成員的預(yù)投票請(qǐng)求后開(kāi)始投票，保證不會(huì)錯(cuò)過(guò)任何一個(gè)成員的預(yù)投票請(qǐng)求.同理，T3等于T2+2*Tdiff+Tst，每個(gè)成員收到所有其他在線(xiàn)成員的投票請(qǐng)求后開(kāi)始計(jì)票，保證不會(huì)錯(cuò)過(guò)任何一個(gè)成員的投票請(qǐng)求.T4等于T3+2*Tdiff+Tst，每個(gè)成員收到所有其他在線(xiàn)成員的廣播請(qǐng)求后選舉過(guò)程結(jié)束.綜上所述，T4等于T1+6*Tdiff+3* Tst，一次選舉過(guò)程耗時(shí)Telect等于6*Tdiff+3* Tst.之前已經(jīng)提到，ntp協(xié)議保證時(shí)鐘偏差最大不超過(guò)100 ms，即Tdiff等于100 ms；而網(wǎng)絡(luò)延遲Tst往往不超過(guò)200 ms，可以算出Telect等于6*Tdiff+3* Tst= 1 200ms.選舉協(xié)議額外保留200 ms，得到擴(kuò)展的選舉時(shí)間Telect2等于1 200 ms + 200 ms = 1 400 ms，即1.4 s.

OceanBase租約有效期為4倍選舉時(shí)間，即5.6 s；選舉周期為5倍選舉時(shí)間，即7 s.當(dāng)主機(jī)出現(xiàn)故障，OceanBase會(huì)等到它的租約過(guò)期后，在選舉周期的整數(shù)倍時(shí)間點(diǎn)發(fā)起新的分布式選舉過(guò)程.因此，最壞情況下，從主機(jī)故障到選出新主的時(shí)間為5.6 s(租約有效期) + 7 s(選舉周期) + 1.2 s(選舉時(shí)間)，即13.8 s.

2.4 優(yōu)缺點(diǎn)

Google Spanner和Raft系統(tǒng)中都實(shí)現(xiàn)了基于Paxos協(xié)議的高可用方案.其中，Spanner[9]中采用原生的Paxos協(xié)議，Raft對(duì)協(xié)議進(jìn)行了簡(jiǎn)化.OceanBase進(jìn)一步將Paxos協(xié)議由“異步模式”改進(jìn)為“同步模式”，工程實(shí)現(xiàn)上更加簡(jiǎn)單，且能夠保證最長(zhǎng)約2個(gè)選舉周期就能選出新主.無(wú)論是Spanner還是Raft，都無(wú)法做到這一點(diǎn).然而，OceanBase選舉協(xié)議依賴(lài)時(shí)鐘同步，要求多臺(tái)服務(wù)器之間的時(shí)鐘偏差不能過(guò)大，底層的ntp服務(wù)需要嚴(yán)格保證這一點(diǎn).

3 結(jié) 論

本文介紹了傳統(tǒng)數(shù)據(jù)庫(kù)的高可用方案，分析了其中的不足，并給出了OceanBase高可用方案以及其中的幾個(gè)性能優(yōu)化措施.OceanBase高可用方案同時(shí)滿(mǎn)足強(qiáng)一致性和高可用性，且成本低廉，是未來(lái)數(shù)據(jù)庫(kù)高可用的趨勢(shì).

[1] RAMAKRISHNAN R, GEHRKE J. Database management systems[M]. 3rd ed.[s.l]: McGraw-Hill, 2003.

[2] 雙十一戰(zhàn)記[EB/OL].http://ucwap.ifeng.com/tech/hulianwang/news?aid=73824780.

[3] OceanBase開(kāi)源[EB/OL].http://alibaba.github.io/oceanbase/.

[4] GOPALAKRISHNAN K. Oracle database 11g oracle real application clusters handbook[M]. 2nd ed.[s.l]:Oracle Press, 2011.

[5] Oracle data guard[EB/OL].http://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm.

[6] Oracle maximum availability architecture[EB/OL]. [2014-08-31].http://www.oracle.com/technetwork/database/availability/maa-consolidation-2186395.pdf?ssSourceSiteId=ocomuk.

[7] LAMPORT L. The part-time parliament[J]. ACM TOCS, 1998, 16(2): 133-169.

[8] ONGARO D, OUSTERHOUT J. In search of an understandable consensus algorithm[C]//Proceedings of the 2014 USENIX Annual Technical Conference. 2014: 305-319.

[9] CORBETT J C, DEAN J, EPSTEIN M, et al. Spanner: Google’s globally-distributed database[C]. OSDI’12, 2012:251-264.

(責(zé)任編輯 林 磊)

High availability solution of OceanBase

YANG Chuan-hui

(AlibabaInc.,Beijing100020,China)

Shared storage or master-slave replication is used in traditional RDBMS to achieve high availability. The first solution relies on high available hardware, and so are of high cost, while the second solution cannot meet the requirements of strong consistency and high availability concurrently. OceanBase combines cloud computing and database technology. Its high availability solution is based on Paxos protocol. This solution is built on top of commodity machine. It meets requirements of both strong consistency and high availability with low cost.

shared storage; master-slave replication; high availability; strong consistency; Paxos

1000-5641(2014)05-0173-07

2014-06

楊傳輝，男，阿里巴巴集團(tuán)技術(shù)專(zhuān)家，研究方向?yàn)榉植际綌?shù)據(jù)庫(kù). E-mail: rizhao.ych@alipay.com.

TP31

A

10.3969/j.issn.1000-5641.2014.05.015