CN102306197A - 保证跨数据源操作结果一致性的装置和方法 - Google Patents

Abstract

本发明提供了一种保证跨数据源操作结果一致性的方法，包括：打开消息中间件的本地事务，当接收到来自消息中间件的指定列队中的消息时，根据消息创建一个全局事务，开始第二数据源的本地事务，其中，消息中间件为第一数据源；根据消息的业务处理需要从第二数据源中获取所需业务数据，在业务处理结束时，将生成的处理结果保存至第二数据源；根据返回的处理结果发起提交或者回滚全局事务的过程，先提交或者回滚第二数据源的本地事务，然后提交或者回滚消息中间件的本地事务，全局事务提交或者回滚成功后，释放全局事务的相关资源。本发明还提供了一种保证跨数据源操作结果一致性的装置。可以在非XA协议方式下，保证跨数据源的操作结果的一致性。

Description

保证跨数据源操作结果一致性的装置和方法

技术领域

本发明涉及同步技术领域，具体而言，涉及保证跨数据源操作结果一致性的装置和方法。

背景技术

在当前的企业级分布式生产环境中，多个数据源的使用在保持高效率、高可用的同时也带来了如何保证跨数据源的全局事务的操作结果一致性问题。目前主流的解决方案一般是利用独立的事务管理器，使用XA协议的两阶段提交过程来保证其一致性(详请参见X/OPEN组织定义的XA规范)。但XA协议有以下的弊端：

1.使用XA协议实现的事务本身要用到数据源的一些关键资源，这使得对数据源的性能有一定的影响。

2.根据XA规范，XA协议在预提交成功后会要求数据源锁定本事务相关的资源；直到第二阶段(真正的提交或者回滚)完成，相关资源的锁才会被释放。一旦在第二阶段异常，在事务完成前的很长一段时间里被锁定的资源将会不可访问，这在很多客户现场是不可接受的。

3.这种锁是一种“硬锁”——即使连接断掉、数据库实例甚至整个机器重新启动该锁都不会释放，这对某些数据访问实时性要求很高的***是不合适的。

从以上描述不难看出使用XA协议做分布式的事务管理的种种弊端，在一些特定的情况下可能因为对资源的锁定会造成一时间事务相关的数据不可访问，从而给客户以很差的使用体验。

因此，如何在不使用XA协议的情况下保证跨数据源的分布式全局事务的一致性，是需要解决的问题。

发明内容

本发明所要解决的技术问题在于，提供一种数据同步技术，可以在不使用XA协议的情况下保证跨数据源的分布式全局事务的一致性。

根据本发明的一个方面，提供了一种保证跨数据源操作结果一致性的装置，包括：消息处理单元，请求打开消息中间件的本地事务，接收来自所述消息中间件的指定列队中的消息，根据所述消息向全局事务控制单元发送创建一个全局事务的第一请求以及在接收到来自应用服务单元返回的处理结果时，向所述全局事务控制单元发送发起提交或者回滚所述全局事务的过程的第二请求以及在接收到来自所述全局事务单元的命令时，提交或者回滚所述消息中间件的本地事务，所述消息中间件的本地事务为在所述消息中间件上运行的事务，所述消息中间件为第一数据源；所述全局事务控制单元，在接收到来自所述消息处理单元的所述第一请求时，创建一个所述全局事务，开始第二数据源的本地事务以及在接收到来自所述消息单元的所述第二请求时，发起提交所述全局事务的过程，先提交所述第二数据源的本地事务，然后命令所述消息处理单元提交所述消息中间件的本地事务，以完成所述全局事务的提交或者回滚过程，所述全局事务提交或者回滚成功后，释放所述全局事务的相关资源，所述全局事务为跨所述第一数据源和所述第二数据源运行的事务，所述第二数据源的本地事务为在所述第二数据源上运行的事务；所述应用服务单元，根据所述消息的业务处理需要从所述第二数据源中获取所需业务数据，在所述业务处理结束时，将生成的处理结果保存至所述第二数据源，将所述处理结果返回至所述消息处理单元。

在上述技术方案中，优选地，所述消息单元还用于在接收到所述消息时，请求所述全局事务控制单元查看所述消息是否为第一次处理的消息以及接收来自所述全局事务单元的所述全局事务的标识并将所述标识发送至所述应用单元；所述全局事务单元还用于在确定所述消息为第一次处理时，请求为创建的所述全局事务分配相应的标识，并将所述标识发送至所述消息单元，在确定所述消息不是第一次被处理时，根据恢复出来的对应的所述全局事务的状态继续处理所述消息。

