CN107045454B - 跨进程分布式事务控制方法及相关系统 - Google Patents

Abstract

本发明提供跨进程分布式事务控制方法及相关系统。在该方法中,第一事务管理器对应主事务，创建包括全局事务状态的全局事务上下文，通过RPC将全局事务上下文发送给第二事务管理器。第二事务管理器对应子事务，使用子事务相关信息更新接收到的全局事务上下文并通过RPC发送给第一事务管理器。第一事务管理器在相应的服务完成业务逻辑后，通过全局事务快照器将全局事务上下文发送至消息中间件，并通知第二事务管理器提交子事务，在子事务提交成功后，再提交主事务，并在主事务提交成功后，通过全局事务快照器通知消息中间件将全局事务上下文中的全局事务状态更改为完成。在实现对分布式事务的控制的同时，还保持了数据更新的一致性。

Description

跨进程分布式事务控制方法及相关系统

技术领域

本发明涉及计算机技术领域，特别是涉及跨进程分布式事务控制技术。

背景技术

云应用下，业务系统为了支持扩展性，都遵从分布式架构。在分布式架构中，一个业务不再局限于在一个进程中执行，其可能会拆分到不同的进程上，由不同进程上的服务发起事务来共同完成。

例如，假定某一业务需要完成Lucy向lily转账500元，则其可能拆成到两个进程中，由其中一个进程中的服务完成的事务是将Lucy账户中的余额减500，由另一个进程中的服务完成的事务是将lily账户中的余额增加500。事务提交后，最终的结果是，多个进程中的服务各自更新数据到各自的数据库。

上述不同的进程可能在不同的虚拟机甚至在不同的物理机上运行。那么保持它们数据更新的一致性就成了一种挑战。

发明内容

本发明的目的在于提供跨进程分布式事务控制方法及相关系统，以实现地分布式场景下对事务的控制，同时保持数据更新的一致性。

为实现上述目的，本发明提供了如下方案：

一方面，本申请的实施例提供一种跨进程分布式事务控制方法，第一事务管理器对应主事务，第二事务管理器对应子事务，第一事务管理器创建包括全局事务状态的全局事务上下文，通过RPC将全局事务上下文发送给第二事务管理器。第二事务管理器对应子事务，使用子事务相关信息更新接收到的全局事务上下文并通过RPC发送给第一事务管理器。第一事务管理器在相应的服务完成业务逻辑后，通过全局事务快照器将全局事务上下文发送至消息中间件，并通知第二事务管理器提交子事务，在子事务提交成功后，再提交主事务，并在主事务提交成功后，通过全局事务快照器通知消息中间件将全局事务上下文中的全局事务状态更改为完成。这样，在实现对分布式事务的控制的同时，还保持了数据更新的一致性。

在一个可能的设计中，第一事务管理器在创建所述全局事务上下文之前，还判断是否未开启全局事务；在判断出未开启全局事务后再创建包括全局事务id和全局事务状态的全局事务上下文。这样可以防止针对同一全局事务重复创建全局事务上下文。

在一个可能的设计中，第一事务管理器在判断出未开启全局事务时，还为所述第一服务发起的分布式事务分配主事务id。则创建的全局事务上下文还可包括所述主事务id。这样可便于对跨进程分布式事务进行更好的控制。

在一个可能的设计中，所述第二事务管理器在使用子事务相关信息更新所述全局事务上下文之前，还判断是否未开启全局事务；在判断出已开启全局事务后才使用子事务相关信息更新全局事务上下文。这样，也可防止错误更新全局事务上下文。

在一个可能的设计中，第一事务管理器或第二事务管理器在判断是否未开启全局事务时，可判断是否存在全局事务上下文，若存在全局事务上下文，则判断出已开启全局事务，否则，判断出未开启全局事务。这样可进一步精确判断是否开启了全局事务。

