CN114466071B - 一种基于MQ PaaS的事务消息处理方法及装置 - Google Patents

Abstract

本发明提供一种基于MQ PaaS的事务消息处理方法及装置，其中的事务消息处理方法包括：获取目标事务消息，目标事务消息包括消息生产者的分组信息；根据目标事务消息的本地事务执行结果，对目标事务消息进行处理；其中，若本地事务执行结果为不知情，则根据消息生产者的分组信息，回查本地事务执行结果，该方法解决了现有技术中无法在MQ PaaS平台架构下实现事务消息的缺陷，使MQ PaaS平台架构下实现事务消息成为可能。

Description

一种基于MQ PaaS的事务消息处理方法及装置

技术领域

本发明涉及消息处理技术领域，尤其涉及一种基于MQ PaaS的事务消息处理方法及装置。

背景技术

目前通用的分布式事务实现方式包括两阶段提交（2 Phase Commit，简称2PC）、三阶段提交（3 Phase Commit，简称3PC）、两阶段补型事务（Try-Confirm-Concel，简称TCC）、事务消息和消息表，但对于MQ（Message Queue，简称消息队列）PaaS（Platform as aService，简称平台即服务）分布式消息平台而言，2PC、3PC和 TCC这些事务实现方式都过于复杂，不太适用，可行的是基于消息表和RocketMQ原生的事务实现方式。

对于基于消息表的事务实现方式，由于消息表基于关系型数据库，要求使用业务系统的数据库，还要求消息表与业务系统处在同一个事务中，所以，SDK（SoftwareDevelopment Kit，简称软件开发工具包）需要预先或者按照需求在业务数据库中创建消息表，而在业务数据库中创建消息表的操作对业务都有一定的侵入性，因此，对于分布式事务消息的实现而言，使用消息表的方式并不是首选，

对于RocketMQ原生的事务实现方式，事务实现的流程为：1)事务发起方首先发送准备消息到MQ；2)事务发起方在发送准备消息成功后执行本地事务；3) 根据本地事务执行结果返回commit（提交）或者是rollback（回滚）；4) 如果返回rollback，MQ将删除该准备消息不进行发送；如果返回commit，MQ将会把这个消息发送给Consumer端；5)如果执行本地事务过程中，执行端挂掉，或者超时，MQ将会不停地询问同组的其他producer来获取状态；6)Consumer端的消费成功机制由MQ保证。但该事务实现方式在MQ PaaS平台架构下，由于SDK并不与Broker（缓存代理）直连，无法回查本地事务状态，不能完整地实现事务消息。

因此，如何解决现有技术中无法在MQ PaaS平台架构下实现事务消息的问题，是消息处理技术领域亟待解决的重要课题。

发明内容

本发明提供一种基于MQ PaaS的事务消息处理方法及装置，用以解决现有技术中无法在MQ PaaS平台架构下实现事务消息的缺陷，以实现MQ PaaS平台架构下的事务消息。

一方面，本发明提供一种基于MQ PaaS的事务消息处理方法，包括：获取目标事务消息，所述目标事务消息包括消息生产者的分组信息；根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理；其中，若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果。

进一步地，所述若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果，包括：根据所述消息生产者的分组信息，依次查询生产者代理；基于所述生产者代理的查询反馈信息，回查所述本地事务执行结果。

进一步地，所述基于所述生产者代理的查询反馈信息，回查所述本地事务执行结果，包括：若查询的生产者代理为目标生产者代理，则响应所述目标生产者的查询确认信息，回查所述本地事务执行结果；若查询的生产者代理为非目标生产者代理，则响应所述非目标生产者代理的查询否定信息，继续查询其他尚未被查询的生产者代理。

进一步地，所述基于MQ PaaS的事务消息处理方法还包括：若回查得到的所述本地事务执行结果为不知情，则重复回查操作；若回查次数达到预设回查次数时，所述本地事务执行结果仍为不知情，则结束所述回查操作，并删除所述目标事务消息。

