CN102929709A - 任务流异常的处理方法及装置 - Google Patents

Abstract

本申请涉及一种任务流异常的处理方法及装置。该方法包括：(1)将用户请求转换为由多个任务节点构成的任务流，并执行所述任务流；(2)判断各任务节点的执行是否出现异常；(3)如果某个任务节点的执行出现异常，则暂时中止所述任务流的执行，并将出现异常的任务节点的节点信息放入分别指示多个不同等待时间的多级别等待队列中；以及(4)根据所述节点信息，执行所述出现异常的任务节点。本申请可以确保请求的完整执行，保障请求的数据、状态的最终完整性和一致性，提高人工恢复的效率，实现统一、稳定的接口。

Description

任务流异常的处理方法及装置

技术领域

本发明涉及一种任务流异常的处理方法及装置。

背景技术

任务流是一种网站业务的后台处理流程。在网站的业务系统中，存在一些由多个子任务构成的一个完整大任务，这些子任务本身只是为了完成某种特定的工作，而且这些子任务又有很高的重用性，因而不能完全将这些子任务集成在一个大任务中。为了完成这样一个大任务，就需要定义一些任务流，连接起所有的子任务来，并执行完成。以完成电子商务网站上的消息通信请求为例，这一大任务包括：发件人向收件人发送一些站内消息，发件人在自己的发件记录中看到消息，收件人在自己的收件箱中看到消息，即，从发件人发送开始到收件人真正能在收件箱内看到信息，需要经历很多子任务。这些子任务包括但不限于以下子任务或其组合：将这些信息保存到存储器中，对一些垃圾、欺诈信息进行过滤，根据收件人的管理规则进行目录的分配，在不同的数据源之间进行同步，对于重要的信息发送邮件来通知用户等等。这些子任务相互之间比较独立，但它们组成一个整体时，才能完成与一个用户请求对应的大任务。这些子任务中的任何一个出现异常(即，任务流处理出现异常)，对整个请求的完成就会出现问题。

已知的任务流异常的处理方式包括：在执行请求过程中由于任务流异常引入系统不一致的数据不会造成非常大的影响的情况下，直接丢弃请求但不删除这些不一致的数据，如果需要保持数据的一致性，则除了直接丢弃该请求还进一步删除在执行请求过程中已经进入系统的数据；或者用文件的方式将出错的情况保存到一个固定的地方，之后用人工的方式恢复起来。

但上述方式存在以下弊端：

1、对于直接将用户请求在后台处理的过程中丢弃掉的情况，在用户体验上很糟糕。对于电子商务网站来说，其任务流常常涉及用户进行交易的数据，这样的处理显然不合理；而且，在将插入一半的数据删除掉的情况下，虽然能保证那些数据整体上是一致的，但还是没有正确地响应请求的完成，容易造成用户重要的数据丢弃。

2、对于某时刻系统后台处理某个任务流失败的情况出现时采取单一的人工恢复处理方式，不能及时且有针对性地对各种异常(例如，系统脏数据、系统逻辑有误、请求的某些条件暂时还没有达到等)进行区别处理。

3、人工恢复很麻烦、容易出错、效率低：对于所有出错的场景，都采用人工恢复的方式，虽然有希望恢复数据，但是这样做效率低下，而且大部分场景下，并不一定需要人的参与才能将数据恢复；此外人工恢复的数据量增多时，出错率增加并会引发其它类型的问题。

4、由于简单放弃请求或者删除数据，导致接口不统一也不稳定。

发明内容

鉴于上述问题，本申请的一个目的是提供一种任务流异常的处理方法及装置，其可以保障用户请求的数据、状态的最终完整性与一致性。

本申请的另一个目的是提供一种任务流异常的处理方法及装置，其可以有针对性地、时间层次性地给予出现异常的场景足够的时间去解决问题。

本申请的又一个目的是提供一种任务流异常的处理方法及装置，其可以减少人工恢复的数据量，从而提高效率。

本申请的再一个目的是提供一种任务流异常的处理方法及装置，其可以实现统一、稳定的接口。

为了实现上述目的，本申请提供一种任务流异常的处理方法，包括如下步骤：

(1)将用户请求转换为由多个任务节点构成的任务流，并执行所述任务流；

(2)判断各任务节点的执行是否出现异常；

(3)如果某个任务节点的执行出现异常，则暂时中止所述任务流的执行，并将出现异常的任务节点的节点信息放入分别指示多个不同等待时间的多级别等待队列中；以及

(4)根据所述节点信息，执行所述出现异常的任务节点。

