具体实施方式

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

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

为了便于理解本申请的实施例，下面对本申请涉及的部分术语进行解释说明。

任务调度：在计算机科学中，调度就是一种将任务分配给资源去执行的方法。任务可以是项目中的至少一个任务或者一个工作流，可以包括shell脚本(shell script)、java程序、MapReduce程序、hive脚本(hive script)等。各任务之间会存在时间先后以及前后依赖关系，并且存在着周期性重复，而给所有的任务运行定一个运行规则，再按照规则去安排执行的任务就可以理解为任务调度。常见的任务调度系统包括Azkaban、Ooize、Cascading等，任务调度系统最基本的功能是任务定义和任务编排；任务定义主要是确定数据计算和加工的逻辑和规则，包括任务执行的频次、具体执行时间、对应的执行脚本和参数等内容；任务编排主要是确定不同任务的先后关系，确保任务有序且高效地进行。任务编排的输出结果是一个有向无环图(Directed Acyclic graph,DAG)，方便用户查看任务的依赖关系及执行情况，对程序的运行过程进行可视化跟踪。

有向无环图：在数学和计算机科学中，有向无环图是指一个无回路的有向图。有向无环图的结点和结点之间存在的关系是有指向的，并且是单向的，只能从一结点指向另一结点，无法反向，并且可以从任一结点出发沿着方向走过多个结点，但绝对无法再次回到起点，走过的路径无法形成环路。

叶子结点：一棵树当中没有子结点的结点称为叶子结点，简称“叶子”，又称为终端结点。

项目发布：是指将在离线数据开发平台上配置好调度信息、任务依赖关系的项目，对应地在任务调度系统上生成调度项目的过程。

下面对本申请涉及的应用场景进行说明。

随着信息技术的发展，数据分析处理任务大多包含多个数据处理步骤，比如数据的采集、传输、计算、展示等，每个步骤的数据处理算法需要提交到计算框架运行，其中有些步骤可以并发执行，有些步骤需要有依赖关系。在任务简单时可以人为控制，但是当任务非常多、关系复杂时，如果没有清晰的任务规划图，很容易在任务之间形成闭环从而出错，或者多个可并行的任务没有并行执行而浪费资源。而且，有些任务需要在某个特定的时间点去执行，还有些任务的执行具有一定的周期性，为了很好地组织起这样复杂的执行计划、将这种复杂的任务定时调度到分布式计算框架运行，出现了很多任务调度工具。

Azkaban就是其中一种主流的任务调度工具，可以用来对任务进行调度和监控，包括管理程序脚本、配置任务的依赖关系、检查程序是否执行正确、在程序出错时发出报警并重试等功能。应该理解的是，Azkaban并不限于在大数据领域中使用，凡是涉及到任务调度的，Azkaban都可以发挥其任务调度能力，比如说一个简单的定时发送邮件任务就可以通过在Azkaban上设置任务执行时间来定时调度执行。在Azkaban框架下是按照项目(project)、工作流(flow)、任务(job)依次来管理的。一个项目包含一个或多个工作流，一个工作流包含多个任务。job是在Azkaban中运行的一个进程，可以是简单的Linux命令，也可以是java程序，还可以是复杂的shell脚本、MapReduce程序、hive脚本或者Python脚本等。一个job可以依赖于另一个job的运行结果，各个job之间形成依赖关系，便组成了工作流，在一个工作流内以一个特定的顺序运行一组任务。

图1是本申请实施例提供的一种基于Azkaban的任务调度系统100，该任务调度系统100可包括：管理服务器101(Azkaban Web Server)、执行服务器102(AzkabanExecutorServer)和关系型数据库103(Relational Database)。管理服务器101、执行服务器102和关系型数据库103之间可通过网络连接，该网络可以是有线网络，也可以是无线网络，还可以是二者的混合。

关系型数据库103目前仅支持使用MySQL数据库，需要在MySQL服务器中创建Azkaban数据库并且完成初始化。Azkaban系统将配置文件信息和绝大多数的状态信息都保存在MySQL数据库103中，管理服务器101和执行服务器102都需要访问MySQL。

