分布式事务处理方法和系统与流程

本发明涉及计算机处理领域，特别是涉及一种分布式事务处理方法和系统。

背景技术：

事务(Transaction)是由一组操作构成的可靠、独立的工作单元，在该工作单元中所有的操作要么都成功，要么都失败。事务具备四个基本的特性：原子性、一致性、隔离性、持久性，也简称为事务的ACID特性。在微服务时代，业务进行大量的拆分后，随之而来的就是分布式事务的数据一致性问题，特别是涉及到交易的不同系统之间的分布式事务。为了保证分布式事务的数据一致性，通过事务表来记录各个事务或子事务的操作状态，传统的事务表的管理是通过单独的一个服务系统来统一管理各个事务的操作状态，这样每个业务系统都需要和该服务系统建立网络连接，不仅耗费网络流量，而且由于每个业务系统要和服务系统进行交互，所有的操作记录都记录在同一事务表中，不仅加重了事务表的负担，且导致操作效率较低，并且，若服务系统出现故障，那么将会导致业务系统整个瘫痪，即存在单点故障。

技术实现要素：

基于此，有必要针对上述问题，提出一种能够减少网络流量且效率高的分布式事务处理方法和系统。

一种分布式事务处理方法，所述方法包括：主业务系统接收分布式事务的开启请求，根据所述开启请求为所述分布式事务分配一个事务标识，将所述事务标识和对应的开启状态记录到主事务表中，所述主事务表存储在主业务数据库中；所述主业务系统将所述分布式事务分为多个子事务，并分别向对应的各个从业务系统发送执行所述子事务的指令，所述指令中包括事务标识；所述从业务系统根据所述执行子事务的指令在从业务前置表中进行对应的操作，若操作成功，则根据所述事务标识生成一条标识当前子事务操作状态的记录插入到子事务表中，若操作失败，则不记录，其中，所述从业务前置表为从业务主表的复制表，所述从业务前置表和所述子事务表都存储在对应的从业务数据库中；所述主业务系统获取各个子事务的操作结果，并根据所述操作结果更新主事务表中的操作状态，若所有子事务全部操作成功，则向消息系统发送确认消息，若至少一个子事务操作失败，则向消息系统发送取消消息；所述消息系统将所述确认消息或取消消息发送给对应的各个从业务系统；若所述从业务系统接收到的消息为确认消息，则将之前在从业务前置表中的操作同步到从业务主表中以完成对应子事务的提交，若所述从业务系统接收到的消息为取消消息，则直接将之前在从业务前置表中的操作进行回滚。

在其中一个实施例中，所述主业务系统获取各个子事务的操作结果，并根据所述操作结果更新主事务表中的操作状态，若所有子事务全部操作成功，则向消息系统发送确认消息，若至少一个子事务操作失败，则向消息系统发送取消消息的步骤包括：所述主业务系统获取各个子事务的操作结果，若所有子事务全部操作成功，则将主事务表中的操作状态由开启状态更新为尝试完成，然后向消息系统发送确认消息，若消息发送成功，则将主事务表中的操作状态由尝试完成更新为确认完成；若至少一个子事务操作失败，则将主事务表中的操作状态由开启状态更新为回滚中，然后向消息系统发送取消消息，若消息发送成功，则将主事务表中的操作状态由回滚中更新为回滚完成。

在其中一个实施例中，所述若所述从业务系统接收到的消息为确认消息，则将之前在从业务前置表中的操作同步到从业务主表中以完成对应子事务的提交，若所述从业务系统接收到的消息为取消消息，则直接将之前在从业务前置表中的操作进行回滚的步骤包括：若所述从业务系统收到的消息为确认消息，则根据所述确认消息将所述子事务表中的操作状态由尝试完成更新为确认中，然后根据所述子事务表中的操作记录将之前在从业务前置表中的操作同步到从业务主表中，若同步成功，则将所述子事务表中的状态更新为确认完成；若所述从业务系统收到的消息为取消消息，则根据所述事务标识在子事务表中查找与该事务标识对应的操作状态，若能够查找到，则将所述操作状态更新为回滚中，然后根据所述子事务表中的操作记录将之前对所述从业务前置表的操作进行回滚，若回滚成功，则将所述子事务表中的操作状态更新为回滚完成，若查找不到，则结束。