进一步地，所述基于MQ PaaS的事务消息处理方法还包括：若查询到所述目标生产者代理，则记录并保存所述消息生产者和该目标生产者代理之间的消息发送链路信息，以供再次回查时直接调用。

进一步地，所述根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理，包括：若所述本地事务执行结果为事务消息提交，则转发所述目标事务消息。

进一步地，所述根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理，还包括：若所述本地事务执行结果为事务消息回滚，则删除所述目标事务消息。

第二方面，本发明还提供一种基于MQ PaaS的事务消息处理装置，包括：事务消息获取模块，用于获取目标事务消息，所述目标事务消息包括消息生产者的分组信息；事务消息处理模块，用于根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理；其中，事务消息回查模块，用于若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果。

第三方面，本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述基于MQ PaaS的事务消息处理方法的步骤。

第四方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述基于MQ PaaS的事务消息处理方法的步骤。

第五方面，本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述任一种所述基于MQ PaaS的事务消息处理方法的步骤。

本发明提供的基于MQ PaaS的事务消息处理方法，通过获取带有消息生产者分组信息的目标事务消息，并根据该目标事务消息的本地事务执行结果，对目标事务消息进行处理，当本地事务执行结果为不知情时，则根据消息生产者的分组信息，回查本地事务执行结果，以进一步对目标事务消息进行处理，该方法弥补了现有技术中传统无法在MQ PaaS平台架构下实现事务消息的缺陷，使MQ PaaS平台架构下实现事务消息成为可能，并且，这种事务消息实现方式不依赖关系型数据库，所有操作均是在内存中进行，不会入侵业务，也不会影响中间件效率。

附图说明

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

图1为现有技术提供的传统Rocket MQ原生的事务实现方式的流程示意图；

图2为现有技术提供的传统Rocket MQ原生的事务实现方式的回查示意图；

图3为本发明提供的MQ PaaS平台架构下回查失败的逻辑示意图；

图4为本发明提供的基于MQ PaaS的事务消息处理方法的流程示意图；

图5为本发明提供的基于MQ PaaS的事务消息处理的主体交互图；

图6为本发明提供的基于MQ PaaS的事务消息处理装置的结构示意图；

图7是本发明提供的电子设备的结构示意图。

具体实施方式

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

图1示出了传统Rocket MQ原生的事务实现方式的流程示意图。如图1所示，事务发起方首先发送半消息到MQ Server，并在发送消息成功后执行本地事务，根据本地事务执行结果返回commit或者是rollback；若本地事务执行结果为rollback，MQ Server将删除该半消息不进行发送；如果是commit，MQ Server将会把这个消息发送给consumer端；如果在执行本地事务过程中，事务发起方挂掉，或者超时，MQ Server就会不停地询问其他的事务发起方，来获取本地事务的执行状态。

图2示出了传统Rocket MQ原生的事务实现方式的回查示意图。如图2所示，传统Rocket MQ原生的事务实现方式通过RocketMQ生产者与Broker直连进行消息发送，发送事务消息时，Broker很明确是由哪个RocketMQ生产者发送，并可以通过直接连接的RocketMQ生产者进行回查本地事务状态，从而决定事务消息是commit或者rollback。例如，图2中发送事务消息的是RMQ Producer 1，Broker回查时，也是通过查询RMQ Producer 1，以获取本地事务的执行状态。

但是，在MQ PaaS平台架构下，生产者客户端直接与代理层进行连接，代理层与Broker进行连接。也就是说，生产者客户端是不与Broker直连的，这样会导致在进行事务消息回查时，不能明确事务消息是由哪个生产者客户端发送的，从而导致无法回查本地事务状态。具体地，图3示出了MQ PaaS平台架构下回查失败的逻辑示意图。如图3所示，如果Broker回查PProxy1，则会回查失败，因为没有SDK Producer连接在它上面；而如果回查PProxy2或者PProxy3，同样地，由于Broker并不知道代理层与SDK Producer之间的联系，会导致事务消息回查失败。

