一种拜占庭共识机制的制作方法

本发明涉及分布式系统领域，更具体的，涉及一种拜占庭共识机制。

背景技术：

在分布式系统中，由于需要避免单点故障而导致服务不可用，因此需要通过多节点同步复制数据来达到容错和高可用的目的。现有技术主要采用共识机制/共识协议来保证多节点数据完全一致，共识机制可以分为两大类：非拜占庭共识机制和拜占庭共识机制，这两类的区别在于其错误模型不一样。其中拜占庭共识机制：假设节点的行为可以是任意的，甚至不受程序约束，比如某个节点被黑客入侵，其就有可能表现出拜占庭行为。拜占庭共识机制分为两类：primary节点-based共识机制和quorum-based共识机制。下面详细介绍这两种共识机制中的代表机制以及它们存在的优缺点。

pbft共识机制，是primary节点-based拜占庭共识机制的一种，它要求集群的数目至少为3f+1（f为可以容纳出错的节点数目），集群中的节点有两种角色，分别为primary节点和backup。如图1所示，pbft机制完成共识过程需要经过三个通信阶段。

pre-prepare阶段：primary节点汇总用户请求，给请求分配序号，然后构造pre-prepare消息，并广播给所有的backup节点。

pepare阶段：backup节点接收pre-prepare消息，进行相关验证，然后构造prepare消息，广播给所有其他节点。当backup节点接收超过2f+1个有效匹配的prepare消息，则进入commit阶段。

commit阶段：backup节点构造commit消息，广播给所有节点。当节点接收2f+1个commit消息，则可以认为其对应的请求被提交了，然后执行请求，返回响应给用户。

pbft共识机制的优缺点如下：

pbft共识机制要求的集群节点数比较少（比如3f+1），在高并发场景下具有稳定的性能和较高的吞吐量。但是pbft共识机制的延迟比较高，需要经过三个阶段来使节点达成共识。pbft共识机制还存在扩展性差，其要求节点之间相互广播消息，当随着集群节点数n的增加，其消息数目将呈n^2增多，使其扩展性受到了一定的限制。

q/u共识机制，是quorum-based共识机制中的一种。该机制中所有节点的角色是相等，没有primary节点和backup角色之分，是否达成共识是由client端来判断。q/u机制主要向外暴露两个功能：query和update，它要求集群的数目至少为5f+1。如图2所示，update操作分为两步：retrievestate和proposerequest。

retrievestate：client端向所有节点发送请求，获取节点当前最新的逻辑时间戳。client端获取4f+1个响应后，如果当中有3f+1个一致的逻辑时间戳，就可以进入proposerequest阶段。如果没有3f+1个一致的时间戳，此时说明有冲突发生，则需要进行冲突解决。

proposerequest：client把retrievestate阶段获取到的逻辑时间戳分配给request，然后广播给所有节点。节点接收到request后，如果该request上的逻辑时间戳大于等于当前自身维护的逻辑时间戳，该节点就接收该request，执行它，并把结果返回给client端，否则，会返回拒绝响应。client端获取4f+1个响应后，如果当中有3f+1个一致的结果，则可以认为该request执行成功，否则说明有冲突发生，需要进行冲突解决。

q/u共识机制的优缺点如下：

q/u共识机制具有很好的扩展性，随着集群节点数目增加，其消息数目呈线性增加。另外，在低并发的场景下，其延迟比较低，最优情况下两个通信延迟就能完成响应。但是q/u共识机制要求的集群节点数比较多（5f+1）。而且，q/u机制在高并发场景下，该类机制很容易出现性能退化，最严重可能呈现指数级别的性能下降。

技术实现要素：

本发明为了解决现有技术中拜占庭共识机制不能同时兼顾低延迟、吞吐量高、扩展性高、高并发场景下性能平滑降级的问题，提供了一种拜占庭共识机制，其能同时兼顾低延迟、吞吐量高、扩展性高、高并发场景下性能平滑降级的特点。

为实现上述本发明目的，采用的技术方案如下：一种拜占庭共识机制，该拜占庭共识机制包括simple-order-match机制、repair机制；

所述simple-order-match机制的实现步骤如下：

s1：通过client端向所有节点发送请求，接收到请求后，primary节点和backup节点都会为该请求分配序列号，并且分别构造remote-request消息和local-request消息；

s2：backup节点在构造完local-request消息后，会启动一个定时器diff-timer；若在定时器定时器diff-timer超时前，backup节点没有收到来自primary节点的remote-request的匹配消息，则backup节点会触发repair机制；若在定时器diff-timer超时前，backup节点收到来自primary节点的remote-request的匹配消息，则该节点会对请求进行预执行，然后返回响应fast-reply消息给客户端；

s3：当客户端接收到2f+1个匹配的fast-reply消息，则该请求执行完成。

所述repair机制的实现步骤如下：

t1：触发repair机制的backup节点广播diff消息，表明当前节点接收到的请求与primary节点接收到的请求不一样；

t2：当其他节点接收到diff消息后，若该节点已经完成预执行，该节点广播repair消息给所有节点，若该节点未完成预执行，则该节点保存好diff消息；

t3：当节点接收到2f+1个匹配的diff消息或者2f+1个匹配的repair消息后，该节点将进行commit阶段，并请求进行提交操作；

t4：在commit阶段，节点广播commit消息，并且等待其他节点发送commit消息；

t5：当节点接收到2f+1个commit消息，说明该请求已经提交，该请求返回响应commit-reply消息给client端；

t6：当client端接收到f+1个commit-reply消息后，则该请求执行完成。

优选地，所述在simple-order-match机制中，对于backup节点收到来自primary节点的remote-request的不匹配消息，backup节点直接触发repair机制。

优选地，对于存在[0,f)个backup节点的请求队列与primary节点的请求队列不一致，不匹配的请求通过backup节点触发repair机制，最终被所有节点提交，并返回响应commit-reply给client端。

进一步地，对于存在[f,2f)个backup节点的请求队列与primary节点的请求队列不一致，此时所有节点无法收到2f+1个diff消息或者repair消息，从而无法进入commit阶段，同时client端也无法接收到2f+1个fast-reply消息或者f+1个commit-reply消息完成响应；每个节点等待自身维护的vtimer定时器超时，然后选择新的primary节点进行处理。

进一步地，对于存在[2f,3f]个backup节点的请求队列与primary节点的请求队列不一致，请求不匹配的backup节点触发repair机制，广播diff消息；所有节点收到2f+1个diff消息后提交请求，并返回响应commit-reply消息给client端。

本发明的有益效果如下：本发明结合primary节点-based机制和quorum-based机制的优势，在良好的集群环境和低并发的场景下，实现了低延迟和高吞吐的目标。本发明完成一个请求只需要三个通信延迟，实现了低延迟。而吞吐量和扩展性方面，本发明在稳定的网络环境下，不需要节点之间相互广播，减少了不必要通信开销，有利于提高吞吐量和扩展性。在高并发场景下，本发明能以更低的延迟巧妙退化为pbft，实现平滑降级。

附图说明

图1是现有技术pbft共识机制的详细流程图。

图2是现有技术q/u共识机制的详细流程图。

图3是本发明执行simple-order-match机制的流程图。

图4是存在[0,f)个backup节点的请求队列与primary节点的请求队列不一致时的流程图。

图5是存在[f,2f)个backup节点的请求队列与primary节点的请求队列不一致时的流程图。

图6是存在[2f,3f]个backup节点的请求队列与primary节点的请求队列不一致时的流程图。

图7是primary节点处理的流程图。

图8是backup节点处理的流程图。

具体实施方式

下面结合附图和具体实施方式对本发明做详细描述。

实施例1

一种拜占庭共识机制，其结合了quorum-based机制特性的primary节点-based的共识机制，即要求集群节点有primary节点和backup角色之分。本实施例所述拜占庭共识机制包括simple-order-match机制、repair机制；

所述simple-order-match机制的实现步骤如下：