在其中一个实施例中，所述主业务系统将所述分布式事务分为多个子事务，并分别向对应的各个从业务系统发送执行所述子事务的指令，所述指令中包括事务标识的步骤包括：所述主业务系统将所述分布式事务分为多个子事务并设置各个子事务的执行顺序，按照所述执行顺序向对应的从业务系统发送执行所述子事务的指令，所述指令中包括事务标识，当接收到前一个子事务执行结果为成功时，才将后一个子事务的执行命令发送到对应的从业务系统，若接收到前一个子事务的执行结果为失败，则不再执行后面的子事务。

在其中一个实施例中，所述方法还包括：在所述主业务系统和所述每个从业务系统中各设置一个检查机制，所述检查机制用于监控主事务表或子事务表中事务的操作状态，若发现所述操作状态异常，则根据所述事务表中的记录向所述消息系统再次发送确认消息或取消消息以更改所述操作状态。

一种分布式事务处理系统，所述系统包括：主业务系统，用于接收分布式事务的开启请求，根据所述开启请求为所述分布式事务分配一个事务标识，将所述事务标识和对应的开启状态记录到主事务表中，所述主事务表存储在主业务数据库中，并将所述分布式事务分为多个子事务，分别向对应的各个从业务系统发送执行所述子事务的指令，所述指令中包括事务标识；从业务系统，所述从业务系统有多个，用于根据所述执行子事务的指令在从业务前置表中进行对应的操作，若操作成功，则根据所述事务标识生成一条标识当前子事务操作状态的记录插入到子事务表中，若操作失败，则不记录，其中，所述从业务前置表为从业务主表的复制表，所述从业务前置表和所述子事务表都存储在对应的从业务数据库中；所述主业务系统还用于获取各个子事务的操作结果，并根据所述操作结果更新主事务表中的操作状态，若所有子事务全部操作成功，则向消息系统发送确认消息，若至少一个子事务操作失败，则向消息系统发送取消消息；消息系统，用于将所述确认消息或取消消息发送给对应的各个从业务系统；所述从业务系统还用于若接收到的消息为确认消息，则将之前在从业务前置表中的操作同步到从业务主表中以完成对应子事务的提交，若接收到的消息为取消消息，则直接将之前在从业务前置表中的操作进行回滚。

在其中一个实施例中，所述主业务系统还用于获取各个子事务的操作结果，若所有子事务全部操作成功，则将主事务表中的操作状态由开启状态更新为尝试完成，然后向消息系统发送确认消息，若消息发送成功，则将主事务表中的操作状态由尝试完成更新为确认完成；若至少一个子事务操作失败，则将主事务表中的操作状态由开启状态更新为回滚中，然后向消息系统发送取消消息，若消息发送成功，则将主事务表中的操作状态由回滚中更新为回滚完成。

在其中一个实施例中，所述从业务系统还用于若收到的消息为确认消息，则根据所述确认消息将所述子事务表中的操作状态由尝试完成更新为确认中，然后根据所述子事务表中的操作记录将之前在从业务前置表中的操作同步到从业务主表中，若同步成功，则将所述子事务表中的状态更新为确认完成；若收到的消息为取消消息，则根据所述事务标识在子事务表中查找与该事务标识对应的操作状态，若能够查找到，则将所述操作状态更新为回滚中，然后根据所述子事务表中的操作记录将之前对所述从业务前置表的操作进行回滚，若回滚成功，则将所述子事务表中的操作状态更新为回滚完成，若查找不到，则结束。

在其中一个实施例中，所述主业务系统将所述分布式事务分为多个子事务并设置各个子事务的执行顺序，按照所述执行顺序向对应的从业务系统发送执行所述子事务的指令，所述指令中包括事务标识，当接收到前一个子事务执行结果为成功时，才将后一个子事务的执行命令发送到对应的从业务系统，若接收到前一个子事务的执行结果为失败，则不再执行后面的子事务。

在其中一个实施例中，所述主业务系统和所述各个从业务系统还用于通过设置的检查机制监控主事务表或子事务表中事务的操作状态，若发现所述操作状态异常，则根据所述事务表中的记录向所述消息系统再次发送确认消息或取消消息以更改所述操作状态。

