CN111897825A

CN111897825A - 分布式事务处理方法和装置

Info

Publication number: CN111897825A
Application number: CN202010485956.0A
Authority: CN
Inventors: 杨猛; 张娜; 欧创新; 孟庆峰; 于灏; 刘震; 潘曦; 马南; 刘皓
Original assignee: Peoples Insurance Company of China
Current assignee: Peoples Insurance Company of China
Priority date: 2020-06-01
Filing date: 2020-06-01
Publication date: 2020-11-06

Abstract

本说明书实施例公开了一种分布式事务处理方法、装置、电子设备以及计算机可读存储介质。该方法包括：第一用户将生产的消息推送至消息队列中，并将消息推送状态记录至预先建立的消息推送状态表中；根据消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至消息队列；通过消息队列，将推送至消息队列的消息投递至第二用户，并将消息投递信息记录至预先建立的消息接收状态表中，以使第二用户根据所述消息接收状态表消费消息。

Description

分布式事务处理方法和装置

技术领域

本说明书实施例涉及计算机技术领域，尤其涉及分布式事务处理方法、装置、电子设备和计算机可读存储介质。

背景技术

目前云计算、大数据、互联网领域的很多业务系统都采用了分布式架构。在一致性要求较高的分布式架构中，分布式事务成为关键点。目前主流的分布式事务解决方案主要包括：两阶段XA方案、补偿方案(例如，Try-Confirm-Cancel，TCC方案)以及基于异步确保的消息队列方案等。其中，消息队列方案，由于开发成本相对较低、应用场景较广被广泛采用，但采用消息队列方案，要求确保消息幂等性和消息一致性。

研究人员发现，有些消息队列技术采用确认机制来保证消息的发送和接收，这种机制在网络异常、生产者和/或消费者异常等情况下，可能会出现生产者发送消息失败、生成者重复生产消息、消费者重复消费消息等特殊情况。也有些消息队列技术提供事务消息机制，即可实现消息事务与本地事务的同时提交或回滚，但事务消息机制无法解决因本地事务失败或消息事务失败等特殊情况而造成的分布式事务中消息不一致的问题。

如何在这些特殊情况下，确保消息幂等性和消息一致性是本领域技术人员需要解决的。

发明内容

本说明书实施例提供一种分布式事务处理方法、装置、电子设备以及计算机可读存储介质，以解决在一些特殊情况下如何确保分布式事务中消息幂等性和消息一致性的问题。

本说明书实施例采用下述技术方案：

一种分布式事务处理方法，包括：

第一用户将生产的消息推送至消息队列中，并将消息推送状态记录至预先建立的消息推送状态表中；

根据所述消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至所述消息队列；

通过所述消息队列，将推送至所述消息队列的消息投递至第二用户，并将消息投递信息记录至预先建立的消息接收状态表中，以使所述第二用户根据所述消息接收状态表消费消息。

一种分布式事务处理装置，包括：

推送记录模块，用于第一用户将生产的消息推送至消息队列中，并将消息推送状态记录至预先建立的消息推送状态表中；

推送模块，用于根据所述消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至所述消息队列；

投递记录模块，用于通过所述消息队列，将推送至所述消息队列的消息投递至第二用户，并将消息投递信息记录至预先建立的消息接收状态表中，以使所述第二用户根据所述消息接收状态表消费消息。

一种电子设备，包括：存储器、处理器及存储在所在存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现任一项所述的分布式事务处理方法的步骤。

一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现任一项所述的分布式事务处理方法的步骤。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：

本说明书实施例通过将消息推送状态记录在消息推送状态表中，再将消息推送状态为推送失败的消息重新推送至消息队列，可以保障消息可以成功推送至消息队列，从而在分布式事务中确保消息的一致性。另外，通过记录消息投递信息至消息接收状态表中，可以使得第二用户根据消息接收记录表中记录的消息投递信息消费消息，从而可以避免第二用户重复消费消息，以确保消息的幂等性。

附图说明

此处所说明的附图用来提供对本说明书实施例的进一步理解，构成本说明书实施例的一部分，本说明书实施例的示意性实施例及其说明用于解释本说明书实施例，并不构成对本说明书实施例的不当限定。在附图中：

图1为本说明书实施例提供的分布式事务处理方法的流程示意图；

