CN101364997A - 基于网络的分布式事务处理方法和系统 - Google Patents

Abstract

本发明提供了基于网络的分布式事务处理方法和系统，其中，所述方法为至少包含第一业务系统和第二业务系统的业务系统组，其组内的各个业务系统通过消息中间件进行信息交互，完成一次业务，包括：第一业务系统执行第一业务后向消息中间件发送第一业务消息；消息中间件根据所述第一业务消息指示第二业务系统执行第二业务；第二业务系统执行第二业务后向消息中间件发送第二业务消息，从而解决了基于网络的分布式事务，本发明有着很好的通用性，能够地应用于各种大型分布式事务处理系统。

Description

基于网络的分布式事务处理方法和系统

技术领域

本发明涉及网络技术领域，特别是涉及基于网络的分布式事务处理方法和系统。

背景技术

随着网络技术的发展，网络中不同业务系统间存在着越来越多的信息交互，存在很多相互关联的业务。例如，电子商务领域中，某用户通过网络购买某种商品，就可能涉及到订单系统和支付系统，或者更多的业务系统，要完成购买某种商品这样一件事情，需要这两个或者多个不同的业务系统之间在相互关联的业务上具有一致性，这就需要对不同系统之间相互关联的事务要进行分布式事务处理。

分布式事务是指两个或更多资源，比如两个不同的业务系统之间的事务。在分布式事务处理环境中，多个不同的业务系统共同完成一个工作，这个工作即是一个全局事务。如前所述，某用户通过网络购买某种商品就是一个全局事务，它需要订单系统、支付系统甚至更多的系统共同来完成。

目前的分布式事务处理多是针对数据库而言，如XA规范，可以用来处理数据库分布式事务，例如我们要从数据库中获取某个最终的数据，但是这个数据涉及到多个数据库，需要采用分布式的方式分别获得，在解决这个问题时，XA规范采用二阶段提交来完成，第一阶段各个数据库进行预提交，当中间件确认所有数据库都可以提交自身所要提交的数据时，中间件正式提交各个数据库要提交的数据，否则，则撤销此次提交。

这种单纯的针对数据库的分布式事务处理方法很显然不能用来解决不同业务系统间的分布式事务。

数据库外的分布式事务处理只有简单的事务同步机制，如Quartz，它就是一个定时重试机制，很显然，也不能解决不同业务系统间的分布式事务。

综上，在实现本发明过程中，发明人发现，目前针对不同业务系统间的分布式事务还没有非常好的解决方案。

发明内容

鉴于上述问题，本发明实施例提供了基于网络的分布式事务处理方法和系统，以解决不同业务系统间的分布式事务。

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

一种实现基于网络的分布式事务处理方法，至少包含第一业务系统和第二业务系统的业务系统组，其组内的各个业务系统通过消息中间件进行信息交互，完成一次业务，包括：

第一业务系统执行第一业务后向消息中间件发送第一业务消息；

消息中间件根据所述第一业务消息指示第二业务系统执行第二业务；

第二业务系统执行第二业务后向消息中间件发送第二业务消息。

上述方法还包括：

上述方法还包括：

第N业务系统执行第N业务后向消息中间件发送第N业务消息；

或者，

消息中间件根据其他业务消息指示第N业务系统执行第N业务。

所述其他业务消息至少包括一个所述业务组中除第N业务系统之外的业务系统所发送的业务消息。

所述第一业务消息或者第二业务消息或者第N业务消息中携带业务信息，具体包括：

业务内容和业务执行状态。

所述业务执行状态包括：业务成功、业务失败或者业务未完成。

所述业务系统组内的各个业务系统在执行自身的业之前向消息中间件发送业务通知消息，在所述业务通知消息中，携带所述业务的业务信息，所述业务信息中，携带的该业务的业务状态为未完成状态。

在所述业务系统组内的各个业务系统在执行自身的业之前向消息中间件发送业务通知消息之后，还包括：

所述消息中间件存储所述通知消息。

上述方法还包括：

当所述消息中间件在预设时限后没有收到与其存储的通知消息所对应业务的业务系统所发送的业务成功或者业务失败的消息时，所述消息中间件向所述业务系统发送业务查询消息，查询所述业务的业务状态。

上述方法还包括：

