CN104484173B - 基于TPL Dataflow的状态监控方法及装置 - Google Patents

Abstract

本发明公开了一种基于TPL Dataflow的状态监控方法及装置。其中，该方法包括：在.Net开发环境中调用TPL Dataflow类库，并通过TPL Dataflow类库中的一个或多个级块Block构成用于处理数据的处理通道；获取预先设置的需要监视的级块Block的集合列表；遍历级块Block的集合列表中的各个级块Block，获取处理通道中的各个级块Block的状态属性；根据各个级块Block的状态属性，确定级块Block的运行状态。本发明解决了现有技术中每次手动查看各个级块Block的状态属性导致的操作繁琐、效率低下的问题。

Description

基于TPL Dataflow的状态监控方法及装置

技术领域

本发明涉及计算机领域，具体而言，涉及一种基于TPL Dataflow的状态监控方法及装置。

背景技术

TPL是TASK Parallel Library的简称，TPL Dataflow是微软面向高并发应用而推出的类库，借助于异步消息传递与管理，提供比线程池更好的控制。TPL Dataflow提供了一种类似流水线的数据处理视图，数据流中的数据处理节点被称作数据流块(DataflowBlock)。每个Dataflow Block包含一个Input Buffer和Output Buffer。在处理数据流的时候，有必要让开发人员随时了解当前"流水线"的工作状态，以及时了解流水线是否存在故障。

一种传统的监视方法是异步地轮询每个Block的Input Buffer和Output Buffer数目，试图了解每个Block的运作状态。然而这种方式是以数字形式展现，非常不直观，开发人员不能一眼看出哪些Block存在故障；而且，这种方式只展现了每个Block的待处理队列和待传出队列的信息，有时候依然无法给出定位故障Block所需的信息。比如，很多时候，假若某故障Block将待处理数据缓存到了Block内部，并且在内部出现某种故障、不再产生输出，也不结束。此时通过基于Input\Output Count的监视器，会看到所有Block的InputCount和Output Count都是0，但是，却无法知道哪些Block已结束、哪些Block还在运行，无法找到故障Block。

针对现有技术中每次手动查看各个级块Block的状态属性导致的操作繁琐、效率低下的问题，目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种基于TPL Dataflow的状态监控方法及装置，以解决现有技术中每次手动查看各个级块Block的状态属性导致的操作繁琐、效率低下问题。

为了实现上述目的，根据本发明实施例的一个方面，提供了一种基于TPLDataflow的状态监控方法。该方法包括：在.Net开发环境中调用TPL Dataflow类库，并通过TPLDataflow类库中的一个或多个级块Block构成用于处理数据的处理通道；获取预先设置的需要监视的级块Block的集合列表；遍历级块Block的集合列表中的各个级块Block，获取处理通道中的各个级块Block的状态属性；根据各个级块Block的状态属性，确定级块Block的运行状态。

为了实现上述目的，根据本发明实施例的另一方面，提供了一种基于TPLDataflow的状态监控装置，该装置包括：构成单元，用于在.Net开发环境中调用TPLDataflow类库；并通过TPL Dataflow类库中的一个或多个级块Block构成用于处理数据的处理通道；第一获取单元，用于获取预先设置的需要监视的级块Block的集合列表；第二获取单元，用于遍历级块Block的集合列表中的各个级块Block，获取处理通道中的各个级块Block的状态属性；处理单元，用于根据各个级块Block的状态属性，确定级块Block的运行状态。

根据发明实施例，通过获取各个级块Block的状态属性，进而确定各个级块Block的运行状态，解决了现有技术中每次手动查看各个级块Block的状态属性导致的操作繁琐、效率低下的问题。实现了准确、直观的判断某一个Block运行状态，进而能够快速、精确的在数据处理通道中定位到出现故障的Block的效果。

附图说明

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

图1是根据本发明实施例一的基于TPL Dataflow的状态监控方法的流程图；以及

图2是根据本发明实施例二的基于TPL Dataflow的状态监控装置的框图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

本发明实施例提供了一种基于TPL Dataflow的状态监控方法。

