CN105338093A

CN105338093A - 一种数据同步方法和系统

Info

Publication number: CN105338093A
Application number: CN201510781880.5A
Authority: CN
Inventors: 胡俊; 薛红星; 张涛; 郑凯婷; 廖宫燕; 姚芳; 宋捷; 季宜锋; 李泳驱; 袁国能
Original assignee: China Construction Bank Corp
Current assignee: China Construction Bank Corp
Priority date: 2015-11-16
Filing date: 2015-11-16
Publication date: 2016-02-17

Abstract

本发明提供了一种数据同步方法和系统。所述方法包括：判断待同步数据的类别，若所述待同步数据为实时同步数据，则在所述第一数据中心完成对所述待同步数据的本地数据库同步操作之后就向第二数据中心发起同步请求，并接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功；若所述待同步数据为定期同步数据，则定期向所述第二数据中心发起批量数据同步请求以对所述第二数据中心的本地数据库进行同步。实施本发明的方法和系统，能够对两个数据中心之间的数据进行有效同步，确保交易的一致性。

Description

一种数据同步方法和系统

技术领域

本发明涉及数据处理领域，更为具体而言，涉及一种数据同步方法和系统。

背景技术

随着中国经济的快速发展，国内各大商业银行各业务的交易量持续增长，业务复杂度不断提高，数据集中需求日益突出，这些无疑都给后台计算机系统的处理能力提出了新的挑战。目前，国内外各大商业银行大多采用高性能高可靠的集群架构进行核心系统的建设。

目前大多数商业银行的集群架构采用的是“两地三中心”模式，即生产数据中心、同城灾备中心和异地灾备中心。数据中心间是主备关系。为了保障系统能不间断提供业务服务，采用双数据中心独立对外提供服务，简称双活。双中心不仅要保证应用服务器独立，同时数据库服务器也是独立的，但对于实时性要求较高的银行交易数据来说，若两个数据中心之间的数据不同步，会造成严重的交易问题。

目前银行的容灾备份系统大多采取的是主备模式。在这种模式下，主用系统或备用系统本身常常通过轮询的方式从系统中的各单元获取源数据更新的信息，例如通过轮询来检查与各单元数据对应的时间是否发生变化。这种方式的缺点在于，更新始终有滞后性，特别是在有大量动态数据的情况下，轮询将花费更多的时间并且会影响相应单元的操作。在实际的运行过程中主备系统会出现响应与切换周期长，资源利用率低和无法实现业务零中断的问题。因此，两个数据中心或者数据系统之间在确保业务连续的前提下进行数据同步，成为了目前亟需解决的技术问题。

发明内容

为解决上述技术问题，本发明提供了一种数据同步方法和系统。

根据本发明实施方式的第一方面，提供了一种数据同步方法，该方法可包括：判断待同步数据的类别，若所述待同步数据为实时同步数据，则在所述第一数据中心完成对所述待同步数据的本地数据库同步操作之后就向第二数据中心发起同步请求，并接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功；若所述待同步数据为定期同步数据，则定期向所述第二数据中心发起批量数据同步请求以对所述第二数据中心的本地数据库进行同步。

在本发明的一些实施方式中，所述请求反馈包括接收回执或者同步结果，其中，所述接收回执是所述第二数据中心在接收到所述同步请求之后，未对本地数据库更新之前，向所述第一数据中心返回的请求反馈，所述同步结果是所述第二数据中心在接收到所述同步请求之后，已对本地数据库更新之后，向所述第一数据中心返回的请求反馈。

在本发明的一些实施方式中，所述接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功包括：接收所述第二数据中心返回的接收回执，若所述接收回执的结果为成功，则确定所述待同步数据同步成功，若所述接收回执的结果为失败，则将所述待同步数据记录在异常交易表，确定所述待同步数据同步失败。

