CN107908469A - 一种任务调度方法及系统 - Google Patents

Abstract

本申请提供了一种任务调度方法及系统，包括：与服务器相连的多个执行器采用分布式应用程序协调服务互连通信；在处于正常状态的执行器中确定出主执行器、其余为从执行器；主执行器获取工作流并基于工作流在多个执行器中执行任务调度。本申请中不再由服务器来执行任务调度，而是由主执行器来执行任务调度，并且，各个执行器之间互连通信的；所以当主执行器发生故障时，可以在它正常执行器重新确定主执行器来继续执行工作流，从而达到高可用性。

Description

一种任务调度方法及系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种任务调度方法及系统。

背景技术

随着信息的发展大数据分析成为研究热点。大数据分析通常由多个任务组成且各个任务之间具有相互关系。为了便于执行器执行多个任务，通常需要对多个任务进行调度，以形成具有一定执行顺序的工作流。

参见图1，为现有技术中的任务调度系统，包括服务器和执行器。服务器用于生成工作流并用于在多个执行器之间进行任务调度。即，目前任务调度系统中，执行器的调度依赖服务器。

当服务器出现问题时便导致任务调度系统无法运行，所以，目前任务调度系统具有单点故障问题，因此任务调度系统可靠性较差。

发明内容

鉴于此，本申请提供一种任务调度方法及系统，可以解决单点故障的问题。

为了实现上述目的本申请提供了下述技术特征：

一种任务调度方法，包括：

与服务器相连的多个执行器采用分布式应用程序协调服务互连通信；

在处于正常状态的执行器中确定出主执行器、其余为从执行器；

主执行器获取工作流并基于工作流在多个执行器中执行任务调度。

可选的，多个执行器中一执行器上设有分布式应用程序协调服务的主控模块，且，该主控模块用于存储多个执行器的IP地址和端口；

则所述与服务器相连的多个执行器采用分布式应用程序协调服务互连通信，包括：

一执行器从所述主控模块获取另一执行器的IP地址和端口，并发送任务至IP地址对应的另一执行器的端口。

可选的，还包括：

利用所述主控模块监控执行器的工作状态；

在所述主执行器处于非正常状态后，重新在处于正常状态的执行器中确定主执行器、其余为从执行器；

将该主执行器的IP地址和端口通知从执行器。

可选的，还包括：

监控执行器中任务的执行状态；

在任务的执行状态为失败状态的情况下，控制该执行器重新执行该任务；

在重新执行该任务后的执行状态仍为失败状态的情况下，则更换另一执行器执行该任务。

一种任务调度系统，包括：

服务器和与服务器相连的多个执行器，且，所述多个执行器采用分布式应用程序协调服务互连通信；所述多个执行器中处于正常状态的执行器具有一主执行器、其余为从执行器；

所述主执行器，用于从所述服务器获取工作流，并基于工作流在多个执行器中进行任务调度。

可选的，在多个执行器中一执行器上设有分布式应用程序协调服务的主控模块，且，主控模块存储多个执行器的IP地址和端口；

所述主控模块，用于监控执行器的工作状态，在主执行器处于非正常状态后，重新在处于正常状态的执行器中确定主执行器、其余为从执行器，并将该主执行器的IP地址和端口通知从执行器。

可选的，执行器，用于监控任务的执行状态，在任务的执行状态为失败状态的情况下重新执行该任务；重新执行该任务后的执行状态仍为失败状态，则发送通知消息至所述主执行器，以使主执行器更换另一执行器执行该任务。

可选的，所述多个执行器包括多个执行器群组；则所述主执行器基于工作流在多个执行器中进行任务调度，具体用于确定工作流中的当前任务以及当前任务的详情信息；其中，所述详情信息包括当前任务适用的群组标识；确定与详情信息中群组标识对应的执行器群组；发送所述当前任务至所述执行器群组中的执行器。

可选的，服务器，用于提供第一显示界面以及第二显示界面；其中，所述第二显示界面用于显示大数据分析的任务图标，在所述第一显示界面建立包含多个任务图标及其连接关系的连线图，基于所述连线图生成工作流。

可选的，所述服务器基于所述连线图生成工作流，具体包括：

确定连接线输入端的任务图标对应代码，以及连接线输出端的任务图标对应代码；在输出端的任务图标对应代码的输入集合中，添加所述输入端的任务图标的代码；输入集合内任务之间为并联连接符，连接线两端任务之间为串联连接符。

