文章目錄

• • RAFT出現(xiàn)的緣由
  • RAFT 的實(shí)現(xiàn)
  • • STATE MACHINE
    • Log Replicated State Machine
    • Leader Election
    • • 基本角色
      • 關(guān)鍵變量
      • 基本選舉過(guò)程
    • Log Replicated
    • • 基本概念
      • 基本操作
    • Safety
    • • Log Replication: Consistency check
      • Leader Election: Leader Completeness
    • 總結(jié)
  • RAFT 和 ZAB 的對(duì)比
  • 參考文獻(xiàn):

閱讀本篇之后，能夠回答如下幾個(gè)問(wèn)題：

• paxos和raft的區(qū)別，為什么要在paxos基礎(chǔ)上推出raft
• raft 如何保證分布式consensus 特性？
• Replicated Log State Machine 在raft中的作用。
• raft 相比于ZAB的區(qū)別。

本篇主要是幾篇共識(shí)算法相關(guān)論文的匯總，綜合做一個(gè)描述，希望能夠讓大家能夠?qū)沧R(shí)算法:pxos, raft,zab 能夠有一個(gè)全面的了解，方便在今后的使用中選擇適合自己業(yè)務(wù)的共識(shí)算法。

這一些問(wèn)題涉及的分布式共識(shí)算法細(xì)節(jié)會(huì)比較多，難免會(huì)有理解上的紕漏。如相關(guān)機(jī)制的描述有理解上的差異，歡迎留言一起討論。

RAFT出現(xiàn)的緣由

raft論文【3】是在2016年發(fā)出的，在此之前到1998年之間 大家備受paxos的“折磨”【4】。主要原因還是說(shuō)分布式發(fā)展太快，大數(shù)據(jù)的計(jì)算存儲(chǔ)對(duì)分布式的能力需要越來(lái)越緊迫，而一個(gè)易理解，易實(shí)現(xiàn)的分布式共識(shí)算法是分布式系統(tǒng)的基礎(chǔ)，能夠極快得解決自己業(yè)務(wù)問(wèn)題并領(lǐng)先同行（當(dāng)然，核心還是能夠?yàn)楣緞?chuàng)造更多的價(jià)值，節(jié)約資源成本）。

而PAXOS 則成為各大公司的阻礙，復(fù)雜的證明細(xì)節(jié)，簡(jiǎn)略的實(shí)現(xiàn)細(xì)節(jié)，讓研究者和開(kāi)發(fā)者望而卻步。

PAXOS原始論文【4】大家有興趣可以簡(jiǎn)單看看，從問(wèn)題描述到協(xié)議設(shè)計(jì)及相關(guān)一致性/正確性的完整證明，確實(shí)是嚴(yán)謹(jǐn)?shù)膶W(xué)術(shù)論文，但并不適用于教育（國(guó)外大學(xué)會(huì)有分布式課程MIT6.824等）和工業(yè)化。即使后續(xù)推出了一個(gè)原理性的簡(jiǎn)化版論文【5】，但又因?yàn)榧?xì)節(jié)過(guò)少，沒(méi)有辦法快速實(shí)現(xiàn)。只能作為分布式共識(shí)算法的鼻祖，供有興趣的人取之。

到此大家也都比較清楚了，PAXOS 難以理解 也 難以實(shí)現(xiàn)，實(shí)屬業(yè)界公有的分布式實(shí)現(xiàn)的痛點(diǎn)。
這里也基于一些大佬的總結(jié)，將PAXOS的簡(jiǎn)易原理描述做了一個(gè)總結(jié)，供大家參考，節(jié)約學(xué)習(xí)入門(mén)成本。

分布式共識(shí)算法:從PAXOS 到 Multi PAXOS

所以RAFT的出現(xiàn)就是為了解決PAXOS的兩個(gè)問(wèn)題，當(dāng)然最終的結(jié)果是解決了，才有現(xiàn)在的etcd,braft,tikv等

接下來(lái)深入了解一下RAFT如何將復(fù)雜問(wèn)題簡(jiǎn)單化。（當(dāng)然一些數(shù)據(jù)證明肯定是站在PAXOS的基礎(chǔ)上來(lái)描述的，才能夠在raft中簡(jiǎn)單帶過(guò)。）

RAFT 的實(shí)現(xiàn)

RAFT 認(rèn)為自己相比于PAXOS 易于理解的原因除了簡(jiǎn)化了共識(shí)過(guò)程中的角色，更主要的是將復(fù)雜問(wèn)題進(jìn)行分治。

