分布式一致性算法的研究及應(yīng)用

王志瑞 王幕天 劉正濤 黃慧

摘 要： 為了能在分布式環(huán)境下使用FibJs開發(fā)出持續(xù)高可用性的服務(wù)，并能保證分布式環(huán)境下的數(shù)據(jù)一致性，研究了分布式系統(tǒng)中的一致性問題。分析了分布式一致性算法Paxos，研究了該算法的工作原理，并對(duì)該算法進(jìn)行了優(yōu)化。根據(jù)算法思想設(shè)計(jì)了一種適應(yīng)于分布式環(huán)境下的數(shù)據(jù)一致性的方案，采用FibJs對(duì)該方案進(jìn)行了實(shí)現(xiàn)，并在集群環(huán)境下對(duì)該方案進(jìn)行了檢驗(yàn)。驗(yàn)證結(jié)果表明，該方案能夠很好的解決分布式環(huán)境下數(shù)據(jù)一致性問題。

關(guān)鍵詞： 一致性算法； Paxos； 分布式系統(tǒng)； 數(shù)據(jù)一致性； FibJs

中圖分類號(hào)：TP399 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1006-8228（2015）12-13-05

Research and application of distributed consensus algorithm

Wang Zhirui， Wang Mutian， Liu Zhengtao， Huang Hui

（Department of Computer and Information Engineering， Sanjiang University， Nanjing， Jiangsu 210012， China）

Abstract： In order to use FibJs to develop a continuous high availability service in distributed environment and to ensure the consensus of data in the environment， this paper studies the consensus problem in distributed systems. The distributed consensus algorithm Paxos is analyzed； the working principle of the algorithm is studied and then is optimized. According to the idea of the algorithm， a data consensus scheme adapted to the distributed environment is designed； the scheme is implemented by using FibJs and has been verified in a cluster environment. The verification results show that the proposed scheme can solve the consensus problem in distributed environment.

Key words： consensus algorithm； Paxos； distributed system； data consensus； FibJs

0 引言

當(dāng)今，企業(yè)對(duì)計(jì)算機(jī)的依賴越來越強(qiáng)，為了保證企業(yè)的關(guān)鍵業(yè)務(wù)不出現(xiàn)故障，出現(xiàn)了雙機(jī)熱備，雙機(jī)雙工相關(guān)的技術(shù)來保證系統(tǒng)的穩(wěn)定性，但是這些方案的投資和部署難度都比較大，對(duì)于一些傳統(tǒng)的應(yīng)用支持比較好，而對(duì)于一些新技術(shù)的支持不是特別的好。為了能在分布式環(huán)境下使用FibJs開發(fā)出持續(xù)高可用性的服務(wù)，并能保證分布式環(huán)境下的數(shù)據(jù)一致性。

本文研究了分布式系統(tǒng)中的一致性問題，研究了分布式一致性算法Paxos的原理，并對(duì)該算法進(jìn)行了優(yōu)化?；赑axos算法的思想設(shè)計(jì)出了一種適用于分布式環(huán)境下的數(shù)據(jù)一致性的方案。采用FibJs對(duì)該方案進(jìn)行了實(shí)現(xiàn)，并在集群環(huán)境下對(duì)該方案進(jìn)行了檢驗(yàn)。結(jié)果表明，該方案能夠很好地解決分布式環(huán)境下的數(shù)據(jù)一致性問題。

1 一致性算法Paxos

Paxos是由微軟的Leslie Lamport提出的一種基于消息傳遞的分布式一致性算法，其解決的問題是：一個(gè)分布式系統(tǒng)中如何就某個(gè)決議達(dá)成一致。Paxos可以應(yīng)用在數(shù)據(jù)復(fù)制、命名服務(wù)、配置管理、權(quán)限設(shè)置和號(hào)碼分配等場合[1-2]，是解決分布式一致性問題最有效的算法之一。現(xiàn)實(shí)中一些優(yōu)秀軟件的心臟，如Cassandra，Google的Spanner數(shù)據(jù)庫，分布式鎖服務(wù)Chubby都是利用Paxos算法設(shè)計(jì)的。

在分布式系統(tǒng)中節(jié)點(diǎn)崩潰、網(wǎng)絡(luò)故障時(shí)常會(huì)發(fā)生，Paxos算法側(cè)重解決的便是在一個(gè)可能發(fā)生上述異常的分布式系統(tǒng)中就某個(gè)值達(dá)成一致，保證不論發(fā)生何種異常，都不會(huì)破壞系統(tǒng)的一致性。