本申请还提供一种任务流异常的处理装置，该装置包括：

转换单元，将用户请求转换为由多个任务节点构成的任务流，并执行所述任务流；

判断单元，判断各任务节点的执行是否出现异常；

等待单元，如果某个任务节点的执行出现异常，则暂时中止所述任务流的执行，并将出现异常的任务节点的节点信息放入分别指示多个不同等待时间的多级别等待队列中；以及

执行单元，根据所述节点信息，执行所述出现异常的任务节点。

在本申请中，由于并不轻易放弃请求，因而可以尽最大可能地确保请求的完整执行，保障请求的数据、状态的最终完整性和一致性。此外，在本申请中，由于仅有在进入多级别等待队列进行等待之后仍不能恢复的场景才进行人工恢复，因而使得人工恢复的数据量减少，效率提高，出错率降低。

此外，由于将出现异常的任务节点进行等待处理，因而可以有针对性地解决能够利用等待而克服的异常现象。

而且，在本申请中，可以实现统一、稳定的接口。

另外，由于对于出现异常的任务节点执行多级别等待队列的处理，从而有时间层次性地给予出现异常的任务节点适当的时间去解决问题。

本申请包括如上所述的多个优点。当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

图1示例性示出了根据本申请的任务流异常的处理方法的主要流程图；

图2示例性示出了根据本申请的任务流异常的处理方法的示意图；

图3示例性示出了根据本申请的任务流异常的处理方法的第一实施例的流程图；

图4示例性示出了根据本申请的任务流异常的处理方法的第二实施例的流程图；

图5示例性示出了多种异常类型及其相应的等待时间的示意图；以及

图6示例性示出了根据本申请的任务流异常的处理装置的方框图。

具体实施方式

现将参照附图详细描述根据本申请的任务流异常的处理方法及装置。

参照图1，根据一个实施例，在接收到用户请求时，首先，在步骤S11，将该用户请求转换为由多个任务节点(即，子任务)构成的任务流，并执行所述任务流。

其次，在步骤S22，判断各任务节点的执行是否出现异常。处理出现异常的原因很多，例如数据尚未同步、系统逻辑发生错误、外部依赖系统不可用、尚未获得所需的其他数据的计算结果、本系统出现脏数据(即，所存在的与现实逻辑下的数据不一致的数据)以及外部系统的数据出现错误等等。

之后，如果在步骤S22判断出某个任务节点的执行出现异常，则流程进行到步骤S33，暂时中止任务流处理，并将出现异常的任务节点的节点信息放入分别指示多个不同等待时间的多级别等待队列中。

最后，在步骤S44，根据所放入的节点信息，执行所述出现异常的任务节点。

所述多级别等待队列由分别指示多个不同等待时间的多个等待队列组成，例如由第一等待级别的等待队列和第二等待级别的等待队列组成，其中第一等待级别的等待队列包括指示等待时间从短到长的多个子等待队列，第二等待级别的等待队列为指示等待时间为无限长的等待队列。在出现异常的任务节点的节点信息放入第一等待级别的等待队列的子等待队列时，在等待了第一等待级别的等待队列所指示的等待时间之后，根据节点信息返回到出现异常的任务节点并重新执行该出现异常的任务节点。在出现异常的任务节点的节点信息被放入第二等待级别的等待队列中时，提示进行人工干预。优选地，如果某个任务节点是第一次执行出现异常时，则将所述出现异常的任务节点的节点信息放入指示等待时间最短的子等待队列中。当该等待时间结束后，根据节点信息返回到出现异常的任务节点并重新执行该出现异常的任务节点。若重新执行该出现异常的任务节点仍不成功，则重新执行步骤S33，并将所述出现异常的任务节点的节点信息放入比所述出现异常的任务节点所在的前一子等待队列等待时间更长的子等待队列中，直到在等待了某一子等待队列所指示的等待时间后成功执行该出现异常的任务节点从而继续执行该任务流，或者在遍历了所有子等待队列后均未成功执行该出现异常的任务节点的情况下将出现异常的任务节点的节点信息放入第二等待级别的等待队列中以提示进行人工干预。