即 RAFT共識(shí)算法的實(shí)現(xiàn)總結(jié)為如下幾個(gè)子問(wèn)題：

• Leader Election
• Log Replicated
• Safety
• Membership Management
• Log Compaction

其中主要的過(guò)程是前面三個(gè)階段，完成了leader的選舉和日志的同步，并且這兩個(gè)過(guò)程通過(guò)safety保證了前面兩步的一致性和可靠性。

在詳細(xì)描述選舉過(guò)程之前需要對(duì)狀態(tài)機(jī)(state machine) 以及 日志復(fù)制狀態(tài)機(jī)(log replicated state machine)的原理做一個(gè)講解，方便后續(xù)對(duì)RAFT的Log Replicated過(guò)程的理解。

STATE MACHINE

如上圖，狀態(tài)機(jī) 是一些內(nèi)部數(shù)據(jù)/指令執(zhí)行的狀態(tài)遷移過(guò)程，通過(guò)狀態(tài)機(jī)能夠和外部客戶端進(jìn)行通信。
狀態(tài)機(jī)的主要作用是：

• 管理集群內(nèi)部狀態(tài)
• 和客戶端進(jìn)行交互

使用狀態(tài)機(jī)的分布式系統(tǒng)，分布式存儲(chǔ)，分布式服務(wù) 很多，包括HDFS的name node, ceph的blustore, MemCached等

基于狀態(tài)機(jī)實(shí)現(xiàn)的日志復(fù)制狀態(tài)機(jī)(Log Replicated State Machine)則是分布式共識(shí)算法 一致性實(shí)現(xiàn)的基礎(chǔ)。

Log Replicated State Machine

日志復(fù)制狀態(tài)機(jī)的基本構(gòu)造如下：

每一個(gè)日志復(fù)制狀態(tài)機(jī) 存在于一個(gè)節(jié)點(diǎn)或者一個(gè)集群的角色服務(wù)上(follower/leader)，內(nèi)部主要有三個(gè)模塊：

• Consensus Module 共識(shí)模塊。主要作用有兩個(gè)：完成來(lái)自客戶端請(qǐng)求的解析，將客戶端請(qǐng)求解析為能夠被狀態(tài)機(jī)識(shí)別的 log entry;和其他server的共識(shí)模塊進(jìn)行rpc通信，轉(zhuǎn)發(fā)客戶端的請(qǐng)求。
• log 日志列表。用來(lái)存放共識(shí)模塊解析出來(lái)的log entry，追加寫(xiě)。
• state machine 狀態(tài)機(jī)。用來(lái)執(zhí)行日志列表中的日志條目，一般是command的形態(tài)。

一個(gè)共識(shí)集群中每一個(gè)參與集群選舉、一致性保障的角色服務(wù)進(jìn)程中都會(huì)維護(hù)一個(gè)這樣的日志復(fù)制狀態(tài)機(jī)。
如上示意圖代表整個(gè)狀態(tài)機(jī) 集群 從接受到客戶端請(qǐng)求到完成日志復(fù)制最終回復(fù)客戶端的 過(guò)程。

模擬這個(gè)復(fù)制狀態(tài)機(jī)集群 處理客戶端請(qǐng)求的過(guò)程 可以分為五步：

1. 客戶端將請(qǐng)求 x<–z 發(fā)送個(gè)leader上的共識(shí)模塊
2. leader的共識(shí)模塊將客戶端請(qǐng)求轉(zhuǎn)發(fā)給follower上的共識(shí)模塊，并保證收到大多數(shù)（quroum，大于等于n/2 + 1，n表示集群節(jié)點(diǎn)個(gè)數(shù)）的回應(yīng)
3. 每個(gè)server的復(fù)制狀態(tài)機(jī)將各自共識(shí)模塊介些的log entry追加到自己本地的log列表中
4. 每個(gè)server的復(fù)制狀態(tài)機(jī)并行提交log entry中的日志條目到狀態(tài)機(jī)中 執(zhí)行日志中的指令，比如將x設(shè)置為z。這一步可以看作是commit階段，需要持久化。
5. 完成了commit 之后，leader向客戶大返回成功。

當(dāng)然這個(gè)復(fù)制狀態(tài)機(jī)并不能代表完整的raft的日志復(fù)制的過(guò)程，一些日志復(fù)制的細(xì)節(jié)上會(huì)有差異，但是整個(gè)日志復(fù)制到完成提交的過(guò)程是 raft Log Replicated的基礎(chǔ)。