2 算法分析及優(yōu)化

2.1 算法分析

在Paxos算法中，有三種角色，Proposer，Acceptor，和Learner[3-4]，一個(gè)節(jié)點(diǎn)可以兼有多重角色。Proposer提出提案，提案是一個(gè)有序?qū)?m，v>構(gòu)成，M是整數(shù)類型的提案編號(hào)，V是提案的值；Acceptor收到提案后可以接受提案，若提案獲得多數(shù)Acceptor的接受，則稱該提案被批準(zhǔn)；Learner只能學(xué)習(xí)被批準(zhǔn)的提案。Paxos算法的最終目標(biāo)便是只有一個(gè)提案被選定，即確保在一次算法實(shí)例中只產(chǎn)生一個(gè)value。

提案在批準(zhǔn)過程中需要滿足三個(gè)條件才能保證數(shù)據(jù)的一致性[1]：①提案只有被Proposer才可以批準(zhǔn)；②每次只能批準(zhǔn)一個(gè)提案；③只有提案被批準(zhǔn)后Learner才可以獲取這個(gè)決議。為了保證提案的惟一性，只有Acceptor沒有收到編號(hào)大于M的請(qǐng)求時(shí)，才可以批準(zhǔn)編號(hào)為M的提案。在這些約束的基礎(chǔ)上可以將提案的批準(zhǔn)過程分為三階段[7-8]：Prepare階段，Accept階段，Notify階段。

Prepare階段（初次提出提案，查看是否能夠被接受）：Proposer設(shè)定一個(gè)新的提案編號(hào)M，并將prepare請(qǐng)求發(fā)送給Acceptors中的多數(shù)派；Acceptor收到請(qǐng)求之后，如果提案編號(hào)大于它之前己批準(zhǔn)的任何提案編號(hào)，則Acceptor將自己上次批準(zhǔn)回復(fù)給Proposer，并承諾不再批準(zhǔn)小于M的提案；否則拒絕Proposer，Proposer收到拒絕后，會(huì)設(shè)定一個(gè)新的提案編號(hào)M+n，繼續(xù)向Acceptors中的多數(shù)派發(fā)送prepare請(qǐng)求。

Accept階段（再次確認(rèn)提案是否被所有的Acceptors接受）：當(dāng)Proposor收到了多數(shù)派Acceptors確認(rèn)回復(fù)之后，便進(jìn)入了Accept階段。它需要向所有回復(fù)prepare請(qǐng)求的Acceptors發(fā)送一個(gè)針對(duì)[M，V]的accept請(qǐng)求，V就是收到響應(yīng)中編號(hào)最大的M提案的值，若響應(yīng)中不包含任何值，那Proposor可以自由決定value。只要Acceptor沒有對(duì)編號(hào)大于M的提案響應(yīng)，Acceptor就可以最終批準(zhǔn)這個(gè)請(qǐng)求，如果在Prepare階段之后，Acceptor又對(duì)大于M的提案作了響應(yīng)，則Acceptor就可以拒絕這個(gè)請(qǐng)求。

Notify階段（學(xué)習(xí)過程）：當(dāng)Proposor收到多數(shù)派Acceptors的accept請(qǐng)求的確認(rèn)回復(fù)后（反之則回到Prepare階段重新提交新的提案），該提案被選定，就向所有的Learner發(fā)送通知，Learner接受通知更新Value。

2.2 算法優(yōu)化

Paxos是基于消息傳遞的算法，當(dāng)主機(jī)數(shù)量較多，Proposer角色和Acceptor角色較多時(shí)，在每個(gè)提案的批準(zhǔn)過程中，會(huì)出現(xiàn)過多的通信量，使得數(shù)據(jù)一致性代價(jià)過高，因此在實(shí)現(xiàn)中需要對(duì)Paxos算法進(jìn)行優(yōu)化。

Proposer數(shù)量過多時(shí)，當(dāng)Proposer提案被拒絕后，Proposer會(huì)不斷的提高編號(hào)繼續(xù)提交，因此會(huì)出現(xiàn)過多的通信量，為了杜絕這種不斷競爭的現(xiàn)象，可從所有的Proposer中競選出一個(gè)或少量幾個(gè)主Proposer，只允許主Proposer提出提案，杜絕惡性競爭，減少提案批準(zhǔn)過程中的通信量。但是也會(huì)出現(xiàn)單點(diǎn)故障問題，因此在系統(tǒng)運(yùn)行過程中如果發(fā)現(xiàn)主Proposer出現(xiàn)故障，所有的從Proposer就通過Paxos算法競選出一個(gè)新的主Proposer，接替原主Proposer的工作。

