OceanBase一致性與可用性分析

周 歡， 樊秋實， 胡華梁，2

（1.華東師范大學(xué) 軟件學(xué)院，上海 200062；2.浙江理工大學(xué) 經(jīng)濟(jì)管理學(xué)院，杭州 310018）

0 引 言

寬帶、無線和移動終端的普及，方便了用戶通過瀏覽器和移動APP來訪問各類信息系統(tǒng)，也使得信息系統(tǒng)的用戶規(guī)模和負(fù)載情況發(fā)生了巨大的變化.例如，數(shù)千萬用戶可以通過手機(jī)APP隨時訪問和操作自己的銀行賬戶；傳統(tǒng)商用數(shù)據(jù)庫系統(tǒng)的并發(fā)處理能力和系統(tǒng)可擴(kuò)展性，已經(jīng)難以滿足互聯(lián)網(wǎng)時代對數(shù)據(jù)存儲和處理能力的需求；熱門理財產(chǎn)品，短時間內(nèi)可能出現(xiàn)上百萬的并發(fā)訪問請求.

近年來，采用分布式架構(gòu)的具有良好擴(kuò)展性和靈活性的數(shù)據(jù)管理技術(shù)和產(chǎn)品不斷涌現(xiàn)，并且被廣泛應(yīng)用于各種互聯(lián)網(wǎng)應(yīng)用中，例如 Big Table［1］、Spanner［2］、OceanBase［3］等.雖然這些系統(tǒng)多數(shù)擁有存儲和管理海量數(shù)據(jù)的能力，但在數(shù)據(jù)一致性和事務(wù)處理能力上，同傳統(tǒng)的關(guān)系數(shù)據(jù)庫產(chǎn)品還有差距，很難被直接應(yīng)用于銀行業(yè)務(wù)系統(tǒng)等傳統(tǒng)的大型信息系統(tǒng)中.與論壇、微博等互聯(lián)網(wǎng)應(yīng)用不同，以銀行業(yè)務(wù)為代表的金融領(lǐng)域信息系統(tǒng)對于數(shù)據(jù)庫的可用性和一致性有非常高的要求.Brewer的CAP理論［4］指出，分布式系統(tǒng)不可能同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯性（Partition Tolerance），最多只能同時較好地滿足其中兩個.在選擇和應(yīng)用一個分布式數(shù)據(jù)庫產(chǎn)品時，對于該產(chǎn)品在一致性、可用性和分區(qū)容錯性之間的取舍進(jìn)行衡量，確認(rèn)該產(chǎn)品能在多大程度上保證數(shù)據(jù)庫的強(qiáng)一致性和高可用性，是決定這個產(chǎn)品能否被應(yīng)用于金融領(lǐng)域信息系統(tǒng)的關(guān)鍵.

OceanBase是阿里巴巴集團(tuán)研發(fā)的開源分布式關(guān)系數(shù)據(jù)庫產(chǎn)品，具有可擴(kuò)展性、高可用性和低成本等特征.目前，該產(chǎn)品已經(jīng)被成功應(yīng)用于阿里巴巴集團(tuán)的淘寶和天貓等平臺上的業(yè)務(wù)系統(tǒng)，還將被應(yīng)用于支付寶等金融類業(yè)務(wù)系統(tǒng).分析和研究OceanBase系統(tǒng)的一致性和可用性，將有助于該系統(tǒng)的進(jìn)一步研發(fā)和應(yīng)用，有利于推動各類信息系統(tǒng)建設(shè)中的數(shù)據(jù)管理技術(shù)的發(fā)展.本文作者參與了使用OceanBase作為數(shù)據(jù)庫平臺的應(yīng)用系統(tǒng)開發(fā)，對于OceanBase有一定的了解.本文試圖通過分析和研究OceanBase系統(tǒng)的源代碼和文檔，對該系統(tǒng)的一致性和可用性做出客觀評價，以期能夠?qū)ζ渌芯亢烷_發(fā)人員有所幫助.

為了便于理解和閱讀，本文首先在第1節(jié)中介紹了數(shù)據(jù)庫系統(tǒng)一致性和可用性的概念，以及用于保障一致性和可用性的協(xié)議和技術(shù)；第2節(jié)對OceanBase兩個最新版本（0.4.2和0.5）的架構(gòu)和實現(xiàn)技術(shù)進(jìn)行了介紹，并對其各自實現(xiàn)一致性和可用性的策略進(jìn)行了分析；針對OceanBase的單點寫性能的問題，第3節(jié)對OceanBase未來可能的架構(gòu)演變方案進(jìn)行了探討，同時對架構(gòu)演變可能對系統(tǒng)一致性和可用性的影響進(jìn)行了分析；第4節(jié)對全文進(jìn)行了總結(jié)，并根據(jù)OceanBase系統(tǒng)的現(xiàn)狀提出了對應(yīng)用開發(fā)者的建議.

1 一致性與可用性背景

可用性是指系統(tǒng)在面對各種異常時可以提供正常服務(wù)的能力.系統(tǒng)的可用性可以用系統(tǒng)停止服務(wù)時間與正常服務(wù)時間的比例來衡量；例如，某個系統(tǒng)的可用性為5個9（99.999%），相當(dāng)于系統(tǒng)一年停止服務(wù)的時間不能超過365＊24＊60／100 000＝5.25 min.為了保證系統(tǒng)的高可靠和高可用，數(shù)據(jù)在系統(tǒng)中一般存儲多個副本，而多個副本又可能帶來數(shù)據(jù)不一致的問題.一致性是指對同一客戶端而言，讀操作總能讀取到最新完成的寫操作結(jié)果.一致性和可用性是相互矛盾的.為了保證數(shù)據(jù)一致性，各個副本之間需要時刻保持強(qiáng)同步；但是當(dāng)某一副本出現(xiàn)故障時，可能阻塞系統(tǒng)的正常寫服務(wù)，從而影響系統(tǒng)的可用性；如果各副本之間不保持強(qiáng)同步，雖然系統(tǒng)的可用性相對較好，但是一致性卻得不到保障，當(dāng)某一副本出現(xiàn)故障時，數(shù)據(jù)還可能丟失.因此，數(shù)據(jù)庫設(shè)計時需要權(quán)衡系統(tǒng)的一致性和可用性.

