【课程报告九】精度In Search of an Understandable Consensus Algorithm（1）

这篇文章从第五节开始介绍raft算法，前4节列了一些分布式原则和特性。我在阅读时更加关注raft算法本身，一些文中列出的特性罗列如下：

（1）第一节 raft 相对于现有共识算法的新特性：

强领导（Strong leader）:Raft使用比其他共识算法更强的领导形式。例如，日志条目只从leader服务器流向其他服务器。这简化了对复制日志的管理，并使Raft更容易理解。

领袖选举（Leader election）:Raft使用随机计时器来选举领袖。这只在任何共识算法已经需要的心跳机制上增加了少量的机制，同时可以简单而快速地解决冲突。

成员变更（Membership changes）:Raft在集群中更改服务器集合的机制使用了一种新的联合共识方法，在过渡期间，两种不同配置的大多数会重叠。这允许集群在配置更改期间继续正常运行。

（2）第二节 实际系统的共识算法通常具有的特性：

确保在所有非拜占庭条件下的安全性(从不返回错误结果)，包括网络延迟、分区、包丢失、重复和重新排序。

只要大多数服务器都是可操作的，并且能够与其他服务器和客户端通信，就具有完整的功能(可用)。因此，一个典型的5台服务器的集群可以容忍任意两台服务器的故障。假定服务器通过停止而失败;稍后可能从稳定存储上的状态恢复并重新加入集群。

不依赖于时间来确保日志的一致性:错误的时钟和极端的消息延迟，在最坏的情况下，会导致可用性问题。

在一般情况下，只要集群的大多数响应了一轮远程过程调用，命令就可以完成;少数速度较慢的服务器不需要影响整体系统性能。

文章从第五节开始描述raft算法

在5.1中 raft basics将节点的状态分为：领导者leader、追随者 follower、候选者candidate

节点将处于这三者之一。在正常操作中，只有一个领导者，所有其他节点都是追随者。追随者是被动的:他们自己不发出请求，只是回应领导和候选人的请求。领导者处理所有的客户请求(如果客户联系了追随者，那么追随者会将其重定向给领导者)。第三个状态：候选人，用于选举新的领导人。

文章的图4表明：跟随者只接收领导者和候选者的信息。当领导者发现更新的请求，领导者给跟随者发送信息。当候选者发现确定的领导者或新的term，在某个时刻，候选者发起新的选举，跟随者参与选举 。

raft将时间划分为多个长度任意的 terms 用于节点的状态转换。

文章的图5表明：每个term开始于选举（一个或多个候选者发起） ，只有一个候选者会成为新的领导者并在这轮term中回复请求。如果出现平票，则这轮term失效，新的term会迅速开始。

term会像paxos一样有一个数字标记，这个数字随term的轮数逐渐增加。节点会拒绝那些数字标记不是最新的term。

最后提到RPCs（Raft servers communicate）可以简单理解为节点之间通信的方式。

5.2节中描述了领袖选举（Leader election）如何进行。

Raft使用心跳机制来触发领导人选举。节点启动时处于跟随者状态，只要一直接收到领导者或候选者的RPCs，则一直保持跟随者状态。领导者定期向所有追随者发送心跳(AppendEntries rpc，不携带日志条目，即不包含请求内容的信息)。如果一个追随者在一段称为   ‘选举超时’   的时间内没有收到任何通信，那么它会假设没有可行的领导者，并开始选举以选择一个新的领导者。

开始选举时，该跟随者节点将自身状态改为候选者，将自己的term数加1，并投给自己一票。然后想其他节点发送RequestVote RPCs（请求投票）。

这种情况下，将发生三种结果：

（1）该节点赢得了选举。

如果一个候选人在同一届选举中获得了整个集群中大多数服务器的投票，他就赢得了选举。每个服务器在一个任期内最多投票给一位候选人。一旦候选人赢得选举，他就成为领袖。然后，它向所有其他服务器发送心跳消息，并防止新的选举。

（2）另一个节点成为领导者。

如果领导者的任期(包括在其RPC中)至少与候选人的当前任期一样大，那么候选人承认领导人是合法的，并返回追随者状态。如果RPC中的任期小于候选人的当前任期，那么候选人拒绝RPC并继续处于候选人状态。

（3）该节点在选举中既不获胜也不失败，多个节点平票。

每个候选人将暂停并开始新的选举，通过增加其任期和发起另一轮的RequestVote rpc。然而，如果没有额外的措施，平票可能会无限期地重复。

Raft使用随机选举超时来确保平票的情况很少，并且能够快速解决。选举暂停从固定的间隔(例如150 - 300毫秒)中随机选择。