通过以上技术手段，可以实现以下有益效果：

本申请中不再由服务器来执行任务调度，而是由主执行器来执行任务调度，并且，各个执行器之间互连通信的；所以当主执行器发生故障时，可以在它正常执行器重新确定主执行器来继续执行工作流，从而达到高可用性。

附图说明

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

图1a-1b为本申请实施例公开的一种任务调度系统的结构示意图；

图2为本申请实施例公开的一种任务调度方法的流程图；

图3为本申请实施例公开的一种任务调度方法的流程图；

图4a为本申请实施例公开的一种任务调度方法的流程图；

图4b为本申请实施例公开的一种任务调度显示界面示意图；

图5为本申请实施例公开的一种任务调度方法的流程图；

图6为本申请实施例公开的一种任务调度显示界面示意图；

图7为本申请实施例公开的一种任务调度方法的流程图；

图8为本申请实施例公开的一种任务调度方法的流程图；

图9为本申请实施例公开的一种任务调度方法的流程图。

具体实施方式

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

术语解释：

大规模数据分析：在大数据分析中，对于源数据规模较大的情况称为大规模数据分析。在大规模数据分析中源数据存储在多个群组中。不同群组中执行器软硬件环境和源数据的种类不尽相同。

DAG图：无回路有向图，英文解释为Directed Acyclic Graph。由于受制于某些任务必须比另一些任务较早执行的限制，必须排序为一个队列的任务集合可以由一个DAG图来呈现，其中每个顶点表示一个任务，每条边表示一种限制约束，拓扑排序算法可以用来生成一个有效的序列。

参见图1a，本申请提供了一种任务调度系统，包括服务器100和与服务器100相连多个执行器200，且，多个执行器200可以采用分布式应用程序协调服务互连通信，例如，多个执行器200采用Zookeeper方式互连通信。

参见图1b，本申请提供了一种任务调度系统，包括服务器100和与服务器100相连多个执行器200。且，多个执行器200可以采用分布式应用程序协调服务互连通信，例如，多个执行器200采用Zookeeper方式互连通信。

本实施例中多个执行器包括多个执行器群组，不同执行器群组的执行环境不同，一个执行器群组中多个执行器执行环境相同。执行环境即执行器的软硬件环境和源数据，在大规模数据分析中需要多种数据格式的数据，不同数据格式数据需要不同的执行环境。

多个执行器在正常情况下为正常工作状态，在非正常情况下为非正常状态。若处于正常状态的执行器中未有主执行器，则按照一定规则进行选主。选主规则有多种，本实施例不做限定。例如，以负载最低的执行器作为主执行器。

本申请可以在处于正常状态的执行器中可以通过选主方式确定主执行器，其余处于正常状态的执行器为从执行器。其中，主执行器用于与服务器进行通信，获取服务器的工作流，并基于工作流在从执行器中执行任务调度。

本申请在主执行器故障后，可以及时再在进行选主得到更新后的主执行器，更新后的主执行器会继续执行工作流，从而避免单点故障的问题。

下面介绍一种任务调度方法，应用于上述的任务调度系统。参见图2，具体包括以下步骤：

步骤S201：启动各个执行器并确定主执行器；

各个执行器采用Zookeeper方式互连通信，为了实现Zookeeper方式互连通信，在主执行器或从执行器上具有Zookeeper的主控模块。

在执行器启动后会向Zookeeper的主控模块的固定路径(比如/a)中注册IP地址和端口，以便执行器从主控模块上获取IP地址和端口，进行通信。

以主执行器与目标执行器进行通信为例，主执行器会在主控模块的固定路径下找到目标执行器的IP地址和端口，并发送任务至IP地址对应目标执行器的端口。

执行器在正常情况下为正常工作状态，在非正常情况下为非正常状态。若处于正常状态的执行器中未有主执行器，则按照一定规则进行选主，从而确定主执行器，其余为从执行器。

选主规则有多种，例如，以负载最低的执行器作为主执行器。本实施例不做限定。

步骤S202：服务器启动。

服务器启动后会与Zookeeper所在的主控模块进行通信，从而获取主执行器的IP地址，并与该执行器进行通信。

步骤S203：服务器确定大数据分析的工作流。

用户可登陆服务器并在构建大数据分析的多个任务，并构建大数据分析的工作流。本步骤参见图3所示的实施例，再次暂不详细描述。

