分布“內(nèi)存數(shù)據(jù)庫系統(tǒng)的容錯管理

趙鎮(zhèn)輝,黃承晟,周敏奇,周傲英

(華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院,上海200062)

分布“內(nèi)存數(shù)據(jù)庫系統(tǒng)的容錯管理

趙鎮(zhèn)輝,黃承晟,周敏奇,周傲英

(華東師范大學(xué)數(shù)據(jù)科學(xué)與工程研究院,上海200062)

在大數(shù)據(jù)背景下,分布式系統(tǒng)被企業(yè)廣泛部署和應(yīng)用,隨著分布式系統(tǒng)節(jié)點規(guī)模的擴大,系統(tǒng)故障的概率也將隨之增加,在分布式系統(tǒng)中引入容錯機制,對提升分布式系統(tǒng)可用性、可靠性、可恢復(fù)性至關(guān)重要.CLAIMS系統(tǒng)是面向金融領(lǐng)域的對實時數(shù)據(jù)進行實時分析的內(nèi)存數(shù)據(jù)庫系統(tǒng)——在數(shù)據(jù)不斷注入系統(tǒng)時,提供近實時的查詢、分析任務(wù).本文主要探討CLAIMS系統(tǒng)中容錯機制.依據(jù)租約機制,實現(xiàn)系統(tǒng)中異常節(jié)點的快速發(fā)現(xiàn)及標(biāo)記(即Fail-fast).在標(biāo)記異常節(jié)點之后,實現(xiàn)對受影響分析任務(wù)的重啟(即Fail-over);對異常節(jié)點全局內(nèi)存狀態(tài)的恢復(fù)(即Fail-back).實驗結(jié)果表明,本文所提算法能夠較好地實現(xiàn)CLAIMS系統(tǒng)的容錯特性.

分布式內(nèi)存數(shù)據(jù)庫;容錯;租約

0 引言

在大數(shù)據(jù)環(huán)境下,大型互聯(lián)網(wǎng)公司對高性能海量數(shù)據(jù)處理的需求大幅增加.在廉價PC服務(wù)器上部署的分布式數(shù)據(jù)庫系統(tǒng)能進一步降低數(shù)據(jù)處理的成本,同時獲得數(shù)據(jù)處理的高吞吐率,高可用性,高可靠性,分布式系統(tǒng)成為處理高性能海量數(shù)據(jù)的首選.目前,阿里旗下的公司螞蟻金服及阿里巴巴自主研發(fā)的通用關(guān)系數(shù)據(jù)庫OceanBase已經(jīng)支撐淘寶、天貓和聚劃算的所有日常交易.分布式數(shù)據(jù)庫OceanBase具有自動檢測服務(wù)器故障檢測與容錯的功能.2015年“雙十一”阿里旗下的天貓商城全天成交金額為912.17億元,訂單數(shù)達到了4.67億,開場1分12秒后就達到了成交金額就達到了10億元.在服務(wù)器如此高負載的情況下,系統(tǒng)的容錯顯得格外重要,避免如訂單失效、數(shù)據(jù)丟失、查詢錯誤等問題.由Postgres和Ingres聯(lián)合創(chuàng)始人Mike Stonebraker開發(fā)的內(nèi)存數(shù)據(jù)庫VoltDB,使用K-safety機制來保證數(shù)據(jù)的安全.而所有容錯機制對于用戶來說是不可見得[1].這也是容錯的另一大特性.

分布式系統(tǒng)容錯分為兩個階段,錯誤檢測和錯誤處理.錯誤處理階段又可分為兩種策略Fail-over與Fail-back,前者是通過轉(zhuǎn)移失效機器上未完成的任務(wù)來實現(xiàn)查詢處理復(fù)雜的容錯,后者通過失效機器重新激活后或者新機器替換失效機器后恢復(fù)失效機器的全局狀態(tài)來保證數(shù)據(jù)一致性[2].

結(jié)合目前CLAIMS分布式數(shù)據(jù)庫系統(tǒng)的架構(gòu),本文給出了針對不同情況的容錯機制,具體如下.

