其他分享
首页 > 其他分享> > 共识协议——RAFT&PBFT

共识协议——RAFT&PBFT

作者:互联网

  区块链是一个没有中央权威的分布式对等系统。虽然权力下放可以防止各方的腐败行为,但是它必需要有一个可靠的共识协议来作出决策,让分散在世界各地的节点可以形成一致的意见。常见的共识算法有比特币采用的POW,fabric使用的PBFT,以及分布式系统一般采用的RAFT等。

一、RAFT协议

  Raft基于分布式系统中常见的CFT(Crash Fault Tolerance)问题,比如分布式系统中一些节点由于某些原因宕机造成的问题,Raft协议正常运行的前提是要保证系统中至少一半以上(n/2+1)的节点可以正常运行。Raft最主要的两个问题是选举(Leader selection)、日志复制(Log replication)和安全(Safety)。

a. 选举(Leader selection)

三个角色

Raft协议定义了三个角色,也可以说是三种状态:

角色(状态)之间的转换方式如下图所示

  如图所示:系统刚开始启动的时候,所有节点都是follower,在一段时间内如果它们没有收到Leader的心跳信号,follower就会转化为Candidate;如果某个Candidate节点收到大多数节点的票,则这个Candidate就可以转化为Leader,其余的Candidate节点都会回到Follower状态;一旦一个Leader发现系统中存在一个Leader节点比自己拥有更高的任期(Term),它就会转换为Follower。

两个消息

1. RequestVote – 请求选票

包含当前节点的任期(Term)、当前节点的名称(CandidateName)、当前节点最新日志条目的任 期及日志索引号[LastLogTerm, LastLogIndex]等信息

2. AppendEntries – 同步日志

选举过程

具体的过程可以看一个网站上有展示的动画,很详细——raft动画展示,过程描述如下:

选举Leader:

Leader运行时注意的几点

b. 日志复制

在分布式系统中,有了Leader之后,客户端所有并发的请求可以在Leader这边形成一个有序的日志(状态)序列,以此来表示这些请求的先后处理顺序。Leader然后将自己的日志序列发送Follower,保持整个系统的全局一致性。

日志由有序编号(log index)的日志条目组成。每个日志条目包含它被创建时的任期号(term),和日志中包含的数据组成,日志包含的数据可以为任何类型,从简单类型到区块链的区块。每个日志条目可以用[ term, index, data]序列对表示,其中term表示任期, index表示索引号,data表示日志数据。

日志在节点上的形式如下:

日志由这些entry组成,每个log entry包含command和该log entry产生时的任期term。 从上图可以看到,五个节点的日志并不完全一致,raft算法为了保证高可用,并不是强一致性,而是最终一致性,leader会不断尝试给follower发log entries,直到所有节点的log entries都相同。

当然由于网络的不确定性,以及错误发生的不可预知性,在某一时刻,也有可能发生如下图的情况,图中a-f表示的时六种可能的节点状态。一些节点的日志可能比Leader节点长(cd),也可能比它短(ab),还有可能日志的某些部分不匹配(ef)。

 

此时算法会找到每一个Follower与Leader最长的一致日志的位置,比如,a状态时9,b状态是4,c状态是10,d状态是10,e状态是5,f状态是3。找到最长一致位置后,此时算法会删除Follower后面的不一致日志条目,同时将Leader的日志条目拉过来进行同步。

c. 安全(Safety)

Raft算法中提出安全性的概念,安全性是Raft算法保证每个节点的日志数据一致性的安全机制,主要包括如下的规则:

例如出现如下情况:

上面有五个阶段以及五个节点,首先第一个阶段(a),term为2,S1是Leader,且S1写入 日志条目[term, index]为[2, 2],并且日志被同步写入了S2;在阶段b,S1离线,触发一次新的选主,此时S5被选为新的Leader,此时系统term为3, 且写入了日志[term, index]为[3,2];在阶段c,S5离线,进而触发了一次新的选 主,S1重新变成Leader,此时系统term为 4,S1会将自己的日志条目[2,2]同步到了S3,此时该日志条目已经被同步到了多数节点(S1, S2, S3),所以此时这些日志是可以被committed的;现在问题来了,在阶段d,此时假设S1又宕机下线了,S5又重新当选,S5会把之前的日志条目[3,2]广播到其他节点(S1,S2,S3,S4),而节点(S1,S2,S3)的日志条目的[2,2]会被覆盖 ,就会出现一种奇怪的现象,被复制的大多数节点会被日志回滚,即便事件已经被提交。

这个时候根据日志完整性规则就会避免日志回滚事件的发生。该规则规定,当某个节点当选Leader后,不会直接提交该节点之前任期没有committed的日志条目,而是通过提交当前任期日志的同时,将之前任期的日志同步到其他节点,这样就不会出现d阶段的已提交的日志覆盖事情了,即 [2,2]条目不会被提交。如果刚刚当选的Leader节点当前任期没有日志条目,则会在当前任期提交一条空的日志条目。

还有一种情况,在e阶段(S1是Leader),在同步日志条目[4, 3]之后S1离线,由于[4, 3]条目已经复制到S1、S2、S3节点,为避免S4和S5变成主节点。由选举规则规定,拥有较新日志条目的Follower才有资格成为Leader,S5不会成为Leader,Leader只能在S2、S3中间产生。

二、PBFT协议