3 數(shù)據(jù)一致性方案的設(shè)計(jì)與實(shí)現(xiàn)

Paxos算法已經(jīng)有了一些實(shí)現(xiàn)方案，其中包括Google的分布式鎖服務(wù)chubby，Google的Spanner數(shù)據(jù)庫，開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)Cassandra等[6]，這些都是當(dāng)前比較優(yōu)秀的數(shù)據(jù)一致性產(chǎn)品。為了能夠在開源項(xiàng)目FibJs的開發(fā)過程中保證數(shù)據(jù)一致性，我們?cè)贔ibJs環(huán)境下根據(jù)Paxos算法思想對(duì)數(shù)據(jù)一致性進(jìn)行了設(shè)計(jì)與實(shí)現(xiàn)，并對(duì)該方法進(jìn)行了實(shí)驗(yàn)檢驗(yàn)。

3.1 一致性方案的設(shè)計(jì)

Paxos算法設(shè)計(jì)的角色是三個(gè)：Proposer，Acceptor，Learner。本方案在設(shè)計(jì)過程中，根據(jù)Paxos算法思想設(shè)計(jì)了如下三個(gè)角色：Looking，F(xiàn)ollower和Leader。要求集群機(jī)器數(shù)是奇數(shù)，最少三臺(tái)，并通過DNS服務(wù)器維護(hù)集群內(nèi)主機(jī)的IP和域名信息。

Looking角色：當(dāng)一個(gè)新的節(jié)點(diǎn)加入后，它的角色默認(rèn)為Looking，Looking會(huì)向所有的節(jié)點(diǎn)發(fā)送選舉消息來確認(rèn)Leader，可能是系統(tǒng)中已有的Leader，或者重新選舉出的Leader。當(dāng)發(fā)現(xiàn)Leader宕機(jī)后，其他節(jié)點(diǎn)也會(huì)轉(zhuǎn)變?yōu)長ooking并執(zhí)行重新Leader選舉。

Follower角色：當(dāng)選舉結(jié)束后，一個(gè)節(jié)點(diǎn)會(huì)變成Leader，其他節(jié)點(diǎn)發(fā)現(xiàn)Leader選舉出來后則會(huì)成為Follower。Follower角色可以當(dāng)做Paxos算法中的Acceptor和Learner，用來批準(zhǔn)Leader的提案和執(zhí)行Leader的決議。

Leader角色：選舉完成后，某個(gè)節(jié)點(diǎn)會(huì)轉(zhuǎn)變成Leader。它負(fù)責(zé)處理客戶端發(fā)送的所有請(qǐng)求。對(duì)于寫請(qǐng)求，Leader會(huì)采用一致性協(xié)議將請(qǐng)求廣播給所有Follower，得到過半的Follower批準(zhǔn)后再通知Follower執(zhí)行；對(duì)于讀請(qǐng)求，可由Leader直接執(zhí)行。它也管理著Follower節(jié)點(diǎn)，檢測節(jié)點(diǎn)是否正常通信，并提供告警功能。

集群中每個(gè)服務(wù)節(jié)點(diǎn)都是平等的，都可以被選舉為Leader和Follower角色，因而在架構(gòu)上也是相同的。每個(gè)節(jié)點(diǎn)都包含三個(gè)基本功能模塊。

⑴ 網(wǎng)絡(luò)通信模塊：主要用來實(shí)現(xiàn)節(jié)點(diǎn)之間的通信，并在通信的基礎(chǔ)上實(shí)現(xiàn)心跳連接（檢測節(jié)點(diǎn)間的連接狀態(tài)）。

⑵ Paxos算法模塊：主要用來實(shí)現(xiàn)角色轉(zhuǎn)換和Leader選舉，是系統(tǒng)中比較重要的模塊。

⑶ 數(shù)據(jù)管理模塊：用于執(zhí)行數(shù)據(jù)的讀/寫操作和節(jié)點(diǎn)間的數(shù)據(jù)同步，當(dāng)有新節(jié)點(diǎn)或者故障恢復(fù)后的節(jié)點(diǎn)時(shí)，通過數(shù)據(jù)同步來保證與其他節(jié)點(diǎn)的數(shù)據(jù)一致。