(1)在CLAIMS系統(tǒng)中增加基于租約機制的容錯檢測系統(tǒng).

(2)在CLAIMS系統(tǒng)中實現(xiàn)基于容錯檢測機制后的Fail-fast機制來及時發(fā)現(xiàn)節(jié)點失效.

(3)在CLAIMS系統(tǒng)中實現(xiàn)基于容錯檢測機制的Fail-over機制來保證部分節(jié)點宕機時CLAIMS系統(tǒng)能夠?qū)⒉樵冐撦d重新分發(fā)到其他正常節(jié)點并繼續(xù)提供服務(wù).

(4)在CLAIMS系統(tǒng)中實現(xiàn)了基于容錯檢測機制的Fail-back機制來保證節(jié)點恢復(fù)過程中CLAIMS中的節(jié)點重新加入集群中,并繼續(xù)執(zhí)行計算.

本文的內(nèi)容組織:第1節(jié)介紹背景知識;第2節(jié)介紹預(yù)備知識;第3節(jié)介紹容錯算法;第4節(jié)評估實驗;第5節(jié)總結(jié)全文.

1 相關(guān)工作

1.1 CLAIMS系統(tǒng)介紹

系統(tǒng)架構(gòu)介紹分為外部架構(gòu)與內(nèi)部架構(gòu),外部架構(gòu)表現(xiàn)客戶與CLAIMS系統(tǒng)的關(guān)系.內(nèi)部架構(gòu)則分析了CLAIMS系統(tǒng)的主節(jié)點與從節(jié)點內(nèi)部的主要環(huán)境.

1.1.1 外部架構(gòu)

CLAIMS是一個開源的分布式內(nèi)存數(shù)據(jù)庫系統(tǒng).通過具有高吞吐實時數(shù)據(jù)注入的功能實現(xiàn)了實時數(shù)據(jù)分析.系統(tǒng)在處理SQL時,所有數(shù)據(jù)和中間結(jié)果都存于內(nèi)存中,避免了磁盤的I/O開銷,實現(xiàn)了高吞吐量情況下高效的數(shù)據(jù)分析性能.用戶使用在外部主機上運行的Client端,輸入SQL語句.CLAIMS外部架構(gòu)圖見圖1.

1.1.2 內(nèi)部架構(gòu)

CLAIMS的內(nèi)部結(jié)構(gòu)詳見圖2,主節(jié)點包括SQL解析器、查詢優(yōu)化器、數(shù)據(jù)字典管理器、資源管理器、調(diào)度器和存儲管理器.主節(jié)點接收Client端發(fā)來的Sql語句并對SQL請求進行解析與查詢優(yōu)化,將查詢計劃派發(fā)到不同的從節(jié)點上.從節(jié)點結(jié)構(gòu)包括了執(zhí)行器、數(shù)字字典管理器、資源管理器、調(diào)度器和存儲管理器.從節(jié)點執(zhí)行主節(jié)點發(fā)送的物理查詢計劃,同時負責(zé)底層的文件系統(tǒng)進行數(shù)據(jù)的存儲與接收[3].

圖1 CLAIMS外部架構(gòu)圖Fig.1CLAIMS external architecture diagram

圖2 CLAIMS內(nèi)部架構(gòu)圖Fig.2CLAIMS internal architecture diagram

1.1.3 問題闡述

CLAIMS系統(tǒng)是運行在較大數(shù)據(jù)集上的實時數(shù)據(jù)分析系統(tǒng).實時數(shù)據(jù)分析要求CLAIMS系統(tǒng)容錯機制的時間開銷很小,在一次數(shù)據(jù)的實時數(shù)據(jù)分析中,節(jié)點的非拜占庭錯誤不會使用戶獲得錯誤結(jié)果,所造成的額外的時間開銷也應(yīng)該被控制.系統(tǒng)在檢測到系統(tǒng)中存在節(jié)點失效時,會返回”錯誤”并重啟失效節(jié)點.

1.2 預(yù)備知識

