什么是一致性協(xié)議？

注意，今天是大白話隨便聊聊，目的是直白的了解 raft 是什么，不用太摳理論定義。

什么是一致性協(xié)議？

字面理解就是讓某些東西保持一致的協(xié)議嘛。

什么是一致？

大白話就是內(nèi)容完全相同唄。以存儲(chǔ)場(chǎng)景舉例，假設(shè)有三個(gè)磁盤文件，大小為 1M ，如果三個(gè)文件 1M 的數(shù)據(jù)都完全相同，那么這可以說(shuō)這文件的數(shù)據(jù)是一致的。

一致性還分了不同的等級(jí)，如線性、因果、最終一致性等等，而且如果站在不同的系統(tǒng)層面來(lái)看，承諾的一致性也會(huì)有所不同。這些今天都不重要，重要的是我們知道了：一致性協(xié)議就是用來(lái)達(dá)到一致的協(xié)議唄。

有兩個(gè)最出名的一致性協(xié)議：paxos 和 raft 。數(shù)學(xué)上已經(jīng)嚴(yán)格證明了 paxos 的正確性，只要嚴(yán)格遵守它協(xié)議的約束，就能保證在分布式的惡劣環(huán)境下多副本數(shù)據(jù)的一致。我們來(lái)看一下吧！

paxos 協(xié)議

paxos 是 Leslie Lamport 大神于 1990 年提出的一致性協(xié)議。它解決的問題是一個(gè)分布式系統(tǒng)如何就某個(gè)值（決議）達(dá)成一致。

劃重點(diǎn)：paxos 協(xié)議本質(zhì)是確定一個(gè)值。

論文《The part-time parliarment》提到的 paxos 里面有兩個(gè)重要角色：

• Proposer：提議發(fā)起者
• Acceptor：提議接受者

它們的操作對(duì)象就是：提議（ Proposal ） = 提議的值 提議編號(hào)。里面有三大"定律"，滿足這三大約束條件，那么就能保證一致性：

第一定律：每輪的投票編號(hào)唯一；

第二定律：投票滿足多數(shù)才算成功（并且如果任意兩次投票都存在多數(shù)派，則多數(shù)派的交集不為空）；

第三定律：如果一輪編號(hào)為 Bbal 的投票，多數(shù)派中任意一位成員曾投過(guò) Bbal 編號(hào)小的票（B'），那么 Bdec == B'dec；

上面就是 paxos 最核心的內(nèi)容，但是說(shuō)實(shí)話，每一個(gè)字都看得懂，但是連起來(lái)就不知道啥意思？

paxos 到底能做啥？這個(gè)我們存儲(chǔ)系統(tǒng)有啥關(guān)系？它為啥那么難懂？

paxos 難就難在于它沒告訴大家，這個(gè)東西能用來(lái)做啥，映射不到現(xiàn)實(shí)，就無(wú)法產(chǎn)生共鳴。

我們先接受一個(gè)事實(shí)：paxos 的本質(zhì)是確定一個(gè)值，且一旦這個(gè)值確定之后，后續(xù)無(wú)論怎么投票，無(wú)論發(fā)生什么，這個(gè)值保持不變。

那我就比以前更懵逼了！怎么越說(shuō)越糊涂了了，說(shuō)好的做一個(gè)分布式存儲(chǔ)服務(wù)嗎？存儲(chǔ)服務(wù)應(yīng)該允許可以寫入任何數(shù)據(jù)，且可以 Update 的嘛。

確定一個(gè)不能變的值有啥用？

paxos 的工程化

我們下面嘗試將 paxos 工程化，將它具現(xiàn)化到現(xiàn)實(shí)的工程實(shí)現(xiàn)。

1 確定一個(gè)值，有啥用？

回到最開始的問題，確定一個(gè)值對(duì)我們有啥用？

我們來(lái)簡(jiǎn)要發(fā)散下 paxos 工程化的思路。

paxos 本質(zhì)：確定一個(gè)值，現(xiàn)在把這里面參與的角色打包起來(lái)，Proposer，Acceptor，Proposal 等等組成的抽象的集合：paxos instance，稱為 paxos 實(shí)例：

劃重點(diǎn)：每個(gè)實(shí)例必須是完全獨(dú)立，投票互不干涉，即可。

一個(gè) instance 確定一個(gè)值，多個(gè) instance 確定多個(gè)值。