3.2 一致性方案的實(shí)現(xiàn)

3.2.1 網(wǎng)絡(luò)通信模塊

該模塊主要包括節(jié)點(diǎn)間的網(wǎng)絡(luò)通信和心跳連接兩個(gè)主要部分，其中節(jié)點(diǎn)通信主要采用RPC（Remote Procedure Call Protocol）框架實(shí)現(xiàn)，F(xiàn)ibJs中內(nèi)置有RPC框架的功能，直接使用即可。心跳連接主要用來檢測Follower與Leader之間的通信狀態(tài)，并告知Follower當(dāng)前的數(shù)據(jù)日志編號(hào)M，當(dāng)Follower發(fā)現(xiàn)和Leader不一致時(shí)通知數(shù)據(jù)管理模塊進(jìn)行數(shù)據(jù)同步。

具體算法流程：首先由Follower發(fā)起keepAlive請(qǐng)求，然后等待一段時(shí)間后接收響應(yīng)。當(dāng)Leader收到Follower的keepAlive請(qǐng)求時(shí)，會(huì)將Follower的sid寫入阻塞隊(duì)列，再阻塞一段時(shí)間后響應(yīng)給Follower，同時(shí)將該sid移除阻塞隊(duì)列，等待下次keepAlive請(qǐng)求再寫入。而Follower接收到響應(yīng)后會(huì)立刻再次發(fā)起keepAlive請(qǐng)求。這樣Leader上總會(huì)有keepAlive請(qǐng)求阻塞，Leader也從而得知它與Follower之間的通信是否正常。阻塞時(shí)間的設(shè)定可根據(jù)服務(wù)器的壓力進(jìn)行調(diào)節(jié)，以確保運(yùn)行高效。

當(dāng)某個(gè)Follower等待了兩倍于阻塞時(shí)間后仍未接收到Leader的響應(yīng)，則它會(huì)認(rèn)為Leader已不存在或已崩潰，然后它會(huì)轉(zhuǎn)變成Looking狀態(tài)，并開始發(fā)起選舉。同樣的，Leader也會(huì)定期檢查是否存在Follower節(jié)點(diǎn)通信異常（通過檢測阻塞隊(duì)列內(nèi)節(jié)點(diǎn)的個(gè)數(shù)），若大多數(shù)節(jié)點(diǎn)都無法與其通信，那么Leader會(huì)自己轉(zhuǎn)變成Looking狀態(tài)并開始選舉。

3.2.2 Paxos算法模塊

該模塊主要包括角色轉(zhuǎn)換和Leader選舉。Leader選舉借助Paxos算法思想，利于多數(shù)派的投票來確定，選舉模塊包括了選舉啟動(dòng)，消息傳輸，選舉算法實(shí)現(xiàn)這幾個(gè)步驟。

首先確定投票所用到相關(guān)參數(shù)。

sid：用來惟一標(biāo)識(shí)每個(gè)節(jié)點(diǎn)的整數(shù)值，值越大則權(quán)重越大。在這里表示為選舉的Leader，開始時(shí)Looking都會(huì)選舉自己為Leader。

clock：用來區(qū)分不同的選舉輪次，初值為0，每進(jìn)行一輪值加1。

leader：當(dāng)Leader和Follower接收到投票時(shí)會(huì)返回當(dāng)前系統(tǒng)中的leader。

voteSet：Looking接受到投票時(shí)，會(huì)返回voteSet，即自己的投票集合。

選舉算法的工作機(jī)制如下，算法中AB階段的流程圖見圖1。ACD階段流程圖見圖2。

[節(jié)點(diǎn)狀態(tài)][A][Looking] [B][sid，clock] [Looking] [比較clock] [比較sid][相等] [＼&忽略＼&＼&][小][＼&更新clock

清空投票

sid加入投票集合＼&＼&] [大][A] [＼&更新clock＼&＼&] [大][＼&sid加入投票集合＼&＼&][A] [接受返回值] [Voteset，clock] [Voteset，clock] [比較clock] [大][Follower] [Leader] [Voteset，clock][leader，clock]

圖1 AB階段流程圖

A：發(fā)送投票：當(dāng)節(jié)點(diǎn)狀態(tài)為Looking時(shí)，會(huì)向集群內(nèi)所有節(jié)點(diǎn)發(fā)送投票，投票中包含投票集合中最大的sid和clock，初次發(fā)送時(shí)會(huì)用自己的sid。

B：接受投票：不同狀態(tài)的節(jié)點(diǎn)接受到投票后處理方式不同。