CLAIMS中的容錯是基于租約機制的實現(xiàn),租約為其提供了理論的基礎(chǔ).在實現(xiàn)中,本系統(tǒng)采用CAF框架,CAF為CLAIMS提供了多線程高性能網(wǎng)絡(luò)通信庫.結(jié)構(gòu)圖見圖3.

圖3 CLAIMS容錯結(jié)構(gòu)圖Fig.3CLAIMS fault-tolerance structure diagram

1.2.1 租約介紹

1989年斯坦福大學(xué)的Gray C和Cheriton D提出了利用租約來維護緩存一致性的方法[4].租約是指服務(wù)器給予客戶端在一定期限內(nèi)可以控制讀寫操作的權(quán)利,當(dāng)服務(wù)器試圖修改數(shù)據(jù)時,首先向擁有這塊數(shù)據(jù)的租約的客戶端發(fā)送請求.客戶端從服務(wù)器讀取數(shù)據(jù)時就同時獲取租約,如果在租約期限內(nèi),沒有收到服務(wù)器的修改請求,就可以保證當(dāng)前緩存中的內(nèi)容是最新的.租約過期后,如果客戶端還需要讀取數(shù)據(jù),則必須重新獲取租約即“續(xù)約”.租約分為短租約與長租約.短租約維護開銷較大,一般短租約時間長度為秒級別的,而長租約續(xù)約的開銷會小很多.在CLAIMS中結(jié)合短租約實現(xiàn)了基于租約的心跳機制.

1.2.2 CAF Actor模型框架介紹

CLAIMS系統(tǒng)中,使用CAF完成節(jié)點間的通信,實現(xiàn)Fail-fast機制.CAF是一個輕量級通信框架.CAF的實現(xiàn)方法是,在線程的級別上再創(chuàng)建一個Actor結(jié)構(gòu),Actor承擔(dān)原來系統(tǒng)結(jié)構(gòu)中線程的角色,然后線程池的線程輪轉(zhuǎn)完成Actor的指令.使用這種結(jié)構(gòu),創(chuàng)建220個Actor在4～64核的機器上時間開銷小于2 s,性能比同類型其他Actor框架高很多.在消息傳輸上,在64核的機器上,100個Actor對1個Actor各發(fā)送1000000條消息(總共100000000條消息)用時為86 s,同樣的任務(wù)在使用Scala的通信框架時則需花費1086 s[5].此外,CAF還支持無鎖編程,并提供了錯誤檢測,在CAF中消息只有發(fā)送成功與發(fā)送失敗兩種狀態(tài),編程者不需要考慮重發(fā),跨平臺等問題.

2 算法介紹

主要介紹3種算法,Fail-fast實現(xiàn)錯誤檢測,Fail-over實現(xiàn)集群失效時繼續(xù)為外界提供服務(wù),Fail-back實現(xiàn)集群中節(jié)點重啟恢復(fù)后再次提供服務(wù)[6].

2.1 Fail-fast算法

CLAIMS中使用短租約即心跳機制主動去監(jiān)測節(jié)點宕機或網(wǎng)絡(luò)擁塞所造成的節(jié)點失效.主節(jié)點(Master)啟動一個線程級別的Master Actor去監(jiān)聽某一個端口并接受集群其他節(jié)點的心跳和其他消息.從節(jié)點將向主節(jié)點的Master Actor發(fā)送注冊請求,主節(jié)點檢查從節(jié)點的合法性(檢查是否包含重復(fù)IP和端口,假設(shè)集群中的所有節(jié)點都不會發(fā)送惡意的信息.)后分配給從節(jié)點一個全局唯一的節(jié)點ID.Master Actor將該從節(jié)點ID加入到由自身維護的存活列表L中,并且在一定周期T1內(nèi)增加列表L中的每個節(jié)點i的心跳計數(shù)Ci,當(dāng)Ci達到Cmax時將L中的該節(jié)點標(biāo)記為死亡[7].當(dāng)從節(jié)點i收到注冊成功請求后表示注冊成功,將在一個周期T2內(nèi)發(fā)送心跳信息給主節(jié)點.Master Actor接收到心跳信息后就會將該節(jié)點對應(yīng)的Ci清0,并且返回當(dāng)前存活節(jié)點的所有信息,使從節(jié)點獲得當(dāng)前系統(tǒng)中的存活節(jié)點信息,這些信息在多Master架構(gòu)或多Coordinator架構(gòu)中是至關(guān)重要的[8].原理圖見圖4.

