專利名稱：一種云存儲數(shù)據(jù)同步框架及其實現(xiàn)方法
技術(shù)領(lǐng)域：
本發(fā)明屬于數(shù)據(jù)云存儲領(lǐng)域，特別是涉及數(shù)據(jù)同步框架的設(shè)計與實現(xiàn)。
背景技術(shù)：
隨著互聯(lián)網(wǎng)產(chǎn)業(yè)的飛速發(fā)展，海量數(shù)據(jù)的存儲及實時處理成了計算機行業(yè)亟待解決的難題。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫已經(jīng)不能處理海量數(shù)據(jù)中非結(jié)構(gòu)化數(shù)據(jù)日漸增長的特點，而以Hadoop為代表的分布式數(shù)據(jù)解決方案則開始成為業(yè)界關(guān)注的焦點。Hadoop框架已經(jīng)成為當(dāng)前進(jìn)行海量數(shù)據(jù)處理的首選框架，甚至被譽為“連接21世界海量數(shù)據(jù)處理的金鑰匙”。作為Hadoop的基礎(chǔ)模塊，HDFS為用戶提供了一個分布式的文件系統(tǒng)。HDFS采用經(jīng)典的master/slave架構(gòu)，一個搭建了 HDFS的集群往往是由一個作為master的Namenode節(jié)點和一定數(shù)目作為slave的Datanodes節(jié)點組成。HDFS的結(jié)構(gòu)可用
圖I進(jìn)行說明。Namenode是HDFS系統(tǒng)的核心。它是一個中心服務(wù)器，存儲著文件系統(tǒng)的所有元數(shù)據(jù)(Metadata)，包括名字空間、訪問控制信息、文件與數(shù)據(jù)存儲塊的映射關(guān)系，以及當(dāng)前系統(tǒng)內(nèi)所有數(shù)據(jù)塊的位置信息，用來管理文件系統(tǒng)中的命名空間及客戶端對文件系統(tǒng)的訪問。同時，Namenode節(jié)點還管理著系統(tǒng)范圍內(nèi)的活動，包括數(shù)據(jù)存儲塊的分配，孤兒存儲塊的回收，以及數(shù)據(jù)存儲塊在不同Datanodes節(jié)點之間的遷移。在實現(xiàn)上，Namenode節(jié)點使用心跳信息包周期性地與每個Datanode服務(wù)器聯(lián)系，并且維持一個在線Datanode的列表，發(fā)送指令到各個Datanode服務(wù)器并接收它們的狀態(tài)信息。HDFS的master/slave結(jié)構(gòu)具有高容錯的特點,可提供高吞吐量的數(shù)據(jù)訪問，非常適合海量數(shù)據(jù)集的應(yīng)用。HDFS放寬了對部分POXIS的限制，可方便地實現(xiàn)流式文件系統(tǒng)讀取的目的。由于master采用單一的Namenode服務(wù)器，優(yōu)點是容易實現(xiàn)，并且可以使用簡單有效的邏輯來管理元數(shù)據(jù)。然而，HDFS的這種結(jié)構(gòu)也存在缺點作為其master/slave架構(gòu)中master的中心服務(wù)器,Namenode節(jié)點為單一節(jié)點意味著,如果Namenode服務(wù)器失效,將造成整個文件系統(tǒng)的崩潰。并且，由于所有的訪問都要流經(jīng)Namenode結(jié)點，所以該單點也會成為系統(tǒng)的熱點，成為效率的瓶頸。針對Namenode失效的可能，HDFS本身采用了 FsImage與EditLog結(jié)合備份的方式。當(dāng)Namenode失效以后,文件系統(tǒng)可以根據(jù)硬盤中的映像FsImage及操作日志EditLog進(jìn)行恢復(fù)。根據(jù)文件系統(tǒng)的規(guī)模，恢復(fù)過程所花費的時間也有所不同；更重要的一點是，在Namenode的恢復(fù)期間，整個文件系統(tǒng)將處于不可訪問的狀態(tài)。目前在業(yè)界，也存在多種解決HDFS Namenode單點故障的HDFS HA (HighAvailability,高可用性)方案。如，F(xiàn)acebook公司的AvatarNode項目實際上提供了一種熱備方式。它采用Namenode主備切換的方式，當(dāng)主Namenode節(jié)點失效以后,通過人工切換的方式，將所有對Namenode的請求轉(zhuǎn)移到備機上去。而DRBD (Distributed ReplicatedBlock Device)則提供了一種冷備方式。當(dāng)將數(shù)據(jù)寫入本地DRBD設(shè)備上的文件系統(tǒng)時，數(shù)據(jù)會被同時發(fā)送到網(wǎng)絡(luò)中的另外一臺主機上，并以完全相同的形式被記錄在其上的文件系統(tǒng)中。本地節(jié)點與遠(yuǎn)程節(jié)點的數(shù)據(jù)可以保證實時同步，并且保證IO的一致性。所以當(dāng)本地節(jié)點的主機出現(xiàn)故障時，遠(yuǎn)程節(jié)點的主機上還會保留著一份完全相同的數(shù)據(jù)可供使用，從而達(dá)到了 HA的目的。這兩類方案雖然可以實現(xiàn)Namenode的故障恢復(fù)，體現(xiàn)了當(dāng)前HDFS HA (高可用性)的主要思路，但其缺點也顯然易見
1.并沒有將Namenode從單點中解放，同一時間仍只有一個中心服務(wù)器在線，所以它仍是系統(tǒng)的熱點。在大規(guī)模的集群應(yīng)用中，仍是系統(tǒng)效率的瓶頸；
2.由于需要在主機備機之間進(jìn)行數(shù)據(jù)的同步，同步的頻率從數(shù)秒到幾分鐘不等，則在Namenode失效之后，肯定有部分?jǐn)?shù)據(jù)被丟失；
3.主備切換需要人工的干預(yù)，從系統(tǒng)失效報警到人工切換備機，期間必定存在一定時間間隔，那這段時間內(nèi)，系統(tǒng)同樣是不可訪問的。