在本发明的一些实施方式中，所述方法还包括：读取所述异常交易表中的待同步数据，向所述第二数据中心重新发起同步请求，接收所述第二数据中心返回的同步结果，根据所述同步结果的结果确定所述异常交易表中的待同步数据是否同步成功，若所述同步结果的结果为成功，则将所述异常交易表中的待同步数据的记录删除，若所述同步结果的结果为失败，则继续向所述第二数据中心重新发起同步请求。

在本发明的一些实施方式中，所述接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功包括：接收所述第二数据中心返回的同步结果，若所述同步结果的结果为成功，则确认所述第一数据中心的本地数据库的同步操作，确定所述待同步数据同步成功，若所述同步结果的结果为失败，则将所述第一数据中心的本地数据库的同步操作回滚，确定所述待同步数据同步失败。

在本发明的一些实施方式中，所述向第二数据中心发起同步请求是通过单向队列进行发送。

在本发明的一些实施方式中，所述接收所述第二数据中心返回的请求反馈是通过单向队列进行接收。

根据本发明实施方式的第二方面，提供了一种数据同步系统，所述系统包括：判断模块，用于判断待同步数据的类别；请求处理模块，设置于第一数据中心，用于：在待同步数据为实时同步数据时，在完成对所述待同步数据的本地数据库同步操作之后就向第二数据中心发起同步请求，并接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功；以及在所述待同步数据为定期同步数据时，定期向所述第二数据中心发起批量数据同步请求以对所述第二数据中心的本地数据库进行同步；同步模块，设置于所述第二数据中心，用于接收所述请求处理模块发送的同步请求，并向所述请求处理模块返回请求反馈。

在本发明的一些实施方式中，所述同步模块，还用于在接收到所述同步请求之后，向所述请求处理模块返回接收回执作为请求反馈，然后对所述同步请求的待同步数据进行本地数据库同步操作。

在本发明的一些实施方式中，所述同步模块，还用于在接收到所述同步请求之后，对所述同步请求的待同步数据进行本地数据库同步操作，然后向所述请求处理模块返回所述本地数据库同步操作的同步结果作为请求反馈。

在本发明的一些实施方式中，所述请求处理模块，还用于：在所述接收回执的结果为成功时确定所述待同步数据同步成功，在所述接收回执的结果为失败时将所述待同步数据记录在异常交易表，确定所述待同步数据同步失败。

在本发明的一些实施方式中，所述系统还包括：异常重发模块，用于：读取所述异常交易表中的待同步数据，向所述同步模块重新发起同步请求，接收所述同步模块返回的同步结果，根据所述同步结果的结果确定所述异常交易表中的待同步数据是否同步成功，若所述同步结果的结果为成功，则将所述异常交易表中的待同步数据的记录删除，若所述同步结果的结果为失败，则继续向所述第二数据中心重新发起同步请求。

在本发明的一些实施方式中，所述请求处理模块，还用于：在所述同步结果的结果为成功时确认所述第一数据中心的本地数据库的同步操作，确定所述待同步数据同步成功，在所述同步结果的结果为失败时将所述第一数据中心的本地数据库的同步操作回滚，确定所述待同步数据同步失败。

在本发明的一些实施方式中，所述同步模块是通过单向队列接收所述同步请求。

在本发明的一些实施方式中，所述同步模块是通过单向队列发送所述请求反馈。

本发明实施方式提供的数据同步方法和系统，能够根据待同步数据对实时性的要求分别进行实时同步和定期同步，有效缓解了数据同步的处理压力，而且有利于保证交易数据的一致性和完整性。

附图说明

图1是根据本发明一种实施方式的数据同步方法的流程示意图；

图2是根据本发明一种实施方式的两个数据中心的逻辑架构示意图；

图3是根据本发明一种实施方式的数据同步方法的流程示意图；

图4是根据本发明一种实施方式的数据传输通道的示意图；

图5是根据据本发明一种实施方式的消息队列的示意图；

图6是根据本发明一种实施方式的数据同步的流程示意图；

图7是根据本发明一种实施方式的数据同步的流程示意图；

图8是根据本发明一种实施方式的数据同步系统的结构示意图；

图9是根据本发明一种实施方式的数据同步系统的结构示意图。