在一个可能的设计中，在第二事务管理器提交子事务失败后，所述第一事务管理器可放弃主事务的提交。这样，可实现子事务提交失败后，主事务也不提交。则各服务对应的数据库中的数据也不会发生更新，从而仍可保证数据的一致性。

在一个可能的设计中，在所述第一事务管理器提交失败后，跨进程分布式事务控制系统可根据所述MQ中的全局事务上下文发起针对提交成功的分布式事务的回滚。这样，可令数据已发生更新的数据库中的数据恢复至未更新前，从而仍可保证数据的一致性。

另一方面，本发明实施例提供了一种第一事务管理器，该第一事务管理器具有实现上述方法实际中第一事务管理器行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。

又一方面，本发明实施例提供了一种第二事务管理器，该第二事务管理器具有实现上述方法实际中第二事务管理器行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。

又一方面，本发明实施例提供了一种全局事务快照器，该全局事务快照器具有实现上述方法实际中全局事务快照器行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。

又一方面，本发明实施例提供了一种跨进程分布式事务控制系统，该系统包括上述方面所述的全局事务快照器、第一事务管理器和至少一个第二事务管理器。

再一方面，本发明实施例提供了一种计算机存储介质，用于储存为上述第一事务管理器所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

再一方面，本发明实施例提供了一种计算机存储介质，用于储存为上述第二全局事务快照器所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

再一方面，本发明实施例提供了一种计算机存储介质，用于储存为上述第二事务管理器所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

再一方面，本发明实施例提供了一种计算机存储介质，用于储存为上述跨进程分布式事务控制系统所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

相较于现有技术，本发明提供的方案，在开启全局事务后，事务管理器之间通过RPC传递信息，令子事务提交后，主事务再提交，在实现对分布式事务的控制的同时，还保持了数据更新的一致性。

附图说明

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

图1a为本发明实施例提供的分布式场景示意图；

图1b为本发明实施例提供的跨进程分布式事务控制系统示例性结构图；

图2-3为本发明实施例提供的跨进程分布式事务控制方法示例性流程图；

图4为本发明实施例提供的跨进程分布式事务控制系统示例性结构图；

图5为本发明实施例提供的跨进程分布式事务控制系统运行在同一计算机设备上该计算机设备的示例性结构图；

图6为本发明实施例提供的跨进程分布式事务控制系统运行在不同的计算机设备上的示意图。

具体实施方式

本发明实施例提供了跨进程分布式事务控制方法及系统，其可用于在分布式场景下,控制业务跨多个进程访问数据库并保障数据一致性。具体包括将跨进程业务拆分成至少两个分布式事务，并调用不同进程上的服务执行至少两个分布式事务。

图1a给出了上述跨进程分布式事务控制方法及系统的一种应用场景:跨进程业务拆分到不同的进程上的服务(A、B、C)去执行,服务A、B、C会发起事务以更新数据到各自对应的数据库，与此同时，还要保持数据库间数据更新的一致性。图1a中的TM表示事务管理器，DB表示数据库。

不同的进程可在不同的虚拟机或物理机上运行。本发明不对其进行限制。

服务A、B、C各自发起的事务即为跨进程分布式事务(或简称为分布式事务)，在本发明中，对应同一跨进程业务的多个分布式事务统一在一个全局事务之下。

上述跨进程分布式事务控制系统包括全局事务快照处理器以及至少两个事务管理器。

为方便起见，以跨两个进程(其中一个进程中运行服务A，另一进程中运行服务B)为例，请参见图1b，跨进程分布式事务控制系统可包括事务管理器A和事务管理器B。事务管理器之间可通过通用RPC通信框架传递信息(通信)。所传递的信息具体可为全局事务上下文，通知消息、响应消息等。

其中，事务管理器主要负责管理数据库资源(特别是负责跨进程事务依赖的数据库资源引用的统一管理)，控制事务的发起和提交。事务管理器可内置事务协调器，由内置事务协调器负责跨进程事务依赖的数据库资源引用的统一管理)。

