Raft算法由斯坦福大学的Diego Ongaro和John Ousterhout于2014年在论文《In Search of anUnderstandable Consensus Algorithm》中提出。Raft算法面向对多个决策达成一致的问题,分解了Leader选举、日志复制和安全方面的考虑,并通过约束减少了不确定性的状态空间。
典型的过程包括以下两个主要阶段:
- Leader选举:开始所有节点都是Follower,在随机超时发生后未收到来自Leader或Candidate消息,则转变角色为Candidate,提出选举请求。最近选举阶段(Term)中得票超过一半者被选为Leader;如果未选出,随机超时后进入新的阶段重试。
- Leader负责从客户端接收log,并分发到其他节点
- 同步日志:Leader会找到系统中日志最新的记录,并强制所有的Follower来刷新到这个记录,数据的同步是单向的。
- 此处日志并非是指输出消息,而是各种事件的发生记录。
共识算法以Raft为基础的区块链:
- Hyperledger Fabric
- Quorum : 企业级以太坊
- R3 Corda
Raft 概念
日志条目(Log entry)。 Raft 排序服务中的主要工作单元是一个“日志条目”,该项的完整序列称为“日志”。如果大多数成员(换句话说是一个法定人数)同意条目及其顺序,则我们认为条目是一致的,然后将日志复制到不同排序节点上。
共识者集合(Consenter set)。主动参与给定通道的共识机制并接收该通道的日志副本的排序节点。这可以是所有可用的节点(在单个集群中或在多个集群中为系统通道提供服务),也可以是这些节点的一个子集。
有限状态机(Finite-State Machine,FSM)。Raft 中的每个排序节点都有一个 FSM,它们共同用于确保各个排序节点中的日志序列是确定(以相同的顺序编写)。
法定人数(Quorum)。描述需要确认提案的最小同意人数。对于每个共识者集合,这是大多数节点。在具有五个节点的集群中,必须有三个节点可用,才能有一个法定人数。如果节点的法定人数因任何原因不可用,则排序服务集群对于通道上的读和写操作都不可用,并且不能提交任何新日志。
领导者(Leader)。这并不是一个新概念,正如我们所说,Kafka 也使用了领导者,但是在任何给定的时间,通道的共识者集合都选择一个节点作为领导者,这一点非常重要(我们稍后将在 Raft 中描述这是如何发生的)。领导者负责接收新的日志条目,将它们复制到跟随者的排序节点,并在认为提交了某个条目时进行管理。这不是一种特殊类型的排序节点。它只是排序节点在某些时候可能扮演的角色,而不是由客观环境决定的其他角色。
跟随者(Follower)。再次强调,这不是一个新概念,但是理解跟随者的关键是跟随者从领导者那里接收日志并复制它们,确保日志保持一致。我们将在关于领导者选举的部分中看到,跟随者也会收到来自领导者的“心跳”消息。如果领导者在一段可配置的时间内停止发送这些消息,跟随者将发起一次领导者选举,它们中的一个将当选为新的领导者。
Raft 是如何选举领导者的
尽管选举领导者的过程发生在排序节点的内部过程中,但是值得注意一下这个过程是如何工作的。
节点总是处于以下三种状态之一:跟随者、候选人或领导者。所有节点最初都是作为跟随者开始的。在这种状态下,他们可以接受来自领导者的日志条目(如果其中一个已经当选),或者为领导者投票。如果在一段时间内没有接收到日志条目或心跳(例如,5秒),节点将自己提升到候选状态。在候选状态中,节点从其他节点请求选票。如果候选人获得法定人数的选票,那么他就被提升为领导者。领导者必须接受新的日志条目并将其复制到跟随者。
什么时候做 commit 操作?
(1)Client向Leader提交指令(如:SET 5),Leader收到命令后,将命令追加到本地日志中。此时,这个命令处于“uncomitted”状态,复制状态机不会执行该命令。
(2)然后,Leader将命令(SET 5)并发复制给其他节点,并等待其他其他节点将命令写入到日志中,如果此时有些节点失败或者比较慢,Leader节点会一直重试,知道所有节点都保存了命令到日志中。之后Leader节点就提交命令(即被状态机执行命令,这里是:SET 5),并将结果返回给Client节点。
(3)Leader节点在提交命令后,下一次的心跳包中就带有通知其他节点提交命令的消息,其他节点收到Leader的消息后,就将命令应用到状态机中(State Machine),最终每个节点的日志都保持了一致性。