分布式事务的处理方法及装置与流程

本申请涉及数据库技术领域，尤其涉及一种分布式事务的处理方法及装置。

背景技术：

随着网络技术的发展，网络中不同业务系统间存在着越来越多的信息交互，存在一类事务，要求对在物理上处于不同数据库中的数据的操作需要保证其在同一个事务中，例如，电子商务、网站账号注册、微博、论坛发言等等，采用分布式事务的解决方案可以保证这类事务的数据操作在同一个事务中，例如，用户通过网络购买某种商品，就可能涉及到订单系统和支付系统，或者更多的业务系统，这些系统可以统称为分布式系统，可以对分布式系统之间相互关联的事务进行分布式事务处理来完成。

现有技术中，分布式系统采用两阶段提交(two phase commit，2PC)协议来完成分布式事务的处理，分布式系统一般包含两类节点：协调节点和参与节点(participants，cohorts或workers)，协调节点通常一个分布式系统中只有一个；而参与节点一般包含多个。2PC中的每个节点都会记录日志并持久性存储，即使节点发生故障日志也不会丢失。然而，由于协调节点在整个分布式事务处理的过程中起着主要的协调作用，其在记录日志以及持久化存储的过程中通常不能及时地对参与节点作出响应，这会影响分布式事务的响应时间，从而降低了分布式系统的性能。

技术实现要素：

本申请实施例提供了一种分布式事务的处理方法及装置，可以减小分布式事务的响应时间，从而可以提升分布式系统的性能。

第一方面，提供了一种分布式事务的处理方法，该方法包括：

协调节点接收客户端发送的事务启动请求，将所述事务启动请求对应的事务划分为多个子事务，并选取执行所述多个子事务中至少一个子事务的参与节点；

向所述参与节点发送事务执行请求，以使所述参与节点执行相应的子事务，记录并发送所述子事务的第一执行结果信息；

接收所有子事务的第一执行结果信息，根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息；

根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息，并向所述参与节点发送事务提交消息或回滚消息，以使所述参与节点执行所述子事务的提交操作或回滚操作，记录并发送所述子事务的操作状态信息。

第二方面，提供了一种分布式事务的处理方法，该方法包括：

参与节点接收协调节点发送的事务执行请求，其中，所述参与节点用于执行由所述协调节点对从客户端接收的事务启动请求对应的事务划分的多个子事务中至少一个子事务；

执行相应的子事务，并记录所述子事务的第一执行结果信息；

向所述协调节点发送所述子事务的第一执行结果信息，以使所述协调节点根据接收到的所有子事务的第一执行结果信息确定所述事务的第二执行结果信息，并使所述协调节点根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息；

接收事务提交消息或回滚消息，根据接收的事务提交消息或回滚消息执行所述子事务的提交操作或回滚操作，并记录所述子事务的操作状态信息。

第三方面，提供了一种分布式事务的处理装置，该装置包括：处理单元、 发送单元、接收单元和返回单元；

所述处理单元，用于接收客户端发送的事务启动请求，将所述事务启动请求对应的事务划分为多个子事务，并选取执行所述多个子事务中至少一个子事务的参与节点；

所述发送单元，用于向所述处理单元选取的所述参与节点发送事务执行请求，以使所述参与节点执行相应的子事务，记录并发送所述子事务的第一执行结果信息；

所述接收单元，用于接收所有子事务的第一执行结果信息，根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息；

所述返回单元，用于根据所述接收单元确定的所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息，并向所述参与节点发送事务提交消息或回滚消息，以使所述参与节点执行所述子事务的提交操作或回滚操作，记录并发送所述子事务的操作状态信息。

第四方面，提供了一种分布式事务的处理装置，该装置包括：接收单元、执行单元和发送单元；

所述接收单元，用于接收协调节点发送的事务执行请求，其中，所述装置用于执行由所述协调节点对从客户端接收的事务启动请求对应的事务划分的多个子事务中至少一个子事务；

所述执行单元，用于执行相应的子事务，并记录所述子事务的第一执行结果信息；

所述发送单元，用于向所述协调节点发送所述执行单元执行所述子事务的第一执行结果信息，以使所述协调节点根据接收到的所有子事务的第一执行结果信息确定所述事务的第二执行结果信息，并使所述协调节点根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息；