通用RPC通信框架主要负责全局事务上下文的框进程传递。全局事务上下文可包含全局事务id、子事务id、全局事务状态、操作命令、子事务依赖数据库连接引用，子事务状态等。本文后续将对全局事务上下文进行介绍。其中,操作命令可包括标记事务是正常还是异常的命令，这是因为全局事务上下文是动态变化的，所以通用RPC通信框架会提供接口给事务管理器，以便于其通过操作命令修改全局事务上下文。

通用RPC通信框架基于的协议是RPC(Remote Procedure Call Protocol，远程过程调用协议)，该协议是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

通用RPC通信框架在物理上是公共的库，在逻辑上，其运行在进程中，嵌入进程的初始环境中，为进程中的服务提供公共服务。

全局事务快照器主要负责在全局事务提交前对全局事务信息(也即前述的全局事务上下文)进行快照，并将快照结果传递给MQ。这样，当出现故障的时候，可启动其他进程或线程依据MQ中的快照结果进行故障恢复。全局事务信息包括但不限于全局事务状态、全局事务id、全局事务关联的服务(例如图1b中的服务A、服务B)、服务参数和SQL语句。

其中，服务在程序上会对应到方法(java)或函数(C/C++)，这些方法或函数的输入就是“服务参数”。

SQL语句与服务的业务逻辑对应，因为业务逻辑最终会表现为SQL语句，由数据库去执行，实现数据的增删改查，本发明所谓事务其作用是保证多条SQL语句一起执行成功或一起执行失败。

以银行转账业务为例，其涉及两个事务：对一个账户扣钱，对另一个账户增加相应数额的钱。

更具体的，假定Lucy向lily转账500元，则图1b中进程1的服务A完成的事务是将Lucy账户中的余额减500，进程2的服务B完成的事务是将lily账户中的余额增加500。

实际上，同时可能有多个转账业务需要处理，例如，Lucy向lily转账500元(业务1)，May向Shirley转账1500元(业务2)，David向Mark转账1000元(业务3)，上述三个业务均需调用服务A、B各一次，则进程1和进程2会分别创建多个线程来进行处理。例如：

进程1创建了线程1-3，进程2创建了线程100-103，其中，线程1用于调用服务A，以完成针对业务1的事务：“将Lucy账户中的余额减500”；线程102用于调用服务B，以完成针对业务1的事务：“将lily账户中的余额增加500”。

并且，线程1中会嵌入事务管理器A，线程102中会嵌入事务管理器B，事务管理器A和事务管理器B通过上述通用RPC通信框架传递信息(例如全局事务上下文，通知消息、响应消息)。也即每一线程会对应有一个事务管理器。

由于一个进程上可能有多个(至少两个)线程需要远程过程提供服务，为实现区分，一个远程过程由三个要素来唯一确定：程序号、版本号和过程号。通过上述三要素，可实现线程1嵌入的事务管理器A与线程102嵌入的事务管理器B传递信息，而不会把信息错传至其他线程。跨进程线程的关联是透明的，只要是同步调用，就会保证跨进程的线程能映射起来。

为简单起见，本发明后续将以图1b所示跨两个进程(其中一个进程中运行服务A，另一进程中运行服务B)为例，对技术方案进行介绍。如无必要，将不再强调线程。

请参见图2，上述跨进程分布式事务控制系统所执行的跨进程分布式事务控制方法可包括如下步骤：

S201：业务应用发起分布式服务调用，首先调用服务A；

为进行区别，也可将业务应用首先调用的服务称为第一服务。

S202：服务A向事务管理器A进行注册。

事务管理器A为与服务A对应的事务管理器。为便于区分，也可将其称为第一事务管理器。

S203：事务管理器A为服务A发起的分布式事务分配数据库连接引用。

为便于区分，可将事务管理器A为服务A分配的数据库连接引用称为第一数据库连接引用。

第一数据库连接引用可用于服务A对相应的数据库执行业务逻辑。

S204：事务管理器A判断是否未开启全局事务。

更具体的，事务管理器A可根据全局事务上下文判断是否开启了全局事务：若存在全局事务上下文，则判定已开启全局事务，否则，判定未开启全局事务。

由于服务可能会被跨进程业务调用，也可能会被非跨进程业务调用。因此，在本发明其他实施例中，在判断是否未开启全局事务之前，事务管理器A还可判断是否需要跨进程调用，如果需要跨进程调用，再判断是否未开启全局事务。

在具体实现时，可针对不同业务，预先配置其所涉及的服务，从而可获知是否需要跨进程调用。

需要说明的是，任一事务管理器在相应服务发起注册后，均会判断是否未开启全局事务。

步骤S203和步骤S204可同时并行执行，也可先执行步骤S204再执行S203，或者相反。

S205：在判定未开启全局事务时，事务管理器A将服务A注册的分布式事务作为全局事务中的主事务，并创建全局事务上下文。

由于服务A是首先被调用的服务，所以在服务A注册时，并未开启全局事务。事务管理器A则将服务A注册的事务作为主事务，并创建全局事务上下文。创建的全局事务上下文至少可包括全局事务id和全局事务状态。

主事务对应的事务管理器后续将起主导作用，例如，其可通知其他事务管理器提交子事务。

在一个示例中，事务管理器A还可为主事务分配主事务id，并将主事务id放入全局事务上下文。在另一个示例中，也可不为主事务分配主事务id，直接采用全局事务id作为主事务的事务id。

此外，可将第一数据库连接引用放入全局事务上下文，也可不放入。

S206：事务管理器A通过RPC通信框架将创建的全局事务上下文传递给事务管理器B。

后续事务管理器A还将通过该RPC通信框架接收由事务管理器B更新的全局事务上下文。

为便于区别，可将事务管理器B称为第二事务管理器。第二事务管理器为该跨进程分布式事务控制系统中除第一事务管理器的其他事务管理器。由于业务可能跨两个以上进程，因此，第二事务管理器可以有多个。

在具体实现时，RPC通信框架提供类似共享缓存的功能，全局事务上下文存储于“共享缓存”中，任一事务管理器可以从“共享缓存”处获取全局事务上下文，对其进行更改后，再将更改后的全局事务上下文放入该“共享缓存”。

更具体的，在更改时，是通过前述介绍的操作命令实现的。

S207：服务B向事务管理器B进行注册。

事务管理器B为与服务B对应的事务管理器。为便于区分，可将事务管理器B称为第二事务管理器。

S208：事务管理器B为服务B发起的分布式事务分配数据库连接引用。

为便于区分，可将事务管理器B为服务B分配的数据库连接引用称为第二数据库连接引用。

第二数据库连接引用可用于服务B对相应的数据库执行业务逻辑。

S209：事务管理器B判断是否未开启全局事务。

更具体的，事务管理器B可根据全局事务上下文判断是否开启了全局事务：若存在全局事务上下文，则判定已开启全局事务，否则，判定未开启全局事务。

由于服务可能会被跨进程业务调用，也可能会被非跨进程业务调用。因此，在本发明其他实施例中，在判断是否未开启全局事务之前，事务管理器B还可判断是否需要跨进程调用，如果需要跨进程调用，再判断是否未开启全局事务。

在具体实现时，可针对不同业务，预先配置其所涉及的服务，从而可获知是否需要跨进程调用。

由于事务管理器A已经创建了全局事务上下文，因此，后续事务管理器B会根据已存在的全局事务上下文判定已开启全局事务，主动加入全局事务。

S2010：在判断出已开启全局事务时，事务管理器B为服务B发起的分布式事务分配子事务id，将上述第二数据库连接引用和子事务id放入该全局事务上下文。

这样，可令全局事务与服务A和服务B数据库连接引用相关联。第二数据库连接引用在全局事务上下文中是作为子事务依赖数据库连接引用的。

S2011：事务管理器B通过通用RPC通信框架将更新后的全局事务上下文传递给该事务管理器A。

具体如何传递可参见206部分的介绍，在此不作赘述。

S2012：服务A执行业务逻辑，并在完成业务逻辑后向事务管理器A发起事务提交请求。

服务A是使用第一数据库连接引用执行业务逻辑的。更具体的，服务A会向数据库发送指令，数据库在接收到指令后，会执行相应的操作。

S2013：服务B执行业务逻辑，并在完成业务逻辑后向事务管理器B发起事务提交请求。

服务B是使用第二数据库连接引用执行业务逻辑的。更具体的，服务B会向数据库发送指令，数据库在接收到指令后，会执行相应的操作。

S2014：事务管理器A在接收到服务A发起的事务提交请求后，通过全局事务快照器将全局事务上下文发送至消息中间件(MQ)。

具体的，可由事务快照器对全局事务上下文进行快照，并将全局事务上下文发送给MQ。

可选的，事务管理器A在通过全局事务快照器将全局事务上下文发送至MQ之前，会判断是否有子事务。如果没有，直接提交当前事务，如果有，则通过全局事务快照器将全局事务上下文发送至消息中间件。

在提交主事务之前，将全局事务上下文发送至消息中间件，是考虑到下述场景：子事务提交成功，但在主事务提交之前，出现故障(例如死机)，则主事务无法提交。

这样，当故障排除，可启动其他进程或线程依据MQ中的全局事务上下文重新完成主事务提交。或者由MQ通知主事务所在的计算机设备(进程)重新完成主事务提交。

全局事务快照器可存在多个进程中，也可只存在于主事务所在的进程中。

S2015：事务管理器A通过通用RPC通信框架通知事务管理器B提交事务。

S2016：事务管理器B在接收到服务B发起的事务提交请求以及事务管理器A的通知后，进行子事务提交。

在一些场景后，可能会发生服务A调用服务B，服务B调用服务C，则服务C发起的事务，相当于服务B发起事务的子事务。则事务管理器B在进行事务提交之前，也会判断是否有子事务。如果没有，直接提交当前事务，如果有，则进行事务提交。

当然，无论提交成功或失败，事务管理器B会返回响应，通知事务管理器A事务是否提交成功。

进一步的，事务管理器A还可根据事务管理器B的响应修改全局事务上下文，并通过全局事务快照器通知MQ，对MQ中存储的全局事务上下文进行相应更改。

或者，也可由事务管理器B对全局事务上下文中的子事务状态进行修改后，再通过RPC通信框架将全局事务上下文传递给事务管理器A，事务管理器A再通过全局事务快照器通知上述MQ，对MQ中存储的全局事务上下文进行相应更改。S2017：事务管理器A在事务管理器B成功提交事务后，提交主事务。

对于有多于两个事务管理器的情况，主事务对应的事务管理器会等待其他子事务的事务管理器均成功提交后，再提交主事务。

S2018：事务管理器A在提交主事务成功后，通过全局事务快照器通知上述MQ将全局事务上下文中的全局事务状态更改为完成。

在本发明实施例中，在开启全局事务后，事务管理器之间通过通用RPC通信框架传递信息，令子事务提交后，主事务再提交，在实现对分布式事务的控制的同时，还保持了数据更新的一致性。

在本发明其他实施例中，请参见图3，上述方法还可包括如下步骤：

S3017：在第二事务管理器(事务管理器B)提交(子)事务失败后，第一事务管理器(事务管理器A)放弃主事务的提交。

这样，可实现子事务无法提交，主事务也不提交。各服务对应的数据库的数据也不会发生更新，从而仍可保证数据的一致性。

在本发明其他实施例中，上述所有实施例中的方法还可包括：在任一事务管理器(特别是第一事务管理器)提交(主)事务失败后，根据所述MQ中的全局事务上下文发起针对提交成功的分布式事务的回滚。这样，可令数据已发生更新的数据库中的数据恢复至未更新前，从而仍可保证数据的一致性。

更具体的，可由MQ通知成功提交分布式事务的计算机设备/进程/服务，对提交成功的分布式事务进行回滚。

上述主要从各个装置之间交互的角度对本发明实施例提供的方案进行了介绍。可以理解的是，各个装置，例如事务管理器、全局事务快照器等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

图4示出了上述实施例中所涉及的跨进程分布式事务控制系统的一种可能的结构示意图，包括：

全局事务快照器1和至少两个事务管理器2，其中，这两个事务管理器2通过通用RPC通信框架传递信息，并与不同进程上的服务一一对应。

任一事务管理器2可用于：为相应服务发起的分布式事务进行事务注册；

其中，事务注册可包括：

为分布式事务分配数据库连接引用(也即前述的第一数据库连接引用或第二数据库连接引用)，而数据库连接引用用于服务对相应的数据库执行业务逻辑。相关细节请参照图2或图3所示的203或208部分。

判断是否未开启全局事务；相关细节请参照图2或图3所示的204或209部分。

在判断出未开启全局事务时，将上述分布式事务作为全局事务中的主事务，创建全局事务上下文，通过通用RPC通信框架将创建出的全局事务上下文传递给其他事务管理器，并通过RPC通信框架接收由其他事务管理器更新的全局事务上下文。其中，创建出的全局事务上下文至少包括全局事务id和全局事务状态；相关细节请参照图2或图3所示的205和206部分。

在判断出已开启全局事务时，为上述分布式事务分配子事务id，更新通过通用RPC通信框架获取的全局事务上下文(将子事务数据库连接引用和子事务id放入全局事务上下文中)，再通过RPC通信框架将更新后的全局事务上下文传递给主事务的事务管理器。相关细节请参照图2或图3所示的步骤2010部分和2011部分。

在作为主事务对应的事务管理器时，事务管理器2还可用于：

在接收到事务提交请求(前述的第一事务提交请求)后，通过全局事务快照器1将全局事务上下文发送至消息中间件MQ，并通过通用RPC通信框架通知其他事务管理器提交事务。上述事务提交请求是服务在完成业务逻辑后发起的。相关细节请参照图2或图3所示的2012部分、2014和2015部分。

在其他事务管理器成功提交子事务后，提交主事务；相关细节请参照图2所示的2017部分。

在提交主事务成功后，通过全局事务快照器1通知MQ将全局事务上下文中的全局事务状态更改为完成；相关细节请参照图2所示的2018部分。

在作为子事务对应的事务管理器时，上述任一事务管理器2还用于：

在接收到事务提交请求(前述的第二事务提交请求)以及主事务对应的事务管理器的通知后，进行子事务提交。相关细节请参照图2或图3所示的2013部分、2016部分。

在本发明其他实施例中，主事务对应的事务管理器1还可用于：在子事务提交失败后，放弃主事务的提交。相关细节请参照图3所示的3017部分。

在本发明其他实施例中，上述所有实施例中的跨进程分布式事务控制系统还可包括监控器，用于在子事务或主事务提交失败后，根据MQ中的全局事务上下文发起针对提交成功的分布式事务的回滚。

图5示出了上述实施例中所涉及的跨进程分布式事务控制系统运行在同一计算机设备上的一种示例性结构，该计算机设备可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，计算机设备可以是台式机、便携式电脑、网络服务器、掌上电脑(Personal Digital Assistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备或有图5中类似结构的设备。本发明实施例不限定计算机设备的类型。其可包括：

总线、控制器/处理器501、存储器502、通信接口503、输入设备504和输出设备505。处理器501、存储器502、通信接口503、输入设备504和输出设备505通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

输入设备504可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入装置、触摸屏等。

输出设备505可包括允许输出信息给用户的装置，例如显示屏、打印机、扬声器等。

通信接口503可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(WLAN)等。此外，通信接口503还支持通用RPC通信框架。

控制器/处理器501可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(Network Processor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。控制器/处理器501也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。

存储器502中保存有执行本发明技术方案的程序，还可以保存有操作系统和其他应用程序。具体地，程序可以包括程序代码，并由处理器501来控制执行。程序代码包括计算机操作指令。更具体的，存储器502可以是只读存储器(read-only memory，ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器等等。

控制器/处理器501可通过执行存储器502中的代码完成图2或3中涉及的处理过程和/或用于本申请所描述的技术的其他过程。控制器/处理器501也可通过执行存储器502中的代码来实现前述全局事务快照器、事务管理器、监控器的功能。

在具体实现中，作为一种实施例，上述计算机设备可以包括多个处理器。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

在本发明其他实施例中，请参见图6，上述跨进程分布式事务控制系统运行在不同的计算机设备上。以运行在两个计算机设备为例，任一计算机设备的硬件架构可如图5所示，至少可包括网卡，处理器和内存。其中一个计算机上运行的第一事务管理器为主事务的事务管理器，在该计算机上还运行有全局事务快照器，在另一计算机上运行的第二事务管理器为子事务的事务管理器。两计算机可通过网络通信，并支持通用RPC通信框架。

两计算机设备可通过执行各自存储器中的代码来实现相互通信，并完成图2或3中涉及的处理过程和/或用于本申请所描述的技术的其他过程。

结合本发明公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于用户设备中。当然，处理器和存储介质也可以作为分立组件存在于用户设备中。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (15)

1.一种跨进程分布式事务控制方法，其特征在于，基于跨进程分布式事务控制系统，所述系统包括全局事务快照器和至少两个事务管理器，所述至少两个事务管理器之间通过远程过程调用协议RPC通信；所述方法包括：

第一事务管理器创建包括全局事务标识id和全局事务状态的全局事务上下文；所述第一事务管理器为与第一服务对应的事务管理器；所述第一服务为首先调用的服务；

所述第一事务管理器通过所述RPC将创建的全局事务上下文发送给第二事务管理器；所述第二事务管理器为所述跨进程分布式事务控制系统中除第一事务管理器的其他事务管理器；

所述第二事务管理器将第二服务发起的分布式事务作为子事务，使用子事务相关信息更新所述全局事务上下文，并通过所述RPC将更新后的全局事务上下文发送给所述第一事务管理器；所述子事务相关信息至少包括子事务id，所述第二服务为与所述第二事务管理器对应的服务；

响应于第一事务提交请求，所述第一事务管理器通过所述全局事务快照器将所述更新的全局事务上下文发送至消息中间件MQ，并通过所述RPC通知所述第二事务管理器提交子事务；所述第一事务提交请求是所述第一服务在完成业务逻辑后发起的；

响应于第二事务提交请求以及所述第一事务管理器的通知，所述第二事务管理器进行子事务提交；所述第二事务提交请求是所述第二服务在完成业务逻辑后发起的；

在所述第二事务管理器成功提交子事务后，所述第一事务管理器提交主事务；

在提交主事务成功后，所述第一事务管理器通过所述全局事务快照器通知所述MQ将所述全局事务上下文中的全局事务状态更改为完成。

2.如权利要求1所述的方法，其特征在于，其特征在于，在所述第一事务管理器创建所述全局事务上下文之前，还包括：所述第一事务管理器判断是否未开启全局事务；

所述创建包括全局事务id和全局事务状态的全局事务上下文的操作是在判断出未开启全局事务后执行的。

3.如权利要求1所述的方法，其特征在于，其特征在于，在所述第二事务管理器使用子事务相关信息更新所述全局事务上下文之前，还包括：所述第二事务管理器判断是否未开启全局事务；

所述使用子事务相关信息更新所述全局事务上下文的操作是在判断出已开启全局事务后执行的。

4.如权利要求2或3所述的方法，其特征在于，所述判断是否未开启全局事务包括：判断是否存在全局事务上下文，若存在全局事务上下文，则判断出已开启全局事务，否则，判断出未开启全局事务。

5.如权利要求2所述的方法，其特征在于，在判断出未开启全局事务时，还包括：所述第一事务管理器为所述第一服务发起的分布式事务分配主事务id；所述创建的全局事务上下文还包括所述主事务id。

6.如权利要求1所述的方法，其特征在于，还包括：在所述第二事务管理器提交子事务失败后，所述第一事务管理器放弃主事务的提交。

7.如权利要求1所述的方法，其特征在于，还包括：

在所述第一事务管理器提交失败后，根据所述MQ中的全局事务上下文发起针对提交成功的分布式事务的回滚。

8.如权利要求1所述的方法，其特征在于，还包括：

所述第一事务管理器为所述第一服务发起的分布式事务分配第一数据库连接引用；所述第一数据库连接引用用于所述第一服务对相应的数据库执行业务逻辑。

9.一种跨进程分布式事务控制系统，其特征在于，包括全局事务快照器、第一事务管理器和至少一个第二事务管理器，至少两个事务管理器之间通过远程过程调用协议RPC通信；其中，

所述第一事务管理器用于：

创建包括全局事务标识id和全局事务状态的全局事务上下文；所述第一事务管理器为与第一服务对应的事务管理器；所述第一服务为首先调用的服务；

通过所述RPC将创建的全局事务上下文发送给第二事务管理器，并通过所述RPC通信框架接收更新的全局事务上下文；所述第二事务管理器为所述跨进程分布式事务控制系统中除第一事务管理器的其他事务管理器；

响应于第一事务提交请求，所述第一事务管理器通过所述全局事务快照器将所述更新的全局事务上下文发送至消息中间件MQ，并通过所述RPC通知所述第二事务管理器提交子事务；所述第一事务提交请求是所述第一服务在完成业务逻辑后发起的；

在所述第二事务管理器成功提交子事务后，再提交主事务；

在提交主事务成功后，通过所述全局事务快照器通知所述MQ将所述全局事务上下文中的全局事务状态更改为完成；

所述第二事务管理器用于：

将第二服务发起的分布式事务作为子事务，使用子事务相关信息更新所述全局事务上下文，并通过所述RPC将更新后的全局事务上下文发送给所述第一事务管理器；所述子事务相关信息至少包括子事务id，所述第二服务为与所述第二事务管理器对应的服务；

响应于第二事务提交请求以及所述第一事务管理器的通知，所述第二事务管理器进行子事务提交；所述第二事务提交请求是所述第二服务在完成业务逻辑后发起的；

所述全局事务快照器用于在第一事务管理器的指示下对全局事务上下文进行快照，并将快照结果传递给MQ。

10.如权利要求9所述的系统，其特征在于，在创建所述全局事务上下文之前，所述第一事务管理器还用于：判断是否未开启全局事务；所述创建包括全局事务id和全局事务状态的全局事务上下文的操作是在判断出未开启全局事务后执行的。

11.如权利要求9所述的系统，其特征在于，在使用子事务相关信息更新所述全局事务上下文之前，所述第二事务管理器还用于：判断是否未开启全局事务；所述使用子事务相关信息更新所述全局事务上下文的操作是在判断出已开启全局事务后执行的。

12.如权利要求10或11所述的系统，其特征在于，在判断是否未开启全局事务的方面，所述第一或第二事务管理器具体用于：

判断是否存在全局事务上下文，若存在全局事务上下文，则判断出已开启全局事务，否则，判断出未开启全局事务。

13.如权利要求10所述的系统，其特征在于，所述第一事务管理器还用于：

在判断出未开启全局事务时，为所述第一服务发起的分布式事务分配主事务id；所述创建的全局事务上下文还包括所述主事务id。

14.如权利要求9所述的系统，其特征在于，所述第一事务管理器还用于：

在所述第二事务管理器提交子事务失败后，放弃主事务的提交。

15.如权利要求9所述的系统，其特征在于，还包括监控器，用于在所述第一事务管理器提交失败后，根据所述MQ中的全局事务上下文发起针对提交成功的分布式事务的回滚。

Images