這些值不斷的被確定（永不更改），形成了一個(gè)值序列，這有啥用？

2 確定多個(gè)值有啥用？

接著上面，我們現(xiàn)在有了一系列永遠(yuǎn)無(wú)法被修改了值序列，有啥用？存儲(chǔ)服務(wù)的基本特點(diǎn)是允許存儲(chǔ)任何數(shù)據(jù)，并且能夠增刪改。

哪還有啥用？

這一個(gè)個(gè)值序列像不像一個(gè)東西：日志！

這個(gè)跟 rocksdbdb，leveldb 的 wal 日志是不是差不多意思了？

我們應(yīng)用這些日志就能得到一致性的輸出。所以我們還缺個(gè)啥？

狀態(tài)機(jī)嘛。

3 加個(gè)狀態(tài)機(jī)就起飛了

什么是狀態(tài)機(jī)？

狀態(tài)機(jī)全稱為有限狀態(tài)機(jī)。它接收條件的觸發(fā)，由一種狀態(tài)轉(zhuǎn)變?yōu)樾碌臓顟B(tài)。初始狀態(tài)相同，輸入的一系列事件相同，那么它最終的狀態(tài)一定相同。

這可太常見了，比如 rocksdb，leveldb 等等 lsm 存儲(chǔ)，它們數(shù)據(jù)先寫 append log ，通過(guò)重放日志到達(dá)的系統(tǒng)狀態(tài)一定是一致的。

這種狀態(tài)機(jī)的應(yīng)用模式可不僅限于存儲(chǔ)服務(wù)。

到這，我相信童鞋們已經(jīng)很豁然開朗了，只要我們通過(guò) paxos  來(lái)產(chǎn)生分布式一致的有序的操作日志，加上狀態(tài)機(jī)的配合，實(shí)現(xiàn)一個(gè)分布式存儲(chǔ)服務(wù)必然不是問題。

通過(guò)不停的確定一個(gè)個(gè)值，形成一個(gè)有序的操作系列，配合狀態(tài)機(jī)的應(yīng)用，這，就是 paxos 的工程化方向。

4 活鎖的問題怎么解決？

對(duì)于 paxos 來(lái)說(shuō)，Proposer 和 Acceptor 角色是可以重疊的，每個(gè)節(jié)點(diǎn)既可以是 Proposer，也可以是 Acceptor ，或者兩者都是。

這帶來(lái)了非常大的靈活，每一個(gè) Proposer 都可以遞交協(xié)議（寫入數(shù)據(jù)），但由于最終只能確定一個(gè)值，那么這會(huì)導(dǎo)致非常多的無(wú)效功，這期間是使用類似樂觀鎖來(lái)解決那些沖突的提議。

比如說(shuō)，A 剛遞交一個(gè)提案，B 就遞交一個(gè)新提案導(dǎo)致 A 的提案被否定了，然后 A 又迅速遞交一個(gè)提案，形成了一種類似活鎖的狀態(tài)，這時(shí)間就浪費(fèi)了呀。

怎么解決？

問題根因在于可以提案的點(diǎn)太多，大家都是平等的。那么統(tǒng)一聲音才能解決這個(gè)問題。于是Leader 就應(yīng)運(yùn)而生。通過(guò)某種方法指定一個(gè)節(jié)點(diǎn)為 Leader ，只有一個(gè)節(jié)點(diǎn)能遞交提案，這樣就解決了混亂問題，效率提隨之提升（這就是 Multi-Paxos ）。

5 paxos 工程化小結(jié)

小結(jié)一下，如果要將一個(gè) paxos 工程化落地，衍生了哪些東西：

1. paxos 本質(zhì)是確定一個(gè)值，把參與確定這個(gè)值的角色打包稱為一組實(shí)例（ paxos instance ）；2.不同實(shí)例之間決議互不干擾。多組 paxos 實(shí)例確定多個(gè)值，形成一組操作序列，也是就日志 ；
2. 日志 狀態(tài)機(jī) 可以成為任何有意義的工程系統(tǒng)；
3. 為了解決遞交提案混亂可能引發(fā)的效率問題（比如活鎖），可以通過(guò)指定 Leader 角色來(lái)解決；

慢著，這個(gè)工程化方向咋這么眼熟呢？

這不就是 raft ！

raft 協(xié)議

終于到了 raft 協(xié)議，raft 的論文開篇就是這么一段話：

Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to (multi-)Paxos, and it is as efficient as Paxos, but its structure is different from Paxos;