具体实施方式

以下结合附图和具体实施方式对本发明的各个方面进行详细阐述。其中，众所周知的模块、单元及其相互之间的连接、链接、通信或操作没有示出或未作详细说明。并且，所描述的特征、架构或功能可在一个或一个以上实施方式中以任何方式组合。本领域技术人员应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。还可以容易理解，本文所述和附图所示的各实施方式中的模块或单元或处理方式可以按各种不同配置进行组合和设计。

参见图1，图1是根据本发明一种实施方式的数据同步方法的流程示意图，该方法可包括：

S101，判断待同步数据的类别，若是实时同步数据，则执行步骤S102，若是定期同步数据，则执行步骤S103；

S102，在所述第一数据中心完成对所述待同步数据的本地数据库同步操作之后就向第二数据中心发起同步请求，并接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功；

S103，定期向所述第二数据中心发起批量数据同步请求以对所述第二数据中心的本地数据库进行同步。

本发明的数据同步方法可适用于两个数据中心之间的数据同步，这两个数据中心为主备关系，主备数据中心都同时承担业务处理，主备两个数据中心可互为备份。下面主要以银行数据中心为例说明本发明的数据同步方法，需要说明的是，本发明的数据同步方法不仅仅适用于银行等金融行业的数据同步，还可适用于对数据实时性要求不同的其他领域的数据同步。

综合前置系统是处于银行IT结构的中间部分，负责将各类交易转发到各个业务处理子系统。综合前置系统采用双活架构，也就是说，将综合前置系统分别完整部署在两个数据中心，一个数据中心为主用数据中心，另一个数据中心为备用数据中心。这两个数据中心都是独立的数据中心，有独立的联机数据库(例如，可存储交易类数据等)和管理类数据库(例如，可存储管理类数据等)，它们可同时对外提供服务器。例如，参见图2，图2是根据本发明一种实施方式的两个数据中心的逻辑架构示意图。图2中的数据中心201可以是主用数据中心，数据中心202可以是备用数据中心。这两个数据中心201和202分别部署有综合前置系统2011和2021、联机数据库2012和2022以及管理数据库2013和2023。数据中心201和202从渠道系统203(例如，可包括柜面前置和ATM前置等)接收各种交易请求，发送到核心业务系统204进行相应的处理。

数据中心的各种交易数据根据对实时性的要求不同可分为实时同步数据(例如，交易类的数据)和定期同步数据(例如，管理类的数据)。交易类的数据直接影响联机交易是否成功，必须实时同步，包括现金尾箱信息，凭证尾箱信息和系统实时运行参数等。管理类的数据并不直接影响联机交易，包括机构信息、柜员信息、ATM信息和管理控制类等信息。这类数据对实时性要求较低，只需要进行定期同步(例如，日终同步)。

对于交易类数据等需要实时同步的数据，执行步骤S102，由第一数据中心完成对待同步数据的本地数据库(例如，联机数据库)的同步操作之后，向第二数据中心发起针对该待同步数据的数据同步请求，并接收第二数据中心返回的对于该数据同步请求的请求反馈，然后根据该请求反馈的结果(例如，成功或失败)确定待同步数据是否同步成功。

步骤S102中的数据同步可分为两种，可依据请求反馈的具体形式进行划分。请求反馈可包括接收回执或者同步结果，其中，接收回执是第二数据中心在接收到同步请求之后，立即向第一数据中心返回的请求反馈，在返回请求反馈之前并未对该第二数据中心的本地数据库针对该同步请求的数据进行更新；同步结果是第二数据中心在接收到同步请求之后，对该第二数据中心的本地数据库针对该同步请求的数据更新之后，向第一数据中心返回的请求反馈。

在请求反馈为接收回执的情形下，步骤S102中接收第二数据中心返回的请求反馈，然后根据该请求反馈的结果确定该待同步数据是否同步成功可包括：接收第二数据中心返回的接收回执，若该接收回执的结果为成功，则确定该待同步数据同步成功，然后可通知渠道系统的前置设备(例如，ATM前置或柜面前置设备等)交易成功；若接收回执的结果为失败，则将该待同步数据记录在异常交易表中，确定该同步数据同步失败，但通知渠道系统的前置设备交易成功。