所述接收单元，还用于接收事务提交消息或回滚消息，根据接收的事务提交消息或回滚消息执行所述子事务的提交操作或回滚操作，并记录所述子 事务的操作状态信息。

本申请提供的分布式事务的处理方法及装置，在协调节点与参与节点按照两阶段提交协议通信的过程中，协调节点不需要将所有子事务的第一执行结果信息和事务的第二执行结果信息记录到日志文件，由此可以减小分布式事务的响应时间，从而可以提升分布式系统的性能，在协调节点发生故障而无法获取事务的第二执行结果信息时，只需要向参与节点询问该事务的所有子事务的第一执行结果信息，即可获取事务的第二执行结果信息。

附图说明

图1为本申请一种实施例提供的分布式事务的处理方法流程图；

图2为本申请2PC协议的通信方法信息交互图；

图3为本申请另一种实施例提供的分布式事务的处理方法流程图；

图4为本申请再一种实施例提供的分布式事务的处理装置示意图；

图5为本申请又一种实施例提供的分布式事务的处理装置示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为便于对本申请实施例的理解，下面将结合附图以具体实施例做进一步的解释说明，实施例并不构成对本申请实施例的限定。

本申请实施例提供的分布式事务的处理方法及装置，适用于分布式系统采用2PC协议来完成分布式事务的处理的场景，此处，分布式系统可以为转账系统、订单系统、支付系统以及其它业务系统等。在2PC协议中，分布式 系统可以包括客户端以及服务端，其中服务端一般包括两类节点：协调节点以及参与节点，协调节点可以接收客户端发送的事务启动请求，并可以根据接收的事务启动请求向参与节点发起事务执行指令(即启动分布式事务的执行)；此外，还可以向客户端返回事务启动成功或失败的响应消息，其中，事务由一系列相关的数据操作构成，而每条数据操作可以称为一个子事务；而参与节点是子事务的执行者。

图1为本申请一种实施例提供的分布式事务的处理方法流程图。所述方法的执行主体可以为协调节点，如图1所示，所述方法具体可以包括：

步骤110，协调节点接收客户端发送的事务启动请求，将所述事务启动请求对应的事务划分为多个子事务，并选取执行所述多个子事务中至少一个子事务的参与节点。

客户端的事务启动请求会发送给服务端的某个节点，并将该节点作为本次事务的协调节点。可以理解的是，在不同的应用场景下客户端发送的事务启动请求是不相同的，而一个事务启动请求则会唯一地启动一个事务。如，用户在使用支付宝系统进行转账时，则客户端发送的事务启动请求可以为转账事务启动请求，其转账事务启动请求会启动转账事务；而用户在使用支付宝系统进行支付时，则客户端发送的事务启动请求可以为支付事务启动请求，该支付事务启动请求会启动支付事务。

为了提高事务的执行效率，可以将事务启动请求对应的事务(即启动的事务)划分为多个子事务，其中，每个子事务对应事务的一条数据操作，且每个子事务由不同的节点执行。举例来说，转账事务启动请求对应的事务为转账事务，协调节点可以将该转账事务划分为两条数据操作：扣款操作和转入操作，该两条数据操作即为由转账事务划分的两个子事务。假设执行扣款操作的节点为节点A，而执行转入操作的节点为节点B，则可以将节点A以及节点B选取为参与节点。具体地，协调节点可以采用服务端驱动定位的数据定位方式进行数据定位，确认该两条数据操作的目标数据所在的节点(即节 点A以及节点B)，并将节点A以及节点B选取为参与节点。

当然，在实际应用中，上述扣款操作和转入操作也可以只由一个参与节点执行，且上述节点A以及节点B还可以用于执行其它事务的子事务，本申请对此不作限定。

在一种实施方式中，协调节点还可以为事务启动请求对应的事务分配事务唯一标识(Identity，ID)，以用于协调节点唯一地识别该事务，如协调节点可以为转账事务启动请求对应的转账事务分配事务ID。

步骤120，向所述参与节点发送事务执行请求，以使所述参与节点执行相应的子事务，记录并发送所述子事务的第一执行结果信息。

如前述例子，协调节点在选取节点A以及节点B之后，就可以按照2PC协议与参与节点进行通信。参见图2所示的2PC协议的通信方法信息交互图，图2中，协调节点与参与节点的通信可以划分为两个阶段：第一阶段，请求阶段；第二阶段，提交阶段。

