分布式Raft协议

http://thesecretlivesofdata.com/raft/

对于一个节点，就一个值达成一致意见很容易，那如果我们有多个节点，该如何达成共识呢？这就是分布式共识的问题。Raft是实现分布式共识的协议。

protocal overview

节点可以出现以下三种状态之一，the Follower State，the Candidate State，the Leader State。

所有节点都从follower状态开始，如果followers没有收到leader的信号，那么他们就可以成为candidate，然后candidate从其他节点请求选票，节点将以投票进行答复，如果candidate获取大多数节点的支持他将变成leader，这个过程称为leader election。

现在对系统的所有更改都通过leader进行，每个更改都作为节点日志中的一个条目添加，此日志条目未提交，因此不会更新节点的值，要提交条目，leader首先将其复制到followers节点，然后leader等待，直到大多数节点都编写了该条目。条目现在提交给leader，leader的状态更新，然后leader通知candidates条目已经提交，集群现在就系统状态达成共识，这个过程称为日志复制。

leader election

在Raft中有两个控制选举的超时设置，首先是election timeout，选举超时时间是追随者等待成为候选者的时间，选举超时设置为在150ms到300ms之间，选举超时后，追随者成为候选人，并开始一个新的选举任期…为自己投票…并向其他节点发送请求投票消息。如果接收节点在本阶段还没有投票，那么它将投票给候选人…然后节点重置election timeout。一旦候选人获得多数选票，他就成为领袖。

领导者开始向其追随者发送附加条目消息。这些消息按心跳超时指定的间隔发送。然后追随者响应每个追加条目消息。这个选举任期将持续到追随者停止心跳成为候选人为止。

让我们看以下重新选举的过程。节点C现在是第2任期的领导者。要求获得多数选票保证了每一届只能选出一名领导人。如果两个节点同时成为候选人，则可能出现分裂投票。让我们看一个分裂投票的例子…两个节点都开始为相同的任期进行选举。每个节点都先于其他节点到达一个跟随者节点。现在每个候选人都有两张选票，这一届不能再多收选票了（总共四个节点）。节点将等待新的选举，然后再试一次。节点C在第6届选举中获得多数选票，成为领袖。

log replication

一旦我们选出了一个领导者，我们需要将对系统的所有更改复制到所有节点。这是通过使用与心跳相同的追加条目消息来实现的。让我们来看看这个过程。首先，客户端向领导者发送一个更改。更改被附加到leader的日志中……然后在下一次心跳时将更改发送给追随者。一旦一个条目被大多数关注者认可，它就会被提交。…并向客户机发送响应。

Raft甚至可以在面对网络分区时保持一致。让我们添加一个分区来将A和B与C、D和E分开。由于我们的分裂，我们现在有了两位领导人。让我们添加另一个客户机，并尝试更新两个leader。一个客户机将尝试将节点B的值设置为“3”。节点B无法复制到大多数节点，因此其日志条目保持未提交状态。另一个客户机将尝试将节点C的值设置为“8”。这将会成功，因为它可以复制到大多数。现在让我们修复网络分区。节点B将看到更高的选举任期并下台。两个节点A和B都将回滚它们未提交的条目，并匹配新leader的日志。我们的日志现在在集群中是一致的。

注意与paxos算法的对比https://cyc2018.github.io/CS-Notes/#/notes/%E5%88%86%E5%B8%83%E5%BC%8F?id=%E4%BA%94%E3%80%81paxos