数据的同步方法和装置与流程

本发明涉及互联网领域，具体而言，涉及一种数据的同步方法和装置。

背景技术：

数据备份是容灾和数据分析的基础，其主要是为防止系统出现操作失误或系统故障导致数据丢失，而将全部或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。传统的数据备份主要是采用内置或外置的磁带机进行冷备份。但是这种方式只能防止操作失误等人为故障，而且其恢复时间也很长。随着技术的不断发展，数据的海量增加，不少的企业开始采用网络备份。网络备份一般通过专业的数据存储管理软件结合相应的硬件和存储设备来实现。

Mysql提供了一种多主一从的网络备份架构，实现数据的多源同步。系统中存在多个Master节点(即主节点或源节点)和一个Slave节点(即从节点)。多个主节点的数据通过二进制日志文件同步到从节点上，达到数据同步的效果。当一个Master节点挂掉时，可以通过从节点上的数据恢复主节点的数据。

使用上述的Mysql官方提供的多主一从的架构设计，存在如下三方面缺点：(1)在其中一个主节点挂掉，利用从节点恢复主节点的数据的过程中，由于主节点的数据未完全恢复，故无法为用户提高有效服务，从而影响数据服务的可用性；(2)利用这种方案设计，需要数据同步的对象(如数据库、数据表等)是固定的，只允许主节点和目标机器(即从节点)的固定表进行同步，灵活性较差；(3)多主一从的架构设计使得从节点存在单点故障风险，在从节点故障时需要手工恢复从节点的数据，由于数据同步时只允许固定表之间的同步，在用户有新的同步需求时，需要手动修改底层的配置文件等信息，从而使得进行数据同步处理时效率较低。

针对上述相关技术中进行数据同步处理时效率较低的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种数据的同步方法和装置，以至少解决相关技术中进行数据同步处理时效率较低的技术问题。

根据本发明实施例的一个方面，提供了一种数据的同步方法，该方法包括：检测到同步操作，其中，同步操作用于请求将第一节点的目标类型的数据同步至第二节点；获取由同步操作触发的同步任务，其中，同步任务用于将保存在第一节点的从设备上的目标类型的数据同步至第二节点，第一节点包括一个主设备和备份有主设备上数据的多个从设备；执行同步任务，从消息队列中读取包括目标类型的数据的目标消息，其中，消息队列中缓存的消息携带有从第一节点的从设备获取的各个类型的数据；将目标消息中的目标类型的数据保存至第二节点。

根据本发明实施例的另一方面，还提供了一种数据的同步装置，该装置包括：检测单元，用于检测到同步操作，其中，同步操作用于请求将第一节点的目标类型的数据同步至第二节点；第一获取单元，用于获取由同步操作触发的同步任务，其中，同步任务用于将保存在第一节点的从设备上的目标类型的数据同步至第二节点，第一节点包括一个主设备和备份有主设备上数据的多个从设备；执行单元，用于执行同步任务，从消息队列中读取包括目标类型的数据的目标消息，其中，消息队列中缓存的消息携带有从第一节点的从设备获取的各个类型的数据；保存单元，用于将目标消息中的目标类型的数据保存至第二节点。

在本发明实施例中，通过检测同步操作，在检测到同步操作时执行同步任务，将目标类型的数据从第一节点备份至第二节点，实现了对一类或者多类数据的自动备份，可以解决了相关技术中进行数据同步处理时效率较低的技术问题，进而达到提高数据同步时的处理效率的技术效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的数据的同步方法的硬件环境的示意图；

图2是根据本发明实施例的一种可选的数据的同步方法的流程图；

图3是根据本发明实施例的一种可选的多主一从架构的示意图；

图4是根据本发明实施例的一种可选的数据的备份系统的示意图；

图5是根据本发明实施例的一种可选的一主多从架构的示意图；

图6是根据本发明实施例的一种可选的数据的同步装置的示意图；

图7是根据本发明实施例的一种可选的数据的同步装置的示意图；

图8是根据本发明实施例的一种可选的数据的同步装置的示意图；以及

图9是根据本发明实施例的一种终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本发明实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

ZooKeeper：是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby的一个开源的实现方式，是Hadoop和Hbase的重要组件，它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

