一种多信息流节点的协同处理方法及装置

摘要

本申请实施例公开了多信息流节点的协同处理方法。该方法包括：在获取协同处理节点集中的当前信息流节点后，对其关联模式类型进行识别，然后根据不同类型进行不同处理：如果为“第一类型”，则在当前信息流节点处理完信息任务后启动协同处理节点集中其他节点或者在协同处理集中的其他节点处理完信息任务后启动当前信息流节点；如果为“第二类型”，则在当前信息流节点是协同处理节点集中最晚被识别的节点时，启动待协同处理的全部节点处理信息任务。本申请实施例还提供了一种多信息流节点的协同处理装置。本申请实施例的技术方案适应了多关联模式下的信息流节点间的协同处理，总体上提高了信息处理任务的处理效率。

说明书

技术领域

本申请涉及信息处理技术领域，尤其涉及一种多信息流节点的协同处理 方法及其装置。

背景技术

随着信息技术的发展，信息流产品已得到广泛应用。信息流产品对信息 处理任务进行步骤化实施，通过每个节点的处理来实现整个信息处理任务的 处理，这种方式简化了信息处理任务的处理过程，以分散的处理能力减低了 处理复杂度。信息流产品上的每个节点称为信息流节点。基于信息处理任务 的复杂性，一个信息流节点可能与其他信息流节点存在关联关系，比如顺序 关系，即某个信息流节点的任务处理需要等到其他节点的任务处理完成后才 能启动，还比如同步关系，即某个信息流节点的任务处理需要与其他节点同 步进行。为确保这种信息流节点间具有关联关系的信息流成功运行，必须提 供协调机制，以协同各个信息流节点间的任务处理。

信息流节点间的协同处理的难点在于信息流节点间关联关系的多样性。 参见图1(a)～(e)，该图示出了较为常见的5种关联模式，即：同一信息流 的多个并行分支均完成后启动后续处理；同一信息流多个并行分支内的信息 流节点需同时启动；同一信息流某个并行分支内的信息流节点需要等待其他 分支节点完成后启动；不同信息流的信息流节点需同时启动；一个信息流节 点内的信息流节点需等待其他信息流内的信息流节点完成后启动。目前的信 息流产品均支持图1(a)的关联模式，而在其他关联模式下，如果某个信息 流节点不能正确执行，包含该信息流节点的信息处理任务将被驳回重新处理， 不同模式下不同流程(信息流节点)将按照各自独立的方式运行，从而导致 信息处理任务的整体处理效率低下。此外，对于信息流中出现的特殊情形， 比如信息流节点回退、节点跳过等操作，现有的信息流产品更是无法实现多 信息流节点的协同处理。

发明内容

为解决上述技术问题，本申请实施例提供了一种多信息流节点的协同处 理方法及其装置，以适应信息流节点间在多种关联模式下的协同处理需要， 从而总体上提高信息处理任务的处理效率。

本申请实施例提供的多信息流节点的协同处理方法包括：

从预设协同处理节点集中获取将处理信息任务的当前信息流节点；

识别当前信息流节点的关联模式的类型，所述关联模式为一个信息流节 点与其他信息流节点处理信息任务时的时序关系；

如果当前信息流节点的关联模式为第一类型，则在当前信息流节点处理 完信息任务后启动预设协同处理节点集中的其他节点或者在预设协同处理集 中的其他节点处理完信息任务后启动当前信息流节点，所述第一类型为一个 信息流节点在另一个或多个信息流节点完成信息任务处理后启动；

如果当前信息流节点的关联模式为第二类型，则判断当前信息流节点是 否是预设协同处理节点集中最晚识别为第二类型的节点，如果是，则启动预 设待协同处理节点集内的全部节点，所述第二类型为一个信息流节点与另一 个或多个信息流节点同步启动信息任务处理。

优选地，所述如果当前信息流节点的关联模式为第一类型，在预设协同 处理集中的其他节点处理完信息任务后启动当前信息流节点，具体包括：

接收预设协同处理集中的其他节点处理完信息任务后发送的通知消息；

在当前信息流节点的关联模式识别为第一类型时，判断接收到的通知消 息的数量是否比预设协同处理节点集内的节点少一个，如果是，则启动当前 信息流节点。

优选地，所述如果当前信息流节点的关联模式为第二类型，则判断当前 信息流节点是否是预设协同处理节点集中最晚识别为第二类型的节点，如果 是，则启动预设待协同处理节点集内的全部节点，具体包括：