本发明的数据同步方法还可包括对异常同步数据的重发步骤，具体而言，可包括：读取记录在异常交易表中的待同步数据，向第二数据中心重新发起对于该待同步数据的数据同步请求，接收该第二数据中心返回的同步结果，根据该同步结果的结果确定异常交易表中的待同步数据是否同步成功，若同步结果的结果为成功，也就是说，第二数据中心已经将该待同步数据更新到其本地数据库(例如，联机数据库)，则将异常交易表中的待同步数据的记录删除。若同步结果的结果为失败，也就是说，第二数据中心本次还是没有将该待同步数据更新到其本地数据库，则继续向第二数据中心发起同步请求，多次重复发起同步请求，直至成功将待同步数据更新到第二数据中心的本地数据库，或者通过人工的方式将待同步数据写入数据库。

在一种具体的实施例中，在请求反馈为接收回执的情况下，本发明的数据同步方法在请求发起方、同步服务器和数据库之间的数据同步操作过程可以如图6所示。步骤S601，请求发起方发起数据同步请求；步骤S602，同步服务器接收同步请求，然后向请求发起方返回接收回执；步骤S603，请求发起方接收同步服务器返回的接收回执；步骤S604，对数据库执行数据同步操作；步骤S605，判断数据库的同步结果，若同步结果为成功，在结束流程，若同步结果为失败，则执行步骤S606；步骤S606，判断已经重发的次数，若重发的次数超过预设的阈值，则执行步骤S607；若重发的次数未超过预设的预知，则执行步骤S604；步骤S607，通过人工方式向数据库写入文件，将待同步数据手动同步。

在本发明的返回接收回执的同步方式中，将发起数据同步请求视为交易成功的标识，在返回接收回执之后再进行数据库同步操作，一定程度上降低了联机交易的耦合性，在保持业务数据一致性的前提下，有利于改善交易数据处理的效率。

在请求反馈为同步结果的情况下，步骤S102中接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功可包括：接收第二数据中心返回的同步结果，若同步结果的结果为成功，也就是说，第二数据中心将待同步数据成功同步到其本地数据库，则确认第一数据中心的本地数据库针对该待同步数据的同步操作，确认待同步数据同步成功，并通知渠道系统的前置设备交易成功。若同步结果的结果为失败，也就是说，第二数据中心没有将待同步数据成功同步到其本地数据库，则将第一数据中心的本地数据库对于该待同步数据的同步操作回滚，确认待同步数据同步失败，并通知渠道系统的前置设备交易失败。

在本发明的请求反馈为同步结果的同步方式中，将两个数据中心的数据库同步操作保持严格一致，有利于保持业务数据库的高度一致性。

在一种具体的实施例中，上面描述的数据同步可以采用如图3所示的流程进行处理。其中，数据中心为301和302，每个数据中心可包括负载均衡器3011、3021、3015和3025，进行业务处理的应用集群3012和3022，数据库3013和3023，同步服务器3014和3024,渠道前置系统303包括前置设备3031和负载均衡器3032。

在一种数据实时同步处理中，渠道前置系统303将前置设备3031的交易数据通过负载均衡器3032发送到数据中心301。数据中心301的负载据衡器3011根据预定的负载均衡策略将交易数据转发至相应的业务服务器的应用集群3012进行处理，在应用集群3012完成交易处理后，更新数据中心301的本地数据库3013，在完成本地数据库3013的更新后，向数据中心302的发起数据同步请求。数据中心302的负载均衡器3025对数据同步请求进行负载均衡，并将同步请求转发至同步服务器3024，同步服务器3024接收到同步请求后，对数据中心302的本地数据库3023进行数据同步，并将数据库3023的同步结果返回数据中心301的应用集群3012。应用集群3012接收到同步结果之后，对同步结果的结果进行判断，若结果为成功，在确认对数据库3013的同步操作，并经由负载均衡器3011和3032通知前置设备3031该交易成功；若结果为失败，在将前面对数据库3013的同步操作回滚，并经由负载均衡器3011和3032通知前置设备3031该交易失败。