傳統(tǒng)數(shù)據(jù)庫依賴高端服務(wù)器采用共享存儲或者主備庫同步的方式實現(xiàn)系統(tǒng)的一致性和可用性.主備庫同步包括3種模式［5］：

1）最大保護(hù)模式 事務(wù)必須先同步到備庫，主庫才能應(yīng)答客戶端成功；

2）最大性能模式 事務(wù)異步同步到備庫，只要主庫執(zhí)行成功就可以應(yīng)答客戶端；

3）最大可用模式 事務(wù)盡力同步到備庫，當(dāng)主備庫之間網(wǎng)絡(luò)正常時，采用最大保護(hù)模式；當(dāng)主備庫之間網(wǎng)絡(luò)出現(xiàn)故障時，退化為最大性能模式.

3種模式支持了不同程度的一致性和可用性，最大保護(hù)模式能夠保證主備庫數(shù)據(jù)的一致性，但是當(dāng)備庫或者主備庫之間出現(xiàn)網(wǎng)絡(luò)故障時，系統(tǒng)將無法提供服務(wù)；最大性能模式能夠保證系統(tǒng)的高可用性，但是主備庫的數(shù)據(jù)不能保證完全一致，當(dāng)主庫出現(xiàn)故障時，則可能導(dǎo)致數(shù)據(jù)不一致；最大可用性模式介于最大保護(hù)模式和最大性能模式之間，當(dāng)主備庫之間網(wǎng)絡(luò)正常時保證數(shù)據(jù)一致性，當(dāng)網(wǎng)絡(luò)出現(xiàn)故障時保證系統(tǒng)的可用性，但是當(dāng)主備庫之間的網(wǎng)絡(luò)和主庫同時出現(xiàn)故障時，主備庫的數(shù)據(jù)可能不一致.在應(yīng)用生產(chǎn)中，為了兼顧系統(tǒng)的一致性和可用性一般選擇最大可用模式.

隨著數(shù)據(jù)規(guī)模越來越大，Oracle、微軟、SAP等傳統(tǒng)數(shù)據(jù)庫系統(tǒng)軟件公司自主研發(fā)或收購了一批分布式數(shù)據(jù)庫管理系統(tǒng)，如 Oracle Berkeley DB［6］、SAP HANA［7］、VoltDB［8］等，來解決傳統(tǒng)數(shù)據(jù)庫在處理互聯(lián)網(wǎng)應(yīng)用時的低并發(fā)處理能力和不易擴(kuò)展等問題.這些高性能數(shù)據(jù)庫管理系統(tǒng)大多采用存儲多個數(shù)據(jù)副本的方式來保證可用性和可靠性，使用不同的一致性協(xié)議和并發(fā)控制技術(shù)來保證一致性.在分布式環(huán)境下，數(shù)據(jù)通過分區(qū)和復(fù)制的方式分布在不同的PC服務(wù)器上，分布式數(shù)據(jù)庫的一致性包括以下兩個方面.

1）副本一致性 同一數(shù)據(jù)的多個副本之間的一致性；

2）事務(wù)一致性 在分布式并發(fā)事務(wù)場景下，不同數(shù)據(jù)之間事務(wù)的一致性.

要保證數(shù)據(jù)一致性，需要所有副本有一個本地操作執(zhí)行更新的確切時間；例如，副本可以使用Lamport時間戳［9］來決定執(zhí)行操作的全局順序，或者用一個協(xié)調(diào)器來分配這樣一個順序.然而，CAP定理證明了一致性、可用性、分區(qū)容錯性三者無法兼得.在大規(guī)模分布的系統(tǒng)中，由于網(wǎng)絡(luò)分區(qū)無法避免，因此為了保證系統(tǒng)的可用性和分區(qū)容錯性，提出了多種一致性模型［10］，通常分為三種.

1）強(qiáng)一致性 數(shù)據(jù)在任一副本上被更新成功后，后續(xù)任何對該數(shù)據(jù)的讀取操作都能得到最新的值.

2）弱一致性 在一定的時間窗口內(nèi)，對某一數(shù)據(jù)的讀取操作得不到最新的值.

3）最終一致性 是弱一致性的特例，系統(tǒng)確保最終所有訪問都能得到更新的數(shù)據(jù).

根據(jù)應(yīng)用對數(shù)據(jù)一致性的不同容忍程度，系統(tǒng)可以選擇不同的一致性模型.在分布式系統(tǒng)領(lǐng)域，實現(xiàn)副本一致性的協(xié)議有很多.例如，Paxos［11］協(xié)議和基于主副本的強(qiáng)同步復(fù)制協(xié)議［10］實現(xiàn)了副本的強(qiáng)一致性，HDFS采用的NRW協(xié)議［12］實現(xiàn)了副本最終一致性.保證事務(wù)一致性的協(xié)議和技術(shù)也有很多.例如，兩階段提交協(xié)議（2PC）［13］保證了分布式事務(wù)的原子性；向量時鐘（Vector Clock）技術(shù)［10］、分布式加鎖機(jī)制、Chubby互斥鎖機(jī)制［14］、全球時鐘同步機(jī)制TrueTime技術(shù)［2］和多版本并發(fā)控制（MVCC）解決了分布式環(huán)境下的并發(fā)沖突保證了數(shù)據(jù)正確性.兩階段提交協(xié)議是阻塞協(xié)議，執(zhí)行過程中需要鎖住其他更新并且有大量的網(wǎng)絡(luò)通信開銷，為了提高保證系統(tǒng)的可用性和高性能，大多分布式系統(tǒng)選擇盡量避免分布式事務(wù).為了更好地兼顧可用性和一致性，在實際應(yīng)用中，常常通過將應(yīng)用在邏輯上進(jìn)行分區(qū)，在分區(qū)內(nèi)實現(xiàn)強(qiáng)一致性；在分區(qū)間通過應(yīng)用層的處理解決網(wǎng)絡(luò)分區(qū)故障帶來的一致性問題，從而保證系統(tǒng)的可用性.

在數(shù)據(jù)庫實現(xiàn)中，為了保證并發(fā)事務(wù)操作之間相互不受影響，采用兩階段封鎖實現(xiàn)事務(wù)的串行化；但事務(wù)串行化執(zhí)行將導(dǎo)致很多資源得不到充分利用，大大降低了系統(tǒng)并發(fā)能力.為了提高讀寫性能，數(shù)據(jù)庫支持在數(shù)據(jù)的不同粒度［15］上進(jìn)行加鎖并且放松釋放鎖的時間；例如在行粒度上進(jìn)行加讀鎖和寫鎖，讀鎖可以在讀操作結(jié)束之后立即釋放，不用等到事務(wù)結(jié)束之后才釋放.在保證事務(wù)寫操作串行執(zhí)行的基礎(chǔ)上適當(dāng)放寬讀操作的要求，從而產(chǎn)生了4個事務(wù)隔離級別.

1）序列化（Serializable）：提供嚴(yán)格的事務(wù)隔離.要求事務(wù)序列化執(zhí)行，即事務(wù)只能一個接一個執(zhí)行，不能并發(fā)執(zhí)行.實現(xiàn)序列化需要鎖定整張表，并且讀鎖和寫鎖在事務(wù)提交之后才能釋放.

2）可重復(fù)讀（Repeatable Read）：要求在一個事務(wù)中可以多次讀取某些數(shù)據(jù)，且每次讀取的結(jié)果相同，并且只能讀到已提交的數(shù)據(jù).但是有時會產(chǎn)生幻讀，即重復(fù)讀取的結(jié)果集中存在一條新插入的記錄.實現(xiàn)可重復(fù)讀是在一定范圍內(nèi)加讀、寫鎖，并且讀鎖和寫鎖在事務(wù)提交之后才能釋放.

3）讀已提交數(shù)據(jù)（Read Committed）：要求每次讀取必須是已提交的數(shù)據(jù).但是可以出現(xiàn)不可重復(fù)讀和幻讀.讀已提交數(shù)據(jù)是在單行記錄上加讀、寫鎖，并且讀鎖在讀取單條記錄結(jié)束之后立即釋放，寫鎖要在事務(wù)提交之后才能釋放.

4）讀未提交數(shù)據(jù)（Read Uncommited）：允許讀取沒有提交的數(shù)據(jù)，但不允許更新丟失.讀未提交數(shù)據(jù)是在單行記錄上加寫鎖.寫鎖需要等到事務(wù)提交之后才能釋放，這里的寫鎖排斥其他寫事務(wù)，但允許讀取該行數(shù)據(jù).

采用多版本并發(fā)控制實現(xiàn)的分布式數(shù)據(jù)庫還提供另一種隔離級別——快照（Snapshot）讀，即讀取某一時間戳的數(shù)據(jù).數(shù)據(jù)研究和設(shè)計者發(fā)現(xiàn)，實現(xiàn)高可用的分布式數(shù)據(jù)庫無法提供序列化和可重復(fù)讀的隔離級別，因此大多主流數(shù)據(jù)管理系統(tǒng)都將讀已提交（Read Committed）作為缺省隔離級別，如 MemSQL1b［16］、Oracle 11g［16］、SAP HANA 等.

2 OceanBase的一致性與可用性

OceanBase是阿里巴巴集團(tuán)研發(fā)的，具有高可用性、高性能、強(qiáng)一致性和支持跨行跨表事務(wù)等特點的分布式數(shù)據(jù)庫.OceanBase將整體架構(gòu)劃分為4個模塊：主控服務(wù)器Root－Server、更新服務(wù)器 UpdateServer、基線數(shù)據(jù)服務(wù)器ChunkServer以及合并服務(wù)器MergeServer.其主要功能如下.

1）RootServer提供服務(wù)器管理和集群管理的功能，存儲集群的管理信息，一般與UpdateServer部署在同一臺服務(wù)器中；

2）UpdateServer存儲系統(tǒng)最近一段時間的增量更新數(shù)據(jù)，是唯一的寫入模塊，一般與RootServer部署在同一臺服務(wù)器中；

3）ChunkServer存儲系統(tǒng)的基準(zhǔn)數(shù)據(jù)，一般與MergeServer部署在同一臺服務(wù)器中；

4）MergeServer接收并解析用戶的SQL請求，經(jīng)過詞法分析、語法分析、查詢優(yōu)化等一系列操作后，將物理執(zhí)行計劃發(fā)到相應(yīng)的ChunkServer或者UpdateServer，一般與ChunkServer部署在同一臺服務(wù)器中.

OceanBase采用讀寫分離架構(gòu)將共享數(shù)據(jù)分為基準(zhǔn)數(shù)據(jù)和增量數(shù)據(jù).基準(zhǔn)數(shù)據(jù)通過分區(qū)和復(fù)制的方式分布在多臺ChunkServer中，并且只提供讀服務(wù)，增量數(shù)據(jù)存儲的是所有基準(zhǔn)數(shù)據(jù)的更新操作結(jié)果并集中式存放在一臺UpdateServer上.增量數(shù)據(jù)通過定期合并操作融合到基準(zhǔn)數(shù)據(jù)中，避免了單臺UpdateServer的存儲容量成為瓶頸，實現(xiàn)了良好的擴(kuò)展性.這種架構(gòu)將寫事務(wù)集中在一臺服務(wù)器上，巧妙地避免了復(fù)雜的分布式事務(wù)，高效地實現(xiàn)跨行跨表事務(wù)，同時大大降低了實現(xiàn)分布式數(shù)據(jù)庫一致性和高可用性的難度.

2.1 OceanBase 0.4.2的一致性與可用性