圖4 CLAIMS系統(tǒng)Fail-fast算法原理圖Fig.4The principle of Fail-fast algorithm in CLAIMS system diagram

2.2 Fail-over算法

Fail-over是一種容錯機制,在分布式系統(tǒng)中的概念是越過失敗并繼續(xù)向用戶提供服務(wù)[9].在Claims中Fail-over將保證在節(jié)點出現(xiàn)故障時,不中斷地對外服務(wù).主節(jié)點(master)上的協(xié)調(diào)器保持監(jiān)聽從節(jié)點(slave)的活躍信息(心跳機制),當(dāng)某個節(jié)點不可用(丟失或死亡)時,協(xié)調(diào)器(Coordinator)將節(jié)點的死亡情況標(biāo)識給資源管理器(Resource Manager),資源管理器將獲得這個節(jié)點的死亡信息,并將其標(biāo)記為死亡節(jié)點.同時,master會終止該從節(jié)點上所有未執(zhí)行的query的租約的“續(xù)租”,所有的從節(jié)點在執(zhí)行這些query的計算都將因“續(xù)租”而停止運算,清空相關(guān)中間數(shù)據(jù).

2.3 Fail-back算法

Fail-back機制,即當(dāng)一臺機器宕機后,機器能夠恢復(fù)到正常的狀態(tài),繼續(xù)工作[10].恢復(fù)的主要目的是恢復(fù)原來該機器內(nèi)存中的數(shù)據(jù),以及已持久化的數(shù)據(jù).當(dāng)機器未宕機,只是從節(jié)點上的程序崩潰時,在主節(jié)點(Master)fail-fast機制中會發(fā)現(xiàn)節(jié)點失效,發(fā)送重啟命令,啟動存放在指定目錄下的重啟腳本,重啟該slave程序.當(dāng)機器出現(xiàn)宕機或丟失等情況時, Master在n次嘗試無效后,CLAIMS系統(tǒng)會發(fā)出警報通知管理員,集群管理員重啟機器.原理圖見圖6.

圖5 CLAIMS系統(tǒng)Fail-over算法原理圖Fig.5The principle of Fail-over algorithm in CLAIMS system diagram

圖6 CLAIMS系統(tǒng)Fail-back算法原理圖Fig.6The principle of Fail-back algorithm in CLAIMS system diagram

3 實驗

3.1 實驗環(huán)境

實驗由3部分組成,分別為Fail-fast,Fail-over,Fail-back.實驗運行于一組3臺PC組成的分布式集群中,其中一臺作為Master節(jié)點兩臺(a、b)作為Slave節(jié)點.硬件環(huán)境均為i7-4790 3.6Ghz*8、同批次1 t機械硬盤.

實驗中使用TPC-H 1G數(shù)據(jù)集作為測試數(shù)據(jù)集.

3.2 Fail-fast實驗

實驗內(nèi)容

在上述實驗環(huán)境中部署分布式的CLAIMS系統(tǒng),分別為Master和Slave-a,Slave-b.在CLAIMS系統(tǒng)正常運行后,手動停止Slave-a,分別統(tǒng)計不同心跳間隔時,Master節(jié)點檢測到子節(jié)點Slave-a丟失的平均時間.通過遍歷存活列表,n次未發(fā)現(xiàn)節(jié)點存活信息則認為此節(jié)點丟失.

分別設(shè)定心跳間隔為1、1.5、2、2.5和3,分別設(shè)定n為3、5,共10種狀態(tài),每種狀態(tài)運行5次并計算平均時間.

實驗結(jié)果

見圖7.MaxTry表示為最大嘗試次數(shù),當(dāng)超過嘗試次數(shù)Master會將該Slave標(biāo)記為死亡的.

