CN103795754A - 多***间的数据同步方法和*** - Google Patents
多***间的数据同步方法和*** Download PDFInfo
- Publication number
- CN103795754A CN103795754A CN201210427781.3A CN201210427781A CN103795754A CN 103795754 A CN103795754 A CN 103795754A CN 201210427781 A CN201210427781 A CN 201210427781A CN 103795754 A CN103795754 A CN 103795754A
- Authority
- CN
- China
- Prior art keywords
- data
- centroid
- partial node
- operation instruction
- atomic operation
- 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.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提出多***间的数据同步方法和***。由中心节点进行基于统一时间轴的时间同步,分节点向中心节点以版本号v0、以及版本号对应数据的校验摘要值s0请求增量数据;中心节点以版本号Vi以及校验摘要值Si应答分节点;分节点获取到增量数据后,对副本执行增量操作;根据副本执行结果计算本地摘要s1;若s1==Si,则分节点与中心节点数据一致;分节点取本地最新的版本号v1,若v1<Vi,则将v1=Vi,即,分节点本地最新的版本号低于中心节点的版本号,用中心节点的版本号对本地最新的版本号进行更新。本发明实现多***间数据同步的高效低耗以及同步后数据一致性。
Description
技术领域
本发明属于多副本、分布式节点之间的数据同步处理领域,尤其涉及多***间的数据同步方法和***。
背景技术
多***可理解为有共同关注数据类型的不同业务***,比如:IM(Instant Messaging,即时通讯)***、邮箱***与短信***,通讯录为其共同关注的数据类型。多***间的数据同步技术着重于如何架构高效、高可靠性、高准确性的数据同步***。
当前多***间的同步,主要有三种:一对多、多对一单向模型,多对一,一对多双向混合模型,其中以一对多和多对一两种结构的数据同步模型居多。
图1为现有技术的一对多单向模型示意图。
一对多***的数据同步中,中心节点为源数据节点,生成业务数据并承担分发职能,各分节点为数据目的节点,接收分发的业务数据并面向用户。
图2为现有技术的多对一单向模型示意图。
多对一***模型中,各分节点为实际业务节点,为源数据节点,各分节点将业务数据汇聚到中心节点,中心节点多承担数据的统计分析职能。
这两种同步模型中,数据的流向实际为单向,业务模式相对简单,技术实现也可采用相对简单的传输-等待-反馈的同步方式。
图3为现有技术的多对一,一对多多点双向混合同步模型示意图。
传统的多对一,一对多多点双向混合同步模型,其时序上一般采用传输-等待-反馈的同步时序,这种模式用以下的例子进行说明。
中心节点向分节点A***同步数据,中心节点先将数据传输给分节点A,分节点A本地处理成功后,将结果返回给中心节点,而分节点A在本地处理过程中,中心节点一直处于等待状态。扩展到多***间的数据同步,比如,存在分节点B、C、D...等多个分***,因为这种传输-等待-反馈的同步方式,则整个***的效率取决于效率最低的分***,至于为什么传统的数据同步要采用这种同步时序,是因为这种时序模式能够有效的确保数据同步的准确性。
对于多对一,一对多多点双向混合同步模型,时序上采用传输-等待-反馈的同步模式将使得***间的耦合度陡升,并对整个***产生致命的短板效应。
当前业界有多***间同步需求的产品,一般采取基于集中存储的数据共享模式,而非分布式的基于中心同步引擎节点的多点、多副本双向同步方式。例如,某项数据集中存储在北京的某个IDC,而业务平台部署在广州的IDC,那么,当用户需要访问该数据时,需要先向广州本地业务平台请求数据,再由广州业务平台转发至北京IDC请求数据,这样就会多一层转发路由,从而造成获取数据的时延增大。
极少数有多点、多副本需求的产品采用的同步方式也是基于一种高耦合的单向同步处理方式,即:中心节点传输至某分节点A***并等待A节点处理结果,A处理成功后,A向中心节点返回其结果,一次同步过程结束。从该流程中可以看出,中心节点受目的节点***限制,以这样的算法搭建的多***数据同步模型,其整体性能出现木桶原理所致的短板效应。
因此,现有技术的同步过程使得多***间数据同步的效率低、数据一致性差。
发明内容
鉴于以上,本发明提出多***间的数据同步方法和***。
根据本发明一方面,提出多***间的数据同步方法,包括以下步骤:
分节点产生数据更新请求,并在分节点的***时间t1将所述数据更新请求提交给中心节点;
中心节点记录其接收到分节点的所述数据更新请求时中心节点的***时间t0,并计算其与分节点的***时间差△t=t0-t1;
中心节点从原子操作指令中获取产生数据更新请求的用户在所述数据更新请求产生的时间+△t之后的、对要进行更新的数据的所有增量操作;
分节点向中心节点以版本号v0、以及所述版本号对应数据的校验摘要值s0请求增量数据;
中心节点以版本号Vi以及校验摘要值Si应答分节点,角标i取值为大于等于0的整数;
分节点返回应答,表示已经正确接收到数据,生成本地数据副本;
分节点获取到增量数据后,分别对源本与副本执行增量操作;
分节点根据副本执行结果计算本地摘要s1;
分节点做摘要比对,若s1==Si,则表示校验通过,即分节点与中心节点数据一致;
分节点取本地最新的版本号v1,若v1<Vi,则将v1=Vi,即,分节点本地最新的版本号低于中心节点的版本号,用中心节点的版本号对本地最新的版本号进行更新。
进一步,分节点与中心节点数据不一致,进入数据自恢复流程,包括以下步骤:
当分节点有数据更新时,分节点调用第一用户接口向中心节点提交更新请求,更新请求的内容就是此次更新的原子操作指令集;
中心节点正确应答,该流程结束,否则,分节点将该次更新请求的原子操作指令作为故障点移入故障栈中进行待处理;
分节点触发向中心节点的增量请求;
分节点执行完增量指令后,进入校验过程,如果校验通过,则流程结束,否则,分节点询问故障栈中是否存在故障点;
若故障栈中存在故障点,分节点调用第二用户接口,向中心节点请求执行源故障指令的重新再执行,如果中心节点正确响应,流程结束,否则,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致;
若故障栈中不存在故障点,则直接进入数据自恢复过程,即,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致,其中,有限冗余自恢复算法是在两端数据出现不一致后,分节点将其所有数据提交给中心节点,中心节点做字段级核对后取合集即,同样的数据只取一条,然后将全集数据分发给分节点。
进一步,中心节点执行源故障指令的重新再执行,包括至少如下之一:
若数据更新请求所对应的原子操作指令为新增,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为删除,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为更新,则直接按照字段进行合并,即冲突字段以时间靠后为准,字段空值与非空值取合集。
进一步,所述校验包括弱校验和强校验,其中:
弱校验是指对两个***间参与同步的部分数据结构做摘要,摘要即哈希,然后比对其一致性来判断数据是否一致;
强校验是指对两个***间参与同步的所有数据结构做摘要,然后比对其一致性来判断***间数据是否一致。
根据本发明另一方面,提出多***间的数据同步***,其中:
分节点,产生数据更新请求,并在分节点的***时间t1将所述数据更新请求提交给中心节点;向中心节点以版本号v0、以及所述版本号对应数据的校验摘要值s0请求增量数据;分节点返回应答,表示已经正确接收到数据,生成本地数据副本;获取到增量数据后,分别对源本与副本执行增量操作;根据副本执行结果计算本地摘要s1;做摘要比对,若s1==Si,则表示校验通过,即分节点与中心节点数据一致;获取本地最新的版本号v1,若v1<Vi,则将v1=Vi,即,分节点本地最新的版本号低于中心节点的版本号,用中心节点的版本号对本地最新的版本号进行更新;
中心节点,记录其接收到分节点的所述数据更新请求的中心节点的***时间t0,并计算其与分节点的***时间差△t=t0-t1;从原子操作指令中获取产生数据更新请求的用户在所述数据更新请求产生的时间+△t之后的、对要进行更新的数据的所有增量操作;以版本号Vi以及校验摘要值Si应答分节点,角标i取值为大于等于0的整数。
进一步,分节点与中心节点数据不一致,分节点调用第一用户接口向中心节点提交更新请求,更新请求的内容就是此次更新的原子操作指令集;当中心节点未正确应答,分节点将更新请求的原子操作指令作为故障点移入故障栈中进行待处理;触发向中心节点的增量请求,分节点执行完增量指令后,进入校验过程,如果校验通过,则流程结束,否则,分节点询问故障栈中是否存在故障点;
若故障栈中存在故障点,分节点调用第二用户接口,向中心节点请求执行源故障指令的重新再执行,如果中心节点正确响应,流程结束,否则,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致;
若故障栈中不存在故障点,则直接进入数据自恢复过程,即,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致,其中,有限冗余自恢复算法是在两端数据出现不一致后,分节点将其所有数据提交给中心节点,中心节点做字段级核对后取合集即,同样的数据只取一条,然后将全集数据分发给分节点。
进一步,中心节点执行源故障指令的重新再执行,包括至少如下之一:
若数据更新请求所对应的原子操作指令为新增,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为删除,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为更新,则直接按照字段进行合并,即冲突字段以时间靠后为准,字段空值与非空值取合集。
进一步,所述校验包括弱校验和强校验,其中:
弱校验是指对两个***间参与同步的部分数据结构做摘要,然后比对其一致性来判断数据是否一致,摘要即哈希;
强校验是指对两个***间参与同步的所有数据结构做摘要,然后比对其一致性来判断***间数据是否一致。
本发明实现多***间数据同步的高效低耗、以及同步后数据一致性。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本发明的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为现有技术的一对多单向模型示意图。
图2为现有技术的多对一单向模型示意图。
图3为现有技术的多对一,一对多多点双向混合同步模型示意图。
图4为本发明基于统一时间轴的时序控制流程图。
图5为本发明数据校验算法流程图。
图6为本发明断点保护算法流程图。
图7为本发明摘要计算示例。
具体实施方式
现在将参照附图来详细描述本发明的各种示例性实施例。应注意到:除非另外具体说明,否则在这些实施例中阐述的部件和步骤的相对布置和数值不限制本发明的范围。
同时,应当明白,为了便于描述,附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
以下对至少一个示例性实施例的描述实际上仅仅是说明性的,决不作为对本发明及其应用或使用的任何限制。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论,但在适当情况下,所述技术、方法和设备应当被视为授权说明书的一部分。
在这里示出和讨论的所有示例中,任何具体值应被解释为仅仅是示例性的,而不是作为限制。因此,示例性实施例的其它示例可以具有不同的值。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步讨论。
***间数据同步,重点考量数据同步的高效低耗、以及同步后数据的一致性。多***间的数据同步对于这两点的要求显得尤为重要,若控制不当,单点的错误会迅速在多点蔓延;多***间数据的实时同步是一个存在较大业务和技术复杂度的课题,业界尚无较为成熟的技术解决方案。为实现多***间数据同步的高效低耗、以及同步后数据一致性的目标,本发明提出多***间的数据同步方法和***。
本发明的数据同步包括时序控制和数据校验,还可以包括数据自恢复流程,即断点保护。下面将结合附图进行详细说明。
图4为本发明基于统一时间轴的时序控制流程图。
多***间的数据同步模型中,各***节点既为数据的生产者,又作为数据的消费者,且各节点均能对同一数据做更新。中心节点作为数据的汇聚和转发中心必须要有一套严格的时序控制机制,才能确保数据的有序流转。本发明中采用将各***产生的数据更新校准到统一的时间轴上,从而确保了在准实时的数据同步中,数据能够有序的在各节点间流动。具体流程详细见图4。
S401、某个分节点产生数据更新请求,在t1(该分节点的***时间)将数据更新请求提交给中心节点。该数据更新请求可以包括:该条数据的用户属性uid、该条数据的唯一标识cid、该条数据更新所对应的原子操作指令cmd、该原子操作指令产生的时间cmd.t、以及本次更新所产生的原子操作指令数cmd.count。
例如,用户uid拥有某条联系人数据cid,唯一标识可由任意一个节点按照统一规范生成,所有分节点以及中心节点在同步过程中均用此cid来标识该条数据。用户uid在分组A下面添加了一个联系人a,则可拆分成两个原子操作指令,add contact“a”与add contact“a”to group“A”。原子操作指令数为原子操作指令的条数,那么,对于该实施例,原子操作指令数为2。
S402、中心节点记录其收到该分节点的数据更新请求的时间t0(中心节点此时刻的***时间)。
S403、中心节点计算其与分节点的***时间差△t=t0-t1。
S404、中心节点从历史增量表获取该用户uid的具有唯一标识cid的数据在操作时间cmd.t+△t之后的所有增量操作cmds1。历史增量表记录的就是所有用户对数据的原子操作指令。
到该步骤为止,已经实现了对于时序较为严格的控制,确保数据基于统一的时间轴在各节点间有序流动。
图5为本发明数据校验算法流程图。
由于各***在整体构成、程序语言、数据格式等方面的差异性,再加上网络传输过程中可能的报文损坏、丢失等因素,使得数据在***各节点流转过程中会产生一定概率的数据失真,而这种失真在多节点流转中会出现叠加和放大效应,使得数据同步的可用性变得不可忍受。另外,多***、多副本双向同步模型不适宜采用传输-等待-反馈的高耦合同步模式。
所以,本发明采用传输-返回-校验的异步模式,针对多***间数据同步提出了数据校验机制,即弱校验,也可以进行强校验。该算法承认***间的异构性以及网络的不稳定会使数据的同步存在天然的缺陷,解决方案不是穷尽可能的代码优化,而是通过一套事后校验机制。进一步,还通过有限冗余数据自恢复机制来确保数据在出现同步失真后具备自恢复能力,从而保障数据的完整性和一致性。
弱校验是指对两个***间参与同步的部分数据结构做摘要,然后比对其一致性来判断数据是否一致。
强校验是指对两个***间参与同步的所有数据结构做摘要,然后比对其一致性来判断***间数据是否一致。
比如,我们的通讯录有姓名,手机,邮箱,固话,传真,职务等等几十个字段以及组关系,弱校验为对联系人总数以及组关系做摘要校验,强校验对通讯录的完整数据结构做摘要校验,即,将该数据的所有字段以及组关系按照一定的序列化方式做摘要校验。
强、弱校验有效保证多***间数据同步的一致性和完整性,一致性就是判定同步后中心节点和分节点数据是否一致,通过比对两份数据的摘要,若摘要一致则数据一致。既能平衡业务体验和***性能的高性价比,又有效解决了数据准确性和同步高效性的动态平衡。完整性,例如,有数据a,b,c,d,则数据经过若干次同步后(未执行删除操作),应仍然为a,b,c,d。
下面将通过实例说明强校验和弱校验的策略控制。以通信录***的数据同步作为描述蓝本。例如,在通讯录数据的实际使用中90%的用户视觉焦点集中在联系人的数量以及组关系上,而对联系人的详细属性则主要在实际沟通时才会注意到。因此,技术实现时,每次同步过程中可以采用***开销较低的弱校验,而强校验则根据***间的健壮性确定校验周期,并且安排到***闲时进行。再通过有限冗余数据自恢复算法保持差异双方***数据的一致。
下面将详细描述数据一致性控制算法。
S501、分节点向中心节点以版本号v0,以及该版本号对应数据的校验摘要值s0请求增量数据,中心节点应答Vi以及Si。
比如,某个分节点的数据版本号为v0,该版本号所对应的弱校验摘要值为s0,而此时,若中心节点的数据已经更新到版本vi和si了,则v0与vi之间的差异即增量数据,而s0与si仅表示其所对应版本的校验摘要值。
各分节点对于数据的版本号只维护,不生成,数据版本号统一由中心节点生成并传递,版本号为自增ID(标识)。Vi以及Si的角标i取自增数,比如0,1,2......,即角标i取值为大于等于0的整数。Vi指版本号,Si指该版本对应的摘要值。在具体实施例中,可以在获取增量数据的请求中携带强校验摘要值,也可以携带弱校验摘要值。弱校验的计算过程是,可以只选取关键的信息序列化后计算摘要,而不是全部数据。
S502、分节点返回“200 OK”,表示已经正确接收到数据,分节点生成本地数据副本。这里所说的数据,比如,通讯录数据、产品数据(型号,各项配置等等)。
S503、分节点获取到增量数据后,分别对源本与副本执行增量操作。对源本执行增量操作即是对数据执行正常的update,也就是正常的更新数据。对副本执行增量操作,这是因为在分节点执行增量的过程中,分节点有可能产生新的增量,需要对数据做即时保护,确保摘要校验的有效性。
S504、根据副本执行结果计算本地摘要s1。Update副本数据后,对数据做摘要即可计算本地摘要s1。摘要计算示例如图7所示,其中,组按照GroupID升序排列。
摘要即哈希,将任意长度的二进制值映射为固定长度的较小二进制值,这个较小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。比如,某个用户的联系人数据对应的摘要值为:y3K5lBFXG1ozMgV1lgeOHw==。
S505、分节点做摘要比对,判断s1==Si,如果是,进入S506,否则,进入S507。
S506、校验通过,分节点与中心节点数据一致,继续S508。
S507、校验未通过,进入数据自恢复流程。数据自恢复流程将在下面结合图6进行详细说明。
S508、分节点与中心节点数据一致,分节点取本地最新的版本号v1,判断分节点本地最新的版本号是否低于中心节点的版本号,即,是否v1<Vi,如果是,进入S509,否则,进入S510。
S509、将v1=Vi,用中心节点的版本号对本地最新的版本号进行更新。
S510、不做处理。
本发明的数据一致性控制算法对校验的频率进行了有效的控制,因为同步是双向的,无需每次都进行校验,只需要维持单向的校验频率就可以保持数据的一致性在99.9%以上。
以下数据是该算法在某一通信录平台上实践时采集统计的,以一天的同步数据作为样本(样本数据>100万):
类别 | 数据一致率 | 占用***开销 | 同步性能(数据延时) |
单向校验 | 99.981% | 约5% | 约5~10S |
双向校验 | 99.995% | 约12% | 约20~30S |
从上表可见,本发明的数据一致性控制过程大大节省了***开销、并提升了同步性能。
本发明的多***同步采用了异步接口处理机制,规避了短板效应,处理方式的核心就是传输-返回-校验。即,中心节点传输至分节点A***,分节点A接收后即向中心节点返回“200 OK”,表示已经正确接收到数据,节点A处理完后再自行对数据进行一致性校验,若数据一致,则结束。若数据不一致,还可以按照有限冗余数据自恢复算法进行数据恢复。
这样,整个同步***的整体性能不会因为某个***性能低下而被拖累,并且,附加校验机制也确保同步数据的一致性。本发明降低了***间的耦合,提高数据流转的效率并达到较高的***可用性。例如,多***间同步应用于通信录项目,在每天高达100万次的数据同步中,数据同步时延控制在15S内,数据同步可靠率达到99.9%以上。
在本发明多***间数据同步的另一实施例中,由于接口故障所产生的数据指令断点将被记录并采用故障栈方式进行回收,结合校验机制,对回收的故障指令进行出栈再处理,从而保证数据具备多重恢复窗口。
图6为本发明断点保护算法流程图。也就是数据自恢复算法的流程,是图5中校验失败后需要执行的流程。
S601、当分节点有数据更新时,分节点调用第一UI(UserInterface,用户接口)向中心节点提交更新请求,更新请求的内容就是此次更新的原子操作指令集。
S602、中心节点是否正确应答,正确应答是指中心节点收到了分节点提交的更新请求后,返回给中心节点200 OK,中心节点收到分节点的更新指令,并置入执行队列即会向分节点正确应答。如果是,该流程结束,否则,进入S603。
S603、将该次更新请求的原子操作指令作为故障点移入故障栈中进行待处理。
S604、分节点触发向中心节点的增量请求,调用获取增量接口(Get User data interface,GUI)。可由分节点根据自身的业务特点来决定触发时间,比如:用户在分节点登陆,查询,导出等等。
S605、分节点执行完增量指令后,进入校验过程,这里所执行的增量指令,即为获取增量数据后,计算摘要并进行摘要比对。判断校验是否通过,如果校验通过,则流程结束,否则,进入S606。
S606、分节点询问故障栈中是否存在故障点,即S603中提及的故障栈。若故障栈中存在故障点,进入S607,否则,进入S609。
S607、分节点调用第二UI,向中心节点请求执行源故障指令的重新再执行,即,向中心节点发送数据更新请求,继续S608。源故障指令的重新再执行是指分节点在向中心节点传递指令时因为某种原因而未执行成功,置入故障栈中的指令的再次执行。
中心节点对各分节点的指令进行了容错处理,确保不因某个分节点提交的冗余指令而导致数据混乱。下面将详细说明中心节点执行的容错处理。本领域技术人员应该可以理解,所做说明只是示例性的,不应理解为对本发明的限制。
对增量操作cmds1与原子操作指令cmd执行以下操作:
若cmd==add指令,即新增,则继续判断cmds1.count(指令数)是否为0,若为0,则执行cmd指令,并在历史增量表中记录该cmd指令,若不为0,则不执行cmd指令,但是在历史增量表中记录该cmd指令。
如果cmds1.count()为0,说明cmd指令后没有更新操作,所以正常执行cmd,若不等于0,则说明cmd指令之后已经有了针对该条数据的更新操作,该指令已经是陈旧指令了。
比如,某个分节点增加一条数据add contact a,分节点将此数据同步给中心节点,但是此时因为某种原因,发生了故障,没有同步成功,该条指令被存入了分节点的故障栈中保存起来,若下一个时间点,用户对这条数据做了更新,update contact a.mobilephone to 189。若某次校验时,校验未通过,分节点会从故障栈中先取出未执行的指令addcontact a给中心节点,而此时分节点因为已经执行完了add contact a后的指令,所以也就不需要再执行add contact a指令了。
若cmd==delete指令,即删除,则继续判断cmds1.count(指令数)是否为0,若为0,则执行cmd指令,并在历史增量表中记录该cmd指令,若不为0,则不执行该cmd指令,但是在历史增量表中记录该cmd指令。
若cmd==update指令,即更新,则直接按照字段进行合并,合并算法核心准则:冲突字段以时间靠后为准,字段空值与非空值取合集。
S608、判断中心节点是否正确应答,如果中心节点正确应答,正确应答是指中心节点收到了分节点提交的更新请求后,返回给中心节点200 OK。流程结束。否则,进入S609。
S609、分节点调用中心节点提供的数据自恢复接口(RecoveryInterface,RI),执行有限冗余自恢复算法,使数据恢复一致。本次操作结束。
自恢复算法,即,在两端数据出现不一致后,分节点将其所有数据提交给中心节点,中心节点做字段级核对后取合集(即:同样的数据只取一条),然后将全集数据分发给分节点。有限冗余数据自恢复算法既确保数据能够自恢复,而又保证数据不出现大面积冗余。
在该实施例中,即使某些处理环节上遇到了***错误,无正常响应也会退出流程,这体现了有原则的重试机制,这对于一个涉及多节点的复杂***来说显得尤为重要。因为只要存在多次数据恢复窗口,就可以不必寻求在某次恢复窗口中一定恢复数据,从而避免给整个***带来巨大的性能风险,并且在高准确性与效率之间找到一个恰当的平衡。
多次数据恢复窗口机制是:一旦数据不一致,每次用户活跃或者数据的更新,都会因为弱校验不一致而触发数据自恢复,若某次恢复不成功,不会再始终进行轮询,而是等待下一次的恢复窗口。
本发明在所有环节上,均追求并达到***开销与综合性能的平衡点,比如弱校验,单向校验,有限重试等。
本发明中对节点的双向同步中指令的传递,均采用异步方式,以有效减少***间的耦合,这在多***的同步模型中显得尤为重要且必须,因为若采用同步方式,则一个***的性能瓶颈将放大到整个***,造成整个***性能的降低,在极端情况下,一个***的故障可能造成整个***的瘫痪。
本发明中对于数据的一致性和准确性,不完全依赖于***之间接口的绝对健壮性来保障,而是采用强、弱校验的方式以及有限冗余数据自恢复方式来进行保证。
本发明还提出多***间的数据同步***,该***包括分节点以及中心节点。
分节点产生数据更新请求,并在分节点的***时间t1将所述数据更新请求提交给中心节点。
中心节点记录其接收到分节点的所述数据更新请求的中心节点的***时间t0,并计算其与分节点的***时间差Δt=t0-t1。从原子操作指令中获取产生数据更新请求的用户在所述数据更新请求产生的时间+Δt之后的、对要进行更新的数据的所有增量操作。
分节点向中心节点以版本号v0、以及所述版本号对应数据的校验摘要值s0请求增量数据。
这里所说的校验包括弱校验和强校验,其中,弱校验是指对两个***间参与同步的部分数据结构做摘要,然后比对其一致性来判断数据是否一致。强校验是指对两个***间参与同步的所有数据结构做摘要,然后比对其一致性来判断***间数据是否一致。
中心节点以版本号Vi以及校验摘要值Si应答分节点,角标i取值为大于等于0的整数。
分节点返回应答,表示已经正确接收到数据,生成本地数据副本。获取到增量数据后,分别对源本与副本执行增量操作。根据副本执行结果计算本地摘要s1,做摘要比对,若s1==Si,则表示校验通过,即分节点与中心节点数据一致。获取本地最新的版本号v1,若v1<Vi,则将v1=Vi,即,分节点本地最新的版本号低于中心节点的版本号,用中心节点的版本号对本地最新的版本号进行更新。
在本发明的一个***实施例中,分节点与中心节点数据不一致,执行数据自恢复流程。
分节点调用第一用户接口向中心节点提交更新请求,更新请求的内容就是此次更新的原子操作指令集。
中心节点正确应答,流程结束。
当中心节点未正确应答,分节点将更新请求的原子操作指令作为故障点移入故障栈中进行待处理;分节点触发向中心节点的增量请求,分节点执行完增量指令后,进入校验过程,如果校验通过,则流程结束,否则,分节点询问故障栈中是否存在故障点。
若故障栈中存在故障点,分节点调用第二用户接口,向中心节点请求执行源故障指令的重新再执行,如果中心节点正确响应,流程结束,否则,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致。
若故障栈中不存在故障点,则直接进入数据自恢复过程,即,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致,其中,有限冗余自恢复算法是在两端数据出现不一致后,分节点将其所有数据提交给中心节点,中心节点做字段级核对后取合集即,同样的数据只取一条,然后将全集数据分发给分节点。
在本发明的一个***实施例中,中心节点对各分节点的指令进行了容错处理,即,发生故障时的断点保护以及断点的重新执行,中心节点执行源故障指令的重新再执行,包括至少如下之一:
若数据更新请求所对应的原子操作指令为新增,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令。
若数据更新请求所对应的原子操作指令为删除,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令。
若数据更新请求所对应的原子操作指令为更新,则直接按照字段进行合并,即冲突字段以时间靠后为准,字段空值与非空值取合集。
至此,已经详细描述了本发明。为了避免遮蔽本发明的构思,没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述,完全可以明白如何实施这里公开的技术方案。
可能以许多方式来实现本发明的方法以及装置。例如,可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法以及装置。用于所述方法的步骤的上述顺序仅是为了进行说明,本发明的方法的步骤不限于以上具体描述的顺序,除非以其它方式特别说明。此外,在一些实施例中,还可将本发明实施为记录在记录介质中的程序,这些程序包括用于实现根据本发明的方法的机器可读指令。因而,本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。
虽然已经通过示例对本发明的一些特定实施例进行了详细说明,但是本领域的技术人员应该理解,以上示例仅是为了进行说明,而不是为了限制本发明的范围。本领域的技术人员应该理解,可在不脱离本发明的范围和精神的情况下,对以上实施例进行修改。本发明的范围由所附权利要求来限定。
Claims (8)
1.多***间的数据同步方法,其特征在于:
分节点产生数据更新请求,并在分节点的***时间t1将所述数据更新请求提交给中心节点;
中心节点记录其接收到分节点的所述数据更新请求时中心节点的***时间t0,并计算其与分节点的***时间差△t=t0-t1;
中心节点从原子操作指令中获取产生数据更新请求的用户在所述数据更新请求产生的时间+△t之后的、对要进行更新的数据的所有增量操作;
分节点向中心节点以版本号v0、以及所述版本号对应数据的校验摘要值s0请求增量数据;
中心节点以版本号Vi以及校验摘要值Si应答分节点,角标i取值为大于等于0的整数;
分节点返回应答,表示已经正确接收到数据,生成本地数据副本;
分节点获取到增量数据后,分别对源本与副本执行增量操作;
分节点根据副本执行结果计算本地摘要s1;
分节点做摘要比对,若s1==Si,则表示校验通过,即分节点与中心节点数据一致;
分节点取本地最新的版本号v1,若v1<Vi,则将v1=Vi,即,分节点本地最新的版本号低于中心节点的版本号,用中心节点的版本号对本地最新的版本号进行更新。
2.根据权利要求1所述多***间的数据同步方法,其特征在于:
分节点与中心节点数据不一致,进入数据自恢复流程,包括以下步骤:
当分节点有数据更新时,分节点调用第一用户接口向中心节点提交更新请求,更新请求的内容就是此次更新的原子操作指令集;
中心节点正确应答,该流程结束,否则,分节点将该次更新请求的原子操作指令作为故障点移入故障栈中进行待处理;
分节点触发向中心节点的增量请求;
分节点执行完增量指令后,进入校验过程,如果校验通过,则流程结束,否则,分节点询问故障栈中是否存在故障点;
若故障栈中存在故障点,分节点调用第二用户接口,向中心节点请求执行源故障指令的重新再执行,如果中心节点正确响应,流程结束,否则,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致;
若故障栈中不存在故障点,则直接进入数据自恢复过程,即,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致,其中,有限冗余自恢复算法是在两端数据出现不一致后,分节点将其所有数据提交给中心节点,中心节点做字段级核对后取合集即,同样的数据只取一条,然后将全集数据分发给分节点。
3.根据权利要求2所述多***间的数据同步方法,其特征在于:
中心节点执行源故障指令的重新再执行,包括至少如下之一:
若数据更新请求所对应的原子操作指令为新增,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为删除,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为更新,则直接按照字段进行合并,即冲突字段以时间靠后为准,字段空值与非空值取合集。
4.根据权利要求1或2或3所述多***间的数据同步方法,其特征在于:
所述校验包括弱校验和强校验,其中:
弱校验是指对两个***间参与同步的部分数据结构做摘要,摘要即哈希,然后比对其一致性来判断数据是否一致;
强校验是指对两个***间参与同步的所有数据结构做摘要,然后比对其一致性来判断***间数据是否一致。
5.多***间的数据同步***,其特征在于:
分节点,产生数据更新请求,并在分节点的***时间t1将所述数据更新请求提交给中心节点;向中心节点以版本号v0、以及所述版本号对应数据的校验摘要值s0请求增量数据;分节点返回应答,表示已经正确接收到数据,生成本地数据副本;获取到增量数据后,分别对源本与副本执行增量操作;根据副本执行结果计算本地摘要s1;做摘要比对,若s1==Si,则表示校验通过,即分节点与中心节点数据一致;获取本地最新的版本号v1,若v1<Vi,则将v1=Vi,即,分节点本地最新的版本号低于中心节点的版本号,用中心节点的版本号对本地最新的版本号进行更新;
中心节点,记录其接收到分节点的所述数据更新请求的中心节点的***时间t0,并计算其与分节点的***时间差Δt=t0-t1;从原子操作指令中获取产生数据更新请求的用户在所述数据更新请求产生的时间+Δt之后的、对要进行更新的数据的所有增量操作;以版本号Vi以及校验摘要值Si应答分节点,角标i取值为大于等于0的整数。
6.根据权利要求5所述多***间的数据同步***,其特征在于:
分节点与中心节点数据不一致,分节点调用第一用户接口向中心节点提交更新请求,更新请求的内容就是此次更新的原子操作指令集;当中心节点未正确应答,分节点将更新请求的原子操作指令作为故障点移入故障栈中进行待处理;触发向中心节点的增量请求,分节点执行完增量指令后,进入校验过程,如果校验通过,则流程结束,否则,分节点询问故障栈中是否存在故障点;
若故障栈中存在故障点,分节点调用第二用户接口,向中心节点请求执行源故障指令的重新再执行,如果中心节点正确响应,流程结束,否则,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致;
若故障栈中不存在故障点,则直接进入数据自恢复过程,即,分节点调用中心节点提供的数据自恢复接口,执行有限冗余自恢复算法,使数据恢复一致,其中,有限冗余自恢复算法是在两端数据出现不一致后,分节点将其所有数据提交给中心节点,中心节点做字段级核对后取合集即,同样的数据只取一条,然后将全集数据分发给分节点。
7.根据权利要求6所述多***间的数据同步***,其特征在于:
中心节点执行源故障指令的重新再执行,包括至少如下之一:
若数据更新请求所对应的原子操作指令为新增,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为删除,则继续判断原子操作指令数是否为0,若为0,则执行并记录所述原子操作指令,若不为0,则不执行所述原子操作指令,但记录所述原子操作指令;
若数据更新请求所对应的原子操作指令为更新,则直接按照字段进行合并,即冲突字段以时间靠后为准,字段空值与非空值取合集。
8.根据权利要求5或6或7所述多***间的数据同步***,其特征在于:
所述校验包括弱校验和强校验,其中:
弱校验是指对两个***间参与同步的部分数据结构做摘要,然后比对其一致性来判断数据是否一致,摘要即哈希;
强校验是指对两个***间参与同步的所有数据结构做摘要,然后比对其一致性来判断***间数据是否一致。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210427781.3A CN103795754B (zh) | 2012-10-31 | 2012-10-31 | 多***间的数据同步方法和*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210427781.3A CN103795754B (zh) | 2012-10-31 | 2012-10-31 | 多***间的数据同步方法和*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103795754A true CN103795754A (zh) | 2014-05-14 |
CN103795754B CN103795754B (zh) | 2017-08-25 |
Family
ID=50671035
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210427781.3A Active CN103795754B (zh) | 2012-10-31 | 2012-10-31 | 多***间的数据同步方法和*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103795754B (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104346479A (zh) * | 2014-11-26 | 2015-02-11 | 北京奇虎科技有限公司 | 一种数据库同步方法及装置 |
CN105335443A (zh) * | 2014-08-13 | 2016-02-17 | 阿里巴巴集团控股有限公司 | 一种用于数据同步中的异常检测的方法与设备 |
CN105592118A (zh) * | 2014-10-23 | 2016-05-18 | 阿里巴巴集团控股有限公司 | 同步用户应用数据的方法、***及服务端 |
WO2016180168A1 (zh) * | 2015-05-11 | 2016-11-17 | 阿里巴巴集团控股有限公司 | 一种数据复制方法和设备 |
CN106202387A (zh) * | 2016-07-08 | 2016-12-07 | 陈光宇 | 一种数据一致性并行维护方法 |
CN106599195A (zh) * | 2016-12-14 | 2017-04-26 | 北京邮电大学 | 一种海量网络数据环境下的元数据同步方法及*** |
CN106775837A (zh) * | 2016-11-29 | 2017-05-31 | 北京元心科技有限公司 | 多***的全局配置同步方法及装置 |
CN107409369A (zh) * | 2015-03-26 | 2017-11-28 | 华为技术有限公司 | 移动核心数据服务的***和方法 |
CN108259562A (zh) * | 2017-12-11 | 2018-07-06 | 杭州品茗安控信息技术股份有限公司 | 一种基于多端点的数据同步方法及装置 |
CN109213769A (zh) * | 2017-06-30 | 2019-01-15 | 华为技术有限公司 | 一种数据对象的数据冲突识别方法 |
CN111845630A (zh) * | 2020-06-08 | 2020-10-30 | 北京百度网讯科技有限公司 | 车辆个性化控制方法、装置、***、电子设备及存储介质 |
US11132265B2 (en) | 2016-12-22 | 2021-09-28 | Huawei Technologies Co., Ltd. | Multi-replica data restoration method and apparatus |
CN115037752A (zh) * | 2022-04-22 | 2022-09-09 | 网易(杭州)网络有限公司 | 资源再分配方法、装置及电子设备 |
CN115086065A (zh) * | 2022-07-12 | 2022-09-20 | 北斗星通智联科技有限责任公司 | 一种基于区块链的数据同步方法、装置、电子设备及介质 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109101627B (zh) * | 2018-08-14 | 2022-03-22 | 交通银行股份有限公司 | 异构数据库同步方法及装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040133591A1 (en) * | 2001-03-16 | 2004-07-08 | Iti, Inc. | Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates only |
WO2006076530A2 (en) * | 2005-01-12 | 2006-07-20 | Wandisco, Inc. | Distributed computing systems and system components thereof |
CN101242302A (zh) * | 2008-03-12 | 2008-08-13 | 华为技术有限公司 | 一种数据同步的方法、设备及*** |
CN101826073A (zh) * | 2009-03-06 | 2010-09-08 | 华为技术有限公司 | 分布式数据库同步方法、设备及*** |
CN102025756A (zh) * | 2009-09-09 | 2011-04-20 | 中兴通讯股份有限公司 | 分布式***及其数据同步方法 |
CN102088489A (zh) * | 2010-12-31 | 2011-06-08 | 北京理工大学 | 一种分布式数据同步***及方法 |
-
2012
- 2012-10-31 CN CN201210427781.3A patent/CN103795754B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040133591A1 (en) * | 2001-03-16 | 2004-07-08 | Iti, Inc. | Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates only |
WO2006076530A2 (en) * | 2005-01-12 | 2006-07-20 | Wandisco, Inc. | Distributed computing systems and system components thereof |
CN101242302A (zh) * | 2008-03-12 | 2008-08-13 | 华为技术有限公司 | 一种数据同步的方法、设备及*** |
CN101826073A (zh) * | 2009-03-06 | 2010-09-08 | 华为技术有限公司 | 分布式数据库同步方法、设备及*** |
CN102025756A (zh) * | 2009-09-09 | 2011-04-20 | 中兴通讯股份有限公司 | 分布式***及其数据同步方法 |
CN102088489A (zh) * | 2010-12-31 | 2011-06-08 | 北京理工大学 | 一种分布式数据同步***及方法 |
Non-Patent Citations (1)
Title |
---|
罗斌: "多数据库***中数据一致性维护技术的研究与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
Cited By (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105335443A (zh) * | 2014-08-13 | 2016-02-17 | 阿里巴巴集团控股有限公司 | 一种用于数据同步中的异常检测的方法与设备 |
CN105592118B (zh) * | 2014-10-23 | 2018-11-13 | 阿里巴巴集团控股有限公司 | 同步用户应用数据的方法、***及服务端 |
CN105592118A (zh) * | 2014-10-23 | 2016-05-18 | 阿里巴巴集团控股有限公司 | 同步用户应用数据的方法、***及服务端 |
CN104346479A (zh) * | 2014-11-26 | 2015-02-11 | 北京奇虎科技有限公司 | 一种数据库同步方法及装置 |
CN107409369A (zh) * | 2015-03-26 | 2017-11-28 | 华为技术有限公司 | 移动核心数据服务的***和方法 |
CN107409369B (zh) * | 2015-03-26 | 2020-02-14 | 华为技术有限公司 | 移动核心数据服务的***和方法 |
CN106302559A (zh) * | 2015-05-11 | 2017-01-04 | 阿里巴巴集团控股有限公司 | 一种数据复制方法和设备 |
US11263231B2 (en) | 2015-05-11 | 2022-03-01 | Alibaba Group Holding Limited | Data copy method and device |
WO2016180168A1 (zh) * | 2015-05-11 | 2016-11-17 | 阿里巴巴集团控股有限公司 | 一种数据复制方法和设备 |
WO2018006624A1 (zh) * | 2016-07-08 | 2018-01-11 | 苏州超块链信息科技有限公司 | 一种数据一致性并行维护方法 |
CN106202387A (zh) * | 2016-07-08 | 2016-12-07 | 陈光宇 | 一种数据一致性并行维护方法 |
CN106202387B (zh) * | 2016-07-08 | 2019-05-21 | 苏州超块链信息科技有限公司 | 一种数据一致性并行维护方法 |
CN106775837A (zh) * | 2016-11-29 | 2017-05-31 | 北京元心科技有限公司 | 多***的全局配置同步方法及装置 |
CN106599195A (zh) * | 2016-12-14 | 2017-04-26 | 北京邮电大学 | 一种海量网络数据环境下的元数据同步方法及*** |
CN106599195B (zh) * | 2016-12-14 | 2020-07-31 | 北京邮电大学 | 一种海量网络数据环境下的元数据同步方法及*** |
US11132265B2 (en) | 2016-12-22 | 2021-09-28 | Huawei Technologies Co., Ltd. | Multi-replica data restoration method and apparatus |
CN109213769A (zh) * | 2017-06-30 | 2019-01-15 | 华为技术有限公司 | 一种数据对象的数据冲突识别方法 |
CN108259562B (zh) * | 2017-12-11 | 2022-02-25 | 杭州品茗安控信息技术股份有限公司 | 一种基于多端点的数据同步方法及装置 |
CN108259562A (zh) * | 2017-12-11 | 2018-07-06 | 杭州品茗安控信息技术股份有限公司 | 一种基于多端点的数据同步方法及装置 |
CN111845630A (zh) * | 2020-06-08 | 2020-10-30 | 北京百度网讯科技有限公司 | 车辆个性化控制方法、装置、***、电子设备及存储介质 |
CN111845630B (zh) * | 2020-06-08 | 2022-07-22 | 阿波罗智联(北京)科技有限公司 | 车辆个性化控制方法、装置、***、电子设备及存储介质 |
CN115037752A (zh) * | 2022-04-22 | 2022-09-09 | 网易(杭州)网络有限公司 | 资源再分配方法、装置及电子设备 |
CN115037752B (zh) * | 2022-04-22 | 2024-03-22 | 网易(杭州)网络有限公司 | 资源再分配方法、装置及电子设备 |
CN115086065A (zh) * | 2022-07-12 | 2022-09-20 | 北斗星通智联科技有限责任公司 | 一种基于区块链的数据同步方法、装置、电子设备及介质 |
CN115086065B (zh) * | 2022-07-12 | 2024-01-19 | 北斗星通智联科技有限责任公司 | 一种基于区块链的数据同步方法、装置、电子设备及介质 |
Also Published As
Publication number | Publication date |
---|---|
CN103795754B (zh) | 2017-08-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103795754A (zh) | 多***间的数据同步方法和*** | |
US9143560B2 (en) | Methods and apparatus for dataset synchronization in a wireless environment | |
US20180365264A1 (en) | Telemetry system for a cloud synchronization system | |
CN103699599B (zh) | 一种基于Storm实时流计算框架的消息可靠处理保障方法 | |
CN107729366A (zh) | 一种普适多源异构大规模数据同步*** | |
CN107209704A (zh) | 检测丢失的写入 | |
CN104335159A (zh) | 间隔控制复制 | |
CN111314125A (zh) | 用于容错通信的***和方法 | |
WO2012045245A1 (zh) | 一种保持数据一致性的方法及*** | |
CN105786642B (zh) | 生产站点、灾备站点及基于快照的远程容灾方法 | |
US9348841B2 (en) | Transaction processing method and system | |
CN114092252B (zh) | 一种区块链交易执行方法、装置、设备及可读存储介质 | |
US20200104404A1 (en) | Seamless migration of distributed systems | |
US20120278429A1 (en) | Cluster system, synchronization controlling method, server, and synchronization controlling program | |
US11086902B2 (en) | Method and system for implementing a redo repeater | |
WO2012171349A1 (zh) | 一种分布式自增计数的实现方法、装置及*** | |
WO2021052237A1 (zh) | 事务处理方法、装置、设备、存储介质、数据库 | |
KR101605455B1 (ko) | 데이터 손실 없는 데이터베이스 리두 로그 이중화 방법 및 그를 위한 시스템 | |
CN104090948A (zh) | 核电站海量数据处理方法、装置及*** | |
CN106682141B (zh) | 一种基于业务操作日志的数据同步方法 | |
JP2015064636A (ja) | 情報処理システム、分散処理方法、及び、プログラム | |
CN104483828A (zh) | 一种分布式容错计算机成员一致性保证方法 | |
US20120191645A1 (en) | Information processing apparatus and database system | |
CN110928532B (zh) | 一种高一致性微服务架构及其数据更新方法 | |
CN113919821A (zh) | 业务的流转方法、装置、计算机设备和存储介质 |
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 |