目前，阿里巴巴開源的是OceanBase 0.4.2，該版本采用傳統(tǒng)的主備雙集群架構(gòu)來保證系統(tǒng)的一致性和可用性.每個集群里有多臺ChunkServer，多臺MergeServer，兩臺Root－Server，兩臺UpdateServer.其雙集群架構(gòu)如圖1所示.

圖1 OceanBase 0.4.2版本的架構(gòu)Fig.1 The architecture of OceanBase 0.4.2

雙集群通過同步RootServer的管理信息和UpdateServer的更新日志來保證系統(tǒng)的一致性并采用最大可用模式來保證系統(tǒng)的可用性.每個集群內(nèi)RootServer和UpdateServer均采用主備高可用模式.主備RootServer之間通過數(shù)據(jù)強(qiáng)同步來保證一致性并且使用Linux HA來實現(xiàn)可用性.通常情況下，集群中的ChunkServer、UpdateServer和客戶端通過VIP（Virtual IP）訪問主RootServer，當(dāng)主RootServer出現(xiàn)故障時，Linux HA檢測到該故障并將指向主RootServer的VIP漂移到備RootServer，備RootServer的后臺線程檢測到VIP漂移到自己機(jī)器上后自動切換為主機(jī)提供服務(wù).為了確保增量數(shù)據(jù)一致性，Root－Server通過租約（Lease）機(jī)制為每個集群選取一臺主UpdateServer對外提供寫服務(wù)，租約有效期一般為3～5 s.正常情況下，RootServer會定期給主UpdateServer發(fā)送命令延長租約有效期.如果主UpdateServer出現(xiàn)異常，RootServer等待主UpdateServer的租約過期后才能選擇其他的UpdateServer為主UpdateServer繼續(xù)提供寫服務(wù).UpdateServer采用主備同步的最大可用性模式（Maximum Availability）來保證OceanBase的高可用性，主備之間通過日志同步來保證數(shù)據(jù)副本的一致性.其工作流程如下：

1）主UpdateServer將更新操作日志（redo日志）發(fā)送到備UpdateServer；

2）將操作日志寫入主UpdateServer硬盤；

3）將操作日志應(yīng)用到主UpdateServer的內(nèi)存表（MemTable）中；

4）等備UpdateServer返回寫入成功后主UpdateServer返回客戶端寫入成功.

OceanBase的高可用機(jī)制保證主UpdateServer、備UpdateServer及主備之間網(wǎng)絡(luò)三者之中的任何一個出現(xiàn)故障都不會對客戶端產(chǎn)生影響.然而，如果三者之中的兩個同時出現(xiàn)故障，則系統(tǒng)的可用性將受到影響.主備UpdateServe之間的副本不是時刻保持強(qiáng)同步，當(dāng)主備之間網(wǎng)絡(luò)出現(xiàn)故障時，主備UpdateServer之間采用異步方式來同步日志，那么當(dāng)主UpdateServer出現(xiàn)故障時，備UpdateServer的數(shù)據(jù)往往落后于主UpdateServer，如果將服務(wù)切到備UpdateServer，可能會丟失一部分提交的事務(wù)，導(dǎo)致數(shù)據(jù)不一致.因此OceanBase是犧牲增量數(shù)據(jù)副本的一致性來保證系統(tǒng)的高可用性.

UpdateServer作為一個單點支持跨行跨表寫事務(wù)，使用加鎖機(jī)制和多版本并發(fā)控制（MVCC）來實現(xiàn)事務(wù)的并發(fā)控制.UpdateServer內(nèi)部使用MemTable存儲結(jié)構(gòu)作為對外提供統(tǒng)一的讀寫接口，MemTable內(nèi)存結(jié)構(gòu)包括兩個部分：高性能內(nèi)存B樹索引結(jié)構(gòu)和行操作鏈表，B樹的葉子節(jié)點存儲表的主鍵值，每行的更新操作按時間順序構(gòu)成一個行操作鏈表掛在B樹的葉子節(jié)點上.處理寫事務(wù)時，首先會在B樹的葉子節(jié)點上申請寫鎖避免并發(fā)時的寫寫沖突，然后根據(jù)事務(wù)提交時的系統(tǒng)時間戳生成一個事務(wù)版本號，最后將事務(wù)版本號和修改操作一起存入行操作鏈表.處理讀事務(wù)時不需要申請讀鎖，直接根據(jù)版本號讀取某個版本的快照數(shù)據(jù)，而且每次都能讀到已提交的最新數(shù)據(jù)，由此可以看出OceanBase支持事務(wù)的強(qiáng)一致性并提供Read Committed和快照（Snapshot）讀兩種事務(wù)隔離級別.

OceanBase 0.4.2采用主備同步最大可用性模式的高可用架構(gòu)，犧牲副本間的強(qiáng)一致性來滿足系統(tǒng)的可用性.OceanBase 0.4.2的可用性能達(dá)到4個9（99.99%），單集群內(nèi)主機(jī)發(fā)生故障時可以通過Linux HA和租約機(jī)制自動切換到備機(jī)提供服務(wù)，但是雙集群間主集群發(fā)生故障時需要手動切換到備集群提供服務(wù).在事務(wù)處理方面，OceanBase 0.4.2采用分布式讀、集中式寫的架構(gòu)避免了大量的讀寫沖突和分布式事務(wù)，降低了處理分布式系統(tǒng)事務(wù)的難度，并采用不加讀鎖，在行粒度上加寫鎖和MVCC策略實現(xiàn)事務(wù)的并發(fā)控制，在保證可用性和高性能的基礎(chǔ)上提供了Read Committed和快照（Snapshot）讀兩種事務(wù)隔離級別.雖然OceanBase 0.4.2提供了高可用性，事務(wù)強(qiáng)一致性和數(shù)十萬TPS、數(shù)百萬QPS的訪問量，但處理讀寫請求時，需要先從ChunkServer中讀取基準(zhǔn)數(shù)據(jù)，再帶著基準(zhǔn)數(shù)據(jù)去UpdateServer執(zhí)行讀或?qū)懖僮?，處理過程中存在著大量的網(wǎng)絡(luò)開銷降低了讀寫性能，同時UpdateServer單點也限制了OceanBase集群整體的讀寫性能.