上述分布式事务处理方法和系统，通过在每个业务系统的数据库中添加一个事务表(为了区分，主业务数据库中的事务表称为主事务表，从业务数据库中的事务表称为子事务表)，即事务表是以分布式方式存在于每个业务系统的本地数据库中，从而可以简单有效的保证每个事务或子事务的ACID性，且由于不再需要单独一个服务系统来统一管理事务表，所以各个业务系统也就不需要再与服务系统建立网格连接，且也不需要再通过与服务系统进行交互来操作事务表，从而不但可以减少网络流量的消耗，而且可以提高处理事务的效率，进一步的，由于该事务表是以分布式方式存在的，所以避免了单点故障，具有一定的容错性，且通过将事务表的记录进行分散，大大减少了单个事务表的读写负担。

附图说明

图1为一个实施例中分布式事务处理方法的应用环境图；

图2为一个实施例中服务器的内部结构框图；

图3为一个实施例中分布式事务处理方法的流程图；

图4为另一个实施例中分布式事务处理方法的应用环境图；

图5为一个实施例中分布式事务处理系统的架构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，在一个实施例中，提出了一种分布式事务处理方法，该方法可应用于如图1所示的应用环境中，在该应用环境中，第一服务器102分别与多个第二服务器104连接，同时，第一服务器102与第三服务器106连接，第二服务器104也与第三服务器106建立连接。其中，第一服务器102运行一个主业务系统，每个第二服务器104运行一个从业务系统，第三服务器106运行一个消息系统。具体的，运行主业务系统的第一服务器102用于接收分布式事务的开启请求，根据所述开启请求为所述分布式事务分配一个事务标识，将所述事务标识和对应的开启状态记录到主事务表中，所述主事务表存储在主业务数据库中，且将所述分布式事务分为多个子事务，并分别向对应的各个从业务系统发送执行所述子事务的指令，所述指令中包括事务标识；运行从业务系统的第二服务器104用于根据所述执行子事务的指令在从业务前置表中进行对应的操作，若操作成功，则根据所述事务标识生成一条标识当前子事务操作状态的记录插入到子事务表中，若操作失败，则不记录，其中，所述从业务前置表为从业务主表的复制表，所述从业务前置表和所述子事务表都存储在对应的从业务数据库中；运行主业务系统的第一服务器102还用于获取各个子事务的操作结果，并根据所述操作结果更新主事务表中的操作状态，若所有子事务全部操作成功，则向消息系统发送确认消息，若至少一个子事务操作失败，则向消息系统发送取消消息；运行消息系统的第三服务器106用于将所述确认消息或取消消息发送给对应的各个从业务系统；运行从业务系统的第二服务器104还用于若接收到的消息为确认消息，则将之前在从业务前置表中的操作同步到从业务主表中以完成对应子事务的提交，若接收到的消息为取消消息，则直接将之前在从业务前置表中的操作进行回滚。

如图2所示，在一个实施例中，上述服务器102的内部结构示意图如图2所示，包括通过系统总线连接的处理器、非易失性存储介质、内存和网络接口。其中，该非易失存储介质包括操作系统、数据库、分布式事务处理装置。数据库用于存储数据，比如，存储事务表。该任务分配的装置用于实现一种分布式事务处理方法，该服务器的处理器用于提供计算和控制能力，支撑整个服务器的运行。该服务器的网络接口用于与外部的服务器和终端通过网络连接通信，比如，接收分布式事务的开启请求等。本领域技术人员可以理解，图2中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

如图3所示，在一个实施例中，提出了一种分布式事务处理方法，该方法包括：

步骤302，主业务系统接收分布式事务的开启请求，根据开启请求为分布式事务分配一个事务标识，将事务标识和对应的开启状态记录到主事务表中，主事务表存储在主业务数据库中。