在上述的数据同步操作中是将交易数据发送至数据中心301，然而在另一些实施方式中，交易数据可发送至数据中心302，与数据中心301的数据同步过程类似，数据中心301和302的数据同步操作可通过图3中较粗的箭头和较细的箭头分别表示。

在另外一种数据同步处理过程中，渠道前置系统303中的前置设备3031通过负载均衡器3032将交易数据发送至数据中心301。数据中心301的3011根据预定的负载均衡策略将交易数据转发至相应的业务服务器的应用集群3012进行处理，在应用集群3012完成交易处理后，更新数据中心301的本地数据库3013，在完成本地数据库3013的更新后，向数据中心302的发起数据同步请求。数据中心302的负载均衡器3025对数据同步请求进行负载均衡，并将同步请求转发至同步服务器3024，同步服务器3024接收到同步请求后，马上向数据中心301的应用集群3011返回接收回执，然后再进行对本地数据库3023的数据更新操作。数据中心301的应用集群3011接收到接收回执之后，判断该接收回执的结果，若成功，则经由负载均衡器3011和3032通知前置设备3031该交易成功，若失败，则将该待同步数据的记录在异常交易表，然后经由负载均衡器3011和3032通知前置设备3031该交易成功。对于异常交易表中的同步失败交易，可通过多次重发同步请求进行同步，直至成功同步。在重发次数超过预定阈值(例如，3次、5次、7次等)，还可以通过人工手动导入同步数据进行同步。

本发明的数据中心之间的数据通信，可采用IBMWebsphereMQ消息中间件进行数据同步。消息传输可采用MQ的双通道模式实现，一个通道用于建立消息发送队列，另一个通道用于建立消息接收队列。例如，可以如图4所示。图4中的数据中心401和数据中心402之间的消息发送使用从数据中心401到数据中心402的单向队列进行发送，消息接收使用数据中心402到数据中心401的单向队列进行接收。

本发明的实施数据方式中，数据中心中的同步服务器用于对同步数据进行处理，同步服务器会将不同交易的同步数据组织成不同的消息队列进行发送和接收，例如，图5所示。发送方501(例如，可以使主备数据中心的任一数据中心)逐条生成消息M1、M2、M3等，将这些消息分别发送至消息发送端5011，消息发送端将这些消息以消息队列的形式通过消息通道503发送至消息接收端5021，消息接收端5021逐条接收消息接收端5021的消息M1、M2、M3等。

通过建立发送和接收两个单向队列来确证消息在传输过程中的一致性和可靠性。这样在某一个交易的同步数据队列出现堵塞现象时，不会影响到其他队列的消息传输。

在待同步数据为定期同步数据的情况下，执行步骤S103，定期向第二数据中心发起批量数据同步请求以对第二数据中心的本地数据库进行同步，例如，每日日终时进行数据同步。在一种具体的实施方式中，定期的数据同步可以通过如图7所示的过程。渠道前置系统703主用数据中心701发起管理类的交易请求，主用数据中心701中的业务服务器的应用集群7011在完成相应交易处理后，只将交易数据同步到管理数据库7012。只有在日终的时候，备用数据中心702的业务服务器的应用集群7021会向主用数据中心701的管理数据库7012请求批量数据同步，管理数据库7012会将本日的管理类交易的数据同步到备用数据中心702的管理数据库7022，完成主用数据中心701和备用数据中心702之间定期同步数据的数据同步。

本发明实施方式根据待同步数据的不同实时性要求，将数据分别进行实时同步和定期同步，在保证交易业务连续性的前提下，有效缓解了数据中心之间数据同步的处理压力；而且对于实时同步数据处理，提供了两种实时同步方式，可以根据数据中心之间的耦合程度选择不同的实时同步方案。

