一种悬挂事务自动处理的方法和装置与流程

本发明涉及计算机通信技术领域，具体涉及一种悬挂事务自动处理的方法和装置。

背景技术：

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务的成员包括发起者、协调者和参与者。其中，发起者是分布式事务的发起方，一次分布式事务请求只有一个发起者。协调者是分布式事务的总控，负责分布式事务生命周期管理和所有分支的管理，一次分布式事务请求只有一个协调者。参与者是分布式事务当中的分支事务的控制者，一次分布式事务请求可以用多个分支事务实现，因此可以有多个参与者。

分布式事务处理过程中，往往会有多个参与者发起的多个分支事务，且这些分支事务处于不同的网络环境和服务器集群，由于分布式事务的环境复杂性，常常导致产生悬挂事务。现有技术在悬挂事务产生后，只有在收到业务没有成功的反馈，或进行日切(就是更换系统记账的时间，也称为日志切换)操作时，才会发现产生了悬挂事务，对悬挂事务进行人工处理。

现有技术无法及时发现并处理悬挂事务，导致后续业务请求的重试失败或者资金损失，同时对于某些业务系统(如账务)，会影响该系统日终结算等。

技术实现要素：

为了解决现有技术的问题，本发明提供了一种悬挂事务自动处理的方法和装置，可以及时发现并处理悬挂事务，可以避免后续业务请求的重试失败 和资金损失，同时对于某些业务系统(如账务)，避免影响该系统日终结算等。

为了解决上述问题，本发明公开了一种悬挂事务自动处理的方法，所述方法包括：

当预设悬挂定时查询时间到达时，查询参与者事务记录表；其中，所述参与者事务记录表中记载有参与者执行的事务的id、所述事务的状态、所述事务的创建时间；

根据所述参与者事务记录表中记载的所述事务的状态、所述事务的创建时间，以及当前时间，确定所述事务是否属于悬挂事务；

当确定所述事务属于悬挂事务时，根据所述事务的id，查询所述事务的业务处理日志；

根据所述事务的业务处理日志，按照预设悬挂事务处理规则，对所述事务进行悬挂处理。

进一步地，根据所述参与者事务记录表中记载的所述事务的状态、所述事务的创建时间，以及当前时间，确定所述事务是否属于悬挂事务，包括：

判断所述参与者事务记录表中记载的所述事务的状态是否为正在执行；

如果所述事务的状态为正在执行，则计算所述当前时间与所述事务的创建时间的间隔；

判断所述当前时间与所述事务的创建时间的间隔是否大于预设悬挂时间间隔阈值；

如果所述当前时间与所述事务的创建时间的间隔大于所述预设悬挂时间间隔阈值，则确定所述事务属于悬挂事务。

进一步地，当确定所述事务属于悬挂事务时，根据所述事务的id，查询所述事务的业务处理日志，包括：

当确定所述事务属于悬挂事务时，在所述参与者事务记录表中标记所述事务的属性为悬挂事务；

当预设悬挂定时处理时间到达时，获取所述参与者事务记录表中属性为 悬挂事务的所述事务的id；

根据属性为悬挂事务的所述事务的id，查询所述事务的业务处理日志。

进一步地，根据所述事务的业务处理日志，按照预设悬挂事务处理规则，对所述事务进行悬挂处理，包括：

判断所述事务的业务处理日志中包含所述事务的多少个阶段的日志；

如果所述事务的业务处理日志中包含所述事务的第一处理阶段和第二处理阶段二个阶段的日志，则对所述事务进行回滚；

如果所述事务的业务处理日志中只包含所述事务的第一处理阶段一个阶段的日志，则根据所述事务的id，查询所述事务的调用日志，从所述事务的调用日志中获取所述参与者的上游系统信息，通过所述上游系统信息对应的上游系统对所述事务进行悬挂处理。

进一步地，通过所述上游系统信息对应的上游系统对所述事务进行悬挂处理，包括：

根据所述事务的id，获取所述上游系统中所述事务的业务处理日志；

判断所述上游系统中所述事务的业务处理日志中包含所述事务的多少个阶段的日志；

如果所述上游系统中所述事务的业务处理日志中包含所述事务的第一处理阶段和第二处理阶段二个阶段的日志，则请求所述上游系统对所述事务进行回滚；

