CN110232097A - 一种数据同步方法及装置 - Google Patents

Abstract

本申请公开了一种数据同步方法及装置，该方法包括：消息中间件首先获取第一数据库中待同步的目标实体的增量数据，然后，将获取到的第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。可见，相比于将增量数据同时写入第一数据库和第二数据库的分布式数据写入方法，本申请是在将目标实体的增量数据写入第一数据库后，再通过消息中间件获取到第一数据库中待同步的目标实体的增量数据，并将该增量数据顺次同步到第二数据库，这样的先后操作顺序能够有效保证第一数据库和第二数据库中目标实体的数据的一致性，并且通过采用消息中间件将增量数据顺次同步到第二数据库的方式，能够避免增量数据的丢失，有效解决了现有的技术问题。

Description

一种数据同步方法及装置

技术领域

本申请涉及数据处理技术领域，具体涉及一种数据同步方法及装置。

背景技术

随着互联网技术的日益发展，接入互联网的用户不断增多，网络数据量不断增加，数据库的访问量也不断增大，由此，为了减轻对远程资源服务器的访问压力以及缓解网络拥塞状况，对于一些公共使用的不敏感数据，可以将其同步到第三方存储空间中，用以提供该部分数据的访问服务。

传统的数据写入方式是将数据进行分布式写入，即，在将数据写入本地资源服务器的同时，调用第三方存储空间的接口，将数据同样写入第三方存储空间中，但这种分布式写入数据的方式，容易导致本地资源服务器与第三方存储空间中数据不一致的问题，例如，当调用第三方存储空间的接口超时，导致调用接口失败时，将无法正常向第三方存储空间写入数据，此时，极易导致数据的丢失。

因此，如何升级数据的同步方式，确保本地资源服务器和第三方存储空间中的数据保持一致，避免数据丢失，已成为亟待解决的问题。

发明内容

有鉴于此，本申请实施例提供一种数据同步方法及装置，以解决现有技术中通过分布式写入数据导致的本地资源服务器与第三方存储空间中数据不一致的技术问题。

为解决上述问题，本申请实施例提供的技术方案如下：

第一方面，本申请提供了一种数据同步方法，所述方法包括：

获取第一数据库中待同步的目标实体的增量数据；

将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。

在一种可选的实现方式中，所述获取第一数据库中待同步的目标实体的增量数据，包括：

获取包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件；

根据所述包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件，获取所述第一数据库中所述目标实体的日志更新记录。

在一种可选的实现方式中，所述获取第一数据库中待同步的目标实体的增量数据，包括：

按照预设时间周期，获取包含所述第一数据库中待同步的目标实体的增量数据的消息协议。

在一种可选的实现方式中，所述将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中之后，还包括：

判断所述第二数据库是否成功接收所述目标实体的增量数据；

若否，则将所述第一数据库中的待同步的目标实体的增量数据存储于消息队列中，并在进行下一时刻的数据同步时，将所述目标实体的增量数据顺次同步到第二数据库中。

在一种可选的实现方式中，将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中之后，还包括：

将所述第二数据库中的目标实体的增量数据同步到第三数据库中；

判断所述第一数据库和第三数据库中的目标实体的数据是否一致；

若否，则根据判断结果，对所述第二数据库和第三数据库中的数据进行修复，以保证所述第一数据库、所述第二数据库以及所述第三数据库中目标实体的数据的一致性。

第二方面，本申请提供了一种数据同步装置，所述装置包括：

获取单元，用于获取第一数据库中待同步的目标实体的增量数据；

第一同步单元，用于将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。

在一种可选的实现方式中，所述获取单元包括：

第一获取子单元，用于获取包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件；

第二获取子单元，用于根据所述包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件，获取所述第一数据库中所述目标实体的日志更新记录。

在一种可选的实现方式中，所述获取单元具体用于：

按照预设时间周期，获取包含所述第一数据库中待同步的目标实体的增量数据的消息协议。

在一种可选的实现方式中，所述同步单元还包括：

判断子单元，用于判断所述第二数据库是否成功接收所述目标实体的增量数据；

存储子单元，用于若判断出所述第二数据库未成功接收所述目标实体的增量数据，则将所述第一数据库中的待同步的目标实体的增量数据存储于消息队列中，并在进行下一时刻的数据同步时，将所述目标实体的增量数据顺次同步到第二数据库中。

在一种可选的实现方式中，所述装置还包括：

第二同步单元，用于将所述第二数据库中的目标实体的增量数据同步到第三数据库中；

判断单元，用于判断所述第一数据库和第三数据库中的目标实体的数据是否一致；

修复单元，用于若判断出所述第一数据库和第三数据库中的目标实体的数据不一致，则根据判断结果，对所述第二数据库和第三数据库中的数据进行修复，以保证所述第一数据库、所述第二数据库以及所述第三数据库中目标实体的数据的一致性。

由此可见，本申请实施例具有如下有益效果：

在本申请提供的数据同步方法中，消息中间件首先获取第一数据库中待同步的目标实体的增量数据，然后，可以将获取到的第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。可见，相比于将增量数据同时写入第一数据库和第二数据库的分布式数据写入方法，本申请实施例是在将目标实体的增量数据写入第一数据库后，再通过消息中间件获取到第一数据库中待同步的目标实体的增量数据，并将该增量数据顺次同步到第二数据库中，这样的先后操作顺序能够有效保证第一数据库和第二数据库中目标实体的数据的一致性，并且通过采用消息中间件将增量数据顺次同步到第二数据库的方式，能够避免增量数据的丢失，有效解决了现有的技术问题。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为现有的分布式写入数据的应用场景示意图；

图2为本申请实施例提供的一种数据同步方法的流程图；

图3为本申请实施例提供一种数据同步方法的结构示意图；

图4为本申请实施例提供的一种数据同步装置的结构示意图。

具体实施方式

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

为了便于理解本申请提供的技术方案，下面先对本申请技术方案的研究背景进行简单说明。

随着大数据时代的到来，网络数据量不断增加，数据库的访问量也不断增大，为了减轻对远程资源服务器的访问压力以及缓解网络拥塞状况，对于一些公共使用的不敏感数据，如用户昵称、视频播放次数等，可以将这些数据同步到第三方存储空间中，比如，同步到远程数据库中进行存储，用以提供这部分公共数据的访问服务。

在现有的数据写入过程中，一般采用的是分布式数据写入方法，参见图1，其示出了现有的分布式写入数据的应用场景示意图，其中，以本地数据库为一种关系数据库管理系统MySQL，第三方存储空间为第三方数据库为例，对于自媒体服务数据、认证后台数据等待同步的公共数据来说，在将其写入本地数据库MySQL的同时，会调用第三方数据库提供的接口，将这些数据同步写入第三方数据库中，通过该数据库来提供这些公共数据的访问服务，以减轻本地数据库MySQL的访问压力。

但是这种分布式数据写入的方式，容易导致本地资源服务器(如图1中的MySQL)与第三方存储空间(如图1中的第三方数据库)中数据不一致的问题，例如，当调用图1中第三方数据库的接口超时，导致接口调用失败时，将无法正常向第三方数据库中写入数据，此时，极易造成数据的丢失，导致MySQL与第三方数据库中存储的数据不一致。

基于此，本申请提出了一种数据同步方法及装置，在将目标实体的增量数据写入第一数据库后，通过消息中间件先获取第一数据库中待同步的目标实体的增量数据，然后，再将获取到的第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中，而不再对数据进行分布式写入，将“同步写入”的方式改成了“异步写入”，从而能够有效避免数据丢失，保证第一数据库和第二数据库中数据的一致性，避免增量数据的丢失。

接下来，本申请实施例将结合附图对该方法进行详细说明。

参见图2，其示出了本申请实施例提供的一种数据同步方法的流程图，如图2所示，该方法包括：

S201：获取第一数据库中待同步的目标实体的增量数据。

在本实施例中，将需要进行同步的字段定义为目标实体，并将目标实体中需要进行同步的新增数据定义为目标实体的增量数据。需要说明的是，目标实体的增量数据指的是公共使用的非敏感数据，比如，用户在网站上的注册昵称、视频播放次数等，而例如用户的身份证号、电话号等敏感数据则不作为待同步的增量数据。

并且，本实施例不限制目标实体的增量数据的来源，比如，这些数据可以来自于自媒体服务(如第三方用户在某网站上发布的音频或视频文件)、认证后台等。消息中间件在获取到待同步的目标实体的增量数据后，将继续执行步骤S202。

其中，消息中间件具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，常用的消息中间件包括Kafka、RocketMQ(简称RMQ)等。

需要说明的是，在后续介绍中，本申请将选取消息中间件RMQ为例进行说明。但实际应用中可以根据实际情况来选择不同的消息中间件，本申请对此不进行限制。

在本申请实施例一些可能的实现方式中，可以预先将第一数据库与消息中间件(如RMQ)建立连接，并将后续步骤S202中介绍的第二数据库也与该消息中间件建立连接.。

其中，消息中间件RMQ指的是一款开源的分布式消息系统，可以基于高可用分布式集群技术，来提供低延时的、高可靠的消息发布与订阅服务，由此，在本实施例中。通过RMQ可以实现数据的可靠传输。

需要说明的是，在本实施例中，可以利用现有或未来出现的数据写入方式，先将目标待同步的目标实体的增量数据写入第一数据库，其中，第一数据库指的是存储所有用户信息以及数据信息的本地数据库，比如，某网站用于存储该网站上所有注册用户信息以及多媒体数据信息的数据库等，可以为MySQL等。

在本申请实施例一些可能的实现方式中，上述步骤S201的实现过程具体包括：

步骤A1：获取包含第一数据库中待同步的目标实体的增量数据更新信息的文件。

在本实现方式中，为了实现对第一数据库中的目标实体的增量数据的同步，消息中间件(如RMQ)首先需要获取到第一数据库中包含这些增量数据更新信息的文件，其中，一种可选的实现方式是，第一数据库可以为一种关系型数据库管理系统MySQL，则可以利用binlog二进制日志作为存储待同步的目标实体的增量数据更新信息的文件。

其中，MySQL主数据库中的binlog二进制日志指的是用于记录该数据库中所有更新了的数据或者已经潜在更新的数据的所有编码语句，这些语句是以“事件”的形式进行保存，用以描述MySQL数据库中数据的更改记录，比如可以用来描述MySQL数据库中目标实体的增量数据的更新记录。

步骤A2：根据包含第一数据库中待同步的目标实体的增量数据更新信息的文件，获取第一数据库中目标实体的日志更新记录。

消息中间件RMQ通过步骤A1获取到包含第一数据库中待同步的目标实体的增量数据更新信息的文件后，进一步可以利用现有或未来出现的数据处理方法，对获取到的文件进行数据处理，以获取到第一数据库中目标实体的增量数据对应的日志更新记录。该日志更新记录表征了已经更新了的部分或全部目标实体的增量数据。

举例说明：以第一数据库为MySQL为例，由于MySQL作为存储系统，所有业务访问数据的操作都会转化为底层数据库系统的IO行为(缓存系统也可以当做是key-value的数据库)，由此，在获取该数据库中目标实体的增量数据对应的日志更新记录的过程中，具体可以基于MySQL的IO机制，对MySQL的主数据库进行监控，即，对MySQL的主数据库中的目标实体的增量数据进行监听，并利用MySQL主数据库中存储待同步的目标实体的增量数据更新信息的文件(比如binlog二进制日志)，获取到MySQL主数据库中目标实体的增量数据对应的日志更新记录。

需要说明的是，本实现方式中的“binlog二进制日志”可以采用任意格式，比如将每一条已修改增量数据的结构化查询语言(Structured Query Language，简称SQL)都记录在binlog中、或不记录SQL语句上下文相关信息，仅保存哪条增量数据记录被修改、或二者结合使用的格式，等等。具体实现方式与现有方式相同，在此不再赘述。

在本申请实施例一些可能的实现方式中，上述步骤S201的实现过程具体用于：

按照预设时间周期，获取包含第一数据库中待同步的目标实体的增量数据的消息协议。

在本实现方式中，为了实现对第一数据库中的目标实体的增量数据的同步，消息中间件RMQ首先可以按照预设的时间周期，比如每隔1小时或2小时，利用现有或未来出现的消息获取方式，定时获取到包含第一数据库中待同步的目标实体的增量数据的消息协议，比如，可以按照预先定义的传输数据协议或数据消息格式，定时获取包含第一数据库中待同步的目标实体的增量数据的消息协议，以便从中获取到第一数据库中待同步的目标实体的增量数据。

S202：将第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。

在本实施例中，消息中间件RMQ通过步骤S201获取到第一数据库中待同步的目标实体的增量数据后，进一步可以将这些增量数据顺次同步到第二数据库中。

其中，第二数据库指的是备份第一数据库中所有已存储的公共数据(即非敏感数据)的第三方数据库，比如，可以是远程数据库或云数据库等。

具体来讲，在获取到第一数据库中待同步的目标实体的增量数据后，可将这些增量数据按照其所属业务类型和所属用户，进行分类，并根据这些增量数据所属类型和/或所属不同用户，将其通过消息队列按顺序依次同步到第二数据库中，从而可以保证第二数据库中存储的目标实体的数据与第一数据库中存储的目标实体的数据是一致的，避免造成增量数据的丢失。

接下来，本申请将通过下述步骤B1-B3对上述步骤S202的具体实现过程进行详细介绍：

步骤B1：将第一数据库中待同步的目标实体的增量数据统一封装成消息体。

在本实现方式中，由于预先将第一数据库和第二数据库与消息中间件(如RMQ)建立了连接，则基于该消息中间件(如RMQ)消息队列的特性，比如，能够保证严格的消息顺序(即数据同步的顺序)、提供丰富的消息拉取模式(即数据获取模式)、实时的消息订阅机制、消息重试且重试次数可配置等，确定数据作为消息传输的格式，以便将第一数据库中待同步的目标实体的增量数据，通过按照统一的消息格式，以及单线程的方式，顺次准确同步到第二数据库中。

具体来讲，首先可以按照基于RMQ特性确定的消息格式，将第一数据库中待同步的目标实体的增量数据统一封装成一个消息体。

需要说明的是，本实施例中的消息体为json格式，举例说明：假设消息体是{"uid":7,"field":"nickname"}，则其中uid表示需要同步的增量数据主体(即7)，也是增量数据的唯一标识；field表示需要同步的字段(即nickname)，即需要同步更新“昵称”这个字段。可以理解的是，定义这种标准的消息格式，主要是为了在同步增量数据的时候，可以统一数据解析方式。

此外，还需要说明的是，增量数据的同步来源，也可以不限于MysqlIO，比如，假设某个字段数据不一致需要修复时，也可以发送一个标准格式的消息进行修复。

步骤B2：通过消息中间件，将增量数据，按照增量数据所属的业务类型和/或增量数据所属的用户进行分类，得到分类结果。

通过步骤B1将第一数据库中待同步的目标实体的增量数据统一封装成消息体后，可以通过消息中间件，将该消息体中的增量数据，按照其所属的业务类型和/或增量数据所属的用户进行分类，得到分类结果，即，将属于同一业务类型的所有相关增量数据划分到一起，和/或，将同一用户的所有相关增量数据划分到一起，用以进行后续步骤B3。

举例说明：在将第一数据库中待同步的目标实体的增量数据统一封装成消息体后，可以按照自媒体表消息队列、运营表消息队列等不同业务类型，通过uid取模的方式，将增量数据按照业务类型进行划分，其中，uid取模方法的实现与现有方式一致，在此不再赘述。

接着，可以再通过uid取模的方式，将所有按照业务类型进行划分的增量数据，按照其所属的用户进行分类，即，将同一个用户的相关增量数据，划分到一起，进一步的，还可以将多个用户的相关增量数据划分为一个“消费端(Consumer)”，并在该消费端中，将按照增量数据的更新时间进行用户排序，以得到最终的分类结果。

步骤B3：根据该分类结果，将同一播放内容的增量数据同步到第二数据库中，和/或，将同一用户的增量数据，通过同一个线程，同步到第二数据库中。

通过步骤B2将增量数据进行分类，得到分类结果后，可以将其中同一播放内容的增量数据，通过同一个线程，同步到第二数据库中，和/或，将同一用户的所有相关增量数据，按照同一个消息格式，通过同一个线程，按序顺次同步到第二数据库中，从而可以有效避免传统的数据并发传输时导致的数据不一致的问题，完成将增量数据从第一数据库准确同步到第二数据库中，避免增量数据的丢失。

进一步的，将增量数据同步到第二数据库中后，在本申请实施例一些可能的实现方式中，本申请还包括下述步骤C1-C2：

步骤C1：判断第二数据库是否成功接收目标实体的增量数据。

在本实现方式中，当通过上述步骤将同一播放内容的增量数据顺次同步到第二数据库中，和/或，将同一用户的所有相关增量数据按序顺次同步到第二数据库中后，进一步还可以判断出第二数据库是否成功接收目标实体的增量数据，比如可以通过数据库查询的方式，分别从第一数据库和第二数据库中查询出目标实体的所有相关增量数据，并判断二者是否完全一致，若是，则表明所有增量数据已成功完成同步，若否，则需要执行后续步骤C2。

或者，也可以通过判断第二数据库的接收状态的方式，来确认第一数据库中的待同步的目标实体的增量数据是否被接收成功。需要说明的是，具体的判断第二数据库是否成功接收目标实体的增量数据的方式可根据实际情况进行设置，本申请对此不进行限定。

其中，还需要说明的是，导致第二数据库未成功接收第一数据库中目标实体的增量数据的原因可能是消费方代码bug或RMQ消息丢失等。

步骤C2：若判断出第二数据库未成功接收目标实体的增量数据，则将第一数据库中的待同步的目标实体的增量数据存储于消息队列中，并在进行下一时刻的数据同步时，将该目标实体的增量数据顺次同步到第二数据库中。

在本实现方式中，若通过步骤C1判断出第二数据库未成功接收目标实体的增量数据，比如，若接收到第二数据库反馈的未成功接收增量数据的状态标识，则表明第二数据库未成功接收到目标实体的增量数据，此时，则可以根据RMQ的消息重试且重试次数可配置等特性，先将该第一数据库中的待同步的目标实体的增量数据存储于消息队列中，以便当通过RMQ进行下一时刻的数据同步时，可以将该增量数据再次按序顺次向第二数据库进行同步。

另外，在通过上述步骤S201-S202完成第一数据库中待同步的目标实体的增量数据的同步后，在本申请实施例一些可能的实现方式中，本申请还包括下述步骤D1-D3：

步骤D1：将第二数据库中的目标实体的增量数据同步到第三数据库中。

在本实现方式中，为了判断出第二数据库中存储的目标实体的增量数据与第一数据库中存储的目标实体的增量数据是否一致，可以先将第二数据库中的目标实体的增量数据同步到第三数据库中，其中，第三数据库是作为第二数据库的备份数据源，用以备份第二数据中的所有数据，并且，实际应用中，可以将第三数据库取为MySQL。

步骤D2：判断第一数据库和第三数据库中的目标实体的增量数据是否一致。

通过步骤D1将第二数据库中的目标实体的增量数据同步到第三数据库后，可以利用数据读取方法，分别读取出第一数据库和第三数据库中目标实体的数据中的每一一用户的所有相关数据，然后，可以判断出第一数据库和第三数据库中存储的同一个用户所有相关数据是否一致，若是，则表明第一数据库、第二数据库以及第三数据库中存储的目标实体的数据是一致的，若否，则需要继续执行后续步骤D3。

例如：在读取出第一数据库中用户M的所有相关数据，以及读取出第三数据库中用户M的所有相关数据后，可以判断出二者是否完全一致，若是，则表明第一数据库、第二数据库以及第三数据库中存储的用户M的所有相关数据是一致的，若否，则表明第一数据库、第二数据库以及第三数据库中存储的用户M的所有相关数据是不一致的。

步骤D3：若判断出第一数据库和第三数据库中的目标实体的数据不一致，则根据该判断结果，对第二数据库和第三数据库中的数据进行修复，以保证第一数据库、第二数据库以及第三数据库中目标实体的数据的一致性。

若通过步骤D2判断出第一数据库和第三数据库中的目标实体的数据不一致，则可以利用数据修复方法，对第二数据库和第三数据库中的数据进行修复，比如，如图3所示，在数据监控过程中，若检测出第一数据库和第三数据库中的目标实体的数据不一致，则可以采用现有或未来出现的数据监控自动修复的方法，对第二数据库和第三数据库中的数据进行修复，具体来讲，可以将检测到不一致的目标实体的数据，记录到第三数据库中，在进行不一致数据修复时，可以从第三数据库中获取不一致的数据记录，基于该记录，对第二数据库进行目标实体的数据的相应修复，以保证第一数据库、第二数据库以及第三数据库中目标实体的数据的一致性。

这样，在本申请提供的数据同步方法中，消息中间件首先获取第一数据库中待同步的目标实体的增量数据，然后，可以将获取到的第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。可见，相比于将增量数据同时写入第一数据库和第二数据库的分布式数据写入方法，本申请实施例是在将目标实体的增量数据写入第一数据库后，再通过消息中间件获取到第一数据库中待同步的目标实体的增量数据，并将该增量数据顺次同步到第二数据库中，这样的先后操作顺序能够有效保证第一数据库和第二数据库中目标实体的数据的一致性，并且通过采用消息中间件将增量数据顺次同步到第二数据库的方式，能够避免增量数据的丢失，有效解决了现有的技术问题。

为便于理解，现结合图3所示一种数据同步方法的结构示意图。对本申请实施例提供的数据同步方法的实现过程进行介绍。

如图3所示，假设目标实体的增量数据为自媒体服务数据、认证后台数据等，第一数据库为MySQL，第二数据库为远程数据库。则本申请实施例的实现过程为：首先，在获取到自媒体服务数据、认证后台数据等待同步的目标实体的增量数据后，可以先将这些增量数据写入MySQL中，然后，消息中间件(如RMQ)可以根据MySQL中的存储增量数据更新信息的文件(如binlog)，获取到MySQL中目标实体的增量数据的日志更新记录，或者，按照预设时间周期，获取包含第一数据库中待同步的目标实体的增量数据的消息协议，接着，再根据该日志更新记录或消息协议，获取第一数据库MySQL中待同步的目标实体的增量数据，进而，可以基于RMQ的特性，通过uid取模的方式，将增量数据按照业务类型和/或所属用户进行划分，以得到各个“消费端(如图3所示的Consumer模块)”作为分类结果，最后，可以按序将各个Consumer模块中所有增量数据顺次同步到远程数据库中。具体实现过程参见步骤S201～S202。

此外，在完成第一数据库中待同步的目标实体的增量数据的同步后，还可以将远程数据库中的目标实体的增量数据同步到备份数据源中，用以判断MySQL和远程数据库中的目标实体的数据是否一致，具体实现过程参见步骤D1～D3。

上述实施例详细叙述了本申请方法的技术方案，相应地，本申请还提供了数据同步装置，下面对该装置进行介绍。

参见图4，图4是本申请实施例提供的一种数据同步装置的结构示意图，如图4所示，该装置包括：

获取单元401，用于获取第一数据库中待同步的目标实体的增量数据；

第一同步单元402，用于将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。

可选地，所述获取单元401包括：

第一获取子单元，用于获取包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件；

第二获取子单元，用于根据所述包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件，获取所述第一数据库中所述目标实体的日志更新记录。

可选地，所述获取单元401具体用于：

按照预设时间周期，获取包含所述第一数据库中待同步的目标实体的增量数据的消息协议。

可选地，所述第一同步单元402还包括：

判断子单元，用于判断所述第二数据库是否成功接收所述目标实体的增量数据；

存储子单元，用于若判断出所述第二数据库未成功接收所述目标实体的增量数据，则将所述第一数据库中的待同步的目标实体的增量数据存储于消息队列中，并在进行下一时刻的数据同步时，将所述目标实体的增量数据顺次同步到第二数据库中。

可选地，所述装置还包括：

第二同步单元，用于将所述第二数据库中的目标实体的增量数据同步到第三数据库中；

判断单元，用于判断所述第一数据库和第三数据库中的目标实体的数据是否一致；

修复单元，用于若判断出所述第一数据库和第三数据库中的目标实体的数据不一致，则根据判断结果，对所述第二数据库和第三数据库中的数据进行修复，以保证所述第一数据库、所述第二数据库以及所述第三数据库中目标实体的数据的一致性。

这样，在本申请提供的数据同步装置中，消息中间件首先获取第一数据库中待同步的目标实体的增量数据，然后，可以将获取到的第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。可见，相比于将增量数据同时写入第一数据库和第二数据库的分布式数据写入方法，本申请实施例是在将目标实体的增量数据写入第一数据库后，再通过消息中间件获取到第一数据库中待同步的目标实体的增量数据，并将该增量数据顺次同步到第二数据库中，这样的先后操作顺序能够有效保证第一数据库和第二数据库中目标实体的数据的一致性，并且通过采用消息中间件将增量数据顺次同步到第二数据库的方式，能够避免增量数据的丢失，有效解决了现有的技术问题。

需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统或装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种数据同步方法，其特征在于，所述方法应用于消息中间件，所述方法包括：

获取第一数据库中待同步的目标实体的增量数据；

将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。

2.根据权利要求1所述的方法，其特征在于，所述获取第一数据库中待同步的目标实体的增量数据，包括：

获取包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件；

根据所述包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件，获取所述第一数据库中所述目标实体的日志更新记录。

3.根据权利要求1所述的方法，其特征在于，所述获取第一数据库中待同步的目标实体的增量数据，包括：

按照预设时间周期，获取包含所述第一数据库中待同步的目标实体的增量数据的消息协议。

4.根据权利要求1所述的方法，其特征在于，所述将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中之后，还包括：

判断所述第二数据库是否成功接收所述目标实体的增量数据；

若否，则将所述第一数据库中的待同步的目标实体的增量数据存储于消息队列中，并在进行下一时刻的数据同步时，将所述目标实体的增量数据顺次同步到第二数据库中。

5.根据权利要求1所述的方法，其特征在于，所述将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中之后，还包括：

将所述第二数据库中的目标实体的增量数据同步到第三数据库中；

判断所述第一数据库和第三数据库中的目标实体的增量数据是否一致；

若否，则根据判断结果，对所述第二数据库和第三数据库中的数据进行修复，以保证所述第一数据库、所述第二数据库以及所述第三数据库中目标实体的数据的一致性。

6.一种数据同步装置，其特征在于，所述装置包括：

获取单元，用于获取第一数据库中待同步的目标实体的增量数据；

第一同步单元，用于将所述第一数据库中待同步的目标实体的增量数据顺次同步到第二数据库中。

7.根据权利要求6所述的装置，其特征在于，所述获取单元包括：

第一获取子单元，用于获取包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件；

第二获取子单元，用于根据所述包含所述第一数据库中待同步的目标实体的增量数据更新信息的文件，获取所述第一数据库中所述目标实体的日志更新记录。

8.根据权利要求6所述的装置，其特征在于，所述获取单元具体用于：

按照预设时间周期，获取包含所述第一数据库中待同步的目标实体的增量数据的消息协议。

9.根据权利要求8所述的装置，其特征在于，所述第一同步单元还包括：

判断子单元，用于判断所述第二数据库是否成功接收所述目标实体的增量数据；

存储子单元，用于若判断出所述第二数据库未成功接收所述目标实体的增量数据，则将所述第一数据库中的待同步的目标实体的增量数据存储于消息队列中，并在进行下一时刻的数据同步时，将所述目标实体的增量数据顺次同步到第二数据库中。

10.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二同步单元，用于将所述第二数据库中的目标实体的增量数据同步到第三数据库中；

判断单元，用于判断所述第一数据库和第三数据库中的目标实体的数据是否一致；

修复单元，用于若判断出所述第一数据库和第三数据库中的目标实体的数据不一致，则根据判断结果，对所述第二数据库和第三数据库中的数据进行修复，以保证所述第一数据库、所述第二数据库以及所述第三数据库中目标实体的数据的一致性。