分布式一致性算法对比 - Raft VS Paxos

分布式一致性算法对比 - Raft VS Paxos

ACID & CAP,分布式一致性,两类一致性算法

  • 数据库 ACID 的一致性,又称之为内部一致性
事务开始前和结束后,数据库的完整性约束没有被破坏 。比如 A 向 B 转账,不可能 A 扣了钱,B 却没收到。
  • 分布式 CAP 的一致性,也称之为外部一致性
在分布式系统中,写操作后再读,就必须返回写入的值。比如分布式数据库A、B、C,A 中写入数据 hello,写完马上读 B 和 C,就一定要读出 hello,读出来我们就称之为符合一致性
  • 两者区别,内部一致性注重于事务前后数据的完整性,而外部一致性则注重于读写数据值是否一致


ACID事务一致性

  • 2PC、3PC协议使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的算法。
  • ACID 一致性是指分布式事务的ACID中的C, 一致性,在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这里的一致性是指逻辑上的一致性,即所有操作是符合现实当中的期望的, 比如丢失修改、不可重复读、脏读、幻读
  • 进阶产品:Percolator 、Spanner、 CockroachDB 、TiDB


多副本的一致性

  • 一致性协议大多使用了Quorum机制,但仅仅有Quorum(R+W>N)机制是保证不了一致性的
  • Paxos Raft Zab 协议用于保证同一个数据分片的多个副本之间的数据一致性。当这些副本分布到不同的数据中心时,这个需求尤其强烈。通过Paxos算法,是可以解决外部的一致性, 本文讨论的一致性正是的一种
  • 进阶产品:TiKV, Etcd, ZooKeeper


Paxos算法

  • Paxos算法莱斯利·兰伯特(英语:Leslie Lamport,LaTeX中的“La”)于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。
  • Paxos算法如需解锁这个技能,请移步原作者论文跟下面视频

basic paxos

basic paxos的协议更复杂,且相对效率较低。所以现在所有的和paxos有关的协议,一定是基于multi-paxos来实现的。先来看basic paxos的角色

首先将议员的角色分为 proposers,acceptors,和 learners(允许身兼数职)。proposers 提出提案,提案信息包括提案编号和提议的 value;acceptor 收到提案后可以接受(accept)提案,若提案获得多数派(majority)的 acceptors 的接受,则称该提案被批准(chosen);learners 只能“学习”被批准的提案。

multi-paxos

Paxos的典型部署需要一组连续的被接受的值(value),作为应用到一个分布式状态机的一组命令。如果每个命令都通过一个Basic Paxos算法实例来达到一致,会产生大量开销。如果Leader是相对稳定不变的,第1阶段就变得不必要。 这样,系统可以在接下来的Paxos算法实例中,跳过的第1阶段,直接使用同样的Leader。

为了实现这一目的,在同一个Leader执行每轮Paxos算法时,提案编号 I 每次递增一个值,并与每个值一起发送。Multi-Paxos在没有故障发生时,将消息延迟(从propose阶段到learn阶段)从4次延迟降低为2次延迟
使用同一个的提案编号计数器
因为执行实例使用的都是同一个的提案编号计数器,这样它承诺不再通过小于 n 的提案,应该可以应用在所有执行实例上,而不影响正确性
prepare阶段,acceptor承诺不再回复小于n的提案。这是acceptor的职责。只要满足这个条件,paxos正确性就得到了保证。


Raft

由于Paxos难以理解,所以才有了Raft

Raft 以可理解性和易于实现为目标

Leader选举(Leader election)
日志同步(Log replication)
安全性(Safety)
日志压缩(Log compaction)
成员变更(Membership change)


Raft VS multi-paxos

multi-paxos和raft,在选定了leader状态下的行为模式一模一样

raft仅允许日志最多的节点当选为leader,而multi-paxos则相反,任意节点都可以当选leader

raft不允许日志的空洞,这也是为了比较方便和拉平两个节点的日志方便,而multi-paxos则允许日志出现空洞

在Multi-paxos中,任何一个 leader election 算法都可以给 multi-paxos 使用,这里不详细描述了。多个leader并不会破坏算法正确性

1.Paxosstore相当于使用上一次Paxos算法的结果来约定一个leader
2.PhxPaxos使用Paxos算法来确定一个带租约的Master


采用租约强主模式存在主切换空隙,可能会拒绝服务。主失效时,整个系统也会失效,直到新的主产生。微信Paxosstore采用Paxos考量也是基于这一点:采用无租约的方式使得系统在保证强一致性的前提下达到最大的可用性;相对而言,租约的方式必然引入主备切换导致的不可用

它们能用来做什么

分布式锁,分布式锁服务,比如Zookeeper
领导人选举
database replication, log replication等
naming service, 如大型系统内部通常存在多个接口服务相互调用
config配置管理
号码分配
分布式存储系统,比如分布式消息队列、分布式块系统、分布式文件系统、分布式表格系统等
高可靠元信息管理,比如各类Master模块的HA


  • 一致性的情况下,它们不能用来提高性能。相反,它们的性能比单机版本往往要更差
  • 基于非拜占庭将军问题(Leslie Lamport
  • Raft不支持乱序提交,如果状态机无关可以分为多个Raft Group解决这个问题
  • batching和piplining
  • 乱序提交与空洞等问题并不是明显的优势或劣势,这属于特性。Raft要需要的时候,通过多Raft Group将无关状态机分到不同的Raft Group来优化即可
  • 其他Paxos变种,如Fast Paxos, Epaxos只是优化减少部分步骤。实际PhxPaxos, Paxosstore都对这些情况做进一步优化,并不会存在更优秀的情况
paxosstore架构github.com


The Part-Time Parliamentresearch.microsoft.com
https://lamport.azurewebsites.net/pubs/paxos-simple.pdflamport.azurewebsites.net
优酷视频v.youku.com


发布于 2019-10-27