4.6.2　Raft算法

Paxos算法虽然给出了共识设计，但并没有讨论太多实现细节，也并不重视工程上的优化，因此后来在学术界和工程界出现了一些改进方案，包括Fast Paxos、Multi-Paxos，Zookeeper Atomic Broadcast（ZAB）和Raft等。这些算法重点在于改进执行效率和可实现性。

其中，Raft算法由斯坦福大学的Diego Ongaro和John Ousterhout于2014年在论文“In Search of an Understandable Consensus Algorithm”中提出，该算法基于Multi-Paxos算法进行重新简化设计和实现，提高了工程实践性。Raft算法的主要设计思想与ZAB类似，通过先选出领导节点来简化流程和提高效率。实现上解耦了领导者选举、日志复制和安全方面的需求，并通过约束减少了不确定性的状态空间。

Raft算法包括三种角色：领导者（leader）、候选者（candidate）和跟随者（follower）。每个任期内选举一个全局的领导者，领导者角色十分关键，决定日志（log）的提交。每个日志都会路由到领导者，并且只能由领导者向跟随者单向复制。

典型的过程包括两个主要阶段：

●领导者选举。开始所有节点都是跟随者，在随机超时发生后若未收到来自领导者或候选者消息，则转变角色为候选者（中间状态），提出选举请求。最近选举阶段（term）中得票超过一半者被选为领导者；如果未选出领导者，随机超时后进入新的阶段重试。领导者负责从客户端接收请求，并分发到其他节点。

●同步日志。领导者会决定系统中最新的日志记录，并强制所有的跟随者刷新到这个记录，数据的同步是单向的，确保所有节点看到的视图一致。

此外，领导者会定期向所有跟随者发送心跳消息，如果跟随者发现心跳消息超时未收到，则可以认为领导者已经下线，尝试发起新的选举过程。