服务器基于工作流生成DAG图，并将DAG图存储于数据库中。

步骤S204：服务器发送工作流至主执行器。

用户下发执行工作流指令后，服务器可以将工作流传送到主执行器。

步骤S205：主执行器基于工作流执行任务调度。

主执行器从数据库中得到工作流对应的DAG图，并确定任务执行顺序。主执行器基于DAG图进行任务分析，并根据任务的详情信息确定各个任务的执行器。当任务需要顺序执行时，可以选用与详情信息对应的从执行器执行顺序执行任务，可以理解的是，在执行任务的过程中，可以选择负载最小的执行器来执行任务。

当多个任务可以并行执行时，可以同步发送多个任务至任务对应的执行器，以便多个并行任务可以同步运行，从而节省工作流的执行时间。

可以理解的是，多个并行任务也可以发送到同一执行器。由于执行器中通常使用多线程方式来执行任务，所以可以采用多个线程来分别执行并行任务。

执行器获取任务后继续分析该任务，得到执行需要的软件以及生成执行任务的命令，并进行执行任务。

步骤S206：在主执行器处于非正常状态后，重新在处于正常状态的执行器中进行选主确定新的主执行器，并利用新的主执行器继续执行工作流。

Zookeeper的主控模块不断监控各个执行器(主执行器和从执行器)的负载和状态，在一个从执行器出现故障后，从执行器会向主控模块发送IP地址和故障指令，以便主控模块记录故障执行器，并更改其状态为非正常状态。

在主执行器出现故障后，主执行器会向主控模块发送IP地址和故障指令，以便主控模块记录故障执行器，并更改其状态为非正常状态。

当主控模块发现主执行器处于非正常状态的情况下，会在处于正常状态下从执行器中重新进行选主，并确定新的主执行器，其余处于正常状态的执行器为从执行器。

本申请中不再由服务器来执行任务调度，而是由主执行器来执行任务调度，并且，各个执行器之间互连通信的；所以当主执行器发生故障时，可以在它正常执行器重新确定主执行器来继续执行工作流，从而达到高可用性。

另外，当执行器执行一个任务执行失败后，可以重新执行任务，再次执行任务失败后可以更换执行器重新执行任务。一个任务的失败不影响其它任务，则可以继续进行其它任务，从而不会导致全部任务的失败。

在本发明服务器只起到展示和上传的作用。对任务信息的分析、分发和执行均由执行器来完成。并且，本申请增加任务重试机制，可以尽量提高任务的完成率。

在大数据分析过程中具有很多任务，首先构建本次大数据分析的多个任务。具体而言，参见图3，可以包括以下步骤：

步骤S301：接收构建任务的指令。

用户可以操作服务器并触发构建任务的指令，服务器接收构建任务指令。

步骤S302：提供一个任务详情填写界面。

服务器提供一个任务详情填写界面，其界面可以包括：任务名称、执行文件、任务类型、执行器标识、软件版本和调度规则等信息。

由于各个执行器群组的执行环境不一，为此，需要在详情信息中添加该任务所适用的群组标识。

针对每个任务，若该任务需要某个执行器的源数据的情况下，则在详情信息中添加执行器标识。若该任务可适用于执行器群组各个执行器的情况下，则无需在详情信息中添加执行器标识。

若一个任务需要特定软件版本，例如，一些任务需要1.7版本的系统来执行任务，另外一些任务需要1.8版本的系统来执行任务。此情况下，可以在详情信息中添加软件版本。

即，在大规模数据分析中，数据的存放包含多种形式且保存在多个集群，为了使不同的分析任务在不同环境和群组中进行。本申请把各个执行器所在群组和执行器上的软件路径和软件版本存放到数据库中。

并且，构建任务时，在任务的详情信息中添加任务执行时所需的群组标识、执行软件和软件版本等内容，以便服务器根据详情信息正确分配任务至对应的执行器。当然，还可以根据实际情况进行增加或删除具体信息。

步骤S303：接收填写完成指令，保存任务详情信息。

用户填写完毕后，可以触发填写完成指令，以便服务器保存任务详情信息。

步骤S304：以任务名称为任务图标并显示任务图标。

现有技术中通常采用人工手工编写执行顺序的方式生成工作流，本申请提供了另外一种方式，以便可以提高工作流的生成效率。

