CN105592117A - 一种事务消息的处理方法和装置 - Google Patents

Abstract

本申请实施例提供了一种事务消息的处理方法和装置，所述的方法包括：生成事务消息；针对所述事务消息添加指定的处理状态标识；将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。本申请实施例用以以较小的代价保证事务消息的发送结果和事务的业务处理逻辑的一致性。

Description

一种事务消息的处理方法和装置

技术领域

本申请涉及消息处理的技术领域，特别是涉及一种事务消息的处理方法和一种事务消息的处理装置。

背景技术

在分布式的网络环境下，业务***之间需要进行消息的交互以完成关联的业务，为了降低业务***之间的耦合性，通常采用异步可靠消息来进行消息的交互。异步可靠消息一般分为普通消息和事务消息。普通消息与发送结果不绑定。作为发送端的业务***，在执行本地事务时，不依赖普通消息的发送结果，即使普通消息发送失败，也可以按照本地事务的业务处理逻辑继续执行相应的操作。由于不能保证普通消息的发送结果和本地事务的业务处理逻辑的一致性，因此，在对一致性要求严格的场景通常选用事务消息。事务消息与发送结果绑定。在执行本地事务时，依赖事务消息的发送结果，即事务消息发送结果和本地事务的业务处理逻辑保持一致。

在具体实现中，如果发送端发事务消息失败，则需要回滚本地事务，此外，如果在发送端本地事务执行失败，也需要回滚事务消息，以保证发送结果和本地事务的业务处理逻辑的一致性。目前事务消息一般采用两阶段提交的方式，并将事务消息的状态分为未决状态和已提交状态。事务消息两阶段提交的方式具体为：

第一阶段，在发送端进行本地事务的处理时操作业务数据库，并将本地事务于事务消息绑定，在本地事务执行过程中发送未决状态的事务消息到消息服务器，消息服务器将该事务消息持久化到消息数据库；

第二阶段，在发送端确定事务消息是提交或者回滚，此时会发送指示提交或回滚的消息到消息服务器，如果是指示回滚的消息，消息服务器会删除先前持久化到消息数据库的未决状态消息，如果是指示提交的消息，消息服务器会将事务消息的状态从未决状态更新为已提交状态，然后再进行投递。

如果在第二阶段的事务消息发送失败，消息服务器会回查发送端咨询事务消息的状态，消息服务器咨询该事务消息的状态后，决定对事务消息是要提交还是回滚。

由此可知，事务消息的两阶段提交方式的缺点主要有：

1、消息量倍增。由于事务消息是两阶段提交，而每一个阶段都需要发送一条事务消息，这意味着执行本地事务过程中的一次事务消息的发送动实际上需要发送用两次才能发送，从而使消息量增加了一倍，加重了网络负载、消息服务器负担以及消息数据库的事务消息数。

2、需要实现回查逻辑。如果第二阶段的事务消息未能成功发送到消息服务器，消息服务器需要回查发送端，以决定事务消息的提交或回滚。实现事务消息回查逻辑，实现较为复杂，且需要一定的代价。

因此，目前需要本领域技术人员迫切解决的一个技术问题就是：提出一种事务消息的处理机制，用以以较小的代价保证事务消息的发送结果和事务的业务处理逻辑的一致性。

申请内容

本申请实施例所要解决的技术问题是提供一种事务消息的处理方法，用以以较小的代价保证事务消息的发送结果和事务的业务处理逻辑的一致性。

相应的，本申请实施例还提供了一种事务消息的处理装置，用以保证上述方法的实现及应用。

为了解决上述问题，本申请公开了一种事务消息的处理方法，所述的方法包括：

生成事务消息；

针对所述事务消息添加指定的处理状态标识；

将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；

若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。

优选地，在针对所述事务消息添加指定的处理状态标识的步骤之后，还包括：

将所述具有处理状态标识的事务消息存储到预设的数据库中。

优选地，所述方法还包括：

判断是否将所述具有指定的处理状态标识的事务消息发送至消息服务器；

若是，则执行所述将事务消息发送至消息服务器的步骤；

若否，则删除所述事务消息。