下面将参照图2说明根据本申请一实施例的任务流异常的处理方法。首先，将用户请求转换为由多个任务节点(即任务节点1-n)构成的任务流T，这些任务节点1-n为对于某个用户请求所需要执行的后台处理流程，它们按照一定的执行顺序执行。如果整个任务流T中每个任务节点需要的条件完备，那么每个任务节点就可以正确地被执行，从而正确地完成用户请求。每个节点对于同一个节点信息，在出现异常后每次执行该节点时造成的系统状态基本相同。优选地，每个节点对于同一个节点信息，在出现异常后每次执行该节点时造成的系统状态都是一样的，也就是幂等的；或者每次执行该节点之后，虽然会造成系统状态不太一样，但是总体上只可能是增加一些数据(每次增加的数据，对于由于出现异常下一次执行或者系统其他地方而言，都是没有影响的多余数据)，而不会影响整体系统的正确性与完整性。

图2中的附图标记1表示多级别等待队列，其由指示有限长等待时间的第一等待级别的等待队列(包括子等待队列11、12和13)以及指示无限长等待时间的第二等待级别的等待队列14组成。尽管在图2中示出第一等待级别的等待队列由三个子等待队列(即，子等待队列11、12和13)组成，但本领域的技术人员应当可以理解的是，第一等待级别的等待队列可由其它数目的子等待队列(例如，两个、四个、五个子等待队列)组成。图2中的这些子等待队列11、12和13从下到上表示需要等待的时间逐级增加，直到指示等待时间为无限长的第二等待级别的等待队列14，该第二等待级别的等待队列14表示无论等待了多久都无法完成的等待队列。例如，可将子等待队列11所指示的等待时间设为1分钟，将子等待队列12所指示的等待时间设为10分钟，将子等待队列13所指示的等待时间设为1小时。但本领域的技术人员应当可以理解的是，这些子等待队列所指示的等待时间可依照实际情况或需要而设定。

如图2所示，如果在任务流处理过程中任务节点k出现异常，比如在处理的过程中，由于有脏数据、或者对应的流程本身逻辑有问题、或者是有些需要等待的条件还没有发生等等，导致任务节点k无法正确地执行下去，则将出现异常的任务节点k的节点信息放置到多级别等待队列中，如图2的箭头A所示，同时暂时中止该请求。节点信息用于识别该出现异常的任务节点k，从而该出现异常的任务节点k可被重新自动执行或人工干预执行。节点信息的一个实例包括节点标识、任务流的整体流程定义以及当前操作的数据对象等。

接着，在出现异常的任务节点k的节点信息在第一等待级别的等待队列中等待了当前等待队列所指示的时间长度之后，尝试重新执行出现错误的任务节点k，如图2的箭头B所示。优选地，对于出现异常的任务节点k，先将其节点信息放在所指示的等待时间比较短的队列中，如级别最低的子等待队列11，然后在该等待队列所指示的等待时间结束之后，根据其节点信息找到该任务节点k并自动执行；如果仍然失败，则将其节点信息放到所指示的等待时间更长的队列中去，如子等待队列12；依此类推。即，将出现异常的任务节点的节点信息按照所指示的等待时间从短到长的顺序依次放入多个子等待队列中。也就是说，首先将出现异常的任务节点k的节点信息放在所指示的等待时间比较短的队列中，并在该等待队列所指示的等待时间结束之后，根据其节点信息找到该任务节点k并自动执行，如果执行不成功，则默认该等待时间不够长，然后将该任务节点k的节点信息放入所指示的等待时间更长的队列中。由于各子等待队列所指示的等待时间并不相同，而且出现异常的任务节点k从较短的等待时间开始以逐次增加的等待时间进行等待和尝试重新执行，因而能够尽可能地减少等待时间以及重试次数，减轻整个系统的负荷，更加快速有效地执行任务流。

当出现异常的任务节点的节点信息在所指示的等待时间最长的子等待队列(如级别最高的子等待队列13)仍执行失败时，将该节点信息放入所指示的等待时间无限长的等待队列，即，第二等待级别的等待队列14中，并提示人工干预。例如，可以将任务节点k判定为无效的任务，并提示人工干预来决定节点信息的去向。如果人工订正之后可以恢复，则可以手动将节点信息返回到流程，如图2的箭头C所示；否则可以通过程序设定或人工将任务节点k直接踢出整个任务流处理流程，即放弃任务流T所对应的用户请求。也就是说，对于无法利用等待解决的问题进行人工干预，对于那些放入所指示的等待时间无限长的第二等待级别的等待队列中的任务流进行必要的监控，当发现数据量很多、发生情况很集中、发生现象类似时，可以针对这些队列中的数据排除问题，及时解决问题，并重新放回对应的队列继续自动执行；而对于无法完成的用户请求，可以考虑踢出系统，减少资源的占用。