本实施例提供了构建多个任务组成的工作流的实现过程，应用于任务调度系统中服务器100，参见图4a，包括以下步骤：

步骤S401：提供第一显示界面以及第二显示界面。

参见图4b，本实施例中服务器提供两个显示界面，其中，第二显示界面用于显示步骤S304中创建的大数据分析的任务图标，以便用户查看。

可选的，第二显示界面可以创建任务的先后顺序显示任务图标，也可以按照指定顺序显示任务图标，在此不做限定。

本实施例中为了避免用户手动编写任务调度代码，提供第一显示界面，以便用户在第一显示界面采用任务图标拖动方式和连线方式，构建连接图(在步骤S402中进行详细介绍)。

步骤S402：在所述第一显示界面建立包含多个任务图标及其连接关系的连线图。

参见图5，本步骤具体包括：

步骤S501：响应于任务图标由所述第二显示界面至所述第一显示界面的拖动操作，并在所述第一显示界面显示任务图标。

在大数据分析的任务构建完毕后，第一显示界面显示有大数据分析的多个任务图标。用户可以拖动任务图标由第二显示界面至第一显示界面，以便在第一显示界面显示任务图标。

可选的，在第二显示界面的任务拖动至第一显示界面后，第二显示界面可以不再显示该任务图标，以便用户从第二显示界面了解剩余任务图标。

用户可以执行多次图标拖动操作，以便第一显示界面可以显示多个任务图标。

步骤S502：响应于所述第一显示界面中任务图标之间的连线操作，并在图标之间显示带方向的连接线。

用户可以根据在第一显示界面中，对任务图标进行连线操作，并在连线起始任务图标和结束任务图标之间显示连接线，其方向由起始图标指向结束图标。

步骤S503：重复执行上述拖动操作和连线操作，直到多个任务使用完毕。

服务器可以重复执行上述步骤S501和步骤S502，直到第二显示界面中的任务使用完毕，即第二显示界面的已有任务均已经在第一显示界面显示，也具有连接关系。

第一显示界面显示有多个任务图标以及多个任务图标之间的连接关系，参见图6，为连接图的一种示意图。

接着返回图4，进入步骤S403：基于所述连线图生成工作流。

在连接图上已经具有各个任务的执行顺序，本步骤需要自动基于连线图生成工作流。

参见图7，本步骤具体包括以下步骤：

步骤S701：确定连接线输入端的任务图标对应代码，以及连接线输出端的任务图标对应代码。

由于连接图上为任务图标，为了使其转变为可供服务器识别的工作流，首先，需要得知连接线输入端的任务图标对应代码，以及，连接线输出端的任务图标对应代码。

步骤S702：在输出端的任务图标对应代码的输入集合中，添加所述输入端的任务图标对应代码。

确定输出端的任务图标对应代码的输入集合，输出端的任务图标对应代码不具有输入集合，则构建一个输入集合，以用于保存输入端的任务图标对应代码。

参见图6中的连接图，连接线1和连接线2的输入端任务图标对应代码均为A，则分别在输出端的任务图标对应代码B和代码C的输入集合中添加代码A。

连接线3和连接线4的输入端的任务图标对应代码分别为B和C，输出端的任务图标对应代码为D，则代码D的输入集合包括代码B和代码C，以表示代码B和代码C任务的输出结果用于作为代码D任务的输入参数。

步骤S703：输入集合内任务之间为并联连接符，连接线两端任务之间为串联连接符，生成任务代码之间具有连接符的工作流。

代码A、代码B和代码C之间具有先后执行顺序，因此为串联执行。因此代码A与代码B之间的串联连接符，同理，代码A与代码C之间的串联连接符。A串联B，A串联C。代码A对应的任务优先执行，所以排列靠前。

代码D的输入集合代码B和代码C，由于不具有先后关系，所以可以并行执行，采用并联连接符连接。即，B并联C输出D。

至于具体的串联连接符和并联连接符，在此不再赘述。

接着返回图4a，进入步骤S404：检测工作流中是否有死循环；若是，则进入步骤S405，若否则进入步骤S406。

步骤S405：若工作流中有死循环，则显示提醒消息并指出死循环位置。

步骤S406：若工作流中无死循环，显示工作流正确无误的消息。

通过上述内容可以看出本实施例具有以下效果：

本实施例可以简单方便构建工作流，对于用户而言简单方便且较为直观。