本申请实施例还公开了一种事务消息的处理方法，包括：

接收到发送端发送的具有指定的处理状态标识的事务消息；

依据所述处理状态标识投递所述事务消息；

若成功投递所述事务消息，则接收到针对所述事务消息的通知；

依据所述通知删除发送端的事务消息。

优选地，所述方法还包括：

若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述投递状态信息包括投递次数、下次投递时间和/或接收端的标识。

优选地，所述方法还包括：

按照预设时间间隔从所述发送端获取所述指定的处理状态标识的事务消息；

重新尝试投递所述事务消息。

本申请实施例还公开了一种事务消息的处理装置，所述的装置包括：

第一生成模块，用于生成事务消息，并针对所述事务消息添加指定的处理状态标识；

发送模块，用于将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；

第一接收模块，用于若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。

优选地，所述装置还包括：

存储模块，用于将所述具有处理状态标识的事务消息存储到预设的数据库中。

优选地，所述装置还包括：

判断模块，用于判断是否将所述指定的处理状态标识的事务消息发送至消息服务器；若是，则调用发送模块；若否，则删除所述事务消息。

本申请实施例还公开了一种事务消息的处理装置，包括：

第二接收模块，用于接收到发送端发送的具有指定的处理状态标识的事务消息；

第一投递模块，用于依据所述处理状态标识投递所述事务消息；

通知模块，用于若成功投递所述事务消息，则接收到针对所述事务消息的通知；

删除模块，用于依据所述通知删除发送端的事务消息。

优选地，所述装置还包括：

第二生成模块，用于若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述投递状态信息包括投递次数、下次投递时间和/或接收端的标识。

优选地，所述装置还包括：

获取模块，用于按照预设时间间隔从所述发送端获取所述指定的处理状态标识的事务消息；

第二投递模块，用于重新尝试投递所述事务消息。

与现有技术相比，本申请实施例包括以下优点：

在本申请实施例中，在本地业务***执行事务的过程中生成事务消息，并且为该事务消息添加指定的处理状态标识，当事务消息发送至消息服务器时，消息服务器则可以依据所述处理状态标识将所述事务消息进行投递，如果消息服务器成功将事务消息投递到目标业务***，则消息服务器接收到目标业务***发送的通知，并依据该通知删除事务消息。在传统的事务消息的处理过程中，由于事务消息是两阶段提交，而每一个阶段都需要发送一条事务消息，导致消息量倍增，另外，如果第二阶段的事务消息未能成功发送到消息服务器，消息服务器需要回查发送端，以决定事务消息的提交或回滚，也就是需要实现回查逻辑，本申请实施例相对于传统的事务消息的处理过程而言，事务消息只需要投递一次，从而避免消息量的增加以及无需实现事务回查逻辑，实现简单，能够以较小的代价保证事务消息的发送结果和事务的业务处理逻辑的一致性。

在本申请实施例中，如果事务消息投递目标业务***失败，消息服务器还将针对事务消息更新投递状态消息，消息服务器定期从本地业务***的数据库中捞取未投递成功的事务消息，并根据投递状态消息重新尝试将事务消息投递目标业务***，从而保证了事务消息不回被遗漏，进而提高了用户的体验效果。

附图说明

图1是本申请的一种事务消息的处理方法实施例方法实施例1的步骤流程图；

图2是本申请的一种事务消息的处理方法实施例方法实施例2的步骤流程图；

图3是本申请的一种事务消息的业务处理逻辑的流程图示意图；

图4是本申请的一种事务消息的处理方法实施例装置实施例1的结构框图；

图5是本申请的一种事务消息的处理方法实施例装置实施例2的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种事务消息的处理方法实施例1的步骤流程图，具体可以包括如下步骤：

步骤101，生成事务消息；

在具体实现中，一组业务整体处理的行为叫一个事务，通常根据该业务的业务处理逻辑进行处理，在处理过程中通过生成事务消息与消息服务器进行通信。

以银行***为例，如果去银行转账，需要先从用户账户中取出指定的金额，再往目标账户中转入指定的金额。取出和转入这两个步骤银行必须要确保正确无误的进行，其中任何一个步骤出错，那么此次转账失败。