B.1：Looking節(jié)點(diǎn)，會(huì)根據(jù)投票中clock的值進(jìn)行處理。

B.1.1：接收到的clock比自己當(dāng)前的clock大，更新clock，并清空自己的投票集合，將sid加入自己的投票集合，并返回voteSet和clock，然后從A開始繼續(xù)投票。

B.1.2：接收到的clock比自己當(dāng)前的小，則忽略該投票，并將voteSet和clock返回給對(duì)方。

B.1.3：接收到的clock與自己當(dāng)前的一致，若接收到的sid比自己大，則更新投票sid，并將該sid加入自己的投票集合，然后從A開始繼續(xù)投票；若接收到的sid比自己的小，并返回voteSet和clock。

[C] [比較clock] [包含參數(shù)] [相等][＼&更新clock＼&＼&] [大] [leader] [判斷sid][＼&忽略＼&＼&][D] [大][＼&更新投票＼&＼&] [voteSet] [包含參數(shù)] [leader] [voteSet][＼&更新投

票集合＼&＼&][A] [小] [voteSet，clock

leader，clock]

圖2 ACD階段流程圖

每個(gè)Looking都會(huì)維護(hù)一個(gè)投票集合，當(dāng)接收到投票時(shí)便要根據(jù)clock進(jìn)行更新，然后判斷集合中是否存在節(jié)點(diǎn)獲得的投票已經(jīng)過半，如果存在，等待一段時(shí)候后再觀察是否有變?cè)?，若有變化則繼續(xù)執(zhí)行選舉，若無變化則跳至D。

B.2：Follower節(jié)點(diǎn)或者Leader節(jié)點(diǎn)：會(huì)直接返回當(dāng)前的Leader和clock，并判斷clock是否比自己大，如果大就更新。

C：接受返回值：Looking節(jié)點(diǎn)會(huì)根據(jù)返回值的clock值進(jìn)行處理。

C.1：若clock比自己當(dāng)前的大，就更新自己的clock。若返回值中包含Leader參數(shù)，則跳至D；若包含voteSet參數(shù)，則更新投票集合，并從A開始繼續(xù)投票。

C.2：當(dāng)clock和自己當(dāng)前的相同時(shí)，若包含Leader參數(shù)，則跳至D；若包含voteSet參數(shù)，判斷sid，若大則更新投票，并從A開始繼續(xù)投票。

C.3：一般不會(huì)有clock比自己當(dāng)前的小，若出現(xiàn)則通常為網(wǎng)絡(luò)故障?？芍苯雍雎栽摲祷刂?。

D：確定Leader：Looking會(huì)根據(jù)Leader的sid是否是自己來轉(zhuǎn)變自己的角色，若為Follower，則與Leader進(jìn)行心跳連接，當(dāng)一段時(shí)間都未得到Leader的響應(yīng)，則放棄，并轉(zhuǎn)變?yōu)長ooking開始新一輪選舉；若為Leader，就等待Follower與自己連接，當(dāng)一段時(shí)間沒有過半Follower連接，則轉(zhuǎn)變?yōu)長ooking開始新一輪選舉。

3.2.3 數(shù)據(jù)管理模塊

數(shù)據(jù)同步模塊用來實(shí)現(xiàn)數(shù)據(jù)的讀寫操作，并保證節(jié)點(diǎn)之間的數(shù)據(jù)同步。在數(shù)據(jù)寫入過程中為了能夠記錄每一次的寫操作，并保證節(jié)點(diǎn)間的數(shù)據(jù)一致性，引入了編號(hào)M，每寫入一次數(shù)據(jù)則加1；為了保證Follower批準(zhǔn)的提案和執(zhí)行的提案是同一個(gè)提案，引入了惟一編號(hào)uuid，具體的算法工作機(jī)制如下。算法的流程圖見圖3。

[uuid是否相同][＼&將M+1和

寫操作寫

入日志＼&＼&][Follower][Leader][＼&同步數(shù)據(jù)

寫數(shù)據(jù)，寫日志

M+1＼&＼&] [M+1，uuid，寫操作][客戶端] [發(fā)送數(shù)據(jù)操作] [操作類型] [寫操作][＼&取最大編號(hào)M

生成uuid＼&＼&] [Follower][sid，M+1，uuid][＼&記錄uuid＼&＼&] [M+1>N

Leader==sid] [是] [Leader] [accept] [否

neject] [Accept

占多數(shù)] [是] [否] [讀操作]