当所述消息中间收到业务系统所发送的业务成功或者业务失败的消息时将自身存储的与所述业务相对应的通知消息删除。

一种实现基于网络的分布式事务处理的系统，包括消息中间件以及至少由第一业务系统和第一业务系统组成的业务系统组，所述业务系统组内的业务系统通过消息中间件进行信息交互，其中，

所述第一业务系统，用于执行完第一业务后向所述消息中间件发送第一业务消息；

所述消息中间件，用于根据所述第一业务消息指示第二业务系统执行第二业务；

所述第二业务系统，用于执行完第二业务后向所述消息中间件发送第二业务消息。

上述系统还包括：

第N业务系统，用于执行第N业务后向消息中间件发送第N业务消息；或者，

用于接收消息中间件根据第一业务消息而发出的业务指示，并根据所述业务指示执行第N业务。

所述第一业务消息或者第二业务消息或者第N业务消息包括：

业务执行状态和业务内容。

所述业务执行状态包括：业务成功、业务失败或者业务未完成。

所述消息中间件还用于接收业务系统组中的各个业务系统在执行业务前发送的业务通知消息。

所述消息中间件还用于存储各个业务系统发送的业务通知消息。

所述消息中间件还用于在预设时限后没有收到与自身存储的业务通知消息所对应业务的业务系统发送的业务成功或者业务失败的消息时，向所述业务系统发送业务查询消息，查询所述业务的业务状态。

所述消息中间件还用于在收到业务系统所发送的业务成功或者业务失败的消息时将自身存储的与所述业务相对应的通知消息删除。

可见，在本发明实施例中，至少包含第一业务系统和第二业务系统的业务系统组，其组内的各个业务系统通过消息中间件进行信息交互，完成一次业务，包括：第一业务系统执行第一业务后向消息中间件发送第一业务消息；消息中间件根据所述第一业务消息指示第二业务系统执行第二业务；第二业务系统执行第二业务后向消息中间件发送第二业务消息，从而解决了基于网络的分布式事务，本发明有着很好的通用性，能够地应用于各种大型分布式事务处理系统。

此外，因为本发明采用以消息为载体控制分布式系统的事务，所以通常情况下，消息可以即时送达目的地，从而保证了业务的实时性。

附图说明

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

图1为本发明实施例所提供的方法的流程图；

图2为本发明另一实施例所提供的方法的信令流图；

图3为本发明另一实施例所提供的方法的信令流图；

图4为本发明实施例所提供的系统的结构示意图。

具体实施方式

本发明实施例提供了基于网络的分布式事务处理方法和系统，下面结合附图对本发明实施例进行详细描述。

参见图1，实现本发明实施例所提供的方法为至少包含第一业务系统和第二业务系统的业务系统组，其组内的各个业务系统通过消息中间件进行信息交互，完成一次业务，具体包括：

步骤101：第一业务系统向消息中间件发送业务通知消息。

本发明实施例所描述的方法用来解决一个全局性事务由多个不同的业务系统来共同完成的问题。

第一业务系统在执行业务之前通过业务通知消息告知消息中间件自身将要执行的业务，在所述通知消息中，携带有该系统所要执行的业务信息，所述业务信息包括业务内容和业务状态，因为该业务还未被执行，所以在该业务信息中，该业务的业务状态为未完成(half)状态。

步骤102：消息中间件回复收到所述业务通知消息。

消息中间件收到第一业务系统发送的业务通知消息后，通过消息回应第一业务系统；所述第一业务系统在发送业务通知消息后一直等待，如果收到失败回应或者超时，则可返回到上一步，直到收到成功回应，则进入下一步。

步骤103：第一业务系统执行第一业务。

步骤104：第一业务系统向消息中间件发送第一业务消息；

第一业务消息中携带有业务信息，该业务信息包括业务内容和业务执行状态，当第一业务系统执行完第一业务后，通过第一业务消息将此次业务的业务内容和业务执行状态告知消息中间件。

此时的业务状态包括业务成功和业务失败两种情况。

如果此次业务失败，则使得总的业务终止，业务流程结束。

如果此次业务成功，则执行步骤105。

步骤105：消息中间件根据所述第一业务消息指示第二业务系统执行第二业务。

第一业务消息中包含有业务内容，所以根据业务内容，消息中间件才能指导第二业务系统执行第二业务。