图1是根据本发明实施例的基于TPL Dataflow的状态监控方法的流程图。如图1所示，该方法包括步骤如下：

步骤S11，在.Net开发环境中调用TPL Dataflow类库，并通过TPL Dataflow类库中的一个或多个级块Block构成用于处理数据的处理通道。

具体的，在上述步骤S11中，TPL Dataflow类库中包含了各种功能不同的级块Block，可以根据需求在处理通道中加入功能不同的级块Block。

步骤S13，获取预先设置的需要监视的级块Block的集合列表。

具体的，在上述步骤S13中，可以将需要监视的级块Block加入至集合列表当中，把性能稳定的级块Block从集合列表中删除，这样，通过预先设置的级块Block的集合列表，就可以方便的对需要进行监控的级块Block进行设置。

步骤S15，遍历级块Block的集合列表中的各个级块Block，获取处理通道中的各个级块Block的状态属性。

具体的，在上述步骤S15中，可以通过获取每个Block的Completion Task属性，可以清晰的判断该Block的工作状态，是正在运行，还是已经运行结束。Completion Task属性有助于判断Block的真实状态。

步骤S17，根据各个级块Block的状态属性，确定级块Block的运行状态。

具体的，在上述步骤S17中，通过级块Block的状态属性仅用来表示当前级块Block的在实际运行中所处于的状态，而级块Block的运行状态，则是相比于整个处理通道而言，着重描述的是该级块Block的状态对于真个数据处理通道的贡献，若该级块Block能够执行且正确的执行处理通道分配的任务，则认为该级块Block的运行状态正常；若该级块Block不能够执行处理通道分配的任务，则该级块Block的状态属性表现异常；若该级块Block能够执行但错误的执行处理通道分配的任务，虽然从状态属性上看该级块Block并无异常，但此时仍认为该级块Block的运行状态非正常。

综上可知，本发明解决了现有技术中每次手动查看各个级块Block的状态属性导致的操作繁琐、效率低下的问题。实现了准确、直观的判断某一个级块Block运行状态，进而能够快速、精确的在数据处理通道中定位到出现故障的级块Block的效果。

优选的，在步骤S15遍历级块Block的集合列表中的各个级块Block，获取处理通道中的各个级块Block的状态属性中，步骤还包括：

步骤S151，接收触发信号，其中，触发信号至少包括如下任意一种生成方式：通过用户手动点击触发控件生成触发信号、通过预先设定的发送频率生成触发信号。

步骤S153，当接收到触发信号时，根据级块Block的集合列表获取级块Block的状态属性。

具体的，通过上述步骤S151至步骤S153，监视器会异步运行一个任务，该任务，每隔一定时间，就会根据集合列表，轮询该Block集合列表中的所有Block，获取所有Block的状态属性并进行打印。此实例中，获取的Block的状态属性主要为：每个Dataflow Block包含的Completion Task属性，该Completion Task属性表示了该DataflowBlock的运作状态。Completion Task属性至少包括“Running”运行状态，“Complete”完成状态。

优选的，在步骤S17根据各个级块Block的状态属性，确定级块Block的运行状态中，步骤包括：

步骤S171，遍历处理通道中的各个级块Block，确定处理通道中级块Block的总数量。

步骤S173，根据处理通道中所包含的级块Block的总数量和各个级块的Block的状态属性，确定处理通道的工作状态。

步骤S175，将各个级块的Block的状态属性与处理通道的工作状态进行比对，确定各个级块Block的运行状态。

具体的，通过上述步骤S171至步骤S175，遍历了处理通道中的各个级块Block，确定了处理通道中级块Block的总数量。并根据获取的各个级块Block的状态属性进行分析并确定该处理通道的工作状态。当有级块Block的工作状态与级块Block所处的处理通道的工作状态不一致时，则认为这个级块Block的运行状态不正常。例如，若有一个级块Block的状态为“Running”，其他所有级块Block的状态均为“Complete”，那么可以确定，当前处理通道的工作状态为“Complete”状态；而经过比对，可以迅速定位该状态属性与当前处理通道的工作状态不同的级块Block。

