共识算法-Raft协议

---

title: 共识算法-Raft协议
tags: 区块链,共识算法

---

在很多分布式系统场景下， 并不需要解决拜占庭将军问题， 也就是说，在这些分布式系统的实用场景下， 其假设条件不需要考虑拜占庭故障，而只是处理一般的死机故障。 在这种情况下， 采用Paxos等协议会更加高效。 Paxos是Lamport设计的保持分布式系统一致性的协议。 但由于Paxos非常复杂， 比较难以理解， 因此后来出现了各种不同的实现和变
种。Raft是由Stanford提出的一种更易理解的一致性算法，意在取代目前广为使用的Paxos算法。Raft最初是一个用于管理复制日志的共识算法，它是一个为真实世界应用建立的协议，主要注重协议的落地性和可理解性。Raft是在非拜占庭故障下达成共识的强一致协议。

强烈建议观看 Raft动画演示 :http://thesecretlivesofdata.com/raft/

Raft协议

假设我们有一个单节点系统,我们还有一个可以向服务器发送值的客户端
一个节点很容易就该值达成一致或达成共识。但是，如果我们有多个节点，我们如何达成共识？这就是分布式共识的问题。Raft是用于实现分布式共识的协议。
在Raft中，每个结点会处于下面三种状态中的一种：

• follower(随从)：所有结点都以follower的状态开始。如果没收到leader消息则会变成candidate状态
• candidate(候选者)：会向其他结点“拉选票”，如果得到大部分的票则成leader。这个过程就叫做Leader选举(Leader Election)
• leader(领导)：所有对系统的修改都会先经过leader。每个修改都会写一条日志(log entry)。leader收到修改请求后的过程如下，这个过程叫做日志复制(Log Replication)。

Raft一致性算法

所有节点都是follower状态，如果follower不听取leader的意见，那么他们可以成为candidate。candidate然后请求来自其他节点投票。节点将向candidate投票，获得票数最多的candidate将成为leader，此过程称为领导者选举。

选出leader后，数据更改现在都通过leader，每个更改信息都加入到日志中，如果没有提交日志，那么就不会更改节点的值，要提交修改，节点首先将其复制到follwer,然后leader等待大部分节点都写入了日志，leader再将日志提交，并且通知其他节点，达成共识，此过程称为日志复制。

• Leader election (领导选举)：原来的leader挂掉后，必须选出一个新的leader
• Log replication (日志复制)：leader从客户端接收日志，并复制到整个集群中
• Safety (安全性)：如果有任意的server将日志项回放到状态机中了，那么其他的server只会回放相同的日志项

Leader election(领导选举)

当follower在选举超时时间内未收到leader的心跳消息，则转换为candidate状态。为了避免选举冲突，这个超时时间是一个150~300ms之间的随机数。

一般而言，在Raft系统中：
1.任何一个服务器都可以成为一个候选者candidate，它向其他服务器follower发出要求选举自己的请求。
2.其他服务器同意了，发出OK。注意，如果在这个过程中，有一个follower宕机，没有收到请求选举的要求，此时候选者可以自己选自己，只要达到N/2+1的大多数票，候选人还是可以成为leader的。
3.这样这个候选者就成为了leader领导人，它可以向选民也就是follower发出指令，比如进行记账。
4.以后通过心跳进行记账的通知。
5.一旦这个leader崩溃了，那么follower中有一个成为候选者，并发出邀票选举。
6.follower同意后，其成为leader，继续承担记账等指导工作。

Log replication (日志复制)

Raft的记账过程按以下步骤完成：
1.假设leader领导人已经选出，这时客户端发出增加一个日志的要求；
2.leader要求follower遵从他的指令，都将这个新的日志内容追加到他们各自日志中；
3.大多数follower服务器将交易记录写入账本后，确认追加成功，发出确认成功信息；
4.在下一个心跳中，leader会通知所有follower更新确认的项目。对于每个新的交易记录，重复上述过程。

在这一过程中，若发生网络通信故障，使得leader不能访问大多数follower了，那么leader只能正常更新它能访问的那些follower服务器。而大多数的服务器follower因为没有了leader，他们将重新选举一个候选者作为leader，然后这个leader作为代表与外界打交道，如果外界要求其添加新的交易记录，这个新的leader就按上述步骤通知大多数follower。当网络通信恢复，原先的leader就变成follower，在失联阶段，这个老leader的任何更新都不能算确认，必须全部回滚，接收新的leader的新的更新。

Safety (安全性)

选举限制

在一些一致性算法中，即使一台server没有包含所有之前已提交的log entry，也能被选为主，这些算法需要把leader上缺失的日志从其他的server拷贝到leader上，这种方法会导致额外的复杂度。相对而言，raft使用一种更简单的方法，即它保证所有已提交的log entry都会在当前选举的leader上，因此，在raft算法中，日志只会从leader流向follower。

为了实现上述目标，raft在选举中会保证，一个candidate只有得到大多数的server的选票之后，才能被选为主。得到大多数的选票表明，选举它的server中至少有一个server是拥有所有已经提交的log entry的，而leader的日志至少和follower的一样新，这样就保证了leader肯定有所有已提交的log entry。

提交之前任期内的日志条目
领导人知道一条当前任期内的日志记录是可以被提交的，只要它被存储到了大多数的服务器上。如果一个领导人在提交日志条目之前崩溃了，未来后续的领导人会继续尝试复制这条日志记录。然而，一个领导人不能断定一个之前任期里的日志条目被保存到大多数服务器上的时候就一定已经提交了。下图展示了一种情况，一条已经被存储到大多数节点上的老日志条目，也依然有可能会被未来的领导人覆盖掉。