raft 證明和 paxos 等價(jià)，raft 是一種日志復(fù)制的一致性算法。

看懂了嗎？raft 的著眼點(diǎn)就是 日志 狀態(tài)機(jī) 的方向。

劃重點(diǎn)：raft 天生就是 paxos 協(xié)議工程化的一種樣子。

如下圖：

圖里交代了關(guān)鍵模塊：

1. 客戶端（ Client ）：就是用戶嘛，寫入數(shù)據(jù)的就是它嘍；
2. 一致性模塊（ Consensus Module ）：負(fù)責(zé)寫入 log，并且把 log 復(fù)制到其他節(jié)點(diǎn)；
3. 狀態(tài)機(jī)（ State Machine ）：輸入 log ，推進(jìn)變更系統(tǒng)狀態(tài)；

raft 確實(shí)比 paxos 簡(jiǎn)單啊，因?yàn)樗呀?jīng)把實(shí)現(xiàn)程序交互的樣子都畫出來(lái)了。

在 raft 論文里面直接把幾個(gè)因素交代清楚了：

1. raft 就是管理日志復(fù)制的算法；
2. 日志 狀態(tài)機(jī) 就能落地一個(gè)一致性的系統(tǒng)應(yīng)用；
3. 集群角色有分類，Leader 作為唯一的寫入點(diǎn)，所有日志復(fù)制是 Leader 到 Follower 單項(xiàng)傳輸；

說(shuō)實(shí)話，上面的這些知識(shí)點(diǎn)都是我們對(duì) paxos 工程化的長(zhǎng)時(shí)間推導(dǎo)才想明白的。

沒想到 raft 論文上來(lái)就給整好了，所以我才說(shuō)，raft 協(xié)議出生就是為了解決工程化的問題的。

raft 把一致性歸納成三個(gè)核心問題：

1. Leader 的選舉；
2. 日志的復(fù)制；
3. 正確性的保證（約束條件）；

其實(shí)真正要做的就兩個(gè)，第三個(gè)問題貫穿前兩個(gè)事情：

1. 選出一個(gè) Leader ；
2. 把 Leader 的日志復(fù)制分發(fā)到 Follower 節(jié)點(diǎn)；

我們下面來(lái)看下這兩個(gè)事情是怎么做的。

而用戶則只好奇兩個(gè)事情：

1. 數(shù)據(jù)怎么讀寫？
2. 節(jié)點(diǎn)擴(kuò)縮容怎么搞？

1 Leader 選舉

角色轉(zhuǎn)變：

簡(jiǎn)單看下 raft 協(xié)議中關(guān)于 Leader 選舉的部分。下面是角色轉(zhuǎn)化圖，非常清晰：

圖里至少能得到這么幾點(diǎn)知識(shí)點(diǎn)：

1. 系統(tǒng)開始每個(gè)節(jié)點(diǎn)都是從 Follower 角色開始；
2. 定時(shí)器超時(shí)之后，角色轉(zhuǎn)變?yōu)?Candidate ，開始競(jìng)選 Leader；
3. Candidate 如果獲得多數(shù)人的支持，那么選舉成功，角色轉(zhuǎn)變?yōu)?Leader 。如果選舉失敗，那么退為 Follower ；

Leader 選舉成功之后則可以對(duì)外提供服務(wù)。

在論文中，為了讓選舉更高效（避免類似活鎖的場(chǎng)景），各個(gè)節(jié)點(diǎn)的定時(shí)器間隔是隨機(jī)值。

服務(wù)時(shí)間線：

從時(shí)間線來(lái)看，可以分為兩部分時(shí)間（如下圖）：

1. 無(wú) Leader 狀態(tài)（選舉中）；
2. 正常狀態(tài)（ Leader ）；

每個(gè) Leader 都有自己的任期，注意：無(wú) Leader 的狀態(tài)是停服狀態(tài)。

Leader 選舉的規(guī)則？

被多數(shù)節(jié)點(diǎn)接受并且持久化的的日志叫做 committed log 。

說(shuō)實(shí)話，Leader 選舉的規(guī)則其實(shí)就一條：具備完備的 committed 的 log 數(shù)據(jù)即可。

那怎么才能選出具有完備數(shù)據(jù)的節(jié)點(diǎn)呢？