X軸Frequency表示為每次發(fā)送心跳的周期長短,1.5表示1.5 s發(fā)送一次心跳,Master也會在每個1.5 s更新一次自己的存活列表.Y軸time表示發(fā)現(xiàn)死亡的時間,如MaxTry=3時,Frequency=1.5 s/times時需要4.5 s左右發(fā)現(xiàn)節(jié)點失效.

圖7 檢測到心跳時間與頻率圖Fig.7Check time with different heartbeat timeout and frequency

綜合圖中顯示的實驗結(jié)果可以看出,發(fā)現(xiàn)錯誤的時間與搜索間隔基本呈線性增長,更長的心跳間隔會產(chǎn)生更長的錯誤響應(yīng)時間.較短的心跳間隔會產(chǎn)生網(wǎng)絡(luò)阻塞而導(dǎo)致的錯誤報警,從而造成額外的容錯開銷,所以根據(jù)實際應(yīng)用場景選擇適合的心跳周期,是非常重要的.

在CLAIMS系統(tǒng)中,MaxTry設(shè)置為3,心跳間隔設(shè)為1 s,由在主節(jié)點上的協(xié)調(diào)器負責(zé)收集其他從節(jié)點上的心跳信息,當(dāng)3次沒有收到從節(jié)點的心跳就將從節(jié)點標(biāo)記為死亡.

3.3 Fail-over實驗

實驗設(shè)計思路及內(nèi)容

在CLAIMS系統(tǒng)中完成一組多個SQL語句的查詢計劃,并且在固定語句時使節(jié)點丟失,記錄所有的查詢時間,并且對比在未發(fā)生節(jié)點丟失的情況下的查詢時間,通過對比查詢時間的差異,來判斷Fail-over模塊的實際運行情況.步驟如下.

(1)啟動CLAIMS系統(tǒng),導(dǎo)入1G TPC-H數(shù)據(jù)集.

(2)輸入TPC-H SQL開始進行查詢(共計8條,依次輸入).

(3)手動停止Slave-a上的CLAIMS進程(在執(zhí)行TPC-H6時).

(4)獲取結(jié)果(查詢時間).

(5)重復(fù)2-4步驟6次,當(dāng)偶數(shù)次時,不進行第3步,統(tǒng)計所有的結(jié)果.

通過對比結(jié)果時間,可以看出,除去第4組測試語句,大部分語句的運行時間相差很小,在奇數(shù)次實驗時,第4個SQL查詢比偶數(shù)次實驗時耗時短很多,并在其后的語句中,用時略微超過偶數(shù)次實驗.在第4個手動中斷slave-a上的CLAIMS進程,導(dǎo)致系統(tǒng)直接返回錯誤,語句未完成B返回錯誤.除此之外,奇數(shù)次實驗的4～8個SQL語句的查詢耗時均比偶數(shù)次實驗有小幅度的增加,在有節(jié)點故障后,系統(tǒng)性能略有下降,fail-over模塊正常工作,并達到預(yù)期設(shè)計效果.

在CLAIMS系統(tǒng)中,發(fā)現(xiàn)有節(jié)點失效的信息,立刻停止在該節(jié)點上所分配任務(wù)的租約續(xù)租并且返回給客戶端錯誤信息,每個從節(jié)點在執(zhí)行計劃時會定期向主節(jié)點續(xù)租,當(dāng)?shù)玫綗o法續(xù)租的信息后,將放棄執(zhí)行該語句.

表1 CLAIMS系統(tǒng)完成各TPC-HSQL時間Tab.1Time result for different TPC-H SQL in CLAIMS

3.4 Fail-back實驗

實驗設(shè)計思路及內(nèi)容

模擬子節(jié)點宕機情況,通過檢查主節(jié)點上的存活列表,通過子節(jié)點是否重新出現(xiàn)在存活列表上,判斷子節(jié)點是否被成功Fail-back.