接下來(lái)我們?cè)敿?xì)探討一下整個(gè)raft各個(gè)階段的基本實(shí)現(xiàn)過(guò)程，揣摩將共識(shí)問(wèn)題分解為一個(gè)個(gè)子問(wèn)題一一實(shí)現(xiàn)的好處。

PS： raft論文中會(huì)完整得描述從選舉到日志合并和成員變更的過(guò)程，但日志合并和成員變更本身會(huì)有非常多的細(xì)節(jié)，全部放在本篇?jiǎng)t會(huì)過(guò)于冗余。本篇的定位是raft的基本原理，也就是會(huì)描述Leader Election , Log Replicated 以及 以上兩個(gè)階段的穩(wěn)定性Safety保證。

Leader Election

介紹日志選舉前需要對(duì)整個(gè)raft中的角色以及其作用做一個(gè)統(tǒng)一的介紹。

基本角色

這里的角色在實(shí)際raft相關(guān)的應(yīng)用中是以服務(wù)進(jìn)程的形式存在的。

• follower ，所有角色開(kāi)始時(shí)的狀態(tài)，等待接受leader心跳RPCs，如果收不到則會(huì)變成Candidate
• Candidate，候選人。是變成Leader的上一個(gè)角色，候選人會(huì)向其他所有節(jié)點(diǎn)發(fā)送RequestVote RPCs，如果收到集群大多數(shù)的回復(fù)，則會(huì)將自己角色變更為L(zhǎng)eader，并發(fā)送AppendEntries RPCs。
• Leader ，集群的皇帝/主人…，raft能夠保證每一個(gè)集群僅有一個(gè)leader。負(fù)責(zé)和客戶端進(jìn)行通信，并將客戶端請(qǐng)求轉(zhuǎn)發(fā)給集群其他成員。

關(guān)鍵變量

• Election Timeout 選舉超時(shí)時(shí)間。即Cadidate 向集群其他節(jié)點(diǎn)發(fā)送vote請(qǐng)求時(shí)，如果在Election Timeout時(shí)間內(nèi)沒(méi)有收到大多數(shù)的回復(fù)，則會(huì)重新發(fā)送vote rpc。

  以上將實(shí)際RequestVote簡(jiǎn)寫(xiě)為vote ,就是請(qǐng)求投票的rpc

  一般這個(gè)超時(shí)時(shí)間是在150-300ms的隨機(jī)時(shí)間，為了防止集群出現(xiàn)頻繁的 split vote 影響leader選舉效率的情況，將這個(gè)超時(shí)時(shí)間取在155-300ms范圍內(nèi)的隨機(jī)時(shí)間。當(dāng)然，這個(gè)數(shù)值也是經(jīng)過(guò)測(cè)試的，超時(shí)時(shí)間設(shè)置在150-300ms 之間能夠保證raft集群 leader的穩(wěn)定性，也可以將超時(shí)時(shí)間設(shè)置的比較低（12-24ms），但是存在的網(wǎng)絡(luò)延遲則會(huì)導(dǎo)致一些不必要的leader選舉。

  關(guān)于splite vote的情況可以看如下圖，圖片來(lái)自raft可視化官網(wǎng)【6】：
  
  兩個(gè)節(jié)點(diǎn)收到對(duì)方的vote請(qǐng)求之前變成了candidate，發(fā)送了各自的request vote。

• Heartbeats Timeout 心跳超時(shí)時(shí)間。follower接受來(lái)自leader的心跳，如果在heartbeats timeout這個(gè)時(shí)間段內(nèi)follower沒(méi)有收到來(lái)自leader的AppendEntries RPCs，則follower會(huì)重新觸發(fā)選舉。收到了，則重置follower 本地的 heartbeats timeout。

• RequestVote RPCs 以上兩個(gè)超時(shí)過(guò)程也說(shuō)了，投票是的rpc請(qǐng)求

• AppendEntries RPCs leader 同步數(shù)據(jù)時(shí)的rpc請(qǐng)求。

基本選舉過(guò)程

在之前的描述過(guò)程中基本選舉已有有一些描述了，這里通過(guò)角色變化圖展示一下。

主要是三個(gè)角色的變化完成leader選舉。