优选地，对于出错的任务节点k给予具有阶梯型的重复尝试机会。即，由于任务节点的异常经常属于不同错误类型，因此需要指示的等待时间为不同长度才能完成。参考图3说明几种典型的出错场景及其对应的几个等待时间等级(即，这些等待时间等级根据解决出错问题的时间而预先设定)。如图3所示，等待数据同步问题和等待其它数据的计算结果问题需要的等待时间很短(I)，外部依赖系统不可用问题需要的等待时间较短(II)，系统逻辑错误问题需要的等待时间较长(III)，以及本系统出现脏数据问题和外部系统出现数据错误问题需要的等待时间很长(IV)。因而，可以将相邻的子等待队列所指示的等待时间设置为彼此相差很多，以形成阶梯型等待时间，这样可以更有效地利用等待来解决出现的异常。

下面参照图3说明本申请任务流异常的处理方法的第一实施例。

首先，在步骤S1中，接收用户请求；

然后，在步骤S2中，将用户请求转换为由多个任务节点构成的任务流，例如先用消息方式将该请求格式化，然后再将用户请求转换为由多个任务节点构成的任务流；

之后，在步骤S3中，执行所述任务流；

接着，在步骤S4中，判断是否有任务节点的执行出现异常；

如果在步骤S4中判断没有任务节点的执行出现异常，则流程进行到步骤S5，响应用户请求。

如果在步骤S4中判断有任务节点的执行出现异常，则流程进行到步骤S41，判断出现异常的任务节点的节点信息是否已进入等待队列；

如果在步骤S41中判断信息没有进入等待队列，则流程进行到步骤S415，将出现异常的任务节点的节点信息放入初始等待队列，该初始等待队列可为子等待队列11、12或13；之后流程进入到步骤S416，等待当前等待队列指示的等待时间；然后，在等待时间结束时，流程进入到步骤S417，根据出现异常的任务节点的节点信息找到出现异常的任务节点并重新执行；然后，流程进入步骤S3继续执行该任务流。

如果在步骤S41中判断节点信息已进入等待队列，则流程进行到步骤S411，出现异常的任务节点的节点信息进入所指示的等待时间更长的等待队列；之后，在步骤S412中，判断出现异常的任务节点的节点信息是否进入所指示的等待时间为无限长的等待队列；

如果判断没有进入所指示的等待时间为无限长的等待队列，则流程进入到步骤S416，等待当前等待队列指示的等待时间；之后，在等待时间结束时，根据出现异常的任务节点的节点信息找到出现异常的任务节点并重新执行该任务节点；然后，流程进入步骤S3继续执行该任务流。

如果判断进入所指示的等待时间为无限长的等待队列，则流程进入步骤S413，提示进行人工干预，从而允许人工排除问题，例如订正数据或者修正系统；接着，进入步骤S414，如果人工干预后，问题仍未得到修复，即，步骤S414为否，则流程进行到步骤S418，放弃该用户请求；如果问题得到修复，即，步骤S414为是，则流程进入到步骤S417，找到出现异常的任务节点并重新执行；然后，流程进入步骤S3继续执行该任务流。

下面参考图4描述根据本申请的任务流异常的处理方法的第二实施例。该第二实施例与第一实施例之间的区别仅在于：在第二实施例中，用步骤S41’和步骤S411’代替第一实施例中的步骤S41、S411和S412。具体地说，在第二实施例中，已知第一等级级别的子等待队列的个数，在步骤S41’利用计数器对本步骤的每次执行进行计数，并判断节点信息是否已进入等待队列中。如果步骤S41’为否，则与第一实施例相同，流程进入步骤S415；如果步骤S41’为是，则流程进入步骤S411’，判断计数值与子等待队列的个数之间的关系。如果计数值小于等于子等待队列的个数，则流程进入步骤S416；如果计数值大于子等待队列的个数，则流程进入步骤S413提示进行人工干预。例如以图1所示具有三个子等待队列11、12和13为例，每次执行步骤S41’时均使计数器的数值加1，当计算器累加后的数值小于等于3时，进入步骤S416；当计算器累加后的数值为4时，即可确定出现异常的任务节点的节点信息进入无限长等待队列，从而流程进入步骤S413。

图4示例性示出本申请的任务流异常的处理装置的功能框图，本申请的任务流异常的处理装置对应于上述实施例中的任务流异常的处理方法。参见图4，任务流异常的处理装置包括：分割模块，将任务流分成多个任务节点；判断模块，判断各任务节点的处理是否出现异常；等待模块，如果某个任务节点出现异常，则暂时中止任务流处理，并将出现异常的任务节点的节点信息放入多级别等待队列中。

