raft算法_Raft算法与实现

强一致性、高可用的存储组件是构建现代分布式系统的必要条件，广泛应用于注册中心、配置中心等平台设施中，分布式锁、协调器等等各类场景需求也有相关需求，在该领域有众多知名的开源组件，如etcd、zookeeper、Tikv等等。

共识算法是实现这类组件的关键算法。简单的说共识算法是协调多个节点达成共识的算法，这是构建高可用系统的基石。大部分典型的共识算法都是基于状态复制机来实现的，每个节点都有一个状态机以及一个日志，状态机用于保持一个共识的结果，这样客户端只要连接到任意节点上就可以获取到状态机的内容。而日志是用于保证输入的顺序，只要保证所有日志的提交顺序是一致的则可以保证各个节点的状态机是一直的。

共识算法有很多种，就我知道的有paxos、raft、zab、VR(Viewstamped Replication)等等。paxos以复杂和难以理解著称，通常来说raft是更容易理解的算法，也更容易在工程实践中采用，而且在性能上并没有损失，所以下面我们讨论一下raft的的基本原理和一些要点。 下面的文章主要基于raft的paper整理而成，相关资料可以从https://raft.github.io/获取。

raft算法原理与实现

raft最主要的贡献在于2点，一个是将复杂的分布式算法分解成几个独立的解释和解决的子问题，并且。将状态进行简化，最小程度的考虑必要的问题，这些工作使得raft共识算法成为一种有效的新的方法。广泛的应用于教学和工程实践中： raft算法的基本流程是首先选举出leader，由leader完成日志复刻的功能。如果follower仅仅接受来自leader的日志复制请求，而没有反向的日志流。raft的leader是一个强大的leader。当follower的日志和leader的日志不同时会强制覆盖自己的日志给follower。当leader宕机时，会选出新的leader，来继续任务。

raft讲上述的基本流程拆分成3个部分：选主过程(leader election)、日志复制(log replication)、安全性(safety)加上成员变更(membership changing)。不过在具体讨论这4个部分的内容的过程中我们还是简单的讨论下raft的一些关键模型和概念：

角色和周期

节点的角色

raft的典型节点可以分为3种：follower、candidate、leader。

• follower：所有节点在初始化之后都是follower。follower的职责仅仅是接受来自leader的复制日志的请求，或是在leader宕机时(未在超时时间内接受到心跳信息)成candidate尝试成为leader，亦或是接受到candidate的投票请求时响应改请求
• candidate：当leader宕机时，超过超时时间的follower会转变成candidate，candidater会向集群内的所有机器发送请求投票给自己的请求。
• leader：leader负责日志复制的过程。并且将自己的日志通过心跳发送给其他机器同步日志，所有来自客户端的写请求都会由leader处理，在过半数的机器提交之后就可以返回成功标志给客户端。

任期周期

raft工作流程由一个个任期组成，通常来说