復(fù)制狀態(tài)機作為分布式系統(tǒng)的主要容錯手段,典型地使用復(fù)制日志來實現(xiàn)。該方法維持一組服務(wù)器上的多個復(fù)制日志彼此相同,同時要求每個狀態(tài)機按照順序執(zhí)行日志中的命令,由此保證每臺服務(wù)器產(chǎn)出相同的狀態(tài),從而可以容忍少數(shù)服務(wù)器故障。復(fù)制狀態(tài)機方法需要使用分布式共識協(xié)議保證多個復(fù)制日志能夠就下一個日志條目達(dá)成共識,同時需要在故障和消息延遲情況下保證多個狀態(tài)機對外的數(shù)據(jù)一致。共識協(xié)議作為復(fù)制狀態(tài)機的核心組件,需要被簡潔高效地實現(xiàn)。但諸如Paxos、ViewStamped Replication、Zab這些主流的共識協(xié)議,算法本身難以理解,工程實現(xiàn)上也需要進(jìn)行額外擴(kuò)展或性能優(yōu)化,不便于構(gòu)建實際系統(tǒng)。此外,基于復(fù)制狀態(tài)機構(gòu)建滿足給定一致性模型的分布式服務(wù),需要根據(jù)服務(wù)特性和應(yīng)用場景進(jìn)行特定設(shè)計,沒有通用的解決方案。基于以上問題,本文的研究內(nèi)容如下:（1）本文分析對比主流的共識協(xié)議,基于可理解性和易于工程實現(xiàn)的需求,選擇Raft協(xié)議作為核心算法。但現(xiàn)有Raft協(xié)議實現(xiàn),大多數(shù)為實驗性質(zhì),在完整性上有所欠缺或在正確性上缺乏驗證,少數(shù)可行實現(xiàn)都是作為大型服務(wù)的一部分,沒有封裝成一個通用的基礎(chǔ)庫形式。因此本文從零開... 

【文章來源】：西安電子科技大學(xué)陜西省 211工程院校 教育部直屬院校

【文章頁數(shù)】：99 頁

【學(xué)位級別】：碩士

【部分圖文】：

圖２．１?Ｒａｆｔ狀態(tài)轉(zhuǎn)移圖??

圖２．２?Ｒａｆｔ任期??

正常運行期間，一致性檢查總是從新條目的上一個索引位置進(jìn)行的，所以領(lǐng)導(dǎo)者??和跟隨者日志總是一致的。但是，當(dāng)發(fā)生領(lǐng)導(dǎo)者崩潰或者網(wǎng)絡(luò)分區(qū)時，跟隨者的日志??就會和領(lǐng)導(dǎo)者存在沖突。圖２．４給出了跟隨者日志不同于領(lǐng)導(dǎo)者的幾種形式。每個日??志條目中只給出了任期號，省去了客戶端命令。跟隨者可能缺失日志條目（圖２．４中??的（ａ－ｂ）），也可能擁有額外的不在領(lǐng)導(dǎo)者日志中的條目（圖２．４中的（ｃ－ｄ）），或者兩??者都有（圖２．４中的（ｅ－ｆ））。??】２?３?４?５?６?７?８?９?１０?１１?１２?索引??ＴＴＴＴＴ＇ｐｒｎｉＴＴＴＴＴＴＴＴＴＩ?任期為ｓ?的??￣￣￣￣￣￣￣￣￣?領(lǐng)導(dǎo)者??（ａ）?１?Ｉ?１?４?４?５?５?６?６??（ｂ）?１１１４??（ｃ）?｜?１?１?１?｜?１?１?４?｜?４?１?５?１?５?｜?６?１?６?１?６?［７］?可能的??￣￣￣￣￣￣￣￣ｒ?－ｒ?■■?￣￣ｒ￣＿！?跟隨者??（ｄ）?１?１?１?｜４［４｜５｜５｜６｜６［６｜７｜７??（ｅ）?１?Ｉ?１４?４?４?４??（〇?Ｉ?１?Ｉ?２２２３３?３?３３??圖２．４日志不一致的可能情況??１６??


本文編號：3360560