步骤106：第二业务系统向消息中间件发送第二业务消息。

在第二业务系统执行完第二业务后，通过第二业务消息将第二业务的业务内容和业务状态告知消息中间件。

如果第二业务状态的第二业务成功执行，则此次由第一业务系统和第二业务系统联合执行的一个总的业务就顺利执行完成，本发明实施例所提供的方法成功地解决了一个需要由第一业务系统和第二业务系统共同来完成的全局性事务，实现了基于网络，包含至少两个业务系统的分布式事务处理。

本发明实施例所提供的方案可以广泛地适用于各种大型的分布式应用，下面，以电子商务中的网络交易为例，对本发明实施例做进一步说明。参见图2，在本发明实施例中，某个客户希望通过网络购买商品，全局事务即为网络购物，假设它涉及到的系统是订单系统和支付系统，那么，本发明实施例所提供的方法具体包括：

步骤201：消费者在订单系统成功下单后，订单系统向消息中间件发送业务通知消息。

在业务通知消息中携带此次业务信息，包括此次业务的业务内容和业务状态。

其中，业务内容可以包括订单号，产品单价，数量，总金额，交易时间等。当参与执行一个全局事务的业务系统不同时，所执行的业务和业务内容一定会有所区别，本发明实施例对此不做限定。

此时，系统业务还未执行，所以此时的业务状态为half状态。

步骤202：消息中间件对订单系统的业务通知消息进行回复，返回接收结果。

消息中间件收到订单系统发送的业务通知消息后，通过消息回应订单系统；所述订单在发送业务通知消息后一直等待，如果收到失败回应或者超时，则可返回到上一步，直到收到成功回应，则进入下一步。

步骤203：订单系统执行订单业务，将订单数据保存到自身的数据库。

步骤204：订单系统向消息中间件发送订单业务消息。

在订单业务消息中携带有此次订单业务的业务信息，仍然包括业务内容和业务状态，其中业务内容与业务通知消息中携带的业务内容相同，但是业务状态就有所变化。因为此时订单业务已经执行过，所以有成功(commit)和失败(rollback)两种情况，消息中间件通过接收到的订单业务消息判断当次订单业务是否成功。

步骤205：订单业务成功时，消息中间件将订单业务消息转发给支付系统，指导所述支付系统执行支付业务。

步骤206：支付系统根据订单业务消息执行支付业务。

步骤207：支付业务执行完成后，向消息中间件发送支付业务消息。

在支付业务消息中携带有此次支付业务的业务信息，同样包括业务内容和业务状态，此时的业务内容包括业务流水号，对应的订单号，支付款项，支付时间等等。此时的业务状态也有成功和失败两种情况，如果此次支付业务成功，则成功地完成了此次网络购物。

在实际应用中，为了进一步地对一次业务进行跟踪，在步骤202之后，还包括：

步骤202a：消息中间件存储所述业务通知消息。

在步骤204之后还包括：

步骤204b：所述消息中间件在预设时限后没有收到与其存储的通知消息所对应业务的业务系统所发送的业务成功或者业务失败的消息时，所述消息中间件向所述业务系统发送业务查询消息，查询所述业务的业务状态。

当然，在实际应用中，为了保证消息中间件有效运转，提高它的利用率，步骤204之后，还包括：

步骤204b’：当所述消息中间收到业务系统所发送的业务成功或者业务失败的消息时将自身存储的与所述业务相对应的通知消息删除。

通过步骤204b，有效地避免了某个业务系统的业务执行成功，仅仅因为业务状态消息没有及时发送到消息中间件而导致整个业务失败的情况，为分布式事务处理提供了有效的保障，此外步骤204b’也为消息中间件的顺利运转提供了有力的保障。

在实际应用中，一个全局性事务所涉及到的业务形态可能更多，例如有3个，4个或者N个，而且，可能作为先决条件的系统业务可能也不止一个，后续的系统业务也可能有多个，实际上，不论一个全局事务由几个业务系统合作完成，所采用的方法都是相同的，参见图3，在本发明实施例中，某个全局事务需要四个系统协作完成，描述上的方便将四个业务系统用A、B、C和D来代指，该方法具体包括：

步骤301a：A向消息中间件发送A业务通知消息。

步骤301b：B向消息中间件发送B业务通知消息。