如果所述上游系统中所述事务的业务处理日志中包含所述事务的第一处理阶段一个阶段的日志，则判定无法确定所述事务的悬挂原因。

为了解决上述问题，本发明还公开了一种悬挂事务自动处理的装置，所述装置包括：

第一查询模块，用于当预设悬挂定时查询时间到达时，查询参与者事务记录表；其中，所述参与者事务记录表中记载有参与者执行的事务的id、所述事务的状态、所述事务的创建时间；

确定模块，用于根据所述参与者事务记录表中记载的所述事务的状态、 所述事务的创建时间，以及当前时间，确定所述事务是否属于悬挂事务；

第二查询模块，用于当确定所述事务属于悬挂事务时，根据所述事务的id，查询所述事务的业务处理日志；

处理模块，用于根据所述事务的业务处理日志，按照预设悬挂事务处理规则，对所述事务进行悬挂处理。

进一步地，所述确定模块包括：

第一判断单元，用于判断所述参与者事务记录表中记载的所述事务的状态是否为正在执行；

计算单元，用于如果所述事务的状态为正在执行，则计算所述当前时间与所述事务的创建时间的间隔；

第二判断单元，用于判断所述当前时间与所述事务的创建时间的间隔是否大于预设悬挂时间间隔阈值；

确定单元，用于如果所述当前时间与所述事务的创建时间的间隔大于所述预设悬挂时间间隔阈值，则确定所述事务属于悬挂事务。

进一步地，所述第二查询模块包括：

标记单元，用于当确定所述事务属于悬挂事务时，在所述参与者事务记录表中标记所述事务的属性为悬挂事务；

获取单元，用于当预设悬挂定时处理时间到达时，获取所述参与者事务记录表中属性为悬挂事务的所述事务的id；

查询单元，用于根据属性为悬挂事务的所述事务的id，查询所述事务的业务处理日志。

进一步地，所述处理模块包括：

第三判断单元，用于判断所述事务的业务处理日志中包含所述事务的多少个阶段的日志；

回滚单元，用于如果所述事务的业务处理日志中包含所述事务的第一处理阶段和第二处理阶段二个阶段的日志，则对所述事务进行回滚；

处理单元，用于如果所述事务的业务处理日志中只包含所述事务的第一 处理阶段一个阶段的日志，则根据所述事务的id，查询所述事务的调用日志，从所述事务的调用日志中获取所述参与者的上游系统信息，通过所述上游系统信息对应的上游系统对所述事务进行悬挂处理。

进一步地，所述处理单元包括：

获取子单元，用于根据所述事务的id，获取所述上游系统中所述事务的业务处理日志；

判断子单元，用于判断所述上游系统中所述事务的业务处理日志中包含所述事务的多少个阶段的日志；

回滚子单元，用于如果所述上游系统中所述事务的业务处理日志中包含所述事务的第一处理阶段和第二处理阶段二个阶段的日志，则请求所述上游系统对所述事务进行回滚；

判定子单元，用于如果所述上游系统中所述事务的业务处理日志中包含所述事务的第一处理阶段一个阶段的日志，则判定无法确定所述事务的悬挂原因。

与现有技术相比，本发明可以获得包括以下技术效果：

1)当预设悬挂定时查询时间到达时，查询参与者事务记录表，根据参与者事务记录表中记载的事务的状态、事务的创建时间，以及当前时间，确定事务是否属于悬挂事务，当确定事务属于悬挂事务时，根据事务的id，查询事务的业务处理日志，根据事务的业务处理日志，按照预设悬挂事务处理规则，对事务进行悬挂处理，可以及时发现并处理悬挂事务，可以避免后续业务请求的重试失败和资金损失，同时对于某些业务系统(如账务)，避免影响该系统日终结算等。

2)通过配置悬挂定时查询时间、悬挂定时处理时间方式，可以自动发现悬挂事务并自动解决，可以尽快消除业务重试失败风险和资金风险。

当然，实施本发明的任一产品必不一定需要同时达到以上所述的所有技术效果。

附图说明

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

图1是本发明实施例的第一种悬挂事务自动处理的方法流程图；

图2是本发明实施例的一种分布式事务的处理示意图；

图3是本发明实施例的第二种悬挂事务自动处理的方法流程图；

图4是本发明实施例的第三种悬挂事务自动处理的方法流程图；