步骤102，针对所述事务消息添加指定的处理状态标识；

在本申请实施例中，对于即将要发送到消息服务器的事务消息，为其添加指定的状态处理标识，以指示该事务消息随后可能被处理方式。例如，将状态处理标识添加已提交状态标识，则该事务消息如果确定提取，则随后将被提交至消息服务器。

在本申请的一种优选实施例中，在所述步骤102之后，还可以包括如下步骤：

步骤S11，将所述具有状态标识的事务消息存储到预设的数据库中。

在具体实现中，在作为发送事务消息的发送端的本地业务***中，包括有预设的数据库。在本地的业务***执行事务时，操作数据库进行事务相关业务数据的处理，并将该事务的业务数据存储到该数据库中。

以银行***为例，银行***的事务执行中，业务数据的内容可以包括订单号，产品金额、数量，交易时间等等。在具体实现过程中，业务数据的内容根据执行一个事务的业务***的不同，所执行事务消息和业务数据可能会有所区别。本发明实施例对此不加以限制。

当业务***需要生成事务消息时，将该事务消息存储到数据库中，并且该事务消息携带有指定的状态处理标识，若该事务消息可能会发送至消息服务器，则该状态处理标识可以是已提交状态。

需要说明的是，在本申请实施例中，可以针对不同的事务消息添加不同的状态标识，以表明事务消息可能需要进行处理的状态，本申请实施例对此不加以限制。

在本申请的一种优选实施例中，所述方法还可以包括如下步骤：

步骤S21，判断是否将所述指定的处理状态标识的事务消息发送至消息服务器；若是，则执行步骤S22；若否，则执行步骤S23；

步骤S22，执行所述步骤103；

步骤S23，删除所述事务消息。

在具体实现中，在事务的执行过程中，本地业务***控制事务提交或回滚。如果事务回滚，业务数据和消息将一起回滚。其中，当事务回滚时，数据库的事务回滚机制会保证同时删除数据库中业务数据和事务消息。业务处理和事务消息处理均结束，提前返回。数据库的事务机制保证了事务回滚时，在执行事务的过程中对数据库的所有操作都会被回滚。所以业务数据和事务消息都会被删除。如果事务提交，则将消息发送到远程的消息服务器。

需要说明的是，如果事务回滚，所删除的是在事务执行过程中涉及的事务消息，非本事务执行过程涉及到的事务消息则不需要删除。

步骤103，将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；

在具体实现中，如果本地业务***控制事务提交，那么则将事务消息发送至消息服务器，消息服务器接收后，如果发现所述事务消息为已提交状态标识，则将该事务消息投递到所对应的目标业务***中。

步骤104，若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息；

在本申请的一种优选实施例中，消息服务器将事务消息投递到所对应的目标业务***中后，若事务消息投递成功，消息服务器接收到目标业务***发送的通知，基于该通知消息服务器从本地业务***中删除事务消息。

参照图2，示出了本申请的一种事务消息的处理方法实施例2的步骤流程图，具体可以包括如下步骤：

步骤201，接收到发送端发送的具有指定的处理状态标识的事务消息；

在具体实现中，在消息服务器中接收到作为发送端的本地业务***发送的事务消息，其中，该事务消息为本地业务***在执行事务的过程中发送，并且在本地业务***的数据库中存储有携带有指定的状态处理标识的事务消息。

步骤202，依据所述处理状态标识投递所述事务消息；

在具体实现中，如果消息服务器根据状态处理标识判断如何处理相应的事务消息。例如，如果本地业务***控制事务提交，那么则将事务消息到达消息服务器，若消息服务器发现所述事务消息的状态处理标识为已提交状态标识，则将需要该事务消息投递到所对应的目标业务***中。

步骤203，若成功投递所述事务消息，则接收到针对所述事务消息的通知；

步骤204，依据所述通知删除发送端的事务消息。

如果消息服务器成功将事务消息投递到相应的目标业务***中，则消息服务器接收到目标业务***发送的通知，基于该通知消息服务器可以从本地业务***中删除事务消息。

