CN105988861A - 事务消息的发送方法和装置 - Google Patents

Abstract

本发明提出一种事务消息的发送方法和装置，上述事务消息的发送方法包括：接收消息中心发送的事务回查请求，所述事务回查请求中携带消息标识，用于请求查询所述消息标识对应的本地事务的提交状态；查询数据库中是否存在所述消息标识对应的事务回查记录；如果存在，则通知所述消息中心投递携带所述消息标识的消息。本发明通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，从而大大降低了事务提交状态的判断复杂度。

Description

事务消息的发送方法和装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种事务消息的发送方法和装置。

背景技术

事务是并发控制的单位，是用户定义的一个操作序列，具体来说，事务就是访问数据库时一系列的逻辑相关动作。比如列车订票系统中选择目的地(或车次)、选择日期和时间、选择座位(或上下铺)、出票(总票数减一张)和付费，这一系列的业务处理构成一个事务。

事务中的业务处理要么都执行，要么都不执行，是一个不可分割的工作单位。通过事务，服务器可以将逻辑相关的一组业务绑定在一起，以便服务器保持数据的完整性。

需要发送带事务的消息时，应用系统会在业务处理的过程中向消息中心投递一个消息，但是这时消息中心不会立即将消息投递出去，在本地事务提交后，应用系统会向消息中心发送事务提交信息，以通知消息中心可以将消息投递出去，这时消息中心才会将消息投递出去。

但是应用系统向消息中心发送事务提交信息这一步骤可能由于网络调用超时或者其他原因断掉，导致消息中心无法确认消息是需要投递，还是删除，所以消息中心会发起事务回查，以确保应用系统的本地事务的提交状态与消息的投递状态一致。

现有技术中，事务提交状态的判断是根据业务数据的状态来进行的，但是由于事务中各业务对数据的更改，所以业务数据的状态的判断是非常复杂的，执行难度较大。

发明内容

本发明的目的旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明的第一个目的在于提出一种事务消息的发送方法。该方法通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，从而大大降低了事务提交状态的判断复杂度。

本发明的第二个目的在于提出一种事务消息的发送装置。

为了实现上述目的，本发明第一方面实施例的事务消息的发送方法，包括：接收消息中心发送的事务回查请求，所述事务回查请求中携带消息标识，用于请求查询所述消息标识对应的本地事务的提交状态；查询数据库中是否存在所述消息标识对应的事务回查记录；如果存在，则通知所述消息中心投递携带所述消息标识的消息。

本发明实施例的事务消息的发送方法，接收消息中心发送的事务回查请求，当查询到数据库中存在上述事务回查请求中携带的消息标识对应的事务回查记录时，就可以确定上述消息标识对应的本地事务已提交，于是就可以通知消息中心投递携带上述消息标识的消息，从而可以通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，大大降低了事务提交状态的判断复杂度。

为了实现上述目的，本发明第二方面实施例的事务消息的发送装置，包括：接收模块，用于接收消息中心发送的事务回查请求，所述事务回查请求中携带消息标识，用于请求查询所述消息标识对应的本地事务的提交状态；查询模块，用于查询数据库中是否存在所述接收模块接收的消息标识对应的事务回查记录；通知模块，用于当所述查询模块确定所述数据库中存在所述接收模块接收的消息标识对应的事务回查记录时，通知所述消息中心投递携带所述消息标识的消息。

本发明实施例的事务消息的发送装置，接收模块接收消息中心发送的事务回查请求，当查询模块查询到数据库中存在上述事务回查请求中携带的消息标识对应的事务回查记录时，就可以确定上述消息标识对应的本地事务已提交，于是通知模块就可以通知消息中心投递携带上述消息标识的消息，从而可以通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，大大降低了事务提交状态的判断复杂度。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明事务消息的发送方法一个实施例的流程图；

图2为本发明事务消息的发送方法另一个实施例的流程图；

图3为本发明事务消息的发送方法再一个实施例的流程图；

图4为本发明事务消息的发送装置一个实施例的结构示意图；

图5为本发明事务消息的发送装置另一个实施例的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