• follower 沒(méi)有收到heartbead 變成Candidate
• Candiate 投票給自己，并發(fā)送投票請(qǐng)求給其他server ，收到大多數(shù)的相應(yīng)則變成leader，否則等待超時(shí)再次變成Candidate 發(fā)送投票 或 接受其他的投票。
• Leader 發(fā)送AppendEntries 復(fù)制日志到其他follower；維護(hù)心跳來(lái)保證自己被其他follower可見(jiàn)。心跳超時(shí)或發(fā)現(xiàn)更高的Term 就變成follower。

Leader選舉過(guò)程中除了之前提到的基本變量，還會(huì)有一個(gè)Term 的概念。

這是raft論文中的一幅Term概念描述的圖。簡(jiǎn)單來(lái)說(shuō)Term 可以用一個(gè)數(shù)字來(lái)表示，主要提現(xiàn)的是raft集群Leader的存活周期。即當(dāng)前Term為1，維持了一段時(shí)間，這段時(shí)間集群的leader沒(méi)有發(fā)生變化。而當(dāng)Term變成2，表示一定發(fā)生了Leader的變更(leader所在服務(wù)器跪了)，但不一定表示Leader一定被選舉出來(lái)了。

上圖中的 term3 則完全沒(méi)有選出leader，這種情況的出現(xiàn)就是上文中描述的splite vote的情況，這個(gè)時(shí)候Term也會(huì)增加，當(dāng)時(shí)并沒(méi)有l(wèi)eader 被選出來(lái)，在ceph/zookeeper中 其實(shí)就類(lèi)比于Epoch。

關(guān)于Term在candidate 投票過(guò)程中發(fā)生的變化 如下圖。

到此整個(gè)raft 選主過(guò)程就描述完了，一些一致性保證的問(wèn)題會(huì)在日志復(fù)制 講完之后進(jìn)一步整體描述。

Log Replicated

日志復(fù)制的過(guò)程就會(huì)用到我們前面講到的Log Replicated State Machine，raft 是基于這個(gè)機(jī)制來(lái)實(shí)現(xiàn)日志復(fù)制的基本過(guò)程。

講述日志復(fù)制的過(guò)程之前 還對(duì)日志復(fù)制的基本概念做一個(gè)描述

基本概念

除了日志復(fù)制狀態(tài)機(jī)已經(jīng)完整介紹過(guò)了，這里主要介紹一下raft中的log entry 列表。

如上圖，其中每一個(gè)角色都有自己的log entry列表，列表中的每一個(gè)方格代表一條entry。
方格中有一個(gè)數(shù)字1、2、3，一條entry x<–3、y<–1，數(shù)字代表的是Term，entry是能被狀態(tài)機(jī)執(zhí)行的commnad。
最上面有一排數(shù)字:1、2、3… 表示entry索引，是entry的全局唯一標(biāo)識(shí)。

從這個(gè)日志列表中，我們能夠看到通過(guò)index + term 能夠唯一標(biāo)識(shí)一條entry，且整個(gè)集群正常工作的成員的entry和index需要保持一致，上圖中存在部分節(jié)點(diǎn)出現(xiàn)過(guò)異常導(dǎo)致現(xiàn)在的entry出現(xiàn)不一致的情況，這個(gè)時(shí)候leader會(huì)負(fù)責(zé)完成Log Replicated 來(lái)將follower的entry補(bǔ)全。

基本操作

leader 完成Log Replicated 的過(guò)程是通過(guò)如下幾步完成的：

1. 客戶端發(fā)送請(qǐng)求到leader
2. leader 將客戶端的請(qǐng)求轉(zhuǎn)化成entry 追加到log列表中
3. leader 通過(guò) AppendEntries RPCs 將log entry 發(fā)送到其他follower
4. 新的log entry被committed 需要經(jīng)過(guò)如下幾步：
   • leader 首先在自己本地的狀態(tài)機(jī)執(zhí)行l(wèi)og entry中的command（落盤(pán)持久化），并向客戶端返回成功
   • leader 喚醒follower節(jié)點(diǎn)各自本地按順序提交log entry
   • follower節(jié)點(diǎn)將log entry添加到狀態(tài)機(jī)中完成持久化操作
5. 如果發(fā)生follower異常/宕機(jī)，會(huì)持續(xù)嘗試發(fā)送AppendEntries RPCs

從上面的基本操作我們能夠發(fā)現(xiàn)當(dāng)前Term 下的 Leader 一定是擁有最全的且已經(jīng)完成了持久化的log entry，整個(gè)過(guò)程是通過(guò)日志復(fù)制狀態(tài)機(jī)來(lái)完成的。