這就是 raft 協(xié)議里安全性的內(nèi)容。投票發(fā)起者（ Candidate ）要告訴對(duì)方兩個(gè)東西：

1. 任期編號(hào)；
2. 當(dāng)前日志的最新位置；

其他節(jié)點(diǎn)（ Follower ）收到這兩個(gè)信息會(huì)決定要投它一票，還是拒絕它？

劃重點(diǎn)：做這個(gè)決定依賴于它的日志是不是比我新（全）。

那怎么判斷誰(shuí)更新（全）呢？

1. 先比 term ，誰(shuí)更大誰(shuí)就新;
• 舉個(gè)例子，F(xiàn)ollower 節(jié)點(diǎn)保存的任期是 4，Candidate 發(fā)過(guò)來(lái)的是 3 ，這種就直接拒絕了；
2. 如果任期相同，那么就比較 index ，index 誰(shuí)更大就新;
• 舉個(gè)例子，對(duì)面發(fā)過(guò)來(lái)的 index 是 7，我本地是的 8 ，那么就多說(shuō)了，拒絕；

我們看一眼下圖，我們知道 raft 的操作對(duì)象就是日志。在 raft 協(xié)議中，每個(gè)日志都有唯一的編號(hào)：index ，代表了它唯一的槽位。

題外話：這里可以類比上面 paxos 章節(jié)說(shuō)的 instance 概念。其實(shí)每一個(gè)日志槽位和其他模塊對(duì)象結(jié)合其他就是單獨(dú)的 instance ，這一系列的日志對(duì)象就類似于 paxos 多實(shí)例 instance 確定的值。

每個(gè) index 槽位代表的值一旦確定將永不更改，它們的確認(rèn)不相互影響。

從完備的數(shù)據(jù)來(lái)看 committed 的位置在 index：7 這個(gè)位置。那么第一個(gè)節(jié)點(diǎn)、第三個(gè)節(jié)點(diǎn)、第五個(gè)節(jié)點(diǎn)都具備完備的數(shù)據(jù)，但是按照協(xié)議跑起來(lái)，只有第一個(gè)節(jié)點(diǎn)和第三個(gè)節(jié)點(diǎn)才有可能會(huì)成為 Leader 。因?yàn)樗鼈儍蓚€(gè)節(jié)點(diǎn)有最新的數(shù)據(jù)（雖然是沒有 commited 的），第五個(gè)節(jié)點(diǎn)找它們投票的時(shí)候，會(huì)被拒絕（它雖然有完備的數(shù)據(jù)，但是不夠新）。

2 日志復(fù)制

日志復(fù)制有幾個(gè)特點(diǎn)：

1. 日志傳輸為單向傳輸，Leader 到 Follower ；
2. Leader 永遠(yuǎn)不會(huì)改寫或者刪除自己的日志，永遠(yuǎn)只做 Append ；
3. 日志內(nèi)容一切以 Leader 為主，哪怕是強(qiáng)制覆蓋 ；

和 paxos 類似，每個(gè)日志槽位的值一旦確定就無(wú)法更改，無(wú)論怎么投票，怎么運(yùn)轉(zhuǎn)，這個(gè)值不再變更。raft 就這樣連續(xù)的確定值就能形成一個(gè)的日志序列，給到狀態(tài)機(jī)使用。

這里類比 paxos 的 instance ，其實(shí)我們只需要保證每個(gè)槽位的投票和數(shù)據(jù)的獨(dú)立就和 instance 的是一個(gè)效果。

以這個(gè)圖為例，在不切主的情況下，數(shù)據(jù)從節(jié)點(diǎn)（1）向其他節(jié)點(diǎn)發(fā)送，補(bǔ)齊數(shù)據(jù)。

經(jīng)過(guò)狀態(tài)機(jī)應(yīng)用，所有的節(jié)點(diǎn)最終系統(tǒng)狀態(tài)一致：

• x = 4
• y = 7

思考一個(gè)問題：如果用戶寫失敗了，系統(tǒng)提供了什么結(jié)果語(yǔ)義？

劃重點(diǎn)：未定義。有可能寫入了，有可能沒寫入。這種場(chǎng)景只能依賴于用戶重試。標(biāo)準(zhǔn)的存儲(chǔ)服務(wù)寫失敗語(yǔ)義。

還是以上圖舉例，就拿 index：8 這個(gè)位置的寫入來(lái)說(shuō)，用戶從節(jié)點(diǎn)（1）寫入數(shù)據(jù) x=4。