上面结合具体实施例描述了本发明的数据同步方法的流程，下面将结合具体实施例描述应用上述数据同步方法的数据同步系统。

参见图8，图8是根据本发明一种实施方式的数据同步系统的结构示意图，该系统800可包括：

判断模块801，用于判断待同步数据的类别；

请求处理模块802，设置于第一数据中心，用于：

在待同步数据为实时同步数据时，在完成对所述待同步数据的本地数据库同步操作之后就向第二数据中心发起同步请求，并接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功；以及

在所述待同步数据为定期同步数据时，定期向所述第二数据中心发起批量数据同步请求以对所述第二数据中心的本地数据库进行同步；

同步模块803，设置于所述第二数据中心，用于接收所述请求处理模块发送的同步请求，并向所述请求处理模块返回请求反馈。

本发明实施方式的数据同步系统800可应用于两个数据中心之间的数据同步，这两个数据中心为主备关系，主备数据中心都同时承担业务处理，主备两个数据中心可互为备份。下面主要以银行数据中心为例说明本发明的数据同步方法，需要说明的是，本发明的数据同步系统不仅仅适用于银行等金融行业的数据同步，还可适用于对数据实时性要求不同的其他领域的数据同步。

本发明实施方式中涉及的数据中心可以是如图2所示的逻辑架构。数据中心的各种交易数据根据对实时性的要求不同可分为实时同步数据(例如，交易类的数据)和定期同步数据(例如，管理类的数据)。交易类的数据直接影响联机交易是否成功，必须实时同步，包括现金尾箱信息，凭证尾箱信息和系统实时运行参数等。管理类的数据并不直接影响联机交易，包括机构信息、柜员信息、ATM信息和管理控制类等信息。这类数据对实时性要求较低，只需要进行定期同步(例如，日终同步)。

判断模块801可设置在数据中心的应用服务器的集群，在应用集群完成相应的业务处理之后，完成本地数据库的更新操作之后，判断待同步的数据的类别，在判断类别之后，由请求处理模块802进行相应的实时同步处理和定期同步处理。

请求处理模块802可设置在任一数据中心的应用服务器集群上。为了描述方便，设定请求处理模块802设置在第一数据中心，在第一数据中心中的应用集群完成渠道前置系统发送的交易，将交易数据更新到本地数据库之后，向第二数据中心发起针对该待同步数据的数据同步请求，并接收第二数据中心返回的对于该数据同步请求的请求反馈，然后根据该请求反馈的结果(例如，成功或失败)确定待同步数据是否同步成功。

依据请求反馈的具体形式可以将同步分为严格实时同步和准实时同步两种方式。请求反馈可包括接收回执或者同步结果，其中，接收回执是第二数据中心的同步模块803(例如，可设置在数据中心的同步服务器上)在接收到同步请求之后，立即向第一数据中心的请求处理模块802返回的请求反馈，在返回请求反馈之前并未对该第二数据中心的本地数据库针对该同步请求的数据进行更新，可以称之为准实时同步；同步结果是第二数据中心的同步模块803在接收到同步请求之后，对该第二数据中心的本地数据库针对该同步请求的数据更新之后，向第一数据中心的请求处理模块802返回的请求反馈，可以称之为实时同步。也就是说，本发明的实时同步可分为实时同步和准实时同步两种。

在请求反馈为接收回执的情形下，请求处理模块802接收第二数据中心的同步模块803返回的接收回执，若该接收回执的结果为成功，则定该待同步数据同步成功，然后可通知渠道系统的前置设备(例如，ATM前置或柜面前置设备等)交易成功；若接收回执的结果为失败，则将该待同步数据记录在异常交易表中，确定该同步数据同步失败，但通知渠道系统的前置设备交易成功。

