CN104516790B - 一种分布式环境下检查点记录和恢复的系统及方法 - Google Patents
一种分布式环境下检查点记录和恢复的系统及方法 Download PDFInfo
- Publication number
- CN104516790B CN104516790B CN201410816875.9A CN201410816875A CN104516790B CN 104516790 B CN104516790 B CN 104516790B CN 201410816875 A CN201410816875 A CN 201410816875A CN 104516790 B CN104516790 B CN 104516790B
- Authority
- CN
- China
- Prior art keywords
- checkpoint
- message
- check point
- max
- module
- 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
Landscapes
- Retry When Errors Occur (AREA)
Abstract
本发明公开了一种分布式环境下检查点记录和恢复的系统及方法,这个系统包括3个模块,即监控模块,检查点记录模块和检查点恢复模块。监控模块,负责监控进程是否正确运行,在运行不正常的时候关闭记录模块,启动恢复模块;检查点记录模块,负责以消息为单位记录检查点;检查点恢复模块,负责按照一定的规则恢复检查点;所述监控模块分别与检查点记录模块和检查点恢复模块相连,监控模块、检查点记录模块和检查点恢复模块分别将父进程运行信息进行监控、记录和恢复。方法包括:检查点记录和检查点恢复。本发明解决了分布式检查点最终无法找到一致性检查点的问题,进程之间的通信量非常少,其具有分布式检查点非阻塞的优点。
Description
技术领域
本发明属于计算机科学领域,涉及计算机集群可靠性,更具体地,具体是适用于分布式环境下的异步检查点技术协议,可用于计算机集群错误恢复。
背景技术
目前,计算任务变得越来越复杂并且需要不断增长的运算时间。与此同时,高性能计算系统包括越来越多的故障频发组件。最终结果是长期运行的分布式计算越来越多的被高频的硬件错误所打断。在分布式计算中,当一个进程失效,代价是不仅是损失这个进程的全部计算量,与之通信的计算进程的计算量都会损失。为了确保分布式应用在大规模的环境中可以更加有效的使用,支持容错机制是当务之急。
分布式在逻辑上可以看成若干个相互独立又相互协作的进程,进程之间通过消息互相通信共享信息资源,共同完成某项任务。现阶段进行分布式环境下故障恢复主要使用的是被动容错技术。即通过定时在系统内记录检查点以保存系统状态,在系统出现故障时选取一致性检查点状态并进行恢复。
检查点技术关键点主要存在于两个方面:第一,检查点的实现,现在已有blcr,creck等多种实现。并且已经有多种MPI,例如openmpi,mpich等,将检查点技术与MPI技术相融合。第二,检查点协议的实现,即如何选取全局一致的检查点进行恢复。当进程之间存在通信的时候,不加选择的随意使用记录检查点进行恢复则会造成多米诺效应,造成恢复进程的状态不属于一致性状态,造成进程无法继续正常运行。因此,检查点的记录和恢复都应该按照一定的协议以保证,在系统出现问题的时候可以找到一致性状态。检查点协议现阶段主要有集中式检查点协议和分布式检查点协议两种。但是对于分布式的应用环境这两种协议都有其自身的不足。
集中式检查点在记录全局一致检查点时需要阻塞所有进程并清空所有的进程通信信道从而获得全局一致的进程状态。将这类检查点协议应用于分布式环境会增加记录检查点所需要的时间和记录检查点时的不确定性,并且对于大规模应用控制节点可能成为瓶颈。分布式检查点每个应用程序自行决定什么时候记录检查点,这样可以避免在记录检查点的时候进行阻塞和同步的工作,但是在系统恢复的时候需要特定的算法寻找一致性状态,在出现问题的进程和与其通信的进程中寻找状态一致性的检查点状态。但是由于检查点是进程自身是随意记录的,因此可能出现无法找到一致性状态的问题。
发明内容
本发明的目的是提供一种分布式环境下检查点记录和恢复的系统及方法,其方法可以用简单的记录及恢复的方法和很小的进程通信代价来选择具有一致性的检查点。该方法是一种特殊的非阻塞检查点协议。该方法不再像非阻塞检查点协议无规律的进行检查点的记录和恢复,而是以消息为单位成对记录和恢复检查点。
本发明还实现了一套与之相关的系统用以实现检查点记录和恢复。
根据实施例提供的一种分布式环境下检查点记录和恢复的系统,这个系统包括3个模块,即监控模块,检查点记录模块和检查点恢复模块。
监控模块,负责监控进程是否正确运行,在运行不正常的时候关闭记录模块,启动恢复模块;检查点记录模块,负责以消息为单位记录检查点;检查点恢复模块,负责按照一定的规则选择检查点恢复进程;监控模块分别与检查点记录模块和检查点恢复模块相连,监控模块、检查点记录模块和检查点恢复模块分别对进程进行实时监控、记录和恢复。
相应地,本发明给出了一种分布式环境下检查点记录和恢复的方法,该方法包括下述步骤:
A、检查点记录:
1)启动计算任务,对系统的监控模块、检查点记录模块和检查点恢复模块进行初始化;
2)在进程正式运算前,每个进程各自记录一个检查点,作为初始状态,命名为CK+进程IP+Num_0,进程IP为进程自身所分配的IP地址;
3)系统中每个进程维护一个max值列表,将max列表中所有value的值初始化为0;
4)初始化之后,进程各自运行,发送的所有消息按照消息在发送端的发出顺序进行编号;
5)监控模块对系统的通信状况进行监控,每检测到通信信道有一条消息发送,检查点记录模块记录一个检查点,命名为CKS+源IP+目的IP+Num_M,其中源IP为消息发送源端的IP,目的IP为消息接收端的IP,M为从源IP向目的IP发送的信息编号,并按时间顺序保存在磁盘上;
6)监控模块对通信状态进行监控,每检测到通信信道接收一条消息,检查点记录模块记录一个检查点,命名为CKR+源IP+目的IP+Num_M,其中源IP为消息发送源端的IP,目的IP为消息接收端的IP,M为从源IP向目的IP发送的信息编号,并按时间顺序保存在磁盘上;
7)接收端接收消息记录检查点后,更新max列表;
B、检查点恢复:
1)在崩溃进程端寻找所有以CKR开头的检查点记录,并找到最后记录的检查点CKRlast,并记录其源IP为IPlast;
2)依照步骤B第1)步中记录的源IPlast,在max列表中寻找key=IPlast,读取其value记为Mmax;
3)将Mmax发送给步骤B第1)步中的IPlast所在的进程;
4)崩溃端进程从步骤B第1)步中的检查点CKRlast恢复,恢复后暂停进程;
5)在IPlast端根据Mmax值找到检查点CKS+源IP+目的IP+Num_Mmax,其中从此检查点进行恢复,并通知崩溃端继续运行进程;
6)收到确认消息,恢复任务完成。
进一步地,所述步骤A第3)步中,列表用以记录本进程接收系统中其他某个固定进程的所有消息编号中的最大值,列表具体结构如下:
列表由(P-1)个key-value对组成;
其中,P为系统中参与任务的进程个数;key为消息发送端的IP,记为IPsend;value为本端接收IPsend端发送的消息中的消息编号的最大值。
进一步地,所述系统中其他某个固定进程的所有消息编号中的最大值,即初始化之后,进程发送的所有消息按照消息在发送端的发出顺序的消息编号。
进一步地,所述步骤A第7)步中,更新max列表具体步骤如下:
ⅰ)读取检查点的名字,提取源IP记为IPreceived和M值记为Mreceived;
ⅱ)在max值列表中寻找key=IPreceived,读取其value值记为Mmax;
ⅲ)如果Mmax<Mreceived,将Mreceived赋值给value,否则不赋值。
本发明具有如下优点:
本发明解决了分布式检查点最终无法找到一致性检查点的问题,通过大量的检查点记录保证系统中一定存在一致性状态。且由于检查点是按照一定的规律记录的,因此恢复时进程也可以按照一定的方法在固定数目的步骤内完成。由于只需要固定数目的步骤,进程之间的通信量也非常少。并且方法本身属于分布式检查点协议的改进,具有分布式检查点非阻塞的优点。
附图说明
图1是进程系统模块图。
图2是模块启动流程图。
图3是发送端检查点记录模块流程。
图4是重组后数据包格式。
图5是接收端检查点记录模块流程。
图6是接收模块流程图。
图7是方法思想来源图。
具体实施方式
下面结合附图及实施例对本发明做进一步详细说明。
一、系统初始化流程
本发明主要是有三个模块组成的。分别是监控模块,检查点记录模块,检查点恢复模块。监控模块负责监控进程是否正确运行,在运行不正常的时候关闭记录模块,启动恢复模块。检查点记录模块负责以消息为单位记录检查点。检查点恢复模块负责按照一定的规则恢复检查点。监控模块分别与检查点记录模块和检查点恢复模块相连,监控模块、检查点记录模块和检查点恢复模块分别对进程进行实时监控、记录和恢复。
如图1所示,系统启动时首先启动父进程,父进程启动四个子进程,分别运行计算任务,监控模块,检查点记录模块,检查点恢复模块。四个模块的具体启动流程与相互调用方式如图2所示。
步骤1:启动父进程。父进程的工作主要依据启动各个子进程的返回结果决定下一步工作;
步骤2:父进程启动子进程运行计算任务;
步骤3:监控模块判断计算任务是否启动成功。如果启动不成功,转步骤2;如果启动成功,转步骤4。监控模块判断进程是否启动成功,主要依赖于子进程启动后传给父进程的返回码;
步骤4:父进程启动监控进程。监控进程的任务是监控任务的运行状态。监控模块通过从父进程处获得计算任务的进程id,再定时调用任务管理器检查进程是否存在的方式进行;
步骤5:监控模块判断监控进程是否启动成功,如果不成功转步骤4。启动成功转步骤6;
步骤6:父进程启动检查点记录模块。
二、检查点记录和恢复
下面给出了一种分布式环境下记录检查点的方法,包括下述步骤:
A、检查点记录模块进行检查点记录
1)启动计算任务初始化系统的监控模块、记录检查点模块和检查点恢复模块进行初始化,初始化时检查点命名为CK+进程IP+Num_0;
2)在进程正式运算前,每个进程各自记录一个检查点,作为初始状态,命名为CK+进程IP+Num_0,进程IP为进程自身所分配的IP地址;
3)系统中每个进程为系统中其他进程维护一个max值列值,所有的max值构成一个列表,列表中所有值初始化为0,列表用以记录接收到某个固定进程的最大消息的编号;
列表用以记录本进程接收系统中其他某个固定进程的所有消息编号中的最大值,列表具体结构如下:
列表由(P-1)个key-value对组成;
其中,P为系统中参与任务的进程个数;key为消息发送端的IP,记为IPsend;value为本端接收IPsend端发送的消息中的消息编号的最大值。即初始化之后,下一步骤进程发送的所有消息按照消息在发送端的发出顺序的消息编号;
4)初始化之后,进程各自运行,发送的所有消息按照消息在发送端的发出顺序进行编号;
5)监控模块对通信状态进行监控,每检测到通信信道有一条消息发送,检查点记录模块记录一个检查点,命名为CKS+源IP+目的IP+Num_M,其中源IP为消息发送源端的IP,目的IP为消息接收端的IP,M为从源IP向目的IP发送的信息编号,并按时间顺序保存在磁盘上;
6)监控模块对通信状态进行监控,每检测到通信信道接收一条消息,检查点记录模块记录一个检查点,命名为CKR+源IP+目的IP+Num_M,其中源IP为消息发送源端的IP,目的IP为消息接收端的IP,M为从源IP向目的IP发送的信息编号,并按时间顺序保存在磁盘上;
7)接收端接收消息记录检查点后,更新max列表;
更新max列表具体步骤如下:
ⅰ)读取检查点的名字,提取源IP记为IPreceived和M值记为Mreceived;
ⅱ)在max列表中寻找key=IPreceived,读取其value值记为Mmax;
ⅲ)如果Mmax<Mreceived,将Mreceived赋值给value,否则不赋值。
监控信道记录检查点具体实施流程如图3,图5所示。
步骤1:将编号计数器数组置为0,编号计数器主要记录本进程发送给系统其它进程的消息条数,本进程和系统其余任何进程都需要一个变量记录,因此需要N-1变量(N为分布式计算环境下运行计算的进程数);
步骤2:监控信道并拦截数据包,这部分主要使用libpcap对IP数据包进行拦截;
步骤3:提取源IP和目的IP,提取的源IP和目的IP主要是用作检查点的命名;
步骤4:在IP数据包数据段末尾添加消息编号,此处主要因为编号的长度不定,为了防止数值过大而编号溢出,数据包最后两个字节是IP数据包编号的长度N,代表编号的长度。最后两个字节之前的倒数第2+N字节到倒数第3字节是正式的编号。新IP数据包的数据具体格式如图4;
步骤5:将添加编号的IP数据包重新发送。
步骤6:记录检查点。
B、检查点恢复:
1)在崩溃进程端寻找所以CKR开头的检查点记录并找到最后记录的检查点CKRlast,并记录其源IP记为IPlast;
由于以CKR开头的检查点在记录时依照接收的顺序进行记录,因此直接寻找最后的CKR检查点。找到检查点后从检查点的名字读取源IP;
2)依照步骤B第1)步中记录的源IPlast,在max列表中寻找key=IPlast,读取其value记为Mmax;
3)将max值发送给步骤B第1)步中的源IPlast所在的进程;
4)崩溃端进程从步骤B第1)步中的检查点CKRlast恢复,恢复后暂停进程;
5)在IPlast端根据max值找到检查点CK+源IP+目的IP+Num_max,从此检查点进行恢复,并通知崩溃端继续运行进程;
6)收到确认消息,恢复任务完成。
上述过程如图6所示。
三、方法基本原理证明:
本方法的思路来自于数据库的transaction。Transaction是具有原子性的执行单元,是不可以破坏的实体,transaction之前是一个逻辑状态,transaction之后又是另一个逻辑状态。在两个进程间进行通讯的时候将一条message看作一个“transaction”,这样消息发送之前的两个进程可以看作是同一个逻辑状态,消息发送之后的两个进程可以看作是另一个逻辑状态。在记录检查点的时候,以消息为单位在通信进程两端相同的逻辑状态记录检查点。具体如图7所示。
多米诺效应分析
将分布式系统进行如下的模型化:
多米诺效应的本质是一个逻辑问题。进程间的每条消息通信都代表一个新的逻辑状态,消息发送的先后决定了逻辑状态的先后顺序,发送消息后的进程或者接收消息的进程的逻辑状态就被更新为消息所在的逻辑状态。因此,在时间维度上每条消息将发送端进程依照消息发送次序分成若干个逻辑状态间隔,接收端依照到达的消息也被分成不同的逻辑状态,而多米诺效应的实质是就是接收端进程检查点所处的逻辑状态晚于发送端的检查点所处的逻辑状态。
一个分布式系统被定义为一组进程的集合,进程通过消息传递信息。每个进程在时间这个维度上被模型化为一系列的逻辑状态序列,每个状态间隔从消息的发送或者接收开始,消息之后进程的逻辑状态就是消息的逻辑状态直到下一个消息的发出或者接收。
每个进程由于通信的对象的不同将通信状态分成不同的模块,例如,P1与进程P2通信的状态集合称为P12,这样进程的状态可以被拆成和不同进程通信的状态的集合。
P={P1,P2,…,Pn},Pi表示进程Pi的所有状态集合,i=1,2,3…n;n>=2。
Pm={Pm-m1,Pm-1m,Pm-m2,Pm-2m,Pm-m3,Pm-3m,…,Pm-mn,Pm-nm},Pm-mi表示从进程m发送,由进程i接收的所有消息及其在发送端引起的状态变化。Pm-im表示从进程i发送由进程m接收的所有消息及其在接收端引起的状态变化。
每条消息记录为Mp-q-n,其中p为发送端的进程号,q为接收端的进程号,n为消息时序编号。
由于协议设置在消息的发送和接收时都要记录检查点,因此需要区分发送端的检查点和接收端的检查点。
发送端的状态为Sp-q-n,其中p为发送端的进程号,q为接收端的进程号,n为逻辑状态编号,并与消息时序编号一致。
接收端的状态为Rp-q-n,其中p为发送端的进程号,q为接收端的进程号。由于进程是到达时不是按顺序到达而是乱序到达,因此,进程的时序状态并不完全依照有消息的逻辑时序决定,因为逻辑时序按照时间只能向前不能退后,因此,n为所有消息中逻辑时序最新的消息的时序。
初始化时的状态记为Ip-0。
Pm-mn={Im-0,Mm-n-1,Sm-n-1,Mm-n-2,Sm-n-2,…,Mm-n-r,Sm-n-r}
Pm-nm={In-0,Mn-m-1,Rn-m-a1,Mn-m-2,Rn-m-a2,…,Mn-m-s,Rn-m-as}
as=max(a1,a2,a3,…,as-1)
由于发送端的逻辑状态代表消息的发送状态,接收端的状态代表消息的接收状态,而根据逻辑上来说消息只有发送了才能接收,因此发送端的时序状态必须大于接收端的时序状态。设发送端选取恢复的检查点所处的逻辑状态为Sm-n-ai,接收端的选取恢复的检查点所处的逻辑状态是Rn-m-aj。则ai>=aj。
而依照本文的方案,系统的选取的是aj=ai。
Claims (4)
1.一种分布式环境下检查点记录和恢复的方法,其特征在于,该方法包括下述步骤:
A、检查点记录:
1)启动计算任务,对系统的监控模块、检查点记录模块和检查点恢复模块进行初始化;
2)在进程正式运算前,每个进程各自记录一个检查点,作为初始状态,命名为CK+进程IP+Num_0,进程IP为进程自身所分配的IP地址;
3)系统中每个进程维护一个max值列表,将max列表中所有value的值初始化为0;
4)初始化之后,进程各自运行,发送的所有消息按照消息在发送端的发出顺序进行编号;
5)监控模块对系统的通信状况进行监控,每检测到通信信道有一条消息发送,检查点记录模块记录一个检查点,命名为CKS+源IP+目的IP+Num_M,其中源IP为消息发送源端的IP,目的IP为消息接收端的IP,M为从源IP向目的IP发送的信息编号,并按时间顺序保存在磁盘上;
6)监控模块对系统的通信状态进行监控,每检测到通信信道接收到一条消息,检查点记录模块记录一个检查点,命名为CKR+源IP+目的IP+Num_M,其中源IP为消息发送源端的IP,目的IP为消息接收端的IP,M为从源IP向目的IP发送的信息编号,并按时间顺序保存在磁盘上;
7)接收端接收消息记录检查点后,更新max列表;
B、检查点恢复:
1)在崩溃进程端寻找所有以CKR开头的检查点记录,并找到最后记录的检查点CKRlast,并记录其源IP为IPlast;
2)依照步骤B第1)步中记录的源IPlast,在max列表中寻找key=IPlast,读取其value记为Mmax;
3)将Mmax发送给步骤B第1)步中的IPlast所在的进程;
4)崩溃端进程从步骤B第1)步中的检查点CKRlast恢复,恢复后暂停进程;
5)在IPlast端根据Mmax值找到检查点CKS+源IP+目的IP+Num_Mmax,从此检查点进行恢复,并通知崩溃端继续运行进程;
6)收到确认消息,恢复任务完成。
2.根据权利要求1所述的分布式环境下检查点记录和恢复的方法,其特征在于,所述步骤A第3)步中,列表用以记录本进程接收系统中其他某个固定进程的所有消息编号中的最大值,列表具体结构如下:
列表由(P-1)个key-value对组成;
其中,P为系统中参与任务的进程个数;key为消息发送端的IP,记为IPsend;value为本端接收IPsend端发送的消息中的消息编号的最大值。
3.根据权利要求2所述的分布式环境下检查点记录和恢复的方法,其特征在于,所述系统中其他某个固定进程的所有消息编号中的最大值,即初始化之后,进程发送的所有消息按照消息在发送端的发出顺序的消息编号。
4.根据权利要求1所述的分布式环境下检查点记录和恢复的方法,其特征在于,所述步骤A第7)步中,更新max列表具体步骤如下:
ⅰ)读取检查点的名字,提取源IP记为IPreceived和M值记为Mreceived;
ⅱ)在max值列表中寻找key=IPreceived,读取其value值记为Mmax;
ⅲ)如果Mmax<Mreceived,将Mreceived赋值给value,否则不赋值。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410816875.9A CN104516790B (zh) | 2014-12-24 | 2014-12-24 | 一种分布式环境下检查点记录和恢复的系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410816875.9A CN104516790B (zh) | 2014-12-24 | 2014-12-24 | 一种分布式环境下检查点记录和恢复的系统及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104516790A CN104516790A (zh) | 2015-04-15 |
CN104516790B true CN104516790B (zh) | 2017-08-25 |
Family
ID=52792141
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410816875.9A Active CN104516790B (zh) | 2014-12-24 | 2014-12-24 | 一种分布式环境下检查点记录和恢复的系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104516790B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109375873B (zh) * | 2018-09-27 | 2022-02-18 | 郑州云海信息技术有限公司 | 一种分布式存储集群中数据处理守护进程的初始化方法 |
CN113515430A (zh) * | 2021-09-14 | 2021-10-19 | 国汽智控(北京)科技有限公司 | 进程的状态监控方法、装置和设备 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1578300A (zh) * | 2003-07-01 | 2005-02-09 | 国际商业机器公司 | 一种检查点处理器和用于管理检查点的方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5839774B2 (ja) * | 2010-01-06 | 2016-01-06 | 三菱重工業株式会社 | 計算機及び計算機管理方法並びに計算機管理プログラム |
-
2014
- 2014-12-24 CN CN201410816875.9A patent/CN104516790B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1578300A (zh) * | 2003-07-01 | 2005-02-09 | 国际商业机器公司 | 一种检查点处理器和用于管理检查点的方法 |
Non-Patent Citations (1)
Title |
---|
分布式系统中回卷恢复技术研究;刘国良;《万方数据库》;20130523;论文正文第2页-第6页,第19页-第23页 * |
Also Published As
Publication number | Publication date |
---|---|
CN104516790A (zh) | 2015-04-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11894972B2 (en) | System and method for data replication using a single master failover protocol | |
US11899684B2 (en) | System and method for maintaining a master replica for reads and writes in a data store | |
US10929240B2 (en) | System and method for adjusting membership of a data replication group | |
CN106406896B (zh) | 一种并行PipeLine技术的区块链建块方法 | |
US9411873B2 (en) | System and method for splitting a replicated data partition | |
US10248704B2 (en) | System and method for log conflict detection and resolution in a data store | |
US9489434B1 (en) | System and method for replication log branching avoidance using post-failover rejoin | |
US8949828B2 (en) | Single point, scalable data synchronization for management of a virtual input/output server cluster | |
CN105959151A (zh) | 一种高可用的流式处理系统及方法 | |
CN103259688B (zh) | 一种分布式存储系统的故障诊断方法与装置 | |
JP2018156683A (ja) | マルチアイテムトランザクションサポートを有するマルチデータベースログ | |
CN106294357A (zh) | 数据处理方法和流计算系统 | |
CN106575251B (zh) | 流数据的推测数据处理 | |
CN107656705B (zh) | 一种计算机存储介质和一种数据迁移方法、装置及系统 | |
CN114064217B (zh) | 一种基于OpenStack的节点虚拟机迁移方法及装置 | |
CN104516790B (zh) | 一种分布式环境下检查点记录和恢复的系统及方法 | |
CN112269690B (zh) | 一种数据备份的方法和装置 | |
CN101986602B (zh) | 基于报文数目检验无阻塞检查点设置和故障进程恢复方法 | |
CN102841840A (zh) | 基于消息重排序和消息数目检验消息日志恢复方法 | |
Awerbuch et al. | Maintaining database consistency in peer to peer networks | |
Helland | Decoupled Transactions: Low Tail Latency Online Transactions Atop Jittery Servers. | |
CN116388990A (zh) | 一种区块链的智能合约系统 | |
CN115174594A (zh) | 分布式系统的数据同步方法、装置、设备及介质 | |
CN115048453A (zh) | 一种数据同步的方法、装置、设备及存储介质 | |
Zhang et al. | ZooKeeper+: The Optimization of Election Algorithm in Complex Network Circumstance |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |