一种数据同步方法、装置及系统与流程

本申请涉及数据库技术领域，尤其涉及一种数据同步方法、装置及系统。

背景技术：

在大数据时代，出于灾备的目的，数据拥有方一般都会建设两个以上的数据中心。在传统的冷备容灾方案中，主数据中心用于承担核心业务，其他数据中心用于对主数据中心的数据进行备份，这种方案的问题在主数据中心和备份中心之间不能直接复用，备份数据中心只在灾难发生时才能起到作用，导致资源利用率低下。另外备份数据中心接替主数据中心也需要较长的处理时间和较为复杂的操作，往往会严重影响到正常业务的处理。

分布式多活数据中心(简称多活)技术是针对冷备技术所存在的问题而提出，其实现思路是：多个数据中心的业务没有主备之分，正常模式下协同工作，并行地为业务访问提供服务，避免备份数据中心处于闲置状态，同时可以成倍提高系统的服务能力。而在其中一个数据中心发生故障的情况下，其他数据中心可以迅速接管全部业务。

在多活方案中，由于各个数据中心的地位是相对平行的，因此对于数据中心的之间数据同步的时效性要求较高。特别是在数据中心异地部署的应用场景下，如何在较远的通信距离上尽量提高两地数据同步的时效性，是当前多活数据中心建设所面临的一个重要问题。

技术实现要素：

针对上述技术问题，本申请提供一种数据同步方法、装置及系统，技术方 案如下：

根据本申请的第1方面，提供一种数据同步方法，该方法包括：

数据同步源端确定源端数据库的数据修改后，针对本次数据修改生成实时通知，将所述实时通知发送至数据同步目标端，所述实时通知中，携带本次数据修改的相关信息；

数据同步目标端接收到所述实时通知后，从所述实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新。

根据本申请的第2方面，提供一种数据同步方法，应用于数据同步源端，该方法包括：

确定源端数据库的数据修改后，针对本次数据修改生成实时通知，所述实时通知中，携带本次数据修改的相关信息；

将所述实时通知发送至数据同步目标端，以使得数据同步目标端接收到所述实时通知后，从所述实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新。

根据本申请的第3方面，提供一种数据同步方法，应用于数据同步目标端，该方法包括：

接收数据同步源端发送的实时通知；

从所述实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新；

其中，所述实时通知，是在数据同步源端确定源端数据库的数据修改后，针对本次数据修改生成并发送，所述实时通知中，携带本次数据修改的相关信息。

根据本申请的第4方面，提供一种数据同步源端装置，该装置包括：实时通知生成模块、实时通知发送模块；

所述实时通知生成模块用于在确定源端数据库的数据修改后，针对本次数据修改生成实时通知；所述实时通知中，携带本次数据修改的相关信息；

所述实时通知发送模块用于将所述实时通知发送至数据同步目标端；以使 得数据同步目标端接收到所述实时通知后，从所述实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新。

根据本申请的第5方面，提供一种数据同步目标端装置，该装置包括：实时通知接收模块、缓存数据更新模块；

所述实时通知接收模块用于接收数据同步源端发送的实时通知；

所述缓存数据更新模块用于从所述实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新；

其中，所述实时通知，是数据同步源端在确定源端数据库的数据修改后，针对本次数据修改生成并发送，所述实时通知中，携带本次数据修改的相关信息。

根据本申请的第6方面，提供一种数据同步系统，该系统包括数据同步源端装置及数据同步目标端装置：

所述数据同步源端装置包括：实时通知生成模块、实时通知发送模块；

所述实时通知生成模块用于在确定源端数据库的数据修改后，针对本次数据修改生成实时通知；所述实时通知中，携带本次数据修改的相关信息；

所述实时通知发送模块用于将所述实时通知发送至数据同步目标端；

所述数据同步目标端装置包括：实时通知接收模块、缓存数据更新模块；

所述实时通知接收模块用于接收所述实时通知，

所述缓存数据更新模块用于从所述实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新。

本申请提供的技术方案，数据同步源端修改数据后，立刻向数据同步目标端发送实时通知，目标端接收到实时通知后，如果能够直接根据实时通知中携带的信息更新本地的数据库缓存，则无需等待底层数据库的同步完成再进行缓存更新，从而降低缓存同步更新的时延；如果目标端无法直接根据实时通知中携带的信息更新本地的数据库缓存，也可以得知本地数据库即将被同步更新，进一步可以对本地数据库的发起监测，以便在本地数据完成同步后第一时间对缓存数据进行更新，从而达到降低缓存同步更新时延的效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

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

图1是现有技术双活系统的第一种结构示意图；

图2是现有技术双活系统的第二种结构示意图；

图3是本申请的双活系统的第一种结构示意图；

图4是本申请的双活系统的第二种结构示意图；

图5是本申请的数据同步方法的第一种流程示意图；

图6是本申请的数据同步方法的第一种流程示意图；

图7是本申请的数据同步源端装置的结构示意图；

图8是本申请的数据同步目标端装置的结构示意图；

图9是本申请的数据同步系统的结构示意图；

图10是用于配置本申请装置的一种设备的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

首先对多活数据中心方案的系统架构及工作原理进行简单介绍，图1示出了一种双活系统的架构示意图，两个数据中心分别架设在机房a和机房b。数 据库a和数据库b分别位于机房a和机房b，在每个机房中，应用服务器直接与数据库进行交互，应用服务器根据用户侧或其他系统发送的指令，对本地的数据库进行读写操作。根据多活系统的要求，如果某个机房的数据库被修改，需要尽快将修改情况同步到其他机房，在同步过程中，将首先被修改的数据库称为源端数据库，将后续同步的数据库称为目标数据数据库。

以图1所示的双活系统为例，根据底层数据库的原生数据同步方案，假设应用服务器a对数据库a进行了写入操作，则在数据库a侧发生的所有写入事件都会被按序打包，然后按批次输到另一侧的数据库b进行相应的数据修改，修改完成后，应用服务器b就可以从数据库b读取到与数据库a完全一致的数据。

缓存是数据库操作中的一种常用技术，相对于基本的底层数据库存储区域而言，缓存具有更优的数据读写性能，并且可以避免应用侧与底层数据库直接交互。例如，对于状态型数据而言，一个比较明显的特征就是读多写少，以用户信息数据为例，用户在注册阶段填写个人信息之后，就不太可能频繁地对个人信息进行修改。基于这样的特征，大部分系统都会在数据库上层使用一层缓存来抵挡大量的数据查询请求，从而减少实际发送至数据库的查询请求，提升系统总体的查询性能。

在多活系统中同样可以应用缓存技术，参见图2所示，在数据库上层设置一层缓存，并且预先将常用数据放入缓存，应用服务器需要使用数据时，会优先从缓存中读取数据，从而提高数据读取的效率，同时避免应用服务器与底层的数据库直接交互，降低底层数据库的读写负担。

由于加入缓存机制后，缓存成为了应用服务器读取数据的主要来源，因此在数据中心之间进行数据同步时，必须进一步考虑目标端机房缓存的同步更新问题，以确保目标端数据查询的正确性。以图2所示的双活系统为例，根据现有的同步方案，如果应用服务器a对数据库a进行了写入操作，则缓存a和缓存b都需要进行相应的更新，缓存a的更新属于本地操作，可以直接采用现有技术方案，这里不做进一步说明；而缓存b的更新，则需要先完成数据库a与 数据库b之间的数据同步操作，再由应用服务器b根据同步后的数据库b对本地的缓存b进行更新。此外，双活系统中，也可以在机房a部署两个数据库，其中一个数据库作为写库，一个数据库作为读库，其他机房，例如机房b部署读库，这样，数据的写入操作均通过机房a中的写库进行，而写库写入数据后，可将新写入的数据同步本地机房的读库以及其他机房的读库，这样在缓存操作时，写库写入的数据，需要先通过到各机房的读库后，才能更新相应的缓存。

在实际应用中，这种缓存数据同步方式至少存在两方面问题：

首先，在缓存机制下，目标端的应用服务器会优先从缓存中读取数据，因此对目标端缓存数据的同步更新才是最终目的。底层数据库之间的串行数据同步效率本身就比较低，特别在数据中心异地部署的情况下，时延已经比较明显，而加入缓存更新步骤后，会导致时延的进一步增加。

其次，对于目标端的应用服务器而言，实际上并不能感知到本地底层数据的更新，也就无法第一时间对缓存数据进行更新，从而使得时延现象更为严重。

以异地数据中心为例，两个数据中心分别部署在距离1000km的两个城市，经测试，数据库写库与异地读库的数据同步时延在3s左右，所以如果两地的数据同步全部采用数据库的原生数据同步复制方案，数据时效性会达到秒级别，可能会出现用户在一个城市的数据中心写入数据，然后从另一个城市的数据中心却无法立即读取到刚刚写入的数据，需要用户等待几秒钟后自行重试才能解决，影响了用户体验。

针对上述问题，本申请提供一种数据同步方法，以降低数据中心之间数据库缓存的同步更新时延，该方法包括以下步骤：

数据同步源端确定源端数据库的数据修改后，针对本次数据修改生成实时通知，将实时通知发送至数据同步目标端，实时通知中，携带本次数据修改的相关信息；

数据同步目标端接收到实时通知后，从实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新。

上述方法的执行主体，可以是分别位于数据同步源端和数据同步目标端的 同步装置，如图3所示，位于数据同步源端的同步装置a与应用服务器a通信连接，确定应用服务器a对数据库a执行写入操作后，生成实时通知发送给位于数据同步目标端的同步装置b，同步装置b根据该实时通知直接对缓存b进行更新。

可以理解的是，在实际应用设计中，上述同步装置的相关功能模块，既可以全部位于与应用服务器相对独立的物理实体(例如专用的服务器)中，如图3所示。也可以有部分或全部位于应用服务器中，在同步装置的全部功能模块均位于应用服务器中的情况下，相当于数据同步源端和数据同步目标端两侧的同步装置功能均整合在两侧的应用服务器中，则相应的系统架构可以简化为如图4所示，前述的同步装置与应用服务器之间的交互则简化为应用服务器的内部交互。

本申请所提供的技术方案，通过引入实时通知来降低数据同步目标端数据库缓存的更新时延，而并不需要对底层数据库的原生数据同步方案做过多调整。另外，数据同步源端本地的缓存更新操作，可以直接采用现有技术方案实现，而且与数据同步目标端数据库缓存的更新时延基本无关，因此在本申请中不另做说明。

需要说明的是，根据图3和图4所示出的系统，一种典型的配置方案是：数据库a为写库、数据库b为读库。当然本申请方案与数据库的读写分离机制并没有必然联系，例如数据库a与数据库b也可以都是写库，或者，可以在一个机房部署写库和读库，其他机房部署读库等，这并不影响本申请方案的实现。

下面结合具体的实施例，对本申请所提供的数据同步方法做进一步详细说明。

图5示出了在双活系统中应用本申请方案的一种数据同步流程，为描述方便，以下实施例将结合图4所示的简化系统架构对整个流程进行说明。

s101，数据同步源端确定源端数据库的数据修改；

确定数据修改的确定时机，可以是在应用服务器a向数据库a发出数据写入请求后，也可以是在确定数据库a已经写入成功后，前一种方式理论上可以 进一步降低整体流程的时延，后一种方式则可以避免数据同步源端数据库写入失败而导致的数据同步目标端缓存更新与数据库不一致的情况，本领域技术人员可以根据系统的稳定性能、应用场景等因素灵活设置。

s102，数据同步目标端针对本次数据修改生成实时通知，并将实时通知发送至数据同步目标端。

本实施例中，应用服务器a将每次对数据库a的数据写入操作对应的数据修改详细情况写入实时通知中，也即将修改详细情况写入实时通知所对应的消息体中。这里的修改详细情况至少应包括修改后的数值信息，例如{张三,男,20}，根据数据库的实际数据存储格式及两侧数据的传输方式约定，还可能进一步包括修改涉及的数据表标识、行标识、列标识等信息，例如{name＝“张三”，age＝“20”}等等，本申请对“修改详细情况”所涉及的具体信息内容不需要进行限定。实时通知生成后，立即发送至数据同步目标端。

可以理解的是，在实时通知的生成及发送过程中，可以进一步采用压缩、加密或其他编码方式，从而达到提高传输效率、保密传输等效果，本申请实施例对实时通知的具体生成及传输方式并不需要进行限定。

另外作为对照，在s103，应用服务器a向数据库a写入成功后，数据库a开始就本次修改发起对数据库的同步操作。这里需要说明的是，对于数据同步源端而言，步骤s102和s103对应是两个相对独立的操作，因此两个步骤之间并没有时序上的先后限制；对于数据同步目标端而言，步骤104在时序上应位于接收到实时通知之后。

s104，数据同步目标端从实时通知中解析得到数据修改详细信息，直接根据解析结果对目标端数据库缓存进行更新；

在数据同步目标端，应用服务器b实时对实时通知接收端口进行检测，接收到实时通知后，立即对其进行解析，根据应用服务器a对实时通知的处理，应用服务器b在解析可能需要执行相应的解压缩、解密等操作，这里不再详细说明。

在本实施例中，应用服务器b从实时通知解析得到对数据库a的数据修改 详细情况后，直接根据解析结果，对本地的数据库缓存b进行更新。由于底层数据库数据的同步并不是实时向异地进行传输，而是积累了一定数量的修改数据块之后按批次打包进行传输，因此实时通知的平均传输速度要高于底层数据库的同步速度，参见图4的s105所示，一般情况下，数据同步目标端在底层数据库同步完成之前，就能够根据实时通知直接更新本地缓存，不需要依赖底层数据库的同步完成。根据实际测试，在距离1000km左右的异地架构双活系统中，底层数据库的同步平均时延在3s左右，而通过实时通知的方式，可以将缓存数据的同步更新时延降低至30ms左右，甚至可以延时更低，数据库缓存同步的时效性得到明显改善。

需要说明的是，对于应用服务器b而言，接收到实时通知后会立即向缓存服务器发送更新消息以执行更新操作。但是对于缓存服务器而言，收到更新消息后，可能会进一步根据实际情况判断是否需要对缓存数据进行更新，例如根据数据的写入时间戳进行判断，或者通知消息中也可以携带一些其它信息，以便于根据该些信息确定是否需要更新缓存，例如可携带版本号信息，通过查看版本号来确定是否需要进行缓存的更新，等等。也就是说在一些情况下，尽管应用服务器b执行了更新操作，但是缓存数据最终是否更新成功需要由缓存服务器自身进行判断，这种更新方式并不影响本申请方案的实现。

在上述实施例中，数据同步源端将本地数据库的详细修改信息携带在实时通知中，利用实时通知的低时延特点，使得数据同步目标端不需要依赖底层数据库同步完成即可以先行完成本地数据库缓存的同步更新。然而，在实际应用中，实时通知中可传输的信息量可能会受到传输带宽、通知消息中心存储容量等多方面客观因素的限制，如果数据同步源端一次性修改的数据量过大，这些详细修改情况将难以通过实时通知传输至数据同步目标端，针对该情况，本申请也提供了相应的解决方案。其中，上述的实时通知可以通过消息系统来实现传送，例如可以利用已有的消息系统或者单独为此建立的消息系统，消息系统的架构和形式不做限制。

图6示出了在双活系统中应用本申请方案的另一种数据同步流程，为描述 方便，以下实施例将结合图3所示的系统架构对整个流程进行说明。

s201，数据同步源端确定源端数据库的数据修改；

本步骤与s101相似，本实施例不再赘述。

s202，数据同步目标端针对本次数据修改生成实时通知，并将实时通知发送至数据同步目标端。

应用服务器a对数据库a执行数据写入操作时，对于每一次写入操作都会生成一个标识信息，该标识信息可以是序列号，也可以是利用特定算法生成的标识字符串，等等，向数据库a发起写入请求时，应用服务器a将需要修改数据的详细情况(数值、数据表标识、行标识、列标识等)连同该标识信息一同提交给数据库a。在本实施例中，受实时通知消息体承载能力的限制，应用服务器a将该标识信息写入实时通知中。实时通知生成后，立即发送至数据同步目标端。

s203，应用服务器a向数据库a写入成功后，数据库a开始就本次修改发起对数据库的同步操作。在同步过程中，上述修改标识信息也与具体的数据修改内容一同被传输到数据库b。

与前一实施例类似，对于数据同步源端而言，步骤s202和s203对应是两个相对独立的操作，因此两个步骤之间并没有时序上的先后限制；对于数据同步目标端而言，步骤204在时序上应位于接收到实时通知之后。

s204，数据同步目标端从实时通知中解析得到数据修改操作标识，根据解析结果对目标端数据库进行监测。

在数据同步目标端，应用服务器b实时对实时通知接收端口进行检测，接收到实时通知后，立即对其进行解析，在本实施例中，应用服务器b从实时通知解析得到源端对数据库a的修改操作标识后，针对该标识开始对数据库b进行监测。

s205，数据同步源端到数据同步目标端的底层数据库同步完成；

s206，数据同步源端根据同步后的目标端数据库内容，对目标端数据库缓存进行更新；

应用服务器监测标识对应的修改操作已经从数据库a同步到数据库b后，从数据库b中读取相应的数据，然后根据读取结果对本地的数据库缓存b进行更新。