在一些实施方式中，数据同步系统800还可包括异步重发模块804，如图9所示。异步重发模块804读取请求处理模块802记录在异常交易表中的待同步数据，向第二数据中心的同步模块803重新发起对于该待同步数据的数据同步请求，接收该第二数据中心的同步模块803返回的同步结果，根据该同步结果的结果确定异常交易表中的待同步数据是否同步成功，若同步结果的结果为成功，也就是说，第二数据中心的同步模块803已经将该待同步数据更新到其本地数据库(例如，联机数据库)，则将异常交易表中的待同步数据的记录删除。若同步结果的结果为失败，也就是说，第二数据中心的同步模块803本次还是没有将该待同步数据更新到其本地数据库，则继续向第二数据中心发起同步请求，多次重复发起同步请求，直至成功将待同步数据更新到第二数据中心的本地数据库，或者通过人工的方式将待同步数据写入数据库。

在请求反馈为同步结果的情况下，请求处理模块802接收第二数据中心的同步模块803返回的同步结果，若同步结果的结果为成功，也就是说，第二数据中心的同步模块802将待同步数据成功同步到其本地数据库，请求处理模块802确认第一数据中心的本地数据库针对该待同步数据的同步操作，确认待同步数据同步成功，并通知渠道系统的前置设备交易成功。若同步结果的结果为失败，也就是说，第二数据中心的同步模块802没有将待同步数据成功同步到其本地数据库，请求处理模块802将第一数据中心的本地数据库对于该待同步数据的同步操作回滚，确认待同步数据同步失败，并通知渠道系统的前置设备交易失败。

本发明的请求处理模块802(设置于第一数据中心的应用集群上)和同步模块803(设置于第二数据中心的同步服务器上)之间的数据通信，可以采用IBMWebsphereMQ消息中间件进行。消息传输可采用MQ的双通道模式实现，一个通道用于建立消息发送队列，另一个通道用于建立消息接收队列。同步模块803接收请求处理模块802的同步请求可以通过第一数据中心到第二数据中心的单向队列进行接收，同步模块803向请求处理模块802返回请求反馈可以通过第二数据中心到第一数据中心的单向队列进行发送。

在一种具体的实施例中，设置于数据中心的应用集群上的请求处理模块执行以下操作：

(1)纪录本地交易流水表，将交易流水表中的数据记为未同步；

(2)就交易流水表中未同步的交易数据向另一数据中心的同步模块发起同步请求；

(3)接收同步模块通过IBMMQ返回的接收回执；

(4)若接收回执的结果为成功，则将交易流水表中该交易数据标记为已同步，若接收回执的结果为失败，则将改交易数据的失败信息记录到异常交易表。

设置于另一数据中心的同步模块可执行以下操作：

(1)通过IBMMQ读取请求处理模块的同步请求消息；

(2)对本地数据库进行同步操作，若对本地数据库的同步操作失败，则继续发起同步操作，并记录重发的次数；

(3)若重发次数超过预定次数，则将该同步数据记录到流水表中，以便通过人工方式将数据同步到数据库。

设置于数据中心的轮询模块可执行下述操作：

(1)查询指定时间内本地交易流水表中标记为未同步的交易数据；

(2)将这些未同步的交易数据记入异常交易表。

设置于数据中心的异步重发模块可执行下述操作：

(1)从异常交易表中读取未同步的交易数据；

(2)向同步模块发起同步请求；

(3)接收同步模块返回的同步结果，

(4)在同步结果为成功的情况下，删除异常交易表中的未同步数据。

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

本发明说明书中使用的术语和措辞仅仅为了举例说明，并不意味构成限定。本领域技术人员应当理解，在不脱离所公开的实施方式的基本原理的前提下，对上述实施方式中的各细节可进行各种变化。因此，本发明的范围只由权利要求确定，在权利要求中，除非另有说明，所有的术语应按最宽泛合理的意思进行理解。

Claims

1.一种数据同步方法，其特征在于，所述方法包括：

判断待同步数据的类别，

若所述待同步数据为实时同步数据，则在所述第一数据中心完成对所述待同步数据的本地数据库同步操作之后就向第二数据中心发起同步请求，并接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功；

若所述待同步数据为定期同步数据，则定期向所述第二数据中心发起批量数据同步请求以对所述第二数据中心的本地数据库进行同步。