在本申请的一种优选实施例中，所述的方法还可以包括如下步骤：

步骤S31，若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述投递状态信息可以包括投递次数、下次投递时间和/或接收端的标识。

在本申请实施例中，如果消息服务器不能成功将投递事务消息到目标业务***，则操作数据库更新投递状态。

在本申请的具体应用的一种示例中，在消息服务器在投递事务消息到目标业务***的过程中，可能由于网络或者其他问题导致投递失败，此时消息服务器可以针对该事务消息记录相关的投递状态信息，比如该事务消息在成功投递前所投递次数，下次投递到目标业务***的时间，以及作为接收端的目标业务***的标识等等。当然，投递状态信息还可以包括其他事务消息的相关数据，本申请实施例对此不加以限制。

当达到下次投递到目标业务***的时间后，消息服务器根据接收端的标识确定目标业务***，可以重新尝试将事务消息投递至目标业务***。

在本申请的一种优选实施例中，所述的方法还可以包括如下步骤：

步骤S41，按照预设时间间隔从所述发送端获取所述确定处理状态的事务消息；

步骤S42，重新尝试投递所述事务消息。

在本地业务***的数据库中存储有尚未投递成功的事务消息，为了保证事务消息都能成功发送给目标业务***，在本申请实施例中，消息服务器将按照预设时间间隔从本地业务***的数据库中捞取尚未投递成功的事务消息，可以立即重新尝试将事务消息投递至目标业务***，或者按照其他设定的时间将事务消息投递至目标业务***。其中，预设时间间隔可以自由设置，一般可以设置为分钟级别，当然也可以根据实际情况设置为毫秒级别或者其他级别，本申请实施例对此不加以限制。

为了使本领域技术人员更好地理解本申请实施例，以下采用具体的示例来说明事务消息的处理过程。

参照图3所示的本申请的一种事务消息的业务处理逻辑的流程图示意图，具体可以包括如下几个步骤：

1、首先开启本地事务，然后根据本地事务执行相应的业务处理逻辑，操作本地数据库进行本地事务的相关业务数据的处理。在本地事务的处理过程中发送事务消息，并将已提交状态的消息***本地业务***的数据库中。

2、本地业务***控制事务提交或回滚。如果事务回滚，业务数据和事务将一起回滚。当事务回滚时，数据库的事务回滚机制会保证同时删除业务数据和事务消息，本地事务的处理和事务消息处理均结束，提前返回到本地业务***中进行删除。如果事务提交，则将事务消息发送到远程的消息服务器。

3、消息服务器接收到事务消息后，不再按照传统的事务消息处理方式，将事务消息进行持久化到消息数据库中。

4、消息服务器将事务消息投递到目标业务***。

5、如果事务消息投递成功，则消息服务器直接删除事务消息，否则更新消息投递状态信息，所述消息投递状态信息包含投递次数、下次投递时间、投递失败的目标业务***的标识等，以等待下次重试投递。

6、消息服务器定期从本地业务***的数据库中捞取未投递成功的事务消息，进行重试投递到目标业务***。如果能捞取到事务消息，则重复步骤4和步骤5。

在本申请实施例中，在本地业务***执行事务的过程中生成事务消息，并且为该事务消息添加指定的处理状态标识，当事务消息发送至消息服务器时，消息服务器则可以依据所述处理状态标识将所述事务消息进行投递，如果消息服务器成功将事务消息投递到目标业务***，则消息服务器接收到目标业务***发送的通知，基于该通知消息服务器从本地业务***中删除事务消息。在传统的事务消息的处理过程中，由于事务消息是两阶段提交，而每一个阶段都需要发送一条事务消息，导致消息量倍增，另外，如果第二阶段的事务消息未能成功发送到消息服务器，消息服务器需要回查发送端，以决定事务消息的提交或回滚，也就是需要实现回查逻辑，本申请实施例相对于传统的事务消息的处理过程而言，事务消息只需要投递一次，从而避免消息量的增加以及无需实现事务回查逻辑，以较小的代价保证事务消息的发送结果和事务的业务处理逻辑的一致性。