图5是本发明实施例的第四种悬挂事务自动处理的方法流程图；

图6是本发明实施例的一种悬挂事务自动处理的装置结构示意图。

具体实施方式

以下将配合附图及实施例来详细说明本发明的实施方式，藉此对本发明如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。

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

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

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

如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。此外，“耦接”一词在此包含任何直接及间接的电性耦接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表所述第一装置可直接电性耦接于所述第二装置，或通过其他装置或耦接手段间接地电性耦接至所述第二装置。说明书后续描述为实施本发明的较佳实施方式，然所述描述乃以说明本发明的一般原则为目的，并非用以限定本发明的范围。本发明的保护范围当视所附权利要求所界定者为准。

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

实施例描述

下面以一实施例对本发明方法的实现作进一步说明。如图1所示，为本发明实施例的一种悬挂事务自动处理的方法流程图，该方法包括：

s101：当预设悬挂定时查询时间到达时，查询参与者事务记录表。

其中，参与者事务记录表中记载有参与者执行的事务的id(身份标识)、事务的状态、事务的创建时间等。事务的状态包括正在执行、第一处理阶段完结、第二处理阶段完结等。

需要说明的是，分布式事务处理过程中一般包括二个阶段，第一处理阶段和第二处理阶段，第一处理阶段进行事务的发起，第二处理阶段进行事务 的提交或回滚等。

例如：分布式事务的参与者a的参与者事务记录表中记载有：事务的id：123、事务的状态：正在执行、事务的创建时间：2016-2-20-13:12、事务的内容：租场地。

具体地，可以配置悬挂事务定时查询任务，当预设悬挂定时查询时间到达时，进行悬挂事务查询，确定是否产生了悬挂事务。预设悬挂定时查询时间可以根据实际情况进行设置，如可以设置为30分钟、1小时等。每隔一预设悬挂定时查询时间，查询一下是否产生了悬挂事务。

s102：根据参与者事务记录表中记载的事务的状态、事务的创建时间，以及当前时间，确定事务是否属于悬挂事务。

具体地，确定事务是否属于悬挂事务，即确定事务是否发生了悬挂，产生了悬挂事务。

具体地，参见图2，为常见分布式事务的处理流程(其中，参与者可以包括多个)，在流程的第3步如果网络超时，此时发起者会收到协调者添加分支事务失败的结果，从而发起回滚，此时在第二处理阶段协调者收到的回滚请求，因为第4步超时，分支事务记录没有成功落地，所以空回滚，而此时待第3步请求真正处理完成时，整个事务已经回滚成功，本次分布式事务请求结束，第4步实际落地的分支事务记录，将一直留在协调者中，而不会被现有分布式事务处理，产生悬挂事务。在流程的第5步如果网络超时，此时发起者会收到参与者添加分支事务失败的结果，从而发起回滚，此时在第二处理阶段参与者收到的回滚请求，因为第5步超时，预处理记录没入成功落地，所以空回滚，而此时待第5步请求真正处理完成时，整个事务已经回滚成功，第6步实际落地的预处理记录，将一直留在参与者中，而不会被现有分布式事务处理，产生悬挂事务。

从上面描述可以看出悬挂事务产生的一种情况为：由于网络超时，可能导致第二处理阶段的请求会在预处理落地之前就到达，而第二处理阶段请求处理时由于第一处理阶段的数据还没落地，所以两阶段回滚会空回滚，在分布式事务结束后，结束的分布式事务将不在发起第二阶段请求，从而产生悬挂事务。

悬挂事务产生的另一种情况为：在第一处理阶段完成后，发起者由于代码bug(漏洞)导致没有发起第二处理阶段，从而产生悬挂事务。

s103：当确定事务属于悬挂事务时，根据事务的id，查询事务的业务处理日志。

具体地，业务处理日志按照对应的事务的id存储在参与者服务器的预设存储空间。在事务处理过程，产生业务处理日志时，参与者服务器会进行双写，以保证业务处理日志的持久性。

s104：根据事务的业务处理日志，按照预设悬挂事务处理规则，对事务进行悬挂处理。

具体地，根据s102中悬挂事务产生的情况，预先设置相应的悬挂事务处理规则，当确定事务属于悬挂事务后，根据事务的业务处理日志确定悬挂事务属于哪一种情况，然后根据该种情况的悬挂事务的处理规则，对事务进行悬挂处理。

具体地，在本发明实施例的一优选实施例中，参见图3，s102根据参与者事务记录表中记载的事务的状态、事务的创建时间，以及当前时间，确定事务是否属于悬挂事务，包括：

s102a：判断参与者事务记录表中记载的事务的状态是否为正在执行,如果事务的状态为正在执行，则执行s102b；否则，执行s102e。

s102b：计算当前时间与事务的创建时间的间隔。

s102c：判断当前时间与事务的创建时间的间隔是否大于预设悬挂时间间隔阈值，如果当前时间与事务的创建时间的间隔大于预设悬挂时间间隔阈值，则执行s102d；否则，执行s102e。

其中，预设悬挂时间间隔阈值可以根据实际应用状况进行设置，如对于一个业务系统来说通常会有超时时间，一般超时时间为30s，可以考虑设置预设悬挂时间间隔阈值大于超时时间，如可以设置为2分钟等，如果事务处于正在执行状态，同时处理时间已经远超过了超时时间，此类情况下正常都会超时回滚掉，对于此情况的事务可确定属于悬挂事务。

s102d：确定事务属于悬挂事务，然后结束。

s102e：确定事务不属于悬挂事务，然后结束。

具体地，在本发明实施例的一优选实施例中，参见图4，s103当确定事务属于悬挂事务时，根据事务的id，查询事务的业务处理日志，包括：

s103a：当确定事务属于悬挂事务时，在参与者事务记录表中标记事务的属性为悬挂事务。

具体地，在参与者事务记录表中标记事务的属性为悬挂事务，通过标记使得后续可以方便地查询得到事务是否属于悬挂事务。标记事务的属性为悬挂事务时，可以通过标识等方法实现，如可以通过标识11表示事务是悬挂事务，通过标识00表示事务不是悬挂事务等。

s103b：当预设悬挂定时处理时间到达时，获取参与者事务记录表中属性为悬挂事务的事务的id。

具体地，可以配置悬挂事务定时处理任务，可以考虑跟悬挂事务定时查询任务的频率相同，可以在悬挂事务定时查询任务完结后的预设时间(如5秒后，2分钟后)启动。

s103c：根据属性为悬挂事务的事务的id，查询事务的业务处理日志。

具体地，在本发明实施例的一优选实施例中，参见图5，s104根据事务的业务处理日志，按照预设悬挂事务处理规则，对事务进行悬挂处理，包括：

s104a：判断事务的业务处理日志中包含事务的多少个阶段的日志，如果事务的业务处理日志中包含事务的第一处理阶段和第二处理阶段二个阶段的日志，则执行s104b；如果事务的业务处理日志中只包含事务的第一处理阶段一个阶段的日志，则执行s103c。

s104b：对事务进行回滚，然后结束。

具体地，对事务进行回滚，处理完成后，更新事务的属性为非悬挂事务。

s104c：根据事务的id，查询事务的调用日志，从事务的调用日志中获取参与者的上游系统信息，通过上游系统信息对应的上游系统对事务进行悬挂处理，然后结束。

其中，上游系统可能是参与者的上游参与者、协调者、或发起者。

具体地，在本发明实施例的一优选实施例中，参见图6，s104c中的通过上游系统信息对应的上游系统对事务进行悬挂处理，包括：

s104c1：根据事务的id，获取上游系统中事务的业务处理日志。

s104c2：判断上游系统中事务的业务处理日志中包含事务的多少个阶段的日志，如果上游系统中事务的业务处理日志中包含事务的第一处理阶段和第二处理阶段二个阶段的日志，则执行s104c3；如果上游系统中事务的业务处理日志中包含事务的第一处理阶段一个阶段的日志，则执行s104c4。

s104c3：请求上游系统对事务进行回滚，然后结束。

具体地，请求上游系统对事务进行回滚，上游系统对事务进行回滚，处理完成后，更新事务的属性为非悬挂事务。

s104c4：判定无法确定事务的悬挂原因，然后结束。

具体地，对事务进行回滚，处理完成后，或在判定无法确定事务的悬挂原因后，可以通过发送短信、邮件等形式将处理结果通知指定用户(如检测系统&调用系统技术人员等)，便于后续处理。