管理服务器101作为Azkaban主要的管理者，功能包括用户登录认证、项目创建、项目管理、上传任务、任务定时、查看任务执行状情况、查看历史任务等等。用户可通过浏览器104访问管理服务器101，并在管理服务器提供的用户界面(UserInterface，UI)上执行上述各种管理操作。

执行服务器102是整个任务调度系统中实际运行任务的结点，主要负责工作流的提交和执行，包括调度Hadoop任务、调度shell脚本任务、调度hive任务、单点故障等，并通过MySQL数据库103来协调各任务的执行。

也就是说，Azkaban的管理服务器101是作为分发者存在的，管理服务器101分发任务到执行服务器102中，执行服务器102再从Azkaban数据库103的项目文件(project_files)中拿到用户上传的压缩文件，并解压到本地的项目(projects)文件夹中，最终提交任务到线程池中，其执行的本质就是将每个job放置在线程池中执行。

Azkaban定义了一种KV文件(properties)格式来建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪工作流。首先，用户需要新建一个以.job为拓展名的文件，一个.job文件即代表一个任务。所有的任务都需要一个指导它如何去执行的类型(type)，Azkaban默认的任务类型包括command、java等。定义完job类型后，在这个文件中添加这个任务所需的参数与参数值，可以添加的其中一种参数为dependencies参数，它定义了该文件所依赖的文件，值为被依赖文件的文件名，多个目标以逗号分隔，不加拓展名。保存为.job文件即创建好了一个job，定义好所有的参数后即定义好了一个job，如果添加了dependencies参数，便是配置了任务间的依赖关系以形成工作流。然后将所有.job文件以及所需要的资源文件(例如java程序包、hive脚本文件、MapReduce程序jar包等)打包成一个zip文件，在Azkaban提供的用户界面上传。Azkaban会对上传的zip文件进行解压缩，然后分析形成各个结点组成的有向无环图，也就是在web用户界面呈现一个任务间的依赖关系图，便于用户查看任务间的依赖关系以及各任务的执行状态等。依赖关系图中用实线连接具有依赖关系的结点，默认用灰色表示任务未执行，蓝色表示任务执行中，绿色表示任务执行成功，红色表示任务执行失败。然后用户选择配置定时调度(schedule)或者立即执行(execute)。若选择定时调度方式，则在达到定时调度的时间点时，执行服务102就会到Azkaban数据库103中读取配置文件，然后将需要的数据下载到本地。之后执行服务器102开始执行工作流，并将各任务的执行状态信息不断的放入到数据库103中，通过web管理服务器101可以查看执行状态信息等。

例如，图2示例性地给出了任务间的一种关系图。用户在本地新创建一个A.job文件，再创建一个B.job文件，并且在B.job文件中添加语句“dependencies＝A”，即通过添加dependencies参数定义了B任务依赖于A任务的执行结果。同理，创建C.job文件，令C任务也依赖于A任务，再创建D.job文件，令D任务依赖于B任务及C任务，最后创建E.job文件，令E任务依赖于D任务。保存好5个job文件之后，将这5个job文件及各任务所需的资源文件一起打包成zip包(即配置文件)。在Azkaban的web管理界面新建一个项目，包括填写工作流名称、备注信息等等，然后上传这个zip包，从而一个工作流建好，任务调度系统将配置文件存储在azkaban数据库103中，最终呈现一个如图2所示的任务间的依赖关系图。

相关技术中，用户手动编写完成各任务各自的配置文件，并将所有的配置文件及所需要的资源文件打包成一个zip文件，通过Azkaban服务器提供的用户界面向Azkaban服务器上传zip文件，之后再通过该用户界面调取Azkaban服务器上各任务各自的调度信息配置页面，通过页面切换的方式，逐一完成各调度信息配置页面上调度信息的配置。然而，由于配置文件的编写和调度信息的配置由用户分多次完成，因此导致配置过程较复杂。

为了解决相关技术中具有的上述技术问题，本申请实施例提供一种任务调度方法，该方法可应用于能够与图1所示的任务调度系统通信的电子设备中，该电子设备中部署有能够呈现可视化配置界面的离线数据开发平台，当需要进行项目发布时，用户启动运行该离线数据开发平台，并从该离线数据开发平台提供的可视化配置界面上进行调度相关的配置。