在上述技术方案中，优选地，所述全局事务控制单元包括：状态修改模块，在所述应用服务单元处理所述消息之前，设置所述全局事务的状态为正在进行业务处理状态，在进行所述消息的处理过程时，将所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态以及在发起提交所述全局事务的过程时，修改所述全局事务的状态为正在提交状态，修改所述消息中间件的本地事务的状态为正在提交状态，预先修改所述第二数据源的本地事务的状态为提交完成状态，当监控到所述第二数据源的本地事务和所述消息中间件的本地事务均提交完成时，先修改所述消息中间件的本地事务的状态为提交完成状态，然后修改所述全局事务的状态为提交完成状态，释放所述全局事务的相关资源。

在上述技术方案中，优选地，所述全局事务控制单元还可以包括：恢复模块，在提交所述第二数据源的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，***恢复后，所述应用服务单元将重新处理所述消息，在提交所述消息中间件的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，在***恢复后，所述应用服务单元将重新处理该消息，而由于针对本消息的第二数据源处理已经完成(通过激烈的本地事务状态可以查询)，所以处理结束后只要删除所述消息就行以及在修改所述消息中间件的本地事务的状态为提交完成状态之前，若出现异常并重新启动，则在所述消息中间件中删除所述消息。

在上述技术方案中，优选地，所述全局事务控制单元还可以包括：控制模块，在所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态时，允许在所述全局事务中加入其它数据源的本地事务，在所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时，不允许在所述全局事务中加入所述其它数据源的本地事务；所述消息中间件的本地事务的状态信息、所述第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据源中，所述第二数据源为数据库数据源。

通过上述技术方案，可以使用非XA协议方式来保证跨数据源的数据操作结果一致性——利用保存在第二数据源里的全局事务的状态，来双向核对DBMS(第二数据源)和MOM(消息中间件，第一数据源)这两类数据源，通过绝对的状态控制来保证事务业务处理的操作结果一致性。

根据本发明的又一方面，还提供了一种保证跨数据源操作结果一致性的方法，包括：步骤602，打开消息中间件的本地事务，当接收到来自所述消息中间件的指定列队中的消息时，根据所述消息创建一个全局事务，开始第二数据源的本地事务，其中，所述消息中间件为第一数据源，所述消息中间件的本地事务为在所述消息中间件上运行的事务，所述第二数据源的本地事务为在所述第二数据源上运行的事务，所述全局事务为跨所述第一数据源和所述第二数据源运行的事务；步骤604，根据所述消息的业务处理需要从所述第二数据源中获取所需业务数据，在所述业务处理结束时，将生成的处理结果保存至所述第二数据源；步骤606，根据返回的所述处理结果发起提交或者回滚所述全局事务的过程，先提交或者回滚所述第二数据源的本地事务，然后提交或者回滚所述消息中间件的本地事务，以完成所述全局事务的提交或者回滚过程，所述全局事务提交或者回滚成功后，释放所述全局事务的相关资源。

在上述技术方案中，优选地，所述步骤602还可以包括：判断所述消息是否为第一次处理的消息，若判断出所述消息为第一次处理，则创建所述全局事务并请求为所述全局事务分配标识，根据所述标识处理所述消息，若判断出所述消息不是第一次被处理，则根据恢复出来的对应的所述全局事务的状态继续处理所述消息。

在上述技术方案中，优选地，所述步骤602还可以包括：在处理所述消息之前，设置所述全局事务的状态为正在进行业务处理状态，在进行所述消息的处理过程时，将所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态；所述步骤606还包括：在发起提交所述全局事务的过程时，修改所述全局事务的状态为正在提交状态，修改所述消息中间件的本地事务的状态为正在提交状态，预先修改所述第二数据源的本地事务的状态为提交完成状态，当监控到所述第二数据源的本地事务和所述消息中间件的本地事务均提交完成时，先修改所述消息中间件的本地事务的状态为提交完成状态，然后修改所述全局事务的状态为提交完成状态，释放所述全局事务的相关资源。

在上述技术方案中，优选地，所述步骤606还可以包括：在提交所述第二数据源的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务和所述第二数据源的本地事务，所述消息回到所述消息中间件的指定列队中，重新处理所述消息；在提交所述消息中间件的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，，将所述消息返回到所述消息中间件的指定列队中，重新处理所述消息，处理结束后删除所述消息；在修改所述消息中间件的本地事务的状态为提交完成状态之前，若出现异常并重新启动，则在所述消息中间件中删除所述消息。

