http://www.zhihu.com/question/36648084
作者：朱一聰
鏈接：http://www.zhihu.com/question/36648084/answer/82332860
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
鏈接：http://www.zhihu.com/question/36648084/answer/82332860
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
Raft協議比paxos的優點是 容易理解，容易實現。它強化了leader的地位，把整個協議可以清楚的分割成兩個部分，並利用日誌的連續性做了一些簡化：
（1）Leader在時。由Leader向Follower同步日誌
（2）Leader掛掉了，選一個新Leader，Leader選舉算法。
但是本質上來說，它容易的地方在於流程清晰，描述更清晰，關鍵之處都給出了僞代碼級別的描述，可以直接用於實現，而paxos最初的描述是針對非常理論的一致性問題，真正能應用於工程實現的mulit-paxos，Lamport老爺爺就提了個大概，之後也有人沒嘗試對multi-paxos做出更爲完整詳細的描述，但是每個人描述的都不大一樣。
Zookeeper的ZAB，Viewstamped Replication（VR），raft，multi-paxos，這些都可以被稱之爲Leader-based一致性協議。不同的是，multi-paxos leader是作爲對經典paxos的優化而提出，通過選擇一個proposer作爲leader降低多個proposer引起衝突的頻率，提升性能將一次決議的平均消息代價縮小到最優的兩次，實際上就算有多個leader存在，算法還是安全的，只是退化爲經典的paxos算法。而經典的paxos，從一個提案被提出到被接受分爲兩個階段，第一個階段去詢問值，第二階段根據詢問的結果提出值。這兩個階段是無法分割的，兩個階段的每個細節都是精心設計的，相互關聯，共同保障了協議的一致性。而VR,ZAB,Raft這些強調唯一的leader的協議，它們直接從leader的角度描述協議的流程，但是實際上它們使用了和Paxos完全一樣的原理來保證協議的安全性，當同時存在多個節點同時嘗試成爲leader或者多個節點都認爲自己時leader時，它們都可以視作是經典Paxos流程。
Paxos和raft都是一旦一個entries（raft協議叫日誌，paxos叫提案，叫法而已）得到多數派的贊成，這個entries就會定下來，不丟失，值不更改，最終所有節點都會贊成它。Paxos中稱爲提案被決定，Raft,ZAB,VR稱爲日誌被提交，這只是說法問題。一個日誌一旦被提交(或者決定），就不會丟失，也不可能更改，這一點這4個協議都是一致的。Multi-paxos和Raft都用一個數字來標識leader的合法性，multi-paxos中叫proposer-id，Raft叫term，意義是一樣的，multi-paxos proposer-id最大的Leader提出的決議纔是有效的，raft協議中term最大的leader纔是合法的。實際上raft協議在leader選舉階段，由於老leader可能也還存活，也會存在不只一個leader的情形，只是不存在term一樣的兩個leader，因爲選舉算法要求leader得到同一個term的多數派的同意，同時贊同的成員會承諾不接受term更小的任何消息。這樣可以根據term大小來區分誰是合法的leader。Multi-paxos的區分leader的合法性策略其實是一樣的，誰的proproser-id大誰合法，而proposer-id是唯一的。因此它們其實在同一個時刻，都只會存在一個合法的leader。同時raft協議的Leader選舉算法，新選舉出的Leader已經擁有全部的可以被提交的日誌，而multi-paxos擇不需要保證這一點，這也意味multi-paxos需要額外的流程從其它節點獲取已經被提交的日誌。因此raft協議日誌可以簡單的只從leader流向follower在raft協議中，而multi-paxos則需要額外的流程補全已提交的日誌。需要注意的是日誌可以被提交和日誌已經被提交是兩個概念，它們的區別就像是我前方有塊石頭和我得知我前方有塊石頭。但是實際上，Raft和multi-Paxos一旦日誌可以被提交，就能會保證不丟失，multi-paxos天然保證了這一點，這也是爲什麼新leader對於尚未被確認已經提交的日誌需要重新執行經典paxos的階段一，來補全可能缺失的已經被提交的日誌，Raft協議通過強制新Leader首先提交一個本term的no-op 日誌，配合前面提到的Leader選舉算法所保證的性質，確保了這一點。一條日誌一旦被多數派的節點寫入本地日誌文件中，就可以被提交，但是leader只有得知這一點後，纔會真正commit這條日誌，此時日誌纔是已經被提交的。
Raft協議強調日誌的連續性，multi-paxos則允許日誌有空洞。日誌的連續性蘊含了這樣一條性質：如果兩個不同節點上相同序號的日誌，term相同，那麼這和這之前的日誌必然也相同的。raft協議利用日誌的連續性，leader可以很方便的得知自己的follower擁有的日誌的情況，Follower只要告訴Leader自己本地日誌文件的最後一個日誌的序號和term就可以了；同時由於已經commit的日誌本身也是連續的，只需要記錄最後一條已經commit的日誌的位置，就可以判定這條日誌之前所有的日誌都已被提交。而multi-paxos則不行，所以當新leader產生時需要每個日誌重新用proposer-id重走一遍所有的日誌。可以舉個列子，A,B,C三臺機器，C是Leader，term是3，A告訴C它們最後一個日誌的序列號都是4，term是3，那麼C就知道A肯定有序列號爲1,2,3,4的日誌，而且和C中的序列號爲1,2,3,4的日誌一樣，這是raft協議日誌的連續性所強調的，好了那麼Leader知道日誌1，2，3，4已經被多數派（A,C)擁有了，可以提交了。同時，這也保證raft協議在leader選舉的時候，只需要從一個多數集中選擇最後出最後一條日誌term最大並且日誌數目最多的節點，新leader同樣必定擁有所有的已commit的日誌。這是由於任意一條commit的日誌，至少被多數派記錄，而由於日誌的連續性，擁有最後一條commit的日誌也就意味着擁有全部的commit日誌，因此raft協議中一個多數派必然存在一個節點擁有全部的已提交的日誌。而對於multi-paxos每個日誌需要單獨被確認是否可以提交，因此當新leader產生後，它只好重新對每個日誌進行確認，已確定它們是否可以被提交，甚至於新leader可能缺失可以被提交的日誌，需要向其它節點學習到缺失的可以被提交的日誌，當然這都可以通過向一個多數派詢問完成（這個流程存在着很大的優化空間，例如可以將這個流程合併到leader選舉階段，可以將所有日誌的確認和學習合併到一輪消息中，減少消息數目等）。所以本質上，兩者是一樣的。一個日誌被多數派擁有，那麼它就可以被提交，但是Leader需要通過某種方式得知這一點，同時爲了已經被提交的日誌不被新leader覆寫，新leader需要擁有所有已經被提交的日誌（或者說可以被提交，因爲有時候並沒有辦法得知一條可以被提交的日誌是否已經被提交），之後才能正常工作。兩者的區別在於Leader確認提交和獲取所有可以被提交日誌的方式上，而方式上的區別又是由於是日誌是否連續造成的，Raft協議利用日誌連續性，簡化了這個過程。
在Raft和multi-paxos協議確保安全性的原理上，更進一步的說，所有的凡是 滿足 集羣中存活的節點數還能構成一個多數派，一致性就能滿足的算法，raft協議，paxos，zab，viewstamp都是利用了同一個性質：兩個多數派集合之間存在一個公共成員這個特性。對於一致性協議來說，就是一旦一個變量的值被確定，那麼這個變量的值應該是唯一的，不再更改的。Raft,paoxos等協議，對於一個變量v來說，一個由節點n1提出的值a只有被一個多數集q1認可並記錄後，纔會正式令v=a，如果另一個節點n2想要修改變量v的值爲b，也需要一個多數集q2的認可，而q1和q2必然至少有一個共同的成員p,節點p已經記錄了v=a。因此只需要通過增加一些約束，讓p能夠告訴節點n2這個事實：v=a，使得n2放棄自己的提議，或者讓節點p拒絕節點n2想要賦予v的值爲b這個行爲，都可以確保變量v的一致性不被破壞。這個思想對於這個四個協議來說都是一樣的，4個協議都使用一個唯一的整數作爲標識符來標明leader的合法性，paxos叫做proposer-id，ZAB叫epoch，VR叫view，raft叫term。把leader看做是想要賦予變量v某個值的節點n1,n2，上面提到的情形中，如果n2是目前的合法leader，那麼n2需要知道v=a這個事實，對於raft來說就是選擇n2是已經記錄了v=a的節點，對於multi-paxos來說，就是重新確認下v的值。如果n1是目前的合法leader，n2是老的leader，p就會根據leader的標識符拒絕掉n2的提案，n2的提案會由於得不到一個多數派的接受而失效。最直接的從理論上闡明這個原理的是經典的paxos算法，關於這個原理更具體的闡述可以看看我在如何淺顯易懂地解說 Paxos 的算法？下的回答。所以確實在一定程度上可以視raft,ZAB,VR都是paxos算法的一種改進，一種簡化，一種優化，一種具象化。Lamport老人家還是叼叼叼。。。。。。。不過值得一提的是，ZAB和raft作者確實是受了paxos很多啓發，VR是幾乎同時獨立於paxos提出的。
Raft容易實現在於它的描述是非常規範的，包括了所有的實現細節。如上面的人說的有如僞代碼。而paxos的描述側重於理論，工程實現按照谷歌chubby論文中的說話，大家從paxos出現，寫着寫着，處理了n多實際中的細節之後，已經變成另外一個算法了，這時候正確性已經無法得到理論的保證。所以它的實現非常難，因爲一致性協議實非常精妙的。小細節上沒考慮好，整個協議的一致性就崩潰了，而發現並更正細節上的錯誤在沒有詳盡的現成的參考的情況下是困難的，這需要對協議很深的理解。而且在Raft協議的博士論文CONSENSUS: BRIDGING THEORY AND PRACTICE，兩位作者手把手事無鉅細的教你如何用raft協議構建一個複製狀態機。我表示智商正常的大學生，都能看懂。我相信在未來一致性現在被提起來，肯定不是現在這樣，大部分人覺得好難啊，實現更難。。。。應該會成爲一種常用技術。
（1）Leader在時。由Leader向Follower同步日誌
（2）Leader掛掉了，選一個新Leader，Leader選舉算法。
但是本質上來說，它容易的地方在於流程清晰，描述更清晰，關鍵之處都給出了僞代碼級別的描述，可以直接用於實現，而paxos最初的描述是針對非常理論的一致性問題，真正能應用於工程實現的mulit-paxos，Lamport老爺爺就提了個大概，之後也有人沒嘗試對multi-paxos做出更爲完整詳細的描述，但是每個人描述的都不大一樣。
Zookeeper的ZAB，Viewstamped Replication（VR），raft，multi-paxos，這些都可以被稱之爲Leader-based一致性協議。不同的是，multi-paxos leader是作爲對經典paxos的優化而提出，通過選擇一個proposer作爲leader降低多個proposer引起衝突的頻率，提升性能將一次決議的平均消息代價縮小到最優的兩次，實際上就算有多個leader存在，算法還是安全的，只是退化爲經典的paxos算法。而經典的paxos，從一個提案被提出到被接受分爲兩個階段，第一個階段去詢問值，第二階段根據詢問的結果提出值。這兩個階段是無法分割的，兩個階段的每個細節都是精心設計的，相互關聯，共同保障了協議的一致性。而VR,ZAB,Raft這些強調唯一的leader的協議，它們直接從leader的角度描述協議的流程，但是實際上它們使用了和Paxos完全一樣的原理來保證協議的安全性，當同時存在多個節點同時嘗試成爲leader或者多個節點都認爲自己時leader時，它們都可以視作是經典Paxos流程。
Paxos和raft都是一旦一個entries（raft協議叫日誌，paxos叫提案，叫法而已）得到多數派的贊成，這個entries就會定下來，不丟失，值不更改，最終所有節點都會贊成它。Paxos中稱爲提案被決定，Raft,ZAB,VR稱爲日誌被提交，這只是說法問題。一個日誌一旦被提交(或者決定），就不會丟失，也不可能更改，這一點這4個協議都是一致的。Multi-paxos和Raft都用一個數字來標識leader的合法性，multi-paxos中叫proposer-id，Raft叫term，意義是一樣的，multi-paxos proposer-id最大的Leader提出的決議纔是有效的，raft協議中term最大的leader纔是合法的。實際上raft協議在leader選舉階段，由於老leader可能也還存活，也會存在不只一個leader的情形，只是不存在term一樣的兩個leader，因爲選舉算法要求leader得到同一個term的多數派的同意，同時贊同的成員會承諾不接受term更小的任何消息。這樣可以根據term大小來區分誰是合法的leader。Multi-paxos的區分leader的合法性策略其實是一樣的，誰的proproser-id大誰合法，而proposer-id是唯一的。因此它們其實在同一個時刻，都只會存在一個合法的leader。同時raft協議的Leader選舉算法，新選舉出的Leader已經擁有全部的可以被提交的日誌，而multi-paxos擇不需要保證這一點，這也意味multi-paxos需要額外的流程從其它節點獲取已經被提交的日誌。因此raft協議日誌可以簡單的只從leader流向follower在raft協議中，而multi-paxos則需要額外的流程補全已提交的日誌。需要注意的是日誌可以被提交和日誌已經被提交是兩個概念，它們的區別就像是我前方有塊石頭和我得知我前方有塊石頭。但是實際上，Raft和multi-Paxos一旦日誌可以被提交，就能會保證不丟失，multi-paxos天然保證了這一點，這也是爲什麼新leader對於尚未被確認已經提交的日誌需要重新執行經典paxos的階段一，來補全可能缺失的已經被提交的日誌，Raft協議通過強制新Leader首先提交一個本term的no-op 日誌，配合前面提到的Leader選舉算法所保證的性質，確保了這一點。一條日誌一旦被多數派的節點寫入本地日誌文件中，就可以被提交，但是leader只有得知這一點後，纔會真正commit這條日誌，此時日誌纔是已經被提交的。
Raft協議強調日誌的連續性，multi-paxos則允許日誌有空洞。日誌的連續性蘊含了這樣一條性質：如果兩個不同節點上相同序號的日誌，term相同，那麼這和這之前的日誌必然也相同的。raft協議利用日誌的連續性，leader可以很方便的得知自己的follower擁有的日誌的情況，Follower只要告訴Leader自己本地日誌文件的最後一個日誌的序號和term就可以了；同時由於已經commit的日誌本身也是連續的，只需要記錄最後一條已經commit的日誌的位置，就可以判定這條日誌之前所有的日誌都已被提交。而multi-paxos則不行，所以當新leader產生時需要每個日誌重新用proposer-id重走一遍所有的日誌。可以舉個列子，A,B,C三臺機器，C是Leader，term是3，A告訴C它們最後一個日誌的序列號都是4，term是3，那麼C就知道A肯定有序列號爲1,2,3,4的日誌，而且和C中的序列號爲1,2,3,4的日誌一樣，這是raft協議日誌的連續性所強調的，好了那麼Leader知道日誌1，2，3，4已經被多數派（A,C)擁有了，可以提交了。同時，這也保證raft協議在leader選舉的時候，只需要從一個多數集中選擇最後出最後一條日誌term最大並且日誌數目最多的節點，新leader同樣必定擁有所有的已commit的日誌。這是由於任意一條commit的日誌，至少被多數派記錄，而由於日誌的連續性，擁有最後一條commit的日誌也就意味着擁有全部的commit日誌，因此raft協議中一個多數派必然存在一個節點擁有全部的已提交的日誌。而對於multi-paxos每個日誌需要單獨被確認是否可以提交，因此當新leader產生後，它只好重新對每個日誌進行確認，已確定它們是否可以被提交，甚至於新leader可能缺失可以被提交的日誌，需要向其它節點學習到缺失的可以被提交的日誌，當然這都可以通過向一個多數派詢問完成（這個流程存在着很大的優化空間，例如可以將這個流程合併到leader選舉階段，可以將所有日誌的確認和學習合併到一輪消息中，減少消息數目等）。所以本質上，兩者是一樣的。一個日誌被多數派擁有，那麼它就可以被提交，但是Leader需要通過某種方式得知這一點，同時爲了已經被提交的日誌不被新leader覆寫，新leader需要擁有所有已經被提交的日誌（或者說可以被提交，因爲有時候並沒有辦法得知一條可以被提交的日誌是否已經被提交），之後才能正常工作。兩者的區別在於Leader確認提交和獲取所有可以被提交日誌的方式上，而方式上的區別又是由於是日誌是否連續造成的，Raft協議利用日誌連續性，簡化了這個過程。
在Raft和multi-paxos協議確保安全性的原理上，更進一步的說，所有的凡是 滿足 集羣中存活的節點數還能構成一個多數派，一致性就能滿足的算法，raft協議，paxos，zab，viewstamp都是利用了同一個性質：兩個多數派集合之間存在一個公共成員這個特性。對於一致性協議來說，就是一旦一個變量的值被確定，那麼這個變量的值應該是唯一的，不再更改的。Raft,paoxos等協議，對於一個變量v來說，一個由節點n1提出的值a只有被一個多數集q1認可並記錄後，纔會正式令v=a，如果另一個節點n2想要修改變量v的值爲b，也需要一個多數集q2的認可，而q1和q2必然至少有一個共同的成員p,節點p已經記錄了v=a。因此只需要通過增加一些約束，讓p能夠告訴節點n2這個事實：v=a，使得n2放棄自己的提議，或者讓節點p拒絕節點n2想要賦予v的值爲b這個行爲，都可以確保變量v的一致性不被破壞。這個思想對於這個四個協議來說都是一樣的，4個協議都使用一個唯一的整數作爲標識符來標明leader的合法性，paxos叫做proposer-id，ZAB叫epoch，VR叫view，raft叫term。把leader看做是想要賦予變量v某個值的節點n1,n2，上面提到的情形中，如果n2是目前的合法leader，那麼n2需要知道v=a這個事實，對於raft來說就是選擇n2是已經記錄了v=a的節點，對於multi-paxos來說，就是重新確認下v的值。如果n1是目前的合法leader，n2是老的leader，p就會根據leader的標識符拒絕掉n2的提案，n2的提案會由於得不到一個多數派的接受而失效。最直接的從理論上闡明這個原理的是經典的paxos算法，關於這個原理更具體的闡述可以看看我在如何淺顯易懂地解說 Paxos 的算法？下的回答。所以確實在一定程度上可以視raft,ZAB,VR都是paxos算法的一種改進，一種簡化，一種優化，一種具象化。Lamport老人家還是叼叼叼。。。。。。。不過值得一提的是，ZAB和raft作者確實是受了paxos很多啓發，VR是幾乎同時獨立於paxos提出的。
Raft容易實現在於它的描述是非常規範的，包括了所有的實現細節。如上面的人說的有如僞代碼。而paxos的描述側重於理論，工程實現按照谷歌chubby論文中的說話，大家從paxos出現，寫着寫着，處理了n多實際中的細節之後，已經變成另外一個算法了，這時候正確性已經無法得到理論的保證。所以它的實現非常難，因爲一致性協議實非常精妙的。小細節上沒考慮好，整個協議的一致性就崩潰了，而發現並更正細節上的錯誤在沒有詳盡的現成的參考的情況下是困難的，這需要對協議很深的理解。而且在Raft協議的博士論文CONSENSUS: BRIDGING THEORY AND PRACTICE，兩位作者手把手事無鉅細的教你如何用raft協議構建一個複製狀態機。我表示智商正常的大學生，都能看懂。我相信在未來一致性現在被提起來，肯定不是現在這樣，大部分人覺得好難啊，實現更難。。。。應該會成爲一種常用技術。
raft利用日誌連續性對Paxos做了大量很好的簡化，但是其中有一點有很強的誤導性，就是新任leader對於舊日誌的處理，他的原文描述是“Raft uses a simpler approach where it guarantees that all the committed entries from previous terms are present on each new leader from the moment
of its election, without the need to transfer those entries to the leader.”
raft利用日誌連續確認的特性，只要選舉termID最大的做leader，就可以保證leader當選以後，不需要對本地舊日誌重新投票，而是請follower過來直接抓就行了。即使對哪些尚未形成多數派的entry，也是一樣的處理方式，並未進行重新投票，在他的協議裏這個做法是沒有問題的。
但是multi-paxos原本的意思是，即使形成了多數派，仍然需要使用新的proposalID走一遍prepare-accept過程，工程上做了優化之後，對於明確標記了已形成多數派的entry可以不重新投票，但是未確認是否形成多數派的entry，則要求新任leader使用新的proposalID重新投票。
因爲multi-paxos並不假設日誌間有連續確認的關係，每條日誌之間相互獨立，沒有關係，1號日誌尚未確認時，2號日誌就可以確認形成多數派備份。附一張之前分享ppt裏的圖，大家自己琢磨吧。
raft利用日誌連續確認的特性，只要選舉termID最大的做leader，就可以保證leader當選以後，不需要對本地舊日誌重新投票，而是請follower過來直接抓就行了。即使對哪些尚未形成多數派的entry，也是一樣的處理方式，並未進行重新投票，在他的協議裏這個做法是沒有問題的。
但是multi-paxos原本的意思是，即使形成了多數派，仍然需要使用新的proposalID走一遍prepare-accept過程，工程上做了優化之後，對於明確標記了已形成多數派的entry可以不重新投票，但是未確認是否形成多數派的entry，則要求新任leader使用新的proposalID重新投票。
因爲multi-paxos並不假設日誌間有連續確認的關係，每條日誌之間相互獨立，沒有關係，1號日誌尚未確認時，2號日誌就可以確認形成多數派備份。附一張之前分享ppt裏的圖，大家自己琢磨吧。