在第一阶段，协调节点向参与节点发送事务执行请求(即prepare请求)，该事务执行请求可以携带与该参与节点对应的子事务(也称本地子事务或者数据操作)以及该子事务所属事务的ID。如前述例子，协调节点向节点A发送的事务执行请求可以携带扣款操作以及转账事务的事务ID，而协调节点向节点B发送的事务执行请求可以携带转入操作以及转账事务的事务ID；节点A在接收到事务执行请求之后，执行从账户X扣除指定金额款的扣款操作，并在扣款成功时，通过日志文件的形式记录扣款操作成功的信息，而在扣款失败时，通过日志文件的形式记录扣款操作失败的信息，并向协调节点发送扣款操作成功或失败的信息；也即参与节点执行相应的子事务，记录并发送所述子事务的第一执行结果信息；同理，节点B执行将上述指定金额款转入账户Y的转入操作，记录并发送转入操作成功的信息或者失败的信息。

可以理解的是，上述子事务的第一执行结果信息可以为成功的信息或者失败的信息，当为成功的信息时，参与节点可以在日志文件中记录与该参与 节点对应的子事务(即本地子事务)执行成功的信息、该子事务以及该子事务所属事务的事务ID，如，节点A可以在日志文件中记录扣款操作成功的信息、扣款操作以及转账事务的事务ID；当为失败的信息时，参与节点可以在日志文件中仅记录与该参与节点对应的子事务执行失败的信息以及该子事务所属事务的事务ID，如节点A可以在日志文件中记录扣款操作失败的信息以及转账事务的事务ID。

此外，上述账户X、指定金额款以及账户Y等信息均可以携带在事务执行请求中，也可以通过其它方式获取，本申请对此不作限定。

步骤130，接收所有子事务的第一执行结果信息，根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息。

如前述例子，协调节点将事务启动请求对应的事务划分了两个子事务，则协调节点接收两个子事务的第一执行结果信息，该第一执行结果信息可以携带在prepare ack消息中，如协调节点接收节点A发送的扣款操作成功的信息或失败的信息，还可以接收节点A发送的事务ID；此外，协调节点还接收节点B发送的转入操作成功的信息或失败的信息，还可以接收节点B发送的事务ID。此处，假设两个子事务的第一执行结果信息均为成功的信息，则事务的第二执行结果信息为成功的信息；否则只要其中一个子事务的第一执行结果信息为失败的信息，则事务的第二执行结果信息为失败的信息。

可以理解的是，事务的第二执行结果信息可以为成功的信息或失败的信息。

可选地，在所述根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息之前，所述方法还包括：

若在第一规定时长内未接收到所有子事务的第一执行结果信息，则向所述参与节点发送执行结果询问消息，所述执行结果询问消息用于指示所述参与节点根据记录的所述子事务的第一执行结果信息，重新向所述协调节点发送所述子事务的第一执行结果信息；

接收所有子事务的第一执行结果信息，并根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息。

此处，第一规定时长可以是由服务端预先设定好存储在本地的。如前述例子，如果协调节点在第一规定时长内只接收到一个子事务的第一执行结果信息或者未接收到任一子事务的第一执行结果信息，以只接收到一个子事务的第一执行结果信息为例，如，协调节点在第一规定时长内只接收到节点A发送的扣款操作成功的信息或失败的信息，则协调节点需要执行异常恢复的步骤，即向节点A以及节点B发送执行结果询问消息，该执行结果询问消息可以携带转账事务的事务ID，节点A或者节点B在接收到该执行结果询问消息之后，根据其携带的事务ID查找日志文件，从而确定与上述事务ID对应的子事务(也即本地子事务，如，扣款操作)的第一执行结果信息；之后节点A以及节点B重新向协调节点发送其本地子事务的第一执行结果信息；协调节点在接收到两个子事务的第一执行结果信息之后，确定事务的第二执行结果信息，其确定方法如前所述，在此不作赘述。

步骤140，根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息，并向所述参与节点发送事务提交消息或回滚消息，以使所述参与节点执行所述子事务的提交操作或回滚操作，记录并发送所述子事务的操作状态信息。