在本实施例中，主业务系统是指直接接收事务的系统，该主业务系统从事务入口处接收分布式事务的开启请求，然后根据该开启请求为分布式事务分配一个事务标识，其中，事务标识用于唯一标识一个分布式事务，事务标识可以是分配给分布式事务的唯一编号，也可以是其他可以唯一代表该分布式事务的标识。为了清楚的了解每个分布式事务的操作状态，需要将分布式事务的操作状态记录到主事务表中，也就是说，主事务表用于记录每个分布式事务的当前操作状态。具体的，当为分布式事务分配了一个事务标识后，根据该事务标识和对应的开启状态生成一条记录该分布式事务的开启状态的记录插入到该主事务表中，主事务表存在在该主业务系统的本地数据库中，可以有效的保证事务的ACID性，即如果分布式事务开启成功，那么必然会将该分布式事务的开启状态记录到主事务表中，也就是说，两者之间的操作具有原子性，要么全部执行，要么全部不执行。

步骤304，主业务系统将分布式事务分为多个子事务，并分别向对应的各个从业务系统发送执行子事务的指令，指令中包括事务标识。

在本实施例中，主业务系统将分布式事务开启之后，还需要按照预设的规则将分布式事务分为多个子事务，然后分别向对应的各个从业务系统发送执行子事务的指令，该指令中包括事务标识，便于从业务系统了解该子事务属于哪个分布式事务。从业务系统是相对主业务系统而言的，用于执行主业务系统分配的子事务，一般从业务系统有多个，主业务系统需要分别向各个从业务系统发送执行对应子事务的指令。在一个实施例中，主业务系统是通过并行的方式将各个从业务系统发送执行对应子事务的指令，即主业务系统将划分后的子事务同时分别发送给各个从业务系统，各个从业务系统之间是并行执行的方式。在另一个实施例中，主业务系统是通过串行的方式将子事务发送给对应的从业务系统进行执行，此时不但需要将分布式事务分为多个子事务还需要设置各个子事务的执行顺序，只有前一个子事务执行成功，才会将后一个子事务的执行命令发送到对应的从业务系统，若接收到前一个子事务的执行结果为失败，则不再执行后面的子事务。举一个例子，假设有商城系统，库存系统、订单系统这三个业务系统，其中，商城系统为主业务系统，而库存系统和订单系统分别为从业务系统；商城系统接收到用户的购买请求后，首先需要进行在库存系统中进行减库存的操作，然后再在订单系统中进行新增订单的操作，只有减库存的操作成功，才会执行新增订单的操作，若减库存的操作失败，说明没有库存或库存不足，不能满足用户的需求，也就不需要再进行新增订单的操作。

步骤306，从业务系统根据执行子事务的指令在从业务前置表中进行对应的操作，若操作成功，则根据事务标识生成一条标识当前子事务操作状态的记录插入到子事务表中，若操作失败，则不记录，其中，从业务前置表为从业务主表的复制表，从业务前置表和子事务表都存储在对应的从业务数据库中。

在本实施例中，从业务系统接收到主业务系统发送的执行子事务的指令后，根据该指令在从业务前置表中进行对应的操作，其中，从业务前置表是从业务主表的复制表。在整个分布式事务未执行成功前，为了保证各个子事务的一致性，先是在从业务前置表中操作，保持从业务主表的数据不变，后续待所有子事务都执行成功后，再同时执行各个从业务主表，这样可以有效的保证各个子事务的一致性，且由于是在前置表中进行的操作，在分布式事务提交之前即分布式事务执行成功之前，如果进行读操作，则读取的是业务主表。具体的，若从业务系统操作从业务前置表成功后，则根据事务标识生成一条标识当前子事务操作状态的记录插入到子事务表中，若操作失败，则不记录。由于从业务前置表和子事务表存在于同一数据库中，所以可以有效保证事务的ACID性，即只要操作从业务前置表成功，则必然会在子事务表中插入一条标记当前操作状态的记录，同样的，若操作失败，则不会有任何记录。

步骤308，主业务系统获取各个子事务的操作结果，并根据操作结果更新主事务表中的操作状态，若所有子事务全部操作成功，则向消息系统发送确认消息，若至少一个子事务操作失败，则向消息系统发送取消消息。