2.根据权利要求1所述的方法，其特征在于，所述请求反馈包括接收回执或者同步结果，其中，

所述接收回执是所述第二数据中心在接收到所述同步请求之后，未对本地数据库更新之前，向所述第一数据中心返回的请求反馈，

所述同步结果是所述第二数据中心在接收到所述同步请求之后，已对本地数据库更新之后，向所述第一数据中心返回的请求反馈。

3.根据权利要求2所述的方法，其特征在于，所述接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功包括：

接收所述第二数据中心返回的接收回执，

若所述接收回执的结果为成功，则确定所述待同步数据同步成功，

若所述接收回执的结果为失败，则将所述待同步数据记录在异常交易表，确定所述待同步数据同步失败。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

读取所述异常交易表中的待同步数据，向所述第二数据中心重新发起同步请求，接收所述第二数据中心返回的同步结果，根据所述同步结果的结果确定所述异常交易表中的待同步数据是否同步成功，

若所述同步结果的结果为成功，则将所述异常交易表中的待同步数据的记录删除，

若所述同步结果的结果为失败，则继续向所述第二数据中心重新发起同步请求。

5.根据权利要求2所述的方法，其特征在于，所述接收所述第二数据中心返回的请求反馈，然后根据所述请求反馈的结果确定所述待同步数据是否同步成功包括：

接收所述第二数据中心返回的同步结果，

若所述同步结果的结果为成功，则确认所述第一数据中心的本地数据库的同步操作，确定所述待同步数据同步成功，

若所述同步结果的结果为失败，则将所述第一数据中心的本地数据库的同步操作回滚，确定所述待同步数据同步失败。

6.根据权利要求1所述的方法，其特征在于，所述向第二数据中心发起同步请求是通过单向队列进行发送。

7.根据权利要求1所述的方法，其特征在于，所述接收所述第二数据中心返回的请求反馈是通过单向队列进行接收。

8.一种数据同步系统，其特征在于，所述系统包括：

判断模块，用于判断待同步数据的类别；

请求处理模块，设置于第一数据中心，用于：

同步模块，设置于所述第二数据中心，用于接收所述请求处理模块发送的同步请求，并向所述请求处理模块返回请求反馈。

9.根据权利要求8所述的系统，其特征在于，所述同步模块，还用于在接收到所述同步请求之后，向所述请求处理模块返回接收回执作为请求反馈，然后对所述同步请求的待同步数据进行本地数据库同步操作。

10.根据权利要求8所述的系统，其特征在于，所述同步模块，还用于在接收到所述同步请求之后，对所述同步请求的待同步数据进行本地数据库同步操作，然后向所述请求处理模块返回所述本地数据库同步操作的同步结果作为请求反馈。

11.根据权利要求9所述的系统，其特征在于，所述请求处理模块，还用于：在所述接收回执的结果为成功时确定所述待同步数据同步成功，在所述接收回执的结果为失败时将所述待同步数据记录在异常交易表，确定所述待同步数据同步失败。

12.根据权利要求11所述的系统，其特征在于，所述系统还包括：

异常重发模块，用于：读取所述异常交易表中的待同步数据，向所述同步模块重新发起同步请求，接收所述同步模块返回的同步结果，根据所述同步结果的结果确定所述异常交易表中的待同步数据是否同步成功，若所述同步结果的结果为成功，则将所述异常交易表中的待同步数据的记录删除，若所述同步结果的结果为失败，则继续向所述第二数据中心重新发起同步请求。

13.根据权利要求10所述的系统，其特征在于，所述请求处理模块，还用于：在所述同步结果的结果为成功时确认所述第一数据中心的本地数据库的同步操作，确定所述待同步数据同步成功，在所述同步结果的结果为失败时将所述第一数据中心的本地数据库的同步操作回滚，确定所述待同步数据同步失败。

14.根据权利要求8所述的系统，其特征在于，所述同步模块是通过单向队列接收所述同步请求。

15.根据权利要求8所述的系统，其特征在于，所述同步模块是通过单向队列发送所述请求反馈。