在当前信息流节点的关联模式识别为第二类型时，发送通知消息；

判断当前信息流节点是否是待协同处理的节点中最晚发送通知消息的节 点，如果是，则启动预设待协同处理节点集内的全部节点。

优选地，所述方法还包括：在从预设协同处理节点集中获取将处理信息 任务的当前信息流节点后，判断所述当前信息流节点是否具有虚拟标记，所 述虚拟标记用于标记处理信息任务过程中跳过的信息流节点，如果否，则执 行识别当前信息流节点的关联模式的类型的步骤。

优选地，所述方法还包括：在从预设协同处理节点集中获取将处理信息 任务的当前信息流节点后，判断所述当前信息流节点是否已启动过信息处理 任务，如果否，则执行识别当前信息流节点的关联模式的类型的步骤。

本申请实施例还提供了一种多信息流节点的协同处理装置。该装置包括： 获取单元、识别单元、第一启动单元和第二启动单元，其中：

所述获取单元，用于从预设协同处理节点集中获取将处理信息任务的当 前信息流节点；

所述识别单元，用于识别当前信息流节点的关联模式的类型，所述关联 模式为一个信息流节点与其他信息流节点处理信息任务时的时序关系；

所述第一启动单元，用于在当前信息流节点的关联模式为第一类型且当 前信息流节点处理完信息任务后，启动预设协同处理节点集中的其他节点， 或者，在当前信息流节点的关联模式为第一类型且预设协同处理集中的其他 节点处理完信息任务后，启动当前信息流节点，所述第一类型为一个信息流 节点在另一个或多个信息流节点完成信息任务处理后启动；

所述第二启动单元，用于在当前信息流节点的关联模式为第二类型且当 前信息流节点是预设协同处理节点集中最晚识别为第二类型的节点时，启动 预设待协同处理节点集内的全部节点，所述第二类型为一个信息流节点与另 一个或多个信息流节点同步启动信息任务处理。

优选地，所述装置还包括接收单元，用于接收预设协同处理集中的其他 节点处理完信息任务后发送的通知消息，则所述第一启动单元具体用于：

在当前信息流节点的关联模式识别为第一类型且接收到的通知消息的数 量比预设协同处理节点集内的节点少一个时，启动当前信息流节点。

优选地，所述装置还包括发送单元，用于在当前信息流节点的关联模式 识别为第二类型时发送通知消息，则所述第二启动单元具体用于：

在当前信息流节点的关联模式为第二类型且当前信息流节点是预设协同 处理节点集中最晚发送通知消息的节点时，启动预设待协同处理节点集内的 全部节点。

优选地，所述装置还包括第一判断单元，用于在从预设协同处理节点集 中获取将处理信息任务的当前信息流节点后判断所述当前信息流节点是否具 有虚拟标记，所述虚拟标记用于标记处理信息任务过程中跳过的信息流节点， 如果否，则触发识别单元。

优选地，所述装置还包括第二判断单元，用于在从预设协同处理节点集 中获取将处理信息任务的当前信息流节点后判断所述当前信息流节点是否已 启动过信息处理任务，如果否，则触发识别单元。

本申请实施例在获取预设协同处理节点集中的信息流节点作为当前信息 流节点后，对其关联模式类型进行识别，然后根据不同的类型进行不同的处 理：如果类型为“通知启动”类型，则在当前信息流节点处理完信息任务后 启动协同处理节点集中其他节点或者在协同处理集中的其他节点处理完信息 任务后启动当前信息流节点；如果类型为“同步启动”类型，则判断当前信 息流节点是否是协同处理节点集中最晚被识别的节点，如果是，则启动待协 同处理的全部节点处理信息任务。与现有技术相比，本申请实施例抛弃了所 有关联模按照各自独立方式处理的现有做法，而是根据关联模式的特点，将 各种关联模式归结为两种类型，进而针对不同的类型采取相应的处理方式， 适应了多信息流节点关联模式多样化环境下的信息任务处理。此外，本申请 实施例针对节点跳跃、节点回退等特殊信息流模式，通过判断信息流节点的 虚拟标志或是否实例化等方式，给出了较好的解决方法。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实 施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面 描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员 来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1(a)～(e)为多信息流节点信息任务处理过程中常见的五种关联模 式示意图；