由于实时通知的传输速度高于底层数据库的同步速度，因此一般情况下，应用服务器b在接收到实时通知后，需要等待一段时间才能对缓存b进行更新。与前一实施例相比，在本实施例中，数据同步目标端需要等待底层数据库同步完成之后才能对本地缓存进行更新。但是由于使用了实时通知，使得数据同步目标端能够提前获知底层数据库将会修改，并且能够通过监测的方式，在同步完成后第一时间获取数据对缓存进行更新，因此与现有的技术方案相比，仍然能够在一定程度上降低缓存同步更新的时延。

以上实施例所介绍的两种数据同步方法，均能够不同程度地降低数据同步目标端缓存的同步更新时延，在实时通知容量不受限的情况下，可以选择第一种方案以实现较低的时延效果。在实际应用中，应用服务器对数据库的数据修改量往往是不确定的，以cif(customerinformationfile，用户信息文件)系统为例，对于个人用户信息的修改数据量一般较小，而对于某些关联了众多子账户的大型账户而言，一次修改可能涉及大量子账户的数据变更，针对这种情况，本申请还提供一种自适应的数据同步方案：

在数据同步源端，确定源端数据库的数据修改后，首先判断本次修改的数据量是否超过预设的阈值，该阈值是根据实时通知的承载能力确定，而实时通知的承载能力则取决于传输带宽、通知消息中心存储容量等多方面因素，当然阈值的确定可能还需要考虑生成实时通知时的压缩、编码等因素。总之，如果判断认为实时通知能够承载本次修改操作所涉及的具体修改情况，则将包括至少包括修改具体数值信息在内的修改情况写入实时通知中；如果判断认为实时通知无法承载本次修改操作所涉及的具体修改情况，则仅将本次修改的操作标识写入实时通知中。

在数据同步目标端，接收到实时通知后，首先对实时通知进行解析。如果解析结果中包括修改涉及的具体数值信息，则直接根据解析结果对目标端数据 库缓存进行更新；否则，根据解析得到的修改操作标识，对目标端数据库进行监测，当监测到该标识对应的修改操作已经从源端数据库同步到目标端数据库后，再从目标端数据库获取相应的数据对目标端数据库缓存进行更新。

在上述方案中，数据同步源端根据修改所涉及的数据量自适应地生成携带不同内容的实时通知。这样，对于小规模的数据修改，数据同步目标端无需等待底层数据库同步完成就可以对本地缓存数据进行更新，而对于大规模的数据修改，也可以在同步完成后第一时间对本地缓存数据进行更新。

可以理解的是，以上实施例中仅示出了针对一次数据修改的缓存同步更新过程，对于连续发生的数据修改，只需重复上述流程即可。另外，以上实施例仅以双活系统为例进行说明，对于包括三个以上数据中心的多活系统而言，数据同步源端与各个数据同步目标端的缓存更新流程是类似的，本申请实施例不再做重复说明。

本申请还提供一种数据同步源端装置，参见图7所示，该装置可以包括：实时通知生成模块110、实时通知发送模块120；

实时通知生成模块110用于在确定源端数据库的数据修改后，针对本次数据修改生成实时通知；该实时通知中，携带本次数据修改的相关信息；

实时通知发送模块120用于将实时通知发送至数据同步目标端；以使得数据同步目标端接收到实时通知后，从实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新。

在本申请的一种具体实施方式中，实时通知生成模块110可以具体用于：在确定源端数据库的数据修改后，将本次修改涉及的具体数值信息写入实时通知中。

在本申请的一种具体实施方式中，实时通知生成模块110可以具体用于：在确定源端数据库的数据修改后，将本次修改的操作标识写入实时通知中。

在本申请的一种具体实施方式中，实时通知生成模块110可以具体用于：在确定源端数据库的数据修改后，判断本次修改的数据量是否超过预设的阈值；如果否，则将本次修改涉及的具体数值信息写入实时通知中；如果是，则将本 次修改的操作标识写入实时通知中。

在本申请的一种具体实施方式中，数据同步源端装置可以配置在数据同步源端应用服务器中。

本申请还提供一种数据同步目标端装置，参见图8所示，该装置可以包括：实时通知接收模块210、缓存数据更新模块220；

实时通知接收模块210用于接收数据同步源端发送的实时通知；

缓存数据更新模块220用于从实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新；