优选的，当状态属性至少包括：运行中和完成时，其中，在步骤S173根据处理通道中所包含的级块Block的总数量和各个级块的Block的状态属性，确定处理通道的工作状态中，步骤还包括：

步骤S1731，根据各个级块Block的状态属性，确定状态属性为运行中的级块Block的运行数量。

步骤S1733，根据级块Block的运行数量和处理通道中级块Block的总数量，计算得出状态属性为运行中的级块Block的运行比例。

步骤S1735，根据运行比例，确定处理通道的工作状态。

具体的，通过上述步骤S171至步骤S175，对处理通道中，状态属性为“运行中”的级块Block和状态属性为“完成”的级块Block的数量进行确认，当状态属性为“运行中”的级块Block的比例大于状态属性为“完成”的级块Block的情况下，判断处理通道的工作状态为“运行中Running”。反之，处理通道的工作状态为“完成Complete”。当然，级块Block的状态属性还可以包括其他状态类型，都可以通过上述判断处理通道的工作状态的方法进行确定，此处不做赘述。

上述实例通过异步的监视每个Dataflow Block的Completion Task属性，进而获取处理通道中运行中的Block及其总数量，以及完成时的Block及其总数量，有助于判断当前处理通道的工作状态，并将Block的属性状态与当前处理通道的工作状态进行比对，迅速找出故障Block。

优选的，在步骤S13获取预先设置的需要监视的级块Block的集合列表之前，方法还包括：

步骤S12，遍历处理通道中的级块Block，生成级块Block的集合列表。

具体的，通过上述步骤S12，可以通过系统遍历处理通道中的级块Block的方法，自动生成级块Block的集合列表。从而免去了人为操作的麻烦。在程序设计的初期，可以通过该方法，来对处理通道进行调试。

实施例2

本发明实施例还提供了一种基于TPL Dataflow的状态监控装置，如图2所示，该装置可以包括：构成单元21、第一获取单元23、第二获取单元25和处理单元27。

其中，构成单元21，用于在.Net开发环境中调用TPL Dataflow类库，并通过TPLDataflow类库中的一个或多个级块Block构成用于处理数据的处理通道。

具体的，在上述构成单元21中，TPL Dataflow类库中包含了各种功能不同的级块Block，可以根据需求在处理通道中加入功能不同的级块Block。

第一获取单元23，用于获取预先设置的需要监视的级块Block的集合列表。

具体的，在上述第一获取单元23中，可以将需要监视的级块Block加入至集合列表当中，把性能稳定的级块Block从集合列表中删除，这样，通过预先设置的级块Block的集合列表，就可以方便的对需要进行监控的级块Block进行设置。

第二获取单元25，用于遍历级块Block的集合列表中的各个级块Block，获取处理通道中的各个级块Block的状态属性。

具体的，在上述第二获取单元25中，可以通过获取每个Block的Completion Task属性，可以清晰的判断该Block的工作状态，是正在运行，还是已经运行结束。CompletionTask属性有助于判断Block的真实状态。

处理单元27，用于根据各个级块Block的状态属性，确定级块Block的运行状态。

具体的，在上述处理单元27中，通过级块Block的状态属性仅用来表示当前级块Block的在实际运行中所处于的状态，而级块Block的运行状态，则是相比于整个处理通道而言，着重描述的是该级块Block的状态对于真个数据处理通道的贡献，若该级块Block能够执行且正确的执行处理通道分配的任务，则认为该级块Block的运行状态正常；若该级块Block不能够执行处理通道分配的任务，则该级块Block的状态属性表现异常；若该级块Block能够执行但错误的执行处理通道分配的任务，虽然从状态属性上看该级块Block并无异常，但此时仍认为该级块Block的运行状态非正常。

综上可知，本发明解决了现有技术中每次手动查看各个级块Block的状态属性导致的操作繁琐、效率低下的问题。实现了准确、直观的判断某一个级块Block运行状态，进而能够快速、精确的在数据处理通道中定位到出现故障的级块Block的效果。

优选的，上述第二获取单元25包括：接收模块251和接收模块251。