图2为本申请实施例一的多信息流节点的协同处理方法流程图；

图3为本申请实施例二的多信息流节点的协同处理方法流程图；

图4(a)、(b)为多信息流节点在信息任务处理中的特殊流转情形示意图；

图5为本申请实施例三的多信息流节点的协同处理装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合 本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描 述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施 例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前 提下所获得的所有其他实施例，都应当属于本申请保护的范围。

参见图2，该图示出了本申请的一种多信息流节点的协同处理方法实施例 (实施例一)的流程。该实施例包括：

步骤S201：从预设协同处理节点集中获取将处理信息任务的当前信息流 节点；

“协同处理”是相对于“独立处理”而言的：独立处理信息任务的信息 流节点不需依赖其他信息流节点或者不被其他信息流节点依赖(这种信息流 节点之间的相互依赖、约束等关系称为关联关系)而独立地完成信息任务的 处理，它按照正常业务流程处理即可；而协同处理信息任务的信息流节点或 者受到其他信息流节点的约束，或者约束其他信息流节点，因此，在信息任 务处理过程中，必须协同这些具有约束或被约束关系的信息流节点，以保证 信息处理任务的顺利完成。协同处理的节点可由用户在信息处理任务开始之 前进行指定，也可以根据业务需要由自动化设备按照预设条件从信息流中识 别出需要协同处理的节点，这些节点被归并到协同处理节点集之中。当处理 信息任务的信息流涉及正常信息流节点时，比如独立处理型信息流节点，则 按照正常的业务流程进行处理；当处理信息任务的信息流涉及到协同处理节 点时，则从预设的协同处理节点集内读取协同处理节点，将该节点作为当前 信息流节点。

在实际应用过程中，协同处理节点集可通过定义协同处理定义表予以反 映。协同处理定义表可设置多个属性字段，用于表征协同处理节点集的成员 以及各成员间的关联关系，比如可以包括：协同处理节点集标识、协同处理 节点集内各信息流节点标识、流程标识、是否等待等，其中：协同处理节点 集标识，用于在包含多个协同处理节点集时标识各个节点集；流程标识，用 于标识各信息流节点所述的信息流；是否等待，用于标识信息流节点是直接 启动还是需要等待别的节点的触发启动。

步骤S202：识别当前信息流节点的关联模式的类型，所述关联模式为一 个信息流节点与其他信息流节点处理信息任务时的时序关系；

聚焦到当前信息流节点后，本实施例需要识别当前信息流节点的关联模 式类型，关联模式体现了本信息流节点在处理信息任务过程中与其他信息流 节点之间的时序关系，这些时序关系主要包括两种类型：一是完成启动类型， 即本信息流节点的信息任务处理需要等待别的一个或多个信息流节点的任务 处理完成后才能启动(如图1(c)中的信息流节点2)，或者本信息流节点的 信息任务处理完成后才启动别的一个或多个其他信息流节点的任务处理(如 图1(e)中的信息流节点3和信息流节点5)，这种关系可以体现在一个信息 流内的两个或多个信息流节点之间(如图1(a)～(c))，也可以体现在属于 不同信息流的信息流节点之间(如图1(d)、(e))；二是同步启动类型，即本 信息流节点的信息任务处理需要和别的一个或多个信息流节点的任务处理同 步启动，同样地，这种关系可以体现在一个信息流内的两个或多个信息流节 点之间，也可以体现在属于不同信息流的信息流节点之间。在实际应用过程 中，还可能出现由上述两种类型组合成的混合型时序关系(如图1(c)、(e))。

步骤S203：如果当前信息流节点的关联模式为第一类型，则在当前信息 流节点处理完信息任务后启动预设协同处理节点集中的其他节点或者在预设 协同处理集中的其他节点处理完信息任务后启动当前信息流节点，所述第一 类型为一个信息流节点在另一个或多个信息流节点完成信息任务处理后启 动；