2.2 OceanBase 0.5的一致性與可用性

在生產(chǎn)應(yīng)用中發(fā)現(xiàn)，OceanBase 0.4.2可能存在因數(shù)據(jù)不一致而導(dǎo)致系統(tǒng)故障的情況.為了提高OceanBase的一致性和可用性，OceanBase 0.5版本提出了三機(jī)房的集群架構(gòu)：每個機(jī)房里有多臺ChunkServer，多臺 MergeServer，一臺RootServer，一臺UpdateServer.我們將這種三機(jī)房的集群稱為大集群.其機(jī)房架構(gòu)如圖2所示.

在大集群中，RootServer和UpdateServer均采用一主多備的架構(gòu)，同一時刻只有一臺主RootServer和一臺主UpdateServer對外提供服務(wù).在多臺RootServer之間，使用基于Paxos的分布式選舉協(xié)議，保證有且只有一臺RootServer被選為主RootServer對外提供服務(wù)，從而保證了系統(tǒng)的一致性.備RootServer定期從主RootServer同步內(nèi)容，從而保證數(shù)據(jù)副本的一致性；當(dāng)主RootServer出現(xiàn)故障時，分布式選舉協(xié)議將選舉出一臺可靠的備Root－Server作為主RootServer繼續(xù)提供服務(wù)，保證了系統(tǒng)的可用性.基于Paxos的分布式選舉協(xié)議的基本準(zhǔn)則包括以下三個方面：

圖2 OceanBase 0.5版本的架構(gòu)Fig.2 The architecture of OceanBase 0.5

1）成員不說假話（非拜占庭式）；

2）單個成員說話不自相矛盾：就某一決議投票給了A，就不能再投票給B；

3）任何修改需要多數(shù)成員同意.

OceanBase 0.5在實現(xiàn)分布式選舉協(xié)議時對Paxos協(xié)議進(jìn)行了簡化，將原生態(tài)Paxos的“異步模式”改進(jìn)為“同步模式”，不僅實現(xiàn)上變得簡單同時能夠保證系統(tǒng)只有幾秒到十幾秒的時間不能提供服務(wù)，但是OceanBase選舉協(xié)議依賴時鐘同步，要求多臺服務(wù)器之間的時鐘偏差不能過大，底層的NTP服務(wù)需要嚴(yán)格保證時鐘同步.多臺UpdateServer之間由主RootServer使用租約（Lease）機(jī)制為大集群選舉一臺主UpdateServer，當(dāng)主UpdateServer出現(xiàn)故障時，RootServer將從剩余兩臺備UpdateServer中選擇日志時間戳最大的作為主UpdateServer繼續(xù)提供服務(wù)，從而保證了UpdateServer的可用性.主備UpdateServer之間使用Paxos協(xié)議同步操作日志從而保證了數(shù)據(jù)副本一致性，主UpdateServer采用異步請求方式向備UpdateServer同步日志，但是寫本地硬盤采用同步的方式，即前一個日志塊沒有響應(yīng)不會寫下一個日志塊，并且任何一份數(shù)據(jù)需要在三臺UpdateServer中的兩臺（超過半數(shù)UpdateServer）確認(rèn)寫盤成功主UpdateServer才認(rèn)為寫請求成功，保證了任何一臺機(jī)器出現(xiàn)故障時系統(tǒng)都不會丟失數(shù)據(jù)，可以繼續(xù)提供服務(wù)，從而兼顧了系統(tǒng)的一致性和可用性.在事務(wù)處理方面，OceanBase 0.5仍使用分布式讀集中式寫的事務(wù)處理架構(gòu)，采用行粒度上加寫鎖和MVCC來實現(xiàn)并發(fā)控制，保證事務(wù)強(qiáng)一致性并提供Read Committed和快照（Snapshot）讀兩種事務(wù)隔離級別.

OceanBase 0.5采用主備強(qiáng)同步策略和分布式選舉保證了數(shù)據(jù)副本一致性和高可用性.雖然在每次更新時保證至少有一個備副本與主副本完全同步，但是所有副本之間仍滿足最終一致性.因此，這種實現(xiàn)方案仍是犧牲了副本的強(qiáng)一致性來保證高可用性.OceanBase 0.5的可用性可以達(dá)到4個半9.事務(wù)處理方面仍采用OceanBase 0.4.2的實現(xiàn)方法保證了事務(wù)一致性并提供供Read Committed和快照（Snapshot）讀兩種隔離級別.雖然OceanBase 0.5提供了更高的可用性，但集群中仍只有一臺UpdateServer提供寫服務(wù)，UpdateServer單點影響系統(tǒng)整體讀寫性能的缺陷仍然存在，同時處理讀寫請求時的網(wǎng)絡(luò)開銷也仍然存在.

3 多UpdateServer架構(gòu)的一致性與可用性

OceanBase雖然實現(xiàn)了一致性和可用性，但單點UpdateServer和處理讀寫請求的網(wǎng)絡(luò)開銷限制了系統(tǒng)的讀寫性能.為了提高OceanBase集群的讀寫性能，需要多個UpdateServer同時提供寫服務(wù).改善單點性能的方法有兩種：第一是數(shù)據(jù)鏡像，把所有數(shù)據(jù)同步到多個服務(wù)器，服務(wù)器間提供無差別的服務(wù)；第二是數(shù)據(jù)分區(qū)，把數(shù)據(jù)按照一定規(guī)則進(jìn)行分區(qū)存放在服務(wù)器上.

3.1 數(shù)據(jù)鏡像架構(gòu)