在上述技术方案中，优选地，当所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态时，允许在所述全局事务中加入其它数据源的本地事务，当所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时，不允许在所述全局事务中加入所述其它数据源的本地事务，所述消息中间件的本地事务的状态信息、所述第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据源中，所述第二数据源为数据库数据源(例如，OLTP数据源)。

通过上述技术方案，可以使用非XA协议方式来保证跨数据源的数据操作结果一致性——利用保存在第二数据源里的全局事务的状态，来双核对DBMS(第二数据源)和MOM(消息中间件，第一数据源)这两类数据源，通过绝对的状态控制来保证事务业务处理的操作结果一致性。

附图说明

图1示出了根据本发明的实施例的保证跨数据源操作结果一致性的***的框图；

图2示出了根据本发明的实施例的多模块协作的时序图；

图3示出了根据本发明的实施例的全局事务的状态变化示意图；

图4示出了根据本发明的实施例的全局事务中的分支状态变化示意图；

图5示出了根据本发明的实施例的保证跨数据源操作结果一致性的装置的框图；以及

图6示出了根据本发明的实施例的保证跨数据源操作结果一致性的方法的流程图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明并不限于下面公开的具体实施例的限制。

在下文中出现的英文缩写的说明如下：

消息中间件：英文名称Message Oriented Middleware，简称MOM，是一种构建高效可靠的数据传输平台的基础软件。

数据库管理***：英语名称Database Management System，简称DBMS，也是一种基础软件，主要功能是向上层应用提供数据的可靠存储和高效查询服务。

事务：是一系列操作的集合，这些操作将作为一个整体参与到上层逻辑中(事务的原子性)；最终的结果只有两个，要么所有操作全部生效，要么全部失败。

本地事务：一般指在单个数据源上运行的事务。

全局事务：一般是跨数据源或者跨***的事务。

事务管理器：一般是跨数据源的、独立的事务管理***。其功能是维护跨数据源的全局事务(协调参与本事务的每一个数据源的本地事务)，并保证其分布式环境下的结果一致性。

首先结合图1中所示的实施例在整体上说明根据本发明的技术方案。

如图1所示，事务管理器102作为一种中间件***，通过事务管理接口可以向上层应用(应用层)提供服务；向下封装了DBMS(例如图中的数据库管理***104，可以为OLTP数据源并作为第二数据源)、MOM(例如图中的消息中间件106，作为第一数据源)和其他的EIS所提供的服务(位于企业信息***层)，为事务管理器102提供统一的接口。

事务管理器102的核心模块有以下三个构成：

全局事务标识管理1022：该模块主要负责维护全局事务标识。为保证唯一性，将全局事务标识信息持久化在了DBMS中，并向其他模块提供统一的调用接口。

消息处理单元1024：在多层模型中，上层应用已经进化成为一个个服务并嵌入在事务管理器或者其他的中间件***中运行。消息处理单元1024封装了事务和JMS消息处理的相关细节，根据JMS规范(详细请参见JMS规范)，应用只要实现相应的消息数据处理逻辑即可，这极大地简化了上层应用的难度。

全局事务控制单元1026：该模块主要负责全局事务的管理，并向外提供事务处理的接口，如创建、提交、回滚、超时监控等。一个全局事务将包括两个分支：一个分支用于处理MOM的操作，另一个分支用于处理DBMS的操作。对全局事务的管理(包括对全局事务分支的管理)通过对全局事务的状态维护来实现。实际上，全局事务的状态就是对消息进行业务处理的状态，为了保证全局操作的结果一致性，在设计中全局事务的信息及状态也会被持久化到DBMS***中，这样就可以将全局事务的状态操作和业务操作的事务进行绑定，从而保证消息被不重不丢的处理。

通过上面的描述可以看到实现的过程为：从MOM接收一个消息并处理这个消息，把对应这个消息数据的业务处理所需要的其他业务数据从DBMS里提取出来，在业务逻辑处理完成后将生成的结果存储到DBMS中去；但如果加入可靠性要求——在异常情况下也能保证消息被不重不丢的处理，这就需要事务管理器102通过全局事务来协调两个数据源的本地事务，以此来保证结果一致性。为了避免使用XA协议给带来的影响，将使用双向状态核对机制来控制全局事务的状态。下面将以一个多模块协作的时序图来描述如何实现使用双向状态核对来控制全局事务的状态：