另外，本实施例中可以在第一显示界面中更改一个或多个任务，对应的，工作流中任务对应代码则会根据第一显示界面的连接图进行适应性修改。因此本实施例中以任务为执行粒度，其粒度较为合适。

可以理解的是，在基于所述连线图生成工作流之后，还包括：在新建任务后更新工作流；或在删除任务后更新工作流。即，在生成工作流之后，用户还可以根据实际情况再修改连接图，对应的，工作流也会对应改变。

参见图8，关于所述在新建任务后更新工作流，包括：

步骤S801：新建任务并在连接图中添加所述新建任务。

步骤S802：在连接图中添加新建任务。

新建任务会显示在第二显示界面，用户可以拖动新建任务至第一显示界面，并在新建任务与已有任务图标之间建立连接线。

步骤S803：在工作流中添加新建任务对应代码。

由于连接线的添加方式不同，工作流中添加代码的方式也会不尽相同。

若新建任务位于连接线的输出端，则在工作流中添加新建任务对应代码，并在新建任务代码的输入集合中，添加连接线输入端的任务图标对应代码；

若新建任务位于连接线的输入端，则在连接线输出端的任务图标对应代码的输入集合中，添加新建任务图标的代码。

可选的，在删除任务后更新工作流之后，还包括在工作流中删除任务对应代码。

现有技术中在工作流执行过程中服务器仅仅会记录执行日志，本申请中，服务器不仅仅会记录执行日志，还会实时监测执行日志，以便及时发现异常情况和不合理情况，并发出告警消息，以便用户进行修改。

在执行任务的时候，服务器会采取实时监控的方式，并且可以监测运行日志，及时的了解该任务的执行状态。以一个进程为例，可以监控该进程的状态，例如比如进程启动，正常结束，异常结束等状态。

服务器可以将执行日志流转发到日志检测系统，例如kafka。然后使用日志检测技术(例如spark streaming)检测kafka消息并获得分析结果，分析结果反馈给服务器，服务器可以把结果记录到数据库。在分析结果有异常情况下，发送告警消息。

通过以上技术手段，可以实现以下有益效果：

本实施例中通过提供第一显示界面和第二显示界面，采用直观拖动任务图标的方式构建连接图，并基于连接图直接生成工作流。由于拖动任务图标形成连接图的方式，对于用户而言直观方便，相比于通过编码方式构建工作流而言，可以大大提高构建工作流效率并降低复杂度。

图1a中任务调度系统中多个执行器的执行环境均是一致的，所以图1a任务调度系统没有群组概念(或者说目前任务调度系统仅适用于一个群组)，无法适用于大规模数据分析中在多个群组中实现任务调度。

本申请提供了一种任务调度方法，应用于图1b所示的系统，以便适用于大规模数据分析。参见图9，具体包括以下步骤：

步骤S901：确定并展示多个执行器群组的执行环境。

在执行器群组确定后，其上源数据及其执行环境也是确定的，服务器可以向执行器群组发送获取执行环境的指令，从而获知执行器群组的执行环境。或者，在服务器上预先保存多个执行器群组的执行环境和源数据。

步骤S902：构建大数据分析的多个任务及其详情信息。

在构建大数据分析的任务的情况下，服务器展示多个执行器群组的执行环境，及，各执行器上的源数据。

接着返回图2，进入步骤S903：构建多个任务组成的工作流。

本步骤在图4所示的实施例中进行详细说明，在此不再赘述。

步骤S904：确定大数据分析工作流中的当前任务以及当前任务的详情信息；其中，所述详情信息包括当前任务适用的群组标识。

服务器在得到工作流之后，分析依赖关系形成DAG图。根据DAG图的信息找到工作流的起点进行执行任务。由于各个任务的执行流程一致，本实施例中以一个任务为例，进行说明。

基于DAG图确定待执行的当前任务标识，在预先存储任务标识与任务的对应关系中，查找并获取与当前任务标识对应的当前任务及其详情信息。

步骤S905：确定与详情信息中群组标识对应的执行器群组；

服务器在预先存储的群组标识和执行器群组中，确定与详情信息中的群组标识确定对应的执行器群组。

步骤S906：发送所述当前任务至所述执行器群组中的执行器。

本步骤具体而言，可以包括下述步骤：

可以理解的是，详情信息还可以包括当前任务的一些限制条件，例如执行器标识。服务器可以判断所述详情信息中是否包括当前任务所适用的执行器标识。