如前述例子，协调节点在确定事务的第二执行结果信息之后，就进入两阶段提交协议的第二阶段，如在确定转账事务启动请求对应的转账事务的第二执行结果信息为成功的信息或失败的信息时，即进入两阶段提交协议的第二阶段，在第二阶段，可直接向客户端返回事务启动成功消息或失败消息。具体地，第二执行结果信息为成功的信息时，直接向客户端返回事务启动成功消息(即commited消息)；而第二执行结果信息为失败的信息时，直接向客户端返回事务启动失败消息(即aborted消息)。

由上可以看出，本申请实施例中，协调节点在确定事务的第二执行结果 信息后，即确定了事务的最终启动结果，因此可以在第二阶段开始时直接向客户端返回事务启动成功消息或失败消息，而无需在接收到所有子事务的操作状态信息之后，再向客户端返回事务启动成功消息或失败消息，从而减小了用户等待系统响应的时间，由此可以提高用户的体验度。

在进入第二阶段后，协调节点还可以向所述参与节点发送事务提交消息(即commit消息)或回滚消息(即abort消息)。如前述例子，协调节点在确定转账事务的第二执行结果信息为成功的信息，则向节点A以及节点B发送事务提交消息，该事务提交消息可以携带转账事务的事务ID，节点A或者节点B在接收到上述事务提交消息之后，执行本地子事务的提交操作(如，节点A执行扣款操作的提交操作)，在日志文件中记录上述事务ID以及操作状态信息，该操作状态信息包括提交操作成功的信息。同理，协调节点可以向节点A以及节点B发送回滚消息，节点A以及节点B执行本地子事务的回滚操作，并记录本地子事务所属转账事务的事务ID以及回滚操作成功的信息。

需要说明的是，由于所有子事务的操作都已经在第一阶段完成，所以第二阶段参与节点向协调节点返回的操作状态信息为成功的信息，即上述操作状态信息可以为提交操作成功的信息，或者也可以为回滚操作成功的信息。

可选地，若在第二规定时长内未接收到所有子事务的操作状态信息，则向所述参与节点发送状态询问消息，所述状态询问消息用于指示所述参与节点根据记录的所述子事务的操作状态信息，重新向所述协调节点发送所述子事务的操作状态信息；

接收所有子事务的操作状态信息，并根据所述所有子事务的操作状态信息确定所述事务的状态信息。

此处，第二规定时长也可以是由服务端预先设定好保存在本地的。如前述例子中，如果协调节点在第二规定时长内只接收到一个子事务的操作状态信息或者未接收到任一子事务的操作状态信息，以只接收到一个子事务的操作状态信息为例，该操作状态信息可以携带在commit ack或者abort ack消 息中，如协调节点在第二规定时长内只接收到节点A发送的提交操作成功的信息，则协调节点需要执行异常恢复的步骤，即向节点A以及节点B发送状态询问消息，该状态询问消息可以携带转账事务的事务ID，节点A或者节点B在接收到该状态询问消息之后，根据其携带的事务ID查找日志文件，从而确定与上述事务ID对应的子事务(也即本地子事务，如，扣款操作)的操作状态信息；之后节点A以及节点B重新向协调节点发送其本地子事务的操作状态信息；协调节点在接收到两个子事务的操作状态信息之后，确定事务的状态信息。

由于所有子事务的操作都已经在第一阶段完成，所以第二阶段参与节点向协调节点返回的操作状态信息为成功的信息，即上述操作状态信息可以为提交操作成功的信息，或者也可以为回滚操作成功的信息。当所有子事务的操作状态信息为提交操作成功的信息时，则事务的状态信息为提交成功的信息；而当所有子事务的操作状态信息为回滚操作成功的信息时，则事务的状态信息为回滚成功的信息。

需要说明的是，本申请实施例还可以包括参与节点异常恢复的步骤，具体包括：

若在规定的第三时长内未接收到事务提交消息或回滚消息，则根据记录的所述子事务的第一执行结果信息，重新向所述协调节点发送所述子事务的第一执行结果信息。

此处，第三规定时长也可以是由服务端预先设定好保存在本地的。参与节点在向协调节点返回第一执行结果信息之后，若在第三规定时长内未接收到协调节点发送的事务提交消息或回滚消息，如前述例子，节点A在向协调节点返回本地子事务的第一执行结果信息之后，若在第三规定时长内未接收到协调节点发送的事务提交消息或回滚消息，则根据转账事务的事务ID查找日志文件，从而确定与上述事务ID对应的扣款操作的第一执行结果信息；之后节点A重新向协调节点发送其本地子事务的第一执行结果信息；协调节点 在接收到两个子事务的第一执行结果信息之后，确定事务的第二执行结果信息；并在确定事务的第二执行结果信息后，进入步骤140，步骤140的具体执行过程如前所述，在此不作赘述。