本实施例所述的悬挂事务自动处理的方法，当预设悬挂定时查询时间到达时，查询参与者事务记录表，根据参与者事务记录表中记载的事务的状态、事务的创建时间，以及当前时间，确定事务是否属于悬挂事务，当确定事务属于悬挂事务时，根据事务的id，查询事务的业务处理日志，根据事务的业务处理日志，按照预设悬挂事务处理规则，对事务进行悬挂处理，可以及时发现并处理悬挂事务，可以避免后续业务请求的重试失败和资金损失，同时对于某些业务系统(如账务)，避免影响该系统日终结算等。通过配置悬挂定时查询时间、悬挂定时处理时间方式，可以自动发现悬挂事务并自动解决，可以尽快消除业务重试失败风险和资金风险。

如图6所示，是本发明实施例的一种悬挂事务自动处理的装置结构图，该装置包括：

第一查询模块201，用于当预设悬挂定时查询时间到达时，查询参与者事务记录表；其中，参与者事务记录表中记载有参与者执行的事务的id、事 务的状态、事务的创建时间；

确定模块202，用于根据参与者事务记录表中记载的事务的状态、事务的创建时间，以及当前时间，确定事务是否属于悬挂事务；

第二查询模块203，用于当确定事务属于悬挂事务时，根据事务的id，查询事务的业务处理日志；

处理模块204，用于根据事务的业务处理日志，按照预设悬挂事务处理规则，对事务进行悬挂处理。

进一步地，确定模块202包括：

第一判断单元，用于判断参与者事务记录表中记载的事务的状态是否为正在执行；

计算单元，用于如果事务的状态为正在执行，则计算当前时间与事务的创建时间的间隔；

第二判断单元，用于判断当前时间与事务的创建时间的间隔是否大于预设悬挂时间间隔阈值；

确定单元，用于如果当前时间与事务的创建时间的间隔大于预设悬挂时间间隔阈值，则确定事务属于悬挂事务。

进一步地，第二查询模块203包括：

标记单元，用于当确定事务属于悬挂事务时，在参与者事务记录表中标记事务的属性为悬挂事务；

获取单元，用于当预设悬挂定时处理时间到达时，获取参与者事务记录表中属性为悬挂事务的事务的id；

查询单元，用于根据属性为悬挂事务的事务的id，查询事务的业务处理日志。

进一步地，处理模块204包括：

第三判断单元，用于判断事务的业务处理日志中包含事务的多少个阶段的日志；

回滚单元，用于如果事务的业务处理日志中包含事务的第一处理阶段和 第二处理阶段二个阶段的日志，则对事务进行回滚；

处理单元，用于如果事务的业务处理日志中只包含事务的第一处理阶段一个阶段的日志，则根据事务的id，查询事务的调用日志，从事务的调用日志中获取参与者的上游系统信息，通过上游系统信息对应的上游系统对事务进行悬挂处理。

进一步地，处理单元包括：

获取子单元，用于根据事务的id，获取上游系统中事务的业务处理日志；

判断子单元，用于判断上游系统中事务的业务处理日志中包含事务的多少个阶段的日志；

回滚子单元，用于如果上游系统中事务的业务处理日志中包含事务的第一处理阶段和第二处理阶段二个阶段的日志，则请求上游系统对事务进行回滚；

判定子单元，用于如果上游系统中事务的业务处理日志中包含事务的第一处理阶段一个阶段的日志，则判定无法确定事务的悬挂原因。

本实施例所述的悬挂事务自动处理的装置，当预设悬挂定时查询时间到达时，查询参与者事务记录表，根据参与者事务记录表中记载的事务的状态、事务的创建时间，以及当前时间，确定事务是否属于悬挂事务，当确定事务属于悬挂事务时，根据事务的id，查询事务的业务处理日志，根据事务的业务处理日志，按照预设悬挂事务处理规则，对事务进行悬挂处理，可以及时发现并处理悬挂事务，可以避免后续业务请求的重试失败和资金损失，同时对于某些业务系统(如账务)，避免影响该系统日终结算等。通过配置悬挂定时查询时间、悬挂定时处理时间方式，可以自动发现悬挂事务并自动解决，可以尽快消除业务重试失败风险和资金风险。

所述装置与前述的方法流程描述对应，不足之处参考上述方法流程的叙述，不再一一赘述。

上述说明示出并描述了本发明的若干优选实施例，但如前所述，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内， 通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。