發(fā)明內(nèi)容
本發(fā)明針對Hadoop中心服務(wù)器節(jié)點Namenode的單點故障問題及以上應(yīng)對方案存在的缺陷，重點圍繞提高中心服務(wù)器的可用性，提出了一種云存儲數(shù)據(jù)同步框架。該框架能很好地解決Namenode單節(jié)點故障情況下的服務(wù)中斷問題，又不以犧牲系統(tǒng)的效率和部分?jǐn)?shù)據(jù)為代價，使系統(tǒng)即使發(fā)生服務(wù)器節(jié)點失效，依然可以高效正確的對外部訪問者提供數(shù)據(jù)訪問、管理整個文件系統(tǒng)，而無需人工干預(yù)，保證了數(shù)據(jù)的最終一致性。為解決上述技術(shù)問題，本發(fā)明采用的技術(shù)方案是提供一種云存儲數(shù)據(jù)同步框架，包括應(yīng)用于HDFS的經(jīng)典的master/slave架構(gòu),其中Namenode節(jié)點是中心服務(wù)器,所述云存儲數(shù)據(jù)同步框架采用雙中心服務(wù)器架構(gòu)，雙中心服務(wù)器同時在線服務(wù)。在HDFS架構(gòu)圖中，Namenode節(jié)點和Datanodes節(jié)點的關(guān)系是I :N,這突顯了 Namenode節(jié)點是不可或缺的。Namenode之所以如此重要，還因為HDFS系統(tǒng)中最重要的元數(shù)據(jù)的唯一一份拷貝在該Namenode服務(wù)器中。而Datanodes的請求往往是對Metadata數(shù)據(jù)的讀寫訪問，因此,倘若Metadata在多臺服務(wù)器上存在多個副本,那么對Namenode節(jié)點的聯(lián)系就可以分散到不同的機器上去了?；谶@樣的思想，本發(fā)明提出了基于雙中心服務(wù)器的HDFS架構(gòu)，改進(jìn)后的架構(gòu)可以用圖2說明。在本發(fā)明的這個架構(gòu)中，Namenode節(jié)點不再唯一,從而除去了構(gòu)成單點故障的必要條件。即使在一個Namenode服務(wù)器失效離線之后，只要另一個Namenode服務(wù)器在線，HDFS系統(tǒng)就可以正常運作。從而解決了 HDFS存在的單點問題。在雙中心服務(wù)器中，它們的內(nèi)存中都保存著一份最新的元數(shù)據(jù)，外部請求會依據(jù)一定的策略被分發(fā)到某個Namenode服務(wù)器，這樣就緩解了僅有一臺中心服務(wù)器所帶來的熱點問題。所以，我們的方案中所述Namenode節(jié)點可以有多個,每個Namenode節(jié)點都保存有最新的元數(shù)據(jù)。另外，需要指出的是，雙中心服務(wù)器架構(gòu)并不同于雙機熱備中雙主機的方式。雙機熱備的雙主機方式即指兩種不同業(yè)務(wù)分別在兩臺服務(wù)器上互為主備狀態(tài)(即Active-Standby和Standby-Active狀態(tài))。兩者的區(qū)別在于,雙主機方式即服務(wù)器上兩種不同的服務(wù)分別在兩臺服務(wù)器上互為主備，言外之意就是該方式下，兩臺服務(wù)器雖然會同時在線，響應(yīng)外界的請求，但對某項功能(或服務(wù))而言，卻是只有一臺服務(wù)器可以提供的，因此將粒度細(xì)分到服務(wù)上，就會發(fā)現(xiàn)它其實也是Active-Standby方式。而雙中心服務(wù)器的特點是兩臺中心服務(wù)器的地位完全對等，無論從粗粒度角度把它當(dāng)個黑盒來對待，還是細(xì)化到單個功能服務(wù)上，兩個服務(wù)器對外界而言是完全對等的。在該架構(gòu)下，客戶端對一個服務(wù)器提出的請求實際上也可以由另一服務(wù)器來進(jìn)行處理。上述基于多Namenode節(jié)點的方案還面臨著一個顯而易見的問題即如何保持這多個Namenode節(jié)點之間數(shù)據(jù)的一致性，杜絕臟數(shù)據(jù)的出現(xiàn)。這是屬于分布式一致性范疇領(lǐng)域研究的問題。分布一致性問題是分布式算法中的一個經(jīng)典問題。在一個分布式系統(tǒng)中，存在一組Process,它們需要確定一個Value。于是每個Process都提出了一個Value, —致性是指只有其中的一個Value能夠被選中作為最后確定的值，并且當(dāng)這個值被選出來以后，所有的Process都需要被通知到。在分布式系統(tǒng)中，可能存在各種各樣的問題。例如，某臺服務(wù)器崩潰了怎么辦，所以我們可能需要有幾臺服務(wù)器共同決定。此外，Process提交Value的時間都不一樣，網(wǎng)絡(luò)
傳輸過程中由于延遲這些Value到達(dá)server的順序也都沒有保證。為了解決此類問題，我們進(jìn)一步提出數(shù)據(jù)一致性的設(shè)計。經(jīng)過對多種分布式一致性算法的對比，本發(fā)明最終選擇了經(jīng)典算法Paxos作為本方案的分布一致性算法的基礎(chǔ)。Paxos算法被業(yè)界視為該領(lǐng)域中最經(jīng)典的算法。本發(fā)明將復(fù)雜的Paxos算法進(jìn)行了簡化，將適應(yīng)于多機選舉的Paxos算法改造為三機Paxos算法。改造的三機Paxos算法設(shè)定存在三個結(jié)點A、B和C，這三個節(jié)點都具備acceptor和learner角色，其中A和B還具有proposer的角色。對于A (B)，它提出的提案，只要B (A)或C中任意一個acc印t 了，加上它自己就足夠構(gòu)成多數(shù)派，因此選舉的關(guān)鍵在于讓B (A)或C中任意一個acceptor通過(accept)提案。假設(shè)A選擇一個提案編號η,并向B和C發(fā)送prepare請求,此時B有三種情況
I. B沒有accept任何請求,也沒有prepare比η編號更大的請求,則B會承諾不再批準(zhǔn)小于η的提案。A和B構(gòu)成多數(shù)派，A繼續(xù)提出(propose)這個提案。2. B已經(jīng)prepare編號為m (m>n)的請求,貝U這個prepare請求一定是B提出的。此時，C的prepare結(jié)果決定了 A和B誰會提議(propose)議案。3. B已經(jīng)accept 了編號為m (m>n)的請求,則這個請求一定是B提出的,而且C必然也已經(jīng)prepare 了編號為m的請求,則A不能再提出任何請求,它必須accept這個編號為m的請求。 對于C也有三種情況
I. C沒有accept任何請求,也沒有prepare比η編號更大的請求,則C會承諾不再批準(zhǔn)小于η的提案。A加上C構(gòu)成多數(shù)派，A繼續(xù)提出(propose)這個提案。2. C已經(jīng)prepare編號為m (m>n)的請求，則這個prepare請求一定是B提出的，并且B和C已構(gòu)成多數(shù)派，B會提出(propose)提案。此時A需要再選擇一個更大的編號。3. C已經(jīng)accept 了編號為m的請求,此時B和C都已accept該請求,構(gòu)成多數(shù)派，A必須服從這個決定，accept這個請求。也就是說,無論如何,經(jīng)過至多2次提議(propose), A、B和C之間一定會得到一個多數(shù)派，A和B可以繼續(xù)提議(propose)，并且該議案會被最終批準(zhǔn)。本發(fā)明結(jié)合雙中心服務(wù)器架構(gòu)以及改造的Paxos算法實現(xiàn)了數(shù)據(jù)同步框架Quorum。它從避免全局單點入手，實現(xiàn)雙機可寫，并保證數(shù)據(jù)的最終一致性。利用該數(shù)據(jù)同步框架Quorum，本發(fā)明提出了基于雙中心服務(wù)器的HDFS高可用方案。即將HDFS的中心服務(wù)器進(jìn)行復(fù)制，建立關(guān)系對等的兩個中心服務(wù)器，同時對外提供相同的功能，并使用Quorum框架保持?jǐn)?shù)據(jù)一致性。使得即便在某個Namenode服務(wù)器出現(xiàn)故障的情況下，HDFS照樣能維持良好運作。本發(fā)明所述的云存儲數(shù)據(jù)同步框架的實現(xiàn)方法，包括寫操作、讀操作和同步操作。所述寫操作包括以下步驟
步驟5. 1，客戶端寫操作請求發(fā)送到結(jié)點A ；
步驟5. 2，結(jié)點A請求提升本地版本號；
步驟5.3，結(jié)點B/C接收請求，提升本地版本號；
步驟5. 4，結(jié)點A等待結(jié)點B/C返回結(jié)果；
步驟5. 5，結(jié)點A更新本地數(shù)據(jù)。所述讀操作包括以下步驟
步驟6. 1，客戶端讀操作請求發(fā)送到結(jié)點A ；
步驟6. 2，結(jié)點A自檢本地數(shù)據(jù)是否是正確的數(shù)據(jù)；
步驟6. 3，向結(jié)點B請求版本號信息，詢問B是否同自己的意見一致；
步驟6. 4，結(jié)點A等待結(jié)點B返回結(jié)果；
步驟6. 5，結(jié)點A向結(jié)點C請求版本信息；
步驟6. 6，結(jié)點A允許讀出數(shù)據(jù)。所述同步操作包括以下步驟
步驟7. 1，掃描結(jié)點A (B)的流水日志，取出對Key的操作；
步驟7. 2，確定系統(tǒng)中的多數(shù)派；
步驟7. 3，數(shù)據(jù)復(fù)制，假定結(jié)點A數(shù)據(jù)較新，需要將結(jié)點A的數(shù)據(jù)復(fù)制到結(jié)點B，并更新A/B/C三結(jié)點的版本號。與現(xiàn)有技術(shù)相比，有益效果是
I.避免全局單點，將重要的數(shù)據(jù)保存多份副本，置放在不同的服務(wù)器之上。這樣即使一臺中心服務(wù)器主機出現(xiàn)網(wǎng)絡(luò)割裂、物理宕機等故障而造成服務(wù)不可訪問時，還有其它的中心服務(wù)器可以代替故障服務(wù)器，提供相同的服務(wù)。在本發(fā)明的方案設(shè)計中，提供雙中心服務(wù)器來保存核心數(shù)據(jù)。2.實現(xiàn)雙機可寫，兩臺服務(wù)器才可能處于對等的位置，保證最終數(shù)據(jù)一致性。3.在某臺主機發(fā)生故障時，應(yīng)盡量減少對讀寫服務(wù)的影響。在傳統(tǒng)的雙機熱備方式下，當(dāng)主機不可訪問后，備機會用來對外界提供可讀服務(wù)，卻往往是不可寫的，這樣的目的是為了保證主機數(shù)據(jù)的最新。然而Quorum框架則應(yīng)當(dāng)保證即使在某臺主機出現(xiàn)故障后，另外一臺主機仍然可以對外提供受限的可讀可寫服務(wù)。4.由于同時有兩臺服務(wù)器對外提供服務(wù)，通過有效的負(fù)載方案，將使客戶端請求在兩臺服務(wù)器上進(jìn)行負(fù)載平衡，從而提高了系統(tǒng)效率。