在本实施例中，主业务系统获取到各个子事务的操作结果后，根据该操作结果更新主事务表中的操作状态，若全部操作成功，则将主事务表中的操作状态由开启状态更新为尝试完成状态，然后向消息系统发送确认消息；若至少一个子事务执行失败，则将主事务表中的开启状态更新为回滚中状态，然后向消息系统发送取消消息。具体的，通过主业务系统通过采用AOP切面技术来获取到各个子事务的操作结果，即延伸了业务事务范围操作事务表，不但保证了各个子事务之间的原子性，即要么全部成功，要么全部失败，而且对业务代码无侵入即不需要更改业务代码。

步骤310，消息系统将确认消息或取消消息发送给对应的各个从业务系统。

在本实施例中，消息系统接收到主业务系统发送的确认消息或取消消息后，根据确认消息或取消消息中的事务标识，将该确认消息或取消消息发送到与该事务标识对应的各个从业务系统，即发送到所有与该事务标识有关的从业务系统。

步骤312，若从业务系统接收到的消息为确认消息，则将之前在从业务前置表中的操作同步到从业务主表中以完成对应子事务的提交，若从业务系统接收到的消息为取消消息，则直接将之前在从业务前置表中的操作进行回滚。

在本实施例中，若从业务系统收到的消息为确认消息，则根据确认消息中的事务标识在子事务表中找到对应的操作记录，将之前在从业务前置表中的操作同步到从业务主表中从而完成对应子事务的提交；若从业务系统接收到的消息为取消消息，则通过回调直接将之前在从业务前置表中操作进行回滚。具体的，若从业务系统收到的消息为确认消息，首先根据该确认消息将子事务表中的操作状态由尝试完成更新为确认中，然后再根据子事务表中的操作记录将之前在从业务前置表中的操作同步到从业务主表中，若同步成功，则将子事务表中的状态由确认中更新为确认完成；若从业务系统收到的消息为取消消息，则根据事务标识在子事务表中查找与该事务标识对应的操作状态，若能够查找到，则将操作状态由尝试完成更新为回滚中，然后根据子事务表中的操作记录将之前对业务前置表的操作进行回滚，若回滚成功，则将子事务表中的操作状态更新为回滚完成，若查不到，则结束，说明之前执行失败，没有相关记录所以不需要处理。

在本实施例中，通过在每个业务系统的数据库中添加一个事务表(为了区分，主业务数据库中的事务表称为主事务表，从业务数据库中的事务表称为子事务表)，即事务表是以分布式方式存在于每个业务系统的本地数据库中，从而可以简单有效的保证每个事务或子事务的ACID性，且由于不再需要单独一个服务系统来统一管理事务表，所以各个业务系统也就不需要再与服务系统建立网格连接，且也不需要再通过与服务系统进行交互来操作事务表，从而不但可以减少网络流量的消耗，而且可以提高处理事务的效率，进一步的，由于该事务表是以分布式方式存在的，所以避免了单点故障，具有一定的容错性。且通过将事务表的记录进行分散，大大减少了单个事务表的读写负担。

在一个实施例中，主业务系统获取各个子事务的操作结果，并根据操作结果更新主事务表中的操作状态，若所有子事务全部操作成功，则向消息系统发送确认消息，若至少一个子事务操作失败，则向消息系统发送取消消息的步骤308包括：主业务系统获取各个子事务的操作结果，若所有子事务全部操作成功，则将主事务表中的操作状态由开启状态更新为尝试完成，然后向消息系统发送确认消息，若消息发送成功，则将主事务表中的操作状态由尝试完成更新为确认完成；若至少一个子事务操作失败，则将主事务表中的操作状态由开启状态更新为回滚中，然后向消息系统发送取消消息，若消息发送成功，则将主事务表中的操作状态由回滚中更新为回滚完成。

在本实施例中，主业务系统获取到各个子事务的操作结果，若所有子事务全部操作成功，说明所有子事务都已经做好了提交的准备，此时将主事务表中的操作状态由开启状态更新为尝试完成，然后向消息系统发送确认消息，接收到消息系统返回的应答时，说明消息成功发送，此时主业务系统的工作已经全部完成，所以将主事务表中的操作状态由尝试完成更新为确认完成。若出现一个或多个子事务操作失败，那么遵循事务的ACID性，代表该分布式事务执行失败，此时需要将主事务表中的操作状态由开启状态更新为回滚中，然后向消息系统发送取消消息，同样地，若收到消息系统返回的应答则说明消息已经发送成功，然后将主事务表中的操作状态由回滚中更新为回滚完成。

