CN109600323B - 一种拜占庭共识机制 - Google Patents
一种拜占庭共识机制 Download PDFInfo
- Publication number
- CN109600323B CN109600323B CN201811340715.6A CN201811340715A CN109600323B CN 109600323 B CN109600323 B CN 109600323B CN 201811340715 A CN201811340715 A CN 201811340715A CN 109600323 B CN109600323 B CN 109600323B
- Authority
- CN
- China
- Prior art keywords
- node
- request
- nodes
- message
- commit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/56—Queue scheduling implementing delay-aware scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/56—Queue scheduling implementing delay-aware scheduling
- H04L47/564—Attaching a deadline to packets, e.g. earliest due date first
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/622—Queue service order
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种拜占庭共识机制,本发明结合Primary节点‑based机制和Quorum‑based机制的优势,在良好的集群环境和低并发的场景下,实现了低延迟和高吞吐的目标。本发明完成一个请求只需要三个通信延迟,实现了低延迟。而吞吐量和扩展性方面,本发明在稳定的网络环境下,不需要节点之间相互广播,减少了不必要通信开销,有利于提高吞吐量和扩展性。在高并发场景下,本发明能以更低的延迟巧妙退化为PBFT,实现平滑降级。
Description
技术领域
本发明涉及分布式系统领域,更具体的,涉及一种拜占庭共识机制。
背景技术
在分布式系统中,由于需要避免单点故障而导致服务不可用,因此需要通过多节点同步复制数据来达到容错和高可用的目的。现有技术主要采用共识机制/共识协议来保证多节点数据完全一致,共识机制可以分为两大类:非拜占庭共识机制和拜占庭共识机制,这两类的区别在于其错误模型不一样。其中拜占庭共识机制:假设节点的行为可以是任意的,甚至不受程序约束,比如某个节点被黑客入侵,其就有可能表现出拜占庭行为。拜占庭共识机制分为两类: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操作分为两步:Retrieve State和Propose Request。
Retrieve State:Client端向所有节点发送请求,获取节点当前最新的逻辑时间戳。Client端获取4f + 1个响应后,如果当中有3f + 1个一致的逻辑时间戳,就可以进入Propose Request阶段。如果没有3f + 1个一致的时间戳,此时说明有冲突发生,则需要进行冲突解决。
Propose Request:Client把Retrieve State阶段获取到的逻辑时间戳分配给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节点处理。
显然,本发明的上述实施例仅仅是为清楚地说明本发明所作的举例,而并非是对本发明的实施方式的限定。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明权利要求的保护范围之内。
Claims (5)
1.一种拜占庭共识方法,其特征在于:该拜占庭共识方法包括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消息,其中f为大于零的正整数,则该请求执行完成;
所述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消息后,则该请求执行完成。
2.根据权利要求1所述的拜占庭共识方法,其特征在于:所述Simple-Order-Match机制中,对于backup节点收到来自Primary节点的Remote-request的不匹配消息,backup节点直接触发Repair机制。
3.根据权利要求1所述的拜占庭共识方法,其特征在于:对于存在[0,f)个backup节点的请求队列与Primary节点的请求队列不一致,不匹配的请求通过backup节点触发Repair机制,最终被所有节点提交,并返回响应Commit-reply给client端。
4.根据权利要求3所述的拜占庭共识方法,其特征在于:对于存在[f,2f)个backup节点的请求队列与Primary节点的请求队列不一致,此时所有节点无法收到2f+1个Diff消息或者Repair消息,从而无法进入commit阶段,同时client端也无法接收到2f+1个Fast-reply消息或者f+1个Commit-reply消息完成响应;每个节点等待自身维护的vtimer定时器超时,然后选择新的Primary节点进行处理。
5.根据权利要求4所述的拜占庭共识方法,其特征在于:对于存在[2f,3f]个backup节点的请求队列与Primary节点的请求队列不一致,请求不匹配的backup节点触发Repair机制,广播Diff消息;所有节点收到2f+1个Diff消息后提交请求,并返回响应Commit-reply消息给client端。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811340715.6A CN109600323B (zh) | 2018-11-12 | 2018-11-12 | 一种拜占庭共识机制 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811340715.6A CN109600323B (zh) | 2018-11-12 | 2018-11-12 | 一种拜占庭共识机制 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109600323A CN109600323A (zh) | 2019-04-09 |
CN109600323B true CN109600323B (zh) | 2021-10-01 |
Family
ID=65958346
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811340715.6A Active CN109600323B (zh) | 2018-11-12 | 2018-11-12 | 一种拜占庭共识机制 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109600323B (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110166364B (zh) * | 2019-05-15 | 2020-07-24 | 武汉理工大学 | 一种软件定义机会网络流表更新方法 |
CN110535680B (zh) * | 2019-07-12 | 2020-07-14 | 中山大学 | 一种拜占庭容错方法 |
CN111342971B (zh) * | 2020-02-07 | 2023-08-08 | 数据通信科学技术研究所 | 一种拜占庭共识方法和系统 |
CN112068978B (zh) * | 2020-08-27 | 2022-06-10 | 恒宝股份有限公司 | View-change二次启动定时器的定时期限延长方法及装置 |
CN112929354B (zh) * | 2021-01-28 | 2022-04-08 | 恒宝股份有限公司 | 一种实用型拜占庭容错抗攻击死锁的方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106445711B (zh) * | 2016-08-28 | 2019-04-30 | 杭州云象网络技术有限公司 | 一种应用于区块链的拜占庭容错共识方法 |
CN107360206B (zh) * | 2017-03-29 | 2020-03-27 | 创新先进技术有限公司 | 一种区块链共识方法、设备及系统 |
-
2018
- 2018-11-12 CN CN201811340715.6A patent/CN109600323B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN109600323A (zh) | 2019-04-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109600323B (zh) | 一种拜占庭共识机制 | |
US10833919B2 (en) | Node device operation method, work status switching apparatus, node device, and medium | |
US10764369B2 (en) | Data storage method and server applicable to distributed server cluster | |
US5802062A (en) | Preventing conflicts in distributed systems | |
US8538923B2 (en) | Method, node and system for controlling version in distributed system | |
CN110535680B (zh) | 一种拜占庭容错方法 | |
Du et al. | Clock-RSM: Low-latency inter-datacenter state machine replication using loosely synchronized physical clocks | |
US20100312915A1 (en) | System and method for implementing a cluster token registry for business continuity | |
US11436218B2 (en) | Transaction processing for a database distributed across availability zones | |
CN112015744A (zh) | 配置数据访问方法、装置、设备、配置中心及存储介质 | |
CN115098229A (zh) | 事务处理方法、装置、节点设备及存储介质 | |
CN111510469A (zh) | 一种消息处理方法和装置 | |
Chan et al. | Reliableweb services: Methodology, experiment and modeling | |
CN114244859B (zh) | 数据处理方法及装置和电子设备 | |
CN107025257B (zh) | 一种事务处理方法及装置 | |
CN110022257A (zh) | 分布式消息系统 | |
CN113055461B (zh) | 一种基于ZooKeeper的无人集群分布式协同指挥控制方法 | |
US10776392B2 (en) | Apparatus and method to establish a connection between apparatuses while synchronization of connection information thereof is suspended | |
CN117714532A (zh) | 一种基于Timeline模型的数据信息推送方法、网关及相关设备 | |
Alchieri et al. | Efficient and modular consensus-free reconfiguration for fault-tolerant storage | |
CN101329670B (zh) | 复制数据库环境下保持数据一致性的方法和系统 | |
US7748010B1 (en) | Global attribute uniqueness (GAU) using an ordered message service (OMS) | |
EP3961415B1 (en) | Transaction confirmation methods and apparatuses in blockchain network | |
EP2980707B1 (en) | Method for creating a database clone of a distributed database, system for creating a database clone of a distributed database, program and computer program product | |
WO2021022396A1 (en) | Transaction processing for database distributed across regions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |