Raft

Raft

Raft可以在高效的解决分布式系统中各个节点日志内容一致性问题的同时,也使得集群具备一定的容错能力。即使集群中出现部分节点故障、网络故障等问题,仍可保证其余大多数节点正确的步进。甚至当更多的节点(一般来说超过集群节点总数的一半)出现故障而导致集群不可用时,依然可以保证节点中的数据不会出现错误的结果。

论文

  1. In Search of an Understandable Consensus Algorithm (Extended Version)
  2. CONSENSUS: BRIDGING THEORY AND PRACTICE

raft算法

3个角色

Raft选举方法

日志复制

当接Leader收到客户端的日志(事务请求)后先把该日志追加到本地的Log中,然后通过heartbeat把该Entry同步给其他Follower,Follower接收到日志后记录日志然后向Leader发送ACK,当Leader收到大多数(n/2+1)Follower的ACK信息后将该日志设置为已提交并追加到本地磁盘中,通知客户端并在下个heartbeat中Leader将通知所有的Follower将该日志存储在自己的本地磁盘中。

安全性

安全性是用于保证每个节点都执行相同序列的安全机制,如当某个Follower在当前Leader commit Log时变得不可用了,稍后可能该Follower又会倍选举为Leader,这时新Leader可能会用新的Log覆盖先前已committed的Log,这就是导致节点执行不同序列;Safety就是用于保证选举出来的Leader一定包含先前 commited Log的机制;

失效处理

集群扩容

集群中节点的变更,要么是故障,要么是业务需求扩容/缩容。 Raft使用联合一致性阶段(joint consensus)来作为过渡阶段实现配置从旧到新的变化。

集群中配置状态的转换:

与Paxos对比

raft中发送的请求(日志项)必须是连续的,而paxos中使可以并发的(就是说paxos可以同时发送日志项2,3,3不需要等待2处理完才能发送,但在状态集中日志顺序还是不变的,有点类似于TCP中的数据发送) raft选主是有限制的, 必须有最新,最全的日志节点才可以当选. 而multi-paxos中是随意的。所以raft 可以看成是简化版本的multi-paxos(这里multi-paxos因为允许并发的写日志,因此不存在一个最新,最全的日志节点,因此只能这么做。这样带来的麻烦就是选主以后, 需要将主里面没有的日志给补全, 并执行commit 过程) 根据上面可以看出,raft更加的简单,paxos支持日志并发,更加的灵活。

Raft常见问答一览

以上转自http://www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle

参考文档

Comments

comments powered by Disqus