图2为本说明书实施例提供的分布式事务中消息队列运行机制的流程示意图；

图3为本说明书实施例提供的分布式事务处理装置的结构示意图；

图4为本说明书实施例提供的电子设备结构示意图。

具体实施方式

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

以下结合附图，详细说明本说明书各实施例提供的技术方案。

研究人员发现，由于某些消息队列，例如，腾讯云消息队列(Cloud MessageQueue,CMQ)，存在消息确认机制，这使得在网络异常、生产者和/或消费者异常等情况下，可能会出现生产者发送消息失败、生成者重复生产消息、消费者重复消费消息等特殊情况。

其中，消息确认机制包括生产者消息确认和消费者消息确认。具体来说，生产者消息确认包括：生产者向消息队列发送消息后，等待消息队列回复确认，在消息队列向生产者返回确认成功后执行本地事务，否则在生产者请求超时、消息队列返回消息持久化失败等情况下，生产者需要向消息队列重新推送消息。消费者消息确认包括：消息队列向消费者投递消息后，将消息置为不可见，在消息不可见时间内，消费者在消费消息后使用句柄删除消息，如果由于网络异常、消费者异常等导致消息未被删除，且不可见的时间超出预设值，消息将重新可见，消息队列会重新该消息投递至消费者。

为解决上述技术问题，本说明书实施例提供了一种分布式事务处理方法，用于确保分布式事务中消息幂等性和消息一致性。该方法的流程示意图如图1所示，包括下述步骤：

步骤11：第一用户将生产的消息推送至消息队列中，并将消息推送状态记录至预先建立的消息推送状态表中。

在实际应用中，第一用户可以是消息的生成者，例如，在保险行业中，投保系统可以是生产者，投保系统生成的保单信息可以是生成的消息。

在实际应用中，分布式系统架构中，第一用户生成的消息不仅可以通过执行本地事务将该消息存储于本地数据库中，还可以发送至需要该消息的第二用户，例如，投保系统生产的保单信息，不仅可以存储于本地数据库，还可以发送至理赔系统、财务系统等，以便于进行理赔处理或财务处理等。

如上文所述，在分布式系统架构中，将第一用户生产的消息发送至第二用户时，即，生成者生产的消息发送至消费者消费，可以通过消息队列实现，由于网络异常、生产者异常等情况下，可能会出现生产者发送消息失败的情况，从而无法保证分布式事务中消息的一致性，本说明书实施例通过预先建立消息推送状态表，在第一用户将生产的消息推送至消息队列中后，将消息推送状态记录至该预先建立的消息推送状态表中。

在实际应用中，消息推送状态包括推送成功和推送失败。可以理解的是，消息推送成功代表生产者生产的消息到达消息队列，且消息队列返回消息持久化成功。则在消息推送成功的情况下，将消息推送状态记录至该预先建立的消息推送状态表中，可以包括，在消息队列返回消息持久化成功时，将推送成功状态记录至消息推送状态表中。

相应的，消息推送失败代表生成者生产的消息未到达消息队列，例如，网络异常导致请求超时使得消息未到达消息队列，或消息到达消息队列而消息队列返回消息持久化失败。则在消息推送失败的情况下，将消息推送状态记录至预先建立的消息推送状态表中，可以包括，在消息队列返回消息持久化失败或请求超时的情况下，将推送失败状态记录至消息推送状态表中。

在本说明一个或多个实施例中，第一用户生产的消息可以包括消息内容和消息标识，则在第一用户将生产的消息推送至消息队列中，并将消息推送状态记录至预先建立的消息推送状态表中，还可以包括：将消息内容和消息标识记录至预先构建的消息推送状态表中。

其中，消息标识可以用于唯一标识消息内容，也就是说，消息标识可以用于区分消息内容，也可以用于分区不同消息内容的消息推送状态。在实际应用中，消息标识可以使用保单号、支付编号或者订单号等，当然也可以采用随机算法生成的字符串等，对此本申请不做限制。

在实际应用中，消息推送记录表中，除了消息标识、消息内容，消息推送状态，还可以记录消息推送次数和最后一次推送时间。例如，表1所示的可以是一种消息推送记录表。

表1：消息推送状态表