在本申请实施例中，如果事务消息投递目标业务***失败，消息服务器还将针对事务消息更新投递状态消息，消息服务器定期从本地业务***的数据库中捞取未投递成功的事务消息，并根据投递状态消息重新尝试将事务消息投递目标业务***，从而保证了事务消息不回被遗漏，进而提高了用户的体验效果。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图4，示出了本申请的一种事务消息的处理装置实施例1的结构框图，具体可以包括如下模块：

第一生成模块301，用于生成事务消息，并针对所述事务消息添加指定的处理状态标识；

在本申请的一种优选实施例中，所述装置还可以包括如下模块：

第一存储模块，用于将所述具有处理状态标识的事务消息存储到预设的数据库中。

在本申请的一种优选实施例中，所述装置还可以包括如下模块：

判断模块，用于判断是否将所述指定的处理状态标识的事务消息发送至消息服务器；若是，则调用发送模块；若否，则删除所述事务消息。

发送模块303，用于将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；

接收模块304，用于若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。

参照图5，示出了本申请的一种事务消息的处理装置实施例2的结构框图，具体可以包括如下模块：

第二接收模块401，用于接收到发送端发送的具有指定的处理状态标识的事务消息；

第一投递模块402，用于依据所述处理状态标识投递所述事务消息；

通知模块403，用于若成功投递所述事务消息，则接收到针对所述事务消息的通知；

删除模块404，用于依据所述通知删除发送端的事务消息。

在本申请的一种优选实施例中，所述装置还可以包括如下模块：

第二生成模块，用于若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述发送状态信息可以包括投递次数、下次投递时间和/或接收端的标识。

在本申请的一种优选实施例中，所述装置还可以包括如下模块：

获取模块，用于按照预设时间间隔从所述发送端获取所述指定的处理状态标识的事务消息；

第二投递模块，用于重新尝试投递所述事务消息。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

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

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

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

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种事务消息的处理方法和一种事务消息的处理装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (12)

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

生成事务消息；

针对所述事务消息添加指定的处理状态标识；

将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；

若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。

2.根据权利要求1所述的方法，其特征在于，在针对所述事务消息添加指定的处理状态标识的步骤之后，还包括：

将所述具有处理状态标识的事务消息存储到预设的数据库中。

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

判断是否将所述具有指定的处理状态标识的事务消息发送至消息服务器；

若是，则执行所述将事务消息发送至消息服务器的步骤；

若否，则删除所述事务消息。

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

接收到发送端发送的具有指定的处理状态标识的事务消息；

依据所述处理状态标识投递所述事务消息；

若成功投递所述事务消息，则接收到针对所述事务消息的通知；

依据所述通知删除发送端的事务消息。

5.根据权利要求4所述的方法，其特征在于，还包括：

若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述投递状态信息包括投递次数、下次投递时间和/或接收端的标识。

6.根据权利要求4或5所述的方法，其特征在于，还包括：

按照预设时间间隔从所述发送端获取所述指定的处理状态标识的事务消息；

重新尝试投递所述事务消息。

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

第一生成模块，用于生成事务消息，并针对所述事务消息添加指定的处理状态标识；

发送模块，用于将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；

第一接收模块，用于若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。

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

存储模块，用于将所述具有处理状态标识的事务消息存储到预设的数据库中。

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

判断模块，用于判断是否将所述指定的处理状态标识的事务消息发送至消息服务器；若是，则调用发送模块；若否，则删除所述事务消息。

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

第二接收模块，用于接收到发送端发送的具有指定的处理状态标识的事务消息；

第一投递模块，用于依据所述处理状态标识投递所述事务消息；

通知模块，用于若成功投递所述事务消息，则接收到针对所述事务消息的通知；

删除模块，用于依据所述通知删除发送端的事务消息。

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

第二生成模块，用于若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述投递状态信息包括投递次数、下次投递时间和/或接收端的标识。

12.根据权利要求10或11所述的装置，其特征在于，还包括：

获取模块，用于按照预设时间间隔从所述发送端获取所述指定的处理状态标识的事务消息；

第二投递模块，用于重新尝试投递所述事务消息。