我会将Raft协议拆成四个部分去总结：
算法基础
选举和日志复制
安全性
节点变更
这是第一篇：《解读Raft（一 算法基础）》
什么是RAFT
分布式系统除了提升整个体统的性能外还有一个重要特征就是提高系统的可靠性。
提供可靠性可以理解为系统中一台或多台的机器故障不会使系统不可用（或者丢失数据）。
保证系统可靠性的关键就是多副本（即数据需要有备份），一旦有多副本，那么久面临多副本之间的一致性问题。
一致性算法正是用于解决分布式环境下多副本之间数据一致性的问题的。
业界最著名的一致性算法就是大名鼎鼎的Paxos（Chubby的作者曾说过：世上只有一种一致性算法，就是Paxos）。但Paxos是出了名的难懂，而Raft正是为了探索一种更易于理解的一致性算法而产生的。
Raft is a consensus algorithm for managing a replicated log.
Raft是一种管理复制日志的一致性算法。
它的首要设计目的就是易于理解，所以在选主的冲突处理等方式上它都选择了非常简单明了的解决方案。
Raft将一致性拆分为几个关键元素：
Leader选举
日志复制
安全性
Raft算法所有一致性算法都会涉及到状态机，而状态机保证系统从一个一致的状态开始，以相同的顺序执行一些列指令最终会达到另一个一致的状态。
以上是状态机的示意图。所有的节点以相同的顺序处理日志，那么最终x、y、z的值在多个节点中都是一致的。
算法基础角色
Raft通过选举Leader并由Leader节点负责管理日志复制来实现多副本的一致性。
在Raft中，节点有三种角色：
Leader：负责接收客户端的请求，将日志复制到其他节点并告知其他节点何时应用这些日志是安全的
Candidate：用于选举Leader的一种角色
Follower：负责响应来自Leader或者Candidate的请求
角色转换如下图所示：
所有节点初始状态都是Follower角色
超时时间内没有收到Leader的请求则转换为Candidate进行选举
Candidate收到大多数节点的选票则转换为Leader；发现Leader或者收到更高任期的请求则转换为Follower
Leader在收到更高任期的请求后转换为Follower
任期
Raft把时间切割为任意长度的任期，每个任期都有一个任期号，采用连续的整数。
每个任期都由一次选举开始，若选举失败则这个任期内没有Leader；如果选举出了Leader则这个任期内有Leader负责集群状态管理。
算法
状态
状态 所有节点上持久化的状态（在响应RPC请求之前变更且持久化的状态）currentTerm 服务器的任期，初始为0，递增
votedFor 在当前获得选票的候选人的 Id
log[] 日志条目集；每一个条目包含一个用户状态机执行的指令，和收到时的任期号
状态 所有节点上非持久化的状态
commitIndex 最大的已经被commit的日志的index
lastApplied 最大的已经被应用到状态机的index
状态 Leader节点上非持久化的状态（选举后重新初始化）
nextIndex[] 每个节点下一次应该接收的日志的index（初始化为Leader节点最后一个日志的Index + 1）
matchIndex[] 每个节点已经复制的日志的最大的索引（初始化为0，之后递增）
AppendEntries RPC