在所述详情信息中包括当前任务所适用的执行器标识的情况下，则在所述执行器群组中确定与所述执行器标识对应的执行器，并发送所述当前任务至执行器标识对应的执行器。

在所述详情信息中不包括当前任务所适用的执行器标识的情况下，在群组中随机确定一执行器，并发送所述当前任务至该执行器。

详情信息还可以包括当前任务的一些限制条件，例如执行软件的软件版本。例如一项任务通常由一款应用或者某种操作系统下运行，当详情信息中存在软件版本时，在执行器群组中确定包含软件版本的执行器，并确定执行器的负载情况。

为了实现执行器群组内各执行器的负载均衡，可以选择负载最小的执行器来执行当前任务。

通过上述实施例，可以看出本申请具有以下有益效果：

本实施例中适用于大规模数据分析，在大规模数据分析中，基于任务详情信息中的群组标识，来发送任务至相应的执行器群组中的执行器，从而可以解决现有技术中无法适用于大规模数据分析的缺陷。

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

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

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

Claims (10)

1.一种任务调度方法，其特征在于，包括：

与服务器相连的多个执行器采用分布式应用程序协调服务互连通信；

在处于正常状态的执行器中确定出主执行器、其余为从执行器；

主执行器获取工作流并基于工作流在多个执行器中执行任务调度。

2.如权利要求1所述的方法，其特征在于，多个执行器中一执行器上设有分布式应用程序协调服务的主控模块，且，该主控模块用于存储多个执行器的IP地址和端口；

则所述与服务器相连的多个执行器采用分布式应用程序协调服务互连通信，包括：

一执行器从所述主控模块获取另一执行器的IP地址和端口，并发送任务至IP地址对应的另一执行器的端口。

3.如权利要求2所述的方法，其特征在于，还包括：

利用所述主控模块监控执行器的工作状态；

在所述主执行器处于非正常状态后，重新在处于正常状态的执行器中确定主执行器、其余为从执行器；

将该主执行器的IP地址和端口通知从执行器。

4.如权利要求1所述的方法，其特征在于，还包括：

监控执行器中任务的执行状态；

在任务的执行状态为失败状态的情况下，控制该执行器重新执行该任务；

在重新执行该任务后的执行状态仍为失败状态的情况下，则更换另一执行器执行该任务。

5.一种任务调度系统，其特征在于，包括：

服务器和与服务器相连的多个执行器，且，所述多个执行器采用分布式应用程序协调服务互连通信；所述多个执行器中处于正常状态的执行器具有一主执行器、其余为从执行器；

所述主执行器，用于从所述服务器获取工作流，并基于工作流在多个执行器中进行任务调度。

6.如权利要求5所述的系统，其特征在于，在多个执行器中一执行器上设有分布式应用程序协调服务的主控模块，且，主控模块存储多个执行器的IP地址和端口；

所述主控模块，用于监控执行器的工作状态，在主执行器处于非正常状态后，重新在处于正常状态的执行器中确定主执行器、其余为从执行器，并将该主执行器的IP地址和端口通知从执行器。

7.如权利要求5所述的系统，其特征在于，

执行器，用于监控任务的执行状态，在任务的执行状态为失败状态的情况下重新执行该任务；重新执行该任务后的执行状态仍为失败状态，则发送通知消息至所述主执行器，以使主执行器更换另一执行器执行该任务。

8.如权利要求5所述的系统，其特征在于，所述多个执行器包括多个执行器群组；则所述主执行器基于工作流在多个执行器中进行任务调度，具体用于确定工作流中的当前任务以及当前任务的详情信息；其中，所述详情信息包括当前任务适用的群组标识；确定与详情信息中群组标识对应的执行器群组；发送所述当前任务至所述执行器群组中的执行器。

9.如权利要求5所述的系统，其特征在于，

服务器，用于提供第一显示界面以及第二显示界面；其中，所述第二显示界面用于显示大数据分析的任务图标，在所述第一显示界面建立包含多个任务图标及其连接关系的连线图，基于所述连线图生成工作流。

10.如权利要求9所述的系统，其特征在于，所述服务器基于所述连线图生成工作流，具体包括：

确定连接线输入端的任务图标对应代码，以及连接线输出端的任务图标对应代码；在输出端的任务图标对应代码的输入集合中，添加所述输入端的任务图标的代码；输入集合内任务之间为并联连接符，连接线两端任务之间为串联连接符。