CN111930529A - 基于消息队列及微服务的数据同步方法、模块及系统 - Google Patents

Abstract

本申请公开了一种基于消息队列及微服务的数据同步方案，包括：注册并加载数据同步服务以创建数据同步模块；创建消息队列服务的长连接，创建微服务的长连接；接收或收集待同步数据；以消息队列协议方式将所接收到的待同步数据以消息内容形式发送给数据同步处理服务模块；通过在监测期间捕捉发送异常信息来判断在利用消息队列协议进行数据同步期间是否发生了数据同步失败的情况：如果确定发生了数据同步失败的情况，则启动数据同步补偿机制以微服务的方式再次将所述消息内容发送给所述数据同步处理服务模块；以及所述数据同步处理服务模块接收从所述数据同步模块发送的消息内容并对所述消息内容进行数据同步处理。

Description

基于消息队列及微服务的数据同步方法、模块及系统

技术领域

本申请涉及数据同步和转换处理领域，更具体而言，涉及一种基于分布式消息队列及微服务的数据映射同步方法、模块及系统。

背景技术

数据同步技术是指在不同存储设备、或终端与终端，终端与服务器之间的数据备份与信息共享操作，使得存储在各个数据源处的数据保持完整性和统一性。

目前数据同步处理领域常见的主流同步方式包括下述几种：

1）任务调度数据同步方式，该方式通过由任务调度管理系统加载注册的定时程序基于定时器配置的时间点来定时执行数据同步操作。这种基于任务调度的定时数据同步的方式对于一些实时性要求较高的应用场景，例如支付场景，会存在处理上的时间差异，无法实现实时的数据同步处理。因此，存在数据同步实时性问题。

2）运行脚本任务方式，该方式以数据库运行脚本形式，或服务器Shell脚本的形式配置系统定时任务以执行完成数据同步操作。这种数据库运行脚本形式的数据同步方式本质上还是基于预定的时间点来定时执行数据同步操作，因此，它还是无法解决数据同步实时性问题。

3）数据库触发器同步方式，即利用数据库自带的触发器在数据写入或更新时执行数据同步处理和转换。这种触发器数据同步方式是基于数据表记录写入或更新操作来触发完成数据同步转换，因此，其能够实现实时的数据同步。但同时，由于当读写操作较多时，每次读写都会触发相应的数据同步操作，因此，对数据库本身的性能消耗较大，同时影响原系统逻辑的处理效率。

4）单纯依赖消息队列的同步方式，该方式基于消息队列的生产者和消费者模式，在系统做出数据操作的同时，发送相关的消息至消息队列中间件，再转由同步服务处理。所述消息队列的同步方式主要具有异步、低耦合、消峰填谷等优点，但是其也存在诸如可用性、复杂性、一致性等问题。

另外，除了上述现有的几种主流数据同步技术自身存在的各种问题之外，现有的数据同步技术还存在诸如下述的共同技术问题：

跨数据源或数据库实例同步问题，即现有同步技术无法实现多目标数据源的同步方式； 同步规则可配置性问题，即在不同类型的数据库之间进行同步时，可能涉及到数据的转换，而数据转换过程中所使用的基本参数、转换规则、映射关系、目标数据源配置等随着所涉及的数据库的类型不同而不同，因此，这就导致同步规则的可配置性极差，不具有通用性；数据同步过程的可靠性问题，当数据同步由于例如软件、硬件或网络故障而失败时，上述这些现有的数据同步技术都缺乏有效的补偿及预警机制，这导致数据同步失败，进而影响数据的可靠性。

因此，存在一种需求，希望能够提供一种能够克服上述现有数据同步方式中的各种问题，同时又简单高效的数据同步方案。

发明内容

为了解决上述问题，本申请提供了一种基于分布式消息队列及微服务的数据映射同步方法、模块及系统。

根据本申请的第一方面，提供了一种基于消息队列及微服务的数据同步方法，包括：注册并加载数据同步服务以创建数据同步模块；以消息队列的生产者身份以工厂模式创建消息队列服务的长连接，并且以以微服务消费者身份以微服务方式创建微服务的长连接；接收或收集待同步数据；以消息队列协议方式将所接收到的待同步数据以消息内容形式发送给数据同步处理服务模块；通过在监测期间捕捉发送异常信息来判断在利用消息队列协议进行数据同步期间是否发生了数据同步失败的情况：如果确定发生了数据同步失败的情况，则启动数据同步补偿机制以微服务的方式再次将所述消息内容发送给所述数据同步处理服务模块；以及所述数据同步处理服务模块接收从所述数据同步模块发送的消息内容并对所述消息内容进行数据同步处理。