本申请提供的分布式事务的处理方法，在协调节点与参与节点按照两阶段提交协议通信的过程中，协调节点不需要将所有子事务的第一执行结果信息和事务的第二执行结果信息记录到日志文件，由此可以减小分布式事务的响应时间，从而可以提升分布式系统的性能；在协调节点发生故障而无法获取事务的第二执行结果信息时，只需要向参与节点询问该事务的所有子事务的第一执行结果信息，即可获取事务的第二执行结果信息。

图3为本申请另一种实施例提供的分布式事务的处理方法流程图，

步骤310，参与节点接收协调节点发送的事务执行请求，其中，所述参与节点用于执行由所述协调节点对从客户端接收的事务启动请求对应的事务划分的多个子事务中至少一个子事务。

客户端的事务启动请求会发送给服务端的某个节点，并将该节点作为本次事务的协调节点。可以理解的是，在不同的应用场景下客户端发送的事务启动请求是不相同的，而一个事务启动请求则会唯一地启动一个事务。如，用户在使用支付宝系统进行转账时，则客户端发送的事务启动请求可以为转账事务启动请求，其转账事务启动请求会启动转账事务；而用户在使用支付宝系统进行支付时，则客户端发送的事务启动请求可以为支付事务启动请求，该支付事务启动请求会启动支付事务。

为了提高事务的执行效率，可以将事务启动请求对应的事务(即启动的事务)划分为多个子事务，其中，每个子事务对应事务的一条数据操作，且每个子事务由不同的节点执行。举例来说，转账事务启动请求对应的事务为转账事务，协调节点可以将该转账事务划分为两条数据操作：扣款操作和转入操作，该两条数据操作即为由转账事务划分的两个子事务。假设执行扣款操作的节点为节点A，而执行转入操作的节点为节点B，则可以将节点A以及 节点B选取为参与节点。具体地，协调节点可以采用服务端驱动定位的数据定位方式进行数据定位，确认该两条数据操作的目标数据所在的节点(即节点A以及节点B)，并将节点A以及节点B选取为参与节点。

当然，在实际应用中，上述扣款操作和转入操作也可以只由一个参与节点执行，且上述节点A以及节点B还可以用于执行其它事务的子事务，本申请对此不作限定。

在一种实施方式中，协调节点还可以为事务启动请求对应的事务分配事务唯一标识(Identity，ID)，以用于协调节点唯一地识别该事务，如协调节点可以为转账事务启动请求对应的转账事务分配事务ID。

步骤320，执行相应的子事务，并记录所述子事务的第一执行结果信息。

如前述例子，协调节点在选取节点A以及节点B之后，就可以按照2PC协议与参与节点进行通信。参见图2所示的2PC协议的通信方法信息交互图，图2中，协调节点与参与节点的通信可以划分为两个阶段：第一阶段，请求阶段；第二阶段，提交阶段。

在第一阶段，协调节点向参与节点发送事务执行请求(即prepare请求)，该事务执行请求可以携带与该参与节点对应的子事务(也称本地子事务或者数据操作)以及该子事务所属事务的ID。如前述例子，协调节点向节点A发送的事务执行请求可以携带扣款操作以及转账事务的事务ID，而协调节点向节点B发送的事务执行请求可以携带转入操作以及转账事务的事务ID；节点A在接收到事务执行请求之后，执行从账户X扣除指定金额款的扣款操作，并在扣款成功时，通过日志文件的形式记录扣款操作成功的信息，而在扣款失败时，通过日志文件的形式记录扣款操作失败的信息，并向协调节点发送扣款操作成功或失败的信息；也即参与节点执行相应的子事务，记录并发送所述子事务的第一执行结果信息；同理，节点B执行将上述指定金额款转入账户Y的转入操作，记录并发送转入操作成功的信息或者失败的信息。