KAFKA：开源消息队列，用于存储二进制解析数据。在多源同步系统中起到了数据缓冲存储作用，保证数据大量生成时可以快速缓冲到消息队列中，减少消息的挤压。

实施例1

根据本发明实施例，提供了一种数据的同步方法的方法实施例。

可选地，在本实施例中，上述方法可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。如图1所示，服务器102通过网络与终端104进行连接，上述网络包括但不限于：广域网、城域网或局域网，终端104并不限定于PC、手机、平板电脑等。本发明实施例的数据的同步方法可以由服务器102来执行，也可以由终端104来执行，还可以是由服务器102和终端104共同执行。其中，终端104执行本发明实施例的数据的同步方法也可以是由安装在其上的客户端来执行。

图2是根据本发明实施例的一种可选的数据的同步方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤S202，检测到同步操作，同步操作用于请求将第一节点的目标类型的数据同步至第二节点；

步骤S204，获取由同步操作触发的同步任务，同步任务用于将保存在第一节点的从设备上的目标类型的数据同步至第二节点，第一节点包括一个主设备和备份有主设备上数据的多个从设备；

步骤S206，执行同步任务，从消息队列中读取包括目标类型的数据的目标消息，消息队列中缓存的消息携带有从第一节点的从设备获取的各个类型的数据；

步骤S208，将目标消息中的目标类型的数据保存至第二节点。

通过上述步骤S202至步骤S208，通过检测同步操作，在检测到同步操作时执行同步任务，将目标类型的数据从第一节点备份至第二节点，实现了对一类或者多类数据的自动备份，可以解决了相关技术中进行数据同步处理时效率较低的技术问题，进而达到提高数据同步时的处理效率的技术效果。

上述的同步操作可以是在客户端上检测到的操作，该客户端用于数据备份的设置，该客户端可以安装在任意的计算机设备上，也可以在多个不同的计算机设备上分别安装，以便于检测不同用户的同步操作。另外，上述的同步操作也可以是计算机设备自动生成的操作，例如，按照用户预先的设置生成同步操作，或者按照脚本程序生成同步操作等。

该客户端也可称为MC组件，其相当于一个前台web界面，供用户自助对同步任务进行配置和操作，同时具备任务下达功能，将用户在前台的任务配置文件下发到zookeeper集群，等待后台侧进行任务解析消费。

上述的节点(包括第一节点和第二节点)为一个服务器集合(可称为一个set)，该set包括一个主服务器Master和多个从服务器Slave(也即一主多从的架构)，主服务器和多个从服务器可以采用分布式部署。

在图3示出的实施例中，Mysql提供了一种多主一从的架构设计，可实现多源同步，系统中存在多个Master和一个Slave，多个Master的数据通过二进制日志文件同步到Slave上，然后在Slave上将这些数据重新同步到其他节点以达到数据同步的效果，当一个Master挂掉时，可以通过Slave上的数据恢复Master。

而采用一主多从的架构，可以克服上述多主一从(多个主服务器和一个从服务器)的如下缺陷：(1)在其中一个Master挂掉，Slave重做Master时，此时Master数据影响服务可用性，而采用多从一主架构，可以将其中一个Slave切换为Master以继续提供服务，此时会更新主从关系，这个时候的同步任务会重新选取新的Slave节点，利用新的Slave节点进行数据同步；多主一从的架构设计中，Slave具有单点故障风险，在Slave故障时需要手工重做Slave，而采用本申请的一主多从的架构，则可以避免单点故障风险。

上述的同步任务可以为同步操作在zookeeper组件中触发的任务，zookeeper组件是一种分布式的任务管理组件，可以安装在不同的计算机设备上(可称为zookeeper集群)。

上述的目标类型的数据可以为一个或者多个类型的数据，具体可以根据用户的同步操作确定，在客户端(也即MC组件)下发任务给zookeeper集群时，可在zookeeper组件的指定目录中发现更新的上述同步任务，从而可以根据该任务确定用户指定的需要备份的一个或多个类型的数据。

可选地，每一种类型的数据可以单独保存在一个数据表中。这样既可从指定的数据表中读取该类型的数据。

上述的消息队列可为分布式消息队列kafka，在执行同步任务时，相当于生成一个对应于该任务的进程，通过执行该进程，可自动从kafka消息队列中读取该类型的数据，并将读取的数据存储至第二节点的主服务器中，与此同时，第二节点的从服务器也会实时备份主服务器中的数据。

本申请的上述方法可以应用于银行、保险、集团企业等具有总公司、分公司的两级或两级以上架构的组织，以解决总公司和分公司的业务数据库需要实时分发、汇总的需求。使用本申请的技术方案，具有如下优势：(1)提供分布式部署方案，可跨机房部署，保障在单一机房故障后数据不丢；(2)针对用户业务数据库设计的复杂性，本方案通过提供灵活的配置方案来满足复杂的业务需求；(3)针对源表和目的表结构信息变更以及历史数据等情况，本方案提供自动同步历史数据以及变更表结构功能，以保证源表和目的表结构的完全一致。本申请通过消息队列，利用经典的生产者消费者模型，可实现高可用、数据高可靠性、配置高度灵活的多源同步。

需要说明的是，在第一节点的主设备发生故障时，由第一节点的多个从设备中数据备份的延迟最小的从设备替代主设备提供数据服务。在图4示出的实施例中，第一节点即源set，第二节点即目标set，数据源和备份侧都是以一个set为一个单元，set采用一主多从的设计方式，在用户主机发生故障时会自动切换主服务器，具体如图5所示，在完成切换后，binlogproducter生产者(也即监控模块)会自主根据故障情况进行选择，确认每个Slave的延迟大小，通过对比两个Slave的延迟确定延迟较小的Slave，解析延迟较小的Slave节点的二进制文件并存入kafka消息队列，以便于用户通过Web界面配置满足生产的任务规则。

上述的binlogproducter组件主要有以下特点：

(1)生产者由一主两备组成，binlogproducter组件会自主的选择多个Slave中延迟比较小的那台Slave上面的二进制日志文件binlog进行提取，当主备切换时会重新选择新的延迟较小的Slave，Master和另外的Slave虽然也有进程在跑，但是不会去分析binlog，可减少资源的浪费。

(2)binlogproducter组件负责二进制文件binlog的解析和提取，将提取的结果转化成json格式的消息存储到kafka消息队列当中，以等待消费者进行消息消费。

(3)在将目标消息中的目标类型的数据保存至第二节点之后，可在接收到第二节点保存目标类型的数据成功的反馈信息之后，通过binlogproducter组件获取用于标识已保存的目标类型的数据的全局标识gtid，并将该全局标识通知给预设服务，即zookeeper组件。上述的全局标识可以是通过解析二进制日志文件binlog获取的。

binlogproducter组件可定期(如3秒、5秒等)保存同步的gtid到zookeeper组件，当发生灾难重启的时候能够继续在上一个gtid位置开始执行，保证数据的一致性和高可用性。

在步骤S202提供的技术方案中，在检测同步操作时，具体是指通过提供的可自助配置的可视化界面(即MC组件)检测到用户执行的同步操作，该同步操作用于配置源set的源数据表至目标set的目的表之间的数据备份，可支持单张源表向多张目的表、多张源表向单张目的表、多张源表向多张目的表的数据同步。

需要说明的是，用户配置表间的同步时，可通过正则表达式的方式实现，这样就可以将具体的数据同步工作交给后台处理，在后台做到自动匹配、自动检测、自动运行同步数据，以提高用户的便捷性，降低学习成本。

在步骤S204提供的技术方案中，获取由同步操作触发的同步任务包括：在监控到预设服务的预设路径保存有用于配置同步任务的配置文件时，从预设服务的预设路径获取配置文件，其中，预设服务为提供分布式任务管理的服务。

上述的预设服务器即zookeeper组件提供的任务管理服务。

在用户在MAC组件上完成同步操作之后，前台MC组件将任务下发到任务中心的zookeeper组件，消费者管理模块会动态实时监控zookeeper组件，如监控zookeeper组件的用于保存被下达的任务的目录，从而可以在新任务被下达时抢占新任务并解析任务规则。

在步骤S206提供的技术方案中，在执行同步任务之前，可通过从配置文件中获取的配置信息，确定待同步的至少一个第一节点的用于存储目标类型的数据的第一数据表；在执行同步任务时，从消息队列中读取包括目标类型的数据的目标消息包括：执行按照配置文件配置的同步任务，从消息队列中读取包括第一数据表中数据的目标消息。

上述的配置文件中还记载有同步任务的任务类型，其中，任务类型包括数据全量同步和数据增量同步。

需要说明的是，确定待同步的至少一个第一节点的用于存储目标类型的数据的第一数据表时，每一类数据对应于一个数据表，配置信息中可以具体记载数据表间的如下几种方式的数据同步：源set上一个数据表与目标set上一个数据表之间的同步；源set上多个数据表与目标set上一个数据表之间的同步；一个源set上的数据表与一个目标set上的数据表之间的同步；多个源set上的数据表与一个目标set上的数据表之间的同步；多个源set上的数据表与多个目标set上的数据表之间的同步。

通过上述实施例，可克服现有技术中只允许源机器和目标机器固定数据库和表进行同步的缺陷，用户可在MC组件上进行简单的操作，即可对需要同步的表进行灵活的配置。

上述的消费者管理模块属于任务管理和执行组件，消费者管理模块的任务是实时监控zookeeper组件，当有新的任务下达时抢占任务，产生对应的消费者进程进行消息消费，对消息进行解析并按照配置文件中的用户规则进行数据同步操作，其具备以下特点：支持标准正则表达式，支持可以自定义源和目的的多样化任务；支持数据全量和增量同步；支持目的表的DDL操作；消费者支持任意部署和扩展。

在将目标消息中的目标类型的数据保存至第二节点之前，消费者管理模块会自动检测目的端和源端的数据差异情况和表结构信息，对于源端历史数据会先进行增量数据同步操作，对于源表和目的表结构不一致情况会自动同步DDL操作，具体可以判断第二节点上是否存在与目标类型的数据的数据类型匹配的第二数据表；在判断出第二节点上不存在第二数据表的情况下，通过执行数据定义语言DDL操作创建第二数据表，以保证任务正常运行和数据的一致性。

在步骤S208提供的技术方案中，将目标消息中的目标类型的数据保存至第二节点包括：将目标类型的数据保存至第二节点中与目标类型的数据的数据类型匹配的第二数据表。

在第二节点上存在上述的第二数据表的情况下，可直接将读取的数据存入第二数据表；在第二节点上不存在上述的第二数据表的情况下，就需要进行上述的DDL操作，再将数据保存至新创建的第二数据表中。

利用本申请提供的技术方案，可解决传统mysql数据库中主从同步的限制，实现了多对一，一对多的表级数据同步，而且支持多级同步。该方案弥补了当前开源数据库的同步方案的不足，解决了企业信息系统中的“信息孤岛”问题，该方案可应用于多种数据同步场景：(1)总公司、分公司、分支等多级业务系统架构的数据同步场景；(2)本地数据中心与灾备数据中心的数据同步场景；(3)业务系统与数据仓库之间数据同步的场景；(4)冷热分离时，热数据库向冷数据库同步数据的场景。下面以上述的第一类场景为例详述本申请的实施方式。

场景介绍：

A公司为全国连锁的销售公司，其在各地均有实体店，用户可以使用A公司发售的消费卡在各个实体店中进行消费，这样，为了便于统一管理，就需要将用户数据、用户的消费数据等进行上传，A公司在不同区域分别布置了多个用于收集数据的源SET，为了防止数据丢失，需要将数据备份至目标SET。

在数据同步时，用户可利用本申请提供的客户端进行同步操作，如选择需要同步的数据类型，如选择用户的消费类型信息、消费时间、消费金额、用户信息，在选择这些信息时，可以用相应的正则表达式来表示。

在客户端上接收到上述的同步操作后，包含上述的被选中的信息的配置文件就会被下发至zookeeper组件，而由于消费者管理模块会实时监控zookeeper组件，当有新的任务下达时抢占任务，产生对应的消费者进程进行消息消费，具体是从不同区域的源SET中读取包括上述数据类型的数据，并将每一类数据汇总至目标SET中的一个数据表中，例如，将所有源SET中的消费金额信息汇总至目标SET的一张数据表中，将所有源SET的用户信息汇总至目标SET的另一张数据表中。

在将源SET的数据同步至目标SET的过程中，可以根据待同步数据进行DDL操作，例如，需要将消费金额信息和消费时间同时保存至目标SET，而目标SET中仅有用于保存消费金额信息的数据表，这个时候就可以通过DDL操作对该数据表进行扩充，进而使其可以同时存储消费时间和消费金额信息。

在本申请的实施例中，提供了一种基于触发器方式获取增量变更的同步方案，可根据用户需求进行数据同步，且可以实现秒级实时同步；该方案基于中间件伪装技术，即伪装自己为mysql Slave，向mysql Master发送dump协议的方式进行同步。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述数据的同步方法的数据的同步装置。图6是根据本发明实施例的一种可选的数据的同步装置的示意图，如图6所示，该装置可以包括：检测单元62、第一获取单元64、执行单元66以及保存单元68。

检测单元62，用于检测到同步操作，其中，同步操作用于请求将第一节点的目标类型的数据同步至第二节点；

第一获取单元64，用于获取由同步操作触发的同步任务，其中，同步任务用于将保存在第一节点的从设备上的目标类型的数据同步至第二节点，第一节点包括一个主设备和备份有主设备上数据的多个从设备；

执行单元66，用于执行同步任务，从消息队列中读取包括目标类型的数据的目标消息，其中，消息队列中缓存的消息携带有从第一节点的从设备获取的各个类型的数据；

保存单元68，用于将目标消息中的目标类型的数据保存至第二节点。

需要说明的是，该实施例中的检测单元62可以用于执行本申请实施例1中的步骤S202，该实施例中的第一获取单元64可以用于执行本申请实施例1中的步骤S204，该实施例中的执行单元66可以用于执行本申请实施例1中的步骤S206，该实施例中的保存单元68可以用于执行本申请实施例1中的步骤S208。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

通过上述模块，通过检测同步操作，在检测到同步操作时执行同步任务，将目标类型的数据从第一节点备份至第二节点，实现了对一类或者多类数据的自动备份，可以解决了相关技术中进行数据同步处理时效率较低的技术问题，进而达到提高数据同步时的处理效率的技术效果。

上述的同步操作可以是在客户端上检测到的操作，该客户端用于数据备份的设置，该客户端可以安装在任意的计算机设备上，也可以在多个不同的计算机设备上分别安装，以便于检测不同用户的同步操作。另外，上述的同步操作也可以是计算机设备自动生成的操作，例如，按照用户预先的设置生成同步操作，或者按照脚本程序生成同步操作等。

该客户端也可称为MC组件，其相当于一个前台web界面，供用户自助对同步任务进行配置和操作，同时具备任务下达功能，将用户在前台的任务配置文件下发到zookeeper集群，等待后台侧进行任务解析消费。

上述的节点(包括第一节点和第二节点)为一个服务器集合(可称为一个set)，该set包括一个主服务器Master和多个从服务器Slave(也即一主多从的架构)，主服务器和多个从服务器可以采用分布式部署。

在图3示出的实施例中，Mysql提供了一种多主一从的架构设计，可实现多源同步，系统中存在多个Master和一个Slave，多个Master的数据通过二进制日志文件同步到Slave上，然后在Slave上将这些数据重新同步到其他节点以达到数据同步的效果，当一个Master挂掉时，可以通过Slave上的数据恢复Master。

而采用一主多从的架构，可以克服上述多主一从(多个主服务器和一个从服务器)的如下缺陷：(1)在其中一个Master挂掉，Slave重做Master时，此时Master数据影响服务可用性，而采用多从一主架构，可以将其中一个Slave切换为Master以继续提供服务，此时会更新主从关系，这个时候的同步任务会重新选取新的Slave节点，利用新的Slave节点进行数据同步；多主一从的架构设计中，Slave具有单点故障风险，在Slave故障时需要手工重做Slave，而采用本申请的一主多从的架构，则可以避免单点故障风险。

上述的同步任务可以为同步操作在zookeeper组件中触发的任务，zookeeper组件是一种分布式的任务管理组件，可以安装在不同的计算机设备上(可称为zookeeper集群)。