同F(xiàn)ail-fast實驗,使CLAIMS系統(tǒng)運行在3臺機器組成的集群上,使一臺Slave所在機器宕機,記錄在節(jié)點宕機后,在一定時間內(nèi)Master節(jié)點上存活列表中存活節(jié)點個數(shù).

實驗結(jié)果表如下(見表2和3).

表2 存活節(jié)點與時間圖(心跳頻率為1 s/次)Tab.2Number of alive node with times(frequency=1 s/times)

表3 存活節(jié)點與時間圖(心跳頻率為0.5 s/次)Tab.3Number of alive node with time(frequency=0.5 s/times)

實驗結(jié)果分析

表2記錄的是心跳周期為1 s,檢測間隔是1 s,最大嘗試次數(shù)為3次和5次的實驗結(jié)果情況,表3記錄的心跳周期為0.5 s,檢測間隔是0.5最大嘗試次數(shù)為3次和5次的實驗結(jié)果.

在MaxTry=3,Frequency=1 s/times時,在4 s時,發(fā)現(xiàn)存活列表中只有1個節(jié)點存活,在第5 s是,存活節(jié)點個數(shù)增加為2.在MaxTry=5,Frequency=1 s/times時,在5 s存活節(jié)點減少為1,并且在第6 s時重新加入存活列表.

在MaxTry=3,Frequency=0.5 s/times時,在1.5 s左右發(fā)現(xiàn)了節(jié)點丟失,并且在2 s左右重新加入存活列表,在MaxTry=5,Frequency=0.5 s/times時,在2.5 s左右發(fā)現(xiàn)了節(jié)點丟失,并且在3 s左右重新加入存活列表.

綜合以上結(jié)果,更多的錯誤嘗試次數(shù),或者更長的時間間隔,會導(dǎo)致容錯處理開始的時間變的更久,但是,并不會影響到錯誤處理的時間,無論參數(shù)如何變化,系統(tǒng)重啟節(jié)點的耗時是一定的.

在CLAIMS系統(tǒng)中,節(jié)點恢復(fù)時,主節(jié)點調(diào)用從節(jié)點腳本,重啟從節(jié)點,從節(jié)點重新向主節(jié)點發(fā)送注冊信息,直到注冊成功后,加入到存活列表.

4 結(jié)論

隨著數(shù)據(jù)分析進“海量數(shù)據(jù)時代”,面對越來越大數(shù)量級的數(shù)據(jù),分布式系統(tǒng)必將成為未來數(shù)據(jù)分析的主流載體.在數(shù)據(jù)實時分析領(lǐng)域,目前大部分分布式數(shù)據(jù)庫都不能達到其性能上的要求.CLAIMS系統(tǒng)作為主要面向金融領(lǐng)域的數(shù)據(jù)實時分析的內(nèi)存型數(shù)據(jù)庫,其可靠性與可用性必然有著更高的要求.本文及本文所描述的實驗,為CLAIMS系統(tǒng)加入了容錯機制,提高了系統(tǒng)的可用性與可靠性,為其商業(yè)應(yīng)用提供了技術(shù)支持.CLAIMS的容錯機制主要由以下幾個部分組成:

Fail-fast階段:在CLAIMS中,使用CAF來完成節(jié)點間的通信,實現(xiàn)Fail-fast機制. CLAIMS中對于節(jié)點的容錯需要采用短租約也就是心跳主動去監(jiān)測節(jié)點宕機或網(wǎng)絡(luò)失效所造的節(jié)點失效.

Fail-over階段:在CLAIMS中Fail-over將保證在節(jié)點出現(xiàn)故障時,不中斷地對外服務(wù).主節(jié)點保持監(jiān)聽從節(jié)點的活躍狀態(tài),當(dāng)某個節(jié)點不可用(丟失或死亡)時,主節(jié)點將其標(biāo)記為死亡節(jié)點,同時會終止該從節(jié)點上所有未執(zhí)行的query的租約的續(xù)租,所有的從節(jié)點都會放棄相關(guān)任務(wù),并接受由調(diào)度器新派發(fā)的任務(wù)繼續(xù)工作.