圖I為Hadoop的模塊組成圖；圖2為本發(fā)明的雙中心服務(wù)器架構(gòu) 圖3為本發(fā)明的同步數(shù)據(jù)框架Quorum的模塊組成 圖4為本發(fā)明的同步數(shù)據(jù)框架Quorum寫操作的程序流程 圖5為本發(fā)明的同步數(shù)據(jù)框架Quorum讀操作的程序流程 圖6為本發(fā)明的同步數(shù)據(jù)框架Quorum的同步程序流程圖。
具體實施例方式本發(fā)明提出了針對HDFS的高可用性方案——雙中心服務(wù)器Namenodes節(jié)點。為解決該結(jié)構(gòu)存在的數(shù)據(jù)分布式一致性問題而構(gòu)造了數(shù)據(jù)同步框架Quorum。其理論基礎(chǔ)是在經(jīng)典Paxos算法上進(jìn)行改造，實現(xiàn)三機Paxos算法。下面結(jié)合附圖對本發(fā)明的實現(xiàn)做進(jìn)一步的說明。為避免單點故障，實現(xiàn)雙機可寫，保證中心服務(wù)器狀態(tài)的最終一致性，并且當(dāng)某臺中心服務(wù)器發(fā)生故障時仍框架仍可對外提供讀寫服務(wù)，本發(fā)明設(shè)計了數(shù)據(jù)同步框架Quorum,其模塊圖如圖3所示。在本發(fā)明的模塊圖中存在兩個中心服務(wù)器結(jié)點A和B，它們是關(guān)系對等的實體。A (B)兩個中心服務(wù)器對外提供訪問本機數(shù)據(jù)的接口，這是為了避免單點故障而設(shè)計的雙中心服務(wù)器。Quorum框架還包含一個仲裁結(jié)點C，該仲裁結(jié)點與結(jié)點A、B 一起構(gòu)成了三機Paxos算法的基本成員。數(shù)據(jù)結(jié)點A (B)在保存數(shù)據(jù)的同時，以鍵值對(Key，Value)的形式保存。而結(jié)點會為每個數(shù)據(jù)項的鍵Key，維持一個版本號，表示本地這個鍵值對應(yīng)的版本信息。例如，結(jié)點A會為鍵Key記錄版本對{VerAa，VerAb}，結(jié)點B會記錄版本對{VerBa，VerBb}，仲裁結(jié)點C會記錄版本對{VerCa，VerCb}。以結(jié)點A的{ VerAa，VerAb}為例，它表示結(jié)點A認(rèn)為鍵值Key在結(jié)點A中的版本號為VerAa，在結(jié)點B中的版本號為VerAb。用這樣的數(shù)據(jù)結(jié)構(gòu)來記錄版本信息的優(yōu)點在于，當(dāng)向結(jié)點A請求對Key所對應(yīng)的數(shù)據(jù)進(jìn)行讀寫時，結(jié)點A會先進(jìn)行自檢，若VerAa < VerAb，即結(jié)點A認(rèn)為結(jié)點B上的數(shù)據(jù)比本地結(jié)點A上的數(shù)據(jù)更新，它會直接向請求方返回請求無效，讓請求方向結(jié)點B發(fā)請求。這樣可以直接提高對臟數(shù)據(jù)處理時的效率。仲裁結(jié)點C是當(dāng)結(jié)點A、B出現(xiàn)版本沖突時，對沖突進(jìn)行仲裁的結(jié)點。因為結(jié)點C記錄的版本信息無論是同結(jié)點A、B中的哪一方一致，結(jié)點C都會與一致的一方構(gòu)成多數(shù)派，從而決定結(jié)點A、B中誰的數(shù)據(jù)正確的可能性更高。因此結(jié)點C只需要記錄Key對應(yīng)的版本即可，而Key所對應(yīng)的值Value則由A (B)記錄。為了減少A、B兩個數(shù)據(jù)結(jié)點之間的數(shù)據(jù)不一致所造成的沖突，本發(fā)明的Quorum框架提供了一個同步工具。在Quorum系統(tǒng)中，因為請求會散布到不同的結(jié)點A或B上，所以雙機數(shù)據(jù)會出現(xiàn)短時間的不一致，這需要由該同步工具進(jìn)行數(shù)據(jù)和版本號的同步。數(shù)據(jù)同步框架Quorum的理論基礎(chǔ)是三機Paxos算法。對一個分布式系統(tǒng)而言,利用經(jīng)典Paxos算法就某個值(決議)達(dá)成一致將會經(jīng)歷咨詢(prepare)-〉提案(propose)-〉承諾(promise)->通過(accept)->批準(zhǔn)(chosen)等一系列狀態(tài)，因此經(jīng)典Paxos算法的實現(xiàn)是相當(dāng)復(fù)雜的。三機Paxos算法對它進(jìn)行了改造,在本質(zhì)上仍然遵循Paxos算法的流程，但是將應(yīng)用場景局限在雙機結(jié)點中，從而使處理邏輯變得簡單易懂。
顯而易見，數(shù)據(jù)結(jié)點A (B)分別扮演了 Paxos算法中proposer、acceptor及l(fā)earner的角色,而仲裁結(jié)點C只扮演了 acceptor及l(fā)earner的角色。本發(fā)明對數(shù)據(jù)同步框架Quorum的數(shù)據(jù)流程進(jìn)行了設(shè)計?？蛻舳藢?shù)據(jù)結(jié)點的操作請求包括讀請求和寫請求。此外，Quorum框架還包括同步操作。圖4是數(shù)據(jù)同步框架Quorum處理寫請求操作的過程。 假設(shè)結(jié)點A收到客戶端請求(因為數(shù)據(jù)結(jié)點A、B是完全對等的關(guān)系，即使是結(jié)點B收到請求，其寫請求的操作過程也類似)。寫操作的流程大致如下
I.客戶端寫操作請求發(fā)送到結(jié)點A。2.因為是更新操作，所以結(jié)點A請求提升本地版本號
1)首先檢查本地版本號信息，判斷ver_a與ver_b的大小關(guān)系，提升版本條件為A. ver_a >= A. ver_b ；
2)若條件成立，貝Ij提升A.ver_a = A. ver_a + I,并繼續(xù)執(zhí)行；否則說明結(jié)點A通過自查發(fā)現(xiàn)持有的是臟數(shù)據(jù)，不能進(jìn)行更新，因此返回寫操作失敗，說明這種情況下需要同步工具修復(fù)；
3)向結(jié)點B/C廣播提升版本號請求，要求在條件成立的前提下將ver_a自加。3.結(jié)點B (C)接收請求，提升本地版本號
1)檢查本地版本號信息，判斷B(C). ver_a >= B (C). ver_b ；
2)若條件成立，貝Ij提升 B(C).ver_a = B (C). ver_a + I ；
3)將檢查結(jié)果返回給結(jié)點A。4.結(jié)點A等待結(jié)點B/C返回結(jié)果
1)若收到結(jié)點B或C的提升成功信息，則繼續(xù)執(zhí)行；
2)若兩結(jié)點均返回提升失敗，或提升請求超時，則返回寫請求失敗。5.結(jié)點A更新本地數(shù)據(jù)。上述流程中涉及需要同步工具的修復(fù)會在稍后同步操作中進(jìn)行詳細(xì)的說明。在第4步中，結(jié)點A等待B/C的返回結(jié)果，只有收到結(jié)點B或C提升成功的返回信息，才表示寫操作的前提成立，因為這表示多數(shù)派已經(jīng)存在，沒必要達(dá)成全體版本的一致。寫操作的流程首先檢測版本號，然后提升版本號，上述所有過程完成之后才會進(jìn)行實質(zhì)的數(shù)據(jù)寫入。才流程采納了兩段事務(wù)提交的思想(two-phase commit)。若先寫入數(shù)據(jù)再提升A、B、C的版本號，而此期間如出現(xiàn)網(wǎng)絡(luò)問題等導(dǎo)致操作失敗，版本號沒有得到及時更新，則這些寫入的數(shù)據(jù)就會成為臟數(shù)據(jù)，并同時抹去了之前的數(shù)據(jù)。而提升版本號后，再寫入數(shù)據(jù)，即使寫入數(shù)據(jù)失敗，A、B、C中所有的版本都提升1，對判斷多數(shù)派是沒有影響的。上述的先判斷版本號，然后再將版本號加I的操作應(yīng)當(dāng)是原子性、不可中斷的，否則就會出現(xiàn)臟數(shù)據(jù)。寫操作的有三個可能的返回點，一是寫操作成功，數(shù)據(jù)被成功的寫入數(shù)據(jù)結(jié)點A(或B); 二是寫操作失敗，原因是結(jié)點A通過自查發(fā)現(xiàn)本地的數(shù)據(jù)是臟數(shù)據(jù)，需要同步工具的修復(fù)；第三種返回結(jié)果是寫操作失敗，原因是結(jié)點B及C都沒能成功提升版本號，結(jié)點B與C組成了一個多數(shù)派，認(rèn)為結(jié)點A持有的是臟數(shù)據(jù)，不能進(jìn)行更新。相較寫操作而言，讀操作較為簡單，可用圖5表示。對一個數(shù)據(jù)結(jié)點而言，它自己本身是沒有辦法確定自己持有數(shù)據(jù)的正確性(或者是否是最新數(shù)據(jù))的，因此它至少要與結(jié)點B (或C)發(fā)生一次通訊，來判斷版本信息是否有沖突，這個通訊過程其實是Paxos算法中確定多數(shù)派的一個過程。讀操作的流程大致如下
I.客戶端讀操作請求發(fā)送到結(jié)點A。2.結(jié)點A首先根據(jù){VerAa, VerAb}自檢本地數(shù)據(jù)是否是正確的數(shù)據(jù)
1)首先檢查本地版本號信息，判斷ver_a與ver_b的大小關(guān)系,條件為A.ver_a >=A. ver_b ；
2)若條件成立，則說明結(jié)點A認(rèn)為自己持有的是最新數(shù)據(jù)，它需要再聯(lián)系一個同盟，繼續(xù)執(zhí)行；否則說明本地數(shù)據(jù)是過期的臟數(shù)據(jù)，返回讀操作失敗，讓客戶端向結(jié)點B申請讀操作。3.向結(jié)點B請求版本號信息，詢問B是否同自己的意見一致
1)結(jié)點B檢查本地版本號信息,判斷B.ver_a >= B. ver_b ；
2)若條件成立，則說明結(jié)點A持有的是最新信息，結(jié)點B與A組成多數(shù)派，可以不用再考慮仲裁結(jié)點C的意見；若條件不成立，則說明結(jié)點A與B發(fā)生版本沖突，還需要由結(jié)點C進(jìn)行裁決；
3)將檢查結(jié)果返回給結(jié)點A。4.結(jié)點A等待結(jié)點B返回結(jié)果
1)若結(jié)點B返回B.ver_a < B. ver_b,則需再同結(jié)點C發(fā)生一次通訊,繼續(xù)執(zhí)行；
2)若結(jié)點B返回B.ver_a >= B. ver_b的結(jié)果，則A、B已經(jīng)通過查詢請求，允許讀出數(shù)據(jù)，返回讀操作成功。5.結(jié)點A向結(jié)點C請求版本信息
1)仲裁結(jié)點C檢查自己的版本號,判斷本地C.ver_a >= C. ver_b ；
2)若條件成立，則說明結(jié)點A與C組成了多數(shù)派，繼續(xù)執(zhí)行；若條件不成立，則結(jié)點C與B組成了多數(shù)派，返回讀失?。?br> 3)結(jié)點C將檢查結(jié)果返回給結(jié)點A。6.結(jié)點A允許讀出數(shù)據(jù)，返回讀操作成功。從效率上考慮，數(shù)據(jù)同步框架Quorum提供的讀操作至少需要通過一次通訊，如果第一次通訊不能組成多數(shù)派，則需要再進(jìn)行第二次通訊，因此在效率上確實會有所降低。然而這個過程卻是必不可少的，因此只有當(dāng)結(jié)點確認(rèn)自己持有的是最新數(shù)據(jù)之后，才可以負(fù)責(zé)任地交給客戶端，這個通訊過程是Paxos算法中組成多數(shù)派必需的。讀操作的返回結(jié)果只有兩種可能一種結(jié)果是結(jié)點A持有的是最新數(shù)據(jù)，允許讀出，讀操作成功；另外一種可能的結(jié)果是結(jié)點A持有的是臟數(shù)據(jù)，這樣并非只單純地返回讀操作失敗，而是讓客戶端去向結(jié)點B索取數(shù)據(jù)，而這個過程是無需再次進(jìn)行通信的，因為已經(jīng)可以肯定結(jié)點B持有的是正確的數(shù)據(jù)。因此讀操作也分為嘗試讀及肯定讀兩種可能。在最壞情況下，讀一次數(shù)據(jù)至少要發(fā)生4次通信。通信次數(shù)是算法必需的，不可減少，因此改善這種問題只能從減少最壞情況出現(xiàn)的次數(shù)入手。在數(shù)據(jù)同步框架Quorum系統(tǒng)中，雙機數(shù)據(jù)會出現(xiàn)短時間的不一致，因此需要同步工具進(jìn)行數(shù)據(jù)和版本號的同步。假設(shè)這樣一種情況，客戶端的一條對與Key對應(yīng)的數(shù)據(jù)項的寫請求被轉(zhuǎn)發(fā)到了結(jié)點A，并且經(jīng)過Quorum內(nèi)部的通信之后，該寫請求被允許，結(jié)點A的數(shù)據(jù)成為最新，稍后客戶端又有一條關(guān)于該Key的讀請求被轉(zhuǎn)發(fā)到了數(shù)據(jù)結(jié)點B，但結(jié)點B的數(shù)據(jù)是臟數(shù)據(jù)，經(jīng)過內(nèi)部通信后，該讀請求會被拒絕，要求客戶端去向結(jié)點A申請數(shù)據(jù)。前面已經(jīng)討論過，這樣的一個讀請求至少要通過4次通信。然而倘若在客戶端的讀請求被發(fā)送之前，B結(jié)點的版本號與數(shù)據(jù)就已經(jīng)被同步工具進(jìn)行過同步，同結(jié)點A —樣保持最新，那顯然讀請求會得到執(zhí)行，而非拒絕。因此，同步操作是減少數(shù)據(jù)不一致，提高讀寫操作效率的一個重要步驟。同步操作的流程可用圖6表示，以結(jié)點A為例，其具體的操作流程如下
I.掃描結(jié)點A (B)的流水日志，取出對Key的操作。2.確定系統(tǒng)中的多數(shù)派。I)廣播詢問A/B/C三結(jié)點，獲得三結(jié)點各自版本號關(guān)系rA，rB和rC CrX =X. ver_a - X. ver_b);
2)根據(jù)版本號關(guān)系中多數(shù)派的結(jié)果，得到結(jié)點A還是結(jié)點B數(shù)據(jù)較新。3.數(shù)據(jù)復(fù)制。假定結(jié)點A數(shù)據(jù)較新，需要將結(jié)點A的數(shù)據(jù)復(fù)制到結(jié)點B，并更新A/B/C三結(jié)點的版本號(若結(jié)點B數(shù)據(jù)較新，采用相同的邏輯進(jìn)行處理)
1)從結(jié)點A 讀出 curr_data=A· data 和 curr_ver=A· ver_a, PUSH 到 B 和 C ;
2)結(jié)點B :若 curr_ver < B. ver_a,則放棄;否則,先更新數(shù)據(jù) B. data = curr_data,再更新版本號B. ver_a = B. ver_b = curr_ver ；
3)結(jié)點C:若curr_ver < C. ver_a,則放棄，否則更新版本號C. ver_a = C. ver_b=curr_ver ；
4)最后結(jié)點A更新版本號，A.ver_b = curr_ver。上述流程中所指的本地流水日志用來記錄數(shù)據(jù)結(jié)點A (或B)上對某Key進(jìn)行寫操作的記錄，因為讀操作不涉及到數(shù)據(jù)的更新，因此不用記錄到日志中。本地流水日志只是一個抽象的概念，具體實現(xiàn)因應(yīng)用場景及需求而有所不同，Quorum框架本身不指定流水日志的格式。在進(jìn)行數(shù)據(jù)復(fù)制的過程中，如結(jié)點A的數(shù)據(jù)較新，PUSH到結(jié)點B進(jìn)行更新，則應(yīng)要求先更新數(shù)據(jù)，當(dāng)數(shù)據(jù)更新成功后再更新版本號。因為在Quorum系統(tǒng)中，版本號直接決定了一個數(shù)據(jù)項的有效性，即使原始數(shù)據(jù)為臟數(shù)據(jù)，通過版本號也可以正確地識別，而不進(jìn)行采納。而版本號是不允許出現(xiàn)臟數(shù)據(jù)的，因為沒有針對版本號的查錯機制。
權(quán)利要求
1.一種云存儲數(shù)據(jù)同步框架，包括應(yīng)用于HDFS的經(jīng)典的master/slave架構(gòu)，其中Namenode節(jié)點是中心服務(wù)器，其特征是，所述云存儲數(shù)據(jù)同步框架采用雙中心服務(wù)器架構(gòu)，雙中心服務(wù)器同時在線服務(wù)。
2.根據(jù)權(quán)利要求I所述的云存儲數(shù)據(jù)同步框架，所述Namenode節(jié)點有多個，每個Namenode節(jié)點都保存有最新的元數(shù)據(jù)。
3.根據(jù)權(quán)利要求I所述的云存儲數(shù)據(jù)同步框架，所述云存儲數(shù)據(jù)同步框架采用適應(yīng)于三機Paxos算法。
4.根據(jù)權(quán)利要求1-3任一項所述的云存儲數(shù)據(jù)同步框架的實現(xiàn)方法，包括寫操作、讀操作和同步操作。
5.根據(jù)權(quán)利要求4所述的實現(xiàn)方法，其特征是，所述寫操作包括以下步驟 步驟5. 1，客戶端寫操作請求發(fā)送到結(jié)點A ； 步驟5. 2，結(jié)點A請求提升本地版本號； 步驟5.3，結(jié)點B/C接收請求，提升本地版本號； 步驟5. 4，結(jié)點A等待結(jié)點B/C返回結(jié)果； 步驟5. 5，結(jié)點A更新本地數(shù)據(jù)。
6.根據(jù)權(quán)利要求4所述的實現(xiàn)方法，其特征是，所述讀操作包括以下步驟 步驟6. 1，客戶端讀操作請求發(fā)送到結(jié)點A ； 步驟6. 2，結(jié)點A自檢本地數(shù)據(jù)是否是正確的數(shù)據(jù)； 步驟6. 3，向結(jié)點B請求版本號信息，詢問B是否同自己的意見一致； 步驟6. 4，結(jié)點A等待結(jié)點B返回結(jié)果； 步驟6. 5，結(jié)點A向結(jié)點C請求版本信息； 步驟6. 6，結(jié)點A允許讀出數(shù)據(jù)。
7.根據(jù)權(quán)利要求4所述的實現(xiàn)方法，其特征是，所述同步操作包括以下步驟 步驟7. 1，掃描結(jié)點A (B)的流水日志，取出對Key的操作； 步驟7. 2，確定系統(tǒng)中的多數(shù)派； 步驟7. 3，數(shù)據(jù)復(fù)制，假定結(jié)點A數(shù)據(jù)較新，需要將結(jié)點A的數(shù)據(jù)復(fù)制到結(jié)點B，并更新Α/B/C三結(jié)點的版本號。
8.根據(jù)權(quán)利要求7所述的實現(xiàn)方法，其特征是，所述流水日志為數(shù)據(jù)結(jié)點上對Key進(jìn)行寫操作的記錄。
全文摘要
本發(fā)明在分析當(dāng)前Hadoop框架中HDFS模塊存在的中心服務(wù)器Namenode節(jié)點的單點故障這一缺陷的基礎(chǔ)上，提出了一種云存儲數(shù)據(jù)同步框架，所述云存儲數(shù)據(jù)同步框架采用雙中心服務(wù)器架構(gòu)，雙中心服務(wù)器同時在線服務(wù)，解決了數(shù)據(jù)的一致性問題，并基于分布一致性Paxos算法，設(shè)計了針對雙中心服務(wù)器的三機Paxos算法，從而構(gòu)成數(shù)據(jù)同步框架Quorum，并規(guī)范了該架構(gòu)上的讀寫操作。采用本發(fā)明的數(shù)據(jù)同步框架Quorum，將能很好地解決Namenode節(jié)點單點故障情況下的服務(wù)中斷問題，使系統(tǒng)在某一服務(wù)器出問題的情況下依然可以對外提供正確的數(shù)據(jù)讀寫訪問，并保證數(shù)據(jù)的最終一致性。
文檔編號H04L29/08GK102882927SQ201210313628
公開日2013年1月16日 申請日期2012年8月29日 優(yōu)先權(quán)日2012年8月29日
發(fā)明者劉發(fā)貴, 楊英儀, 楊平安 申請人:華南理工大學(xué)