s1：通过client端向所有节点发送请求，接收到请求后，primary节点和backup节点都会为该请求分配序列号，并且分别构造remote-request消息和local-request消息；

s2：backup节点在构造完local-request消息后，会启动一个定时器diff-timer；若在定时器定时器diff-timer超时前，backup节点没有收到来自primary节点的remote-request的匹配消息，则backup节点会触发repair机制；若在定时器diff-timer超时前，backup节点收到来自primary节点的remote-request的匹配消息，则该节点会对请求进行预执行，然后返回响应fast-reply消息给客户端；

s3：当客户端接收到2f+1个匹配的fast-reply消息，则该请求执行完成。

所述repair机制的实现步骤如下：

t1：触发repair机制的backup节点广播diff消息，表明当前节点接收到的请求与primary节点接收到的请求不一样；

t2：当其他节点接收到diff消息后，若该节点已经完成预执行，该节点广播repair消息给所有节点，若该节点未完成预执行，则该节点保存好diff消息后什么也不做；

t3：当节点接收到2f+1个匹配的diff消息或者2f+1个匹配的repair消息后，该节点将进行commit阶段，并请求进行提交操作；

t4：在commit阶段，节点广播commit消息，并且等待其他节点发送commit消息；

t5：当节点接收到2f+1个commit消息，说明该请求已经提交，该请求返回响应commit-reply消息给client端；

t6：当client端接收到f+1个commit-reply消息后，则该请求执行完成。

如图3所示，当所有backup节点的请求队列与primary节点的请求队列一致，此时所有节点都会顺利执行simple-order-match机制，不会触发repair机制，此时只需要三个通信延迟，client端即可获取响应。

所述在simple-order-match机制中，对于backup节点收到来自primary节点的remote-request的不匹配消息，backup节点直接触发repair机制。

如图4所示，对于存在[0,f)个backup节点的请求队列与primary节点的请求队列不一致，不匹配的请求会通过backup节点触发repair机制最终被所有节点提交此时节点最终会收到2f+1个repair消息，进入commit阶段，并返回响应commit-reply给client端。而这些不匹配被提交的过程实际就是重新执行了一个类似pbft的三阶段共识机制。而与primary节点匹配的那部分请求则会顺序执行simple-order-match机制，并且在三个通信延迟后将响应fast-reply返回给client端。

如图5所示，对于存在[f,2f)个backup节点的请求队列与primary节点的请求队列不一致，此时所有节点无法收到2f+1个diff消息或者repair消息从而进入commit阶段，而client端也无法接收到2f+1个fast-reply消息或者f+1个commit-reply消息完成响应。这种情况下，每个节点等待自身维护的vtimer定时器超时，然后进行重新选主。当新的primary节点选出来后，机制就会继续顺利执行。

如图6所示，对于存在[2f,3f]个backup节点的请求队列与primary节点的请求队列不一致，请求不匹配的backup节点触发repair机制，广播diff消息。最终，所有节点收到2f+1个diff消息从而提交请求，并返回响应commit-reply消息给client端。

如图7所示，本实施例中所述的primary节点处理流程如下：给请求分配序列号，进行预执行；返回fast-reply消息给client端；client端判断是否接收到diff消息，若client端接收到diff消息，则向所有节点广播repair消息，若client端没有接收到diff消息，则返回继续判断；client端向所有节点广播repair消息后，若能成功进入commit阶段，返回commit-reply消息client端，结束primary节点处理；若不能进入commit阶段，先client端触发view-change协议，后返回commit-reply消息client端，结束primary节点处理。

如图8所示，本实施例中所述的backup节点处理流程如下：给请求分配序列号，等待remote-request；判断是否成功som机制，若成功，client端向所有节点广播repair消息，若不成功，进行预执行，并返回fast-reply消息给client端；backup节点判断是否接收different或repair消息，若不接收，则继续判断；若接收判断是否成功进入commit阶段；若能成功进入commit阶段，返回commit-reply消息client端，结束primary节点处理；若不能进入commit阶段，先client端触发view-change协议，后返回commit-reply消息client端，结束primary节点处理。

显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。