在一个实施例中，若从业务系统接收到的消息为确认消息，则将之前在从业务前置表中的操作同步到从业务主表中完成对应子事务的提交，若从业务系统接收到的消息为取消消息，则直接将之前在从业务前置表中的操作进行回滚的步骤312包括：若从业务系统收到的消息为确认消息，则根据确认消息将子事务表中的操作状态由尝试完成更新为确认中，然后根据子事务表中的操作记录将之前在从业务前置表中的操作同步到从业务主表中，若同步成功，则将子事务表中的状态更新为确认完成；若从业务系统收到的消息为取消消息，则根据事务标识在子事务表中查找与该事务标识对应的操作状态，若能够查找到，则将操作状态更新为回滚中，然后根据子事务表中的操作记录将之前对从业务前置表的操作进行回滚，若回滚成功，则将子事务表中的操作状态更新为回滚完成，若查找不到，则结束。

在本实施例中，消息系统将确认消息或取消消息发送给各个参与的从业务系统，为了避免消息系统重复发送消息造成操作的重复执行，从业务系统在接收到确认消息或取消消息后，首先需要进行消息去重，即判断该消息是否为重复发送，具体的，可以采用消息应用状态表记录每次消息的发送，接收到消息后，首先在该消息应用状态表中查找是否收到过同样的消息，若是，则说明该消息为重复发送，丢弃即可，若没有查找到，说明该消息是第一次发送，则保留。若从业务系统经过消息去重收到的消息为确认消息，则首先根据确认消息中的事务标识将子事务表中该事务的操作状态由尝试完成更新为确认中，然后通过回调确认方法根据子事务表中的操作记录将之前在从业务前置表中的操作同步到从业务主表中，若同步完成，则将子事务表中的状态更新为确认完成。该方案在尝试(Try)阶段先在前置表中操作，当所有子事务都确认尝试完成后，再同时根据确认消息提交各个子事务，从而保证了各个子事务的一致性。若从业务系统经过消息去重收到的消息为取消消息，则根据事务标识在子事务表中查找与该事务标识对应的操作状态，若能够查找到，说明之前操作已经尝试完成，则将操作状态由尝试完成更新为回滚中，然后根据子事务表中的操作记录采用取消调用方法将之前对从业务前置表的操作进行回滚，若回滚成功，则将子事务表中的操作状态更新为回滚完成。若查找不到，说明之前操作失败，即之前操作从业务前置表失败，因此不需要进行回滚操作，直接结束不做任何处理。

在一个实施例中，主业务系统将分布式事务分为多个子事务，并分别向对应的各个从业务系统发送执行子事务的指令，该指令中包括事务标识的步骤304包括：主业务系统将分布式事务分为多个子事务并设置各个子事务的执行顺序，按照执行顺序向对应的从业务系统发送执行子事务的指令，指令中包括事务标识，当接收到前一个子事务执行结果为成功时，才将后一个子事务的执行命令发送到对应的从业务系统，若接收到前一个子事务的执行结果为失败，则不再执行后面的子事务。

在本实施例中，主业务系统将分布式事务分为多个子事务同时设置各个子事务的执行顺序，按照预设的执行顺序向对应的从业务系统发送执行子事务的指令，当然，指令中包括事务标识。后一个子事务的执行是以前一个子事务的执行结果为依据的，只有前一个子事务执行成功，才会将后一个子事务的执行命令发送给从业务系统，若前一个子事务执行失败，根据事务的ACID性，整个分布式事务已经确认为执行失败，所以不需要再执行后面的子事务。通过该方法每个只需要锁定一个子事务资源，避免了同时占用大量的资源，能够做到及时回滚。

在一个实施例中，上述分布式事务处理方法还包括：在主业务系统和各个从业务系统中都设置有一个检查机制，检查机制用于监控主事务表或子事务表中事务的操作状态，若发现操作状态异常，则根据事务表中的记录向消息系统再次发送确认消息或取消消息以更改操作状态。