上述的目标类型的数据可以为一个或者多个类型的数据，具体可以根据用户的同步操作确定，在客户端(也即MC组件)下发任务给zookeeper集群时，可在zookeeper组件的指定目录中发现更新的上述同步任务，从而可以根据该任务确定用户指定的需要备份的一个或多个类型的数据。

可选地，每一种类型的数据可以单独保存在一个数据表中。这样既可从指定的数据表中读取该类型的数据。

上述的消息队列可为分布式消息队列kafka，在执行同步任务时，相当于生成一个对应于该任务的进程，通过执行该进程，可自动从kafka消息队列中读取该类型的数据，并将读取的数据存储至第二节点的主服务器中，与此同时，第二节点的从服务器也会实时备份主服务器中的数据。

本申请的上述方法可以应用于银行、保险、集团企业等具有总公司、分公司的两级或两级以上架构的组织，以解决总公司和分公司的业务数据库需要实时分发、汇总的需求。使用本申请的技术方案，具有如下优势：(1)提供分布式部署方案，可跨机房部署，保障在单一机房故障后数据不丢；(2)针对用户业务数据库设计的复杂性，本方案通过提供灵活的配置方案来满足复杂的业务需求；(3)针对源表和目的表结构信息变更以及历史数据等情况，本方案提供自动同步历史数据以及变更表结构功能，以保证源表和目的表结构的完全一致。本申请通过消息队列，利用经典的生产者消费者模型，可实现高可用、数据高可靠性、配置高度灵活的多源同步。

需要说明的是，在第一节点的主设备发生故障时，由第一节点的多个从设备中数据备份的延迟最小的从设备替代主设备提供数据服务。在图4示出的实施例中，第一节点即源set，第二节点即目标set，数据源和备份侧都是以一个set为一个单元，set采用一主多从的设计方式，在用户主机发生故障时会自动切换主服务器，具体如图5所示，在完成切换后，binlogproducter生产者(也即监控模块)会自主根据故障情况进行选择，确认每个Slave的延迟大小，通过对比两个Slave的延迟确定延迟较小的Slave，解析延迟较小的Slave节点的二进制文件并存入kafka消息队列，以便于用户通过Web界面配置满足生产的任务规则。

上述的binlogproducter组件主要有以下特点：

(1)生产者由一主两备组成，binlogproducter组件会自主的选择多个Slave中延迟比较小的那台Slave上面的二进制日志文件binlog进行提取，当主备切换时会重新选择新的延迟较小的Slave，Master和另外的Slave虽然也有进程在跑，但是不会去分析binlog，可减少资源的浪费。

(2)binlogproducter组件负责二进制文件binlog的解析和提取，将提取的结果转化成json格式的消息存储到kafka消息队列当中，以等待消费者进行消息消费。

(3)在将目标消息中的目标类型的数据保存至第二节点之后，可在接收到第二节点保存目标类型的数据成功的反馈信息之后，通过binlogproducter组件获取用于标识已保存的目标类型的数据的全局标识gtid，并将该全局标识通知给预设服务，即zookeeper组件。

binlogproducter组件可定期(如3秒、5秒等)保存同步的gtid到zookeeper组件，当发生灾难重启的时候能够继续在上一个gtid位置开始执行，保证数据的一致性和高可用性。

可选地，第一获取单元包括：第一获取模块，用于在监控到预设服务的预设路径保存有用于配置同步任务的配置文件时，从预设服务的预设路径获取配置文件，其中，预设服务为提供分布式任务管理的服务。

可选地，如图7所示，该装置还可以包括：第二获取单元72，分别于第一获取单元64和执行单元66连接，用于在执行同步任务之前，通过从配置文件中获取的配置信息，确定待同步的至少一个第一节点的用于存储目标类型的数据的第一数据表；执行单元还用于执行按照配置文件配置的同步任务，从消息队列中读取包括第一数据表中数据的目标消息。

可选地，上述的配置文件中还记载有同步任务的任务类型，其中，任务类型包括数据全量同步和数据增量同步。

