Raft基本理论

本文以问答的方式，总结Raft相关知识。
所有信息来源于Raft论文

第一章

1.为什么要寻找一个新的一致性算法？

Unfortunately, Paxos has two significant drawbacks.
The first drawback is that Paxos is exceptionally difficult to understand.
The second problem with Paxos is that it does not provide a good foundation for building practical implementations.
（1）paxos算法比较难理解，即便有很多人尝试着用更容易理解的方式去解释它。education
（2）paxos没有为实际实现打好基础，有许多细节问题没有公布，或者业内没有形成一致意见，以致于在实际构建和部署时，需要做复杂的变更。practice
Because of these problems, we concluded that Paxos does not provide a good foundation either
for system building or for education.
Given the importance of consensus in large-scale software systems, we decided to see if we could design an alternative consensus algorithm with better properties than Paxos. Raft is the result of that experiment.

第二章

1.通常使用什么方法来解决分布式系统的容错问题？举例？

复制状态机
Replicated state machines are used to solve a variety of fault tolerance problems in distributed systems, as described in Section 2.2.
Many large-scale storage systems that have a single cluster leader, such as GFS [30], HDFS [105], and RAMCloud [90], use this approach.

2.复制状态机如何实现？架构？

使用replicated log实现
Replicated state machines are typically implemented using a replicated log, as shown in Figure 2.1.

集群中的每台服务器上都有复制状态机，每个状态机按同样的顺序执行一串相同的命令，从而每个状态机的状态也是一致的。
一致性模块接收客户端命令并将其写入到日志中，每个服务器中的一致性模块互相通信，保证每台服务器上写入日志的命令内容和顺序相同

第三章 Basic Raft algorithm

1.如何实现易懂性？

（1）将单个复杂的问题分解为若干可以独立解决，解释，理解的问题。–问题分解
we divided problems into separate pieces that could be solved, explained, and understood relatively independently.
（2）第二种方法是通过减少需要考虑的情况的数量来简化状态空间，使系统更加连贯并尽可能消除不确定性。–状态简化
Our second approach was to simplify the state space by reducing the number of states to consider, making the system more coherent and eliminating nondeterminism where possible.

2.简单说一下Raft。概述。

Raft实现一致性的方法是：首先选出一个server作为leader，让leader来全权负责replicate log的管理（利用leader来简化replicated log的管理）。leader从客户端接收日志条目，复制到其他服务器，并且告诉其他服务器什么时候将日志应用到状态机上才是安全的。数据流动的方向只会是从leader流向其他服务器。
leader在决定将日志条目放在日志的哪个位置的时候，不需要和其他服务器商议。

有了在系统中使用leader的这个前提，Raft将一致性问题分解为三个相对独立的子问题：
（1）Leader election
（2）Log replication
（3）Safety。（leader变更时的安全性）

（1）leader election ————————- term

At any given time each server is in one of three states: leader, follower, or candidate.

通常只有一个leader，其余的都是follower。
leader处理所有客户端请求，follower将来自客户端的请求转发到leader。
follwoer只响应来自leader和candidate的请求。（passive）
candidate用来选举新的leader。

Raft将时间分成任意长度的任期（term，连续的整数编号），每个term开始的时候都要进行选举（elect），一个或多个候选者参与选举，试图成为leader，赢得选举的server在这个任期的剩余时间内作为leader。某些情况下可能无法成功选出一个leader，所以一个term内最多只有一个leader。
每个server都保存了当前term的数值，server之间通信时，会带上term的信息。

我们选择在Raft中将通信结构化为RPC，以简化其通信模式。
server使用RPC进行通信，基本的一致性算法只需要两种RPC（RequestVote RPC和AppendEntries RPC），后续将要介绍的leader的资格转换会使用其他的RPC。
RequestVote RPC：候选者在elect期间发出
AppendEntries RPC：leader发出的，用于复制日志条目，和提供心跳机制。

Raft uses a heartbeat mechanism to trigger leader election.
Raft使用心跳机制触发leader选举：
server刚启动时，先以follower作为开始。leader会周期性的发送心跳信息到各个follower，维护自己作为leader的地位。如果follower从leader或者candidate收到RPC，则保持follower状态。如果follower在election timeout时间内没有收到心跳信息，则认为没有leader了，follower发起新的选举。

follower发起选举的过程：
增加当前term –> 转换为candidate状态 –> 投票给自己 –> 发送RequestVote RPC给集群中其他服务器，会有三种结果：
（a）赢得选举，成为leader。（相同的term内获得集群中多数选票）（在同一个term中，每个服务器最多只会投票给一个candidate，先收到谁的投票请求，就投票给谁。这保证了在同一个term中最多只有一个leader。当candidate成为leader之后会向集群中其他server发送信息，确保自己的leader地位，避免其他server发起新的选举。）safety
（b）收到其他server以leader身份发来的信息，转变为follower。如果收到其他server作为leader发来的AppendEntries RPC信息，该信息中包含的term不小于自己的term，则承认其他server的leader地位，并转换为follower状态。如果收到的RPC信息中的term小于自己的term，则拒绝该RPC信息，保持candidate状态。（收到其他candidate发来的term大于自己的RequestVote RPC信息应该也会转变为follower吧？？？否则新一轮竞选的时候，还是无法选出leader）
（c）在election timeout时间内，集群中没有选出新的leader。多个server同时转变为candidate发起竞选，可能没有一个candidate能赢得多数选票，则没有新的leader选出来。这种情况下，每个candidate在elect timeout之后增加自己的term，发起新一轮的竞选。（如果没有额外的机制，这种分裂选票导致的无法选出leader的情况可能会不断重复，解决办法是，每个candidate的elect timeout不相同，取150-300ms中的随机数，这样每个candidate超时的时间不相同，发起竞选的时间就会不同，最先发起竞选的很可能成为leader，在其他candidate超时之前，他就已经赢得选举并且发送心跳信息了。网络通信耗时一般在1ms以内，随机数之间的时间差距，提供了充足的选举时间。分裂选票的情况很少出现，并且能快速解决。）（曾经尝试使用给每个server指定一个rank的方式来减少split vote，但是遇到了很多问题，没成功。）We used randomization to simplify the Raft leader election algorithm.（看到的Raft资料中有考虑使用rank的方式）

（2）Log replication ————— term & index

leader选出来之后，就开始处理客户端请求，客户端请求中包含需要执行的命令，leader将命令作为日志条目追加到日志中，然后并行发送给集群中的其他服务器（AppendEntries RPC），日志被安全的复制到其他服务器之后（判断条件？超过半数响应），leader将日志应用到状态机上，然后返回结果给客户端。如果有follower crash，或者运行慢，或者网络丢包的情况，leader会不断发送日志条目直到所