可以理解的是，上述子事务的第一执行结果信息可以为成功的信息或者 失败的信息，当为成功的信息时，参与节点可以在日志文件中记录与该参与节点对应的子事务(即本地子事务)执行成功的信息、该子事务以及该子事务所属事务的事务ID，如，节点A可以在日志文件中记录扣款操作成功的信息、扣款操作以及转账事务的事务ID；当为失败的信息时，参与节点可以在日志文件中仅记录与该参与节点对应的子事务执行失败的信息以及该子事务所属事务的事务ID，如节点A可以在日志文件中记录扣款操作失败的信息以及转账事务的事务ID。

此外，上述账户X、指定金额款以及账户Y等信息均可以携带在事务执行请求中，也可以通过其它方式获取，本申请对此不作限定。

步骤330，向所述协调节点发送所述子事务的第一执行结果信息，以使所述协调节点根据接收到的所有子事务的第一执行结果信息确定所述事务的第二执行结果信息，并使所述协调节点根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息。

如前述例子，协调节点将事务启动请求对应的事务划分了两个子事务，则协调节点接收两个子事务的第一执行结果信息，该第一执行结果信息可以携带在prepare ack消息中，如协调节点接收节点A发送的扣款操作成功的信息或失败的信息，还可以接收节点A发送的事务ID；此外，协调节点还接收节点B发送的转入操作成功的信息或失败的信息，还可以接收节点B发送的事务ID。此处，假设两个子事务的第一执行结果信息均为成功的信息，则事务的第二执行结果信息为成功的信息；否则只要其中一个子事务的第一执行结果信息为失败的信息，则事务的第二执行结果信息为失败的信息。

可以理解的是，事务的第二执行结果信息可以为成功的信息或失败的信息。

可选地，在所述根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息之前，所述方法还包括：

若在第一规定时长内未接收到所有子事务的第一执行结果信息，则向所 述参与节点发送执行结果询问消息，所述执行结果询问消息用于指示所述参与节点根据记录的所述子事务的第一执行结果信息，重新向所述协调节点发送所述子事务的第一执行结果信息；

接收所有子事务的第一执行结果信息，并根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息。

此处，第一规定时长可以是由服务端预先设定好存储在本地的。如前述例子，如果协调节点在第一规定时长内只接收到一个子事务的第一执行结果信息或者未接收到任一子事务的第一执行结果信息，以只接收到一个子事务的第一执行结果信息为例，如，协调节点在第一规定时长内只接收到节点A发送的扣款操作成功的信息或失败的信息，则协调节点需要执行异常恢复的步骤，即向节点A以及节点B发送执行结果询问消息，该执行结果询问消息可以携带转账事务的事务ID，节点A或者节点B在接收到该执行结果询问消息之后，根据其携带的事务ID查找日志文件，从而确定与上述事务ID对应的子事务(也即本地子事务，如，扣款操作)的第一执行结果信息；之后节点A以及节点B重新向协调节点发送其本地子事务的第一执行结果信息；协调节点在接收到两个子事务的第一执行结果信息之后，确定事务的第二执行结果信息，其确定方法如前所述，在此不作赘述。

如前述例子，协调节点在确定事务的第二执行结果信息之后，就进入两阶段提交协议的第二阶段，如在确定转账事务启动请求对应的转账事务的第二执行结果信息为成功的信息或失败的信息时，即进入两阶段提交协议的第二阶段，在第二阶段，可直接向客户端返回事务启动成功消息或失败消息。具体地，第二执行结果信息为成功的信息时，直接向客户端返回事务启动成功消息(即commited消息)；而第二执行结果信息为失败的信息时，直接向客户端返回事务启动失败消息(即aborted消息)。

由上可以看出，本申请实施例中，协调节点在确定事务的第二执行结果信息后，即确定了事务的最终启动结果，因此可以在第二阶段开始时直接向 客户端返回事务启动成功消息或失败消息，而无需在接收到所有子事务的操作状态信息之后，再向客户端返回事务启动成功消息或失败消息，从而减小了用户等待系统响应的时间，由此可以提高用户的体验度。

步骤340，接收事务提交消息或回滚消息，根据接收的事务提交消息或回滚消息执行所述子事务的提交操作或回滚操作，并记录所述子事务的操作状态信息。