如图2所示，1，将建立消息处理单元1024与消息中间件106、数据库管理***104(第二数据源，例如OLTP数据源)、应用服务单元108的连接；2，从数据库管理***中恢复全局事务标识使用情况；3，从数据库管理***中恢复未完成的事务。各个模块都初始化(1、2和3)完成后，事务管理器102提供的消息处理单元1024将阻塞在MOM的消息队列上，等待一个很新的消息请求到来，这是触发一个完整的事务处理流程的前提(见4和5)。

4，消息处理单元1024请求打开一个消息中间件106的本地事务；5，根据业务需要请求消息中间件从指定队列中接收到消息；6，返回给消息处理单元业务对应的消息；7，消息处理单元1024一旦收到消息，请求全局事务控制单元1026查看该消息是否已经注册对应的事务；8，全局事务控制单元1026检查该消息是否已经注册对应的全局事务(已经被处理过的消息)；9，消息处理单元1024收到返回查看结果；10，如果发现是已经被处理过的事务，根据对应的事务的状态决定去完成这个事务，如果是第一次处理这个消息，则请求全局事务控制单元1026创建一个全局事务；11，全局事务控制单元1026请求全局事务标识管理单元1022给一个全局事务标识；12，全局事务标识管理单元1022分配一个全局事务标识给全局事务控制单元1026；13，创建全局事务，将该全局事务的分支(MOM和DBMS的两个本地事务)初始化。14，开始一个第二数据源(DBMS，数据库管理***)的本地事务；15，创建事务过程结束和调用针对该消息的业务处理流程之前，将全局事务的状态修改为正在进行业务处理。

16，全局事务控制单元1026将创建的全局事务的标识传送至消息处理单元1024；17，应用服务单元108调用业务处理逻辑处理接收到的消息；18，应用服务单元108在处理时，向第二数据源获取业务处理需要的业务数据；19，第二数据源返回应用服务单元108需要的业务数据；20，处理消息数据；21，将处理结果返回至消息处理单元；22，消息处理单元1024接收到处理结果后，发起提交全局事务的流程；24，将全局事务的状态修改为正在提交状态，并且将第二数据源装的本地事务的状态修改为已经提交，消息中间件的本地事务的状态修改为正在提交状态，将这些状态信息持久化在第二数据源中；25，全局事务控制单元1026命令提交第二数据源的本地事务；26，全局事务控制单元1026命令消息处理单元1024提交消息中间件的本地事务；27，消息处理单元1024接收到指令后，提交消息中间件的本地事务；28，消息中间件106返回提交成功的信息给消息处理单元；29，消息处理单元1024通知全局事务控制单元1026消息中间件106的本地事务已经提交成功；30，全局事务控制单元1026接收到通知后，修改消息中间件的本地事务状态为已经提交；31，修改全局事务状态为已经提交，并将这些状态信息持久化与第二数据源中；32，到此一个从收到消息到处理的整个过程的全局事务就完成了，最后释放全局事务的相关资源，结束本次请求的处理。

在图2中只给出了消息数据处理成功后全局事务提交的流程，考虑到如果消息数据处理失败后全局事务的回滚流程和提交流程十分类似，因此将不再给出全局事务回滚的相互协作时序图。此外，图2里给出的是正常的业务时序图，真正实现过程中对任何的异常/失败都要严格按照时序进行回滚处理，这样才能保证其全局事务的结果一致性。下面将详细解释这种***是如何保证在各种异常情况下操作结果的一致性的，从时序图里可以看到23～32为全局事务的提交或回滚过程，接下来就针对每一个步骤假设***重新启动，是如何被恢复的。

(1)在25之前***异常并重新启动：

会发现对第二数据源执行的所有操作所在的事务，因为***重新启动而被回滚掉，因此，第二数据源中将没有任何处理该消息所对应的事务的记录；而该消息在消息中间件中对应的本地事务也将回滚掉，消息又重新回到了消息中间件的队列中；***恢复后这个消息将再次被取出并进行处理(和进行第一次处理的过程一样)，所以这种情况不会造成任何的结果不一致。

(2)在26或27或28之前***异常并重新启动：

在消息中间件提交本地事务前***异常并重新启动，将导致消息中间件的本地事务(MOM分支的本地事务)回滚，消息回到消息中间件的制定列队中，按照第一次处理该消息时的流程(获取全局事务，检查全局事务的状态到修改全局事务的状态)重新处理该消息对应的本地事务，而此时DBMS分支的本地事务已经提交，因此全局事务控制单元在初始化时，将把该MOM消息对应的全局事务恢复回来，其全局事务的状态为正在提交，MOM分支的状态为正在提交，而DBMS分支的状态为已经提交，这表示针对这个消息数据所对应的业务处理都已经成功处理结束，接下来所要做的是直接从MOM中删除这个消息并释放全局事务的相关资源就，同样这种情况也不会造成任何结果不一致。