此架構(gòu)采用三機(jī)房的集群：每個機(jī)房里有多臺ChunkServer，多臺 MergeServer，一臺RootServer，一臺UpdateServer.數(shù)據(jù)分為基準(zhǔn)數(shù)據(jù)和增量數(shù)據(jù)，基準(zhǔn)數(shù)據(jù)采用分區(qū)和復(fù)制的方式存放在一個機(jī)房多臺ChunkServer上，然后再鏡像拷貝到其他機(jī)房；增量數(shù)據(jù)集中式存放在一個機(jī)房的UpdateServer上，然后再鏡像拷貝到其他機(jī)房.兩兩集群間的基準(zhǔn)數(shù)據(jù)和增量數(shù)據(jù)作為無差別的數(shù)據(jù)副本對外提供服務(wù)，數(shù)據(jù)副本通常分為兩種架構(gòu)即Master－Slaver［17］和 Master－Master［17］，Master－Slaver架構(gòu)是指多個數(shù)據(jù)副本中存在一個主副本和多個備副本并且同一時刻只有主副本對外提供服務(wù)，Master－Master架構(gòu)是指多個數(shù)據(jù)副本都可以對外提供服務(wù)，各個數(shù)據(jù)副本之間是平等的關(guān)系不存在主備之分.OceanBase 0.5中增量數(shù)據(jù)使用的是Master－Slaver數(shù)據(jù)副本架構(gòu)，而此架構(gòu)采用Master－Master數(shù)據(jù)副本架構(gòu)，即同一時刻三臺UpdateServer都可以接受寫請求.數(shù)據(jù)鏡像架構(gòu)如圖3所示.

在這種架構(gòu)模型下，RootServer采用一主多備架構(gòu)，同一時刻只有一臺主RootServer提供服務(wù)，多臺RootServer之間仍采用OceanBase 0.5的分布式選舉協(xié)議來保證一致性和可用性.UpdateServe的增量數(shù)據(jù)采用Master－Master架構(gòu)，三臺UpdateServe同時接收寫請求的情況下，保證增量數(shù)據(jù)一致性可以采用NRW協(xié)議［17］，這里的N表示總的副本數(shù)，R表示每次讀請求需要讀取的副本數(shù)，W 表示每次寫請求需要寫入的副本數(shù).R、W 需要滿足

以下條件：

至于R、W 取值多少，可以根據(jù)應(yīng)用需求來設(shè)置.這種一致性協(xié)議雖然能保證每次讀取到的都是最新值，但是所有副本滿足最終一致性.在事務(wù)處理方面，采用分布式鎖機(jī)制和MVCC來實現(xiàn)并發(fā)控制.一種簡單的加鎖方法是，采用集中式封鎖機(jī)制維護(hù)一張全局鎖表，鎖表存儲每個副本加鎖的信息.這種方法的明顯缺點是，存在單點性能，當(dāng)存放鎖表的機(jī)器出現(xiàn)故障時，系統(tǒng)將不能提供服務(wù)；另一種加鎖方法是，在每個UpdateServer都維護(hù)一張全局的鎖表.這種方法雖然避免了單點故障，卻增加了保證鎖表一致性的難度；另一種加鎖方法是使用NSX封鎖機(jī)制［10］，其中N表示總的副本數(shù)，S表示事務(wù)獲得數(shù)據(jù)項A的全局共享鎖時必須以共享方式封鎖的A的副本數(shù)，X表示事務(wù)獲得數(shù)據(jù)項A；只要滿足2 X＞N且S＋X＞N，就能滿足數(shù)據(jù)項A上只能有一個排他鎖：不會既有一個排他鎖又有一個共享鎖.還有一種方法是，采用向量時鐘（Vector Clock）來解決寫寫沖突.但這種方法依賴集群內(nèi)部節(jié)點之間的時鐘同步算法，不能完全保證事務(wù)一致性.

圖3 數(shù)據(jù)鏡像架構(gòu)模型Fig.3 The architecture of data mirroring

這種架構(gòu)通過UpdateServer采用Master－Master架構(gòu)提高了系統(tǒng)整體的讀寫性能和系統(tǒng)的擴(kuò)展性，但是保證數(shù)據(jù)一致性卻需要花費很大的代價.實現(xiàn)方案中數(shù)據(jù)副本只保證最終一致性，如果多個UpdateServer之間的更新順序不一致，客戶端可能讀不到預(yù)期的結(jié)果.而且系統(tǒng)的可用性也不是很高，當(dāng)某臺UpdateServer或者客戶端與UpdateServer之間的網(wǎng)絡(luò)出現(xiàn)故障時，R、W 不能滿足預(yù)定的值則不能提供服務(wù)，從而降低了系統(tǒng)的可用性.總的來說，提高了系統(tǒng)讀寫性能卻要承擔(dān)數(shù)據(jù)不一致的風(fēng)險.在實際生產(chǎn)應(yīng)用中，不提倡這種架構(gòu).

3.2 數(shù)據(jù)分區(qū)架構(gòu)

此架構(gòu)采用三機(jī)房的集群架構(gòu)，每個機(jī)房里有多臺ChunkServer，多臺MergeServer，一臺RootServer，多臺UpdateServer.數(shù)據(jù)分為基準(zhǔn)數(shù)據(jù)和增量數(shù)據(jù)，基準(zhǔn)數(shù)據(jù)采用分區(qū)和復(fù)制的方式存放在一個機(jī)房的多臺ChunkServer上，然后再鏡像拷貝到其他機(jī)房；增量數(shù)據(jù)采用分區(qū)和復(fù)制的方式存放在三個機(jī)房的多臺UpdateServer上，兩兩集群間基準(zhǔn)數(shù)據(jù)是一樣的，但增量數(shù)據(jù)可能不一樣，其架構(gòu)如圖4所示.

圖4 數(shù)據(jù)分區(qū)架構(gòu)模型Fig.4 The architecture of data partition