根据本申请的第二方面，提供了一种基于消息队列及微服务的数据同步模块，包括：注册和加载模块，被配置为注册并加载数据同步服务；消息队列生产者长连接模块，被配置为以消息队列的生产者身份以工厂模式创建消息队列服务的长连接；微服务消费者长连接模块，被配置为以微服务消费者身份以微服务方式创建微服务的长连接；接收模块，被配置为接收或收集待同步数据；消息队列发送模块，被配置为以消息队列协议方式将所接收到的待同步数据以消息内容形式发送给数据同步处理服务模块；异常监测和判断模块，被配置为通过在监测期间捕获发送异常信息来判断在利用消息队列协议进行数据同步期间是否发生了数据同步失败的情况；以及补偿机制模块，被配置为如果所述异常监测和判断模块确定发生了数据同步失败，则以微服务的方式再次将所述消息内容发送给所述数据同步处理服务模块。

根据本申请的第三方面，提供了一种基于消息队列及微服务的数据同步系统，包括：如第二方面所述的数据同步模块，以及数据同步处理服务模块，被配置为接收从所述数据同步模块发送的消息内容并对所述消息内容进行数据同步处理。

提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

为了描述可获得本申请的上述和其它优点和特征的方式，将通过参考附图中示出的本申请的具体实施例来呈现以上简要描述的本申请的更具体描述。可以理解，这些附图只描绘了本申请的各典型实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释本申请，在附图中：

图1示出了一个传统的数据同步方案的示例性运行场景。

图2示出了根据本申请的一个实施例的基于分布式消息队列及微服务的数据同步方法的示意性流程图。

图3示出了根据本申请的一个实施例的数据同步模块的系统框图。

图4示出了根据本申请的一个实施例的数据同步处理服务模块的系统框图。

具体实施方式

随着电子商务平台的蓬勃兴起，人们在日常生活中越来越依赖于线上交易。而要给用户提供良好的线上购物体验，线上交易的便利性、可靠性和实时性则是至关重要的因素。特别是在诸如各种网上促销活动期间，可能每秒都存在数万、数十万乃至数百万量级的线上交易，此时，对如何能够将线上交易数据实时可靠地同步到涉及该交易的各数据方（例如发卡银行、支付机构、交易平台、用户各方之间的数据同步）提出了极高的要求。根据线上交易业务的需要，可以将线上交易场景中的数据同步要求归纳为三个基本要求：

1）尽可能接近实时的同步；

2）同步的数据在各数据库之间必须保持数据的一致性；

3）不能影响正常的线上交易。

首先，为了实现尽可能接近实时数据同步，传统的基于定时的任务调度或运行脚本模式的数据同步方式肯定不适用于所述线上交易场景。而数据库触发器同步方式面对短时巨量交易场景，显然也会因为同时触发数以万计的交易数据同步操作而极大拖累整个数据库的处理速度和效率，甚至导致数据库彻底瘫痪。同时，为了不影响正常的线上交易，必须考虑消峰填谷的问题，即将短时发生的大量的交易数据同步操作尽可能推迟到系统后续空闲时再执行以保证平台的正常线上交易。因此，就不能采用真正的实时同步，而是可以利用异步处理来避免交易瓶颈的出现。所以，综合考虑之下，针对线上交易的这些特点，技术人员一般采用消息队列的同步方式来处理交易数据的同步。

但如前所述，现有的消息队列的同步方式也存在自身的各种缺陷，其中，最主要的问题在于数据的一致性难以保持。尽管已经针对消息队列给出了一些改进以实现数据的一致性，例如消息持久化、ACK确认机制、设置集群镜像模式等等机制已经被引入消息队列的同步流程中。但在复杂的系统环境及网络环境下，如果例如消息队列本身，或者平台软件、硬件或网络等方面出现了问题导致基于消息队列的数据同步失败，则即使是上述几种机制也无法保证消息完全不丢失。因此，数据同步要想保持一致必须有补偿机制，即提供另一种不同的数据同步方式来补偿消息队列的同步方式无法完成的数据同步。这样，就从根本上克服了单纯采用消息队列的同步方式所存在的数据一致性缺陷。

为此，本申请提供了一种数据同步通用处理方式，以解决数据同步映射关系配置的灵活性，以及数据同步下数据的实时性、可靠性等问题。具体而言，在本申请中，提供了一种基于消息队列和微服务的、跨数据库种类或实例的实时（或接近实时）数据同步和转换方法。

在开始描述本申请的具体方案之前，先就本申请所涉及的“消息队列”和“微服务”进行下简单的介绍以方便技术人员的理解。