经过关联模式类型识别步骤，如果当前信息流节点的关联模式为第一类 型，即完成启动类型，则存在两种情形：一种是当前信息流节点为主动节点， 即当前信息流节点与协同处理节点集内的其他节点的关系为当前信息流节点 的任务处理完成后其他信息流节点才能启动信息任务的处理；另一种是当前 信息流节点为被动节点，即当前信息流节点与协同处理节点集内的其他节点 的关系为当前信息流节点的任务处理需要在其他信息流节点完成任务处理后 才能启动。针对不同类型，处理方式存在差别：对于前者，在当前信息流节 点处理完信息任务后，即启动预设协同处理节点集中的其他节点的任务处理； 对于后者，在预设协同处理集中的其他节点处理完信息任务后启动当前信息 流节点。需要说明的是：根据业务的执行流程，同一个信息流中的首节点仅 能为主动节点，即该节点的任务处理不需要等待其他节点任务执行完后启动， 同一个信息流中的末节点仅能为被动节点，即该节点的任务处理完成后不需 要通知其他节点的任务处理，但如果执行业务的信息流包括多个，则本流程 的首节点可能成为其他流程的被动节点，本流程的末节点可能成为其他流程 的主动节点。

步骤S204：如果当前信息流节点的关联模式为第二类型，则判断当前信 息流节点是否是预设协同处理节点集中最晚识别为第二类型的节点，如果是， 则启动预设待协同处理节点集内的全部节点，所述第二类型为一个信息流节 点与另一个或多个信息流节点同步启动信息任务处理；

经过关联模式类型识别步骤，如果当前信息流节点的关联模式为第二类 型，即同步启动类型，则说明该信息流节点与协同处理节点集中的其他节点 的任务处理需要同步进行。在同步启动类型下，并非信息流节点被识别为第 二类型后即启动全部信息流节点的处理，这时还需要判断当前信息流节点被 识别为第二类型的时间，如果该时间是协同处理节点集中的最晚的，则说明 协同处理节点集的其他节点已经存于等待状态，当前信息流节点的“识别” 可触发启动协同处理节点集中全部节点的信息任务的处理；如果该时间不是 协同处理节点集中最晚的，则说明协同处理节点集中还存在没有作为“当前 信息流节点”的节点，当前信息流节点将处于等待状态，直至协同处理节点 集中最晚被识别为第二类型的节点触发，才进行信息任务的处理。

本实施例在获取预设协同处理节点集中的信息流节点作为当前信息流节 点后，对其关联模式类型进行识别，然后根据不同的类型进行不同的处理： 如果类型为“完成启动”类型，则在当前信息流节点处理完信息任务后启动 协同处理节点集中其他节点或者在协同处理集中的其他节点处理完信息任务 后启动当前信息流节点；如果类型为“同步启动”类型，则判断当前信息流 节点是否是协同处理节点集中最晚被识别的节点，如果是，则启动待协同处 理的全部节点处理信息任务。与现有技术相比，本实施例抛弃了所有关联模 按照各自独立方式处理的现有做法，而是根据关联模式的特点，将各种关联 模式归结为两种基本类型，进而针对不同的类型采取相应的处理方式，由此 适应了多信息流节点关联模式多样化环境下的信息任务处理，总体上提高了 信息处理任务的处理效率。

在上述实施例基础上，还可以作出某些改进，从而形成本申请的又一个 多信息流节点的协同处理方法实施例(实施例二)。参见图3，该图示出了实 施例二的多信息流节点的协同处理方法流程，该图提供了两种改进方式：

改进方式之一：在实施例一的步骤S203中，针对当前信息流节点为被动 节点的情形，该信息流节点与协同处理节点集内的其他节点进行协同处理的 方式还可以按照如下步骤进行：

步骤S3031：接收预设协同处理集中的其他节点处理完信息任务后发送的 通知消息；

本实施例中协同处理节点集内的其他节点在其作为“当前信息流节点” 时，其处理完信息任务后发送通知消息，用以表明它自身的状态。当信息流 进行到本实施例的当前信息流节点时，接收其他节点发送的通知消息。

步骤S3032：在当前信息流节点的关联模式识别为第一类型时，判断接收 到的通知消息的数量是否比预设协同处理节点集内的节点少一个，如果是， 则启动当前信息流节点；

协同处理节点集内的节点可以根据是否处于“当前”而划分为两类：一 是被聚焦的当前信息流节点，二是未被聚焦的其他信息流节点，当在当前信 息流节点的处理过程中，如果接收到的通知消息的数量为N-1(N为协同处理 节点集内的节点数量)时，说明其他信息流节点均已发送通知消息，则可以 启动当前信息流节点的任务处理。