在這種架構(gòu)模型下，RootServer采用一主多備的架構(gòu)：同一時刻只有一臺主RootServer提供服務(wù)，多臺RootServer之間仍采用OceanBase 0.5的分布式選舉協(xié)議來保證系統(tǒng)的可用性.UpdateServer增量數(shù)據(jù)采用Master－Slaver架構(gòu)：同一數(shù)據(jù)分區(qū)副本之間由主RootServer選出唯一的主分區(qū)副本并對外提供服務(wù)，主備分區(qū)副本之間通過Paxos協(xié)議同步操作日志來保證分區(qū)副本一致性.在事務(wù)處理方面，由于增量數(shù)據(jù)分布在多個UpdateServer上，可能存在跨多個節(jié)點的分布式事務(wù)，此時需要使用兩階段提交（2PC）協(xié)議來保證分布式事務(wù)的原子性，使用分布式鎖機(jī)制和MVCC來實現(xiàn)并發(fā)控制.兩階段提交協(xié)議是阻塞協(xié)議，在執(zhí)行過程中需要鎖住其他更新并且需要大量的網(wǎng)絡(luò)通信，這樣將直接影響系統(tǒng)的讀寫性能.提高性能的唯一辦法是減少分布式事務(wù)，減少分布式事務(wù)則需要根據(jù)應(yīng)用場景將大多數(shù)事務(wù)涉及的數(shù)據(jù)劃分到一個數(shù)據(jù)分區(qū)中并且將大多數(shù)事務(wù)涉及的數(shù)據(jù)分區(qū)存放在同一個物理機(jī)器上.通過分區(qū)規(guī)則使得95%的事務(wù)都是集中式事務(wù)，只有5%的事務(wù)是分布式事務(wù).此架構(gòu)下能夠保證事務(wù)一致性并提供Read Committed和快照（Snapshot）讀兩種事務(wù)隔離級別.

這種架構(gòu)采用數(shù)據(jù)分區(qū)主副本強(qiáng)同步和分布式選舉來保證系統(tǒng)的一致性和高可用性，并且采用數(shù)據(jù)分區(qū)的方式改善了單點UpdateServer的讀寫性能和UpdateServer的擴(kuò)展性.在事務(wù)處理方面，采用較好的數(shù)據(jù)分區(qū)規(guī)則避免大量的分布式事務(wù)影響系統(tǒng)的讀寫性能，采用兩階段提交協(xié)議、加鎖機(jī)制和MVCC來保證事務(wù)原子性、一致性并提供Read Committed和快照（Snapshot）讀兩種隔離級別.這種架構(gòu)雖然保證了系統(tǒng)的高可用性、事務(wù)一致性和較好的讀寫性能，但是讀寫分離架構(gòu)在處理讀寫事務(wù)時會有大量的網(wǎng)絡(luò)開銷，這將直接影響系統(tǒng)的讀寫性能.

3.3 節(jié)點對等架構(gòu)

此架構(gòu)采用三機(jī)房的集群架構(gòu)，每個機(jī)房里有多臺ChunkServer，多臺MergeServer，一臺RootServer，多臺UpdateServer，將ChunkServer、MergeServer和UpdateServer部署在一臺物理機(jī)上.增量數(shù)據(jù)和基準(zhǔn)數(shù)據(jù)采用分開存儲，每臺物理機(jī)上的增量數(shù)據(jù)存儲該臺物理機(jī)上基準(zhǔn)數(shù)據(jù)的更新修改結(jié)果.增量數(shù)據(jù)采用分區(qū)方式存于一個機(jī)房的UpdateServer中，基準(zhǔn)數(shù)據(jù)采用分區(qū)方式存于一個機(jī)房的ChunkServer中，集群之間采用鏡像拷貝存儲基準(zhǔn)數(shù)據(jù)副本和增量數(shù)據(jù)副本，提供無差別的服務(wù).其架構(gòu)如圖5所示.

在這種架構(gòu)模型下，RootServer采用OceanBase 0.5中實現(xiàn)RootServer一致性和高可用性的架構(gòu)和策略，同一時刻選出唯一的主RootServer對外提供服務(wù).UpdateServer增量數(shù)據(jù)采用Master－Slaver架構(gòu)，由主RootServer從多個增量數(shù)據(jù)分區(qū)副本中選出一個主副本對外服務(wù)，副本之間采用Paxos協(xié)議同步更新操作日志保證增量數(shù)據(jù)分區(qū)副本的一致性和可用性.在事務(wù)處理方面，同一個增量數(shù)據(jù)分區(qū)內(nèi)的事務(wù)采用加行鎖和MVCC來保證事務(wù)的一致性，不同增量數(shù)據(jù)分區(qū)之間的分布式事務(wù)采用兩階段提交協(xié)議、分布式加鎖和MVCC來保證分布式事務(wù)的一致性.為了提高系統(tǒng)性能，需要運用較好的數(shù)據(jù)分區(qū)規(guī)則，以盡量避免應(yīng)用中的分布式事務(wù).在保證系統(tǒng)高可用、數(shù)據(jù)一致性和事務(wù)一致性的基礎(chǔ)上，此架構(gòu)可以提供Read Committed和快照（Snapshot）讀兩種事務(wù)隔離級別.

圖5 節(jié)點對等架構(gòu)模型Fig.5 The P2P architecture

這種架構(gòu)將增量數(shù)據(jù)和基準(zhǔn)數(shù)據(jù)存放于同一物理機(jī)上，在處理讀寫請求時減少了基準(zhǔn)數(shù)據(jù)與增量數(shù)據(jù)之間的網(wǎng)絡(luò)開銷，大大提高了系統(tǒng)的讀寫性能.在提升系統(tǒng)性能的基準(zhǔn)上采用增量數(shù)據(jù)分區(qū)主副本強(qiáng)同步和分布式選舉來保證系統(tǒng)的一致性和高可用性，并且采用數(shù)據(jù)分區(qū)的方式改善了單點UpdateServer的瓶頸.在事務(wù)處理方面，依然需要采用適應(yīng)業(yè)務(wù)的分區(qū)規(guī)則避免大量分布式事務(wù)的存在，采用兩階段提交協(xié)議、加行鎖機(jī)制和MVCC來保證事務(wù)原子性和一致性并且能夠提供Read Committed和快照（Snapshot）讀兩種隔離級別.這種架構(gòu)不僅可以實現(xiàn)系統(tǒng)的高可用性和事務(wù)強(qiáng)一致性，而且能夠保證系統(tǒng)的高性能和高擴(kuò)展性，但是數(shù)據(jù)副本之間是最終一致性.