考虑及此，本发明提供了一种基于MQ PaaS的事务消息处理方法，具体地，在一个实施例中，图4示出了本发明所提供的基于MQ PaaS的事务消息处理方法的流程示意图。如图4所示，该事务消息处理方法包括：

S401，获取目标事务消息，目标事务消息包括消息生产者的分组信息；

S402，根据目标事务消息的本地事务执行结果，对目标事务消息进行处理。

需要说明的是，在本实施例中，主要涉及三方主体，即消息生产者、生产者代理和Broker，其中，Broker是一种缓存代理，也是本实施例的执行主体，用于获取目标事务消息，并根据目标事务消息的本地事务执行结果，对目标事务消息进行相应的处理。另外，消息生产者与消息生产者之间存在一定的对应关系，对于具体对应方式，在此不作具体限定。

可以理解的是，消息生产者作为事务发起方，发送目标事务消息到生产者代理，生产者代理在接收目标事务消息后，直接将该目标事务消息转发至Broker。生产者代理在成功转发消息之后即返回，而消息生产者在成功发送消息之后，开始执行与目标事务消息相对应的本地事务，得到本地事务执行结果，并将该本地事务执行结果通过对应的生产者代理传递给Broker。Broker在接收到本地事务执行结果之后，根据本地事务执行结果，决定对目标事务消息的具体处理方式。

其中，目标事务消息是一种准备消息，与消息生产者所执行的本地事务相对应，并且，目标事务消息的消息头中记录有消息生产者的分组信息，以供后续步骤中Broker进行回查操作时使用。消息生产者首先通过生产者代理将目标事务消息发送至Broker，目的是为了告知Broker，它即将要执行某一本地事务，让Broker随时等待它的本地事务执行结果，以对目标事务消息作出及时的处理。

本地事务执行结果有多种，可以包括提交目标事务消息或者回滚目标事务消息。当然，若消息生产者在执行本地事务的过程中因出现故障而挂掉，或者消息生产者执行本地事务超出一定的时长久久没有反馈，则本地事务执行结果也可以为不知情。

S403，若本地事务执行结果为不知情，则根据消息生产者的分组信息，回查本地事务执行结果。

在这一步骤中，当消息生产者所返回的本地事务执行结果为不知情时，生产者代理不能得到与目标事务消息相对应的本地事务执行结果，Broker也不能接收到来自生产者代理的转发，从而导致Broker不能根据本地事务执行结果对目标事务消息进行提交或回滚处理。在这种情况下，Broker只能根据目标事务消息携带的特殊信息，即生产者的分组信息，查询与执行本地事务的消息生产者相对应的生产者代理，通过该生产者代理给消息生产者传递检查本地事务状态的信息，从而达到回查本地事务执行结果的目的。

其中，消息生产者通常都是通过分组进行管理，同组的消息生产者有多个，且同组的生产者均能执行或回查同一本地事务，也就是说，在查询对应的生产者代理时，只要能够查到具有相同组信息的消息生产者与该生产者代理连接，则认为该消息生产者可以回查本地事务执行结果。

在本实施例中，通过获取带有消息生产者分组信息的目标事务消息，并根据该目标事务消息的本地事务执行结果，对目标事务消息进行处理，当本地事务执行结果为不知情时，则根据消息生产者的分组信息，回查本地事务执行结果，以进一步对目标事务消息进行处理，该方法弥补了现有技术中无法在MQ PaaS平台架构下实现事务消息的缺陷，使MQPaaS平台架构下实现事务消息成为可能。

在上述实施例的基础上，进一步地，若本地事务执行结果为不知情，则根据消息生产者的分组信息，回查本地事务执行结果，包括：根据消息生产者的分组信息，依次查询生产者代理；基于生产者代理的查询反馈信息，回查本地事务执行结果；若查询的生产者代理为目标生产者代理，则响应目标生产者的查询确认信息，回查本地事务执行结果；若查询的生产者代理为非目标生产者代理，则响应非目标生产者代理的查询否定信息，继续查询其他尚未被查询的生产者代理。