如图3所示，该方法可以包括以下步骤：

步骤301、从可视化配置界面的关系图编辑区域，获取用于反映各任务之间的依赖关系的关系图。

关系图编辑区域用于根据用户的拖拽操作生成反映各任务之间的依赖关系的关系图。其中，关系图编辑区域包括目录树区域和关系图生成区域，目录树区域包括至少一个结点，每个结点唯一对应一个任务。本实施例中，目录树区域中的结点可以划项目设置，即目录树区域包括此次项目下各任务各自对应的结点，除此之外，该目录树区域还可以包括其它项目下的任务对应的结点；当然为了保证结点的通用性，还可以对目录树区域中的结点分类设置，以使得不同项目下同一类别的任务可以用同一结点表示，当然还可以按照其它的属性或参数对目录树区域中的结点进行设置，本实施例对此不作具体限定。

当根据用户的拖拽操作生成关系图时，获取用户从目录树区域所拖拽的至少两个结点，并在关系图生成区域显示该至少两个结点；获取用户从至少两个结点中指示的能够通过有向线段连接的两个结点，根据用户的指示在两个结点之间显示有向线段，其中有向线段用于表示两个结点之间的依赖关系。例如，当第一结点通过有向线段连接到第二结点时，表示第二结点依赖第一结点的运行结果。

本实施例中，关系图包括但不限于DAG图。

步骤302、解析关系图，生成与任务调度系统适配的配置文件。

电子设备在解析关系图时，首先按照预设的计算机语言格式，生成与关系图对应的关系图描述，由于任务调度系统无法通过计算机语言格式识格式的关系图描述识别任务之间的依赖关系，也无法直接根据计算机语言格式的关系图描述创建调度任务，因此需要将关系图描述转换成任务调度系统所能识别的配置文件。

一个具体实施例中，为了在生成配置文件时，便于查找结点信息以及结点的依赖结点，本实施例中，按照预设的计算机语言格式生成的关系图描述分为用于指示各结点的结点信息的第一部分描述和用于指示各结点的结点关系的第二部分描述。

可选地，本实施例中，预设的计算机语言格式包括但不限于JSON格式。当按照JSON格式生成关系图描述时，关系图描述具体为符合JSON格式的JSON字符串。在JSON字符串中，采用“nodes”描述关系图中的结点，“edges”描述关系图中各结点的结点关系。

其中，“nodes”部分包括各结点各自的结点信息，每个结点的结点信息包括结点标识、结点名称、输入端口号、输出端口号和/或结点在关系图生成区域中的坐标；“edges”部分包括多组结点关系，每组结点关系包括起始结点(srcNodeId)的结点标识和目标结点(dstNodeId)的结点标识，一组结点关系表示dstNodeId依赖srcNodeId。

对应到本实施例中，第一部分描述对应JSON字符串中的“nodes”部分，第二部分描述对应JSON字符串中的“edges”部分。

基于以上关系图描述的具体实现可知，将关系图转换成关系图描述本质是电子设备识别关系图的过程，基于此，如图4所示，本实施例提供以下生成关系图描述的步骤：

步骤401、按照预先设置的结点属性，识别关系图中的至少一个结点；

结点属性包括但不限于结点的结点名称、结点的形状或标识的类型等属性。

由于关系图中的有向线段通常不带有名称，而结点通常可以以对应该结点的任务作为自身的名称，因此可以通过结点名称区分结点和有向线段，从而识别关系图中的结点；或，在关系图中，结点通常并不以线段的形式表示，而是以圆形、椭圆形等形状表示，因此可以通过形状区分结点和有向线段，以识别关系图中的结点；又或，关系图中，结点的结点标识和有向线段的标识可以以不同的位数表示，如结点的结点标识以三位数字表示，而有向线段的标识以两位数表示，因此根据标识的类型区分结点和有向线段，从而识别关系图中的结点。

需要说明的是，无论通过结点名称、结点的形状或标识的类型识别结点，均是本实施例可选的实施方式，本申请对此并不做具体限定，当然现有技术中其它可以识别关系图中的结点的方式也适于本实施例。

步骤402、分别获取各结点各自的结点信息；