可选地，在将目标消息中的目标类型的数据保存至第二节点之前，消费者管理模块会自动检测目的端和源端的数据差异情况和表结构信息，对于源端历史数据会先进行增量数据同步操作，对于源表和目的表结构不一致情况会自动同步DDL操作，具体如图8所示，保存单元68包括：判断模块682，用于在将目标消息中的目标类型的数据保存至第二节点之前，判断第二节点上是否存在与目标类型的数据的数据类型匹配的第二数据表；创建模块684，用于在判断出第二节点上不存在第二数据表的情况下，通过执行数据定义语言DDL操作创建第二数据表。

可选地，本申请的保存单元还用于将目标类型的数据保存至第二节点中与目标类型的数据的数据类型匹配的第二数据表。

可选地，本申请的装置还可以包括：标识处理单元，用于在将目标消息中的目标类型的数据保存至第二节点之后，在接收到第二节点保存目标类型的数据成功的反馈信息之后，获取用于标识已保存的目标类型的数据的全局标识，并将全局标识通知给预设服务。

可选地，本申请的装置还可以包括：任务处理单元，用于在将目标消息中的目标类型的数据保存至第二节点之后，在同步任务重新启动时，从预设服务获取全局标识，并基于全局标识从消息队列中读取消息。

可选地，本申请的装置还可以包括：切换单元，用于在第一节点的主设备发生故障时，由第一节点的多个从设备中数据备份的延迟最小的从设备替代主设备提供数据服务。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

实施例3

根据本发明实施例，还提供了一种用于实施上述数据的同步方法的服务器或终端。

图9是根据本发明实施例的一种终端的结构框图，如图9所示，该终端可以包括：一个或多个(图中仅示出一个)处理器901、存储器903、以及传输装置905(如上述实施例中的发送装置)，如图9所示，该终端还可以包括输入输出设备907。

其中，存储器903可用于存储软件程序以及模块，如本发明实施例中的数据的同步方法和装置对应的程序指令/模块，处理器901通过运行存储在存储器903内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的数据的同步方法。存储器903可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器903可进一步包括相对于处理器901远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置905用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置905包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置905为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器903用于存储应用程序。

处理器901可以通过传输装置905调用存储器903存储的应用程序，以执行下述步骤：检测到同步操作，其中，同步操作用于请求将第一节点的目标类型的数据同步至第二节点；获取由同步操作触发的同步任务，其中，同步任务用于将保存在第一节点的从设备上的目标类型的数据同步至第二节点，第一节点包括一个主设备和备份有主设备上数据的多个从设备；执行同步任务，从消息队列中读取包括目标类型的数据的目标消息，其中，消息队列中缓存的消息携带有从第一节点的从设备获取的各个类型的数据；将目标消息中的目标类型的数据保存至第二节点。

处理器901还用于执行下述步骤：判断第二节点上是否存在与目标类型的数据的数据类型匹配的第二数据表；在判断出第二节点上不存在第二数据表的情况下，通过执行数据定义语言DDL操作创建第二数据表。

采用本发明实施例，通过检测同步操作，在检测到同步操作时执行同步任务，将目标类型的数据从第一节点备份至第二节点，实现了对一类或者多类数据的自动备份，可以解决了相关技术中进行数据同步处理时效率较低的技术问题，进而达到提高数据同步时的处理效率的技术效果。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图9所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices，MID)、PAD等终端设备。图9其并不对上述电子装置的结构造成限定。例如，终端还可包括比图9中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图9所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。

实施例4

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行数据的同步方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

S11，检测到同步操作，同步操作用于请求将第一节点的目标类型的数据同步至第二节点；

S12，获取由同步操作触发的同步任务，同步任务用于将保存在第一节点的从设备上的目标类型的数据同步至第二节点，第一节点包括一个主设备和备份有主设备上数据的多个从设备；

S13，执行同步任务，从消息队列中读取包括目标类型的数据的目标消息，消息队列中缓存的消息携带有从第一节点的从设备获取的各个类型的数据；

S14，将目标消息中的目标类型的数据保存至第二节点。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S21，判断第二节点上是否存在与目标类型的数据的数据类型匹配的第二数据表；

S22，在判断出第二节点上不存在第二数据表的情况下，通过执行数据定义语言DDL操作创建第二数据表。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。