場(chǎng)景一：這個(gè)時(shí)候只把日志成功復(fù)制到節(jié)點(diǎn)（3）就掛了。用戶那邊自然是失敗的。節(jié)點(diǎn)（1）恢復(fù)后，還是又成為了 Leader ，由于 leader 永遠(yuǎn)不會(huì)刪改日志，所以最終還是會(huì)把 index 的日志復(fù)制到其他節(jié)點(diǎn)，等復(fù)制完之后，滿足 quroum 系統(tǒng)狀態(tài)就變了就變成 x=4 了。

場(chǎng)景二：一條日志沒寫入，那么系統(tǒng)狀態(tài)就還是 x=5 ；

所以，用戶寫入失敗的場(chǎng)景，一定要依賴重試。不能對(duì)結(jié)果假定。這種假定在存儲(chǔ)系統(tǒng)中通用。

關(guān)于 raft 日志復(fù)制，有個(gè)規(guī)則不得不提：Leader 永遠(yuǎn)不能 commit 非自己任期的日志。哪怕已經(jīng)滿足 quorum 。

為什么會(huì)有這個(gè)限定 ？

看一個(gè) raft 論文中的簡(jiǎn)單的例子：

這是一個(gè)時(shí)間序列，從 a -> b -> c -> d -> e ：

1. a 時(shí)刻：Leader 為 S1（ 黑框的為 Leader ），它有著最新的日志 index:2 ，雖然最新的 index:2 并沒有 committed（復(fù)制到多數(shù)），只復(fù)制到了 S2 ；
2. b 時(shí)刻：S1 掛了，S5 被選舉為 Leader ，任期為 3 ，并且 Client 還遞交了一個(gè)寫入；
3. c 時(shí)刻：S5 掛了，S1 被重新選舉為 Leader ，任期為 4，這個(gè)時(shí)候它復(fù)制日志，把 index:2 的日志復(fù)制給了 S1，S2，S3 ，這是滿足了 quorum （但注意了，這個(gè)系統(tǒng)千萬(wàn)不能認(rèn)為 commit 了，且往后看）。并且 Client 還遞交了一個(gè)寫入在 index:3 的位置；
4. d 時(shí)刻：S1 掛了，S5 被重新選舉為 Leader（S2，S3，S4 都會(huì)投票），于是把 index:2 的日志強(qiáng)制覆蓋到所有節(jié)點(diǎn)；
5. e 時(shí)刻：這個(gè)時(shí)刻是一種假設(shè)，假設(shè)說(shuō)，S1 在 c 時(shí)刻的時(shí)候在掛掉之前把任期 4，index:3 的日志復(fù)制到多數(shù)節(jié)點(diǎn)，那結(jié)果又不一樣了。這種場(chǎng)景系統(tǒng)可以認(rèn)為 index:3 被 commit 了，index:2 則是被間接 commit 了；

看到了嗎？

為什么在 c 時(shí)刻一直強(qiáng)調(diào)，不要認(rèn)為 index:2 滿足了 quorum 就認(rèn)為是 committed 的日志，然后就去 apply 。因?yàn)槟阋坏┻@樣做了，d 時(shí)刻的場(chǎng)景發(fā)生之后，index:2 的日志是被修改了。

這就導(dǎo)致 index:2 兩次 commit 了不同的 log ！這就違背了一個(gè)槽位確定一個(gè)值，永不更改的承諾。

這絕對(duì)不行。

怎么辦？

解決很簡(jiǎn)單，上面已經(jīng)講了，在 c 時(shí)刻這種場(chǎng)景，就算 index:2 被復(fù)制到多數(shù)，滿足了 quorum 也不能認(rèn)為是 committed （ 沒有 commit 自然就不能 apply ），Leader 只能 commit 自己任期的日志。前面的日志將被間接的遞交。

再談?wù)?e 時(shí)刻為什么把 index:3 的日志復(fù)制到多數(shù)之后，就可以認(rèn)為 index:2 被 commit 了？

因?yàn)?，這樣做了之后，將不可能出現(xiàn) d 時(shí)刻的場(chǎng)景。因?yàn)?S5 的任期只有 3 ！它將不可能成為 Leader 。

題外話：etcd 在每次選舉出 Leader 的第一件事就是廣播一條空白消息，原因就在這里。目的是為了間接 commit 掉前任的日志。