其中，接收模块251，用于接收触发信号，其中，触发信号至少包括如下任意一种生成方式：通过用户手动点击触发控件生成触发信号、通过预先设定的发送频率生成触发信号。

第一获取模块253，用于当接收到触发信号时，根据级块Block的集合列表获取级块Block的状态属性。

具体的，通过上述接收模块251和接收模块251，监视器会异步运行一个任务，该任务，每隔一定时间，就会根据集合列表，轮询该Block集合列表中的所有Block，获取所有Block的状态属性并进行打印。此实例中，获取的Block的状态属性主要为：每个DataflowBlock包含的Completion Task属性，该Completion Task属性表示了该Dataflow Block的运作状态。Completion Task属性至少包括“Running”运行状态，“Complete”完成状态。

优选的，上述处理单元27包括：第一处理模块271、第二处理模块273和第三处理模块275。

其中，第一处理模块271，用于遍历构成单元201构成的处理通道中的各个级块Block，确定处理通道中级块Block的总数量。

第二处理模块273，用于根据处理通道中所包含的级块Block的总数量和第一获取模块获取的各个级块Block的状态属性，确定处理通道的工作状态。

第三处理模块275，用于将各个级块的Block的状态属性与处理通道的工作状态进行比对，确定各个级块Block的运行状态。

具体的，通过上述第一处理模块271、第二处理模块273和第三处理模块275，遍历了处理通道中的各个级块Block，确定了处理通道中级块Block的总数量。并根据获取的各个级块Block的状态属性进行分析并确定该处理通道的工作状态。当有级块Block的工作状态与级块Block所处的处理通道的工作状态不一致时，则认为这个级块Block的运行状态不正常。例如，若有一个级块Block的状态为“Running”，其他所有级块Block的状态均为“Complete”，那么可以确定，当前处理通道的工作状态为“Complete”状态；而经过比对，可以迅速定位该状态属性与当前处理通道的工作状态不同的级块Block。

优选的，当状态属性至少包括：运行中和完成时，上述第二处理模块273包括：第四处理模块2731、计算模块2733和第五处理模块2735。

其中，第四处理模块2731，用于根据各个级块Block的状态属性，确定状态属性为运行中的级块Block的运行数量。

计算模块2733，用于根据级块Block的运行数量和处理通道中级块Block的总数量，计算得出状态属性为运行中的级块Block的运行比例。

第五处理模块2735，用于根据运行比例，确定处理通道的工作状态。

具体的，通过上述步骤S171至步骤S175，对处理通道中，状态属性为“运行中”的级块Block和状态属性为“完成”的级块Block的数量进行确认，当状态属性为“运行中”的级块Block的比例大于状态属性为“完成”的级块Block的情况下，判断处理通道的工作状态为“运行中Running”。反之，处理通道的工作状态为“完成Complete”。当然，级块Block的状态属性还可以包括其他状态类型，都可以通过上述判断处理通道的工作状态的方法进行确定，此处不做赘述。

上述实例通过异步的监视每个Dataflow Block的Completion Task属性，进而获取处理通道中运行中的Block及其总数量，以及完成时的Block及其总数量，有助于判断当前处理通道的工作状态，并将Block的属性状态与当前处理通道的工作状态进行比对，迅速找出故障Block。

优选的，上述装置还包括：生成单元22。

其中，生成单元22，用于遍历构成单元构成的处理通道中的级块Block，生成级块Block的集合列表。

具体的，通过上述生成单元22，可以通过系统遍历处理通道中的级块Block的方法，自动生成级块Block的集合列表。从而免去了人为操作的麻烦。在程序设计的初期，可以通过该方法，来对处理通道进行调试。

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

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、移动终端、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于TPL Dataflow的状态监控方法，其特征在于，包括：

在.Net开发环境中调用TPL Dataflow类库，并通过所述TPL Dataflow类库中的一个或多个级块Block构成用于处理数据的处理通道；

获取预先设置的需要监视的所述级块Block的集合列表；

遍历所述级块Block的集合列表中的各个级块Block，获取所述处理通道中的各个级块Block的状态属性；

根据所述各个级块Block的状态属性，确定所述级块Block的运行状态；