可以理解的是，当本地事务执行结果为不知情时，根据消息生产者的分组信息，回查本地事务执行结果。具体地，Broker接收的目标事务消息中包括消息生产者的分组信息，位于同一分组的消息生产者均可执行目标事务消息相对应的本地事务，并返回相应的本地事务执行结果。若消息生产者在执行本地事务的过程中出现故障，或返回消息超时，使得生产者代理无法获取本地事务执行结果，Broker无法根据本地事务执行结果对目标事务消息进行处理，此时本地事务执行结果为不知情。

Broker根据消息生产者的分组信息，依次查询与其直接相连的生产者代理，相应的，每一个被查询的生产者代理接收到查询信号后，会检查自身是否与具有相同分组信息的消息生产者连接，并基于自身检查的结果，给出相应的查询反馈信息，Broker根据生产者代理的查询反馈信息，回查本地事务执行结果。

进一步地，若所查询的生产者代理通过自身检查，并未发现其与具有相同分组信息的消息生产者相连接，则该生产者代理并非Broker所要查询的目标生产者代理，为了使回查本地事务执行结果的操作继续进行，该非目标生产者代理会将查询否定的信息反馈给Broker，从而Broker会进一步地查询该非目标生产者代理以外的其他生产者代理，直到查询到目标生产者代理为止。

若所查询的生产者代理通过自身检查，发现其与具有同分组信息的消息生产者相连接，则该生产者代理为Broker所要查询的目标生产者代理，此时，目标生产者代理会发出查询确认的查询反馈信息，Broker根据目标生产者代理的反馈，作出响应，向目标生产者代理发出回查本地事务执行结果的信号，目标生产者代理将该回查信号直接转发至与其直连的消息生产者，消息生产者接收回查信号后，对本地事务执行结果的状态进行检查，再一次获取本地事务执行结果，并通过目标生产者代理反馈给Broker，由Broker根据本地事务执行结果对目标事务消息进行处理。

在本实施例中，通过根据消息生产者的分组信息，依次查询所有的生产者代理，并基于每一个被查询的生产者代理所给出的查询反馈信息，回查本地事务执行结果，解决了现有技术中传统无法在MQ PaaS平台架构下实现事务消息的缺陷，使MQ PaaS平台架构下实现事务消息成为可能。

在上述实施例的基础上，进一步地，该事务消息处理方法还包括：若回查得到的本地事务执行结果为不知情，则重复回查操作；若回查次数达到预设回查次数时，本地事务执行结果仍为不知情，则结束回查操作，并删除目标事务消息。

可以理解的是，Broker根据消息生产者的分组信息，回查本地事务执行结果，回查得到的本地事务执行结果，可以是目标事务消息提交，可以是目标事务消息回滚，也可以是不知情。若是提交或回滚目标事务消息，Broker直接进行相应的处理即可；若本地事务执行结果仍为不知情，则会继续执行回查操作。当然，若回查得到的本地事务执行结果一直为不知情，也不可能一直持续不断地进行回查。考虑及此，可以预先设置一个回查次数的阈值，当回查次数达到了预设回查次数，本地事务执行结果仍为不知情，便不再进行回查操作，直接删除目标事务消息。

在一个具体的实施例中，预设回查次数为15次，但前14次以及第15次回查得到的本地事务执行结果仍为不知情，这种情况下，结束回查操作，并删除目标事务消息。只要在15次回查操作中，有一次回查得到的本地事务执行结果为目标事务消息提交或回滚，Broker便可以对目标事务消息进行相应的处理，无需再进行回查操作。