其中，所述实时通知，是数据同步源端在确定源端数据库的数据修改后，针对本次数据修改生成并发送，该实时通知中，携带本次数据修改的相关信息。

在本申请的一种具体实施方式中，实时通知中可以包括本次修改涉及的具体数值信息；

相应地，缓存数据更新模块220可以具体用于：根据解析得到的修改涉及的具体数值信息，直接对目标端数据库缓存进行更新。

在本申请的一种具体实施方式中，实时通知中可以包括本次修改的操作标识；

相应地，缓存数据更新模块220可以具体用于：根据解析得到的修改操作标识，对目标端数据库进行监测，当监测到该标识对应的修改操作已经从源端数据库同步到目标端数据库后，根据同步后的目标端数据库内容，对目标端数据库缓存进行更新。

在本申请的一种具体实施方式中，实时通知中可以包括：本次修改涉及的具体数值信息、或本次修改的操作标识；

相应地，缓存数据更新模块220可以具体用于：在解析结果为修改涉及的具体数值信息的情况下，直接根据解析结果对目标端数据库缓存进行更新；在解析结果为修改操作标识的情况下，根据该标识对目标端数据库进行监测，当监测到该标识对应的修改操作已经从源端数据库同步到目标端数据库后，根据同步后的目标端数据库内容，对目标端数据库缓存进行更新。

在本申请的一种具体实施方式中，数据同步目标端装置可以配置在数据同步目标端应用服务器中。

本申请还提供一种数据同步系统，参见图9所示，该装置可以包括数据同步源端装置100及数据同步目标端装置200：

数据同步源端装置100可以包括：实时通知生成模块110、实时通知发送模块120；

实时通知生成模块110用于在确定源端数据库的数据修改后，针对本次数据修改生成实时通知；该实时通知中，携带本次数据修改的相关信息；

实时通知发送模块120用于将实时通知发送至数据同步目标端；

数据同步目标端装置200可以包括：实时通知接收模块210、缓存数据更新模块220；

实时通知接收模块210用于接收实时通知，

缓存数据更新模块220用于从实时通知中解析得到数据修改相关信息，根据解析结果对目标端数据库缓存进行更新。

在本申请的一种具体实施方式中，实时通知生成模块120可以具体用于在确定源端数据库的数据修改后，将本次修改涉及的具体数值信息写入实时通知中；

对应地，缓存数据更新模块220可以具体用于根据解析得到的修改涉及的具体数值信息，直接对目标端数据库缓存进行更新。

在本申请的另一种具体实施方式中，实时通知生成模块120可以具体用于在确定源端数据库的数据修改后，将本次修改的操作标识写入实时通知中；

对应地，缓存数据更新模块220可以具体用于根据解析得到的修改操作标识，对目标端数据库进行监测，当监测到该标识对应的修改操作已经从源端数据库同步到目标端数据库后，根据同步后的目标端数据库内容，对目标端数据库缓存进行更新。

在本申请的另一种具体实施方式中，实时通知生成模块120可以具体用于在确定源端数据库的数据修改后，判断本次修改的数据量是否超过预设的阈值； 如果否，则将本次修改涉及的具体数值信息写入实时通知中；如果是，则将本次修改的操作标识写入实时通知中；

对应地，缓存数据更新模块220可以具体用于：在解析结果为修改涉及的具体数值信息的情况下，直接根据解析结果对目标端数据库缓存进行更新；在解析结果为修改操作标识的情况下，根据该标识对目标端数据库进行监测，当监测到该标识对应的修改操作已经从源端数据库同步到目标端数据库后，根据同步后的目标端数据库内容，对目标端数据库缓存进行更新。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

在实际应用设计中，上述数据同步源端装置和数据同步目标端装置的相关功能模块，既可以全部位于与应用服务器相对独立的物理实体(例如专用的服务器)中，如图3所示。也可以有部分或全部位于应用服务器中，在同步装置的全部功能模块均位于应用服务器中的情况下，相当于数据同步源端和数据同步目标端两侧的同步装置功能均整合在两侧的应用服务器中，则相应的系统架构可以简化为如图4所示，前述的同步装置与应用服务器之间的交互则简化为应用服务器的内部交互。

本申请所提供的数据同步源端装置和数据同步目标端装置可以分别配置于服务器等硬件设备上，图10所示，为本申请所提供的用于配置上述装置的一种设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提 供的技术方案。

存储器1020可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相 似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置或系统实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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