Part 04：Raft论文翻译-《CONSENSUS: BRIDGING THEORY AND PRACTICE》（基础Raft-算法基础）

3.3 Raft Basic（Raft算法基础）

Raft集群包含若干个服务器，5是一个典型的数字，它允许系统有2个服务器出现故障。在任何给定的时间里，每个服务器都处于三种状态中的一种：Leader、Follower或Candidate。在正常情况下，只有一个Leader，所有其他服务器都是Follower。Follower是被动的：他们自己不发出任何请求，而只是回应来自Leader和Candidate的请求。Leader处理所有客户端请求（如果客户联系Follower，Follower将其重定向到Leader）。第三个状态，Candidate，用于选举如第3.4节所述的新Leader。图3.3显示了状态及其转换；下面将讨论这些转换。

image.png

Raft算法中将时间分为任意长度，如图3.4所示。term用连续的整数进行编号。每个term都以一次选举开始，其中一个或多个Candidate试图成为Leader。如果一个Candidate赢得了选举，那么它将在剩余的term内担任Leader。在某些情况下，选举将导致分裂的投票。这种情况下，term结束时没有Leader；新term（新选举）将很快开始。Raft算法确保在给定期限内最多有一个Leader。

image.png

不同的服务器可能会在不同的时间观察到term之间的转换，在某些情况下，服务器可能不会观察到一个选举，甚至是整个term内都没有观察到。term作为Raft中的逻辑时钟（用于确定顺序的一种方法），它们允许服务器检测过时的信息，如陈旧的Leader。每个服务器存储一个当前的term，它随时间单调地增加。每当服务器通信时，就会交换当前term；如果一个服务器的当前term小于另一个服务器当前的term，则它将其当前term更新为较大的值。如果Leader或Candidate发现其term已过期，它将立即恢复到Follower状态。如果服务器收到一个陈旧term的请求，则它将拒绝该请求。

Raft服务器使用远程过程调用(RPC)进行通信，而基本的共识算法在服务器之间只需要两种类型的RPC。RequestVote RPC由Candidate在选举期间发起（第3.4节），AppendEntries RPC由Leader发起，以复制日志条目并提供一种心跳形式（第3.5节）。Leader转移（第3.10节）和后续章节中描述的机制引入了核心共识算法中这两个机制之外的额外RPC。

我们选择在Raft中通信以RPC调用形式进行，以简化其通信模式。每个请求类型都有一个相应的响应类型，它也作为请求的确认。Raft假设RPC请求和响应可能在网络中丢失；如果RPC没有及时收到响应，请求者有责任重试它。服务器并行发布RPC以获得最佳性能，而Raft并不假设网络保留RPC之间的顺序。

<< 上一章：Raft算法的目的
下一章：Raft算法基础 >>