在本实施例中，由于主业务系统可能在向消息系统成功发送确认消息或取消消息后还没来得及更改操作状态就出现故障或掉线，从业务系统也可能出现在收到确认消息或取消消息后还没来得及更新状态就出现故障或掉线的情况，那么当系统恢复正常后，主事务表或子事务表中的状态就会处于异常状态。为了能够及时的将异常状态进行修复，通过在每个主业务系统和各个从业务系统中各设置一个检查机制，该检查机制用于监控主事务表或子事务表中事务的操作状态，若发现操作状态异常，则根据事务表中的记录向消息系统再次发送确认消息或取消消息以更改操作状态，从而实现了事务的最终一致性。

如图4所示，在一个具体的实施例中，一种分布式事务处理的方法应用于如图4所示的应用环境中，在该应用环境中，包括：商城系统402，库存系统404，订单系统406、消息系统408。具体地，首先，商城系统402接收一个处理用户购买某个物品的分布式事务，为该分布式事务分配一个事务编号，然后在商城数据库中的事务表中插入一条记载该事务状态的记录，此时，事务状态为开启(BEGIN)，记录中除了包括事务状态还包括事务编号、业务流水号、业务类型、事务类型以及产生的时间等，表1为一个实施例中，事务表中的一条记录的示意图。

表1

进一步的，商城系统402根据预设的规则将该分布式事务分为两个子事务，一个是减库存，一个是新增订单，显然，可以采串行的方法进行子事务的处理，即先进行减库存，若减库存成功，再进行新增订单。所以商城系统402首先将减库存的子事务发送到库存系统404进行执行，库存系统404在库存前置表中进行减库存的操作，若操作成功，则在库存数据库中的事务表中插入一条标识子事务操作状态的记录，此时，事务状态为尝试完成(TRIED)。若操作失败，则说明没有足够库存，不会在库存事务表中插入任何记录。商城系统402若收到减库存操作成功的信息，将把新增订单的子事务发送到订单系统406进行执行，同样的，订单系统406在订单前置表中进行新增订单的操作，若操作成功，则在订单数据库中的事务表中插入一条标识子事务状态的记录，事务状态同样为尝试完成(TRIED)，若操作失败，则不会插入任务记录。商城系统402若收到减库存操作失败的信息，则不会再执行新增订单的操作，直接判定该分布式事务执行失败，然后将商城数据库中的事务表中的事务状态由开启(BEGIN)更新为回滚中(CANCELLING)。若减库存操作成功，而新增订单操作失败，同样的会判定该分布式事务执行失败，事务状态同样会由开启(BEGIN)更新为回滚中(CANCELLING)，然后向消息系统408发送取消消息，取消消息发送成功后，将会将商城数据库中事务表中的事务状态由回滚中(CANCELLING)更新为回滚完成(CANCELLED)。只有减库存和新增订单都操作成功，才会将商城数据库中事务表中的事务状态由开启(BEGIN)更新为尝试完成(TRIED)。然后向消息系统408发送确认消息，确认消息发送成功后，将会将商城数据库中事务表中的事务状态由尝试完成(TRIED)更新为确认完成(CONFIRMED)。消息系统408将取消消息或确认消息同时发送给库存系统404和订单系统406。库存系统404和订单系统406若收到的是确认消息，则经过消息去重后，将各自事务表中的事务状态由尝试完成(TRIED)更新为确认中(CONFIRMING)，然后根据事务表中之前操作前置表的记录将之前对库存前置表和订单前置表的操作同步到对应的库存主表和订单主表中，同步成功后，将各自事务表中的事务状态由确认中(CONFIRMING)更新为确认完成(CONFIRMED)，从而实现了事务的一致性。库存系统404和订单系统406若收到的是取消消息，则经过消息去重后，将各自事务表中的事务状态(若存在的话)由尝试完成(TRIED)更新为回滚中(CANCELLING)，然后根据事务表中之前操作前置表的记录对前置表进行回滚，然后将事务表中的事务状态由回滚中(CANCELLING)更新为回滚完成(CANCELLED)。需要说明的是，若在事务表中找不到对应的事务状态时，则不用进行任何处理，这是因为如果事务表中不存在对应的事务状态时，说明之前的操作失败或者是没有进行操作，所以就不需要进行回滚。此外，若商城系统或库存系统或订单系统突然故障或掉线，有可能出现事务表中的事务状态没能及时更新的情况，而为了事务能够保证事务最终一致性，需要在每个系统都布置一个检查机制，该检查机制用来监控各个事务的事务状态，若出现异常，则向消息系统重新发送确认消息或取消消息，以便更改事务的状态。举一个例子，若商城系统402向消息系统408发送确认消息成功后，还没来得及将事务表中的事务状态由确认中(CONFIRMING)更新为确认完成(CONFIRMED)，商城系统就出故障了，那么当商城系统402恢复后，事务状态还是处于确认中(CONFIRMING)，当检查机制发现事务状态一直处于确认中(CONFIRMING)时，则向消息系统重新发送确认消息，确认消息发送成功后，将会将商城数据库中事务表中的状态由确认中(CONFIRMING)更新为确认完成(CONFIRMED)。