图1为本发明事务消息的发送方法一个实施例的流程图，如图1所示，该事务消息的发送方法可以包括：

步骤101，接收消息中心发送的事务回查请求，上述事务回查请求中携带消息标识，用于请求查询上述消息标识对应的本地事务的提交状态。

步骤102，查询数据库中是否存在上述消息标识对应的事务回查记录。

其中，该事务回查记录包括消息标识字段、该事务回查记录的创建时间字段和上述事务回查记录的最后修改时间字段。

本实施例中设计了专门用于事务回查的数据结构，即事务回查记录的数据结构，可以如表1所示。

表1

字段	说明
		Message_id	消息的唯一标识
Create_dt	事务回查记录的创建时间
		Modified_dt	事务回查记录的最后修改时间

步骤103，如果存在，则通知消息中心投递携带上述消息标识的消息。

本实施例中，步骤102，查询数据库中是否存在上述消息标识对应的事务回查记录之后，如果上述数据库中不存在上述消息标识对应的事务回查记录，则通知消息中心删除携带上述消息标识的消息。

进一步地，接收消息中心发送的事务回查请求之前，还可以开启本地事务，在上述本地事务中增加向数据库中插入事务回查记录的操作，在上述本地事务中包含的操作均执行完毕之后，向数据库提交本地事务。

进一步地，在本地事务中增加向数据库中插入事务回查记录的操作之后，还可以向消息中心发送本地事务对应的消息，上述消息中携带上述消息标识。

本实施例中，上述消息所携带的消息标识即为发送该消息的本地事务的事务回查记录中消息标识字段的值。

上述实施例中，接收消息中心发送的事务回查请求，当查询到数据库中存在上述事务回查请求中携带的消息标识对应的事务回查记录时，就可以确定上述消息标识对应的本地事务已提交，于是就可以通知消息中心投递携带上述消息标识的消息，从而可以通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，大大降低了事务提交状态的判断复杂度。

图2为本发明事务消息的发送方法另一个实施例的流程图，如图2所示，该事务消息的发送方法可以包括：

步骤201，应用系统开启本地事务，在上述本地事务中增加向数据库中插入事务回查记录的操作。

其中，上述事务回查记录的数据结构可以如表1所示。

步骤202，应用系统执行本地事务中包含的操作，并向消息中心发送本地事务对应的消息。其中，该消息中携带消息标识，该消息标识即为上述本地事务的事务回查记录中消息标识字段的值。

步骤203，判断本地事务中包含的操作是否均被成功执行完毕。如果否，则执行步骤204；如果本地事务中包含的操作均被成功执行完毕，则执行步骤205。

步骤204，本地事务回滚，数据库中的数据不会发生任何更改，然后应用系统通知消息中心删除上述本地事务对应的消息。

步骤205，本地事务提交，数据库中的数据发生相应更新，然后应用系统通知消息中心投递上述本地事务对应的消息。

而如果由于网络调用超时或者其他原因断掉，使得应用系统无法通知到消息中心是投递还是删除上述本地事务对应的消息，这就导致消息中心无法确认消息是需要投递，还是删除，所以消息中心会发起事务回查，如图3所示，图3为本发明事务消息的发送方法再一个实施例的流程图，图3所示实施例对消息中心发起事务回查的过程进行介绍，可以包括：

步骤301，应用系统接收消息中心发送的事务回查请求，上述事务回查请求中携带消息标识，用于请求查询上述消息标识对应的本地事务的提交状态。

步骤302，应用系统查询数据库中是否存在上述消息标识对应的事务回查记录。如果存在，则执行步骤303；如果数据库中不存在上述消息标识对应的事务回查记录，则执行步骤304。

步骤303，应用系统通知消息中心投递携带上述消息标识的消息。

步骤304，应用系统通知消息中心删除携带上述消息标识的消息。

上述实施例通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，大大降低了事务提交状态的判断复杂度。

下面通过一个举例对本发明所提供的事务消息的发送方法的具体实现过程进行说明。

设想网上购物的一次交易，其付款过程至少包括以下几步数据库操作：