一种可选实施方式，关系图中的各结点携带有用于唯一标识结点的结点属性，如结点名称或结点标识等，因此可以根据结点所携带的结点属性获取结点的结点信息。

本实施例中，可以预先将各任务与电子设备进行关联，使得电子设备能够获取各任务的相关信息，因此在获取关系图中的结点属性后，根据结点属性可以获取结点对应的任务的相关信息，并将该相关信息确定为结点的结点信息。

步骤403、分别识别与各结点各自具有连接关系的有向线段；

步骤404、基于有向线段的方向，分别确定各结点各自的依赖结点；

示例性地，当识别到第一结点通过有向线段连接到第二结点时，可以确定与第一结点具有连接关系的有向线段指向第二结点，那么确定第一结点为第二结点所依赖的结点。

步骤405、按照预设的计算机语言格式，描述各结点各自的结点信息和各结点各自的依赖结点，得到关系图描述。

请参照图5，图5为本实施例示出的又一种关系图。在该关系图中，各结点携带有结点名称，分别为create_table.hql、alter_partition.hql、select.hql、insert_overwrite_tab，因此可以根据结点名称识别到关系图中的各结点。另，由于create_table.hql结点具有连接关系的有向线段所连接的结点分别为alter_partition.hql结点和select.hql结点，且有向线段的方向为从create_table.hql结点连接至alter_partition.hql结点、以及从create_table.hql结点连接至select.hql结点，因此可以确定alter_partition.hql结点和select.hql结点均依赖create_table.hql结点的运行结果，关于insert_overwrite_tab结点所依赖的结点的确定与前述的逻辑类似，此处不再展开描述。

一个具体实施方式中，基于以上关系图描述生成配置文件时，具体地，从第一部分描述中分别获取各结点各自的结点信息、以及从第二部分描述中分别获取各结点各自的依赖结点；根据各结点各自的结点信息和各结点各自的依赖结点，生成与任务调度系统适配的配置文件。

可选地，本实施例中，第二部分描述中的结点关系可以以起始结点和目标结点的相对关系表达，目标结点依赖起始结点。因此在从第二部分描述中获取结点的依赖结点时，从第二部分描述中查找目标结点为结点的目标结点关系；获取目标结点关系中的起始结点；将起始结点确定为结点的依赖结点。可以理解地，将关系图描述中第二部分描述的目标结点对应的起始结点，作为配置文件中该结点的依赖结点，配置文件为任务调度系统可识别文件。

可选地，本实施例中，为了简化任务调度的复杂度，提高调度效率，一个项目下设置一个工作流，该工作流包括上述描述中的各任务。对于Azkaban任务调度系统来说，Azkaban中工作流的命名是根据依赖关系中，末尾结点的名称来决定的，如果存在多个末尾结点，工作流的名称就无法提前判断，给任务调度的维护工作带来一定的困难。所以，本实施例基于上述关系图描述中各结点创建了末尾结点，并针对各结点和末尾结点分别生成了配置文件。

具体实施时，从各结点中确定叶子结点；创建与叶子结点具有依赖关系的末尾结点，末尾结点的依赖结点为叶子结点；获取所述末尾结点的结点信息，并根据末尾结点的结点信息和末尾结点的依赖结点，生成与末尾结点对应的配置文件；根据各结点各自的结点信息和各结点各自的依赖结点，生成与各结点各自对应的配置文件；将与末尾结点对应的配置文件和与各结点各自对应的配置文件，确定为配置文件。

应理解，创建末尾结点实际包括确定末尾结点的依赖结点以及生成末尾结点的结点信息两部分，因此末尾结点创建完成后，能够获取末尾结点的结点信息，以便基于该结点信息和末尾结点的依赖结点生成与末尾结点对应的配置文件。

Azkaban配置文件中包括类型(type)、命令(command)和依赖(dependencies)三个参数，其中type表示结点的类型，command表示结点需要执行的命令，dependencies表示结点所依赖的结点。本实施例中，“type”固定为“command”，表示该结点对应的任务为一个Shell命令任务。当确定结点的dependencies参数取值时，遍历第二部分描述中的每一组结点关系，找出目标结点为该结点的目标结点，将目标结点对应的起始结点确定为该结点对应的配置文件中dependencies参数的取值。关系图描述中的每一个“node”对应一个配置文件，“node”中的结点名称即为配置文件名。