改进方式之二：在实施例一的步骤S204中，针对当前信息流节点是预设 协同处理节点集中最晚识别为第二类型的节点启动预设待协同处理节点集内 的全部节点的任务处理，可以按照如下步骤进行：

步骤S3041：在当前信息流节点的关联模式识别为第二类型时，发送通知 消息；

步骤S3042：判断当前信息流节点是否是待协同处理的节点中最晚发送通 知消息的节点，如果是，则启动预设待协同处理节点集内的全部节点。

上述改进方式一以接收通知消息的形式来判定一个协同处理节点集内除 当前信息流节点之外的其他信息流节点是否处理完信息任务，上述改进方式 二通过发送的通知消息来判定当前信息流节点是否为协同处理节点集内最晚 识别的节点，这些改进方式使多个信息流节点之间的协同处理过程变成简单 的信息交互过程，从而方便了具有关联关系的信息流节点间的任务处理。

在实际应用过程中，还可以根据上述通过消息(包括“完成启动类型” 下协同处理节点集内完成节点任务处理的其他节点发送的通知消息和“同步 启动类型”下当前信息流节点被识别出关联模式类型后发送的通知消息)生 成协同处理实例表，用于记录协同处理节点集内各节点的任务处理状态。该 协同处理实例表可以设置多个属性字段，比如协同业务主键、协同处理节点 集标识、流程标识、节点标识等，其中：协同处理主键，用于在处理信息任 务过程中唯一标识需要协同处理的节点；协同处理节点集标识，用于标识当 前信息流节点所在的协同处理节点集；流程标识，用于标识当前信息流节点 所在的信息流：节点标识，用于标识发送通知消息的协同处理节点集内的信 息流节点。设置协同处理实例表后，协同处理节点集内的各信息流节点一旦 发送通知，则可根据该通知在该实例表中插入一个包含上述字段的记录，从 而可以通过该表获知协同处理节点集内各节点的状态。

前述两个实施例描述了处理信息任务的信息流正常流转情况下多信息流 节点间的协同处理方法，但是，在实际应用过程中，信息流可能出现特殊流 转过程，比如出现“节点跳跃”，即信息流中的某些节点未被执行(聚焦)， 如图4(a)中的信息流节点2，在这种情况下，所有等待该节点触发的协同 处理节点集内的其他节点将无法启动，从而影响到信息任务的正常处理。还 比如，出现“节点回退”，即某些信息流中的某些节点因各种原因遭遇驳回， 如图4(b)中的信息流节点3，在这种情况下，由于协同处理节点集中的其 他同步节点的任务处理均已结束，驳回起点和驳回终点中的信息流节点将永 远无法启动。针对这些信息流的特殊流转过程，本申请提供了相应的解决办 法：

对于节点跳跃的情形：系统将逐一查询跳过的信息流节点，并判断这些 跳过的节点是否属于协同处理节点集中的节点，如果属于，则对该节点进行 虚拟标记，如果采用协同处理实例表的方式来记录节点的状态，系统将为该 节点生成一条虚拟记录，并将该记录插入到协同处理实例表之中。基于此， 本申请对于节点跳跃时的多信息流节点的协同处理方式如下：

在从预设协同处理节点集中获取将处理信息任务的当前信息流节点后， 判断所述当前信息流节点是否具有虚拟标记，如果否，则执行识别当前信息 流节点的关联模式的类型的步骤。

对于节点回退的情形：系统将逐一查询回退起点和回退终点之间的信息 流节点，并判断这些跳过的节点是否属于协同处理节点集中的节点，如果属 于，系统会查询在当前业务(协同处理实例表中的业务主键)下是否已执行 当前信息流节点，如果是，说明当前信息流节点是再次执行的节点，不再需 要协同控制，正常启动即可。即可按照如下方式处理：

在从预设协同处理节点集中获取将处理信息任务的当前信息流节点后， 判断所述当前信息流节点是否已启动过信息处理任务，如果否，则执行识别 当前信息流节点的关联模式的类型的步骤。

前述内容均是对本申请方法实施例的描述，相应地，本申请还提供了多 信息流节点的协同处理装置实施例(实施例三)。参见图5，该图示出了本装 置实施例的多信息流节点协同处理装置的结构框架。该装置实施例500包括： 获取单元501、识别单元502、第一启动单元503和第二启动单元504，其中：

获取单元501，用于从预设协同处理节点集中获取将处理信息任务的当前 信息流节点；

