paxos与raft一致性协议

Published: by

1 一致性协议

一致性协议简单来说，是一种保障集群中所有机器上的数据达到一致的协议。最直观的最好理解的一致性协议，例如2PC、3PC，便是在做数据操作时，对集群中的所有机器同时做数据操作，仅当集群中的全部机器操作成功后，所有机器保证一致后，该数据操作才成功，否则只要有一台机器因为网络等其他原因导致数据操作失败，该数据操作就会失败，其他操作成功的机器也会全部进行数据回滚。 上述一致性协议虽然简单，但相对保守，且无法应对机器宕机、网络分区等故障问题。针对这种情况，paxos以及raft等一致性协议应运而生。 新一代的一致性协议有如下特点：

  • 采取过半原则：即当集群中大于一半的机器认同该数据操作，且数据操作成功后，该数据操作被集群认可（因为任何两个多数派集合中至少有一个成员是公共的）
  • 允许集群中出现部分机器不一致性，且时刻异步进行着机器之间数据的同步
  • 选举出leader协助集群中机器间数据的同步
  • 在出现机器宕机或者网络分区后，集群仍能正常工作，且保证集群一致性，同时当机器重启或者网络恢复后，也能保证集群一致性（利用持久化数据存储）

2 paxos以及raft介绍

下面是关于两种一致性协议的相关论文的详细讲解，这里就不再赘述

3 paxos以及raft异同（这里的paxos指的是Multi-Paxos）

3.1 相同点

  • 保障一致性：一个日志一旦被提交(得到多数派的赞成），就不会丢失，也不可能更改
  • 协议都使用一个唯一的整数作为标识符来标明leader的合法性，paxos叫做proposer-id，ZAB叫epoch，VR叫view，raft叫term。
  • 在同一个时刻，都只会存在一个合法的leader
  • 都是利用了同一个性质：两个多数派集合之间存在一个公共成员

3.2 差异点

1.理论与实践

  • paxos是理论上的一致性协议，虽然高效但是难以理解，难以在实际环境中实现，而一些paxos实现的一致性系统最终也产生一些偏离；
  • raft相对来说更加易于理解，且能很好的运用到实际中。

2.特点

  • paxos的特点在与从一个提案被提出到被接受分为两个阶段，第一个阶段去询问值，第二阶段根据询问的结果提出值。这两个阶段是无法分割的，两个阶段的每个细节都是精心设计的，相互关联，共同保障了协议的一致性
  • raft的特点在于使用算法分解，将协议分为领导选取、日志复制和安全性和减少状态（相对于Paxos，Raft 减少了非确定性的程度和服务器互相不一致的方式）

3.领导人的定位

  • paxos一致性协议中，没有领导人也能很好的工作，领导人选举仅仅是性能优化的手段，而且不是一致性所必须要求
  • raft一致性协议中，使用领导人选举作为一致性协议里必不可少的部分，并且将尽可能多的功能集中到了领导人身上。这样就简化了对日志复制的管理，使得算法更加容易理解。另外Raft 尽可能的减少了非领导人的功能。例如，Raft 中日志条目都遵循着从领导人发送给其他人这一个方向：附加条目 RPC 是向外发送的。在 VR 中，日志条目的流动是双向的（领导人可以在选举过程中接收日志）；这就导致了额外的机制和复杂性。

4.领导选取
都是用心跳机制来保证追随者实时感应到当前领导人，心跳丢失则表明领导人宕机

  • paxos协议未给领导选取提出独立的选举方案，针对领导人选举的独立的机制可以是任意强一致算法，当然也可以是paxos
  • raft通过选举超时(随机超时避免重复瓜分选票)来随机选取领导人，一台服务器最多能给一个候选人投票，同时为了保证安全性，宕机后的重新选举需要选举有效的含有所有被提交日志条目的机器：只有追随者机器上的日志和候选人机器上的日志一样新，追随者才能给候选人投票。

5.大多数一致性协议中仅使用leader主节点来集中处理事务请求

  • 使用paxos实现的一致性集群中Hyperspace 只有一台leader对外提供服务，其他机器只做数据备份
  • raft随机挑选一个服务器进行通信。如果第一次挑选的服务器不是领导人，那么那个服务器会拒绝客户端的请求并且提供它最近接收到的领导人的信息
  • zk集群中其他follower能够接受客户端请求，但是仅仅只是接受，然后把请求转发给leader

6.提案提交

  • paxos从提案被提出到提交需要经过两个阶段，多个提案可以并发同时完成第一个初审阶段，然后串行的按序完成阶段二，两个阶段leader都需要与集群中大部分机器完成通信，且需要集群中过半机器审核通过
  • raft从提案被提出到提交，是提案对应的日志从leader复制到集群中剩余机器的过程(通过rpc)，当该日志复制到集群中的过半机器后，该提案才能被提交。提案的提交具有强顺序性(串行完成提交)

7.日志条目

  • paxos有指令空缺，宕机后重新选举得到的领导人若在日志上有指令空缺，可通过二阶段提交从其它节点获取已经被提交的日志来填补指令空缺。
  • raft的日志条目具有强顺序性，强调日志的连续性，不允许出现空洞，领导人永远不会覆盖或者删除自己的日志，它只会增加条目，新选举出的Leader已经拥有全部的可以被提交的日志

4 混淆概念

raft以及paxos协议中针对每个提案，都有一个全局唯一的递增id，用来表示某个提案的唯一性，这里的提案可以对应为客户端的一次请求或者一条指令。而paxos协议中，每个提案对应一个编号以及提案值，这里的编号与上述的提案id不同，该编号的概念存在于某个提案A从提出到被决策的生命周期中(在该生命中期中自增且唯一)，也可以理解为某个提案A被提出者提出的字数编号，例如序列为100的提案被第一次提出、被第二次提出。