这里A和B是两个彼此独立的业务系统，所以它们分别向消息中间件发送业务通知消息。它们可以是同时完成，所以这里都是用步骤401来表示，只是用a和b对这两个步骤进行区别。

当然业务通知消息中携带的业务信息中是它们各自的业务内容，用A和B进行区别，但是业务状态都是half。

步骤302a：消息中间件回复收到所述A业务通知消息，并对该消息进行存储。

消息中间件收到A业务系统发的业务通知消息后，通过消息回应A业务系统；所述A业务系统在发送业务通知消息后一直等待，如果收到失败回应或者超时，则可返回到步骤302a，直到收到成功回应，则进入步骤303a。

步骤302b：消息中间件回复收到所述B业务通知消息，并对该消息进行存储。

消息中间件收到B业务系统发的业务通知消息后，通过消息回应B业务系统；所述B业务系统在发送业务通知消息后一直等待，如果收到失败回应或者超时，则可返回到步骤302b，直到收到成功回应，则进入步骤303a。

步骤303a：A执行A业务。

步骤303b：B执行B业务。

步骤304a：A向消息中间件发送A业务消息。

步骤304b：B向消息中间件发送B业务消息。

A业务消息中携带有业务信息，该业务信息包括业务内容和业务执行状态，此时业务状态为commit。

B业务消息中携带有业务信息，该业务信息包括业务内容和业务执行状态，此时业务状态为commit。

步骤305c：消息中间件综合所述A业务消息和B业务消息指示C执行C业务。

步骤305d：消息中间件综合所述A业务消息和B业务消息指示D执行D业务。

这里用305c和305d两个步骤来区分分别由C和D执行的步骤，但是在应用中这两个步骤也可以同时执行。

步骤306c：C业务系统向消息中间件发送C业务消息。

步骤306d：D业务系统向消息中间件发送D业务消息。

其中C业务消息中业务状态为commit，D业务消息中业务状态也为commit，通过本发明实施例所提供的方法，实现了基于网络，包含A、B、C、D四个业务系统的分布式事务处理。

其他需要由更多的业务系统协作完成一个全局事务的情况都与本发明实施例类似，都只是数量上的增加和步骤上的重复，这里不再赘述。

与方法实施例相对应，本发明实施例还提供实现基于网络的分布式事务处理的系统，参见图4，所述系统包括消息中间件以及至少由第一业务系统和第二业务系统组成的业务系统组，所述业务系统组内的业务系统通过消息中间件进行信息交互，其中，

所述第一业务系统401，用于执行完第一业务后向所述消息中间件发送第一业务消息。

其中，所述业务消息中携带业务信息，具体包括：业务执行状态和业务内容，而其中业务状态有业务未完成，业务成功和业务失败三种。

所述消息中间件402，用于根据所述第一业务消息指示第二业务系统执行第二业务。

所述第二业务系统403，用于执行完第二业务后向所述消息中间件发送第二业务消息。

在实际应用中，一个全局性事务所涉及到的业务形态可能更多，例如有3个，4个或者N个，而且，可能作为先决条件的系统业务可能也不止一个，所以，所述系统还包括：

第N业务系统404，用于执行第N业务后向消息中间件发送第N业务消息；或者，用于接收消息中间件根据第一业务消息而发出的业务指示，并根据所述业务指示执行第N业务。

所述消息中间件402还用于，综合所述第一业务消息和第N业务消息指示第二业务系统执行第二业务；或者，根据第一业务消息指导第N业务系统执行第N业务。

为了进一步地对一次业务进行跟踪，所述消息中间件402还用于，接收各个业务系统在执行业务前发送的业务通知消息，并对所述业务通知消息进行存储。

在对业务通知消息进行存储之后，所述消息中间件还用于，在预设时限后没有收到与自身存储的业务通知消息所对应业务的业务系统发送的业务成功或者业务失败的消息时，向所述业务系统发送业务查询消息，查询所述业务的业务状态。

很显然，正是各个业务系统在执行业务前向消息中间件发送了通知消息，消息中间件又对该消息进行了存储，所以为对该业务进行追踪奠定了基础，当网络出现故障或者因为其他的一些原因导致本来执行成功的业务消息没有传送到消息中间件时，消息中间件通过查询的方式对与通知消息对应的业务状态进行再一次的确认，为整个业务的成功提供了更多一层的保证。

