Raft 共识算法1-Raft基础
Raft算法中译版地址：http://www.redisant.cn/etcd/contact
英原论文地址：https://raft.github.io/raft.pdf
Etcd Assistant 是一款 etcd 可视化管理软件，便捷高效地操作您的 etcd 集群；支持多种键的视图；管理租约、用户、角色和权限。
Raft 是一种用于管理第 2 节中描述的形式的复制日志的算法。@fig2 以压缩形式总结了该算法以供参考，@fig3 列出了该算法的关键属性； 这些图片中的元素将在本节的其余部分进行分段讨论。
Raft 通过首先选举一个领导者来实现共识，然后让领导者完全负责管理复制的日志。 领导者接受来自客户端的日志条目，将它们复制到其他服务器上，并告诉服务器何时可以安全地将日志条目应用到它们的状态机。 拥有领导者可以简化复制日志的管理。 例如，领导者可以在不咨询其他服务器的情况下决定在日志中放置新条目的位置，并且数据以简单的方式从领导者流向其他服务器。 领导者可能会失败或与其他服务器断开连接，在这种情况下会选举出新的领导者。
考虑到领导方法，Raft将共识问题分解为三个相对独立的子问题，在后面的小节中讨论：
- 领导者选举（Leader election）：当现有领导者失败时，必须选择新的领导者（第 5.2 节）。
- 日志复制（Log replication）：领导者必须接受来自客户端的日志条目并在集群中复制它们，强制其他日志与其自己的日志一致（第 5.3 节）。
- 安全性（Safety）：Raft 的关键安全属性是 @fig3 中的状态机安全属性：如果任何服务器已将特定日志条目应用到其状态机，则没有其他服务器可以对同一日志索引应用不同的命令。 5.4 节描述了 Raft 如何确保这个属性； 该解决方案涉及对第 5.2 节中描述的选举机制的额外限制。
Raft 保证这些属性中的每一个在任何时候都是真实的。 节号表示讨论每个属性的位置。
在介绍了共识算法之后，本节讨论可用性问题和计时在系统中的作用。
== Raft 基础
一个 Raft 集群包含多个服务器； 五是一个典型的数字，它允许系统容忍两次故障。 在任何给定时间，每个服务器都处于三种状态之一：领导者（leader）、追随者（follower）或候选者（candidate）。 在正常操作中，只有一个领导者，所有其他服务器都是追随者。 追随者是被动的：他们不自己发出请求，只是简单地响应领导者和候选者的请求。 领导者处理所有客户端请求（如果客户端请求跟随者，则跟随者将其重定向到领导者）。 第三种状态，候选者，用于选举新的领导者，如第 5.2 节所述。 @fig4 显示了状态及其转换； 下面讨论这种转换。
Raft 共识算法的简要总结（不包括成员变更和日志压缩）。 左上框中的服务器行为被描述为一组独立且重复触发的规则。 §5.2 等节号表示讨论特定功能的位置。 正式规范更准确地描述了该算法。
服务器状态。 追随者只响应来自其他服务器的请求。 如果一个追随者没有收到任何通讯，它就成为候选者并发起选举。 从整个集群中获得大多数选票的候选者成为新的领导者。 领导者通常会一直运作到失败为止。
Raft 将时间划分为任意长度的任期（term），如 @fig5 所示。任期用连续的整数编号。 每个任期都以选举开始，其中一名或多名候选者试图成为第 5.2 节所述的领导者。如果候选人赢得选举，那么它将在该任期的剩余时间内担任领导者。 在某些情况下，选举会导致分裂投票。 在这种情况下，任期将以没有领导者结束； 新任期（包括新选举）即将开始。 Raft 确保在给定任期内至多有一个领导者。
时间分为任期，每个任期从选举开始。 选举成功后，一个领导者管理集群直到任期结束。 有些选举失败，在这种情况下，任期结束时不会选择领导者。 可以在不同服务器上的不同时间观察到任期之间的转换。
不同的服务器可能会在不同的时间观察任期之间的转换，并且在某些情况下，服务器可能不会观察到选举甚至整个任期。 任期在 Raft 中充当逻辑时钟，它们允许服务器检测过时的信息，例如陈旧的领导者。 每个服务器存储一个当前任期号，它随时间单调增加。 每当服务器通信时，都会交换当前任期； 如果一个服务器的当前任期小于另一个，则它将其当前任期更新为较大的值。 如果候选者或领导者发现其任期已过期，则会立即恢复为追随者状态。 如果服务器收到带有陈旧任期号的请求，它会拒绝该请求。
Raft 服务器使用远程过程调用 (RPC) 进行通信，基本的共识算法只需要两种类型的 RPC。 RequestVote RPC 由候选者在选举期间发起（第 5.2 节），AppendEntries RPC 由领导者发起以复制日志条目并提供一种心跳形式（第 5.3 节）。 第 7 节添加了第三个 RPC，用于在服务器之间传输快照。 如果服务器没有及时收到响应，它们会重试 RPC，并且它们会并行发出 RPC 以获得最佳性能。