在本实施例中，考虑到回查得到的本地事务执行结果可能会多次为不知情的情况，设置一个预设回查次数，在预设回查次数范围内，可重复执行回查操作，但若回查次数达到预设回查次数，本地事务执行结果仍为不知情，结束回查操作，并删除目标事务消息，可以在一定程度上节省操作时间。

在上述实施例的基础上，进一步地，该事务消息处理方法还包括：

若回查询到目标生产者代理，则记录并保存消息生产者和该目标生产者代理之间的消息发送链路信息，以供再次回查时直接调用。

可以理解的是，若根据消息生产者的分组信息，查询到了目标生产者代理，则可以将消息生产者和该目标生产者代理之间的消息发送链路信息记录并保存，以供下一次回查同一分组的消息生产者时，可以直接查询对应的生产者代理。其中，消息生产者与生产者代理之间存在一定的对应关系，这种对应关系可以是一对一、一对多、多对一或多对多，在此不作具体限定。

在本实施例中，通过保存消息生产者和生产者代理之间的消息发送链路关系，使得再次回查同一分组的消息生产者时，不用再依次查询生产者代理，直接回查记录对应的生产者代理即可，从而有效地提高回查效率。

在上述实施例的基础上，进一步地，根据目标事务消息的本地事务执行结果，对目标事务消息进行处理，包括：若本地事务执行结果为事务消息提交，则转发目标事务消息；若本地事务执行结果为事务消息回滚，则删除目标事务消息。

可以理解的是，本地事务执行结果可以是事务消息的提交或回滚，当本地事务执行结果为事务消息提交时，Broker直接转发目标事务消息；当本地事务执行结果为事务消息回滚时，则删除目标事务消息。事务消息的提交，意味着与目标事务消息相对应的本地事务的执行生效，而事务消息的回滚，则意味着消息生产者执行本地事务的操作将被撤销，回到最初没有执行本地事务的状态。

在本实施例中，通过根据不同的本地事务执行结果，对目标事务消息进行相应的处理，解决了现有技术中传统无法在MQ PaaS平台架构下实现事务消息的缺陷，使MQ PaaS平台架构下实现事务消息成为可能。

另外，图5示出了本发明提供的基于MQ PaaS的事务消息处理的主体交互图。如图5所示，本发明涉及三方主体，即消息生产者、生产者代理和Broker。具体地，消息生产者首先发出目标事务消息至生产者代理，生产者代理转发目标事务消息至Broker，生产者代理成功转发消息后即返回，消息生产者成功发送消息后开始执行本地事务，得到本地事务执行结果，并将包括提交或回滚目标事务消息的本地事务执行结果转发至生产者代理，生产者代理转发本地事务执行结果至Broker，Broker根据本地事务执行结果，对目标事务消息做出相应处理，即转发该目标事务消息或删除目标事务消息。若生产者代理和Broker均未收到提交或回滚目标事务消息的本地事务执行结果，则回查本地事务执行结果。通过查询与执行本地事务的消息生产者相对应的目标生产者代理，发送回查信号给对应的消息生产者，由该消息生产者检查本地事务结果，并将回查得到的本地事务执行结果通过生产者代理传递给Broker，Broker根据本地事务执行结果，进一步地对目标事务消息进行相应的处理。具体的回查方法已在前面的实施例中进行了阐述，在此不再赘述。

图6示出了本发明所提供的基于MQ PaaS的事务消息处理装置，该事务消息处理装置包括：事务消息获取模块601，用于获取目标事务消息，目标事务消息包括消息生产者的分组信息；事务消息处理模块602，用于根据目标事务消息的本地事务执行结果，对目标事务消息进行处理；其中，事务消息回查模块603，用于若本地事务执行结果为不知情，则根据消息生产者的分组信息，回查本地事务执行结果。

本发明提供的基于MQ PaaS的事务消息处理装置，与上文描述的基于MQ PaaS的事务消息处理方法可相互对应参照，在此不再一一赘述。