需要注意的是，上述消息推送状态表中包含的字段，是本说明书实施例提供的一种具体实施方式，并不代表本说明书全部实施方式，对于字段的名称、赋值等可以根据实际需求确定，当然也根据需求设置其它字段，对此本说明书实施例不做限制。

步骤12：根据消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至消息队列。

可以理解的是，对于消息推送状态为推送失败的消息，可以进行重试推送，即将推送状态为推送失败的消息推送至消息队列。在实际应用中，推送失败的消息相较于推送成功的消息来说占比可能较小，也就是说，一段时间内记录的推送失败的消息可能较少，那么为了避免占用过多的计算机资源，可以在预设定时周期内，定时执行将消息推送状态表中记录的推送失败的消息推送至消息队列，则在本说明书一个或多个实施例中，根据消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至消息队列，可以包括：

按照预设定时周期，定时遍历消息推送状态表中的消息推送状态；

在遍历到消息推送状态为推送失败状态的消息时，将消息推送状态为推送失败状态的消息推送至消息队列。

其中，按照预设定时周期，定时遍历消息推送状态表中的消息推送状态，可以通过设置定时器任务的方式实现。

在实际应用中，以表1所示的消息推送状态表为例，遍历到消息推送状态为推送失败状态的消息，可以是遍历到status的值为0的消息，对于如何遍历出推送失败的消息，本说明书实施例不做限制。

在实际应用中，预设定时周期可以根据实际需求设置为固定时间间隔，例如，5秒或30秒等。当然也可以结合消息推送状态表中记录的消息推送次数和最后一次推送时间，设置为递增的时间间隔，例如，递增的时间间隔可以设置为按照间隔5秒、30秒、180秒和900秒等，那么对于某条推送失败的消息，消息推送状态记录推送失败次数为1，最后一次推送时间为12:00，那么该条消息为第一次推送失败的消息，则可以在5秒后，即12:05重试推送，若12:05重试推送失败，则记录推送失败次数为2，则在30秒后，即12:35再重试推送，依次类推。在实际应用中，对超过1天仍然推送失败的消息取消推送，并记录错误信息，以备开发人员确认推送失败的原因。

步骤13：通过消息队列，将推送至消息队列的消息投递至第二用户，并将消息投递信息记录至预先建立的消息接收状态表中，以使第二用户根据消息接收状态表消费消息。

在实际应用中，消息队列具有发布订阅模式，即，消费者订阅消息队列的主题队列，消息队列根据消费者订阅的主题队列，将该主题队列中的消息投递给消费者。这里的第二用户可以是消费者，即，可以是需求第一用户生产的消息的用户，例如上文所述的理赔系统或财务系统等。

在实际应用中，消息队列为了保证消息送达消费者，使用了消息确认机制，使得消息可能被重复投递至消费者，例如，由于网络异常等原因，消息队列收不到消费者的返回的确认信息，会重复向消费者投递消息。这就是导致消费者可能重复消费消息。在本说明书实施例中，通过建立消息接收状态表，将消息投递信息记录至预先建立的消息接收状态表中，以使第二用户可以根据消息接收状态表消费消息，以避免出现消息重复消费问题，确保消息幂等性。

如上文所述，消息可以包括消息内容和消息标识，消息标识可以用于唯一标识该消息内容，那么通过消息标识可以判断消息队列是否重复投递消息，则在本说明书实施例中，将消息投递信息记录至预先建立的消息接收状态表中，可以包括：将消息的消息标识和消息内容记录至预先建立的消息接收状态表中。以便于根据消息标识判断是否为重复投递的消息。

在实际应用中，消息接收记录表中除了记录消息标识和消息内容，还可以根据需求记录消息接收次数和最后一次消息接收时间等，以便于开发人员查找重复投递原因等。例如表2所示的可以是一种消息接收状态表。

表2：消息接收状态表

字段	说明
		biz_id	消息标识，每条消息对应唯一消息标识
msg	消息内容
		r_count	初始为0，根据biz_id判断每接收一次重复消息，值增加1
receivetime	最后一次接收时间

需要注意的是，上述消息接收状态表中包含的字段，是本说明书实施例提供的一种具体实施方式，并不代表本说明书全部实施方式，对于字段的名称、赋值等可以根据实际需求确定，当然也根据需求设置其它字段，对此本说明书实施例不做限制。