在进入第二阶段后，协调节点还可以向所述参与节点发送事务提交消息(即commit消息)或回滚消息(即abort消息)。如前述例子，协调节点在确定转账事务的第二执行结果信息为成功的信息，则向节点A以及节点B发送事务提交消息，该事务提交消息可以携带转账事务的事务ID，节点A或者节点B在接收到上述事务提交消息之后，执行本地子事务的提交操作(如，节点A执行扣款操作的提交操作)，在日志文件中记录上述事务ID以及操作状态信息，该操作状态信息包括提交操作成功的信息。同理，协调节点可以向节点A以及节点B发送回滚消息，节点A以及节点B执行本地子事务的回滚操作，并记录本地子事务所属转账事务的事务ID以及回滚操作成功的信息。

需要说明的是，由于所有子事务的操作都已经在第一阶段完成，所以第二阶段参与节点向协调节点返回的操作状态信息为成功的信息，即上述操作状态信息可以为提交操作成功的信息，或者也可以为回滚操作成功的信息。当所有子事务的操作状态信息为提交操作成功的信息时，则事务的状态信息为提交成功的信息；而当所有子事务的操作状态信息为回滚操作成功的信息时，则事务的状态信息为回滚成功的信息。

可选地，若在第二规定时长内未接收到所有子事务的操作状态信息，则向所述参与节点发送状态询问消息，所述状态询问消息用于指示所述参与节点根据记录的所述子事务的操作状态信息，重新向所述协调节点发送所述子事务的操作状态信息；

接收所有子事务的操作状态信息，并根据所述所有子事务的操作状态信 息确定所述事务的状态信息。

此处，第二规定时长也可以是由服务端预先设定好保存在本地的。如前述例子中，如果协调节点在第二规定时长内只接收到一个子事务的操作状态信息或者未接收到任一子事务的操作状态信息，以只接收到一个子事务的操作状态信息为例，该操作状态信息可以携带在commit ack或者abort ack消息中，如协调节点在第二规定时长内只接收到节点A发送的提交操作成功的信息，则协调节点需要执行异常恢复的步骤，即向节点A以及节点B发送状态询问消息，该状态询问消息可以携带转账事务的事务ID，节点A或者节点B在接收到该状态询问消息之后，根据其携带的事务ID查找日志文件，从而确定与上述事务ID对应的子事务(也即本地子事务，如，扣款操作)的操作状态信息；之后节点A以及节点B重新向协调节点发送其本地子事务的操作状态信息；协调节点在接收到两个子事务的操作状态信息之后，确定事务的状态信息。

由于所有子事务的操作都已经在第一阶段完成，所以第二阶段参与节点向协调节点返回的操作状态信息为成功的信息，即上述操作状态信息可以为提交操作成功的信息，或者也可以为回滚操作成功的信息。

需要说明的是，本申请实施例还可以包括参与节点异常恢复的步骤，具体包括：

若在规定的第三时长内未接收到事务提交消息或回滚消息，则根据记录的所述子事务的第一执行结果信息，重新向所述协调节点发送所述子事务的第一执行结果信息。

此处，第三规定时长也可以是由服务端预先设定好保存在本地的。参与节点在向协调节点返回第一执行结果信息之后，若在第三规定时长内未接收到协调节点发送的事务提交消息或回滚消息，如前述例子，节点A在向协调节点返回本地子事务的第一执行结果信息之后，若在第三规定时长内未接收到协调节点发送的事务提交消息或回滚消息，则根据转账事务的事务ID查找 日志文件，从而确定与上述事务ID对应的扣款操作的第一执行结果信息；之后节点A重新向协调节点发送其本地子事务的第一执行结果信息；协调节点在接收到两个子事务的第一执行结果信息之后，确定事务的第二执行结果信息；并在确定事务的第二执行结果信息后，进入步骤140，步骤140的具体执行过程如前所述，在此不作赘述。

本申请提供的分布式事务的处理方法，在协调节点与参与节点按照两阶段提交协议通信的过程中，协调节点不需要将所有子事务的第一执行结果信息和事务的第二执行结果信息记录到日志文件中，由此可以减少分布式事务的响应时间，从而可以提升分布式系统的性能；在协调节点发生故障而无法获取事务的第二执行结果信息时，只需要向参与节点询问该事务的所有子事务的第一执行结果信息，即可获取事务的第二执行结果信息。

与上述分布式事务的处理方法对应地，本申请实施例还提供的一种分布式事物的处理装置，如图4所示，该装置包括：处理单元401、发送单元402、接收单元403和返回单元404。

处理单元401，用于接收客户端发送的事务启动请求，将所述事务启动请求对应的事务划分为多个子事务，并选取执行所述多个子事务中至少一个子事务的参与节点。