(3)在29或30之前***异常并重新启动：

虽然在DBMS中的全局事务的状态与上述情况一样，但实际上MOM分支的本地事务已经提交(被处理的消息已经不存在)，只需按正常处理那样去删除这个消息，然后释放全局事务相应的资源，这种情况也不会造成任何的结果不一致。

(4)在31之前***异常并重新启动：

重新启动后，全局事务控制单元从DBMS中恢复事务后，其全局事务状态为正在提交，而DBMS和MOM这两个分支的状态都是已经提交完成，此时处理过程更加简单，只需修改全局事务状态为提交完成并释放全局事务的相关资源，这种情况下也不会有任何结果不一致。

(5)在32之前***异常并重新启动：

在此之前发生异常并重新启动***，全局事务控制单元从DBMS中恢复事务后，发现全局事务状态已经是提交完成，只需释放全局事务相关的资源，这种情况下也不会有任何结果不一致。

从上面的详细描述可以看出根据本发明的技术方案虽然没有使用XA协议，但是在任何情况都能保证全局事务所协调的MOM和DBMS这两个数据源上本地事务的一致性。

下面结合图3说明全局事务的状态变化情况。

如图3所示，步骤302，全局事务的状态以初始状态开始，若事务发起者主动回滚，则进入步骤312，处于正在进行分支回滚状态。步骤304，在各个分支(例如消息中间件的本地事务、第二数据源的本地事务)的业务处理阶段，将各分支的状态设置为正在进行业务处理状态，全局事务的状态也为正在进行业务处理状态，此时，在全局事务中可以加入其他的分支。若进行业务处理超时，则进入步骤312，处于正在进行分支回滚状态。步骤306，所有分支业务处理完成后修改全局事务的状态为业务处理完成状态，这时不能在全局事务中加入其他的分支，若业务处理超时或失败，则进入步骤312，然后进行步骤314，进入分支回滚完成状态。步骤308，收到来自调用者的提交事务信息后，全局事务的状态会被修改为正在提交事务状态，并触发各个分支的提交流程，各分支状态为正在进行提交状态。步骤310，在此期间需要监视所有分支的状态，直到各个分支都提交完成，最后将全局事务状态修改为全局事务提交完成状态，这样就完成了一个全局事务的生命周期。在整个生命周期内任何主动发起或者失败(比如业务失败或者超时)都可以触发全局事务的回滚流程。

下面结合图4说明全局事务分支的状态变化情况。

如图4所示，是全局事务的一个分支(消息中间件的本地事务或OLTP数据源的本地事务)的状态变化示意图，步骤402，与全局事务一样，分支的状态也是以初始状态开始。步骤404，在调用真正的业务处理流程之前其状态会被修改为正在进行业务处理。步骤404，直至业务处理处理完成，分支的状态会被相应的修改，修改为业务处理完成状态。接下来的状态需要等待全局事务的触发，进行分支提交或者回滚流程。判断是否处理成功，如果处理成功或全局事务发起者发起提交指令，则进入步骤408，进入正在进行提交状态，然后进入步骤410，提交完成后，将分支状态修改为提交完成状态。若判断处理失败或全局事务发起者要求回滚，则进入步骤412，进入分支正在进行回滚状态，然后进入步骤414，进入分支回滚完成状态，在提交或者回滚完成后，分支的生命周期结束。

图5示出了根据本发明的实施例的保证跨数据源操作结果一致性的装置的框图。

如图5所示，根据本发明的实施例的保证跨数据源操作结果一致性的装置500，包括：消息处理单元502，请求打开消息中间件的本地事务，接收来自所述消息中间件的指定列队中的消息，根据所述消息向全局事务控制单元504发送创建一个全局事务的第一请求以及在接收到来自应用服务单元506返回的处理结果时，向所述全局事务控制单元504发送发起提交所述全局事务的过程的第二请求以及在接收到来自所述全局事务单元504的命令时，提交所述消息中间件的本地事务，所述消息中间件的本地事务为在所述消息中间件上运行的事务，所述消息中间件为第一数据源；所述全局事务控制单元504，在接收到来自所述消息处理单元502的所述第一请求时，创建一个所述全局事务，开始第二数据源的本地事务以及在接收到来自所述消息单元502的所述第二请求时，发起提交或者回滚所述全局事务的过程，先提交或者回滚所述第二数据源的本地事务，然后命令所述消息处理单元502提交或者回滚所述消息中间件的本地事务，以完成所述全局事务的提交或者回滚过程，所述全局事务提交或者回滚成功后，释放所述全局事务的相关资源，所述全局事务为跨所述第一数据源和所述第二数据源运行的事务，所述第二数据源的本地事务为在所述第二数据源上运行的事务；所述应用服务单元506，根据所述消息的业务处理需要从所述第二数据源中获取所需业务数据，在所述业务处理结束时，将生成的处理结果保存至所述第二数据源，将所述处理结果返回至所述消息处理单元502。

在上述技术方案中，优选地，所述消息单元502还用于在接收到所述消息时，请求所述全局事务控制单元504查看所述消息是否为第一次处理的消息以及接收来自所述全局事务单元504的所述全局事务的标识并将所述标识发送至所述应用单元506；所述全局事务单元504还用于在确定所述消息为第一次处理时，请求为创建的所述全局事务分配相应的标识，并将所述标识发送至所述消息单元502，在确定所述消息不是第一次被处理时，根据恢复出来的对应的所述全局事务的状态继续处理所述消息。

在上述技术方案中，优选地，所述全局事务控制单元504包括：状态修改模块5042，在所述应用服务单元506处理所述消息之前，设置所述全局事务的状态为正在进行业务处理状态，在进行所述消息的处理过程时，将所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态以及在发起提交所述全局事务的过程时，修改所述全局事务的状态为正在提交状态，修改所述消息中间件的本地事务的状态为正在提交状态，预先修改所述第二数据源的本地事务的状态为提交完成状态，当监控到所述第二数据源的本地事务和所述消息中间件的本地事务均提交完成时，先修改所述消息中间件的本地事务的状态为提交完成状态，然后修改所述全局事务的状态为提交完成状态，释放所述全局事务的相关资源。

在上述技术方案中，优选地，所述全局事务控制单元504还可以包括：恢复模块5044，在提交所述第二数据源的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，***恢复后，所述应用服务单元506将重新处理所述消息，在提交所述消息中间件的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，在***恢复后，将所述应用服务单元506重新处理该消息，而由于针对本消息的第二数据源处理已经完成(通过激烈的本地事务状态可以查询)，所以只要在处理结束后删除所述消息就行以及在修改所述消息中间件的本地事务的状态为提交完成状态之前，若出现异常并重新启动，则在所述消息中间件中删除所述消息。

在上述技术方案中，优选地，所述全局事务控制单元504还可以包括：控制模块5046，在所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态时，允许在所述全局事务中加入其它数据源的本地事务，在所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时，不允许在所述全局事务中加入所述其它数据源的本地事务；所述消息中间件的本地事务的状态信息、所述第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据源中，所述第二数据源为数据库数据源(例如，OLTP数据源)。

通过上述技术方案，可以使用非XA协议方式来保证跨数据源的数据操作结果一致性——利用保存在第二数据源里的全局事务的状态，来双核对DBMS(第二数据源)和MOM(消息中间件，第一数据源)这两类数据源，通过绝对的状态控制来保证事务业务处理的操作结果一致性。

图6示出了根据本发明的实施例的保证跨数据源操作结果一致性的方法的流程图。

如图6所示，根据本发明的实施例的保证跨数据源操作结果一致性的方法，包括：步骤602，打开消息中间件的本地事务，当接收到来自所述消息中间件的指定列队中的消息时，根据所述消息创建一个全局事务，命令开始第二数据源的本地事务，其中，所述消息中间件为第一数据源，所述消息中间件的本地事务为在所述消息中间件上运行的事务，所述第二数据源的本地事务为在所述第二数据源上运行的事务，所述全局事务为跨所述第一数据源和所述第二数据源运行的事务；步骤604，根据所述消息的业务处理需要从所述第二数据源中获取所需业务数据，在所述业务处理结束时，将生成的处理结果保存至所述第二数据源；步骤606，根据返回的所述处理结果发起提交或者回滚所述全局事务的过程，先提交或者回滚所述第二数据源的本地事务，然后提交或者回滚所述消息中间件的本地事务，以完成所述全局事务的提交或者回滚过程，所述全局事务提交或者回滚成功后，释放所述全局事务的相关资源。

在上述技术方案中，优选地，所述步骤602还可以包括：判断所述消息是否为第一次处理的消息，若判断出所述消息为第一次处理，则创建所述全局事务并请求为所述全局事务分配标识，根据所述标识处理所述消息，若判断出所述消息不是第一次被处理，则根据恢复出来的对应的所述全局事务的状态继续处理所述消息。

在上述技术方案中，优选地，所述步骤602还可以包括：在处理所述消息之前，设置所述全局事务的状态为正在进行业务处理状态，在进行所述消息的处理过程时，将所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态；所述步骤606还包括：在发起提交所述全局事务的过程时，修改所述全局事务的状态为正在提交状态，修改所述消息中间件的本地事务的状态为正在提交状态，预先修改所述第二数据源的本地事务的状态为提交完成状态，当监控到所述第二数据源的本地事务和所述消息中间件的本地事务均提交完成时，先修改所述消息中间件的本地事务的状态为提交完成状态，然后修改所述全局事务的状态为提交完成状态，释放所述全局事务的相关资源。

在上述技术方案中，优选地，所述步骤606还可以包括：在提交所述第二数据源的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务和所述第二数据源的本地事务，所述消息回到所述消息中间件的指定列队中，重新处理所述消息；在提交所述消息中间件的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，重新处理所述消息，处理结束后删除所述消息；在修改所述消息中间件的本地事务的状态为提交完成状态之前，若出现异常并重新启动，则在所述消息中间件中删除所述消息。

在上述技术方案中，优选地，当所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态时，允许在所述全局事务中加入其它数据源的本地事务，当所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时，不允许在所述全局事务中加入所述其它数据源的本地事务，所述消息中间件的本地事务的状态信息、所述第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据源中，所述第二数据源为数据库数据源(例如，OLTP数据源)。

通过上述技术方案，可以实现使用非XA协议方式来保证跨数据源的操作结果的一致性——利用保存在DBMS里的全局事务的状态做双核对，来协调***中的DBMS和MOM这两类数据源，通过绝对的状态控制来保证事务业务处理的操作结果一致性。通过这种实现机制，既避免了使用XA协议会带来的不利影响和潜在风险，同时又能保证绝对的事务一致性。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种保证跨数据源操作结果一致性的装置，其特征在于，包括：

消息处理单元，请求打开消息中间件的本地事务，接收来自所述消息中间件的指定列队中的消息，根据所述消息向全局事务控制单元发送创建一个全局事务的第一请求以及在接收到来自应用服务单元返回的处理结果时，向所述全局事务控制单元发送发起提交或者回滚所述全局事务的过程的第二请求以及在接收到来自所述全局事务单元的命令时，提交或者回滚所述消息中间件的本地事务，所述消息中间件的本地事务为在所述消息中间件上运行的事务，所述消息中间件为第一数据源；

所述全局事务控制单元，在接收到来自所述消息处理单元的所述第一请求时，创建一个所述全局事务，开始第二数据源的本地事务以及在接收到来自所述消息单元的所述第二请求时，发起提交或者回滚所述全局事务的过程，先提交或者回滚所述第二数据源的本地事务，然后命令所述消息处理单元提交或者回滚所述消息中间件的本地事务，以完成所述全局事务的提交或者回滚过程，所述全局事务提交成功后，释放所述全局事务的相关资源，所述全局事务为跨所述第一数据源和所述第二数据源运行的事务，所述第二数据源的本地事务为在所述第二数据源上运行的事务；

所述应用服务单元，根据所述消息的业务处理需要从所述第二数据源中获取所需业务数据，在所述业务处理结束时，将生成的处理结果保存至所述第二数据源，将所述处理结果返回至所述消息处理单元。

2.根据权利要求1所述的保证跨数据源操作结果一致性的装置，其特征在于，所述消息单元还用于在接收到所述消息时，请求所述全局事务控制单元查看所述消息是否为第一次处理的消息以及接收来自所述全局事务单元的所述全局事务的标识并将所述标识发送至所述应用单元；

所述全局事务单元还用于在确定所述消息为第一次处理时，请求为创建的所述全局事务分配相应的标识，并将所述标识发送至所述消息单元，在确定所述消息不是第一次被处理时，根据恢复出来的对应的所述全局事务的状态继续处理所述消息。

3.根据权利要求1所述的保证跨数据源操作结果一致性的装置，其特征在于，所述全局事务控制单元包括：

状态修改模块，在所述应用服务单元处理所述消息之前，设置所述全局事务的状态为正在进行业务处理状态，在进行所述消息的处理过程时，将所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态以及在发起提交所述全局事务的过程时，修改所述全局事务的状态为正在提交状态，修改所述消息中间件的本地事务的状态为正在提交状态，预先修改所述第二数据源的本地事务的状态为提交完成状态，当监控到所述第二数据源的本地事务和所述消息中间件的本地事务均提交完成时，先修改所述消息中间件的本地事务的状态为提交完成状态，然后修改所述全局事务的状态为提交完成状态，释放所述全局事务的相关资源。

4.根据权利要求3所述的保证跨数据源操作结果一致性的装置，其特征在于，所述全局事务控制单元还包括：

恢复模块，在提交所述第二数据源的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，所述应用服务单元将重新处理所述消息，在提交所述消息中间件的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，所述应用服务单元将重新处理所述消息，处理结束后删除所述消息以及在修改所述消息中间件的本地事务的状态为提交完成状态之前，若出现异常并重新启动，则在所述消息中间件中删除所述消息。

5.根据权利要求4所述的保证跨数据源操作结果一致性的装置，其特征在于，所述全局事务控制单元还包括：

控制模块，在所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态时，允许在所述全局事务中加入其它数据源的本地事务，在所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时，不允许在所述全局事务中加入所述其它数据源的本地事务；

所述消息中间件的本地事务的状态信息、所述第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据源中，所述第二数据源为数据库数据源。

6.一种保证跨数据源操作结果一致性的方法，其特征在于，包括：

步骤602，打开消息中间件的本地事务，当接收到来自所述消息中间件的指定列队中的消息时，根据所述消息创建一个全局事务，开始第二数据源的本地事务，其中，所述消息中间件为第一数据源，所述消息中间件的本地事务为在所述消息中间件上运行的事务，所述第二数据源的本地事务为在所述第二数据源上运行的事务，所述全局事务为跨所述第一数据源和所述第二数据源运行的事务；

步骤604，根据所述消息的业务处理需要从所述第二数据源中获取所需业务数据，在所述业务处理结束时，将生成的处理结果保存至所述第二数据源；

步骤606，根据返回的所述处理结果发起提交或者回滚所述全局事务的过程，先提交或者回滚所述第二数据源的本地事务，然后提交或者回滚所述消息中间件的本地事务，以完成所述全局事务的提交或者回滚过程，所述全局事务提交成功后，释放所述全局事务的相关资源。

7.根据权利要求6所述的保证跨数据源操作结果一致性的方法，其特征在于，所述步骤602还包括：判断所述消息是否为第一次处理的消息，若判断出所述消息为第一次处理，则创建所述全局事务并请求为所述全局事务分配标识，根据所述标识处理所述消息，若判断出所述消息不是第一次被处理，则根据恢复出来的对应的所述全局事务的状态继续处理所述消息。

8.根据权利要求6所述的保证跨数据源操作结果一致性的方法，其特征在于，所述步骤602还包括：在处理所述消息之前，设置所述全局事务的状态为正在进行业务处理状态，在进行所述消息的处理过程时，将所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态；

所述步骤606还包括：在发起提交所述全局事务的过程时，修改所述全局事务的状态为正在提交状态，修改所述消息中间件的本地事务的状态为正在提交状态，预先修改所述第二数据源的本地事务的状态为提交完成状态，当监控到所述第二数据源的本地事务和所述消息中间件的本地事务均提交完成时，先修改所述消息中间件的本地事务的状态为提交完成状态，然后修改所述全局事务的状态为提交完成状态，释放所述全局事务的相关资源。

9.根据权利要求8所述的保证跨数据源操作结果一致性的方法，其特征在于，所述步骤606还包括：在提交所述第二数据源的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，所述消息返回到所述消息中间件的指定列队中，重新处理所述消息；

在提交所述消息中间件的本地事务之前，若出现异常并重新启动，则回滚所述消息中间件的本地事务，将所述消息返回到所述消息中间件的指定列队中，重新处理所述消息，处理结束后删除所述消息；

在修改所述消息中间件的本地事务的状态为提交完成状态之前，若出现异常并重新启动，则在所述消息中间件中删除所述消息。

10.根据权利要求8所述的保证跨数据源操作结果一致性的方法，其特征在于，当所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态时，允许在所述全局事务中加入其它数据源的本地事务，当所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时，不允许在所述全局事务中加入所述其它数据源的本地事务，所述消息中间件的本地事务的状态信息、所述第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据源中，所述第二数据源为数据库数据源。

Images