4 結(jié) 論

本文根據(jù)傳統(tǒng)數(shù)據(jù)庫和分布式數(shù)據(jù)庫一致性和可用性技術(shù)，分析了OceanBase 0.4.2和OceanBase 0.5的一致性和可用性.OceanBase 0.4.2和OceanBase 0.5分別采用了不同的高可用架構(gòu)和一致性協(xié)議來保證系統(tǒng)的高可用性和事務(wù)一致性，為了兼顧系統(tǒng)性能數(shù)據(jù)副本之間滿足最終一致性.雖然OceanBase具有高可用性、一致性、擴(kuò)展性并能支持跨行跨表事務(wù)，但單點UpdateServer處理寫請求和處理讀寫請求時基準(zhǔn)數(shù)據(jù)與增量數(shù)據(jù)之間的網(wǎng)絡(luò)開銷將大大影響系統(tǒng)的讀寫性能.本文針對OceanBase的缺陷提出了3種新的架構(gòu)，并探討了新架構(gòu)一致性和可用性的實現(xiàn)方案.5種架構(gòu)總結(jié)參見表1.

表1 5種架構(gòu)總結(jié)Tab.1 Summary of architectures

OceanBase目前支持的一致性和可用性還不能達(dá)到金融領(lǐng)域?qū)?shù)據(jù)管理系統(tǒng)99.999%的可用性和事務(wù)可串行化隔離級別的要求，并且OceanBase支持的SQL查詢不適用于金融行業(yè)復(fù)雜的交易.在使用OceanBase分布式數(shù)據(jù)庫過程中發(fā)現(xiàn)OceanBase支持的SQL數(shù)據(jù)類型和函數(shù)并不完整，不支持二級索引和復(fù)雜Join，因此OceanBase目前只適用于讀多寫少的簡單查詢應(yīng)用，如果要運行復(fù)雜業(yè)務(wù)時，需要對業(yè)務(wù)邏輯進(jìn)行改造來提高查詢效率.雖然OceanBase分布式數(shù)據(jù)庫要完全應(yīng)用于金融領(lǐng)域還存在著很大的距離，但它實現(xiàn)一致性和可用性的策略與技術(shù)對分布式數(shù)據(jù)庫的研究和實現(xiàn)有很大的參考價值.在運用和學(xué)習(xí)OceanBase時，應(yīng)該注意以下幾點：

1）OceanBase不支持復(fù)雜Join，并且兩張大數(shù)據(jù)量表連接時的效率很低，在業(yè)務(wù)應(yīng)用時需要考慮效率問題；

2）OceanBase不支持查詢優(yōu)化，如不支持二級索引，不支持in主鍵前綴查詢；

3）OceanBase沒有存儲過程和游標(biāo)；

4）OceanBase代碼是由幾個版本融合在一起的，存在廢棄的接口和數(shù)據(jù)類型；

5）OceanBase有自己的內(nèi)存管理機(jī)制，在開發(fā)時不要盲目申請內(nèi)存空間，以免導(dǎo)致內(nèi)存泄露.

［1］ CHANG F，DEAN J，GHEMAWAT S，et al.Bigtable：a distributed storage system for structured data［C］／／Proceedngs of the 7the symposium on OSDI，2006：205－218.

［2］ CORBETT J C，DEAN J，EPSTEIN M，et al.Spanner：Google’s globally distributed database［J］.ACM Trans Comput Syst，2013，31（3）：8.

［3］ 楊傳輝.大規(guī)模分布式存儲系統(tǒng)：原理解析與架構(gòu)實戰(zhàn)［M］.北京：機(jī)械工業(yè)出版社，2013.

［4］ BREWER E A.Towards robust distributed systems（abstract）.PODC2000：7.

［5］ 黃劍.基于 Oracle Data Guard懂得容災(zāi)策略設(shè)計與實現(xiàn)［J］.科技廣場，2006（11）：71－73.

［6］ Oracle Berkeley DB：Performance Metrics and Benchmarks，［EB／OL］.2006［2014－08－31］.http：／／ww.oracle.coms／database／berkeley－db.html.

［7］ SIKKA V，F(xiàn)?RBER F，GOEL A K，et al.SAP HANA：The evolution from a modern main－memory data plat－form to an enterprise application platform［C］.PVLDB，2013，6（11）：1184－1185.

［8］ STONEBRAKER M，WEISBERG A.The VoltDB Main Memory DBMS［J］.IEEE Data Eng Bull，2014，36（2）：21－27.

［9］ LAMPORT L.Time，clocks，and the ordering of events in a distributed system［J］.Commun ACM （CACM），1978，21（7）：558－565.

［10］ TANENBAUM A S，VAN STEEN M.Distributed Systems：Principles and Paradigms［M］.2nd ed.［s.l.］：Prentice Hall，2008.

［11］ LAMPORT L.The Part－Time Parliament［M］.ACM Transaction on Computer Systems，1998，16（2）：133－169.

［12］ BORTHAKKUR D.HDFS Architecture Guide［EB／OL］.2013－02－13.

［13］ Two－phase commit protocol.http：／／en.wikipedia.org／wiki／Two－phase＿commit＿protocol.

［14］ BURROWS M.The chubby lock service for loosely－coupled distributed systems［C］／／7th USENIX Symposium on OSDI 2006：335－350.

［15］ GRAY J N，LORIE R A，PUTZOLU G R，et al.Granularity of Locks and Degrees of consistency in a Shared Data Base［R］.San Jose，California：IBM Research Laboratory.

［16］ BAILIS P，DAVIDSON A，F(xiàn)EKETE A，et al.Highly available transaction：Virtues and Limitations［C］／／Proceedings of the VLDB Endowment，2014，7（3）：181－192.

［17］ DEAN J，GHEMAWAT S.MapReduce：Simplified Data Processing on Large Clusters［C］／／7th USENIX Symposium on OSDI，2004.