基于消息接收状态表，为避免重复消费，在本说明书一个或多个实施例中，第二用户根据消息接收状态表消费消息，可以包括；

根据消息接收状态表中的消息标识，判断消息队列投递的消息是否为重复投递消息；

若为重复投递消息，则在消费重复投递消息中的一条消息后，将重复投递消息从消息队列中删除。

可以理解的是，在第一次接收消息队列投递的某条消息后，消息接收状态表中可以记录该条消息的消息标识和消息内容，若消息队列又投递该条消息，则可以根据消息标识判断出该条消息为重复投递消息，那么可以在消费第一次投递的该条消息后，不再消费后续重复投递的消息，并将该条重复投递的消息从消息队列中删除。在实际应用中，消费重复投递消息中的一条消息，可以是消费第一次投递的消息，当然也可以消费最后一次投递的消息，对此本申请不做限制。

本说明书实施例中，通过将消息推送状态记录在消息推送状态表中，再将消息推送状态为推送失败的消息重新推送至消息队列，可以保障消息可以成功推送至消息队列，从而在分布式事务中确保消息的一致性。另外，通过记录消息投递信息至消息接收状态表中，可以使得第二用户根据消息接收记录表中记录的消息投递信息消费消息，从而可以避免第二用户重复消费消息，以确保消息的幂等性。

以上为本说明书实施例提供的一种分布式事务处理方法，本说明书实施例还提供一种该分布式事务处理方法的具体实施场景，本说明书实施例结合如图2所示的一种分布式事务中消息队列运行机制的流程示意图，介绍该分布式事务处理方法的具体实施方式。

步骤1:生产者向消息队列服务端(MQ server)推送半消息(Half消息)，该半消息为暂不能投递的消息。

步骤2：在MQ Server将消息持久化成功之后，向生产者返回确认半消息已经发送成功，或在生产者请求超时、MQ Server返回消息持久化失败等情况下，将该半消息的消息推送状态记录至预先建立的消息推送状态表中，根据消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至消息队列MQ Serve。

步骤3:生产者接收到消息队列返回的确认半消息发送成功后，开始执行本地事务，例如，执行向本地数据库中写入生成者生产的消息数据的事务。

步骤4：生产者根据本地事务执行状态向MQ Server提交二次确认请求，该二次确认请求包括投递消息(commit)或不投递消息(rollback)，MQ Server收到commit请求后，将半消息标记为可投递，并向消费者投递该消息，并将消息投递信息记录至预先建立的消息接收状态表中，以使消费者根据消息接收状态表消费消息；MQ Server收到rollback请求，则删除该半消息或直接将该半消息置为已消费状态，消费者将不会接受该消息。

步骤5：在断网或者是生产者应用重启等特殊情况下，步骤4提交的二次确认请求未到达MQ Server时，MQ Server将对该消息发起消息回查请求，即，回查本地事务执行状态。

步骤6：生产者收到消息回查请求，检查对应消息的本地事务的执行状态。

步骤7：生产者根据检查到的本地事务的执行状态，再次提交二次确认请求，MQServer按照步骤4对半消息进行处理操作。

在本说明书实施例中，在基于消息队列的分布式事务中，通过应用本说明书实施例提供的分布式事务处理方法，可以在由网络异常、生产者和/或消费者异常等，导致的生产者发送消息失败、生成者重复生产消息、消费者重复消费消息等特殊情况下，确保消息幂等性和消息一致性。

以上为本说明书实施例所提供的分布式事务处理方法，基于相同的发明构思，本说明书实施例还提供了相应的分布式事务处理装置。如图3所示，该装置具体包括：

推送记录模块21，用于第一用户将生产的消息推送至消息队列中，并将消息推送状态记录至预先建立的消息推送状态表中；

推送模块22，用于根据所述消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至所述消息队列；

投递记录模块23，用于通过所述消息队列，将推送至所述消息队列的消息投递至第二用户，并将消息投递信息记录至预先建立的消息接收状态表中，以使所述第二用户根据所述消息接收状态表消费消息。

上述装置实施例的具体工作流程可以包括：推送记录模块21，第一用户将生产的消息推送至消息队列中，并将消息推送状态记录至预先建立的消息推送状态表中；推送模块22，根据所述消息推送状态表中消息推送状态，将消息推送状态为推送失败状态的消息推送至所述消息队列；投递记录模块23，通过所述消息队列，将推送至所述消息队列的消息投递至第二用户，并将消息投递信息记录至预先建立的消息接收状态表中，以使所述第二用户根据所述消息接收状态表消费消息。