识别单元502，用于识别当前信息流节点的关联模式的类型，所述关联模 式为一个信息流节点与其他信息流节点处理信息任务时的时序关系；

第一启动单元503，用于在当前信息流节点的关联模式为第一类型且当前 信息流节点处理完信息任务后，启动预设协同处理节点集中的其他节点，或 者，在当前信息流节点的关联模式为第一类型且预设协同处理集中的其他节 点处理完信息任务后，启动当前信息流节点，所述第一类型为一个信息流节 点在另一个或多个信息流节点完成信息任务处理后启动；

第二启动单元504，用于在当前信息流节点的关联模式为第二类型且当前 信息流节点是预设协同处理节点集中最晚识别为第二类型的节点时，启动预 设待协同处理节点集内的全部节点，所述第二类型为一个信息流节点与另一 个或多个信息流节点同步启动信息任务处理。

本装置实施例的工作过程是：先由获取单元501从预设协同处理节点集 中获取的信息流节点作为当前信息流节点，然后由识别单元502对其关联模 式类型进行识别，根据不同的类型进行不同的处理：如果类型为“完成启动” 类型，则由第一启动单元503在当前信息流节点处理完信息任务后启动协同 处理节点集中其他节点或者在协同处理集中的其他节点处理完信息任务后启 动当前信息流节点；如果类型为“同步启动”类型，则由第二启动单元判断 当前信息流节点是否是协同处理节点集中最晚被识别的节点，如果是，则启 动待协同处理的全部节点处理信息任务。

与现有技术相比，本申请实施例抛弃了所有关联模按照各自独立方式处 理的现有做法，而是根据关联模式的特点，将各种关联模式归结为两种类型， 进而针对不同的类型采取相应的处理方式，适应了多信息流节点关联模式多 样化环境下的信息任务处理。

上述装置实施例中还包括接收单元，用于接收预设协同处理集中的其他 节点处理完信息任务后发送的通知消息，则所述第一启动单元具体用于：在 当前信息流节点的关联模式识别为第一类型且接收到的通知消息的数量比预 设协同处理节点集内的节点少一个时，启动当前信息流节点。上述装置实施 例还包括发送单元，用于在当前信息流节点的关联模式识别为第二类型时发 送通知消息，则所述第二启动单元具体用于：在当前信息流节点的关联模式 为第二类型且当前信息流节点是预设协同处理节点集中最晚发送通知消息的 节点时，启动预设待协同处理节点集内的全部节点。通过增加接收单元，从 而以接收通知消息的形式来判定一个协同处理节点集内除当前信息流节点之 外的其他信息流节点是否处理完信息任务，通过增加发送单元，从而通过发 送的通知消息来判定当前信息流节点是否为协同处理节点集内最晚识别的节 点，这些方式使多个信息流节点之间的协同处理过程变成简单的信息交互过 程，从而方便了具有关联关系的信息流节点间的任务处理。

前述装置实施例是在处理信息任务的信息流正常流转情况下的结构，在 实际应用过程中，信息流还可能出现一些特殊流转控制逻辑，比如节点跳跃、 节点回退等，针对这些情形，本申请还提供了对应的解决方案：对于节点跳 跃的情形，本装置实施例可以包括第一判断单元505，用于在从预设协同处理 节点集中获取将处理信息任务的当前信息流节点后判断所述当前信息流节点 是否具有虚拟标记，所述虚拟标记用于标记处理信息任务过程中跳过的信息 流节点，如果否，则触发识别单元；对于节点回退的情形，本装置实施例可 以包括第二判断单元506，用于在从预设协同处理节点集中获取将处理信息任 务的当前信息流节点后判断所述当前信息流节点是否已启动过信息处理任 务，如果否，则触发识别单元。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然， 在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到 本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解， 本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品 的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、 磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机， 服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所 述的方法。

本申请说明书中的实施例采用递进的方式描述，实施例之间相同相似的 部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。 尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比 较简单，相关之处参见方法实施例的部分说明即可。以上所描述的实施例仅 仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物 理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以 位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选 择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人 员在不付出创造性劳动的情况下，即可以理解并实施。

本申请可用于众多通用或专用的计算系统环境或配置中。例如：个人计 算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、 基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算 机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述， 例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类 型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中 实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处 理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备 在内的本地和远程计算机存储介质中。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普 通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润 饰，这些改进和润饰也应视为本申请的保护范围。