CN116232893A - 分布式***的共识方法、装置、电子设备及存储介质 - Google Patents
分布式***的共识方法、装置、电子设备及存储介质 Download PDFInfo
- Publication number
- CN116232893A CN116232893A CN202310231097.6A CN202310231097A CN116232893A CN 116232893 A CN116232893 A CN 116232893A CN 202310231097 A CN202310231097 A CN 202310231097A CN 116232893 A CN116232893 A CN 116232893A
- Authority
- CN
- China
- Prior art keywords
- node
- message
- distributed system
- nodes
- signature
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
- H04L41/0833—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for reduction of network energy consumption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Hardware Redundancy (AREA)
Abstract
本申请提供一种分布式***的共识方法、装置、电子设备及存储介质,应用于分布式***中的客户端,该方法通过控制分布式***运行在普通操作模式下,当检测到分布式***中存在节点发生拜占庭故障时,将分布式***转换至故障处理模式下运行,在故障处理模式下处理的业务请求的数量达到预设值时,将分布式***由故障处理模式切换为普通操作模式。该技术方案中,通过使用两种工作模式,在普通操作模式下减少副本节点数量到2F个来降低***的通信损耗,且依然可以使整个***达成共识;在故障处理模式下切换为PBFT算法,使分布式***中每个节点都可以达成一致的状态,同时保证了分布式***的活性和安全性,避免了浪费分布式***资源的问题。
Description
技术领域
本申请涉及金融科技技术领域,尤其涉及一种分布式***的共识方法、装置、电子设备及存储介质。
背景技术
分布式***依靠不同的节点通过公共网络进行通信和同步,这些节点通常代表独立的物理硬件设备、单独的软件进程、或其他递归封装的***,分布式***旨在消除***的瓶颈或中心故障点。
分布式***的共识主要依赖于实用拜占庭容错算法(Practical ByzantineFault Tolerance,PBFT)实现,即分布式***中的每个副本节点都保存了服务的状态,同时也实现了客户端所有合法请求的操作,保证在满足分布式***活性和安全性的前提下,允许(n-1)/3个节点出错,其中n为分布式***中所有参与共识的节点数量。即PBFT算法能够保证分布式***在(n-1)/3个节点出现故障或恶意操作的情况下,依然能正确达成分布式***的共识。
然而,PBFT算法中所有从节点都要参与到分布式***的共识中,当***不存在故障节点时,这些多出来的副本节点所发送的消息不会对共识结果产生影响,但是这些多出来的副本节点的通信会占用分布式***中大量的中央处理器(Central Processing Unit,CPU)和网络带宽等资源,从而造成资源的浪费。
发明内容
本申请提供一种分布式***的共识方法、装置、电子设备及存储介质,以解决现有技术针对现有技术中针对分布式***共识时存在资源浪费等问题。
第一方面,本申请实施例提供了一种分布式***的共识方法,应用于分布式***中的客户端,所述方法包括:
控制所述分布式***运行在普通操作模式下,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
当检测到所述分布式***中存在节点发生拜占庭故障时,将所述分布式***转换至故障处理模式下运行,所述故障处理模式中将所述普通操作模式下的所述F个处于被动状态的节点切换为激活状态;
在所述故障处理模式下处理的业务请求的数量达到预设值时,将所述分布式***由所述故障处理模式切换为所述普通操作模式。
在第一方面一种可能的设计中,所述方法还包括:
在将所述分布式***由所述故障处理模式切换为所述普通操作模式之后,若所述分布式***中存在节点发生拜占庭故障,控制存在拜占庭故障的节点退出所述分布式***。
可选的,所述控制存在拜占庭故障的节点退出所述分布式***,包括:
向所述存在拜占庭故障的节点发送退出***指令,所述退出***指令用于指示所述存在拜占庭故障的节点退出所述分布式***。
在第一方面另一种可能的设计中,所述方法还包括:
响应于用户的第一操作,控制新增的目标节点向所述分布式***的主节点发送请求加入信息,所述请求加入信息包括:所述目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名。
可选的,所述方法还包括:
在检测到所述目标节点收到任意F+1个不同节点的配置信息之后,确定所述分布式***中新增所述目标节点成功。
在第一方面再一种可能的设计中,所述控制所述分布式***运行在普通操作模式下,包括:
响应于用户的第二操作,向主节点发送的目标业务请求,所述目标业务请求包括:当前时间戳、业务内容、所述客户端的标识、以及所述客户端对所述目标业务请求的签名;
在处于激活状态的节点执行所述业务内容之后,接收处于激活状态的节点的执行结果,所述处于激活状态的节点包括:所述主节点。
在第一方面还一种可能的设计中,所述将所述分布式***转换至故障处理模式下运行,包括:
向所述分布式***广播内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名;
在2F个处于激活状态的节点和F个处于被动状态的节点基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,确定所述分布式***运行在所述故障处理模式下,所述协议切换消息包括:所述全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名,所述全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的。
在第一方面又一种可能的设计中,在所述将所述分布式***转换至故障处理模式下运行之前,所述方法还包括:
检测到任意一个业务请求在预设时长内未收到相应的执行结果,确定所述分布式***存在所述拜占庭故障。
在第一方面又一种可能的设计中,所述方法还包括:
确定所述分布式***中处于激活状态的节点的总数;
基于所述总数与业务请求对应的时间戳,利用实用拜占庭容错算法,确定所述分布式***的主节点。
第二方面,本申请实施例提供了一种分布式***的共识方法,应用于分布式***中的存在拜占庭故障的节点,所述方法包括:
接收客户端发送的退出***指令,所述退出***指令用于指示所述存在拜占庭故障的节点退出所述分布式***;
根据所述退出***指令,向所述分布式***中的其他节点广播退出消息,所述退出消息包括:当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
第三方面,本申请实施例提供了一种分布式***的共识方法,应用于分布式***中的不存在拜占庭故障的节点,所述方法包括:
接收存在拜占庭故障的节点发送的退出消息,所述退出消息包括当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息;
基于所述存在拜占庭故障的节点对所述退出消息的签名验证所述退出消息的合法性通过之后,向所述分布式***中的其他节点广播确认退出消息,所述确认退出消息包括:所述当前视图、所述存在拜占庭故障的节点的标识、发送所述确认退出消息的节点的标识、以及发送所述确认退出消息的节点对所述确认退出消息的签名。
在第三方面一种可能的设计中,所述方法还包括:
在接收到F+1个不同节点广播的确认退出消息之后,针对每个确认退出消息,在根据所述确认退出消息中的对所述确认退出消息的签名验证所述确认退出消息的合法性通过后,向所述分布式***中的每个节点广播完成退出消息,所述完成退出消息包括:所述当前视图、所述存在拜占庭故障的节点的标识、以及当前节点的标识,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
在接收到F+1个不同节点广播的完成退出消息之后,删除当前节点上所述存在拜占庭故障的节点的相关信息。
第四方面,本申请实施例提供了一种分布式***的共识方法,应用于分布式***中的主节点,所述方法包括:
接收新增的目标节点发来的请求加入信息,所述请求加入信息包括:所述目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
基于所述目标节点对所述请求加入信息的签名验证所述请求加入信息的合法性通过之后,向所述分布式***广播第一消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
在第四方面一种可能的设计中,所述方法还包括:
在接收到F+1个不同节点广播的验证通过消息之后,向所述分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,所述确认新增节点消息包括:所述当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
将所述配置信息同步至所述目标节点。
可选的,所述方法还包括:
接收来自客户端发送的目标业务请求,所述目标业务请求包括:当前时间戳、业务内容、所述客户端的标识、以及所述客户端对所述目标业务请求的签名;
对所述目标业务请求指定序号,并向处于激活状态的节点广播预准备消息,以启动三阶段协议过程,所述预准备消息包括:所述序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,所述当前视图配置有所述分布式***中主节点和从节点的信息。
可选的,所述方法还包括:
接收处于激活状态的节点发送的提交消息,所述提交消息包括:所述序号、所述当前视图、业务内容、以及发送准备消息的节点的标识,所述准备消息包括:所述序号、所述业务内容、所述当前视图、发送所述准备消息的节点的标识、以及发送所述准备消息的节点对所述准备消息的签名;
执行所述业务内容,并将所述业务内容对应的执行结果发送至客户端;
向处于被动状态的节点发送更新消息,所述更新消息包括:所述序号、处于激活状态的节点针对所述执行结果、所述当前视图、当前节点的标识、以及发送所述准备消息的节点对所述更新消息的签名。
在第四方面另一种可能的设计中,所述方法还包括:
接收客户端发送的内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名。
可选的,所述方法还包括:
在不存在所述客户端发送了新的消息、且所述工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,保存本地请求处理历史消息,所述本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对所述本地请求处理历史消息的签名,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
接收处于激活状态的节点发送的本地请求处理历史消息之后,基于所述对所述本地请求处理历史消息的签名验证所述本地请求处理历史消息的合法性通过之后,将各个本地请求处理历史消息进行汇总,生成全局请求处理历史记录;
向处于激活状态的节点和处于被动状态的节点广播协议切换消息,以使处于激活状态的节点和处于被动状态的节点全部处于激活状态,所述协议切换消息包括:所述全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名。
第五方面,本申请实施例提供了一种分布式***的共识方法,应用于分布式***中的从节点,所述方法包括:
在接收到主节点发送的第一消息之后,基于所述主节点对所述第一消息的签名验证请求加入信息的合法性通过之后,向所述分布式***中的其他节点广播验证通过消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息,所述验证通过消息包括:所述从节点对所述验证通过消息的签名、所述当前视图、所述从节点的标识,所述请求加入信息包括:新增的目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
在接收到F+1个不同节点广播的验证通过消息之后,向所述分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,所述确认新增节点消息包括:所述当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
将更新后的配置信息同步至所述目标节点。
在第五方面一种可能的设计中,若所述从节点为处于激活状态的节点,所述方法还包括:
接收主节点广播的预准备消息,以启动三阶段协议过程,所述预准备消息包括:序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,所述当前视图配置有所述分布式***中主节点和从节点的信息。
可选的,所述启动三阶段协议过程包括:
针对每个处于激活状态的节点,向其他处于激活状态的节点发送准备消息,所述准备消息包括:所述序号、所述业务内容、所述当前视图、当前节点的标识、以及当前节点对所述准备消息的签名;
在接收到其他处于激活状态的节点发送的准备消息之后,与所述预准备消息中的序号进行验证,在验证通过之后,向其他处于激活状态的节点发送提交消息,所述提交消息包括:所述序号、所述当前视图、业务内容、以及发送所述准备消息的节点的标识;
在接收到全部处于激活状态的节点发送的提交消息之后,执行所述业务内容,并将所述执行结果返回至客户端。
可选的,所述方法还包括:
向处于被动状态的节点发送更新消息,所述更新消息包括:所述序号、当前节点的执行结果、所述当前视图、当前节点的标识、以及发送所述准备消息的节点对所述更新消息的签名。
在第五方面另一种可能的设计中,若所述从节点为处于被动状态的节点,所述方法还包括:
在获得F+1个处于激活状态的节点发送的更新消息之后,更新自身的配置信息。
在第五方面再一种可能的设计中,所述方法还包括:
接收客户端发送的内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名。
可选的,所述方法还包括:
在不存在所述客户端发送了新的消息、且所述工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,向主节点发送本地请求处理历史消息,所述本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对所述本地请求处理历史消息的签名,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点;
接收主节点广播的协议切换消息,所述协议切换消息包括:全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名,所述全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的;
在基于所述主节点对所述全局请求处理历史记录的签名验证所述协议切换消息的合法性通过之后,所述从节点处于激活状态。
第六方面,本申请实施例提供了一种分布式***的共识装置,应用于分布式***中的客户端,所述方法包括:
控制模块,用于控制所述分布式***运行在普通操作模式下,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
切换模块,用于当检测到所述分布式***中存在节点发生拜占庭故障时,将所述分布式***转换至故障处理模式下运行,所述故障处理模式中将所述普通操作模式下的所述F个处于被动状态的节点切换为激活状态;
所述切换模块,还用于在所述故障处理模式下处理的业务请求的数量达到预设值时,将所述分布式***由所述故障处理模式切换为所述普通操作模式。
在第六方面一种可能的设计中,所述控制模块还用于:
在将所述分布式***由所述故障处理模式切换为所述普通操作模式之后,若所述分布式***中存在节点发生拜占庭故障,控制存在拜占庭故障的节点退出所述分布式***。
可选的,所述控制模块,具体用于:
向所述存在拜占庭故障的节点发送退出***指令,所述退出***指令用于指示所述存在拜占庭故障的节点退出所述分布式***。
在第六方面另一种可能的设计中,所述控制模块,还用于:
响应于用户的第一操作,控制新增的目标节点向所述分布式***的主节点发送请求加入信息,所述请求加入信息包括:所述目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名。
可选的,确定模块,用于:
在检测到所述目标节点收到任意F+1个不同节点的配置信息之后,确定所述分布式***中新增所述目标节点成功。
在第六方面再一种可能的设计中,所述控制模块控制所述分布式***运行在普通操作模式下,具体用于:
响应于用户的第二操作,向主节点发送的目标业务请求,所述目标业务请求包括:当前时间戳、业务内容、所述客户端的标识、以及所述客户端对所述目标业务请求的签名;
在处于激活状态的节点执行所述业务内容之后,接收处于激活状态的节点的执行结果,所述处于激活状态的节点包括:所述主节点。
在第六方面还一种可能的设计中,所述切换模块,将所述分布式***转换至故障处理模式下运行,具体用于:
向所述分布式***广播内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名;
在2F个处于激活状态的节点和F个处于被动状态的节点基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,确定所述分布式***运行在所述故障处理模式下,所述协议切换消息包括:所述全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名,所述全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的。
在第六方面又一种可能的设计中,在所述将所述分布式***转换至故障处理模式下运行之前,所述确定模块,还用于:
检测到任意一个业务请求在预设时长内未收到相应的执行结果,确定所述分布式***存在所述拜占庭故障。
在第六方面又一种可能的设计中,所述确定模块,还用于:
确定所述分布式***中处于激活状态的节点的总数;
基于所述总数与业务请求对应的时间戳,利用实用拜占庭容错算法,确定所述分布式***的主节点。
第七方面,本申请实施例提供了一种分布式***的共识装置,应用于分布式***中的存在拜占庭故障的节点,所述装置包括:
接收模块,用于接收客户端发送的退出***指令,所述退出***指令用于指示所述存在拜占庭故障的节点退出所述分布式***;
发送模块,用于根据所述退出***指令,向所述分布式***中的其他节点广播退出消息,所述退出消息包括:当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
第八方面,本申请实施例提供了一种分布式***的共识装置,应用于分布式***中的不存在拜占庭故障的节点,所述装置包括:
接收模块,用于接收存在拜占庭故障的节点发送的退出消息,所述退出消息包括当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息;
发送模块,用于基于所述存在拜占庭故障的节点对所述退出消息的签名验证所述退出消息的合法性通过之后,向所述分布式***中的其他节点广播确认退出消息,所述确认退出消息包括:所述当前视图、所述存在拜占庭故障的节点的标识、发送所述确认退出消息的节点的标识、以及发送所述确认退出消息的节点对所述确认退出消息的签名。
在第八方面一种可能的设计中,所述发送模块,还用于:
在接收到F+1个不同节点广播的确认退出消息之后,针对每个确认退出消息,在根据所述确认退出消息中的对所述确认退出消息的签名验证所述确认退出消息的合法性通过后,向所述分布式***中的每个节点广播完成退出消息,所述完成退出消息包括:所述当前视图、所述存在拜占庭故障的节点的标识、以及当前节点的标识,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
处理模块,用于在接收到F+1个不同节点广播的完成退出消息之后,删除当前节点上所述存在拜占庭故障的节点的相关信息。
第九方面,本申请实施例提供了一种分布式***的共识装置,应用于分布式***中的主节点,所述装置包括:
接收模块,用于接收新增的目标节点发来的请求加入信息,所述请求加入信息包括:所述目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
发送模块,用于基于所述目标节点对所述请求加入信息的签名验证所述请求加入信息的合法性通过之后,向所述分布式***广播第一消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
在第九方面一种可能的设计中,所述发送模块,还用于:
在接收到F+1个不同节点广播的验证通过消息之后,向所述分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,所述确认新增节点消息包括:所述当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
处理模块,用于将所述配置信息同步至所述目标节点。
可选的,所述接收模块,还用于:
接收来自客户端发送的目标业务请求,所述目标业务请求包括:当前时间戳、业务内容、所述客户端的标识、以及所述客户端对所述目标业务请求的签名;
对所述目标业务请求指定序号,并向处于激活状态的节点广播预准备消息,以启动三阶段协议过程,所述预准备消息包括:所述序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,所述当前视图配置有所述分布式***中主节点和从节点的信息。
可选的,所述接收模块,还用于:
接收处于激活状态的节点发送的提交消息,所述提交消息包括:所述序号、所述当前视图、业务内容、以及发送准备消息的节点的标识,所述准备消息包括:所述序号、所述业务内容、所述当前视图、发送所述准备消息的节点的标识、以及发送所述准备消息的节点对所述准备消息的签名;
执行所述业务内容,并将所述业务内容对应的执行结果发送至客户端;
向处于被动状态的节点发送更新消息,所述更新消息包括:所述序号、处于激活状态的节点针对所述执行结果、所述当前视图、当前节点的标识、以及发送所述准备消息的节点对所述更新消息的签名。
在第九方面另一种可能的设计中,所述接收模块,还用于:
接收客户端发送的内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名。
可选的,所述处理模块,还用于:
在不存在所述客户端发送了新的消息、且所述工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,保存本地请求处理历史消息,所述本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对所述本地请求处理历史消息的签名,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
接收处于激活状态的节点发送的本地请求处理历史消息之后,基于所述对所述本地请求处理历史消息的签名验证所述本地请求处理历史消息的合法性通过之后,将各个本地请求处理历史消息进行汇总,生成全局请求处理历史记录;
向处于激活状态的节点和处于被动状态的节点广播协议切换消息,以使处于激活状态的节点和处于被动状态的节点全部处于激活状态,所述协议切换消息包括:所述全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名。
第十方面,本申请实施例提供了一种分布式***的共识装置,应用于分布式***中的从节点,所述装置包括:
发送模块,用于在接收到主节点发送的第一消息之后,基于所述主节点对所述第一消息的签名验证请求加入信息的合法性通过之后,向所述分布式***中的其他节点广播验证通过消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息,所述验证通过消息包括:所述从节点对所述验证通过消息的签名、所述当前视图、所述从节点的标识,所述请求加入信息包括:新增的目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
所述发送模块,还用于在接收到F+1个不同节点广播的验证通过消息之后,向所述分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,所述确认新增节点消息包括:所述当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
处理模块,用于将更新后的配置信息同步至所述目标节点。
在第十方面一种可能的设计中,若所述从节点为处于激活状态的节点,所述接收模块,还用于:
接收主节点广播的预准备消息,以启动三阶段协议过程,所述预准备消息包括:序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,所述当前视图配置有所述分布式***中主节点和从节点的信息。
可选的,处理模块,用于启动三阶段协议过程包括:
针对每个处于激活状态的节点,向其他处于激活状态的节点发送准备消息,所述准备消息包括:所述序号、所述业务内容、所述当前视图、当前节点的标识、以及当前节点对所述准备消息的签名;
在接收到其他处于激活状态的节点发送的准备消息之后,与所述预准备消息中的序号进行验证,在验证通过之后,向其他处于激活状态的节点发送提交消息,所述提交消息包括:所述序号、所述当前视图、业务内容、以及发送所述准备消息的节点的标识;
在接收到全部处于激活状态的节点发送的提交消息之后,执行所述业务内容,并将所述执行结果返回至客户端。
可选的,所述发送模块,还用于:
向处于被动状态的节点发送更新消息,所述更新消息包括:所述序号、当前节点的执行结果、所述当前视图、当前节点的标识、以及发送所述准备消息的节点对所述更新消息的签名。
在第十方面另一种可能的设计中,若所述从节点为处于被动状态的节点,所述处理模块,还用于:
在获得F+1个处于激活状态的节点发送的更新消息之后,更新自身的配置信息。
在第十方面再一种可能的设计中,所述接收模块,还用于:
接收客户端发送的内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名。
可选的,所述发送模块,还用于:
在不存在所述客户端发送了新的消息、且所述工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,向主节点发送本地请求处理历史消息,所述本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对所述本地请求处理历史消息的签名,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点;
接收主节点广播的协议切换消息,所述协议切换消息包括:全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名,所述全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的;
在基于所述主节点对所述全局请求处理历史记录的签名验证所述协议切换消息的合法性通过之后,所述从节点处于激活状态。
第十一方面,本申请实施例提供一种电子设备,包括:处理器,以及与所述处理器通信连接的存储器和收发器;
所述存储器存储计算机执行指令;所述收发器,用于收发数据;
所述处理器执行所述存储器存储的计算机执行指令,以实现如上述第一、二、三、四、五方面或任一种方式所述的方法。
第十二方面,本申请实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,所述计算机执行指令被处理器执行时用于实现上述第一、二、三、四、五方面或任一种方式所述的方法。
本申请实施例提供的分布式***的共识方法、装置、电子设备及存储介质,该方法应用于分布式***中的客户端,该方法通过控制分布式***运行在普通操作模式下,该普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,F表示分布式***中允许出现拜占庭故障的节点的数量最大值,当检测到分布式***中存在节点发生拜占庭故障时,将分布式***转换至故障处理模式下运行,该故障处理模式中将普通操作模式下的F个处于被动状态的节点切换为激活状态,在故障处理模式下处理的业务请求的数量达到预设值时,将分布式***由故障处理模式切换为普通操作模式。该技术方案中,通过使用两种工作模式,在普通操作模式下减少副本节点数量到2F个来降低***的通信损耗,且依然可以使整个***达成共识;在故障处理模式下切换为PBFT算法,使用所有节点使分布式***中每个节点都可以达成一致的状态,同时保证了分布式***的活性和安全性,并且避免浪费分布式***资源的问题。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。
图1为现有技术中提供的PBFT算法示意图;
图2为本申请实施例提供的分布式***的共识方法的流程示意图一;
图3A为本申请实施例提供的分布式***的共识方法的流程示意图二;
图3B为本申请实施例提供的节点退出示意图;
图4A为本申请实施例提供的分布式***的共识方法的流程示意图三;
图4B为本申请实施例提供的节点增加示意图;
图5A为本申请实施例提供的分布式***的共识方法的流程示意图四;
图5B为本申请实施例提供的普通操作模式示意图;
图6为本申请实施例提供的分布式***的共识方法的流程示意图五;
图7为本申请实施例提供的分布式***的共识装置实施例的结构示意图一;
图8为本申请实施例提供的分布式***的共识装置实施例的结构示意图二;
图9为本申请实施例提供的分布式***的共识装置实施例的结构示意图三;
图10为本申请实施例提供的分布式***的共识装置实施例的结构示意图四;
图11为本申请实施例提供的分布式***的共识装置实施例的结构示意图五;
图12为本申请实施例提供的电子设备的结构示意图。
通过上述附图,已示出本公开明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围,而是通过参考特定实施例为本领域技术人员说明本公开的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在介绍本申请的实施例之前,首先对本申请实施例的专业名词和应用背景进行介绍说明:
实用拜占庭容错算法(Practical Byzantine Fault Tolerance,PBFT):算法是卡斯特罗(英文:Miguel Castro)和利斯科夫(英文:Barbara Liskov)在1999年提出来的,解决了原始拜占庭容错算法效率不高的问题,算法的时间复杂度是O(n^2),使得在实际***应用中可以解决拜占庭容错问题。
分布式***:分布式***是计算机程序的集合,这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。它也被称为分布式计算或分布式数据库,并依靠不同的节点通过公共网络进行通信和同步。这些节点通常代表独立的物理硬件设备,但也可代表单独的软件进程或其他递归封装的***。分布式***旨在消除***的瓶颈或中心故障点。
分布式***中的副本通过一系列配置进行移动,这一系列配置称为视图(英文:view)。用连续的正整数v代表视图编号。在一个视图中只有一个主节点(英文:Primary),其余都是从节点(英文:Slave);可以通过下一节中主节点选举选出对应的主节点。
PBFT算法虽然能够保证异步分布式***中同时存在F个故障节点时,只要非故障节点个数大于2F,整个***仍然能够达成共识。
即F表示分布式***中允许出现拜占庭故障的节点的数量最大值,也即F需要满足以下不等式:
3F+1≤N
其中,N为分布式***的所有节点的总数。
分布式***实现是尽量使得整个***中的节点数量不远多于3F+1,因为额外的节点将在分布式网络中产生更多消息导致整个***的性能下降,而这些大量的冗余节点对***是否能达成共识状态没有影响。
图1为现有技术中提供的PBFT算法示意图,如图1所示,该示意图包括:客户端11、主节点12、从节点131、从节点132、从节点133。
可选的,在客户端11向主节点12发送请求后,主节点向分布式***广播预准备消息,从节点131、从节点132、以及从节点133接收到该预准备消息后,从节点131、从节点132、以及从节点133向***中的各个节点广播准备消息,各个节点在收到准备消息后,又向***中的各个节点广播提交消息,之后各个节点又向***中的各个节点广播提交消息,以完成执行该次客户端发来的请求。
实际上,从节点133为多余的副本节点,不对共识结果产生影响,但依旧会占用分布式***中的资源。
也即,在PBFT算法中所有从节点都要参与到***的共识中,当***不存在故障节点时这些多出来的副本节点所发送的消息不会对共识结果产生影响,这些多余节点的通信会占用***中大量的中央处理器(Central Processing Unit,CPU)和网络带宽等资源。
针对现有技术中存在的技术问题,本申请发明人的构思如下,针对分布式***中副本节点的状态分为两种,当***中不存在BFT问题的节点时,分布式***中所有节点分为激活状态的节点和被动状态的节点,其中被动状态的节点通过不参与本分布式***中请求处理与共识投票来减少分布式***网络中的消息传输,从而提升整个***的性能;此外,激活状态的节点既参与客户端的请求处理又要对共识进行投票;当某一激活状态的节点参与接收客户端请求并广播该请求时,该节点充当主节点角色,其他节点充当从节点角色。
进一步地,当分布式***中存在故障节点时,启动模式切换协议对节点的状态进行转换,以此减小对CPU等资源的占用。
下面,通过具体实施例对本申请的技术方案进行详细说明。需要说明的是,下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。
值得说明的是:本公开分布式***的共识方法、装置、电子设备及存储介质的应用领域可以是金融科技(英文:Fintech),也可以是其他领域,具体不作限定。
其中,本申请的执行主体可以是分布式***中的各个节点、客户端等。
图2为本申请实施例提供的分布式***的共识方法的流程示意图一,如图2所示,该方法可以应用于分布式***中的客户端,包括如下步骤:
步骤21、控制分布式***运行在普通操作模式下。
普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,F表示分布式***中允许出现拜占庭故障的节点的数量最大值。
在本步骤中,由于现有技术中当***不存在节点发生拜占庭故障时,多出来的副本节点所发送的消息不会对共识结果产生影响,这些多余节点的通信会占用***中大量的CPU和网络带宽等资源,因此,可以控制分布式***运行在普通操作模式,也即保证分布式***中有存在2F个处于激活状态的节点正常运行。
也即,普通操作模式是通过减少节点数量来降低分布式***的通信损耗。
可选的,在分布式***的运行过程中,处于激活状态的2F个副本节点参与分布式***的请求接收和共识投票活动,这2F个副本从角色功能又分为主节点和多个从节点,主节点参与接收客户端请求和共识投票,而多个从节点只参与共识投票活动。
步骤22、当检测到分布式***中存在节点发生拜占庭故障时,将分布式***转换至故障处理模式下运行。
故障处理模式中将普通操作模式下的F个处于被动状态的节点切换为激活状态。
在本步骤中,客户端在判定出该分布式***中存在拜占庭错误的节点时,执行从当前的正常操作模式切换为故障处理模式。执行完切换操作后,该分布式***采用PBFT共识算法来处理客户端请求,即激活处于被动状态的节点,使分布式***中所有的节点都参与到共识中。
在此之前,检测到任意一个业务请求在预设时长内未收到相应的执行结果,则确定分布式***存在拜占庭故障。
步骤23、在故障处理模式下处理的业务请求的数量达到预设值时,将分布式***由故障处理模式切换为普通操作模式。
在本步骤中,当分布式***运行在故障处理模式上时,继续处理接下来的业务请求,当处理业务请求的数量超过预设值后,切换分布式***由故障处理模式切换为普通操作模式。
在一种可能的实现下,当分布式***运行在故障处理模式上时,主节点在发送预准备(英文:PRE-PREPARE)消息时会为每一个消息附加上一个足够大的预设值T,当检测到分布式***在故障处理模式下运行时处理了T个业务请求后,分布式***操作模式会切换为运行在普通操作模式下。
进一步地,在将分布式***由故障处理模式切换为普通操作模式之后,若分布式***中存在节点发生拜占庭故障,控制存在拜占庭故障的节点退出分布式***。
也即,在一种可能的实现下,如果分布式***在切换为普通操作模式后,仍然收到客户端的PANIC消息即***中仍然存在节点发生拜占庭故障,此时故障节点的本地状态信息无法得到更新,于是通过向***中其他节点主动发送退出(英文:QUIT)消息,以退出该分布式***。
可选的,主节点的确定方式可以是:首先确定分布式***中处于激活状态的节点的总数,之后基于总数与业务请求对应的时间戳,利用实用拜占庭容错算法,确定分布式***的主节点。
可选的,当前分布式***的时间为T,则主节点p=T mod N,其中,p是主节点的编号,N是分布式***中所有节点的数量。
进而,在后续分布式***中节点的数量发生变化是,该公式也随之变化,具体为:
其一,分布式***新增节点时,p=T mod(N+1);
其二,分布式***删除节点时,p=T mod(N-1)。
也即,在分布式***中新加入节点时,首先更新***参数N为N+1(假设只加入一个节点),再使用p=T mod(N+1)进行主节点选举。新加入节点放到节点信息表的尾端,并赋予相应编号。退出节点时,首先更新分布式***参数N为N-1(假设只退出一个节点),并更新分布式***中节点编号,再使用p=T mod(N-1)进行主节点的选举。主节点选举完成后,进入正常工作模式。节点退出时重新分配了分布式***中节点的编号,当进行切换时可能需要重新执行一定数量的历史请求,这时只要重新广播发送未成功执行的请求让所有节点再次执行即可。
本申请实施例提供的分布式***的共识方法,应用于分布式***中的客户端,该方法通过控制分布式***运行在普通操作模式下,该普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,F表示分布式***中允许出现拜占庭故障的节点的数量最大值,当检测到分布式***中存在节点发生拜占庭故障时,将分布式***转换至故障处理模式下运行,该故障处理模式中将普通操作模式下的F个处于被动状态的节点切换为激活状态,在故障处理模式下处理的业务请求的数量达到预设值时,将分布式***由故障处理模式切换为普通操作模式。该技术方案中,通过使用两种工作模式,在普通操作模式下减少副本节点数量到2F个来降低***的通信损耗,且依然可以使整个***达成共识;在故障处理模式下切换为PBFT算法,使用所有节点使分布式***中每个节点都可以达成一致的状态,同时保证了分布式***的活性和安全性,并且避免浪费分布式***资源的问题。
在上述实施例的基础上,图3A为本申请实施例提供的分布式***的共识方法的流程示意图二,如图3A所示,控制存在拜占庭故障的节点退出分布式***的具体操作,包括:
其中,结合图3B对图3A进行说明,图3B为本申请实施例提供的节点退出示意图。
应理解:在本方案中,节点动态加入以及节点动态退出时,分布式***中所有节点可以查询得到其他节点的证书信息,可以通过***中公钥基础设施(Public KeyInfrastructure,PKI)来实现。
步骤31、客户端向存在拜占庭故障的节点发送退出***指令,退出***指令用于指示存在拜占庭故障的节点退出分布式***。
在本步骤中,当需要将存在拜占庭故障的节点剔除分布式***时,客户端向存在拜占庭故障的节点发送退出***指令,以指示存在拜占庭故障的节点退出分布式***。
步骤32、存在拜占庭故障的节点根据退出***指令,向分布式***中的其他节点广播退出消息。
退出消息包括:当前视图、存在拜占庭故障的节点的标识、以及存在拜占庭故障的节点对退出消息的签名,当前视图配置有当前分布式***中主节点和从节点的信息。
在一种可能的实现中,存在拜占庭故障的节点向分布式***广播退出消息QUIT,该退出信息形式为<QUIT,v,i>σi,其中v代表当前视图的编号,i代表本节点的编号(即存在拜占庭故障的节点的标识),σi表示当前节点i并对本退出信息进行签名。
该步骤即:不存在拜占庭故障的节点接收存在拜占庭故障的节点发送的退出消息。
步骤33、不存在拜占庭故障的节点基于存在拜占庭故障的节点对退出消息的签名验证退出消息的合法性通过之后,向分布式***中的其他节点广播确认退出消息。
确认退出消息包括:当前视图、存在拜占庭故障的节点的标识、发送确认退出消息的节点的标识、以及发送确认退出消息的节点对确认退出消息的签名。
在一种可能的实现中,分布式***中所有不存在拜占庭故障的节点收到该确认退出信息后,首先验证该确认退出消息的签名。在验证通过后,分别向分布式***广播确认退出消息CONFIRM-QUIT消息给其他节点,确认退出消息的形式为<CONFIRM-QUIT,v,i,j>σj。i代表将要退出分布式***的节点的编号,j表示验证该确认退出消息的节点的编号。
应理解:不存在拜占庭故障的节点包括主节点。
步骤34、不存在拜占庭故障的节点在接收到F+1个不同节点广播的确认退出消息之后,针对每个确认退出消息,在根据确认退出消息中的对确认退出消息的签名验证确认退出消息的合法性通过后,向分布式***中的每个节点广播完成退出消息。
完成退出消息包括:当前视图、存在拜占庭故障的节点的标识、以及当前节点的标识,F表示分布式***中允许出现拜占庭故障的节点的数量最大值。
在一种可能的实现中,分布式***中任意副本节点k收到F+1个不同节点确认退出消息CONFIRM-QUIT后,验证该确认退出消息的签名,然后分别向分布式***广播完成退出消息,该完成退出消息的形式为<FIN-QUIT,v,i,k>。
步骤35、不存在拜占庭故障的节点在接收到F+1个不同节点广播的完成退出消息之后,删除当前节点上存在拜占庭故障的节点的相关信息。
在一种可能的实现中,如果分布式***中节点收到F+1个来自不同节点的完成退出消息,则确认***中大部分节点同意该存在拜占庭故障的节点退出,此时更改当前节点***配置,并删除退出节点相关信息,同时发送回复REPLY消息,该REPLY消息的形式为<REPLY,v,FIN>σi,给存在拜占庭故障的节点。
进而,存在拜占庭故障的节点在收到F+1个REPLY消息后,退出该分布式***。
本申请实施例提供的分布式***的共识方法,客户端向存在拜占庭故障的节点发送退出***指令,退出***指令用于指示存在拜占庭故障的节点退出分布式***,存在拜占庭故障的节点根据退出***指令,向分布式***中的其他节点广播退出消息,不存在拜占庭故障的节点基于存在拜占庭故障的节点对退出消息的签名验证退出消息的合法性通过之后,向分布式***中的其他节点广播确认退出消息,不存在拜占庭故障的节点在接收到F+1个不同节点广播的确认退出消息之后,针对每个确认退出消息,在根据确认退出消息中的对确认退出消息的签名验证确认退出消息的合法性通过后,向分布式***中的每个节点广播完成退出消息,不存在拜占庭故障的节点在接收到F+1个不同节点广播的完成退出消息之后,删除当前节点上存在拜占庭故障的节点的相关信息。该技术方案中,及时将故障的节点退出分布式***,并且将各个节点的配置信息中该节点相关信息剔除,以减少多余网络通信的带来的***性能损耗。
在上述实施例的基础上,图4A为本申请实施例提供的分布式***的共识方法的流程示意图三,如图4A所示,该方法还包括:新增目标节点至分布式***,具体步骤为:
其中,结合图4B对图4A进行说明,图4B为本申请实施例提供的节点增加示意图。
步骤41、客户端响应于用户的第一操作,控制新增的目标节点向分布式***的主节点发送请求加入信息。
请求加入信息包括:目标节点的互联网协议(Internet Protocol,IP)地址、目标节点的公钥(Public Key,PK)、以及目标节点对请求加入信息的签名。
在本步骤中,在用户需要加入新的节点时,通过操控客户端,控制新增的目标节点向分布式***的主节点发送请求加入信息。
进而,在一种可能的实现中,目标节点i首先向主节点发送请求加入信息,该请求加入信息的形式为<JOIN,IP,PK>σi,IP代表目标节点i的IP地址,PK表示该目标节点的公钥,σi代表目标节点i对请求加入信息的签名。
相应的,主节点接收新增的目标节点发来的请求加入信息。
步骤42、主节点基于目标节点对请求加入信息的签名验证请求加入信息的合法性通过之后,向分布式***广播第一消息。
第一消息包括:请求加入信息、主节点对第一消息的签名、请求类型、以及当前视图,当前视图配置有当前分布式***中主节点和从节点的信息。
在一种可能的实现中,主节点收到该请求加入信息后,首先验证该目标节点的签名,验证通过后广播第一信息,该第一消息的形式为<New,v,<JOIN,IP,PK>σi>σp到所有节点。
其中NEW代表请求类型,<JOIN,IP,PK>σi为目标节点所发送带签名的请求信息,v代表当前视图编号,p为主节点。
步骤43、从节点在接收到主节点发送的第一消息之后,基于主节点对第一消息的签名验证请求加入信息的合法性通过之后,向分布式***中的其他节点广播验证通过消息。
验证通过消息包括:从节点对验证通过消息的签名、当前视图、从节点的标识,请求加入信息包括:新增的目标节点的互联网协议IP地址、目标节点的公钥、以及目标节点对请求加入信息的签名。
在一种可能的实现中,所有从节点收到主节点广播的第一信息后,首先验证主节点签名,验证通过后,再次验证目标节点的签名的消息。如果通过所有验证,则所有从节点j向分布式***广播验证通过消息,该验证通过消息的形式为<VERIFY,v,j>σj。
步骤44、从节点在接收到F+1个不同节点广播的验证通过消息之后,向分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息。
F表示分布式***中允许出现拜占庭故障的节点的数量最大值;将更新后的配置信息同步至目标节点;确认新增节点消息包括:当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息。
步骤45、主节点在接收到F+1个不同节点广播的验证通过消息之后,向分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息。
对于步骤44和45,在一种可能的实现中,分布式***中任何节点k(包括从节点和主节点)收到F+1个确认验证通过消息后,广播确认新增节点信息,该新增节点信息的形式为<CONFIRM-JOIN,v,k>σk,并更新本节点自身的配置信息,k代表分布式***中发布确认新增节点信息的节点。
步骤46、客户端在检测到目标节点收到任意F+1个不同节点的配置信息之后,确定分布式***中新增目标节点成功。
在一种可能的实现中,任一节点在更新自身节点的配置信息之后,将配置信息,该配置信息的形式为<REPLY,v,k,C>发送给新增节点。
进而,目标节点如果收到F+1个节点发送的配置信息,则客户端确定分布式***中新增目标节点成功,其中C表示配置信息,k代表发送配置信息的节点。
此外,如果新加入节点这一过程还没走完,而视图又切换了即完成了一次共识,那么目标节点所拥有的视图信息就过期了。此时可以通过分布式***中所有副本向新增节点发送最新视图信息,该最新视图信息的形式为<NEW-VIEW,v,j>σj,新增节点如果收到F+1个副本的最新视图信息,则改变节点配置。
如果在新增节点时,同时又有节点退出分布式***,因为新增节点和节点主动退出都是通过协议来完成的,而协议的执行可能会出现交叉的情况。新增节点没有完成时,有节点退出了,因为新增节点时会广播IP地址等信息,即将退出分布式***的节点的退出信息也会广播到新增节点,新增节点处理该信息,更新相应网络配置。
本申请实施例提供的分布式***的共识方法,客户端响应于用户的第一操作,控制新增的目标节点向分布式***的主节点发送请求加入信息,主节点基于目标节点对请求加入信息的签名验证请求加入信息的合法性通过之后,向分布式***广播第一消息,从节点在接收到主节点发送的第一消息之后,基于主节点对第一消息的签名验证请求加入信息的合法性通过之后,向分布式***中的其他节点广播验证通过消息,从节点在接收到F+1个不同节点广播的验证通过消息之后,向分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,主节点在接收到F+1个不同节点广播的验证通过消息之后,向分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,客户端在检测到目标节点收到任意F+1个不同节点的配置信息之后,确定分布式***中新增目标节点成功。该技术方案公开了新增节点至分布式***的方式。
在上述实施例的基础上,图5A为本申请实施例提供的分布式***的共识方法的流程示意图四,如图5A所示,分布式***运行在普通操作模式下,可以包括如下步骤为:
其中,结合图5B对图5A进行说明,图5B为本申请实施例提供的普通操作模式示意图。
步骤51、客户端响应于用户的第二操作,向主节点发送的目标业务请求。
目标业务请求包括:当前时间戳、业务内容、客户端的标识、以及客户端对目标业务请求的签名。
在一种可能的实现中,客户端通过向分布式***中主节点发送目标业务请求,其形如<REQUEST,o,t,C>σc的消息来执行算法协议中的业务内容o,t为当前时间戳,用来确保这一请求只会执行一次,客户端请求中的多个时间戳是全序排列的,后发起的请求的时间戳大于更早发起请求的时间戳,C代表发起请求的客户端,σc表示客户端已经对这条消息进行了签名。
步骤52、主节点对目标业务请求指定序号,并向处于激活状态的节点广播预准备消息,以启动三阶段协议过程。
预准备消息包括:序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,当前视图配置有分布式***中主节点和从节点的信息。
在一种可能的实现中,分布式***中的主节点收到客户端请求执行o操作的REQUEST消息后,先给目标业务请求对应的消息分配一个序号s,然后向分布式***中所有激活状态的节点P广播预准备消息,该预准备消息的形式为<PRE-PREPARE,v,P,o,s,m>σP来启动三阶段协议过程。其中m指的是当前工作模式,此时应为普通操作模式,v为当前视图编号。
步骤53、处于激活状态的从节点接收主节点广播的预准备消息,以启动三阶段协议过程。
该步骤的具体实现可以是:
1、针对每个处于激活状态的节点,向其他处于激活状态的节点发送准备消息,准备消息包括:序号、业务内容、当前视图、当前节点的标识、以及当前节点对准备消息的签名;
在一种可能的实现中,分布式***中任意处于激活状态的从节点收到主节点的预准备消息后,验证本节点的消息日志,如果未收到过具有不同请求但是绑定了相同序列号的PRE-PREPARE消息,则这一从节点接受主节点P的预准备消息。
进而,处于激活状态的从节点接受主节点的预准备消息后,向分布式***中所有激活状态节点广播准备消息,该准备消息的形式为<PREPARE,v,X,o,s,p>σX消息。其中X表示发送PREPARE消息的节点编号。
2、在接收到其他处于激活状态的节点发送的准备消息之后,与预准备消息中的序号进行验证,在验证通过之后,向其他处于激活状态的节点发送提交消息,提交消息包括:序号、当前视图、业务内容、以及发送准备消息的节点的标识;
在该过程中,主节点接收处于激活状态的节点发送的提交消息,主节点执行业务内容,并将业务内容对应的执行结果发送至客户端;主节点向处于被动状态的节点发送更新消息,更新消息包括:序号、当前节点的执行结果、当前视图、当前节点的标识、以及发送准备消息的节点对更新消息的签名
应理解:主节点处于激活状态。
在一种可能的实现中,接收到其他处于激活状态的节点发送的准备消息,处于激活状态的节点向分布式***广播提交消息,该提交消息的形式为<COMMIT,v,X,o,s,p>σX。
3、在接收到全部处于激活状态的节点发送的提交消息之后,执行业务内容,并将执行结果返回至客户端。
在一种可能的实现中,在分布式***中处于激活状态的节点从所有其他节点收到匹配的COMMIT消息之后,该节点就执行相应的业务内容。
进而,把执行结果r通过回复消息,该回复消息的形式为<REPLY,X,t,s,r>σX回复客户端。
步骤54、处于激活状态的从节点向处于被动状态的节点发送更新消息。
在一种可能的实现中,向该分布式***中所有处于被动状态的节点发送更新消息,该更新消息的形式为<UPDATE,v,X,s,u,r>σX消息以更新被动副本节点的状态。
步骤55、处于被动状态的从节点在获得F+1个处于激活状态的节点发送的更新消息之后,更新自身的配置信息。
步骤56、客户端在处于激活状态的节点执行业务内容之后,接收处于激活状态的节点的执行结果。
之后,客户端接收各个处于激活状态的节点的执行结果。
本申请实施例提供的分布式***的共识方法,客户端响应于用户的第二操作,向主节点发送的目标业务请求,主节点接收来自客户端发送的目标业务请求,主节点对目标业务请求指定序号,并向处于激活状态的节点广播预准备消息,以启动三阶段协议过程,处于激活状态的从节点接收主节点广播的预准备消息,以启动三阶段协议过程,处于激活状态的从节点向处于被动状态的节点发送更新消息,处于被动状态的从节点在获得F+1个处于激活状态的节点发送的更新消息之后,更新自身的配置信息,客户端在处于激活状态的节点执行业务内容之后,接收处于激活状态的节点的执行结果。该技术方案详述了普通操作模式下,只有处于激活状态的2F个副本节点参与***的请求接收和共识投票活动,这2F个副本从角色功能又分为主节点和从节点,主节点参与接收客户端请求和共识投票,而从节点只参与共识投票活动。进而提升了分布式***的工作效率,且减少了***资源的占用。
在上述实施例的基础上,图6为本申请实施例提供的分布式***的共识方法的流程示意图五,如图6所示,将分布式***转换至故障处理模式下运行,可以包括如下步骤为:
步骤61、客户端向分布式***广播内核恐慌消息。
内核恐慌消息包括:客户端的标识、工作模式切换内容、客户端对内核恐慌消息的签名。
在一种可能的设计中,当客户端在一段时间内无法获得对某一个请求的结果时,该客户端判定***中出现了故障,则该客户端将向分布式***广播内核恐慌消息,该内核恐慌消息的形式为<PANIC,C,o>σC给该分布式***中所有节点,该处o为工作模式切换内容。
步骤62、主节点和处于激活状态的从节点接收客户端发送的内核恐慌消息。
步骤63、主节点在不存在客户端发送了新的消息、且工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,保存本地请求处理历史消息。
本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对本地请求处理历史消息的签名。
步骤64、处于激活状态的从节点在不存在客户端发送了新的消息、且工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,向主节点发送本地请求处理历史消息。
在一种可能的设计中,步骤63和64中,在收到客户端发送的PANIC消息后,无故障的副本节点(即处于激活状态的节点)针对以下几种情况仍然会执行完客户端的请求而不会进行协议切换:1、同一个客户端C已经发送新的请求;2、客户端发送的PANIC消息指示的请求已经被稳定的检查点覆盖了。
如果是其他情况,那么副本节点马上停止参与正常模式操作协议,同时创建一个在最新稳定检查点之后包含PRE-PREPARE、PREPARE和COMMIT消息的本地请求处理历史消息,该本地请求处理历史消息的形式为<HISTORY,X,h>σX发送到主节点,h为历史消息记录。
步骤65、主节点接收处于激活状态的节点发送的本地请求处理历史消息之后,基于对本地请求处理历史消息的签名验证本地请求处理历史消息的合法性通过之后,将各个本地请求处理历史消息进行汇总,生成全局请求处理历史记录。
在一种可能的设计中,主节点收到所有2F个处于激活状态的节点发送的请求处理历史消息后,首先验证该请求处理历史消息的签名,验证通过后,把这2F个节点提交的请求处理历史消息进行汇总,生成一个全局请求处理历史记录。
步骤66、主节点向处于激活状态的节点和处于被动状态的节点广播协议切换消息,以使处于激活状态的节点和处于被动状态的节点全部处于激活状态。
协议切换消息包括:全局请求处理历史记录、主节点的标识、主节点对全局请求处理历史记录的签名。
在一种可能的设计中,主节点P向该分布式***所有节点(包括处于被动状态的节点)广播包含了全局请求处理历史记录H的协议切换消息<SWITCH,P,H>σP。
步骤67、处于激活状态的从节点在基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,从节点处于激活状态。
步骤68、客户端在2F个处于激活状态的节点和F个处于被动状态的节点基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,确定分布式***运行在故障处理模式下。
在一种可能的设计中,该分布式***中任意节点收到协议切换消息后,验证该协议切换消息的签名,验证通过后所有节点依据全局请求处理历史记录H并使用PBFT算法重新处理客户端的请求。
此外,在上述实施例的实现中,分布式***删除节点时,当分布式***在故障处理模式时,主节点在发送PRE-PREPARE消息时会为每一个消息附加上一个足够大的设定值T,当故障处理模式处理了T个请求后,分布式***操作模式自动切换为普通操作模式。如果分布式***在切换为普通操作模式后,仍然收到客户端的PANIC消息即分布式***中仍然存在故障节点;此时故障节点本地状态信息无法得到更新,于是通过向分布式***中其他节点主动发送QUIT消息,进入动态节点协议,然后退出该分布式***。
本申请实施例提供的分布式***的共识方法,客户端向分布式***广播内核恐慌消息,主节点和处于激活状态的从节点接收客户端发送的内核恐慌消息,主节点在不存在客户端发送了新的消息、且工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,保存本地请求处理历史消息,处于激活状态的从节点在不存在客户端发送了新的消息、且工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,向主节点发送本地请求处理历史消息,主节点接收处于激活状态的节点发送的本地请求处理历史消息之后,基于对本地请求处理历史消息的签名验证本地请求处理历史消息的合法性通过之后,将各个本地请求处理历史消息进行汇总,生成全局请求处理历史记录,主节点向处于激活状态的节点和处于被动状态的节点广播协议切换消息,以使处于激活状态的节点和处于被动状态的节点全部处于激活状态,协议切换消息包括:全局请求处理历史记录、主节点的标识、主节点对全局请求处理历史记录的签名,处于激活状态的从节点接收主节点广播的协议切换消息,处于激活状态的从节点在基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,从节点处于激活状态,客户端在2F个处于激活状态的节点和F个处于被动状态的节点基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,确定分布式***运行在故障处理模式下。该技术方案详述了分布式***转换至故障处理模式下运行,在存在故障的节点时,为了避免***处理业务不及时时所采用的的模式,提高了分布式***的工作效率。
下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。
图7为本申请实施例提供的分布式***的共识装置实施例的结构示意图一。如图7所示,该分布式***的共识装置应用于分布式***中的客户端,该装置包括:
控制模块71,用于控制分布式***运行在普通操作模式下,普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,F表示分布式***中允许出现拜占庭故障的节点的数量最大值;
切换模块72,用于当检测到分布式***中存在节点发生拜占庭故障时,将分布式***转换至故障处理模式下运行,故障处理模式中将普通操作模式下的F个处于被动状态的节点切换为激活状态;
切换模块72,还用于在故障处理模式下处理的业务请求的数量达到预设值时,将分布式***由故障处理模式切换为普通操作模式。
在本申请实施例一种可能的设计中,控制模块71还用于:
在将分布式***由故障处理模式切换为普通操作模式之后,若分布式***中存在节点发生拜占庭故障,控制存在拜占庭故障的节点退出分布式***。
可选的,控制模块71,具体用于:
向存在拜占庭故障的节点发送退出***指令,退出***指令用于指示存在拜占庭故障的节点退出分布式***。
在本申请实施例另一种可能的设计中,控制模块71,还用于:
响应于用户的第一操作,控制新增的目标节点向分布式***的主节点发送请求加入信息,请求加入信息包括:目标节点的互联网协议IP地址、目标节点的公钥、以及目标节点对请求加入信息的签名。
可选的,确定模块73,用于:
在检测到目标节点收到任意F+1个不同节点的配置信息之后,确定分布式***中新增目标节点成功。
在本申请实施例再一种可能的设计中,控制模块71控制分布式***运行在普通操作模式下,具体用于:
响应于用户的第二操作,向主节点发送的目标业务请求,目标业务请求包括:当前时间戳、业务内容、客户端的标识、以及客户端对目标业务请求的签名;
在处于激活状态的节点执行业务内容之后,接收处于激活状态的节点的执行结果,处于激活状态的节点包括:主节点。
在本申请实施例还一种可能的设计中,切换模块72,将分布式***转换至故障处理模式下运行,具体用于:
向分布式***广播内核恐慌消息,内核恐慌消息包括:客户端的标识、工作模式切换内容、客户端对内核恐慌消息的签名;
在2F个处于激活状态的节点和F个处于被动状态的节点基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,确定分布式***运行在故障处理模式下,协议切换消息包括:全局请求处理历史记录、主节点的标识、主节点对全局请求处理历史记录的签名,全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的。
在本申请实施例又一种可能的设计中,在将分布式***转换至故障处理模式下运行之前,确定模块73,还用于:
检测到任意一个业务请求在预设时长内未收到相应的执行结果,确定分布式***存在拜占庭故障。
在本申请实施例又一种可能的设计中,确定模块73,还用于:
确定分布式***中处于激活状态的节点的总数;
基于总数与业务请求对应的时间戳,利用实用拜占庭容错算法,确定分布式***的主节点。
本申请实施例提供的分布式***的共识装置,可用于执行上述任一实施例中应用于分布式***中的客户端所执行的共识方法,其实现原理和技术效果类似,在此不再赘述。
图8为本申请实施例提供的分布式***的共识装置实施例的结构示意图二。如图8所示,该分布式***的共识装置应用于分布式***中的存在拜占庭故障的节点,该装置包括:
接收模块81,用于接收客户端发送的退出***指令,退出***指令用于指示存在拜占庭故障的节点退出分布式***;
发送模块82,用于根据退出***指令,向分布式***中的其他节点广播退出消息,退出消息包括:当前视图、存在拜占庭故障的节点的标识、以及存在拜占庭故障的节点对退出消息的签名,当前视图配置有当前分布式***中主节点和从节点的信息。
本申请实施例提供的分布式***的共识装置,可用于执行上述任一实施例中应用于存在拜占庭故障的节点所执行共识方法,其实现原理和技术效果类似,在此不再赘述。
图9为本申请实施例提供的分布式***的共识装置实施例的结构示意图三。如图9所示,该分布式***的共识装置应用于分布式***中的不存在拜占庭故障的节点,该装置包括:
接收模块91,用于接收存在拜占庭故障的节点发送的退出消息,退出消息包括当前视图、存在拜占庭故障的节点的标识、以及存在拜占庭故障的节点对退出消息的签名,当前视图配置有当前分布式***中主节点和从节点的信息;
发送模块92,用于基于存在拜占庭故障的节点对退出消息的签名验证退出消息的合法性通过之后,向分布式***中的其他节点广播确认退出消息,确认退出消息包括:当前视图、存在拜占庭故障的节点的标识、发送确认退出消息的节点的标识、以及发送确认退出消息的节点对确认退出消息的签名。
在本申请实施例一种可能的设计中,发送模块92,还用于:
在接收到F+1个不同节点广播的确认退出消息之后,针对每个确认退出消息,在根据确认退出消息中的对确认退出消息的签名验证确认退出消息的合法性通过后,向分布式***中的每个节点广播完成退出消息,完成退出消息包括:当前视图、存在拜占庭故障的节点的标识、以及当前节点的标识,F表示分布式***中允许出现拜占庭故障的节点的数量最大值;
处理模块93,用于在接收到F+1个不同节点广播的完成退出消息之后,删除当前节点上存在拜占庭故障的节点的相关信息。
本申请实施例提供的分布式***的共识装置,可用于执行上述任一实施例中应用于不存在拜占庭故障的节点所执行共识方法,其实现原理和技术效果类似,在此不再赘述。
图10为本申请实施例提供的分布式***的共识装置实施例的结构示意图四。如图10所示,该分布式***的共识装置应用于分布式***中的主节点,该装置包括:
接收模块101,用于接收新增的目标节点发来的请求加入信息,请求加入信息包括:目标节点的互联网协议IP地址、目标节点的公钥、以及目标节点对请求加入信息的签名;
发送模块102,用于基于目标节点对请求加入信息的签名验证请求加入信息的合法性通过之后,向分布式***广播第一消息,第一消息包括:请求加入信息、主节点对第一消息的签名、请求类型、以及当前视图,当前视图配置有当前分布式***中主节点和从节点的信息。
在本申请实施例一种可能的设计中,发送模块102,还用于:
在接收到F+1个不同节点广播的验证通过消息之后,向分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,确认新增节点消息包括:当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,F表示分布式***中允许出现拜占庭故障的节点的数量最大值;
处理模块103,用于将配置信息同步至目标节点。
可选的,接收模块101,还用于:
接收来自客户端发送的目标业务请求,目标业务请求包括:当前时间戳、业务内容、客户端的标识、以及客户端对目标业务请求的签名;
对目标业务请求指定序号,并向处于激活状态的节点广播预准备消息,以启动三阶段协议过程,预准备消息包括:序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,当前视图配置有分布式***中主节点和从节点的信息。
可选的,接收模块101,还用于:
接收处于激活状态的节点发送的提交消息,提交消息包括:序号、当前视图、业务内容、以及发送准备消息的节点的标识,准备消息包括:序号、业务内容、当前视图、发送准备消息的节点的标识、以及发送准备消息的节点对准备消息的签名;
执行业务内容,并将业务内容对应的执行结果发送至客户端;
向处于被动状态的节点发送更新消息,更新消息包括:序号、处于激活状态的节点针对执行结果、当前视图、当前节点的标识、以及发送准备消息的节点对更新消息的签名。
在本申请实施例另一种可能的设计中,接收模块101,还用于:
接收客户端发送的内核恐慌消息,内核恐慌消息包括:客户端的标识、工作模式切换内容、客户端对内核恐慌消息的签名。
可选的,处理模块103,还用于:
在不存在客户端发送了新的消息、且工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,保存本地请求处理历史消息,本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对本地请求处理历史消息的签名,普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,F表示分布式***中允许出现拜占庭故障的节点的数量最大值;
接收处于激活状态的节点发送的本地请求处理历史消息之后,基于对本地请求处理历史消息的签名验证本地请求处理历史消息的合法性通过之后,将各个本地请求处理历史消息进行汇总,生成全局请求处理历史记录;
向处于激活状态的节点和处于被动状态的节点广播协议切换消息,以使处于激活状态的节点和处于被动状态的节点全部处于激活状态,协议切换消息包括:全局请求处理历史记录、主节点的标识、主节点对全局请求处理历史记录的签名。
本申请实施例提供的分布式***的共识装置,可用于执行上述任一实施例中应用于主节点所执行共识方法,其实现原理和技术效果类似,在此不再赘述。
图11为本申请实施例提供的分布式***的共识装置实施例的结构示意图五。如图11所示,该分布式***的共识装置应用于分布式***中的从节点,该装置包括:
发送模块111,用于在接收到主节点发送的第一消息之后,基于主节点对第一消息的签名验证请求加入信息的合法性通过之后,向分布式***中的其他节点广播验证通过消息,第一消息包括:请求加入信息、主节点对第一消息的签名、请求类型、以及当前视图,当前视图配置有当前分布式***中主节点和从节点的信息,验证通过消息包括:从节点对验证通过消息的签名、当前视图、从节点的标识,请求加入信息包括:新增的目标节点的互联网协议IP地址、目标节点的公钥、以及目标节点对请求加入信息的签名;
发送模块111,还用于在接收到F+1个不同节点广播的验证通过消息之后,向分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,确认新增节点消息包括:当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,F表示分布式***中允许出现拜占庭故障的节点的数量最大值;
处理模块112,用于将更新后的配置信息同步至目标节点。
在本申请实施例一种可能的设计中,若从节点为处于激活状态的节点,接收模块113,还用于:
接收主节点广播的预准备消息,以启动三阶段协议过程,预准备消息包括:序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,当前视图配置有分布式***中主节点和从节点的信息。
可选的,处理模块112,用于启动三阶段协议过程包括:
针对每个处于激活状态的节点,向其他处于激活状态的节点发送准备消息,准备消息包括:序号、业务内容、当前视图、当前节点的标识、以及当前节点对准备消息的签名;
在接收到其他处于激活状态的节点发送的准备消息之后,与预准备消息中的序号进行验证,在验证通过之后,向其他处于激活状态的节点发送提交消息,提交消息包括:序号、当前视图、业务内容、以及发送准备消息的节点的标识;
在接收到全部处于激活状态的节点发送的提交消息之后,执行业务内容,并将执行结果返回至客户端。
可选的,发送模块111,还用于:
向处于被动状态的节点发送更新消息,更新消息包括:序号、当前节点的执行结果、当前视图、当前节点的标识、以及发送准备消息的节点对更新消息的签名。
在本申请实施例另一种可能的设计中,若从节点为处于被动状态的节点,处理模块112,还用于:
在获得F+1个处于激活状态的节点发送的更新消息之后,更新自身的配置信息。
在本申请实施例再一种可能的设计中,接收模块113,还用于:
接收客户端发送的内核恐慌消息,内核恐慌消息包括:客户端的标识、工作模式切换内容、客户端对内核恐慌消息的签名。
可选的,发送模块111,还用于:
在不存在客户端发送了新的消息、且工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,向主节点发送本地请求处理历史消息,本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对本地请求处理历史消息的签名,普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点;
接收主节点广播的协议切换消息,协议切换消息包括:全局请求处理历史记录、主节点的标识、主节点对全局请求处理历史记录的签名,全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的;
在基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,从节点处于激活状态。
本申请实施例提供的分布式***的共识装置,可用于执行上述任一实施例中应用于从节点所执行共识方法,其实现原理和技术效果类似,在此不再赘述。
需要说明的是,应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块通过处理元件调用软件的形式实现,部分模块通过硬件的形式实现。此外,这些模块全部或部分可以集成在一起,也可以独立实现。这里所述的处理元件可以是一种集成电路,具有信号的处理能力。在实现过程中,上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
图12为本申请实施例提供的电子设备的结构示意图,如图12所示,该电子设备可以包括:处理器121、存储器122及存储在所述存储器122上并可在处理器121上运行的计算机程序指令,所述处理器121执行所述计算机程序指令时实现前述任一实施例提供的方法。
应理解:该电子设备可以是上述任一项方法涉及的执行主体,可以是从节点、主节点、客户端、存在拜占庭故障的节点、或不存在拜占庭故障的节点。
可选的,该电子设备的上述各个器件之间可以通过***总线连接。
存储器122可以是单独的存储单元,也可以是集成在处理器121中的存储单元。处理器121的数量为一个或者多个。
应理解,处理器121可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器121、数字信号处理器121(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)等。通用处理器121可以是微处理器121或者该处理器121也可以是任何常规的处理器121等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器121执行完成,或者用处理器121中的硬件及软件模块组合执行完成。
***总线可以是外设部件互连标准(peripheral component interconnect,PCI)总线或扩展工业标准结构(extended industry standard architecture,EISA)总线等。***总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。存储器122可能包括随机存取存储器122(random access memory,RAM),也可能还包括非易失性存储器122(non-volatile memory,NVM),例如至少一个磁盘存储器122。
实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一可读取存储器122中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储器122(存储介质)包括:只读存储器122(read-only memory,ROM)、RAM、快闪存储器122、硬盘、固态硬盘、磁带(英文:magnetic tape)、软盘(英文:floppydisk)、光盘(英文:optical disc)及其任意组合。
本申请实施例提供的电子设备,可用于执行上述任一方法实施例提供的方法,其实现原理和技术效果类似,在此不再赘述。
本申请实施例提供一种计算机可读存储介质,该计算机可读存储介质中存储有计算机指令,当该计算机指令在计算机上运行时,使得计算机执行上述方法。
上述的计算机可读存储介质,上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器,电可擦除可编程只读存储器,可擦除可编程只读存储器,可编程只读存储器,只读存储器,磁存储器,快闪存储器,磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。
可选的,将可读存储介质耦合至处理器,从而使处理器能够从该可读存储介质读取信息,且可向该可读存储介质写入信息。当然,可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits,ASIC)中。当然,处理器和可读存储介质也可以作为分立组件存在于设备中。
本申请实施例还提供一种计算机程序产品,该计算机程序产品包括计算机程序,该计算机程序存储在计算机可读存储介质中,至少一个处理器可以从该计算机可读存储介质中读取该计算机程序,所述至少一个处理器执行所述计算机程序时可实现上述方法。
应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。
Claims (32)
1.一种分布式***的共识方法,其特征在于,应用于分布式***中的客户端,所述方法包括:
控制所述分布式***运行在普通操作模式下,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
当检测到所述分布式***中存在节点发生拜占庭故障时,将所述分布式***转换至故障处理模式下运行,所述故障处理模式中将所述普通操作模式下的所述F个处于被动状态的节点切换为激活状态;
在所述故障处理模式下处理的业务请求的数量达到预设值时,将所述分布式***由所述故障处理模式切换为所述普通操作模式。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
在将所述分布式***由所述故障处理模式切换为所述普通操作模式之后,若所述分布式***中存在节点发生拜占庭故障,控制存在拜占庭故障的节点退出所述分布式***。
3.根据权利要求2所述的方法,其特征在于,所述控制存在拜占庭故障的节点退出所述分布式***,包括:
向所述存在拜占庭故障的节点发送退出***指令,所述退出***指令用于指示所述存在拜占庭故障的节点退出所述分布式***。
4.根据权利要求1至3任一项所述的方法,其特征在于,所述方法还包括:
响应于用户的第一操作,控制新增的目标节点向所述分布式***的主节点发送请求加入信息,所述请求加入信息包括:所述目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名。
5.根据权利要求4所述的方法,其特征在于,所述方法还包括:
在检测到所述目标节点收到任意F+1个不同节点的配置信息之后,确定所述分布式***中新增所述目标节点成功。
6.根据权利要求1所述的方法,其特征在于,所述控制所述分布式***运行在普通操作模式下,包括:
响应于用户的第二操作,向主节点发送的目标业务请求,所述目标业务请求包括:当前时间戳、业务内容、所述客户端的标识、以及所述客户端对所述目标业务请求的签名;
在处于激活状态的节点执行所述业务内容之后,接收处于激活状态的节点的执行结果。
7.根据权利要求1所述的方法,其特征在于,所述将所述分布式***转换至故障处理模式下运行,包括:
向所述分布式***广播内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名;
在2F个处于激活状态的节点和F个处于被动状态的节点基于主节点对全局请求处理历史记录的签名验证协议切换消息的合法性通过之后,确定所述分布式***运行在所述故障处理模式下,所述协议切换消息包括:所述全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名,所述全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的。
8.根据权利要求1所述的方法,其特征在于,在所述将所述分布式***转换至故障处理模式下运行之前,所述方法还包括:
检测到任意一个业务请求在预设时长内未收到相应的执行结果,确定所述分布式***存在所述拜占庭故障。
9.根据权利要求1所述的方法,其特征在于,所述方法还包括:
确定所述分布式***中处于激活状态的节点的总数;
基于所述总数与业务请求对应的时间戳,利用实用拜占庭容错算法,确定所述分布式***的主节点。
10.一种分布式***的共识方法,其特征在于,应用于分布式***中的存在拜占庭故障的节点,所述方法包括:
接收客户端发送的退出***指令,所述退出***指令用于指示所述存在拜占庭故障的节点退出所述分布式***;
根据所述退出***指令,向所述分布式***中的其他节点广播退出消息,所述退出消息包括:当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
11.一种分布式***的共识方法,其特征在于,应用于分布式***中的不存在拜占庭故障的节点,所述方法包括:
接收存在拜占庭故障的节点发送的退出消息,所述退出消息包括当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息;
基于所述存在拜占庭故障的节点对所述退出消息的签名验证所述退出消息的合法性通过之后,向所述分布式***中的其他节点广播确认退出消息,所述确认退出消息包括:所述当前视图、所述存在拜占庭故障的节点的标识、发送所述确认退出消息的节点的标识、以及发送所述确认退出消息的节点对所述确认退出消息的签名。
12.根据权利要求11所述的方法,其特征在于,所述方法还包括:
在接收到F+1个不同节点广播的确认退出消息之后,针对每个确认退出消息,在根据所述确认退出消息中的对所述确认退出消息的签名验证所述确认退出消息的合法性通过后,向所述分布式***中的每个节点广播完成退出消息,所述完成退出消息包括:所述当前视图、所述存在拜占庭故障的节点的标识、以及当前节点的标识,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
在接收到F+1个不同节点广播的完成退出消息之后,删除当前节点上所述存在拜占庭故障的节点的相关信息。
13.一种分布式***的共识方法,其特征在于,应用于分布式***中的主节点,所述方法包括:
接收新增的目标节点发来的请求加入信息,所述请求加入信息包括:所述目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
基于所述目标节点对所述请求加入信息的签名验证所述请求加入信息的合法性通过之后,向所述分布式***广播第一消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
14.根据权利要求13所述的方法,其特征在于,所述方法还包括:
在接收到F+1个不同节点广播的验证通过消息之后,向所述分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,所述确认新增节点消息包括:所述当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
将所述配置信息同步至所述目标节点。
15.根据权利要求14所述的方法,其特征在于,所述方法还包括:
接收来自客户端发送的目标业务请求,所述目标业务请求包括:当前时间戳、业务内容、所述客户端的标识、以及所述客户端对所述目标业务请求的签名;
对所述目标业务请求指定序号,并向处于激活状态的节点广播预准备消息,以启动三阶段协议过程,所述预准备消息包括:所述序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,所述当前视图配置有所述分布式***中主节点和从节点的信息。
16.根据权利要求15所述的方法,其特征在于,所述方法还包括:
接收处于激活状态的节点发送的提交消息,所述提交消息包括:所述序号、所述当前视图、业务内容、以及发送准备消息的节点的标识,所述准备消息包括:所述序号、所述业务内容、所述当前视图、发送所述准备消息的节点的标识、以及发送所述准备消息的节点对所述准备消息的签名;
执行所述业务内容,并将所述业务内容对应的执行结果发送至客户端;
向处于被动状态的节点发送更新消息,所述更新消息包括:所述序号、处于激活状态的节点针对所述执行结果、所述当前视图、当前节点的标识、以及发送所述准备消息的节点对所述更新消息的签名。
17.根据权利要求13所述的方法,其特征在于,所述方法还包括:
接收客户端发送的内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名。
18.根据权利要求17所述的方法,其特征在于,所述方法还包括:
在不存在所述客户端发送了新的消息、且所述工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,保存本地请求处理历史消息,所述本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对所述本地请求处理历史消息的签名,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
接收处于激活状态的节点发送的本地请求处理历史消息之后,基于所述对所述本地请求处理历史消息的签名验证所述本地请求处理历史消息的合法性通过之后,将各个本地请求处理历史消息进行汇总,生成全局请求处理历史记录;
向处于激活状态的节点和处于被动状态的节点广播协议切换消息,以使处于激活状态的节点和处于被动状态的节点全部处于激活状态,所述协议切换消息包括:所述全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名。
19.一种分布式***的共识方法,其特征在于,应用于分布式***中的从节点,所述方法包括:
在接收到主节点发送的第一消息之后,基于所述主节点对所述第一消息的签名验证请求加入信息的合法性通过之后,向所述分布式***中的其他节点广播验证通过消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息,所述验证通过消息包括:所述从节点对所述验证通过消息的签名、所述当前视图、所述从节点的标识,所述请求加入信息包括:新增的目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
在接收到F+1个不同节点广播的验证通过消息之后,向所述分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,所述确认新增节点消息包括:所述当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
将更新后的配置信息同步至所述目标节点。
20.根据权利要求19所述的方法,其特征在于,若所述从节点为处于激活状态的节点,所述方法还包括:
接收主节点广播的预准备消息,以启动三阶段协议过程,所述预准备消息包括:序号、当前视图、业务内容、激活状态的节点的标识、以及当前工作模式的标识,所述当前视图配置有所述分布式***中主节点和从节点的信息。
21.根据权利要求20所述的方法,其特征在于,所述启动三阶段协议过程包括:
针对每个处于激活状态的节点,向其他处于激活状态的节点发送准备消息,所述准备消息包括:所述序号、所述业务内容、所述当前视图、当前节点的标识、以及当前节点对所述准备消息的签名;
在接收到其他处于激活状态的节点发送的准备消息之后,与所述预准备消息中的序号进行验证,在验证通过之后,向其他处于激活状态的节点发送提交消息,所述提交消息包括:所述序号、所述当前视图、业务内容、以及发送所述准备消息的节点的标识;
在接收到全部处于激活状态的节点发送的提交消息之后,执行所述业务内容,并将所述执行结果返回至客户端。
22.根据权利要求21所述的方法,其特征在于,所述方法还包括:
向处于被动状态的节点发送更新消息,所述更新消息包括:所述序号、当前节点的执行结果、所述当前视图、当前节点的标识、以及发送所述准备消息的节点对所述更新消息的签名。
23.根据权利要求19所述的方法,其特征在于,若所述从节点为处于被动状态的节点,所述方法还包括:
在获得F+1个处于激活状态的节点发送的更新消息之后,更新自身的配置信息。
24.根据权利要求20所述的方法,其特征在于,所述方法还包括:
接收客户端发送的内核恐慌消息,所述内核恐慌消息包括:所述客户端的标识、工作模式切换内容、所述客户端对所述内核恐慌消息的签名。
25.根据权利要求24所述的方法,其特征在于,所述方法还包括:
在不存在所述客户端发送了新的消息、且所述工作模式切换内容未被检查点覆盖时,退出普通操作模式,并创建新的检查点,向主节点发送本地请求处理历史消息,所述本地请求处理历史消息包括:历史消息记录、当前节点的标识、以及当前节点对所述本地请求处理历史消息的签名,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点;
接收主节点广播的协议切换消息,所述协议切换消息包括:全局请求处理历史记录、所述主节点的标识、所述主节点对所述全局请求处理历史记录的签名,所述全局请求处理历史记录是根据处于激活状态的各个节点的全局请求处理历史记录生成的;
在基于所述主节点对所述全局请求处理历史记录的签名验证所述协议切换消息的合法性通过之后,所述从节点处于激活状态。
26.一种分布式***的共识装置,其特征在于,应用于分布式***中的客户端,所述装置包括:
控制模块,用于控制所述分布式***运行在普通操作模式下,所述普通操作模式中包括2F个处于激活状态的节点和F个处于被动状态的节点,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
切换模块,用于当检测到所述分布式***中存在节点发生拜占庭故障时,将所述分布式***转换至故障处理模式下运行,所述故障处理模式中将所述普通操作模式下的所述F个处于被动状态的节点切换为激活状态;
所述切换模块,还用于在所述故障处理模式下处理的业务请求的数量达到预设值时,将所述分布式***由所述故障处理模式切换为所述普通操作模式。
27.一种分布式***的共识装置,其特征在于,应用于分布式***中的存在拜占庭故障的节点,所述装置包括:
接收模块,用于接收客户端发送的退出***指令,所述退出***指令用于指示所述存在拜占庭故障的节点退出所述分布式***;
发送模块,用于根据所述退出***指令,向所述分布式***中的其他节点广播退出消息,所述退出消息包括:当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
28.一种分布式***的共识装置,其特征在于,应用于分布式***中的不存在拜占庭故障的节点,所述装置包括:
接收模块,用于接收存在拜占庭故障的节点发送的退出消息,所述退出消息包括当前视图、所述存在拜占庭故障的节点的标识、以及所述存在拜占庭故障的节点对所述退出消息的签名,所述当前视图配置有当前所述分布式***中主节点和从节点的信息;
发送模块,用于基于所述存在拜占庭故障的节点对所述退出消息的签名验证所述退出消息的合法性通过之后,向所述分布式***中的其他节点广播确认退出消息,所述确认退出消息包括:所述当前视图、所述存在拜占庭故障的节点的标识、发送所述确认退出消息的节点的标识、以及发送所述确认退出消息的节点对所述确认退出消息的签名。
29.一种分布式***的共识方法,其特征在于,应用于分布式***中的主节点,所述方法包括:
接收模块,用于接收新增的目标节点发来的请求加入信息,所述请求加入信息包括:所述目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
发送模块,用于基于所述目标节点对所述请求加入信息的签名验证所述请求加入信息的合法性通过之后,向所述分布式***广播第一消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息。
30.一种分布式***的共识装置,其特征在于,应用于分布式***中的从节点,所述装置包括:
发送模块,用于在接收到主节点发送的第一消息之后,基于所述主节点对所述第一消息的签名验证请求加入信息的合法性通过之后,向所述分布式***中的其他节点广播验证通过消息,所述第一消息包括:所述请求加入信息、所述主节点对所述第一消息的签名、请求类型、以及当前视图,所述当前视图配置有当前所述分布式***中主节点和从节点的信息,所述验证通过消息包括:所述从节点对所述验证通过消息的签名、所述当前视图、所述从节点的标识,所述请求加入信息包括:新增的目标节点的互联网协议IP地址、所述目标节点的公钥、以及所述目标节点对所述请求加入信息的签名;
所述发送模块,还用于在接收到F+1个不同节点广播的验证通过消息之后,向所述分布式***中的其他节点广播确认新增节点消息,并更新自身的配置信息,所述确认新增节点消息包括:所述当前视图、当前节点的标识、以及当前节点对应的更新后的配置信息,所述F表示所述分布式***中允许出现拜占庭故障的节点的数量最大值;
处理模块,用于将更新后的配置信息同步至所述目标节点。
31.一种电子设备,其特征在于,包括:处理器,以及与所述处理器通信连接的存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,以实现如上述权利要求1至25任一项所述的方法。
32.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机执行指令,所述计算机执行指令被处理器执行时用于实现如上述权利要求1至25任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310231097.6A CN116232893A (zh) | 2023-03-01 | 2023-03-01 | 分布式***的共识方法、装置、电子设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310231097.6A CN116232893A (zh) | 2023-03-01 | 2023-03-01 | 分布式***的共识方法、装置、电子设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116232893A true CN116232893A (zh) | 2023-06-06 |
Family
ID=86576629
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310231097.6A Pending CN116232893A (zh) | 2023-03-01 | 2023-03-01 | 分布式***的共识方法、装置、电子设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116232893A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117061324A (zh) * | 2023-10-11 | 2023-11-14 | 佳瑛科技有限公司 | 一种业务数据处理方法以及分布式*** |
-
2023
- 2023-03-01 CN CN202310231097.6A patent/CN116232893A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117061324A (zh) * | 2023-10-11 | 2023-11-14 | 佳瑛科技有限公司 | 一种业务数据处理方法以及分布式*** |
CN117061324B (zh) * | 2023-10-11 | 2023-12-15 | 佳瑛科技有限公司 | 一种业务数据处理方法以及分布式*** |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11368317B2 (en) | Consensus method of consortium blockchain, and consortium blockchain system | |
US10833919B2 (en) | Node device operation method, work status switching apparatus, node device, and medium | |
CN111258822B (zh) | 数据处理方法、服务器和计算机可读存储介质 | |
CN111131209B (zh) | 一种改进的高效共识方法、***、计算机设备及存储介质 | |
US20180308091A1 (en) | Fairness preserving byzantine agreements | |
CN111355810A (zh) | 一种基于信誉与投票机制的改进pbft共识方法 | |
Abraham et al. | Efficient synchronous byzantine consensus | |
CN114048517B (zh) | 区块链的双通道共识***和方法、计算机可读存储介质 | |
WO2020232859A1 (zh) | 分布式存储***、数据写入方法、装置和存储介质 | |
WO2018192534A1 (zh) | 节点设备运行方法、工作状态切换装置、节点设备及介质 | |
CN114050904B (zh) | 一种基于两层级领导节点分片结构的共识***及方法 | |
CN110784331B (zh) | 一种共识流程恢复方法及相关节点 | |
CN111683118B (zh) | 基于区块链的共识方法、装置、主节点设备及从节点设备 | |
WO2023184881A1 (zh) | 提案共识执行方法、区块链***、设备和存储介质 | |
Zhang et al. | Prosecutor: An efficient BFT consensus algorithm with behavior-aware penalization against Byzantine attacks | |
CN115632933A (zh) | 一种基于pbft算法的集群异常恢复方法 | |
CN110635941A (zh) | 一种数据库节点集群故障迁移方法与装置 | |
CN116232893A (zh) | 分布式***的共识方法、装置、电子设备及存储介质 | |
CN111555858B (zh) | 一种基于块链式存储的实用拜占庭容错共识方法 | |
CN111338857A (zh) | 一种拜占庭容错共识协议 | |
CN114936253A (zh) | 区块链的共识方法及装置、电子设备、存储介质 | |
CN111064813B (zh) | 在区块链共识处理时进行处理消息同步的方法及装置 | |
CN114499874B (zh) | 一种应用于工业互联网的拜占庭容错共识优化方法 | |
CN116846888A (zh) | 区块链网络的共识处理方法、装置、设备及存储介质 | |
CN116991623B (zh) | 区块链节点异常恢复方法、装置、电子设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication |