CN110716793A - 一种分布式事务的执行方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种分布式事务的执行方法、装置、设备及存储介质，该方法包括：向各第一资源管理器发送指示提交目标事务的准备指令；如果接收到各第一资源管理器的确认信息，则向第二资源管理器发送预设指令，以指示第二资源管理器提交目标事务并在提交成功后记录事务标记；在第二资源管理器提交成功后，向第一资源管理器发送指示提交目标事务的提交指令；如果接收到任一个第一资源管理器返回的错误信息，则向各资源管理器发送指示回滚目标事务的回滚指令；每个第一资源管理器在自身处于准备提交目标事务的状态持续预设时长时，查询是否存在对应事务标记，如果存在则提交目标事务，否则回滚目标事务。有效保证了各资源管理器的数据一致性。

Description

一种分布式事务的执行方法、装置、设备及存储介质

技术领域

本申请涉及数据库管理***技术领域，更具体地说，涉及一种分布式事务的执行方法、装置、设备及存储介质。

背景技术

在数据库管理***(DBMS，Database Management System)实现分布式XA事务的执行过程中，可能出现由于某种故障导致处理分布式XA事务的某个或者某多个资源管理器，在准备提交分布式XA事务或者提交分布式XA事务或者回滚XA事务时出现异常的情况，进而无法保证执行分布式XA事务的各个资源管理器的数据一致性。

申请内容

本申请的目的是提供一种分布式事务的执行方法、装置、设备及存储介质，能够保证执行分布式事务的各个资源管理器的数据一致性。

为实现上述目的，一方面，本申请提供了一种分布式事务的执行方法，包括：

向资源管理器集群中各第一资源管理器发送准备指令，以指示对应的所述第一资源管理器进入准备提交目标事务的状态；其中，所述资源管理器集群由第二资源管理器及至少一个所述第一资源管理器构成；

如果接收到各所述第一资源管理器返回的确认信息，则向所述第二资源管理器发送预设指令，以指示所述第二资源管理器提交所述目标事务并在提交成功后记录所述目标事务对应的事务标记；在所述第二资源管理器提交成功后，向各所述第一资源管理器发送指示提交所述目标事务的提交指令；

如果接收到任一个所述第一资源管理器返回的错误信息，则向所述资源管理器集群中各资源管理器发送指示回滚所述目标事务的回滚指令；

其中，每个所述第一资源管理器均在自身处于准备提交所述目标事务的状态持续预设时长时，查询是否存在所述目标事务对应事务标记，如果存在则提交所述目标事务，否则，则回滚所述目标事务。

又一方面，本申请还提供了一种分布式事务的执行装置，包括：

第一发送模块，用于：向资源管理器集群中各第一资源管理器发送准备指令，以指示对应的所述第一资源管理器进入准备提交目标事务的状态；其中，所述资源管理器集群由第二资源管理器及至少一个所述第一资源管理器构成；

第二发送模块，用于：如果接收到各所述第一资源管理器返回的确认信息，则向所述第二资源管理器发送预设指令，以指示所述第二资源管理器提交所述目标事务并在提交成功后记录所述目标事务对应的事务标记；在所述第二资源管理器提交成功后，向各所述第一资源管理器发送指示提交所述目标事务的提交指令；

第三发送模块，用于：如果接收到任一个所述第一资源管理器返回的错误信息，则向所述资源管理器集群中各资源管理器发送指示回滚所述目标事务的回滚指令；

其中，每个所述第一资源管理器均在自身处于准备提交所述目标事务的状态持续预设时长时，查询是否存在所述目标事务对应事务标记，如果存在则提交所述目标事务，否则，则回滚所述目标事务。

又一方面，本申请还提供了一种分布式事务的执行设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现前述分布式事务的执行方法的步骤。

又一方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述分布式事务的执行方法的步骤。

本申请公开的技术方案中，向资源管理器集群中各第一资源管理器发送准备提交目标事务的准备指令，在各第一资源管理器返回确认信息后，向第二资源管理器发送预设指令，以指示第二资源管理器对目标事务进行提交并在提交成功后记录目标事务的事务标记，并在第二资源管理器提交成功后为实现各资源管理器的数据一致性，向各第一资源管理器发送指示提交目标事务的指令；在任一第一资源管理器返回错误信息后，为保证各资源管理器的数据一致性，向各资源管理器发送回滚目标事务的指令；同时，各第一资源管理器会在自身处于准备提交目标事务的状态持续预设时长时查询是否记录有目标事务对应事务标记，如果有则提交目标事务，否则则回滚目标事务。可见，本申请通过预设指令将第二资源管理器的两阶段提交退化为一阶段提交，具体是使得第二资源管理器由需要分别执行准备指令及提交指令转换为仅需执行预设指令实现事务提交及标记记录，减少了资源管理器及事务管理器之间的交互，简化了事务执行流程；并且，在第一资源管理器中的目标事务成为处于准备提交的状态持续预设时长的悬挂事务时，仅需通过查询是否记录有事务标记即可确定目标事务进行提交或者回滚，从而在第二资源管理器提交目标事务成功时对成为悬挂事务的目标事务也进行提交，在第二资源管理器无法实现目标事务提交时对成为悬挂事务的目标事务进行回滚，有效保证了各资源管理器中数据的一致性。

附图说明

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

图1为本申请实施例提供的一种分布式事务的执行方法所适用的***的组成架构图；

图2为本申请实施例提供的一种分布式事务的执行方法的第一种流程图；

图3为本申请实施例提供的一种分布式事务的执行方法中事务管理器将事务转换为分布式XA事务到资源管理器的流程示意图；

图4为本申请实施例提供的一种分布式事务的执行方法中向各第一资源发送准备指令及提交指令、向第二资源管理器发送预设指令的流程示意图；

图5为本申请实施例提供的一种分布式事务的执行方法中第一资源管理器实现悬挂事务恢复功能的流程图；

图6为本申请实施例提供的一种分布式事务的执行方法的第二种流程图；

图7为本申请实施例提供的一种分布式事务的执行方法的第三种流程图；

图8为本申请实施例提供的一种分布式事务的执行方法的第四种流程图；

图9为本申请实施例提供的一种分布式事务的执行方法在具体应用场景中的交互图；

图10为本申请实施例提供的一种分布式事务的执行装置的结构示意图；

图11为本申请实施例提供的一种分布式事务的执行设备的结构示意图。

具体实施方式

事务是数据库管理***执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。当事务被提交给数据库管理***，则数据库管理***需要确保该事务中的所有操作都成功完成且其结果被永久保存在数据库中，如果事务中有的操作没有成功完成，则事务中的所有操作都需要被回滚，回到事务执行前的状态；同时该事务对数据库或者其他事务的执行无影响，可以认为所有的事务都在独立的运行。

分布式事务就是在分布式环境下运行的事务，对于分布式事务来说，事务的每个操作步骤是运行在不同节点(机器)上的服务的；分布式事务处理的关键是必须有一种方法可以获知事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)。具体来说，在具有分布式环境的分布式***中，每个节点虽然可以获知自己的操作是成功或者失败，却无法获知其他节点的操作的成功或失败；因此，当一个事务跨越多个节点时，为了保持事务的ACID(atomicity、consistency、isolation、durability，原子性、一致性、隔离性、持久性)特性，需要引入一个作为协调者的组件来统一掌控所有参与者节点的操作结果并最终指示这些节点是否要把操作结果进行真正的提交，也即实现两阶段提交(2PC)。两阶段提交(2PC)的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

XA协议是资源管理器(RM，Resource Manager)与事务管理器(TM,TransactionManager)的接口标准，XA协议的XA接口提供资源管理器与事务管理器之间进行通信的标准接口，XA协议采用两阶段提交的方式来管理分布式事务，此时可称分布式事务为分布式XA事务(下文中所涉及的事务、XA事务均为分布式XA事务)。其中，事务管理器能够将普通事务转换为分布式XA事务与资源管理器进行交互；具体来说，事务管理器接收到应用(或应用层)开启事务的行为时，将应用开启的事务转换为分布式XA事务下发到各个资源管理器中，以发送相应指令的方式控制各个资源管理器对接收到的分布式XA事务进行开始执行、结束执行、准备提交、提交/回滚的操作。在实际执行过程中，TM和RM交互的各个阶段都可能出现软硬件异常，其他步骤在出现异常时均可以对对应的分布式XA事务直接进行回滚，但是在准备提交、提交、回滚时如果出现异常，比如事务管理器或者资源管理器出现节点故障等，则处于准备提交的状态的资源管理器需要获知其他资源管理器是如何处理该分布式XA事务的，才能够确定需要当前准备提交的状态的分布式XA事务进行提交还是回滚。

现有的解决上述问题的技术方案，一种是将事务管理器中每一步事务操作都记录操作日志，这样在故障发生时可以通过操作日志判断当前事务该有的状态(提交或回滚)，但是这会导致记录过多的操作日志，极大的损失事务管理器的性能(达80％以上)，且如果事务管理器的机器坏死，则无法实现上述事务状态的判断，进而无法实现各个资源管理器的数据一致性。另一种是在通过异步线程，在资源管理器准备提交之后、提交之前将对应的操作日志写入至资源管理器中，这样在故障发生时通过资源管理器中的操作日志来判断当前事务该有的状态，但是外部线程会损失一部分性能，且如果外部线程执行失败，则会导致当前事务处于一个可提交也可回滚的中间语义状态，进而无法实现各个资源管理器的数据一致性。

鉴于目前所存在的上述问题，本申请提出了执行分布式事务的技术方案，通过该技术方案，能够在保证性能的同时，保证各个资源管理器的数据一致性。

为了便于理解，下面对本申请的技术方案所适用的***架构进行介绍。参见图1，其示出了本申请的一种分布式事务的执行方法所适用的***的组成架构。

如图1所示，本申请的分布式事务的执行方法所适用的***的一种组成架构可以包括TM终端10、RM终端20及应用终端30，其中，RM终端20的数量为至少两个，图1以RM终端20的数量为3个的实现方式进行展示。

其中，TM终端10、RM终端20及应用终端30均可以为计算机设备、智能终端或者其他能够利用计算机程序实现的终端，而TM终端10、RM终端20及应用终端30可以是相同的终端，也可以是不同的终端，在此不做具体限定；图1以TM终端10、RM终端20均为计算机设备，而应用终端30为智能终端的实现方式进行展示。

对于TM终端10，在一种可能的情况中，TM终端10可以包括TM，TM可以分别与RM终端20及应用终端30进行数据交互，具体来说，TM在接收应用终端30开启事务的行为时，可以将应用终端30开启的事务转换为分布式事务，设置对应的事务标记xid，将分布式事务分发到各个RM终端20中，向各个RM终端发送相应的指令，以控制实现分布式事务的执行，并在执行完成后将相应的执行结果返回给应用终端30。

在一种可能的情况中，TM终端10可以包括监控程序，监控程序可以监控TM实现相应的功能；在TM实现事务转换及与其他终端进行数据交互的过程中，监控程序实时监测TM进行的操作，以在事务转换失败或者数据发送失败或者数据接收失败等时输出对应的提示信息，以便工作人员在得知该提示信息后对TM进行相应的修复操作。

在一种可能的情况中，TM终端10还可以包括人机交互界面，该人机交互界面可以用于上述提示信息向外界的展示，还可以供外界工作人员在人机交互界面上输入修复操作相应的指令，以在该指令的控制下实现TM的修复。

对于RM终端20，RM终端20可以包括RM，RM用于实现分布式事务的执行，具体来说，RM可以在接收到TM终端分发的分布式事务后，在TM终端发送的各项指令的指示下执行接收的分布式事务。

在一种可能的情况中，RM终端可以包括线程池，线程池中可以包括多个用于执行分布式事务的线程，从而在接收到TM终端分配的多个分布式事务后，能够由线程池中获取多个线程，进而利用这多个线程并行实现分布式事务的执行，提高事务执行效率。

对于应用终端30，应用终端30可以包括至少一个应用，应用可以开启事务，进而控制TM终端实现事务的执行。

在一种可能的情况中，应用终端30可以包括指令响应程序，指令响应程序可以在接收到外界输入的相应指令后实现对应操作，此处外界输入的相应指令可以为开启或者关闭应用终端30中包含的某应用的指令，也可以为开启或者关闭应用终端30中包含的某应用的指令，还可以为安装或者卸载应用终端30中包含的某应用的指令。

请参阅图2，其示出了本申请实施例提供的一种分布式事务的执行方法的流程图，该执行方法可以包括：

S101：向资源管理器集群中各第一资源管理器发送准备指令，以指示对应的第一资源管理器进入准备提交目标事务的状态(或者说目标事务进入准备提交的状态)；其中，资源管理器集群由第二资源管理器及至少一个第一资源管理器构成；每个第一资源管理器均在自身处于准备提交目标事务的状态持续预设时长时，查询是否存在目标事务对应事务标记，如果存在则提交目标事务，否则，则回滚目标事务。

本申请实施例提供的一种分布式事务的执行方法的执行主体可以为对应的执行装置，而该执行装置可以设置于事务管理器中，因此本申请实施例提供的一种分布式事务的执行方法的执行主体可以为事务管理器；以下在需要时以执行主体为事务管理器进行说明。

分布式事务涉及到事务管理器及多个资源管理器，其中，第一资源管理器及第二资源管理器均为被分配有分布式事务的资源管理器，而分布式事务具体可以为分布式XA事务，也可以为其他需要利用多个资源管理器进行执行的分布式事务，本申请各实施例中均以分布式事务为分布式XA事务进行具体说明；本实施例中事务管理器可以使用TenDBCluster(针对游戏场景开发维护的一个分布式数据库解决方案)，而资源管理器可以使用TenDB(针对游戏场景开发维护的一个MySQL分支版本)；MySQL对应执行分布式XA事务的XA指令可以包括(其中，xid表示事务的标记)：

XA START xid：开启一个事务，并将事务置于ACTIVE状态，此后执行的SQL语句都将置于该事务中；

XA END xid：对ACTIVRE状态的事务在执行一系列DML后，执行XA END xid，以将事务置于IDLE状态，该IDLE状态表示事务内的SQL语句对应SQL操作完成；

XA PREPARE xid：在事务内SQL操作完成后，通过XA PREPARE xid进行将事务提交的准备工作，事务置于PREPARED状态；

XA COMMIT xid：在所有的资源管理器都处于PREPARE状态后，分别执行XA COMMITxid，让事务最终提交，完成持久化；

XA ROLLBACK xid：在XA PREPARE xid存在异常或者主动放弃事务时，执行XAROLLBACK xid，让事务回滚。

XA RECOVER:查看MySQL中存在的PREPARED状态的事务。

对应的，假设资源管理器集群中挂载有两个资源管理器(分别表示为RM1及RM2)，分布式XA事务在事务管理器上执行，则事务管理器将其转换为分布式XA事务到资源管理器的流程可以如图3所示(假设各操作执行返回的均为正确的信息，因此流程图中无事务管理器对应用的信息传递，也无资源管理器对事务管理器的信息传递)，具体可以包括：

在应用(Application)开启(begin)事务时，TM将该事务转换为分布式XA事务(目标事务,事务标记为xid)，将目标事务分配至RM1及RM2中进行执行；向RM1及RM2分别发送XASTART xid以指示开始执行目标事务；接收应用发送的操作指令(insert into t1(c1)values(1)；update t2 set c2＝3 where c1＝2；),并将对应的操作指令分别分配至RM1及RM2中执行(RM1:insert into xxx；RM2:update t2 xxx)；TM接收应用发送的指示提交(commit)的指令，向RM1及RM2分别发送XA END xid及XA PREPARE xid；如果RM1及RM2均返回确认信息，则向RM1及RM2分别发送XA COMMIT xid，以指示RM1及RM2提交目标事务。

在实际应用中，一个应用普通的事务可以如下：

begin；

insert into t1(c1,c2)values(1,2)；

update t2 set c2＝3 where c1＝2；

commit；

在处理应用启动的事务时，事务管理器能够将普通事务转换为分布式XA事务与资源管理器交互，如图2所示，事务管理器接收到应用开启事务的行为时，设置XA事务标记xid；在接收到应用的DML请求时，事务管理器发送XA START xid到执行分布式XA事务的每个资源管理器中，并在对应的资源管理器中执行DML请求；事务管理器接收到应用的提交事务请求时，依次对各资源管理器执行XA END xid及XA PREPARE xid；如果执行分布式XA事务都正常，事务管理器向各资源管理器节点执行XA COMMIT xid；如果存在返回错误，则事务管理器向各个资源管理器执行XA ROLLBACK xid。

本实施例中资源管理器集群包括多个(大于1个)资源管理器，资源管理器集群中的资源管理器均为第一资源管理器或第二资源管理器，第一资源管理器和第二资源管理器可以为相同的资源管理器，区别在于第一资源管理器及第二资源管理器接收并执行的事务管理器下发的指令有所不同。事务管理器向资源管理器集群中各资源管理器依次下发XASTART xid、XA END xid后且不存在异常时，也即在两阶段提交的第一个阶段最后(事务管理器即对应两阶段提交中的协调者，资源管理器即对应两阶段提交中的参与者)，向各第一资源管理器发送准备指令(XA PREPARE xid)，接收到准备指令的第一资源管理器进入准备提交目标事务的状态，其中，目标事务可以为任一需要执行的分布式XA事务。

S102：如果接收到各第一资源管理器返回的确认信息，则向第二资源管理器发送预设指令，以指示第二资源管理器提交目标事务并在提交成功后记录目标事务对应的事务标记；在第二资源管理器提交成功后，向各第一资源管理器发送指示提交目标事务的提交指令。

事务管理器在向各第一资源管理器发送准备指令之后，各第一资源管理器会在该指令的触发下进行准备提交的工作，并在进行准备提交的工作完成后进入准备提交目标事务的状态，如果准备提交的工作完成均正常，则向事务管理器返回确认信息，事务管理器如果接收到各第一资源管理器返回的确认信息，则表示由各第一资源管理器返回的信息认为目标事务可以提交；此时向第二资源管理器发送预设指令(XA COMMIT xid ONE PHASE)，通过该预设指令将第二资源管理器应实现的两阶段提交退化为一阶段提交，也即将需要向第二资源管理器下发的准备指令及提交指令转换为预设指令，使得第二资源管理器在接收到预设指令后，直接对分布式XA事务进行提交，如果第二资源管理器对分布式XA事务进行提交的结果为提交成功，则记录目标事务对应的事务标记，具体可以是第二资源管理器在本地存储中记录目标事务对应的事务标记，如果第二资源管理器对分布式XA事务进行提交的结果为提交失败，则无需记录目标事务对应的事务标记。

另外，第二资源管理器在提交目标事务成功后可以向事务管理器返回提交成功的信息，或者事务管理器可以通过其他根据实际需要设定的方式获知到第二资源管理器提交目标事务成功的信息，均在本申请的保护范围之内。事务管理器获知第二资源管理器对目标事务提交成功后，向各第一资源管理器发送提交指令(XA COMMIT xid)，以使得各第一资源管理器接收到提交指令后对目标事务进行提交，从而使得资源管理器集群中各资源管理器均对目标事务进行提交，实现数据的一致性。

假设目标事务涉及的资源管理器的数量为四个，且各目标事务返回的均为确认信息，则本实施例中向各第一资源发送准备指令及提交指令、向第二资源管理器发送预设指令的流程可以如图4所示，其中，每个指令前面的数字表示指令的执行顺序，也即先执行1.1至1.4，然后执行1.1至1.3。

S103：如果接收到任一个第一资源管理器返回的错误信息，则向资源管理器集群中各资源管理器发送指示回滚目标事务的回滚指令。

事务管理器在向各第一资源管理器发送准备指令之后，各第一资源管理器会在该指令的触发下进行准备提交的工作，并在进行准备提交的工作完成后进入准备提交目标事务的状态，如果准备提交的工作存在异常，则向事务管理器返回错误信息；事务管理器如果接收到至少一个第一资源管理器返回的错误信息，则表示由第一资源管理器返回的信息认为目标事务需要进行回滚，为了保持资源管理器集群中各资源管理器的数据一致性，需要向资源管理器集群中所有的资源管理器发送回滚指令(XA ROLLBACK)，各资源管理器接收到回滚指令后对目标事务进行回滚，以回到各资源管理器执行目标事务之前的状态。

针对“每个第一资源管理器均在自身处于准备提交目标事务的状态持续预设时长时，查询是否存在目标事务对应事务标记，如果存在则提交目标事务，否则，则回滚目标事务”，需要说明的是，每个第一资源管理器均具备悬挂事务恢复功能，其中，悬挂事务为长时间处于准备提交的状态的事务，本实施例中设定处于准备提交事务的状态持续预设时长及超过预设时长时该处于准备提交的事务则为悬挂事务(预设时长可以根据实际需要进行设定，如30秒或者1分钟等)，通常这种情况是由于TM或者RM出现节点故障导致的，包括事务管理器未成功向资源管理器发送提交指令或者回滚指令、资源管理器未成功接收到事务管理器发送的提交指令或者回滚指令、资源管理器对事务进行提交或者回滚未成功等；此时为了保证各个资源管理器对于同一事务的数据一致性，则需要对悬挂事务进行相应的处理。具体来说，本实施例中各资源管理器可以实时或者定时查询自身是否存在准备提交的状态持续预设时长的事务，或者说各资源管理器可以实时或者定时查询自身是否处于准备提交某事务的状态持续预设时长，如果是，则需要对具有上述特点的事务、即悬挂事务进行处理。在确定出目标事务为悬挂事务后，可以查询是否记录有目标事务对应的事务标记，如果是，则说明各第一资源管理器响应准备指令返回给事务管理器的信息均为确认信息，且第二资源管理器提交目标事务成功，因此为了保证数据一致性，则需要对悬挂事务进行提交；如果否，则说明可能是各第一资源管理器响应准备指令返回给事务管理器的信息存在错误信息，可能是各第一资源管理器响应准备指令返回给事务管理器的信息均为确认信息，且第二资源管理器提交目标事务失败，也可能是其他由于TM或者RM出现节点故障导致的异常情况，因此为了保证数据一致性，则需要对悬挂事务进行回滚。

需要说明的是，本实施例中各第一资源管理器具备的悬挂事务恢复功能可以由部署在各第一资源管理器上的后台线程实现，通过后台线程探测所属的资源管理器中是否存在悬挂事务，只要探测到存在，则通过查询是否记录有悬挂事务对应的事务标记，确定对悬挂事务进行提交还是回滚。另外，第一资源管理器实现悬挂事务恢复功能的流程图可以如图5所示。

本申请公开的技术方案中，向资源管理器集群中各第一资源管理器发送准备提交目标事务的准备指令，在各第一资源管理器返回确认信息后，向第二资源管理器发送预设指令，以指示第二资源管理器对目标事务进行提交并在提交成功后记录目标事务的事务标记，并在第二资源管理器提交成功后为实现各资源管理器的数据一致性，向各第一资源管理器发送指示提交目标事务的指令；在任一第一资源管理器返回错误信息后，为保证各资源管理器的数据一致性，向各资源管理器发送回滚目标事务的指令；同时，各第一资源管理器会在自身处于准备提交目标事务的状态持续预设时长时查询是否记录有目标事务对应事务标记，如果有则提交目标事务，否则则回滚目标事务。可见，本申请通过预设指令将第二资源管理器的两阶段提交退化为一阶段提交，具体是使得第二资源管理器由需要分别执行准备指令及提交指令转换为仅需执行预设指令实现事务提交及标记记录，减少了资源管理器及事务管理器之间的交互，简化了事务执行流程；并且，在第一资源管理器中的目标事务成为处于准备提交的状态持续预设时长的悬挂事务时，仅需通过查询是否记录有事务标记即可确定目标事务进行提交或者回滚，从而在第二资源管理器提交目标事务成功时对成为悬挂事务的目标事务也进行提交，在第二资源管理器无法实现目标事务提交时对成为悬挂事务的目标事务进行回滚，有效保证了各资源管理器中数据的一致性；同时，本申请没有引入异步线程，也无需记录每一步事务操作的操作日志，因此保证了分布式事务的执行性能，并且避免了因事务管理器的机器坏死或者外部线程执行失败导致的无法实现各个资源管理器数据一致性的情况。

在一种具体实施方式中，本申请实施例提供的一种分布式事务的执行方法的流程图可以如图6所示，具体可以包括：

S104：由资源管理器集群包含的资源管理器中随机选取一个资源管理器作为第二资源管理器，确定资源管理器集群中除第二资源管理器之外的其他资源管理器均为第一资源管理器。

需要说明的是，本申请的各实施例中第二资源管理器的数量均可以为一个，当然也可以根据实际需要进行其他设置，均在本申请的保护范围之内。

S105：为各个第一资源管理器设置对应的编号。

对应的，步骤S101中向资源管理器集群中各第一资源管理器发送准备指令的步骤可以包括：

按照设置的编号的顺序，依次向资源管理器集群中各第一资源管理器发送准备指令。

本实施例中，第一资源管理器及第二资源管理器的确定可以以随机的方式实现，也即由资源管理器集群中随机选取一个资源管理器作为第二资源管理器，其他的资源管理器则为第一资源管理器；这种情况下，对每个需要执行的分布式XA事务均可以通过上述方式实现第一资源管理器及第二资源管理器的确定，那么不同的分布式XA事务对应的资源管理器的划分可能不同，从而使得对于资源管理器的划分更加灵活。由于第一资源管理器及第二资源管理器的确定是随机的，因此在第一资源管理器需要查询事务标记时并不能确定事务标记所在的资源管理器，因此其可以依次在每个事务管理器中实现事务标记的查询，从而确定是否记录有对应的事务标记。

在此基础上，可以为各个第一资源管理器设置对应的编号，具体可以根据实际需要进行设置，如将每个第一资源管理器分别设置为RM1至RMn(n为资源管理器的数量)；从而在向各第一资源管理器发送准备指令时，则可以按照为第一资源管理器设置的编号由大到小或者由小到大的顺序依次向各第一资源管理器发送准备指令，从而能够避免在实现准备指令的下发时的漏发送或重复发送；而由于第二资源管理器只有一个，因此为各个第一资源管理器设置对应的编号后，即可确定出没有编号的即为第二资源管理器进而向第二资源管理器发送相应的指令；当然也可以为第二资源管理器设置不同于第一资源管理器的编号，进而直接利用该编号定位到第二资源管理器实现相应指令的发送；均在本申请的保护范围之内。另外，还可以按照编号的顺序实现其他需要向第一资源管理器发送的指令的发送，如向第一资源管理器实现开始指令、结束指令、提交指令、回滚指令等，从而进一步避免指令的漏发送或重复发送。

在另一种具体实施方式中，本申请实施例提供的一种分布式事务的执行方法的流程图可以如图7所示，具体可以包括：

S106：调取预先设置的编号记录信息；其中，编号记录信息包括预先为资源管理器集群中各个资源管理器设置的编号。

对应的，步骤S101中向资源管理器集群中各第一资源管理器发送准备指令的步骤可以包括：

按照编号记录信息中记录的编号的顺序，依次向资源管理器集群中预先设定的各第一资源管理器发送准备指令。

本实施例中，第一资源管理器及第二资源管理器可以是预先确定好的，由此，对于不同的事务对应的第一资源管理器及第二资源管理器相同，这样在第一资源管理器需要查询事务标记时则可以直接到唯一的第二资源管理器查询，提高了悬挂事务的处理效率。并且，还可以预先为每个资源管理器设置对应的编号，并得到表示资源管理器及对应编号的对应关系的编号记录信息，该编号记录信息可以记录在预先设置的信息表中，以便于管理及查询；对应的，在向各第一资源管理器发送准备指令时，则可以按照为编号记录信息中全部第一资源管理器的编号由大到小或者由小到大的顺序依次向各第一资源管理器发送准备指令，从而能够避免在实现准备指令的下发时第一资源管理器的遗漏或重复；另外，还可以按照编号的顺序实现其他需要向第一资源管理器发送的指令的发送，如向第一资源管理器实现开始指令、结束指令、提交指令、回滚指令等，从而进一步避免指令的漏发送或重复发送。

在又一种具体实施方式中，本申请实施例提供的一种分布式事务的执行方法的流程图可以如图8所示，具体可以包括：

S201：第二资源管理器记录目标事务对应的事务标记之前，第二资源管理器调取本地预先设置的提交日志表。

由于在事务管理器中引入了预设指令，因此需要在第二资源管理器中实现该预设指令对应的功能，也即第二资源管理器对目标事务进行提交并且需要在将目标事务提交成功后将目标事务的事务标记进行记录，具体可以是记录在提交日志表的提交日志(xa_commit_log)中。从而通过提交日志表的设置，不仅方便了对于提交日志的存储，也便于实现对提交日志的管理和查询。

S202：在第二资源管理器提交目标事务成功后，第二资源管理器将目标事务对应的事务标记记录至提交日志表中。

S203：在第二资源管理器提交目标事务成功后，第二资源管理器识别当前时刻的时间作为目标事务的提交时间，将提交时间记录至提交日志表中与目标事务的事务标记对应的位置处。

本实施例中在记录事务标记时还可以同时记录提交目标事务成功的时间，具体可以是在第二资源管理器提交目标事务成功后，记录当前时刻的时间作为目标事务的提交时间，进而将目标事务的事务标记及提交时间均记录至提交日志表中，以使得在需要进行相应信息查询时，仅需调取提交日志表即可获知成功提交的事务及成功提交该事务的时间。另外，可以是如本实施例所示在将目标事务对应事务标记记录至提交日志表后，再将目标事务的提交时间提交至与目标事务的事务标记对应位置处，以实现两者对应关系的标识；也可以同时将目标事务的事务标记及提交时间记录至提交日志表中的相应位置处，以提高信息记录的效率；当然还可以根据实际需要进行其他设定，均在本申请的保护范围之内，在一种具体示例中，分别记录日志标记及对应提交日志可以如下所示：

在又一种具体实施方式中，本申请实施例提供的一种分布式事务的执行方法，还可以包括：

第一资源管理器在接收到准备指令后，记录当前时刻的时间作为对应的第一资源管理器进入准备提交目标事务的状态的开始时间；

对应的，第一资源管理器判断自身处于准备提交目标事务的状态是否持续预设时长，可以包括：

第一资源管理器实时判断由记录的开始时间至当前时刻经过的时间段是否达到预设时长。

需要说明的是，为保证出现异常时悬挂事务能够自动恢复，本申请中定义某事务处于准备提交的状态持续预设时长时为需要自动恢复的悬挂事务(进入准备提交目标事务的状态即为目标事务进入准备提交的状态)；而为了以一种有效且简便的方式确定目标事务是否为悬挂事务，本实施例中可以在第一资源管理器接收到准备指令后，记录当前时刻的时间作为目标事务准备提交的状态的开始时间至本地存储，进而仅需实时判断由记录的开始时刻至当前时刻经过的时间是否达到预设时长即可确定出目标事务处于准备提交的状态是否持续预设时长。在另一种情况中，为了减少资源浪费，还可以是定时判断由记录的开始时刻至当前时刻经过的时间是否达到预设时长。在一种具体示例中，在第一资源管理器中增加某任务的开始时间可以如下所示：

在又一种具体实施方式中，本申请实施例提供的一种分布式事务的执行方法，还可以包括：

如果第一资源管理器在自身处于准备提交目标事务的状态持续预设时长时，提交或者回滚目标事务失败，则返回执行提交或者回滚目标事务的步骤，直至提交或者回滚目标事务成功为止。

需要说明的是，在目标事务处于准备提交的状态超过预设时长时目标事务也属于悬挂事务，因此为了进一步保证各资源管理器中数据的一致性，本实施例中在第一资源管理器处于准备提交目标事务的状态持续预设时长时，不论是提交还是回滚目标事务，只要是结果为失败，则直接返回执行或者经过预先根据实际需要设定的一定时间间隔后返回执行提交或者回滚目标事务的步骤，也即如果提交目标事务失败，则返回执行的为提交目标事务的步骤，如果回滚目标事务失败，则返回执行的为回滚目标事务的步骤；直至提交或者回滚目标事务成功为止。

另外，定义事务在事务管理器上执行时有三种返回给应用的返回结果，分别是成功SUCCESS、失败FAILURE及超时TIMEOUT；其中，成功表示事务执行过程都正常，最终相关的资源管理器都执行提交指令；失败表示事务执行过程中出现预期的错误，最终相关的资源管理器都执行回滚指令；超时表示事务执行过程中出现非预期的异常(如软硬件故障等)，此时事务可能处于一个非一致性的状态，需要应用过一段时间后再查询事务是成功还是失败。从而通过这种方式使得应用能够直接获知到事务的执行情况。

为了便于理解，请参考图9，结合本方案的一种应用场景进行介绍，下面以事务管理器为TenDB Cluster、资源管理器为TenDB且应用为游戏应用作为应用场景说明分布式XA事务的执行过程。其中，假设RM1表示第一资源管理器，RM2表示第二资源管理器，不对第一资源管理器的数量进行限制；并且假设目标事务进入准备提交状态之前均正常。

TenDB Cluster在游戏应用开启事务时，将该事务转换为分布式XA事务(目标事务,事务标记为xid)，将目标事务分配至RM1及RM2中进行执行；向各TenDB分别发送XASTART xid以指示开始执行目标事务；接收游戏应用发送的操作指令(insert into t1(c1)values(1)；update t2 set c2＝3 where c1＝2；),并将对应的指令分配至各TenDB中执行(RM1:insert into xxx；RM2:update t2 xxx)；TenDB Cluster接收游戏应用发送的指示提交的指令，向各TenDB发送XA END xid，向RM1发送XA PREPARE xid；如果RM1返回确认信息，则向RM2发送XA COMMIT xid ONE PHASE，以指示RM2如果提交目标事务成功则将对应事务标记记录至本地的日志提交表中；并在RM2提交成功后，向RM1发送XA COMMIT xid；如果RM1返回错误信息，则向各TenDB均发送XA ROLLBACK xid。另外，RM1会在目标事务处于准备提交的状态持续30秒时，查询RM2中是否存在目标事务的事务标记，如果查询到则提交目标事务，否则则回滚目标事务。

本申请通过各第一资源管理器基于准备指令返回确认信息后，让第二资源管理器执行XA COMMIT xid ONE PHASE WITH LOG，访原子操作保证在事务提交成功时一定能够记录对应的事务标记在第二资源管理器中，事务提交失败则不记录。部署在第一资源管理器中的后台线程查询当前准备提交状态持续预设时长的悬挂事务并通过查询悬挂事务对应的事务标记，从而自动裁定对悬挂事务进行提交或者回滚，从而优化XA分发流程，高效恢复悬挂的分布式XA事务，保证异常场景下RM数据最终一致性要求。

本申请实施例还提供了一种分布式事务的执行装置，如图10所示，可以包括：

第一发送模块111，用于：向资源管理器集群中各第一资源管理器发送准备指令，以指示对应的第一资源管理器进入准备提交目标事务的状态；其中，资源管理器集群由第二资源管理器及至少一个第一资源管理器构成；

第二发送模块112，用于：如果接收到各第一资源管理器返回的确认信息，则向第二资源管理器发送预设指令，以指示第二资源管理器提交目标事务并在提交成功后记录目标事务对应的事务标记；在第二资源管理器提交成功后，向各第一资源管理器发送指示提交目标事务的提交指令；

第三发送模块113，用于：如果接收到任一个第一资源管理器返回的错误信息，则向资源管理器集群中各资源管理器发送指示回滚目标事务的回滚指令；

其中，每个第一资源管理器均在自身处于准备提交目标事务的状态持续预设时长时，查询是否存在目标事务对应事务标记，如果存在则提交目标事务，否则，则回滚目标事务。

在一种可能实现方式中，还可以包括：

设置模块，用于：向资源管理器集群中各第一资源管理器发送准备指令之前，由资源管理器集群包含的资源管理器中随机选取一个资源管理器作为第二资源管理器，确定资源管理器集群中除第二资源管理器之外的其他资源管理器均为第一资源管理器；为各个第一资源管理器设置对应的编号；

对应的，第一发送模块可以包括：

第一发送单元，用于：按照设置的编号的顺序，依次向资源管理器集群中各第一资源管理器发送准备指令。

在另一种可能实现方式中，还可以包括：

调取模块，用于：向资源管理器集群中各第一资源管理器发送准备指令之前，调取预先设置的编号记录信息；其中，编号记录信息包括预先为资源管理器集群中各个资源管理器设置的编号；

对应的，第一发送模块可以包括：

第二发送单元，用于：按照编号记录信息中记录的编号的顺序，依次向资源管理器集群中预先设定的各第一资源管理器发送准备指令。

进一步的，本申请实施例还提供了一种分布式事务的执行设备，可以包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现前述任一实施例公开的分布式事务的执行方法的步骤。

具体来说，该执行设备可以是如图11所示的终端40，图11是根据一示例性实施例示出的执行设备的结构图，图中的内容不能被认为是对本申请的使用范围的任何限制。

图11为本申请实施例提供的一种执行设备的结构示意图，该终端40具体可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。

通常，本实施例中的终端40包括有：处理器41和存储器42。

其中，处理器41可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器41可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器41也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器41可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器41还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器42可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器42还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器42至少用于存储以下计算机程序421，其中，该计算机程序被处理器41执行时，能够实现前述任一实施例公开的分布式事务的执行方法中的相关步骤。另外，存储器42所存储的资源还可以包括操作***422和数据423等，存储方式可以是短暂存储或者永久存储。其中，操作***422可以包括Windows、Unix、Linux等。数据423可以包括但不限于测试指令数据、用户身份数据等。

在一些实施例中，终端40还可包括有显示屏43、输入输出接口44、通信接口45、传感器46、电源47以及通信总线48。

本领域技术人员可以理解，图11中示出的结构并不构成对终端40的限定，可以包括比图示更多或更少的组件。

进一步的，本申请实施例还公开了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如前述任一实施例公开的分布式事务的执行方法的步骤。

需要指出的是，上述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

以上对本申请所提供的一种分布式事务的执行方法、装置、设备及存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种分布式事务的执行方法，其特征在于，包括：

向资源管理器集群中各第一资源管理器发送准备指令，以指示对应的所述第一资源管理器进入准备提交目标事务的状态；其中，所述资源管理器集群由第二资源管理器及至少一个所述第一资源管理器构成；

如果接收到各所述第一资源管理器返回的确认信息，则向所述第二资源管理器发送预设指令，以指示所述第二资源管理器提交所述目标事务并在提交成功后记录所述目标事务对应的事务标记；在所述第二资源管理器提交成功后，向各所述第一资源管理器发送指示提交所述目标事务的提交指令；

如果接收到任一个所述第一资源管理器返回的错误信息，则向所述资源管理器集群中各资源管理器发送指示回滚所述目标事务的回滚指令；

其中，每个所述第一资源管理器均在自身处于准备提交所述目标事务的状态持续预设时长时，查询是否存在所述目标事务对应事务标记，如果存在则提交所述目标事务，否则，则回滚所述目标事务。

2.根据权利要求1所述的方法，其特征在于，所述向资源管理器集群中各第一资源管理器发送准备指令之前，还包括：

由所述资源管理器集群包含的资源管理器中随机选取一个所述资源管理器作为第二资源管理器，确定所述资源管理器集群中除所述第二资源管理器之外的其他资源管理器均为第一资源管理器；

为各个所述第一资源管理器设置对应的编号；

所述向资源管理器集群中各第一资源管理器发送准备指令，包括：

按照设置的编号的顺序，依次向所述资源管理器集群中各第一资源管理器发送准备指令。

3.根据权利要求1所述的方法，其特征在于，所述向资源管理器集群中各第一资源管理器发送准备指令之前，还包括：

调取预先设置的编号记录信息；其中，所述编号记录信息包括预先为所述资源管理器集群中各个资源管理器设置的编号；

所述向资源管理器集群中各第一资源管理器发送准备指令，包括：

按照所述编号记录信息中记录的编号的顺序，依次向所述资源管理器集群中预先设定的各第一资源管理器发送准备指令。

4.根据权利要求2或3所述的方法，其特征在于，所述第二资源管理器记录所述目标事务对应的事务标记之前，还包括：

所述第二资源管理器调取本地预先设置的提交日志表；

所述第二资源管理器记录所述目标事务对应的事务标记，包括：

所述第二资源管理器将所述目标事务对应的事务标记记录至所述提交日志表中。

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

所述第二资源管理器在提交所述目标事务成功后，识别当前时刻的时间作为所述目标事务的提交时间；

所述第二资源管理器将所述提交时间记录至所述提交日志表中与所述目标事务的事务标记对应的位置处。

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

所述第一资源管理器在接收到所述准备指令后，记录当前时刻的时间作为对应的所述第一资源管理器进入准备提交目标事务的状态的开始时间；

所述第一资源管理器判断自身处于准备提交所述目标事务的状态是否持续预设时长，包括：

所述第一资源管理器实时判断由记录的所述开始时间至当前时刻经过的时间段是否达到所述预设时长。

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

如果所述第一资源管理器在自身处于准备提交所述目标事务的状态持续预设时长时，提交或者回滚所述目标事务失败，则返回执行提交或者回滚所述目标事务的步骤，直至提交或者回滚所述目标事务成功为止。

8.一种分布式事务的执行装置，其特征在于，包括：

第一发送模块，用于：向资源管理器集群中各第一资源管理器发送准备指令，以指示对应的所述第一资源管理器进入准备提交目标事务的状态；其中，所述资源管理器集群由第二资源管理器及至少一个所述第一资源管理器构成；

第二发送模块，用于：如果接收到各所述第一资源管理器返回的确认信息，则向所述第二资源管理器发送预设指令，以指示所述第二资源管理器提交所述目标事务并在提交成功后记录所述目标事务对应的事务标记；在所述第二资源管理器提交成功后，向各所述第一资源管理器发送指示提交所述目标事务的提交指令；

第三发送模块，用于：如果接收到任一个所述第一资源管理器返回的错误信息，则向所述资源管理器集群中各资源管理器发送指示回滚所述目标事务的回滚指令；

其中，每个所述第一资源管理器均在自身处于准备提交所述目标事务的状态持续预设时长时，查询是否存在所述目标事务对应事务标记，如果存在则提交所述目标事务，否则，则回滚所述目标事务。

9.一种分布式事务的执行设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述分布式事务的执行方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述分布式事务的执行方法的步骤。

Images