raft演算法與paxos演算法相比有什麼優勢，使用場景有什麼差異？
阿新 • • 發佈：2019-02-18
本質上來講，raft協議比paxos的優點是 容易理解，容易實現。容易理解在於它強化了leader的地位。整個協議可以清楚的分割成兩個部分：
(1)Leader在時。由Leader向Follower同步日誌
（2）Leader掛掉了，選一個新Leader，Leader選舉演算法。
Zookeeper的ZAB和Viewstamped Replication也類似，這些都可以被稱之為Leader-based一致性協議。paxos Leader只是一種優化，為了提升效能，實際上就算有多個leader存在，演算法還是安全的。paxos原版協議，從一個提案被提出到被接受分為兩個階段。這兩個階段是無法分割的，因為兩個階段的每個細節都是精心設計的，相互關聯，共同保障了協議的一致性。
paxos和raft都是一旦一個entries（raft協議叫日誌，paxos叫提案，叫法而已）得到多數派的贊成，這個entries就會定下來，不丟失，不更改，最終所有節點都會贊成它。paoxos中稱為提案被決定，raft和zab稱為日誌被提交，這只是說法問題。Raft和ZAB就是一個日誌一旦被提交，就不會丟失，Multi-paxos也是如此。實際上Multi-paxos和Raft都有一個Leader，multi-paxos的proposer-id和Raft的term概念是類似的，都是用來標識leader的合法性，multi-paxos proposer-id最大的Leader提出的決議才是有效的，raft協議中term最大的Leader才是合法的。實際上raft協議也會存在兩個Leader的情形，只是不可能存在term一樣的兩個leader，因為選舉演算法要求leader得到同一個term的多數派的同意，這樣可以根據term來區分誰還是合法的leader。multi-paxos的區分leader的合法性策略其實是一樣的，誰大誰合法。同時raft協議的Leader選舉演算法，新選舉出的Leader一定擁有全部的可以被提交的日誌，而multi-paxos擇不需要保證這一點。這樣raft協議日誌可以簡單的只從leader流向follower在raft協議中，而multi-paxos則需要補全已提交的日誌。需要注意的是日誌可以被提交和日誌已經被提交是兩個概念。它們的區別就像是我前方有塊石頭和我得知我前方有塊石頭。日誌只有已經被提交，才會保證不丟失。
raft協議強調日誌的連續性，如果兩個日誌相同的序列號位置，term相同，那麼這和這之前的日誌必然是相同的。multi-paxos則允許日誌有空洞。raft協議利用日誌的連續性，Leader可以很方便的得知自己的哪些日誌是已經commit的。Follower只要告訴Leader自己的日誌本檔案的最後一個日誌的序號和term就可以了。而multi-paxos則不行，所以需要每個日誌重新用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)擁有了，可以提交了。同樣的情形，multi-paxos就不行。Leader只好重新對日誌進行投票。當然這是可以優化的，只要是Follower告訴Leader它擁有的所有所有日誌的情況。Leader收集統計一下還是可以知道哪些日誌已經被多數派接受了。所以本質上，兩者是一樣的。一個日誌被多數派擁有，那麼它就可以被提交，但是Leader需要通過某種方式得知這一點。兩者的區別在於Leader得知的手段上，手段上的區別又是由於日誌的連續性造成的。
更進一步的說，所有的凡是 滿足 叢集中存活的節點數還能構成一個多數派，一致性就能滿足的演算法，raft協議，paxos，zab都是利用了兩個多數派集合之間存在一個公共集合這個特性，兩個決定分別被兩個多數派接受，必然有一個節點同時接受了兩個決定。從這一個基本點出發，在協議的運轉中增加了約束來使得協議的一致性任何時候都不會被破壞。從這些協議的共同點來說，確實可以認為它們都是paxos演算法的一種改進，一種簡化，一種優化。Lamport老爺爺還是叼叼的。。。。。。。
Raft容易實現在於它的描述是非常規範的，包括了所有的實現細節。如上面的人說的有如虛擬碼。而paxos的描述側重於理論，工程實現按照谷歌chubby論文中的說話，大家從paxos出現，寫著寫著，處理了n多實際中的細節之後，已經變成另外一個演算法了，這時候正確性已經無法得到理論的保證。所以它的實現非常難，因為一致性協議實非常精妙的。小細節上沒考慮好，整個協議的一致性就崩潰了。而且在Raft協議的博士論文CONSENSUS: BRIDGING THEORY AND PRACTICE，兩位作者手把手事無鉅細的教你如何用raft協議構建一個複製狀態機。我表示智商正常的大學生，都能看懂。我相信在未來一致性現在被提起來，肯定不是現在這樣，好難啊，實現更難。。。。會成為一種常用技術。
(1)Leader在時。由Leader向Follower同步日誌
（2）Leader掛掉了，選一個新Leader，Leader選舉演算法。
Zookeeper的ZAB和Viewstamped Replication也類似，這些都可以被稱之為Leader-based一致性協議。paxos Leader只是一種優化，為了提升效能，實際上就算有多個leader存在，演算法還是安全的。paxos原版協議，從一個提案被提出到被接受分為兩個階段。這兩個階段是無法分割的，因為兩個階段的每個細節都是精心設計的，相互關聯，共同保障了協議的一致性。
paxos和raft都是一旦一個entries（raft協議叫日誌，paxos叫提案，叫法而已）得到多數派的贊成，這個entries就會定下來，不丟失，不更改，最終所有節點都會贊成它。paoxos中稱為提案被決定，raft和zab稱為日誌被提交，這只是說法問題。Raft和ZAB就是一個日誌一旦被提交，就不會丟失，Multi-paxos也是如此。實際上Multi-paxos和Raft都有一個Leader，multi-paxos的proposer-id和Raft的term概念是類似的，都是用來標識leader的合法性，multi-paxos proposer-id最大的Leader提出的決議才是有效的，raft協議中term最大的Leader才是合法的。實際上raft協議也會存在兩個Leader的情形，只是不可能存在term一樣的兩個leader，因為選舉演算法要求leader得到同一個term的多數派的同意，這樣可以根據term來區分誰還是合法的leader。multi-paxos的區分leader的合法性策略其實是一樣的，誰大誰合法。同時raft協議的Leader選舉演算法，新選舉出的Leader一定擁有全部的可以被提交的日誌，而multi-paxos擇不需要保證這一點。這樣raft協議日誌可以簡單的只從leader流向follower在raft協議中，而multi-paxos則需要補全已提交的日誌。需要注意的是日誌可以被提交和日誌已經被提交是兩個概念。它們的區別就像是我前方有塊石頭和我得知我前方有塊石頭。日誌只有已經被提交，才會保證不丟失。
raft協議強調日誌的連續性，如果兩個日誌相同的序列號位置，term相同，那麼這和這之前的日誌必然是相同的。multi-paxos則允許日誌有空洞。raft協議利用日誌的連續性，Leader可以很方便的得知自己的哪些日誌是已經commit的。Follower只要告訴Leader自己的日誌本檔案的最後一個日誌的序號和term就可以了。而multi-paxos則不行，所以需要每個日誌重新用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)擁有了，可以提交了。同樣的情形，multi-paxos就不行。Leader只好重新對日誌進行投票。當然這是可以優化的，只要是Follower告訴Leader它擁有的所有所有日誌的情況。Leader收集統計一下還是可以知道哪些日誌已經被多數派接受了。所以本質上，兩者是一樣的。一個日誌被多數派擁有，那麼它就可以被提交，但是Leader需要通過某種方式得知這一點。兩者的區別在於Leader得知的手段上，手段上的區別又是由於日誌的連續性造成的。
更進一步的說，所有的凡是 滿足 叢集中存活的節點數還能構成一個多數派，一致性就能滿足的演算法，raft協議，paxos，zab都是利用了兩個多數派集合之間存在一個公共集合這個特性，兩個決定分別被兩個多數派接受，必然有一個節點同時接受了兩個決定。從這一個基本點出發，在協議的運轉中增加了約束來使得協議的一致性任何時候都不會被破壞。從這些協議的共同點來說，確實可以認為它們都是paxos演算法的一種改進，一種簡化，一種優化。Lamport老爺爺還是叼叼的。。。。。。。
Raft容易實現在於它的描述是非常規範的，包括了所有的實現細節。如上面的人說的有如虛擬碼。而paxos的描述側重於理論，工程實現按照谷歌chubby論文中的說話，大家從paxos出現，寫著寫著，處理了n多實際中的細節之後，已經變成另外一個演算法了，這時候正確性已經無法得到理論的保證。所以它的實現非常難，因為一致性協議實非常精妙的。小細節上沒考慮好，整個協議的一致性就崩潰了。而且在Raft協議的博士論文CONSENSUS: BRIDGING THEORY AND PRACTICE，兩位作者手把手事無鉅細的教你如何用raft協議構建一個複製狀態機。我表示智商正常的大學生，都能看懂。我相信在未來一致性現在被提起來，肯定不是現在這樣，好難啊，實現更難。。。。會成為一種常用技術。