分布式一致性
Paxos
Multi-Paxos
Raft
EPaxos
对比分析
1 可理解性
众所周知,Paxos是出了名的晦涩难懂,不仅难以理解,更难以实现。而Raft则以可理解性和易于实现为目标,Raft的提出大大降低了使用分布式一致性的门槛,将分布式一致性变的大众化、平民化,因此当Raft提出之后,迅速得到青睐,极大地推动了分布式一致性的工程应用。
EPaxos的提出比Raft还早,但却长期无人问津,很大一个原因就是EPaxos实在是难以理解。EPaxos基于Paxos,但却比Paxos更难以理解,大大地阻碍了EPaxos的工程应用。不过,是金子总会发光的,EPaxos因着它独特的优势,终于被人们发现,具有广阔的前景。
2 效率
从Paxos到Raft再到EPaxos,效率有没有提升呢?我们主要从负载均衡、消息复杂度、Pipeline以及并发处理几个方面来对比Multi-Paxos、Raft和EPaxos。
负载均衡
Multi-Paxos和Raft的Leader负载更高,各副本之间负载不均衡,Leader容易成为瓶颈,而EPaxos无需Leader,各副本之间负载完全均衡。
消息复杂度
Multi-Paxos和Raft选举出Leader之后,正常只需要一次网络来回就可以提交一条日志,但Multi-Paxos需要额外的异步Commit消息提交,Raft只需要推进本地的commit index,不使用额外的消息,EPaxos根据日志冲突情况需要一次或两次网络来回。因此消息复杂度,Raft最低,Paxos其次,EPaxos最高。
Pipeline
我们将Pipeline分为顺序Pipeline和乱序Pipeline。Multi-Paxos和EPaxos支持乱序Pipeline,Raft因为日志连续性假设,只支持顺序Pipeline。但Raft也可以实现乱序Pipeline,只需要在Leader上给每个Follower维护一个类似于TCP的滑动窗口,对应每个Follower上维护一个接收窗口,允许窗口里面的日志不连续,窗口外面是已经连续的日志,日志一旦连续则向前滑动窗口,窗口里面可乱序Pipeline。
并发处理
Multi-Paxos沿用Paxos的策略,一旦发现并发冲突则回退重试,直到成功;Raft则使用强Leader来避免并发冲突,Follwer不与Leader竞争,避免了并发冲突;EPaxos则直面并发冲突问题,将冲突依赖也做为一致性问题对待,解决并发冲突。Paxos是冲突回退,Raft是冲突避免,EPaxos是冲突解决。Paxos和Raft的日志都是线性的,而EPaxos的日志是图状的,因此EPaxos的并行性更好,吞吐量也更高。
3 可用性
EPaxos任意副本均可提供服务,某个副本不可用了可立即切换到其它副本,副本失效对可用性的影响微乎其微;而Multi-Paxos和Raft均依赖Leader,Leader不可用了需要重新选举Leader,在新Leader未选举出来之前服务不可用。显然EPaxos的可用性比Multi-Paxos和Raft更好,但Multi-Paxos和Raft比谁的可用性更好呢。
Raft是强Leader,Follower必须等旧Leader的Lease到期后才能发起选举,Multi-Paxos是弱Leader,Follwer可以随时竞选Leader,虽然会对效率造成一定影响,但在Leader失效的时候能更快的恢复服务,因此Multi-Paxos比Raft可用性更好。
4 适用场景
EPaxos更适用于跨AZ跨地域场景,对可用性要求极高的场景,Leader容易形成瓶颈的场景。Multi-Paxos和Raft本身非常相似,适用场景也类似,适用于内网场景,一般的高可用场景,Leader不容易形成瓶颈的场景。