PBFT(Practical Byzantine Fault Tolerance),即实用拜占庭容错算法,该算法针对的问题与传统的分布式系统问题不一样,主要是针对系统中某些节点不再是单纯的出现宕机这种crash错误,同时也有节点会主动作恶,比如向系统中的其他节点发送错误消息,扰乱整个系统的正常运行。该算法在保证系统的安全性和可靠性的前提下提供了(n-1)/3的容错性,即允许系统有不多于三分之一的节点失效或者作恶。

算法流程

主节点接收到来自客户端的请求后,按照三阶段协议向全网广播该消息。 主要包括预准备(pre-prepare)、准备(prepare)和确认(commit) 三个阶段。

副本0是主节点,副本3是失效节点,C是客户端。

1. 客户端发起消息

客户端C向主节点发送操作请求<REQUEST,o,t,c>

2. 预准备阶段

在预准备阶段,主节点对收到的客户端请求消息签名进行验证,验证通过,基于当前视图v分配一个序列号n给收到的客户端请求,然后向所有备份节点群发送预准备消息< <PRE-PREPARE, v, n , d>, m>

预准备消息的目的是作为一种证明,确定该请求已在视图v中被赋予了序号n,从而在视图变更的过程中消息仍可被追溯。

3. 准备阶段

副本节点i收到主节点的PRE-PREPARE消息,需要进行以下校验:

校验通过后,副本节点i向所有副本节点发送准备消息<PREPARE, v, n, d, i>,并将预准备消息和准备消息在节点i进行保存,用于View Change过程中恢复未完成的请求操作。

当节点i收到接超过2f+1个节点的准备消息后,就可以进入确认阶段。其中会检查这些消息的视图编号v,消息序号n 和摘要d。

4. 确认阶段

进入确认阶段的节点向其他节点包括主节点发送一条<COMMIT, v, n, d, i>确认消息。

当节点i接受到2f+1个m的确认消息后并满足相应条件后,消息m变更为 committed-local状态,节点执行m的请求。

在完成m请求的操作之后,每个副本节点都向客户端发送回复。进入reply阶段。

5. 回应客户端

节点i返回<REPLY, v, t, c, i, r>给客户端,r:是请求操作结果。客户端如果收到f+1个相同的REPLY消息,说明客户端发起的请求已经达成全网共识,否则客户端需要判断是否重新发送请求给主节点。

概念

视图(View) 一次成功的主节点变换

PBFT是一种状态机副本复制算法,算法中主节点由公式p = v mod |R|计算得到, 这里v是视图编号,p是副本编号,|R|是副本集合的个数。 当主节点失效的时候就需要启动视图更换(view change)过程。视图编号是连续的。

checkpoint 检查点

算法设置周期性的检查点协议,将系统中的服务器同步到某一个相同的状态, 系统会设置一个checkpoint的时间点,在这个时刻可以定期地处理日志、节约资源并及时纠正服务器状态。 比如上述算法的执行流程中很多步都会将收到的消息以log的形式保存,便于发生ViewChange或者其他一些异常情况发生时,快速恢复,当相应的请求执行完之后,就需要将这些没有用的日志给清除,于是就使用了“批处理”类似的方法,利用请求消息序号n整除一个常数T(比如100)周期性向其他节点广播检查点消息<CHECKPOINT, n, d, i>,这里n是当前节点所保留的最后一个视图请求编号,d是状态的摘要,进而通知到其他节点,如果副本节点i收到了2f+1个验证过的CheckPoint消息,则清除先前日志中无用的消息,并以n作为当前一个stable checkpoint。而此时刻的请求序号n就是检查点。

另一方面由于拜占庭节点的存在,算法不能保证每个节点执行了相同相同序列的请求, 即所有节点状态可能不一致。为了防止某些节点处理速度过快,会设置一个上文提到的高低水位区间[h, H]来解决这个问题。 这两个高低值限定了整个系统可以被接受的消息。 低水位h等于最近一次设置的stable checkpoint,而高水位 H=h+L,L通常是上述周期的倍数,比如2T。

View Change protocol 视图转换协议

某个副本节点i检测出主节点作恶或者下线,会产生超时机制,启动视图更换,并将视图编号v变更为v+1,同时不再接受除检查点消息(checkpoint)、视图更换消息(view-change) 和新视图消息(new-view)外的其他消息请求。

副本节点i会向其他节点广播视图更换消息<VIEW-CHANGE, v+1, n, C, P , i>

其他副本节点知道主节点错误后,通过公式p = v mod |R|计算得到主节点p,当主节点p收到2f个来自其他复制节点的有效的视图更换消息后,节点p向其他复制节点广播新视图消息 <NEW-VIEW, v + 1, V, Q>:

这个时候有两种情况,判断上个view是否有未提交的消息

最后的问题

为什么pbft需要最后的commit阶段,不需要commit,当节点收到prepare阶段2f+1个确认消息的时候直接进行local commit,然后返回给客户端?

因为View Change的时候会出问题.......(在思考中)

 

参考资料

  1. In Search of an Understandable Consensus Algorithm. USENIX ATC ’14

  2. 分享型数据库课程(华东师范大学 张召老师)

  3. The Secret Lives of Data

  4. 一文搞懂Raft算法

  5. Practical Byzantine Fault Tolerance

  6. 深入浅出PBFT算法原理

标签:PBFT,视图,节点,消息,共识,RAFT,日志,条目,Leader
来源: https://www.cnblogs.com/helloworldcode/p/11094099.html