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里的图，大家自己琢磨吧。
drdr xp
，要了几天饱饭就不记得西北风啥味了
bxeldor、知乎用户、知乎用户 等人赞同
raft集成了成员管理，这个地方是唯一比paxos精妙的地方。里面的正确性的保证很有趣。
raft增加了committed状态，如同 @郁白 所说，这个在paxos里没有具体说。raft可以看成multiple paxos的一个实现。
raft给你的基本是伪代码的描述了，方便实现。学理论的话还是paxos好。
大部分场景都可以用raft实现，paxos应该没什么能直接使用的场景，太理论了……
raft增加了committed状态，如同 @郁白 所说，这个在paxos里没有具体说。raft可以看成multiple paxos的一个实现。
raft给你的基本是伪代码的描述了，方便实现。学理论的话还是paxos好。
大部分场景都可以用raft实现，paxos应该没什么能直接使用的场景，太理论了……
本质上来讲，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协议构建一个复制状态机。我表示智商正常的大学生，都能看懂。我相信在未来一致性现在被提起来，肯定不是现在这样，好难啊，实现更难。。。。会成为一种常用技术。
raft优势：简单，好懂，易实现。
场景没什么太大区别.
------------------------------------------------------------
RAFT的简单有好几个方面，比如：
1）协议上的简化（最后主要RPC只有两个，其他协议的二阶段、三阶段也都变成 /看起来像是一阶段）；
2）TERM概念的强化（看起来似乎PAXOS也有重选LEADER的机制，但是强化概念，并增加一个TERM内有一个一个LEADER、ENTRY与TERM相关的属性等都大大简化了流程）；
3）LOG只会从LEADER到FOLLOWER单向同步（实现一下你会发现这真的减少好多问题，代码量都少了好多）；
4）……TODO（先挖坑，回头再填）
但是本质上，又可以把RAFT和PAXOS对应起来（看有没精力后边再填坑……TODO）
场景没什么太大区别.
------------------------------------------------------------
RAFT的简单有好几个方面，比如：
1）协议上的简化（最后主要RPC只有两个，其他协议的二阶段、三阶段也都变成 /看起来像是一阶段）；
2）TERM概念的强化（看起来似乎PAXOS也有重选LEADER的机制，但是强化概念，并增加一个TERM内有一个一个LEADER、ENTRY与TERM相关的属性等都大大简化了流程）；
3）LOG只会从LEADER到FOLLOWER单向同步（实现一下你会发现这真的减少好多问题，代码量都少了好多）；
4）……TODO（先挖坑，回头再填）
但是本质上，又可以把RAFT和PAXOS对应起来（看有没精力后边再填坑……TODO）
http://www.zhihu.com/question/36648084