接下來(lái)會(huì)討論一些異常情況，即follower的日志相比于leader的日志存在缺失的情況，Leader該如何處理？還有如何保證選舉出來(lái)的leader擁有最全的日志信息？

Safety

先回答第一個(gè)問(wèn)題，leader和follower 日志不一致的情況，leader會(huì)怎么處理。

Log Replication: Consistency check

進(jìn)入正題之前 關(guān)注如下幾個(gè)需要注意的前提

• AppendEntries RPCs 內(nèi)容 包括<index, Term>， 分別是log entry在日志列表中的位置index 和 它所處leader 的Term號(hào)。
• follower 收到leader發(fā)送的entry， 必須在<index,Term>和內(nèi)容匹配，匹配則接受并應(yīng)用在自己本地的復(fù)制狀態(tài)機(jī)中；如果不匹配，follower會(huì)拒絕接受當(dāng)前的Log Entry，返回reject
  此時(shí)Leader 會(huì)調(diào)整<index,Term>信息，即發(fā)送本地列表中已經(jīng)提交的上一個(gè)log enry 給follower
• 通過(guò)induction step 不斷的回退嘗試 方式來(lái)完成 Leader和follower 的日志匹配屬性。

Example1:

follower 日志落后于leader的日志，y<–1 這一條日志相比于Leader缺失。這種情況的出現(xiàn)是由于follower 在Term 3可能宕機(jī)，可能網(wǎng)絡(luò)延遲，總之沒(méi)有收到leader 的rpc，重新啟動(dòng)之后需要和leader坐日志同步。

按照如上幾條前提:

1. Leader 發(fā)送<4,3> 的log AppendEntries給follower,follower發(fā)現(xiàn)本地最新的是<3,2>，則拒絕leader 的log entry。
2. Leader induction step,調(diào)整發(fā)送<3,2> 給follower, follower發(fā)現(xiàn)匹配，也就是<3,2>以前的log entry都完成了匹配，那follower就可以接受最新的leader的log entry了。
3. 接下來(lái)的AppendEntries PRCs leader就可以攜帶最新的log entry 給follower。

最終完成集群log entry的完全匹配。

Example 2:

這個(gè)情況是follower的日志多余l(xiāng)eader的日志，這種的情況是出現(xiàn)在網(wǎng)絡(luò)分區(qū)的情況。兩個(gè)分區(qū)分別發(fā)送自己的rpc,一個(gè)分區(qū)中存在舊的leader,并未發(fā)生Term的變更；而另一個(gè)分區(qū)會(huì)重新選舉leader ,維護(hù)更高版本的Term。到現(xiàn)在分區(qū)重新恢復(fù)，就出現(xiàn)了Leader和follower之間的數(shù)據(jù) Term相差較多。

還是按照日志一致性前提，通過(guò)induction step不斷回退日志版本，leader發(fā)送的日志回退到<3,2>還是沒(méi)有發(fā)現(xiàn)和follower的日志達(dá)成匹配，所以會(huì)繼續(xù)回退，發(fā)送<2,1>的entry信息。

就是如上這種情況，最終發(fā)現(xiàn)<2,1>能夠匹配，則會(huì)將<2,1>之后的leader entry發(fā)送給follower,從而覆蓋掉follower的低term log。

這里會(huì)衍生出來(lái)的一些問(wèn)題：
按照之前描述的leader election過(guò)程，可能會(huì)選出一個(gè)leader 的log entry比f(wàn)ollower 最新的log entry版本低，那導(dǎo)致的情況就是這個(gè)新的leader 會(huì)把follower數(shù)據(jù)覆蓋掉，這種情況可能嗎？

接下來(lái)需要深入探討一下Leader Election的限制了。

Leader Election: Leader Completeness

細(xì)節(jié)描述：

• 一旦一個(gè)log entry 在當(dāng)前集群完成提交，未來(lái)選舉的所有l(wèi)eader都需要包含這條entry
• 日志不全的server 無(wú)法被成功選舉
  • 選舉過(guò)程中的 candidate 發(fā)送的 RequestVote RPCs 需要包含 本地最新的index和term
  • 接受投票的server 發(fā)現(xiàn)收到的index和term 比自己本地還舊，會(huì)拒絕選舉
  • log entry是按照<lastTerm, lastIndex> 進(jìn)行比較的，先比較lastTerm的大小，如果相等則比較lastIndex

如上圖，幾個(gè)不同的server有自己的log entry列表。