消息队列是一种存放消息的容器，当系统发生数据操作时（例如增加、修改、删除、移动数据库中的数据时），生产者可以往消息队列中写入相应的消息，而当消费者需要使用消息的时候则可以从消息队列中取出该消息供消费使用和处理。消息队列（也被称为“消息队列中间件”）是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。目前使用较多的消息队列类型有RabbitMQ，Kafka，RocketMQ等。在本申请中以RabbitMQ消息队列为例来加以说明。但应该理解，其他消息队列类型，例如Kafka，RocketMQ等等也同样适用于本申请的方案。

微服务是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTfulAPI) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境类生产环境。而采用微服务作为消息队列的数据同步失败后的补偿方式，是因为可以利用其本身作为一个同步请求的补偿机制，能够满足消息队列服务故障后再次同步的实时性要求，并能实时地获取数据同步响应结果，响应失败可做其他逻辑处理，如告警日志记录。而其他方式补偿，例如前述的基于定时的任务调度、运行脚本模式的同步方式或DB日志方式，这些机制都是先对异常记录做存储，后续系统才根据定时任务再在指定时间进行处理，因此，它们无法保证在线交易数据同步的实时性。本申请中使用分布式应用程序协调服务（Zookeeper）作为服务发现与注册中心。但应该理解，其他微服务类型也同样适用于本申请的方案。

下面结合附图1来说明一个传统的数据同步方案的示例性运行场景。首先，所述环境包括用户110，他可以通过例如手机、数字助理、平板电脑、膝上计算机、个人PC之类的可联网的计算设备经由诸如蜂窝网络、WIFI、广域网等访问服务器120（例如交易平台）以执行希望的任务，例如购买该交易平台提供的各种商品。当用户110选择完商品并进行在线支付时，服务器120就需要与多个数据库进行数据同步，以保持交易的完整性。例如服务器120首先需要与提供支付通道的支付机构（例如支付宝、微信、银联在线等）的数据库130（1）发送交易消息以进行数据同步，然后，所述服务器120（或在一些实施例中可以由收到交易消息的支付机构）向用户110用于支付的银行卡的发卡机构（例如银行、各种消费卡）的数据库130（2）发送交易消息以进行数据同步。而且，服务器120还要将交易消息发送给用户110的计算设备以告知用户交易的进行状态。在一些实施例中，所述服务器120还需要进一步向其他数据库发送交易消息以进行数据同步，例如交易平台的后台数据库130（3）以更新用户账户的交易信息和状态。为此，在服务器120中可以配置有数据同步模块和数据同步处理服务模块以实现所述数据同步。当然如果需要可以通过程序包（例如插件）的加载和注册形式，将这两个模块配置到包含诸如各数据库130的各应用系统中以实现数据同步。关于这两个模块的详细说明，请参见附图3和4及其相关内容。出于线上交易的特殊性，在用户110、服务器120和各个数据库130之间的数据同步必须满足实时性（或尽可能接近实时）、一致性和可靠性。为了能够满足线上交易的上述要求，本申请一种基于分布式消息队列及微服务的数据同步方法、模块及系统。

在图2中示出了根据本申请的一个实施例的基于分布式消息队列及微服务的数据同步方法的示意性流程图。首先，在步骤210中，通过在应用系统中引入程序包来注册并加载数据同步服务以创建相应的数据同步模块。可以利用例如插件的方式注册并加载数据同步模块，所述插件可以同时在多个应用系统中分别注册，或在同一应用集群环境节点服务下进行注册以实现多来源采集和接收数据。换句话说，系统可统一管理数据源访问参数及权限，依据配置中的系统标识和目标数据库标识，将插件注册并加载到不同的数据源。这样，通过插件的注册和加载可以构建不同的数据源的访问实例以为不同的数据源创建相应的数据同步模块。如此一来，就可提供一种跨数据库类型或实例的数据同步方法，使得所述数据同步方案具有良好的通用性和兼容性。同时，所述程序包（插件）进一步包括了与数据同步补偿机制相关的代码，因此，所构建的数据同步模块也集成了补偿机制相关处理逻辑。

在步骤220，所述数据同步模块以消息队列工作队列模式中的生产者身份，以工厂模式创建消息队列服务的长连接，同时也以长连接的方式注册为微服务架构下的服务消费者，即以微服务消费者身份创建微服务的长连接，并注入和实例化远程服务接口对象，所述远程服务接口被用于发送待同步的数据（例如消息内容）。

所述步骤210和220也可以被合并在一起并称为初始化步骤，通过执行所述初始化步骤，所述数据同步模块已经做好了进行数据同步处理的准备。

然后，在步骤230处，所述数据同步模块接收或收集待同步数据。如前所述，所述待同步的数据可以是来自用户110、服务器120或各个数据库130的交易数据。这些数据需要被实时（或尽可能接近实时）、一致、可靠地同步到其他数据源中。 具体而言，数据同步模块可利用例如持久化框架拦截器中的拦截处理方式，或业务层直接处理发送方式来达到接收或收集待同步数据的目的。

接着，在步骤240处，所述数据同步模块作为消息队列中的生产者以消息队列协议方式发送所接收到的待同步的数据。在一些实施例中，在发送所接收到的待同步数据之前，可以对所述待同步数据进行预处理。例如数据同步模块可以将待同步数据转换为Json格式的报文形式的消息内容，并发送该消息内容至消息队列中间件。随后，再由该消息队列中间件负责将消息内容分发至注册为例如RabbitMQ消息队列消费者的数据同步处理服务模块的数据接收组件。

所述预处理还可以包括：标记出实体对象类型和发送系统的ID。例如，对于终端支付交易记录对象，可将其对象类型标记为“TermnalsOrderInfo”， 并标记其来源系统的ID为“tpay”，随后以公共参数的方式将它们标记于数据报文中:

“CommonParam” : {

“EntityType” : “TermnalsOrderInfo”,

“PlatId” : ”tpay”

}

届时在后续的数据同步处理服务中将根据此组合标记获取相关映射转换规则配置。

在少数情况下，如果要进行数据同步的两个数据库的类型和结构完全相同，由此来自一个数据库的待同步数据可以直接被应用于另一个数据库中，则上述预处理是非必要的。但在大多数情况下，示例性运行环境中的各数据库不太可能完全一致，彼此之间的数据缺乏兼容性，无法直接使用。因此，所述预处理步骤和后续的映射转换规则配置还是有必要进行的。

如前所述，与传统的单一数据同步机制不同的是，本申请的数据同步机制在整体上由两部分组成：基于消息队列中间件（RabbitMQ消息代理软件）的数据同步机制和基于微服务总线（Zookeeper注册中心软件）的数据同步机制。也就是说，数据同步模块中的消息队列协议发送方式和微服务消费者发送方式互为辅助及补偿。至于是以消息队列协议同步方式为主还是以微服务同步方式为主，则可视具体业务场景及服务器构成以补偿策略形式来决定。一般，在默认情况下，优先以消息队列协议方式发送，因为消息队列协议的特点更加符合线上交易的要求。

在此方式下，在步骤250处，数据同步模块通过捕获发送异常信息来监测并判断在利用消息队列协议进行数据同步期间（即在经由消息队列中间件将消息内容从数据同步模块发送给数据同步服务模块时）是否发生了数据同步失败的情况，例如因服务器或数据库的突发故障（例如磁盘故障或电源故障）、网络连通性或超时问题、或消息队列中间件的服务故障而导致的发送失败。

如果在步骤250确定利用消息队列中间件将消息内容同步到数据同步服务模块的数据同步操作失败，则所述流程转至步骤260以启用数据同步补偿机制。

具体而言，在步骤260处，数据同步模块的补偿机制相关处理逻辑被激活。根据所述逻辑，数据同步模块将自动按所设置的补偿策略（在该补偿策略中，正常的发送策略是默认以消息队列方式发送数据，但如果消息队列方式发送错误或出现故障（系统捕获到异常），则转入补偿机制（即微服务方式）），再次调用在步骤220的所述数据同步模块的初始化同步期间注册并实例化的远程服务接口，使得该远程服务接口以微服务总线的方式再次发送所述消息内容。

具体而言，首先，原来被转换为Json格式的报文形式（例如Json格式的对象字符串）的消息内容被进一步转换为供微服务网络传输的序列化对象，由于两者是同源的，仅仅是一个数据对象的不同表现形式，因此，所述转换快捷且耗费很少资源。

随后，在微服务数据同步机制下，所述数据同步模块作为微服务的消费者以微服务形式向作为微服务的提供者的数据同步处理服务模块发送补偿请求，所述补偿请求和正常模式下消息队列请求的信息一样，也是数据同步的相关信息（即被转换为供微服务网络传输的序列化对象的消息内容），只是发送途径和方式不同。之后，流程进入到步骤270。

当然，技术人员可以根据实际场景对该补偿策略进行修改，例如默认以微服务方式发送，仅当微服务方式发送发生错误或故障时再转入补偿机制（消息队列方式）。

这样，通过使得数据同步模块中的消息队列协议发送方式（步骤240）和微服务消费者发送方式（步骤260）互为补偿，确保了要同步的数据不会被遗漏，并同时保证了数据信息的可靠性。

另一方面，如果在步骤250确定在利用消息队列中间件将消息内容同步到数据同步处理服务模块时并没有发生同步失败的情况，则所述流程直接前进至步骤270。

在步骤270处，数据同步处理服务模块接收从数据同步模块发送的消息内容并执行数据同步处理。该数据同步处理服务模块在接收方式上存在两个身份，即1）消息队列（例如RabbitMQ）工作队列模式中的消费者身份；和2）基于微服务架构（例如Zookeeper注册中心）下的服务提供者。当在步骤250中确定以消息队列协议发送方式发送消息内容并没有发生同步失败的情况（即发送成功），则所述数据同步处理服务模块可作为消息队列的消费者来接收消息内容并进行后续处理。另一方面，所述数据同步处理服务模块还可作为微服务提供者，提供补偿处理逻辑。当在步骤250中确定同步失败时，由安置在各个业务系统中的数据同步模块（它会注册为微服务的服务消费者）根据所述补偿处理逻辑以微服务形式发送补偿请求，所述数据同步处理服务模块则以微服务提供者的身份接收并处理所述补偿请求中的消息内容。

所述数据同步处理服务模块包括了数据映射规则配置组件、数据接收组件、数据解析转换处理组件以及监控处理组件，并由这些组件对消息内容执行相应的例如接收、解析、转换、执行、监控同步等处理操作以完成数据的同步。该数据同步处理服务模块还可横向扩展部署，达到降低数据同步处理压力，提升处理效率目的。下面针对每个组件介绍下其对应的数据处理流程。

1. 数据规则映射配置组件：该组件在数据同步处理服务模块初始化阶段以系统、源数据、目标数据源多个维度组合的形式构建规则并以例如Json格式数据结构配置相关配置文件。文件配置内容以系统启动加载及定时重载的方式缓存于各数据同步处理服务的应用实例中。定义方式如下：

其中数据映射关系中“目标数据字段名或转换方法名”可通过两种方式实现对应转换，若源和目标数据表字段类型一致，则可直接配置目标数据表字段名称；若目标数据表字段需多字段值组合转换，或逻辑转换，或运算转换的，可配置转换方法，例如程序反射机制实现转换。通过利用数据规则映射配置组件，本申请针对数据转换过程中的基本参数、转换规则、映射关系、目标数据源配置提供了一种通用的转换规则配置方式。技术人员可通过模板文件方式配置数据同步规则，进而提升了同步规则可配置性。

2. 数据接收组件，该组件在数据同步处理服务启动时初始化相关连接及接口服务，以消息队列（例如RabbitMQ）消费者的身份建立连接，同时向微服务（例如Zookeeper注册中心）注册同步服务接口提供者。数据接收组件以此两种方式（消息队列方式或微服务方式）接收数据消息内容，收到待同步数据后进行初步消息报文验证及过滤，报文验证通过后交由数据解析转换处理组件执行下一步骤。

3 数据解析转换处理组件：该组件接收到由数据接收组件接收的消息内容后，首先从中解析出公共参数，包含例如来源系统ID + 转换实体对象类型。通过将该组合标记发送至数据规则映射配置组件进行匹配并获取对应规则。接着，解析规则中的数据映射关系，导向至规则对应的处理模块完成将对应目标数据源的数据对象转换成数据库SQL语句。下一步通过规则中的目标数据源信息，从数据源连接池中获取并建立连接，进而通过所述数据同步处理服务模块作为桥梁来执行各数据源（库）之间的数据同步。通过以系统ID+数据对象作为数据源标识，配置相关访问参数信息，并以装饰器设计模式创建多数据源实例，这样，在获取目标数据源时，就能按标识进行区分以实现动态数据源切换。

4 监控处理组件：在数据同步处理服务初始化时就启动监控告警定时扫描任务。若在所述数据同步处理服务模块的上述数据同步处理过程中出现同步失败情况（例如上述数据格式校验不通过等导致的同步失败），则由该组件负责捕获失败或服务异常信息，以日志文件及数据表的形式记录该信息。并且，如需要还可以将所述异常数据信息存储到相应的数据库中。另外，若出现同步失败则可以邮件或短信形式发送或播报告警。利用该监控处理组件，可以为在数据同步处理服务阶段出现的同步失败提供预警机制，以告知技术人员与异常相关的信息。

这样，从整体上来说，由跨多来源的数据同步模块负责标记、发送、监控待同步的消息内容并在需要时（以消息队列协议形式发送的同步失败时）执行补偿处理（以微服务形式发送），而数据同步处理服务模块则负责接收、解析、转换、执行、监控同步等操作。

在描述完本申请的基于分布式消息队列及微服务的数据同步方法的示意性流程之后，再根据图3和4来分别对根据本申请的一个实施例的数据同步模块和根据本申请的一个实施例的数据同步处理服务模块的系统结构进行说明。

如图3所示，所述数据同步模块300主要分为两个部分，即初始化部分和数据同步部分。

在初始化部分中，主要包括注册和加载模块310、消息队列生产者长连接模块320以及微服务消费者长连接模块330。

注册和加载模块310被配置为通过在应用系统中引入程序包（例如插件）来注册并加载数据同步服务以创建相应的数据同步模块。系统可统一管理数据源访问参数及权限，依据配置中的系统标识和目标数据库标识，将插件注册并加载到不同的数据源。这样，就可提供一种跨数据库类型或实例的数据同步方案。同时，所述程序包（插件）进一步包括了与数据同步补偿机制相关的代码，因此，所构建的数据同步模块也集成了补偿机制相关处理逻辑。

消息队列生产者长连接模块320被配置为使得所述数据同步模块以消息队列工作队列模式中的生产者身份，以工厂模式创建消息队列服务的长连接。

微服务消费者长连接模块330被配置为使得所述数据同步模块以微服务架构下的服务消费者身份创建微服务的长连接。

在经过所述注册和加载、创建消息队列生产者长连接和创建微服务消费者长连接这些步骤之后，所述数据同步模块完成了数据同步的初始化过程。

而在数据同步部分中，则包括了接收模块340、消息队列发送模块350、异常监测和判断模块360以及补偿机制模块370。

接收模块340被配置为收或收集待同步数据。

消息队列发送模块350被配置为以消息队列协议方式发送所接收到的待同步的数据。具体而言，所述待同步的数据可以被预处理，例如被转换为Json格式的报文形式的消息内容，标记出实体对象类型和发送系统的ID并将组合标记加入到数据报文中。这样，在后续的数据同步处理服务中可以根据该标记组合获取匹配的相关映射转换规则配置。所述消息内容被发送至消息队列中间件。随后，再由该消息队列中间件负责将消息内容分发至例如注册为RabbitMQ消息队列消费者的数据同步处理服务模块的接收组件。

异常监测和判断模块360被配置为通过在监测期间捕获发送异常信息来判断在利用消息队列协议进行数据同步期间是否发生了数据同步失败的情况。

补偿机制模块370被配置为如果发生了数据同步失败， 则激活补偿机制相关处理逻辑，根据所述补偿机制处理逻辑，所述数据同步模块以微服务总线的方式再次发送所述消息内容给数据同步处理服务模块的接收组件。在一些实施例中，所述补偿机制模块被进一步配置为在以微服务总线的方式再次发送所述消息内容之前，将原来被转换为Json格式的报文形式的所述消息内容转换为供微服务网络传输的序列化对象。

至此，利用这些组件，所述数据同步模块300实现了标记、发送、监控待同步的消息内容并在需要时（以消息队列协议形式发送的同步失败时）执行补偿处理（以微服务形式发送）的功能。

图4示出了根据本申请的一个实施例的数据同步处理服务模块的系统结构。如图所述，所述数据同步处理服务模块400包括：数据映射规则配置组件410、数据接收组件420、数据解析转换处理组件430以及监控处理组件440。

数据映射规则配置组件410被配置为在数据同步处理服务模块初始化阶段以系统、源数据、目标数据源多个维度组合的形式构建规则并以例如Json格式数据结构配置相关配置文件，并且在数据解析转换处理组件430发送匹配请求时，检索与组合标记相关联的规则。

数据接收组件420被配置为在数据同步处理服务启动时初始化相关连接及接口服务。所述初始化包括以消息队列（例如RabbitMQ）消费者的身份建立连接，同时向微服务（例如Zookeeper注册中心）注册同步服务接口提供者。并且，所述数据接收组件420还被配置为在收到待同步数据后进行初步消息报文验证及过滤，报文验证通过后交由数据解析转换处理组件执行下一处理。

数据解析转换处理组件430被配置为从所接收的消息内容中解析出公共数据参数，例如来源系统ID + 转换实体对象类型，通过将该组合标记发送至数据规则映射配置组件410进行匹配以获取对应的规则，解析规则中的数据映射关系，导向至规则对应的处理模块完成将对应目标数据源的数据对象转换成数据库SQL语句，并且根据规则中的目标数据源信息，从数据源连接池中获取并建立连接以执行数据同步。

监控处理组件440被配置为在数据同步处理服务初始化时就启动监控告警定时扫描任务，监测在所述数据同步处理服务模块的上述组件的处理过程中出现的数据同步失败情况，如果出现同步失败，则可以执行下述一项或多项操作：以日志文件及数据表的形式记录该失败信息，将所述异常数据信息存储到相应的数据库和以邮件或短信等形式发送或播报告警。

应该理解，尽管公开了所述数据同步处理服务模块400包括上述这些组件，但所述说明仅仅是示例性的，并非是对本申请的方案进行限制，事实上，技术人员完全可以根据实际需求，通过增加或减少组件以实现数据同步。

通过上述这些组件，数据同步处理服务模块400可以实现同步数据的接收、解析、转换、执行、监控同步等操作，进而完成所述数据同步流程。

利用上述根据本申请方案所提供的基于分布式消息队列及微服务的数据同步方法和系统，可以实现如下所述的优点和改进：

1. 部分解决了数据同步实时性问题。对于一些实时性要求较高的应用场景，例如支付场景，通过采用消息队列协议发送待同步数据可以实时（或尽可能接近实时）地执行数据同步操作，减少了等待时间。

2. 提供了跨数据源或数据库实例同步。利用例如插件的程序包在多种数据源处的注册和加载机制，可以实现跨多目标数据源同步方式，使得所述数据同步方案具有良好的通用性、可移植性和兼容性。

3. 由于采用了异步的消息队列协议作为发送待同步数据的基本模式，从而减少了数据库的性能损耗。避免了在数据库读写操作较多时，由于巨量并发的数据同步操作导致的对数据库的性能大量消耗和对原系统逻辑的处理效率的较大影响。

4. 解决了同步规则可配置性问题。本申请针对数据转换过程中的基本参数、转换规则、映射关系、目标数据源配置，提供了通用的转换规则配置方式（即数据规则映射配置组件410）。技术人员可通过模板文件方式配置数据同步规则，大大简化了配置操作。

5. 解决了数据同步过程的可靠性问题。针对突发情况产生的消息队列软件服务故障以及目标数据库故障所导致的同步失败的问题，本申请提供了一种补偿及预警机制。通过在消息队列协议发送失败的情况下，另辟蹊径以微服务形式发送消息内容，使得所述消息内容可以通过另一途径被发送给数据同步处理服务，进而实现了可靠的数据同步。并利用监控处理组件实现了及时的预警。

上述内容对本公开特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。而且，相关领域的技术人员将领会，在不偏离如所附权利要求书所定义的本公开的精神和范围的情况下，所述实施例可以在形式和细节方面进行各种修改。因此，此处所公开的本公开的宽度和范围不应被上述所公开的示例性实施例所限制，而应当仅根据所附权利要求书及其等同替换来定义。

Claims (10)

1.一种基于消息队列及微服务的数据同步方法，包括：

注册并加载数据同步服务以创建数据同步模块；

以消息队列的生产者身份以工厂模式创建消息队列服务的长连接，并且以以微服务消费者身份以微服务方式创建微服务的长连接；

接收或收集待同步数据；

以消息队列协议方式将所接收到的待同步数据以消息内容形式发送给数据同步处理服务模块；

通过在监测期间捕捉发送异常信息来判断在利用消息队列协议进行数据同步期间是否发生了数据同步失败的情况：

如果确定发生了数据同步失败的情况，则启动数据同步补偿机制以微服务的方式再次将所述消息内容发送给所述数据同步处理服务模块；以及

所述数据同步处理服务模块接收从所述数据同步模块发送的消息内容并对所述消息内容进行数据同步处理。

2. 如权利要求1所述的数据同步方法，其特征在于，所述方法还包括：在以消息队列协议方式发送消息内容之前，可以对所述待同步数据进行预处理，其中所述预处理包括：

将所述待同步数据转换为Json格式的数据报文形式的消息内容；以及

从所述待同步数据中标记出实体对象类型和发送系统的ID，并以公共参数的方式将它们标记于数据报文中。

3.如权利要求2所述的数据同步方法，其特征在于，所述方法还包括在以微服务的方式再次发送所述消息内容之前，将原来被转换为Json格式的数据报文形式的所述消息内容转换为供微服务网络传输的序列化对象。

4.如权利要求2所述的数据同步方法，其特征在于，所述数据同步处理服务模块对所述消息内容进行下述数据同步处理：

数据规则映射配置，包括：在所述数据同步处理服务模块初始化阶段以系统、源数据、目标数据源多个维度组合的形式构建规则并配置相关配置文件；

数据接收，包括：以消息队列消费者的身份接收所述数据同步模块以所述消息队列协议方式发送的所述消息内容，或者以微服务提供者的身份接收所述数据同步模块以所述微服务方式发送的所述消息内容，并对接收到的所述消息内容进行初步消息报文验证及过滤；

数据解析转换，包括：从所接收的所述消息内容中解析出所述公共参数，所述公共参数包括：所述实体对象类型和所述发送系统的ID，根据所述公共参数从所述数据规则映射配置中获取匹配的规则，解析所述规则中的数据映射关系以导向至所述规则对应的处理模块来完成将对应目标数据源的数据对象转换成数据库SQL语句，通过所述规则中的目标数据源信息，从数据源连接池中获取并建立连接，进而执行数据同步；

监控处理，包括：在所述数据同步处理服务模块初始化时就启动监控告警定时扫描任务以监控在所述数据同步处理过程中出现同步失败情况，并在出现同步失败的情况下时，执行下述一项或多项操作：

以日志文件及数据表的形式记录同步失败信息；

将异常数据信息存储到相应的数据库中；以及

以邮件或短信形式发送或播报告警。

5.如权利要求1所述的数据同步方法，其特征在于，所述注册并加载数据同步服务包括：在应用系统中引入插件，所述插件可以同时在多个应用系统中分别注册，或在同一应用集群环境节点服务下进行注册以实现多来源采集和接收数据。

6.一种基于消息队列及微服务的数据同步模块，包括：

注册和加载模块，被配置为注册并加载数据同步服务；

消息队列生产者长连接模块，被配置为以消息队列的生产者身份以工厂模式创建消息队列服务的长连接；

微服务消费者长连接模块，被配置为以微服务消费者身份以微服务方式创建微服务的长连接；

接收模块，被配置为接收或收集待同步数据；

消息队列发送模块，被配置为以消息队列协议方式将所接收到的待同步数据以消息内容形式发送给数据同步处理服务模块

异常监测和判断模块，被配置为通过在监测期间捕获发送异常信息来判断在利用消息队列协议进行数据同步期间是否发生了数据同步失败的情况；以及

补偿机制模块，被配置为如果所述异常监测和判断模块确定发生了数据同步失败，则以微服务的方式再次将所述消息内容发送给所述数据同步处理服务模块。

7. 一种基于消息队列及微服务的数据同步系统，包括：

如权利要求6所述的数据同步模块，以及

数据同步处理服务模块，被配置为接收从所述数据同步模块发送的消息内容并对所述消息内容进行数据同步处理。

8. 如权利要求7所述的数据同步系统，其特征在于，所述消息队列发送模块被进一步配置为在以所述消息队列协议方式发送所述消息内容之前，对所述待同步数据进行预处理，其中所述预处理包括：

将所述待同步数据转换为Json格式的数据报文形式的消息内容；以及

从所述待同步数据中标记出实体对象类型和发送系统的ID，并以公共参数的方式将它们标记于数据报文中。

9.如权利要求8所述的数据同步系统，其特征在于，所述补偿机制模块被进一步配置为在以微服务的方式再次发送所述消息内容之前，将原来被转换为Json格式的数据报文形式的所述消息内容转换为供微服务网络传输的序列化对象。

10.如权利要求8所述的数据同步系统，其特征在于，所述数据同步处理服务模块包括下述组件：

数据规则映射配置组件，被配置为在所述数据同步处理服务模块初始化阶段以系统、源数据、目标数据源多个维度组合的形式构建规则并配置相关配置文件；

数据接收组件，被配置为：以消息队列消费者的身份接收所述消息队列发送模块以所述消息队列协议方式发送的所述消息内容，或者以微服务提供者的身份接收所述补偿机制模块以所述微服务方式发送的所述消息内容，并对接收到的所述消息内容进行初步消息报文验证及过滤；

数据解析转换组件，被配置为：从所接收的所述消息内容中解析出所述公共参数，所述公共参数包括：所述实体对象类型和所述发送系统的ID，根据所述公共参数从所述数据规则映射配置中获取匹配的规则，解析所述规则中的数据映射关系以导向至所述规则对应的处理模块来完成将对应目标数据源的数据对象转换成数据库SQL语句，通过所述规则中的目标数据源信息，从数据源连接池中获取并建立连接，进而执行数据同步；

监控处理组件，被配置为在所述数据同步处理服务模块初始化时就启动监控告警定时扫描任务以监控在所述数据同步处理过程中出现同步失败情况，并在出现同步失败的情况下时，执行下述一项或多项操作：

以日志文件及数据表的形式记录同步失败信息；

将异常数据信息存储到相应的数据库中；以及

以邮件或短信形式发送或播报告警。

Images