论文 《In Search of an Understandable Consensus Algorithm》，发表于2014年
相比于 Paxos，Raft 最大的特性就是易于理解。为了达到这个目标，Raft主要做了两方面的事情：
- 问题分解：把共识算法分为三个子问题，分别是领导者选举 (leaderlection)、日志复制 (log replication)、安全性 (safety)
- 状态简化：对算法做出一些限制，减少状态数量和可能产生的变动。
1 复制状态机
复制状态机 (Replicated state machine)：相同的初始状态 + 相同的输入 = 相同的结束状态。
多个节点上，从相同的初始状态开始，执行相同的一串命令，产生相同的最终状态。
在 Raft 中，leader 将客户端请求 (command) 封装到一个个日志实体 (log entry) 中，将这些 log entries 复制到所有 follower 节点，然后大家按相同顺序应用 log entries 中的 command，根据复制状态机的理论，大家的结束状态肯定是一致的。
我们使用共识算法，就是为了实现复制状态机。一个分布式场景下的各节点间，就是通过共识算法来保证命令序列的一致，从而始终保持它们的状态一致，从而实现高可用的。（投票选主是一种特殊的命令）
拓展：复制状态机作为一种抽象的思想，其的功能可以更加强大。比如两个副本一个采用行存储的数据结构存储数据，另一个采用列存储，只要它们初始数据相同，并持续发给他们相同的命令，那么同一时刻从两个副本中读取到的结果也是一样的，这就是一种 HTAP 的实现方法 (如 TiDB)。
2 状态简化
在任何时刻，每一个服务器节点都处于 Leader, Follower, Candidate 这三种状态之一。
相比于 Paxos，这一点极大简化了算法的实现，因为 Raft 只需考虑状态的切换，而不用像 Paxos 那样考虑状态之间的共存和互相影响。
- 任何一个节点启动时都处于 Follower 状态，若它察觉到集群中没有 Leader，就会将自己切换到 Candidate 状态。
- 在 Candidate 状态中进行一次或多次的选举，最终根据选举的结果决定将自己切换到 Leader 状态，或切换回 Follower 状态。
- 若选举成功，则切换到 Leader 状态并为客户端提供服务，若它在 Leader 状态的任期结束 or 自身发生宕机等问题，会切换回 Follower 状态，进行下一轮循环。
Raft 把时间分割成任意长度的 任期 (term)，任期用连续的整数标记，通常是 Int 型。
每一段任期从一次选举开始。在某些情况下，一次选举无法选出 Leader (没有任何一个节点的票数超过一半)，在这种情况下，这一任期会以没有 Leader 结束，如图中的 t3；一个新的任期 (包含一次新的选举) 会很快重新开始。Raft 保证在任意一个任期内，最多只有一个 Leader。
任期机制可以明确标识集群状态；且通过任期的比较可确认一台服务器历史的状态，
标签：任期,Follower,Leader,算法,Raft,日志,节点,RPC From： https://www.cnblogs.com/angelia-wang/p/17626546.html