发送单元402，用于向处理单元401选取的所述参与节点发送事务执行请求，以使所述参与节点执行相应的子事务，记录并发送所述子事务的第一执行结果信息。

接收单元403，用于接收所有子事务的第一执行结果信息，根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息。

返回单元404，用于根据接收单元403确定的所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息，并向所述参与节点发送事务提交消息或回滚消息，以使所述参与节点执行所述子事务的提交操作或回滚操作，记录并发送所述子事务的操作状态信息。

可选地，发送单元402，还用于若在第一规定时长内未接收到所有子事务的第一执行结果信息，则向所述参与节点发送执行结果询问消息，所述执行结果询问消息用于指示所述参与节点根据记录的所述子事务的第一执行结果信息，重新发送所述子事务的第一执行结果信息；

接收单元403，还用于接收所有子事务的第一执行结果信息，并根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息。

可选地，发送单元402，还用于若在第二规定时长内未接收到所有子事务的操作状态信息，则向所述参与节点发送状态询问消息，所述状态询问消息用于指示所述参与节点根据记录的所述子事务的操作状态信息，重新发送所述子事务的操作状态信息；

接收单元403，还用于接收所有子事务的操作状态信息，并根据所述所有子事务的操作状态信息确定所述事务的状态信息。

本申请实施例装置的各功能模块的功能，可以通过上述方法实施例的各步骤来实现，因此，本申请提供的装置的具体工作过程，在此不复赘述。

本申请提供的分布式事务的处理装置，处理单元401接收客户端发送的事务启动请求，将所述事务启动请求对应的事务划分为多个子事务，并选取执行所述多个子事务中至少一个子事务的参与节点；发送单元402向所述参与节点发送事务执行请求，以使所述参与节点执行相应的子事务，记录并发送所述子事务的第一执行结果信息；接收单元403接收所有子事务的第一执行结果信息，根据所述所有子事务的第一执行结果信息确定所述事务的第二执行结果信息；返回单元404根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息，并向所述参与节点发送事务提交消息或回滚消息，以使所述参与节点执行所述子事务的提交操作或回滚操作，记录并发送所述子事务的操作状态信息。由此可以减小分布式事务的响应时间，从而可以提升分布式系统的性能。

与上述分布式事务的处理方法对应地，本申请实施例还提供的一种分布 式事物的处理装置，如图5所示，该装置包括：接收单元501、执行单元502和发送单元503。

接收单元501，用于接收协调节点发送的事务执行请求，其中，所述装置用于执行由所述协调节点对从客户端接收的事务启动请求对应的事务划分的多个子事务中至少一个子事务。

执行单元502，用于执行相应的子事务，并记录所述子事务的第一执行结果信息。

发送单元503，用于向所述协调节点发送执行单元502执行所述子事务的第一执行结果信息，以使所述协调节点根据接收到的所有子事务的第一执行结果信息确定所述事务的第二执行结果信息，并使所述协调节点根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息。

接收单元501，还用于接收事务提交消息或回滚消息，根据接收的事务提交消息或回滚消息执行所述子事务的提交操作或回滚操作，并记录所述子事务的操作状态信息。

可选地，发送单元503，还用于若在规定的第三时长内未接收到事务提交消息或回滚消息，则根据记录的所述子事务的第一执行结果信息，重新向所述协调节点发送所述子事务的第一执行结果信息。

本申请实施例装置的各功能模块的功能，可以通过上述方法实施例的各步骤来实现，因此，本申请提供的装置的具体工作过程，在此不复赘述。

本申请提供的分布式事务的处理装置，接收单元501接收协调节点发送的事务执行请求；执行单元502执行相应的子事务，并记录所述子事务的第一执行结果信息；发送单元503向所述协调节点发送所述子事务的第一执行结果信息，以使所述协调节点根据接收到的所有子事务的第一执行结果信息确定所述事务的第二执行结果信息，并使所述协调节点根据所述第二执行结果信息向所述客户端返回事务启动成功消息或失败消息；接收单元501接收事务提交消息或回滚消息，根据接收的事务提交消息或回滚消息执行所述子 事务的提交操作或回滚操作，并记录所述子事务的操作状态信息。由此可以减小分布式事务的响应时间，从而可以提升分布式系统的性能。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的对象及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

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