其中，根据所述各个级块Block的状态属性，确定所述级块Block的运行状态包括：将所述各个级块的Block的状态属性与所述处理通道的工作状态进行比对，确定所述各个级块Block的运行状态。

2.根据权利要求1所述的方法，其特征在于，遍历所述级块Block的集合列表中的各个级块Block，获取所述处理通道中的各个级块Block的状态属性的步骤还包括：

接收触发信号，其中，所述触发信号至少包括如下任意一种生成方式：通过用户手动点击触发控件生成所述触发信号、通过预先设定的发送频率生成所述触发信号；

当接收到所述触发信号时，根据所述级块Block的集合列表获取所述级块Block的状态属性。

3.根据权利要求2所述的方法，其特征在于，根据所述各个级块Block的状态属性，确定所述级块Block的运行状态的步骤还包括：

遍历所述处理通道中的各个级块Block，确定所述处理通道中级块Block的总数量；

根据所述处理通道中所包含的级块Block的总数量和所述各个级块的Block的状态属性，确定所述处理通道的工作状态。

4.根据权利要求3所述的方法，其特征在于，当所述状态属性至少包括：运行中和完成时，其中，根据所述处理通道中所包含的级块Block的总数量和所述各个级块的Block的所述状态属性，确定所述处理通道的工作状态的步骤还包括：

根据所述各个级块Block的所述状态属性，确定所述状态属性为所述运行中的级块Block的运行数量；

根据所述级块Block的运行数量和所述处理通道中级块Block的总数量，计算得出所述状态属性为运行中的级块Block的运行比例；

根据所述运行比例，确定所述处理通道的所述工作状态。

5.根据权利要求1至4中任意一项所述的方法，其特征在于，在获取预先设置的需要监视的所述级块Block的集合列表之前，所述方法还包括：

遍历所述处理通道中的所述级块Block，生成所述级块Block的集合列表。

6.一种基于TPL Dataflow的状态监控装置，其特征在于，包括：

构成单元，用于在.Net开发环境中调用TPL Dataflow类库；并通过所述TPL Dataflow类库中的一个或多个级块Block构成用于处理数据的处理通道；

第一获取单元，用于获取预先设置的需要监视的所述级块Block的集合列表；

第二获取单元，用于遍历所述级块Block的集合列表中的各个级块Block，获取所述处理通道中的各个级块Block的状态属性；

处理单元，用于根据所述各个级块Block的状态属性，确定所述级块Block的运行状态；

其中，所述处理单元包括：第三处理模块，用于将所述各个级块的Block的状态属性与所述处理通道的工作状态进行比对，确定所述各个级块Block的运行状态。

7.根据权利要求6所述的装置，其特征在于，第二获取单元还包括：

接收模块，用于接收触发信号，其中，所述触发信号至少包括如下任意一种生成方式：通过用户手动点击触发控件生成所述触发信号、通过预先设定的发送频率生成所述触发信号；

第一获取模块，用于当接收到所述触发信号时，根据所述级块Block的集合列表获取所述级块Block的状态属性。

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

第一处理模块，用于遍历所述构成单元构成的所述处理通道中的各个级块Block，确定所述处理通道中级块Block的总数量；

第二处理模块，用于根据所述处理通道中所包含的级块Block的总数量和所述第一获取模块获取的所述各个级块Block的状态属性，确定所述处理通道的工作状态。

9.根据权利要求8所述的装置，其特征在于，当所述状态属性至少包括：运行中和完成时，其中，第二处理模块还包括：

第四处理模块，用于根据所述各个级块Block的所述状态属性，确定所述状态属性为所述运行中的级块Block的运行数量；

计算模块，用于根据所述级块Block的运行数量和所述处理通道中级块Block的总数量，计算得出所述状态属性为所述运行中的级块Block的运行比例；

第五处理模块，用于根据所述运行比例，确定所述处理通道的所述工作状态。

10.根据权利要求6至9中任意一项所述的装置，其特征在于，所述装置还包括：

生成单元，用于遍历所述构成单元构成的所述处理通道中的所述级块Block，生成所述级块Block的集合列表。