一、更新客户所购商品的库存信息；

二、保存客户付款信息--可能包括与银行系统的交互；

三、生成订单并且保存到数据库中；

四、更新用户相关信息，例如购物数量等等。

正常的情况下，这些操作将顺利进行，最终交易成功，与交易相关的所有数据库信息也成功地更新。但是，如果在这一系列过程中任何一个环节出了差错，例如在更新商品库存信息时发生异常、该顾客银行账户存款不足等，都将导致交易失败。一旦交易失败，数据库中所有信息都必须保持交易前的状态不变，比如最后一步更新用户信息时失败而导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态——库存信息没有被更新、用户也没有付款，订单也没有生成。否则，数据库的信息将会一片混乱而不可预测。

数据库事务正是用来保证这种情况下交易的平稳性和可预测性的技术。

本例中，可以开启一个本地事务，该本地事务包含网上购物的一次交易所包括的四步操作：更新客户所购商品的库存信息、保存客户付款信息、生成订单并且保存到数据库中和更新用户相关信息，并且在本地事务中增加向数据库中插入事务回查记录的操作。然后，应用系统执行本地事务中的操作，并向消息中心发送本地事务对应的消息，该消息携带消息标识，该消息标识即为上述本地事务对应的事务回查记录中消息标识字段的值。具体到本例中，本地事务对应的消息可以为通知用户本次购物已成功，订单已经在配送中的通知消息。如果应用系统成功执行完本地事务包含的所有操作，则向数据库提交本地事务，这时数据库中的数据将发生相应更新，然后应用系统可以通知消息中心发送上述本地事务对应的消息。而如果本地事务包含的操作中有任何一个执行失败，本地事务回滚，数据库中的数据不会发生任何更改，这时应用系统将通知消息中心删除上述本地事务对应的消息。

但是如果由于网络调用超时或者其他原因断掉，使得应用系统无法通知到消息中心是投递还是删除上述本地事务对应的消息，这就导致消息中心无法确认消息是需要投递，还是需要删除，所以消息中心会发起事务回查，向应用系统发送事务回查请求，上述事务回查请求中携带消息标识，用于请求查询上述消息标识对应的本地事务的提交状态，然后应用系统查询数据库中是否存在上述消息标识对应的事务回查记录，如果存在，则应用系统可以确定上述消息标识对应的本地事务已经成功提交，于是通知消息中心投递携带上述消息标识的消息；而如果数据库中不存在上述消息标识对应的事务回查记录，则应用系统可以确定上述消息标识对应的本地事务未被提交，于是通知消息中心删除携带上述消息标识的消息。从而可以通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，大大降低了事务提交状态的判断复杂度。

图4为本发明事务消息的发送装置一个实施例的结构示意图，本实施例中的事务消息的发送装置可以作为应用系统，或应用系统的一部分实现本发明图1所示实施例的流程，如图4所示，上述事务消息的发送装置可以包括：接收模块41、查询模块42和通知模块43；

其中，接收模块41，用于接收消息中心发送的事务回查请求，上述事务回查请求中携带消息标识，用于请求查询上述消息标识对应的本地事务的提交状态。

查询模块42，用于查询数据库中是否存在接收模块41接收的消息标识对应的事务回查记录；其中，该事务回查记录包括消息标识字段、该事务回查记录的创建时间字段和上述事务回查记录的最后修改时间字段。具体地，事务回查记录的数据结构可以如表1所示。

通知模块43，用于当查询模块42确定上述数据库中存在接收模块41接收的消息标识对应的事务回查记录时，通知消息中心投递携带上述消息标识的消息。

进一步地，通知模块43，还用于当查询模块42确定上述数据库中不存在上述消息标识对应的事务回查记录时，通知消息中心删除携带上述消息标识的消息。

上述事务消息的发送装置中，接收模块41接收消息中心发送的事务回查请求，当查询模块42查询到数据库中存在上述事务回查请求中携带的消息标识对应的事务回查记录时，就可以确定上述消息标识对应的本地事务已提交，于是通知模块43就可以通知消息中心投递携带上述消息标识的消息，从而可以通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，大大降低了事务提交状态的判断复杂度。

