以下内容选自《深入理解分布式共识算法》一书，本书尚处于出版阶段，预计12月底出版，敬请关注。
两者相同之处：
（1） 都是共识算法，引用场景以及所解决的问题是一致的。
（2） 两者都采用“多数派”决策的思想进行协商。
（3） 两者都能友好的支持容错。
两者不同之处：
（1） Raft引入强Leader模型，规避了Basic Paxos的活锁的问题，Multi Paxos也仅仅降低了活锁的概率。
（2） 可用性，Raft引入强Leader，自然也导致了可用性的降低，在Leader选举期间，Raft将不可用。而Multi Paxos尽管也引入Leader，但是当Leader故障时，客户端访问另一个Leader即可，服务仍然是可用的。
（3） 协商性能，Basic Paxos加上提交操作（learn阶段或者comfirm请求）固定需要三个阶段（Prepare Accept Comfirm）才能提交一个提案，Multi Paxos在大多数情况下优化成两阶段（Accept Confirm）提交，但是达到两阶段提交的条件仍然是需要进行Prepare阶段。而Raft抽象出选举阶段（类比Prepare阶段），并通过心跳机制替代了提交阶段（类比Confirm），实现了真正一阶段提交。
（4） 日志连续性，Paxos允许乱序提交，同样允许存在空洞日志。而Raft通过Leader严格规定了日志项的连续性。换句话说，Paxos只保证了每个提案（日志项）达成共识的安全性，而Raft还保证了日志项的连续性，这一特性隐含了两个成员之间，相同日志索引且term相同，那么该日志项之前所有日志项也必然相同。
（4） 非事务请求，Multi Paxos尽管可以让Leader为每个提案（日志项）记录Confirm日志，但是对于未记录这一Confirm日志的提案，必须重新走一遍Paxos流程，才能知道该提案是否已达成共识。而Raft在日志连续的特性上，也要求了日志项提交的顺序。因此，Raft只需要明确committedIndex，即可推测在此之前所有日志项都已达成共识。
（5） 日志压缩，Paxos没有明确这一细节，但是在Paxos的工程实现中往往也会采用类似Raft提到的快照方式，进行日志压缩。
（6） 日志存储，Paxos并不要求每个成员拥有完整的数据，而Raft要求成员加入集群时先和Leader完成数据对齐。
（7） 崩溃恢复，因为Paxos的灵活性，这一点在Paxos中并没有那么重要，由于每个成员的对等性，成员崩溃后重启即可。而Raft成员崩溃后，再加入集群时，需要以Leader的数据为基准恢复数据，然后才可加入集群。
综上所述，两者各存优劣。
Paxos，更加灵活，可用性更好，但是协商效率更低（活锁、三阶段）
Raft，可用性降低，协商效率更好，另外Raft算法更加完整，对非事务请求、日志压缩、崩溃恢复等模块都有明确的实现标准。