在本实施例中，通过事务消息获取模块601获取带有消息生产者分组信息的目标事务消息，事务消息处理模块602根据该目标事务消息的本地事务执行结果，对目标事务消息进行处理，当本地事务执行结果为不知情时，事务消息回查模块603根据消息生产者的分组信息，回查本地事务执行结果，以进一步对目标事务消息进行处理，该方法弥补了现有技术中无法在MQ PaaS平台架构下实现事务消息的缺陷，使MQ PaaS平台架构下实现事务消息成为可能。图7示例了一种电子设备的实体结构示意图，如图7所示，该电子设备可以包括：处理器（processor）710、通信接口（communications Interface）720、存储器（memory）730和通信总线740，其中，处理器710，通信接口720，存储器730通过通信总线740完成相互间的通信。处理器710可以调用存储器730中的逻辑指令，以执行基于MQ PaaS的事务消息处理方法，该方法包括：获取目标事务消息，所述目标事务消息包括消息生产者的分组信息；根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理；其中，若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果。

此外，上述的存储器730中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各方法所提供的基于MQ PaaS的事务消息处理方法，该方法包括：获取目标事务消息，所述目标事务消息包括消息生产者的分组信息；根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理；其中，若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各方法提供的基于MQ PaaS的事务消息处理方法，该方法包括：获取目标事务消息，所述目标事务消息包括消息生产者的分组信息；根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理；其中，若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (9)

1.一种基于MQ PaaS的事务消息处理方法，其特征在于，包括：

获取目标事务消息，所述目标事务消息包括消息生产者的分组信息；

根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理；其中，

若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果；

所述若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果，包括：

根据所述消息生产者的分组信息，依次查询生产者代理；

基于所述生产者代理的查询反馈信息，回查所述本地事务执行结果。

2.根据权利要求1所述的基于MQ PaaS的事务消息处理方法，其特征在于，所述基于所述生产者代理的查询反馈信息，回查所述本地事务执行结果，包括：

若查询的生产者代理为目标生产者代理，则响应所述目标生产者的查询确认信息，回查所述本地事务执行结果；

若查询的生产者代理为非目标生产者代理，则响应所述非目标生产者代理的查询否定信息，继续查询其他尚未被查询的生产者代理。

3.根据权利要求2所述的基于MQ PaaS的事务消息处理方法，其特征在于，还包括：

若回查得到的所述本地事务执行结果为不知情，则重复回查操作；

若回查次数达到预设回查次数时，所述本地事务执行结果仍为不知情，则结束所述回查操作，并删除所述目标事务消息。

4.根据权利要求2所述的基于MQ PaaS的事务消息处理方法，其特征在于，还包括：

若查询到所述目标生产者代理，则记录并保存所述消息生产者和该目标生产者代理之间的消息发送链路信息，以供再次回查时直接调用。

5.根据权利要求1所述的基于MQ PaaS的事务消息处理方法，其特征在于，所述根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理，包括：

若所述本地事务执行结果为事务消息提交，则转发所述目标事务消息。

6.根据权利要求1所述的基于MQ PaaS的事务消息处理方法，其特征在于，所述根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理，还包括：

若所述本地事务执行结果为事务消息回滚，则删除所述目标事务消息。

7.一种基于MQ PaaS的事务消息处理装置，其特征在于，包括：

事务消息获取模块，用于获取目标事务消息，所述目标事务消息包括消息生产者的分组信息；

事务消息处理模块，用于根据所述目标事务消息的本地事务执行结果，对所述目标事务消息进行处理；其中，

事务消息回查模块，用于若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果；

所述若所述本地事务执行结果为不知情，则根据所述消息生产者的分组信息，回查所述本地事务执行结果，包括：

根据所述消息生产者的分组信息，依次查询生产者代理；

基于所述生产者代理的查询反馈信息，回查所述本地事务执行结果。

8.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至6任一项所述基于MQ PaaS的事务消息处理方法的步骤。

9.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述基于MQ PaaS的事务消息处理方法的步骤。

Images