在一种实施方式中，所述推送模块22，包括：

遍历单元，用于按照预设定时周期，定时遍历所述消息推送状态表中的消息推送状态；

推送单元，用于在遍历到所述消息推送状态为推送失败状态的消息时，将所述消息推送状态为推送失败状态的消息推送至所述消息队列。

在一种实施方式中，所述消息包括消息内容和消息标识，所述装置还包括：记录模块，用于将所述消息内容和所述消息标识记录至所述预先构建的消息推送状态表中。

在一种实施方式中，所述投递记录模块23，包括：

记录单元，用于将所述消息的消息标识和消息内容记录至所述预先建立的消息接收状态表中。

在一种实施方式种，所述装置，还包括：消费模块，用于第二用户根据所述消息接收状态表消费消息。

在一种实施方式中，所述消费模块，包括：

判断单元，用于根据所述消息接收状态表中的消息标识，判断所述消息队列投递的消息是否为重复投递消息；

消费单元，用于若为重复投递消息，则在消费所述重复投递消息中的一条消息后，将所述重复投递消息从所述消息队列中删除。

在本说明书实施例中，通过将消息推送状态记录在消息推送状态表中，再将消息推送状态为推送失败的消息重新推送至消息队列，可以保障消息可以成功推送至消息队列，从而在分布式事务中确保消息的一致性。另外，通过记录消息投递信息至消息接收状态表中，可以使得第二用户根据消息接收记录表中记录的消息投递信息消费消息，从而可以避免第二用户重复消费消息，以确保消息的幂等性。

本说明书实施例还提出了一种电子设备，示意图请参考图4，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成应用分布式事务处理装置。处理器，执行存储器所存放的程序，并至少用于执行以下操作：

上述如本说明书实施例图1所示实施例揭示的分布式事务处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(CentralProcessing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本说明书实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本说明书实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图1中分布式事务处理装置执行的方法，并实现分布式事务处理装置在图1所示实施例的功能，本说明书实施例在此不再赘述。

本说明书实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图1所示实施例中分布式事务处理装置执行的方法，并至少用于执行：

本领域内的技术人员应明白，本说明书实施例的实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书实施例是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其它数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其它类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其它内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其它光学存储、磁盒式磁带，磁带磁磁盘存储或其它磁性存储设备或任何其它非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。

Claims

1.一种分布式事务处理方法，其特征在于，包括：

2.如权利要求1所述的方法，其特征在于，根据所述消息推送状态表中消息推送状态，将所述消息推送状态为推送失败状态的消息推送至所述消息队列，包括：

按照预设定时周期，定时遍历所述消息推送状态表中的消息推送状态；

在遍历到所述消息推送状态为推送失败状态的消息时，将所述消息推送状态为推送失败状态的消息推送至所述消息队列。

3.如权利要求1所述的方法，其特征在于，所述消息包括消息内容和消息标识，所述方法还包括：将所述消息内容和所述消息标识记录至所述预先构建的消息推送状态表中。

4.如权利要求3所述的方法，其特征在于，所述将消息投递信息记录至预先建立的消息接收状态表中，包括：

将所述消息的消息标识和消息内容记录至所述预先建立的消息接收状态表中。

5.如权利要求4所述的方法，其特征在于，所述第二用户根据所述消息接收状态表消费消息，包括：

根据所述消息接收状态表中的消息标识，判断所述消息队列投递的消息是否为重复投递消息；

若为重复投递消息，则在消费所述重复投递消息中的一条消息后，将所述重复投递消息从所述消息队列中删除。

6.一种分布式事务处理装置，其特征在于，包括：

7.如权利要求6所述的装置，其特征在于，所述推送模块，包括：

8.如权利要求6所述的装置，其特征在于，所述消息包括消息内容和消息标识，所述装置还包括：记录模块，用于将所述消息内容和所述消息标识记录至所述预先构建的消息推送状态表中。

9.一种电子设备，其特征在于，包括：存储器、处理器及存储在所在存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至5中任一项所述的分布式事务处理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述的分布式事务处理方法的步骤。