• 如果S4 的RequestVote RPCs 先到達(dá)其他server ，按照<lastTerm, lastIndex>比較規(guī)則，它會(huì)收到S1,S2,S5的選票并當(dāng)選為leader，同時(shí)后續(xù)也會(huì)將S3中的9,10 日志覆蓋掉。
• 如果S2的RequestVote RPCs 先到達(dá)其他server，顯然，它無(wú)法贏得選舉；沒(méi)有選票返回，直到超時(shí)，會(huì)進(jìn)入下一輪重新選舉。
• 當(dāng)然 S3現(xiàn)發(fā)起的 vote 肯定能夠當(dāng)選。

這樣，選舉出來(lái)的Leader能夠擁有集群大多數(shù)的log entry，而對(duì)于S3 server這樣的情況顯然9和10 index log entry已經(jīng)可以被丟棄，當(dāng)時(shí)的leader也僅僅在自己本地提交，其他follower一個(gè)也沒(méi)有收到提交的entry（集群內(nèi)部網(wǎng)絡(luò)嚴(yán)重問(wèn)題）。

總結(jié)

到此整個(gè)raft的基本過(guò)程就講完了，除了后續(xù)的成員變更和日志合并之外。整個(gè)raft實(shí)現(xiàn)的共識(shí)算法 基本過(guò)程也就兩個(gè)階段：Leader Election, Log Replicated。

在這兩個(gè)階段基礎(chǔ)上通過(guò)兩種一致性 完成了異常情況下的集群數(shù)據(jù)一致性保障。

• Leader Election的一致性通過(guò)<lastTerm, lastIndex> 比較完成，最新的leader擁有大多數(shù)成員認(rèn)可的最全的日志；
• Log Replicated 一致性通過(guò) induction step， 還是比較日志的term和index，舊了leader就發(fā)送更舊的，直到完全和follower匹配，再補(bǔ)充新的日志。

raft的易理解特性 從論文給的數(shù)據(jù)能夠很明顯得看出來(lái)，讓一部分學(xué)生分別學(xué)習(xí)raft和paxos 并完成相關(guān)的實(shí)驗(yàn)。

可以發(fā)現(xiàn)學(xué)生的反饋中 raft更易理解，更易實(shí)現(xiàn)，對(duì)應(yīng)的測(cè)試分?jǐn)?shù)也比paxos更高。

RAFT 和 ZAB 的對(duì)比

關(guān)于ZAB協(xié)議的基本過(guò)程可以參考:
zookeeper ZAB協(xié)議原理淺析

相比于RAFT 從內(nèi)部描述上的不同主要如下：

• ZAB 的 entry（history entry） 的數(shù)據(jù)同步方向是從follower向leader發(fā)送；raft則是leader負(fù)責(zé)向follower同步log entry
• ZAB 中一個(gè)leader周期是epoch; raft則是 term

從基本選舉和日志同步的流程上來(lái)看：
ZAB 需要經(jīng)過(guò)的rpc更多，整個(gè)leader election + discovery + synchonization 的RPC次數(shù)超過(guò)RAFT 幾倍；伴隨著復(fù)雜度也是幾倍。

從提供的服務(wù)來(lái)看：
zookeeper能夠保證強(qiáng)一致性，選舉出來(lái)的leader一定擁有最全最新的日志，不是raft 中l(wèi)eader 比大多數(shù)新就可以。
zookeeper 能夠提供分布式鎖，分布式隊(duì)列，分布式配置管理 這樣的協(xié)調(diào)服務(wù)，處于應(yīng)用之外。

raft能夠集成到應(yīng)用內(nèi)部，完成一個(gè)分布式存儲(chǔ)（tikv），分布式kv（etcd）, 分布式數(shù)據(jù)庫(kù)（各個(gè)大廠自研）等更加完備的分布式系統(tǒng)，已有的業(yè)界raft實(shí)現(xiàn)都能夠在raft論文基礎(chǔ)上快速完成自己想要的分布式系統(tǒng)的開(kāi)發(fā)。

完整的raft,paxos,zab對(duì)比如下：

參考文獻(xiàn):

1. Zookeeper: https://pdos.csail.mit.edu/6.824/papers/zookeeper.pdf

2. ZAB: http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf

3. RAFT: https://raft.github.io/raft.pdf

4.PAXOS: https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf

5.PAXOS SIMPLE https://lamport.azurewebsites.net/pubs/paxos-simple.pdf

6.raft website

總結(jié)

以上是生活随笔為你收集整理的从paxos到raft zab，为何raft能够“独领风骚”的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。