3 狀態(tài)機(jī)

這部分其實(shí)是最簡(jiǎn)單的，狀態(tài)機(jī)做的事情我們叫做 apply 。apply 的內(nèi)容則是各個(gè)業(yè)務(wù)自行解釋，舉個(gè)例子，如下的日志，這是一個(gè)典型的 kv 系統(tǒng)的樣子：

日志 apply 完之后，系統(tǒng)狀態(tài)為：

x = 4
y = 7
劃重點(diǎn)：日志里面的內(nèi)容由業(yè)務(wù)自行解釋，raft 只保證日志復(fù)制是完全一致的。

4 Propose 遞交

用戶的入口就是從遞交 Propose 開始，由 Leader 接收用戶請(qǐng)求，然后封裝成日志的樣子，經(jīng)過(guò)了 commit（ 確定這個(gè)值 ）之后就能對(duì)外承諾。

思考一個(gè)小問題：集群只有一個(gè) Leader ，如果請(qǐng)求發(fā)給了 Follower 呢？難不成 Client 還要專門記錄誰(shuí)是 Leader ？

也沒關(guān)系，F(xiàn)ollower 可以透明轉(zhuǎn)發(fā)給 Leader 。Leader 處理好之后，回應(yīng)即可。

劃重點(diǎn)：還是那句話，只由 Leader 來(lái)發(fā)起，就算發(fā)給了 Follower ，請(qǐng)求也會(huì)轉(zhuǎn)發(fā) Leader。

5 成員變更

成員變更一般分為兩種場(chǎng)景：

1. 單節(jié)點(diǎn)變更
2. 多節(jié)點(diǎn)變更

場(chǎng)景一：?jiǎn)喂?jié)點(diǎn)變更

這是絕對(duì)安全的，因?yàn)樗粫?huì)直接影響 Leader 的地位。這種的處理也簡(jiǎn)單。把集群變更的消息作為一條日志廣播到集群，被集群 commit 之后，就可以直接 apply 新配置了。

劃重點(diǎn)：集群變更也可以作為日志消息。 還是那句話，日志里面的內(nèi)容可以是任何東西，業(yè)務(wù)自行解釋。raft 只保證它的一致即可。

舉個(gè)栗子：

原始集群 （S1，S2，S3），現(xiàn)在擴(kuò)容一臺(tái) S4 ，只需要封裝一條 < add S4 > 這樣的日志消息，廣播到集群里就可以，等這條消息 commit 了，就可以變更配置了。

場(chǎng)景二：多節(jié)點(diǎn)變更

多節(jié)點(diǎn)的配置則不能這樣做，為什么？

因?yàn)榕乱淮涡詠?lái)的人太多，直接威脅到原有 Leader 的權(quán)威。如下：

比如說(shuō)，原有集群 （ S1，S3，S3 ），一次性來(lái)了兩個(gè) （ S4，S5 ），這就可能導(dǎo)致某個(gè)時(shí)刻出現(xiàn)兩個(gè) Leader 的情況：

1. S1，S2 認(rèn)為 S1 是 Leader，在原有 3 節(jié)點(diǎn)的集群中，滿足多數(shù)，合法 ；
2. S3，S4，S5 認(rèn)為 S3 是 Leader ，在新的 5 節(jié)點(diǎn)集群中滿足多數(shù)，合法；

那這可不行，這不就腦裂了嘛。一個(gè)集群只能有一個(gè) Leader ，不然就會(huì)出現(xiàn)數(shù)據(jù)混亂的情況。

那怎么解決這個(gè)問題呢？

通用的做法是 joint consensus 算法。其實(shí)這個(gè)算法很簡(jiǎn)單，就是加一個(gè)中間過(guò)程，集群配置搞成兩階段切換，過(guò)程中要滿足新集群和老集群的同時(shí)的 quorum 投票。

這個(gè)圖怎么看不懂？我舉個(gè)栗子：

1. 最開始集群配置（ S1，S2，S3 ），我們暫且叫做 C_old ；
2. 遞交兩條集群變更的日志，Add S4，Add S5 ，Leader 向所有 S1，S2，S3 廣播日志；
3. 所有節(jié)點(diǎn)（ S1，S2，S3 ）收到這兩條日志，則代表這兩條日志被 commit 了，于是 apply 這兩條日志，apply 的行為：集群配置變更為（ S1，S2，S3，S4，S5 ）