请参照图6，图6为本实施例示出的表示结点关系的示意图。该图中包括三组结点关系，分别为edge1、edge2和edge3，其中在图中的两个虚框中，左侧虚框中的结点为起始结点(srcNodeId)，右侧虚框中的结点为目标结点(dstNodeId)。当确定结点A的配置文件中dependencies参数的取值时，遍历“dstNodeId”为A的所有“edge”，找到3个结点的“srcNodeId”为B、C、D，因此确定结点A的配置文件中dependencies参数的取值为“B，C，D”。

本实施例中，从各结点中确定叶子结点时，由于直接获取非叶子结点的代价比获取叶子结点的代价要低，计算复杂度小，所以确定叶子结点时，先获取所有结点中的非叶子结点，然后从所有结点中去掉非叶子结点，剩下的结点就是叶子结点。

从各结点中确定叶子结点时，可选地，从第二部分描述中查找目标结点不为空的结点关系；从目标结点不为空的结点关系中获取起始结点；将起始结点作为非叶子结点。

其中，目标结点不为空表示在该组结点关系中，目标结点不具有结点标识，即关系图中实际不存在该目标结点。

请参照图7，图7为本实施例示出的表示结点关系的又一示意图。该图中包括四组结点关系，分别为edge1、edge2、edge3和edge4，其中在图中的两个虚框中，左侧虚框中的结点为起始结点(srcNodeId)，右侧虚框中的结点为目标结点(dstNodeId)。确定图7中的叶子结点时，遍历所有的结点关系，如果dstNodeId不为空，则该结点关系中的srcNodeId就为非叶子结点，那么经过遍历可以确定图7中A结点、B结点和C结点均为非叶子结点。

步骤303、当将配置文件上传至任务调度系统后，从可视化配置界面的调度信息配置区域，获取各任务的调度信息，调度信息包括各任务所属项目的执行时间和告警信息。

其中，告警信息包括但不限于各任务在执行时各自的持续时长、告警的通知人和/或是否电话告警等信息。

可选地，在本申请的其它实施例中，调度信息还可以包括项目描述、数据依赖失败重试次数和间隔执行时长、单脚本重跑的次数和间隔时长等信息。

其中，项目描述可以为项目的名称；关于数据依赖失败重试次数和间隔执行时长的说明：脚本中设置“任务依赖”后，若依赖的表/分区数据量为0，任务会自动失败，设置重试机制，可避免依赖的数据延迟后任务直接失败，等待依赖的数据就绪后继续运行；关于单脚本重跑的次数和间隔时长等信息的说明：若单个脚本失败，只重新执行该脚本，已经执行成功的脚本不会重新执行。

步骤304、向任务调度系统发送调度信息，以使得任务调度系统基于配置文件和调度信息执行对各任务的任务调度。

任务调度系统提供基于Restful的API接口用于与外界进行交互，因此可以通过API接口向任务调度系统发送调度信息。

本申请实施例提供的技术方案，通过可视化配置界面的关系图编辑区域获取用于反映各任务之间的依赖关系的关系图，并解析关系图，生成任务调度系统适配的配置文件，在配置文件上传至任务调度系统后，通过可视化配置界面的调度信息配置区域，获取各任务的调度信息，并向任务调度系统发送调度信息，以使得任务调度系统基于配置文件和调度信息执行对各任务的任务调度。由上可见，本申请实施例通过可视化配置界面的关系图编辑区域和调度信息配置区域实现了在一次配置过程中对调度信息和用于解析得到配置文件的依赖关系的配置，因此配置过程简单，以此大大提高了用户发布调度任务的效率，缩短了离线数据开发的过程。

另外，由于通过统一的可视化配置界面对多个任务进行调度信息配置，减少了Azkaban上多个页面来回切换和复杂的配置操作。

还有，由于可以在可视化配置界面上的关系图编辑区域配置反映各任务依赖关系的关系图，并基于关系图解析得到配置文件，因此可以避免用户手动编写多个配置文件的步骤，大大减少用户编排任务的时间开销，降低甚至减免任务编排的试错次数。