图5为本发明事务消息的发送装置另一个实施例的结构示意图，与图4所示的事务消息的发送装置相比，不同之处在于，图5所示的事务消息的发送装置还可以包括：开启模块44、增加模块45和提交模块46；

其中，开启模块44，用于在接收模块41接收消息中心发送的事务回查请求之前，开启本地事务；

增加模块45，用于在开启模块44开启的本地事务中增加向数据库中插入事务回查记录的操作；

提交模块46，用于在上述本地事务中包含的操作均执行完毕之后，向数据库提交本地事务。

进一步地，上述事务消息的发送装置还可以包括：

发送模块47，用于在增加模块45在上述本地事务中增加向数据库中插入事务回查记录的操作之后，向消息中心发送上述本地事务对应的消息，该消息中携带上述消息标识。本实施例中，上述消息所携带的消息标识即为发送该消息的本地事务的事务回查记录中消息标识字段的值。

上述事务消息的发送装置可以通过增加事务回查记录的数据结构，将复杂的逻辑判断改为对事务回查记录的存在性判断，大大降低了事务提交状态的判断复杂度。

需要说明的是，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(Programmable Gate Array；以下简称：PGA)，现场可编程门阵列(Field ProgrammableGate Array；以下简称：FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (9)

1.一种事务消息的发送方法，其特征在于，包括：

接收消息中心发送的事务回查请求，所述事务回查请求中携带消息标识，用于请求查询所述消息标识对应的本地事务的提交状态；

查询数据库中是否存在所述消息标识对应的事务回查记录；

如果存在，则通知所述消息中心投递携带所述消息标识的消息。

2.根据权利要求1所述的方法，其特征在于，所述查询数据库中是否存在所述消息标识对应的事务回查记录之后，还包括：

如果所述数据库中不存在所述消息标识对应的事务回查记录，则通知所述消息中心删除携带所述消息标识的消息。

3.根据权利要求1或2所述的方法，其特征在于，所述接收消息中心发送的事务回查请求之前，还包括：

开启本地事务，在所述本地事务中增加向数据库中插入事务回查记录的操作；

在所述本地事务中包含的操作均执行完毕之后，向所述数据库提交所述本地事务。

4.根据权利要求3所述的方法，其特征在于，所述在所述本地事务中增加向数据库中插入事务回查记录的操作之后，还包括：

向所述消息中心发送所述本地事务对应的消息，所述消息中携带所述消息标识。

5.根据权利要求1或2所述的方法，其特征在于，所述事务回查记录包括消息标识字段、所述事务回查记录的创建时间字段和所述事务回查记录的最后修改时间字段。

6.一种事务消息的发送装置，其特征在于，包括：

接收模块，用于接收消息中心发送的事务回查请求，所述事务回查请求中携带消息标识，用于请求查询所述消息标识对应的本地事务的提交状态；

查询模块，用于查询数据库中是否存在所述接收模块接收的消息标识对应的事务回查记录；

通知模块，用于当所述查询模块确定所述数据库中存在所述接收模块接收的消息标识对应的事务回查记录时，通知所述消息中心投递携带所述消息标识的消息。

7.根据权利要求6所述的装置，其特征在于，

所述通知模块，还用于当所述查询模块确定所述数据库中不存在所述消息标识对应的事务回查记录时，通知所述消息中心删除携带所述消息标识的消息。

8.根据权利要求6或7所述的装置，其特征在于，还包括：

开启模块，用于在所述接收模块接收消息中心发送的事务回查请求之前，开启本地事务；

增加模块，用于在所述开启模块开启的本地事务中增加向数据库中插入事务回查记录的操作；

提交模块，用于在所述本地事务中包含的操作均执行完毕之后，向所述数据库提交所述本地事务。

9.根据权利要求8所述的装置，其特征在于，还包括：

发送模块，用于在所述增加模块在所述本地事务中增加向数据库中插入事务回查记录的操作之后，向所述消息中心发送所述本地事务对应的消息，所述消息中携带所述消息标识。