然而，虽然说消息中间件对接收到的业务通知消息进行存储为业务跟踪奠定了基础，但是，消息中间件的容量是有限的，所以，为了保证消息中间件有效运转，提高它的利用率，所述消息中间件402还用于：当收到业务系统所发送的业务消息时将自身存储的与所述业务相对应的通知消息删除。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (17)

1、一种实现基于网络的分布式事务处理方法，其特征在于，至少包含第一业务系统和第二业务系统的业务系统组，其组内的各个业务系统通过消息中间件进行信息交互，完成一次业务，包括：

第一业务系统执行第一业务后向消息中间件发送第一业务消息；

消息中间件根据所述第一业务消息指示第二业务系统执行第二业务；

第二业务系统执行第二业务后向消息中间件发送第二业务消息。

2、根据权利要求1所述的方法，其特征在于，还包括：

第N业务系统执行第N业务后向消息中间件发送第N业务消息；或者，

消息中间件根据其他业务消息指示第N业务系统执行第N业务。

3、根据权利要求2所述的方法，其特征在于，所述其他业务消息至少包括一个所述业务组中除第N业务系统之外的业务系统所发送的业务消息。

4、根据权利要求1或2所述的方法，其特征在于，所述第一业务消息、第二业务消息、其他业务消息或者第N业务消息中携带业务信息，具体包括：

业务内容和业务执行状态。

5、根据权利要求4所述的方法，其特征在于，所述业务执行状态包括：业务成功、业务失败或者业务未完成。

6、根据权利要求4所述的方法，其特征在于，所述业务系统组内的各个业务系统在执行自身的业务之前向消息中间件发送业务通知消息，在所述业务通知消息中，携带所述业务的业务信息，所述业务信息中，携带的该业务的业务状态为未完成状态。

7、根据权利要求6所述的方法，其特征在于，在所述业务系统组内的各个业务系统在执行自身的业务之前向消息中间件发送业务通知消息之后，还包括：

所述消息中间件存储所述通知消息。

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

当所述消息中间件在预设时限后没有收到与其存储的通知消息所对应业务的业务系统所发送的业务成功或者业务失败的消息时，所述消息中间件向所述业务系统发送业务查询消息，查询所述业务的业务状态。

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

当所述消息中间收到业务系统所发送的业务成功或者业务失败的消息时将自身存储的与所述业务相对应的通知消息删除。

10、一种实现基于网络的分布式事务处理的系统，其特征在于，包括消息中间件以及至少由第一业务系统和第一业务系统组成的业务系统组，所述业务系统组内的业务系统通过消息中间件进行信息交互，其中，

所述第一业务系统，用于执行完第一业务后向所述消息中间件发送第一业务消息；

所述消息中间件，用于根据所述第一业务消息指示第二业务系统执行第二业务；

所述第二业务系统，用于执行完第二业务后向所述消息中间件发送第二业务消息。

11、根据权利要求10所述的系统，其特征在于，还包括：

第N业务系统，用于执行第N业务后向消息中间件发送第N业务消息；或者，

用于接收消息中间件根据第一业务消息而发出的业务指示，并根据所述业务指示执行第N业务。

12、根据权利要求10或11所述的系统，其特征在于，所述第一业务消息或者第二业务消息或者第N业务消息包括：

业务执行状态和业务内容。

13、根据权利要求12所述的系统，其特征在于，所述业务执行状态包括：业务成功、业务失败或者业务未完成。

14、根据权利要求10所述的系统，其特征在于，所述消息中间件还用于接收业务系统组中的各个业务系统在执行业务前发送的业务通知消息。

15、根据权利要求14所述的系统，其特征在于，所述消息中间件还用于存储各个业务系统发送的业务通知消息。

16、根据权利要求15所述的系统，其特征在于，所述消息中间件还用于在预设时限后没有收到与自身存储的业务通知消息所对应业务的业务系统发送的业务成功或者业务失败的消息时，向所述业务系统发送业务查询消息，查询所述业务的业务状态。

17、根据权利要求16所述的系统，其特征在于，所述消息中间件还用于在收到业务系统所发送的业务成功或者业务失败的消息时将自身存储的与所述业务相对应的通知消息删除。

Images