最后，本方案通过关联在线开发任务，可以满足用户开发完成即可发布的需求，提供了开发、发布一站式的工作体验。

基于同一构思，本申请实施例中提供了一种任务调度装置，该装置的具体实施可参见方法实施例部分的描述，重复之处不再赘述，如图8所示，该装置主要包括：

第一获取单元801，用于从可视化配置界面的关系图编辑区域，获取用于反映各任务之间的依赖关系的关系图；

生成单元802，用于解析关系图，生成与任务调度系统适配的配置文件；

第二获取单元803，用于当将配置文件上传至任务调度系统后，从可视化配置界面的调度信息配置区域，获取各任务的调度信息，调度信息包括各任务所属项目的执行时间和告警信息；

调度单元804，用于向任务调度系统发送调度信息，以使得任务调度系统基于配置文件和调度信息执行对各任务的任务调度。

在本申请其它实施例中，生成单元802具体用于：

按照预设的计算机语言格式，生成与关系图对应的关系图描述，关系图描述包括用于指示各结点的结点信息的第一部分描述和用于指示各结点的结点关系的第二部分描述，任意一个任务在关系图中具有唯一对应的结点；

从第一部分描述中分别获取各结点各自的结点信息、以及从第二部分描述中分别获取各结点各自的依赖结点；

根据各结点各自的结点信息和各结点各自的依赖结点，生成与任务调度系统适配的配置文件。

在本申请其它实施例中，生成单元802具体用于：

按照预先设置的结点属性，识别关系图中的至少一个结点；

分别获取各结点各自的结点信息；

分别识别与各结点各自具有连接关系的有向线段；

基于有向线段的方向，分别确定各结点各自的依赖结点；

按照预设的计算机语言格式，描述各结点各自的结点信息和各结点各自的依赖结点，得到关系图描述。

在本申请其它实施例中，生成单元802具体用于：

对于任意一个结点，从第二部分描述中查找目标结点为结点的目标结点关系；

获取目标结点关系中的起始结点；

将起始结点确定为结点的依赖结点。

在本申请其它实施例中，生成单元802具体用于：

从各结点中确定叶子结点；

创建与叶子结点具有依赖关系的末尾结点，末尾结点的依赖结点为叶子结点；

根据末尾结点的依赖结点，生成与末尾结点对应的第一类配置文件；以及根据各结点各自的结点信息和各结点各自的依赖结点，生成第二类配置文件；

将第一类配置文件和第二类配置文件，确定为配置文件。

在本申请其它实施例中，生成单元802具体用于：

根据各结点各自的依赖结点，从各结点中确定非叶子结点；

将各结点中去除非叶子结点的结点确定为叶子结点。

在本申请其它实施例中，生成单元802具体用于：

从第二部分描述中查找目标结点不为空的结点关系；

从目标结点不为空的结点关系中获取起始结点；

将起始结点作为非叶子结点。

基于同一构思，本申请实施例中还提供了一种电子设备，如图9所示，该电子设备主要包括：处理器901、存储器902和通信总线903，其中，处理器901和存储器902通过通信总线903完成相互间的通信。其中，存储器902中存储有可被处理器901执行的程序，处理器901执行存储器902中存储的程序，实现如下步骤：

从可视化配置界面的关系图编辑区域，获取用于反映各任务之间的依赖关系的关系图；

解析关系图，生成与任务调度系统适配的配置文件；

当将配置文件上传至任务调度系统后，从可视化配置界面的调度信息配置区域，获取各任务的调度信息，调度信息包括各任务所属项目的执行时间和告警信息；

向任务调度系统发送调度信息，以使得任务调度系统基于配置文件和调度信息执行对各任务的任务调度。

上述电子设备中提到的通信总线903可以是外设部件互连标准(PeripheralComponent Interconnect，简称PCI)总线或扩展工业标准结构(Extended IndustryStandard Architecture，简称EISA)总线等。该通信总线903可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器902可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器901的存储装置。

上述的处理器901可以是通用处理器，包括中央处理器(Central ProcessingUnit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任务调度方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。该计算机可以时通用计算机、专用计算机、计算机网络或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、微波等)方式向另外一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带等)、光介质(例如DVD)或者半导体介质(例如固态硬盘)等。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。