一种事务消息的处理方法和装置的制造方法
【技术领域】
[0001]本申请涉及消息处理的技术领域，特别是涉及一种事务消息的处理方法和一种事务消息的处理装置。
【背景技术】
[0002]在分布式的网络环境下，业务系统之间需要进行消息的交互以完成关联的业务，为了降低业务系统之间的耦合性，通常采用异步可靠消息来进行消息的交互。异步可靠消息一般分为普通消息和事务消息。普通消息与发送结果不绑定。作为发送端的业务系统，在执行本地事务时，不依赖普通消息的发送结果，即使普通消息发送失败，也可以按照本地事务的业务处理逻辑继续执行相应的操作。由于不能保证普通消息的发送结果和本地事务的业务处理逻辑的一致性，因此，在对一致性要求严格的场景通常选用事务消息。事务消息与发送结果绑定。在执行本地事务时，依赖事务消息的发送结果，即事务消息发送结果和本地事务的业务处理逻辑保持一致。
[0003]在具体实现中，如果发送端发事务消息失败，则需要回滚本地事务，此外，如果在发送端本地事务执行失败，也需要回滚事务消息，以保证发送结果和本地事务的业务处理逻辑的一致性。目前事务消息一般采用两阶段提交的方式，并将事务消息的状态分为未决状态和已提交状态。事务消息两阶段提交的方式具体为:
[0004]第一阶段，在发送端进行本地事务的处理时操作业务数据库，并将本地事务于事务消息绑定，在本地事务执行过程中发送未决状态的事务消息到消息服务器，消息服务器将该事务消息持久化到消息数据库；
[0005]第二阶段，在发送端确定事务消息是提交或者回滚，此时会发送指示提交或回滚的消息到消息服务器，如果是指示回滚的消息，消息服务器会删除先前持久化到消息数据库的未决状态消息，如果是指示提交的消息，消息服务器会将事务消息的状态从未决状态更新为已提交状态，然后再进行投递。
[0006]如果在第二阶段的事务消息发送失败，消息服务器会回查发送端咨询事务消息的状态，消息服务器咨询该事务消息的状态后，决定对事务消息是要提交还是回滚。
[0007]由此可知，事务消息的两阶段提交方式的缺点主要有:
[0008]1、消息量倍增。由于事务消息是两阶段提交，而每一个阶段都需要发送一条事务消息，这意味着执行本地事务过程中的一次事务消息的发送动实际上需要发送用两次才能发送，从而使消息量增加了一倍，加重了网络负载、消息服务器负担以及消息数据库的事务消息数。
[0009]2、需要实现回查逻辑。如果第二阶段的事务消息未能成功发送到消息服务器，消息服务器需要回查发送端，以决定事务消息的提交或回滚。实现事务消息回查逻辑，实现较为复杂，且需要一定的代价。
[0010]因此，目前需要本领域技术人员迫切解决的一个技术问题就是:提出一种事务消息的处理机制，用以以较小的代价保证事务消息的发送结果和事务的业务处理逻辑的一致性。
[0011]申请内容
[0012]本申请实施例所要解决的技术问题是提供一种事务消息的处理方法，用以以较小的代价保证事务消息的发送结果和事务的业务处理逻辑的一致性。
[0013]相应的，本申请实施例还提供了一种事务消息的处理装置，用以保证上述方法的实现及应用。
[0014]为了解决上述问题，本申请公开了一种事务消息的处理方法，所述的方法包括:
[0015]生成事务消息；
[0016]针对所述事务消息添加指定的处理状态标识；
[0017]将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；
[0018]若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。
[0019]优选地，在针对所述事务消息添加指定的处理状态标识的步骤之后，还包括:
[0020]将所述具有处理状态标识的事务消息存储到预设的数据库中。
[0021]优选地，所述方法还包括:
[0022]判断是否将所述具有指定的处理状态标识的事务消息发送至消息服务器；
[0023]若是，则执行所述将事务消息发送至消息服务器的步骤；
[0024]若否，则删除所述事务消息。
[0025]本申请实施例还公开了一种事务消息的处理方法，包括:
[0026]接收到发送端发送的具有指定的处理状态标识的事务消息；
[0027]依据所述处理状态标识投递所述事务消息；
[0028]若成功投递所述事务消息，则接收到针对所述事务消息的通知；
[0029]依据所述通知删除发送端的事务消息。
[0030]优选地，所述方法还包括:
[0031]若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述投递状态信息包括投递次数、下次投递时间和/或接收端的标识。
[0032]优选地，所述方法还包括:
[0033]按照预设时间间隔从所述发送端获取所述指定的处理状态标识的事务消息；
[0034]重新尝试投递所述事务消息。
[0035]本申请实施例还公开了一种事务消息的处理装置，所述的装置包括:
[0036]第一生成模块，用于生成事务消息，并针对所述事务消息添加指定的处理状态标识；
[0037]发送模块，用于将所述事务消息发送至消息服务器；所述消息服务器用于依据所述处理状态标识将所述事务消息进行投递；
[0038]第一接收模块，用于若成功投递所述事务消息，则所述消息服务器用于删除所述事务消息。
[0039]优选地，所述装置还包括:
[0040]存储模块，用于将所述具有处理状态标识的事务消息存储到预设的数据库中。[0041 ]优选地，所述装置还包括:
[0042]判断模块，用于判断是否将所述指定的处理状态标识的事务消息发送至消息服务器；若是，则调用发送模块；若否，则删除所述事务消息。
[0043]本申请实施例还公开了一种事务消息的处理装置，包括:
[0044]第二接收模块，用于接收到发送端发送的具有指定的处理状态标识的事务消息；
[0045]第一投递模块，用于依据所述处理状态标识投递所述事务消息；
[0046]通知模块，用于若成功投递所述事务消息，则接收到针对所述事务消息的通知；
[0047]删除模块，用于依据所述通知删除发送端的事务消息。
[0048]优选地，所述装置还包括:
[0049]第二生成模块，用于若投递所述事务消息失败，则生成针对所述事务消息的投递状态信息；所述投递状态信息包括投递次数、下次投递时间和/或接收端的标识。
[0050]优选地，所述装置还包括:
[0051]获取模块，用于按照预设时间间隔从所述发送端获取所述指定的处理状态标识的事务消息；
[0052]第二投递模块，用于重新尝试投递所述事务消息。
[0053]与现有技术相比，本申请实施例包括以下优点:
[0054]在本申请实施例中，在本地业务系统执行事务的过程中生成事务消息，并且为该事务消息添加指定的处理状态标识，当事务消息发送至消息服务器时，消息服务器则可以依据所述处理状态标识将所述事务消息进行投递，如果消息服务器成功将事务消息投递到目标业务系统，则消息服务器接收到目标业务系统发送的通知，并依据该通知删除事务消息。在传统的事务消息的处理过程中，由于事务消息是两阶段提交，而每一个阶段都需