根据本发明的任务流异常的处理方法可以由具有运算处理能力的单个或多个处理设备，如单个或多个计算机，运行计算机可执行指令来实现。根据本发明的任务流异常的处理装置可以为单个或多个处理设备，如单个或多个计算机，其中的各个单元(例如转换单元)可以为该处理设备运行计算机可执行指令时具有相应功能的设备组件。根据本申请的一个实施例，可以使用JAVA语言在linux系统下来实现上述任务流异常的处理方法和装置。

本申请包括如下所述的多个优点之一或任意组合，但不限于这些优点：

(1)对于出现异常的请求不会直接丢弃，利用等待队列尽最大可能地确保请求的完整执行，保障请求的数据、状态的最终完整性和一致性。

(2)由于将出现异常的任务节点进行等待处理，因而可以有针对性地解决能够利用等待而克服的异常现象。

(3)由于仅有在进入多级别等待队列进行等待之后仍不能恢复的场景需要进行人工恢复，因而使得人工恢复的数据量减少，效率提高，出错率降低。

(4)实现了统一、稳定的接口。接口的实现务必是统一的、稳定的，因为对于同一个数据对象，可能有多个流转的数据源；而且对于系统的升级、数据的变更等，数据可以正常地执行，而不会因为接口的变化而导致数据无法再正常进入任务流执行。

(5)由于对于出现异常的任务节点执行多级别等待队列的处理，从而有时间层次性地给予出现异常的任务节点适当的时间去解决问题。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

尽管上面以示例性实施例的方式对本申请进行了详细描述，但本申请的范围不限于上述实施例，本领域的技术人员可以对本申请进行各种改进和变型，这些均不脱离本申请的范围和构思。

Claims (11)

1.一种由计算机实施的任务流异常的处理方法，包括如下步骤：

(1)将用户请求转换为由多个任务节点构成的任务流，并执行所述任务流；

(2)判断各任务节点的执行是否出现异常；

(3)如果某个任务节点的执行出现异常，则暂时中止所述任务流的执行，并将出现异常的任务节点的节点信息放入分别指示多个不同等待时间的多级别等待队列中；以及

(4)根据所述节点信息，执行所述出现异常的任务节点。

2.根据权利要求1所述的方法，在所述步骤(3)中：将所述节点信息放入所述多级别等待队列中第一等待级别的等待队列，在所述步骤(4)中，在等待了所述第一等待级别的等待队列指示的等待时间之后，自动重新执行出现异常的任务节点。

3.根据权利要求2所述的方法，其中，所述第一等待级别的等待队列包括指示等待时间从短到长的多个子等待队列。

4.根据权利要求3所述的方法，在所述步骤(3)中，如果某个任务节点是第一次执行出现异常时，则将所述出现异常的任务节点的节点信息放入指示等待时间最短的子等待队列中。

5.根据权利要求3所述的方法，在所述步骤(4)中，当执行所述出现异常的任务节点不成功时，则重新执行步骤(3)，并将所述出现异常的任务节点的节点信息放入比所述出现异常的任务节点所在的前一子等待队列等待时间更长的子等待队列中。

6.根据权利要求5所述的方法，在步骤(3)中，当将出现异常的任务节点放入所述第一等待级别的等待队列中最长的子等待队列中后，所述出现异常的任务节点仍无法在步骤(4)中成功执行，则将所述节点信息放入所述多级别等待队列中第二等待级别的等待队列中，提示进行人工干预。

7.根据权利要求6所述的方法，其中，所述第二等待级别的等待队列为指示等待时间为无限长的等待队列。

8.根据权利要求6所述的方法，其中，所述步骤(4)还包括：当人工干预失败时，丢弃该用户请求。

9.根据权利要求1所述的方法，其中，所述节点信息为用于识别所述出现异常的任务节点的信息。

10.根据权利要求9所述的方法，其中，所述节点信息包括节点标识、任务流的整体流程定义以及当前操作的数据对象。

11.一种任务流异常的处理装置，该装置包括：

转换单元，将用户请求转换为由多个任务节点构成的任务流，并执行所述任务流；

判断单元，判断各任务节点的执行是否出现异常；

等待单元，如果某个任务节点的执行出现异常，则暂时中止所述任务流的执行，并将出现异常的任务节点的节点信息放入分别指示多个不同等待时间的多级别等待队列中；以及

执行单元，根据所述节点信息，执行所述出现异常的任务节点。

Images