Fail-back階段:當(dāng)一臺機器宕機后,將使其恢復(fù)到正常的狀態(tài),繼續(xù)工作.目的是恢復(fù)原來該機器內(nèi)存中的數(shù)據(jù),以及已持久化的數(shù)據(jù).當(dāng)機器未宕機,只是從節(jié)點上的程序崩潰時,在主節(jié)點(Master)Fail-fast機制中會發(fā)現(xiàn)節(jié)點失效,發(fā)送命令,啟動存放在指定目錄下的重啟腳本,重啟該程序.當(dāng)出現(xiàn)機器宕機或停電等情況時,集群管理員重啟機器.

［1］TANENBAUM A S,STEEN M V.Distributed systems principles and paradigms[J].Acm,2002,87(3):65-73.

［2］COULOURIS G,DOLLIMORE J,KINDBERG T,et al.Distributed Systems:Concepts and Design.[M].5th ed.New Jersey:Addison-Wesley,2012:37-76.

［3］王立.分布式內(nèi)存數(shù)據(jù)庫系統(tǒng)的查詢處理與優(yōu)化[D].上海:華東師范大學(xué),2015.

［4］GRAY C,CHERITON D.Leases:An efficient fault-tolerant mechaism for distributed file cache consistency[J]. Acm Sigops Operating Systems Review,1989,23(5):202-210.

［5］CHAROUSSET D,HIESGEN R,SCHMIDT T C.CAF-the C++actor framework for scalable and resourceefficient applications[C].New York:ACM,2014:15-28.

［6］CASTRO M,LISKOV B.Practical byzantine fault tolerance and proactive recovery[J].Acm Transactions on Computer Systems,2002,20(4):398-461.

［7］BORTHAKUR D.The hadoop distributed file system:Architecture and design[J].Hadoop Project Website, 2007,11(11):1-10.

［8］關(guān)國棟,滕飛,楊燕.基于心跳超時機制的Hadoop實時容錯技術(shù)[J].計算機應(yīng)用,2015,35(10):2784-2788.

［9］ZAHARIA M,CHOWDHURY M,DAS T,et al.Resilient distributed datasets:A fault-tolerant abstraction for in-memory cluster computing[C]//Proceedings of the 9th USENIX conference on Networked Systems Design and Implementation.Berkeley:USENIX Association,2012:141-146.

［10］林春.分布式內(nèi)存數(shù)據(jù)庫的恢復(fù)[J].航空計算技術(shù),2003,33(2):90-92.

(責(zé)任編輯:張晶)

Fault-tolerance in distributed in-memory database systems

ZHAO Zhen-hui,HUANG Cheng-shen,ZHOU Min-qi,ZHOU Ao-ying
(Institute for Data Science and Engineering,East China Normal University,Shanghai200062,China)

In the big data era,distributed system has been widely deployed and applied in various fields.Nevertheless,the more nodes involved,the higher probability of system failures may occur.It is important to introduce fault-tolerance mechanism for distributed systems to achieve even higher performance,higher reliability and higher availability. CLAIMS system is an in-memory database system for real-time data analysis,which is mainly used for financial applications.It provides near real time query task and analytic task.This paper mainly discuss fault-tolerance mechanism in CLAIMS.Achieve lease-based quick system failure detection(Fail-fast).Achieve restart of affected analytic task after detecting failure(Fail-over).Achieve in-memory state recovery of abnormal node. Experiment indicate that the algorithm presented in this paper can achieve fault-tolerance in CLAIMS.

distributed in-memory database;fault-tolerance;lease

TP392

A

10.3969/j.issn.1000-5641.2016.05.004

1000-5641(2016)05-0027-09

2016-06

國家自然科學(xué)基金重點項目(61332006);上海市基金(13ZR1413200)

趙鎮(zhèn)輝,男,碩士研究生,研究方向為分布式數(shù)據(jù)庫.

周敏奇,男,教授,研究方向為對等計算、云計算、分布式數(shù)據(jù)管理和內(nèi)存數(shù)據(jù)管理系統(tǒng). E-mail:mgzhou@sei.ecnu.edu.cn.