圖3 數(shù)據(jù)讀寫流程圖

A：客戶端將數(shù)據(jù)操作請(qǐng)求發(fā)送給Leader節(jié)點(diǎn)。

B：Leader判斷請(qǐng)求類別，如果讀操作直接返回讀取結(jié)果；如果寫操作，取出當(dāng)前保存的最大編號(hào)M，生成一個(gè)uuid，并將編號(hào)M+1同Leader的sid一起發(fā)送給Follower，并保存最大編號(hào)為M+1。

C：Follower接收到Leader的寫請(qǐng)求時(shí)會(huì)先判斷編號(hào)M+1是否比本地保存的最大編號(hào)N大，并且它的Leader是否為sid，然后記錄uuid，并返回accept，否則返回reject。

D：當(dāng)Leader收到多數(shù)Follower的accept反饋后，就將編號(hào)M+1和寫操作內(nèi)容同uuid發(fā)送給所有Follower，并將操作寫入日志，然后反饋給客戶端寫入完成。若收到多數(shù)reject，則應(yīng)該是發(fā)生了Leader更換，先檢查與自己連接的Follower是否為大多數(shù)，若還是大多數(shù)，則跳至B進(jìn)行重試。

E：Follower接受到執(zhí)行請(qǐng)求時(shí)，判斷uuid是否相同，然后從Leader的日志中讀取編號(hào)N到編號(hào)M的寫操作，執(zhí)行并寫入本地日志，再執(zhí)行請(qǐng)求的寫操作并寫入日志，并更新N為M+1。

4 實(shí)驗(yàn)檢驗(yàn)

為了方便測試，我們組建了由三臺(tái)服務(wù)器構(gòu)成的集群，每臺(tái)服務(wù)器上使用FibJs作為服務(wù)運(yùn)行框架，并放置了兩個(gè)SQLite文件，分別用來存儲(chǔ)數(shù)據(jù)和日志。

服務(wù)啟動(dòng)后，首先進(jìn)行的是Leader選舉，選舉成功后開始檢測心跳，當(dāng)接受到客戶端的寫請(qǐng)求后進(jìn)行數(shù)據(jù)寫入，如果執(zhí)行成功則將對(duì)應(yīng)的數(shù)據(jù)操作腳本輸出。具體運(yùn)行結(jié)果見圖4。

圖4 Leader選舉與執(zhí)行數(shù)據(jù)寫操作

5 結(jié)束語

本文給出的方案能夠?qū)ibJs開發(fā)的服務(wù)部署到集群中，并對(duì)外提供持續(xù)的可用性，后期考慮對(duì)該方案繼續(xù)研究和優(yōu)化，以期將該方案設(shè)計(jì)成FibJs的一個(gè)組件，能夠集成到FibJs中，讓更多的人員參與該方案的優(yōu)化和使用。希望該方案可為其他系統(tǒng)的設(shè)計(jì)提供參考。

參考文獻(xiàn)（References）：

[1] 許子燦，吳榮泉.基于消息傳遞的Paxos算法研究[J].計(jì)算機(jī)

工程，2011.37（21）：287-290

[2] 高石玉，艾中良，劉忠麟.應(yīng)用Paxos算法構(gòu)建自組織網(wǎng)絡(luò)[J].

計(jì)算機(jī)工程與應(yīng)用，2014.6：88-91，204

[3] Lamport L. Paxos Made Simple[J].ACM SIGACT News，

2001.32（4）：18-25

[4] Jim G，Lamport L. Consensus on Transaction Commit[J].

ACM Transactions on Database Systems，2006.1：133-160

[5] 楊春明，杜炯.一種基于Paxos算法的高可用分布式鎖服務(wù)系

統(tǒng)[J].西南科技大學(xué)學(xué)報(bào)，2014.2：60-65

[6] 趙瑞芬.云存儲(chǔ)中基于PAXOS算法的數(shù)據(jù)一致性研究[J].科

技視界，2013.34：64，121

[7] 趙黎斌.面向云存儲(chǔ)的分布式文件系統(tǒng)關(guān)鍵技術(shù)研究[D].西

安電子科技大學(xué)，2011.

[8] 陳鴻欽.基于Paxos的Leader選舉與分布式日志復(fù)制系統(tǒng)[D].

東南大學(xué)，2012.

[9] 倪超.從Paxos到ZooKeeper分布式一致性原理與實(shí)踐[M].

電子工業(yè)出版社，2015.