如图5所示，在一个实施例中，提出了一种分布式事务处理系统，该述系统包括：

主业务系统502，用于接收分布式事务的开启请求，根据开启请求为分布式事务分配一个事务标识，将事务标识和对应的开启状态记录到主事务表中，主事务表存储在主业务数据库中，并将分布式事务分为多个子事务，分别向对应的各个从业务系统发送执行子事务的指令，指令中包括事务标识；

从业务系统504，从业务系统有多个，用于根据执行子事务的指令在从业务前置表中进行对应的操作，若操作成功，则根据事务标识生成一条标识当前子事务操作状态的记录插入到子事务表中，若操作失败，则不记录，其中，从业务前置表为从业务主表的复制表，从业务前置表和子事务表都存储在对应的从业务数据库中；

主业务系统502还用于获取各个子事务的操作结果，并根据操作结果更新主事务表中的操作状态，若所有子事务全部操作成功，则向消息系统发送确认消息，若至少一个子事务操作失败，则向消息系统发送取消消息；

消息系统506，用于将确认消息或取消消息发送给对应的各个从业务系统；

从业务系统504还用于若接收到的消息为确认消息，则将之前在从业务前置表中的操作同步到从业务主表中以完成对应子事务的提交，若接收到的消息为取消消息，则直接将之前在从业务前置表中的操作进行回滚。

在一个实施例中，主业务系统502还用于获取各个子事务的操作结果，若所有子事务全部操作成功，则将主事务表中的操作状态由开启状态更新为尝试完成，然后向消息系统发送确认消息，若消息发送成功，则将主事务表中的操作状态由尝试完成更新为确认完成；若至少一个子事务操作失败，则将主事务表中的操作状态由开启状态更新为回滚中，然后向消息系统发送取消消息，若消息发送成功，则将主事务表中的操作状态由回滚中更新为回滚完成。

在一个实施例中，从业务系统504还用于若收到的消息为确认消息，则根据确认消息将子事务表中的操作状态由尝试完成更新为确认中，然后根据子事务表中的操作记录将之前在从业务前置表中的操作同步到从业务主表中，若同步成功，则将子事务表中的状态更新为确认完成；若收到的消息为取消消息，则根据事务标识在子事务表中查找与该事务标识对应的操作状态，若能够查找到，则将操作状态更新为回滚中，然后根据子事务表中的操作记录将之前对从业务前置表的操作进行回滚，若回滚成功，则将子事务表中的操作状态更新为回滚完成，若查找不到，则结束。

在一个实施例中，主业务系统502将分布式事务分为多个子事务并设置各个子事务的执行顺序，按照执行顺序向对应的从业务系统发送执行子事务的指令，指令中包括事务标识，当接收到前一个子事务执行结果为成功时，才将后一个子事务的执行命令发送到对应的从业务系统，若接收到前一个子事务的执行结果为失败，则不再执行后面的子事务。

在一个实施例中，主业务系统502和各个从业务系统504还用于通过设置的检查机制监控主事务表或子事务表中事务的操作状态，若发现操作状态异常，则根据事务表中的记录向消息系统再次发送确认消息或取消消息以更改操作状态。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。