CN114756356A - 任务处理方法、工作节点设备、主节点设备及存储介质 - Google Patents

Abstract

本申请提供一种任务处理方法、工作节点设备、主节点设备及存储介质，涉及计算机技术领域。该任务处理方法包括：首先，从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数；并根据所述空闲线程数，确定待执行的任务数量。接着，向主节点发送任务请求消息，并接收所述主节点返回的任务请求结果，根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务。实现了基于拉模式的任务处理方法，即工作节点可以实时根据自己的空闲线程数（即处理任务的能力）向主节点请求相应的任务数量个任务来执行，从而避免任务在工作节点中排队而导致优先级高的任务得不到及时执行。

Description

任务处理方法、工作节点设备、主节点设备及存储介质

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种任务处理方法、工作节点设备、主节点设备及存储介质。

背景技术

随着目前计算机技术的不断发展，需要通过计算机技术处理的任务量不断增多，这对任务调度系统的任务处理能力提出了更高的要求。

目前的任务调度系统的任务处理中，通过主节点和工作节点进行任务分配时，主节点将待执行的任务放入本地优先级队列，可以保证优先级高的任务优先被发送到工作节点，由于工作节点是采用线程池执行任务的，所以当工作节点的线程池中的线程被全部执行调度任务时，接收到的新的任务会被放入线程池队列排队；此时，若优先发送的任务被发送到工作节点时，可能由于工作节点没有空闲线程处理任务而导致接收的新任务等待，而后面发送的任务发送到的其他工作节点由于有空闲线程调度任务会被立即执行，从而达不到任务优先级的效果。

发明内容

本发明的目的在于，针对上述现有技术中的不足，提供一种任务处理方法、工作节点设备、主节点设备及存储介质，以便解决任务调度系统中绝对优先级的问题。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请实施例提供了一种任务处理方法，所述方法应用于任务调度系统中的任一工作节点，所述方法包括：

从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数；

根据所述空闲线程数，确定待执行的任务数量；

向主节点发送任务请求消息，所述任务请求消息包括所述任务数量；所述任务请求消息用于使得所述主节点从预设的任务优先级列表中选择所述任务数量个的目标任务；

接收所述主节点返回的任务请求结果，所述任务请求结果包括：所述目标任务的信息；

根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务；

所述根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务，包括：

根据所述任务请求结果，对所述目标任务中的各任务进行封装；

提交封装后的所述各任务到所述执行线程池中的所述空闲线程，以采用所述任务数量个的所述空闲线程分别执行所述各任务。

可选的，所述从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数，包括：

采用预先开启的轮询线程，扫描所述执行线程池，得到所述执行线程池中的活跃线程数量；

根据所述执行线程池中的总线程数量和所述活跃线程数量，计算所述空闲线程数。

可选的，所述方法还包括：

若所述活跃线程数量等于所述总线程数量，则确定所述执行线程池中不存在空闲线程，并休眠第一预设时长。

可选的，所述方法还包括：

若在发送所述任务请求消息之后的第二预设时长内，未接收到所述主节点返回的任务请求结果，则重新发送所述任务请求消息。

可选的，所述方法还包括：

在所述各任务提交至所述执行线程池中的所述空闲线程之后，向所述主节点发送任务执行应答，所述任务执行应答用于使得所述主节点更新所述任务优先级列表。

可选的，所述方法还包括:

在所述各任务提交至所述执行线程池中的所述空闲线程之后，控制所述轮询线程休眠第三预设时长后，重新确定所述空闲线程数。

第二方面，本申请实施例还提供了一种任务处理方法，所述方法应用于任务调度系统中的任一主节点，所述方法包括：

接收工作节点发送的任务请求消息，所述任务请求消息包括：待执行的任务数量，所述任务数量为所述工作节点从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数，并根据所述空闲线程数所确定的任务数量；

从预设的任务优先级列表中选择所述任务数量个的目标任务；

向所述工作节点返回任务请求结果，所述任务请求结果包括：所述目标任务的信息，所述任务请求结果用于使得所述工作节点根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务；其中，所述任务请求结果用于使得所述工作节点对所述目标任务中的各任务进行封装，并提交封装后的所述各任务到执行线程池的空闲线程中以分别执行所述各任务。

可选的，所述任务请求消息中还包括：任务分组标识；

所述从预设的任务优先级列表中选择所述任务数量个的目标任务，包括：

从所述任务优先级列表中所述任务分组标识对应的任务中，选择所述任务数量个的所述目标任务。

可选的，所述方法还包括：

接收所述工作节点在所述各任务提交至执行线程池中的空闲线程之后发送的任务执行应答；

根据所述任务执行应答，更新所述任务优先级列表。

第三方面，本申请实施例还提供了一种工作节点设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的程序指令，当工作节点设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述程序指令，以执行时执行如第一方面任一所述的任务处理方法的步骤。

第四方面，本申请实施例还提供了一种主节点设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的程序指令，当主节点设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述程序指令，以执行时执行如第二方面任一所述的任务处理方法的步骤。

第五方面，本申请实施例还提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面任一所述的任务处理方法的步骤或执行如第二方面任一所述的任务处理方法的步骤。

本申请的有益效果是：本申请实施例提供一种任务处理方法，所述方法应用于任务调度系统中的任一工作节点。首先，从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数；并根据所述空闲线程数，确定待执行的任务数量。接着，向主节点发送任务请求消息，并接收所述主节点返回的任务请求结果，根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务。相较于现有技术中采用推模式的任务处理方法（即主节点先将任务放入优先级队列，然后将调度任务推送给工作节点），虽然保证了优先级高的任务会优先推送到工作节点，但是主节点不能感知工作节点的实际负载情况，当工作节点的执行线程池满负荷时会导致任务积压而得不到及时处理，特别是不能保证优先级高的任务先执行。本申请实现的是基于拉模式的任务处理方法，即工作节点可以实时根据自己的空闲线程数（即处理任务的能力）向主节点请求相应的任务数量个任务来执行，从而避免任务在工作节点中排队而导致优先级高的任务得不到及时执行，使得优先级高的任务会比优先级低的任务优先执行；任务优先级一样的情况下，优先提交的任务优先执行。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请一实施例提供的任务调度系统架构示意图；

图2为本申请一实施例提供的一种任务处理方法的流程图；

图3为本申请又一实施例提供的一种任务处理方法的流程图；

图4为本申请另一实施例提供的一种任务处理方法的流程图；

图5为本申请再一实施例提供的一种任务处理方法的流程图；

图6为本申请一实施例提供的一种任务处理装置的示意图；

图7为本申请另一实施例提供的一种任务处理装置的示意图；

图8为本申请实施例提供的一种工作节点设备的示意图；

图9为本申请实施例提供的一种主节点设备的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。

在本申请中，除非另有明确的规定和限定，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包含至少一个特征。在本发明中的描述中，“多个”的含义是至少两个，例如两个、三个，除非另有明确具体的限定。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

现有的任务处理方案中基于工作节点（Worker）和主节点（Master）进行任务处理时（例如通过Apache Dolphin Scheduler实现），主要通过如下方式实现：首先，主节点启动后调起待执行的任务，并将待执行的任务放入本地优先级序列中；扫描线程通过对本地优先级序列进行扫描，将优先级高的任务通过负载均衡算法发送到工作节点中；工作节点在接收到任务执行命令后，若有空闲的线程，则执行接收到的任务；若没有空闲线程，则将接收到的任务加入到等待队列当中等待执行。

通过对现有的任务处理方案进行分析可知，主节点将待执行的任务放入本地优先级序列中，可以保证优先级高的任务优先发送到工作节点中（需要说明，在网络延迟等特殊的场景中，可能会出现异常情况，但是在这些异常情况中，其遵循的高优先级任务优先发送的原则是不变的）。由于工作节点采用线程池进行任务执行，当工作节点的线程池中所有的线程都在执行线程任务时，接收到的新的任务会放入线程池队列中排队，因此，优先被主节点发送的任务可能会因为工作节点中没有空闲线程而进入线程池队列中等待。此时，如果在后发送的任务在发送到工作节点时，工作节点中存在空闲线程，那么在后发送的任务会被立即执行，而在线程池队列中等待的优先级高的任务可能继续由于没有空闲线程等待。由此，现有的任务处理方案在任务执行上实现不了优先级高的任务优先处理的效果。

为了进一步说明现有的任务处理方案中存在的问题，下面通过示例进行说明：例如在主节点中存在三个任务：优先级最低的任务C、优先级中等的任务B、优先级最高的任务A，在主节点向工作节点发送任务时，根据三个任务的优先级，其发送顺序为：任务A-任务B-任务C。在实际实现中存在下面这种情况：

主节点最先向工作节点发送的任务A由于工作节点中没有空闲线程，被放入线程池队列中；

主节点在任务A之后向工作节点发送的任务B由于工作节点中没有空闲线程，被放入线程池队列中；

主节点在任务B之后向工作节点发送的任务C由于工作节点中有空闲线程，被立即执行。

之后，工作节点中存在空闲线程，执行线程池队列中的任务A、任务B。也就是说，在这种情况中，优先级最高的任务A虽然最先被主节点发送到工作节点，但在执行中，是在优先级最低的任务C之后执行的。

针对现有技术方案只能够保证优先级高的任务被优先发送到工作节点，但不能保证优先级高的任务被优先执行，即只是实现了相对的优先级，没有解决绝对优先级问题。本申请实施例提供了多种可能的实现方式，以实现任务处理中的任务按照绝对的优先级进行处理。如下结合附图通过多个示例进行解释说明。

本申请的任务处理方法由至少任务调度系统中至少一个工作节点和至少一个主节点配合实现。图1为本申请一实施例提供的任务调度系统架构示意图，如图1所示，任务调度系统中包括：任务系统10、至少一个主节点300、至少一个工作节点100。其中，任务系统与主节点之间通信连接，主节点与工作节点之间通信连接。

需要说明的是，任务系统10用于直接或者间接创建或者修改任务，在一种可能的实现方式中，任务系统10可以基于APIService实现，从而为主节点的任务调起提供基础。在一种具体的实现方式中，用户例如可以通过任务系统10提供的人机交互终端通过页面配置等形式实现任务的创建或者修改，本申请对具体的基于任务系统的任务创建、修改的方式不做限定。

此外，主节点300用于调起任务，并将任务发送给工作节点100。需要说明的是，本申请对主节点的数量不做限定，用户可以根据实际使用情况选择设定主节点的数量；若选择使用多个主节点，则主节点之间例如可以采用分布式部署等部署形式，本申请对此也不做限定。除此之外，主节点可以是基于软件算法实现的节点，也可以是基于硬件设备实现的硬件节点，本申请对此不做限定。若该主节点是基于硬件设备（工作节点设备）实现的，在本申请中，多个主节点可以位于同一主节点设备，也可以位于不同的多个主节点设备中，本申请对此不做限定。其中，主节点设备可以集成于终端设备或者终端设备的芯片，该终端可以是具备数据处理功能的计算设备、服务器等。

在一种可能的实现方式中，若使用多个主节点，每个工作节点可以随机或者根据预设规则从主节点列表中选择一个主节点，并向选择的主节点发送任务请求消息；其中，预设规则例如可以为：为每个工作节点设置指定多个主节点作为目标主节点，从而在发送任务请求消息时，工作节点向随机选择的任一目标主节点发送；或者，预设规则例如可以为：工作节点向处于活跃状态的任一主节点发送任务请求消息；其中，活跃状态的主节点指的是处于工作状态，且通信正常的主节点。

每个主节点在启动时，可将自己的信息注册到预设的第三方软件。每个工作节点可通过订阅第三方软件上主节点的信息，实时感知主节点的状态。当多个主节点中一个或多个主节点发生异常情况（例如宕机、通讯中断等）时，第三方软件会将存在异常的主节点剔除。当工作节点从第三方软件感知到主节点已下线，便可将该主节点从主节点列表中剔除。其中，上述第三方软件可以为预设的协调服务软件如分布式应用程序协调服务软件，或者中间件。

还需要说明的是，工作节点30用于任务执行，和/或任务结果反馈。需要说明的是，本申请对工作节点的数量不做限定，用户可以根据实际使用情况选择设定工作节点的数量；若选择使用多个工作节点，则工作节点之间例如可以采用分布式部署等部署形式，本申请对此也不做限定。除此之外，工作节点可以是基于软件算法实现的节点，也可以是基于硬件设备实现的硬件节点，本申请对此不做限定。若该工作节点是基于硬件设备（工作节点设备）实现的，在本申请中，多个工作节点可以位于同一工作节点设备，也可以位于不同的多个工作节点设备中，本申请对此不做限定。其中，工作节点设备可以集成于终端设备或者终端设备的芯片，该终端可以是具备数据处理功能的计算设备、服务器等。此外，工作节点与主节点可以集成于相同的终端设备，也可以集成于不同的终端设备，用户可以根据实际使用需要进行选择。

在图1的基础上，任务调度系统中还可能包括任务插件，该任务插件用于执行具体的任务，并对执行后的任务进行反馈。例如任务插件可能为Datax、Shell、Hive等，本申请对此不做限定；此外，对执行后的任务进行反馈的反馈结果例如可以为：执行失败、执行成功等，该反馈结果可以通过工作结果发送至主节点，也可以直接发送给主节点，本申请对此不做限定。

图2为本申请一实施例提供的一种任务处理方法的流程图，该方法可由任务调度系统中的工作节点和主节点实现，该电子设备例如可以为终端设备，也可以为服务器等。如图2所示，该方法包括：

应用于任务调度系统中的任一工作节点100：

步骤110：从工作节点对应的执行线程池中确定空闲线程的空闲线程数。

需要说明的是，工作节点在启动时会创建执行线程池，执行线程池是一种多线程任务处理的形式。在本申请中，工作节点创建的线程池的具体大小可以根据用户需要或者预设值进行设定，本申请对此不足限定。

在进行任务处理时，工作节点首先确定当前工作节点对应的执行线程池的空闲线程数。在一种可能的实现方式中，工作节点可以通过监听、中断等方式获取执行线程池中的空闲线程数，本申请对空闲线程数的具体获取方式不做限定。

步骤120：根据空闲线程数，确定待执行的任务数量。

需要说明的是，根据空闲线程数确定待执行的任务数量时，该待执行的任务数量表示的是当前工作节点可以执行的任务数量，此数量与主节点中存在的任务的数量无关。

在一种可能的实现方式中，每个空闲线程都可以用来执行一个待执行的任务，此时，空闲线程数大于等于待执行的任务数量相等，即在这种情况下，只要待执行的任务数量小于等于空闲线程数，即可保证后续取得任务数量对应的任务后工作节点的正常执行。

在另一种可能的实现方式中，每个空闲线程可以用于执行多个待执行的任务，或者，一个待执行的任务可能需要多个空闲线程配合执行，此时，需要对空闲线程数根据具体的比例关系及实际情况进行计算处理后，确定待执行的任务数量。

上述仅为示例说明，在实际实现中，通过空闲线程数确定待执行的任务数量还可能存在其他形式，本申请对此不做限定。

步骤130：向主节点发送任务请求消息，任务请求消息包括任务数量；任务请求消息用于使得主节点从预设的任务优先级列表中选择任务数量个的目标任务。

将任务数量通过任务请求消息发送给主节点，主节点可以根据任务请求消息从任务优先级列表中选择任务数量个目标任务，具体主节点的任务处理方法在步骤310-步骤330中进行说明。

在一种可能的实现方式中，任务请求消息可以由一下参数组装而成：任务数量、自增序列号等（自增序号可以用于进行计数、校验等）。上述仅为示例说明，在实际实现中，任务请求消息还可以包括其他参数，例如加密相关参数等，本申请对此不做限定。

在另一种可能的实现方式中，若使用多个主节点，工作节点向主节点发送任务请求消息之前，获取各个主节点的状态，若存在非活跃状态的主节点，则将该主节点从待选主节点中去除，在活跃状态主节点中随机或者根据预设规则选择一个主节点发送任务请求消息。

任务调度系统中的任一主节点300在接收到工作节点100发送的任务请求消息之后，应用于任务调度系统中的任一主节点300：

步骤310：接收工作节点发送的任务请求消息，任务请求消息包括：待执行的任务数量，任务数量为工作节点从工作节点对应的执行线程池中确定空闲线程的空闲线程数，并根据空闲线程数所确定的任务数量。

主节点接收工作节点发送的任务请求消息，该任务请求消息的具体生成方式参考上述步骤120-步骤130，本申请在此不再赘述。

在一种可能的实现方式中，主节点在启动后即可接收工作节点发送的任务请求消息。

步骤320：从预设的任务优先级列表中选择任务数量个的目标任务。

需要说明的是，主节点在接收工作节点发送的任务请求消息后，根据任务请求消息指示的任务数量，从预设的任务优先级列表中选择任务数量个数的任务为目标任务。

在一种可能的实现方式中，主节点在根据任务请求消息指示的任务数量，从预设的任务优先级列表中选择任务数量个数的任务时，可以根据预设的任务优先级列表中任务的优先级，将预设的任务优先级列表中优先级高任务数量个任务选择为目标任务。此外，主节点也可以根据预设的任务优先级列表中任务的优先级以及创建时间进行综合排序，将预设的任务优先级列表中优先级高、创建时间早的任务数量个任务选择为目标任务。上述仅为示例说明，在进行目标任务选择时，还可以有其他方式，有其他的选择条件，本申请对此不做限定。

在一种具体的实现方式中，主节点根据任务请求消息的指示，可以通过以下查询语句选择目标任务：

select * from task_priority_queue where state=0 order by prioritydesc,create_time asc limit n。此查询语句表示从任务优先级列表（task_priority_queue），根据优先级（priority desc）和创建时间（create_time）排序后，选择等待执行（或称等待消费，state=0）的任务数量（limit n）个任务。

上述仅为示例说明，作为一种主节点在任务优先级列表中的查询方式，在实际实现中，还可以有其他方式，本申请对此不做限定。

在另一种可能的实现方式中，预设的任务优先级列表可以通过如下方式生成：主节点在启动之后，调起待执行的任务，并将待执行的任务插入任务优先级列表中。

需要说明的是，主节点可以通过如下方式调起待执行的任务：参考图1，预先在主节点中设置任务调起触发条件，当主节点中的至少一个任务调起触发条件被触发时，主节点从任务系统中调起该任务调起触发条件对应的任务（即待执行任务）。其中，预先设置的任务调起触发条件例如可以为：时间条件（例如每间隔一定时间从任务系统中调起一定数目的任务）、事件条件（即在满足预设事件后触发，该事件例如可以为：完成某待执行任务的前置任务、执行失败的任务数量达到预设阈值、至少一个主节点或者至少一个工作节点出现异常状态等）。上述仅为示例说明，本申请对主节点调起待执行任务的具体方式不做限定，用户可以根据实际使用需要进行设定。

在一种具体的实现方式中，任务优先级列表例如可以为基于mysql的task_priority_queue表，在此任务优先级列表中，每个任务可以包括以下一项或多项具体字段信息，表1为本申请一实施例提供的一种任务优先级列表字段说明，见表1：

表1 任务优先级列表字段说明

字段	类型	注释
			id	long	主键
state	tinyint	任务状态 0、等待执行，1、已执行
			p riority	tinyint	优先级
c reate _time	datetime	创建时间（即入库时间）
			x xx	xxx	其他扩展字段

在另一种具体的实现方式中，每个待执行任务的优先级可以在该任务创建时设置（即主节点接收的为具有优先级的待执行任务），也可以在该任务进入主节点时由主节点进行设定，本申请对此不做限定。此外，本申请的优先级的具体设置方式不做限定，根据实际需要可以设定多个优先级（例如五级优先级、七级优先级等），只要该优先级能够在主节点中表征每个待执行任务的执行优先级即可。一般地，优先级高的待执行任务会优先有主节点发送给工作节点执行。

还需要说明的是，主节点选择的目标任务的数量小于等于任务数量，根据主节点的任务优先级列表中具体任务量的限制，主节点能够选择的目标任务可能不能完全满足工作节点需要的任务数量，因此可能出现两者数量不匹配的情况，本申请对主节点选择的目标任务的具体数量不做限定，只要其小于等于任务数量即可。

可选的，在上述图2的基础上，本申请还提供一种任务处理方法的可能实现方式，应用于任务调度系统中的任一主节点300，任务请求消息中还包括：任务分组标识；步骤320：从预设的任务优先级列表中选择任务数量个的目标任务，包括：

步骤321：从任务优先级列表中任务分组标识对应的任务中，选择任务数量个的目标任务。

在一种可能的实现方式中，为了进一步加快工作节点的任务处理进度，可以对任务进行分组，同时对每个工作组件处理的任务类型进行限定，由此在工作节点向主节点发送任务请求消息时，在任务请求消息中携带有任务分组标识。主节点在接收到包含任务分组表示的任务请求消息后，除了按照上述方法进行筛选之外，还需要增加一个任务分组的限定条件，即从任务优先级列表中的任务分组标识对应的任务中，选择任务数量个的目标任务。

步骤330：向工作节点返回任务请求结果，任务请求结果包括：目标任务的信息，任务请求结果用于使得工作节点根据目标任务中各任务的信息，采用任务数量个的空闲线程分别执行各任务。

在确定目标任务后向工作节点返回任务请求结果，任务请求结果中包含了目标任务的信息。需要说明的是，任务请求结果中包含的目标任务的信息可以是指示目标任务的信息（例如任务ID等），也可以是目标任务本身（例如封装任务结果集等）。若任务请求结果包含的是指示目标任务的信息，工作节点接收到任务请求结果之后，可以根据该指示目标任务的信息从相关的任务数据库或者文件中调取目标任务相关的信息并执行；若任务请求结果包含的是目标任务本身，则工作节点在接收到任务请求结果之后，可以直接根据任务请求结果进行后续的任务执行。

还需要说明的是，受目标任务数量的影响，在具体实现中，工作节点可能采取小于等于任务数量个空闲线程用于进行目标任务的执行，本申请对于执行任务时具体采取的空闲线程数量不做限定。

主节点300返回任务请求结果之后，任务调度系统中的该任务请求结果对应的工作节点100：

步骤140：接收主节点返回的任务请求结果，任务请求结果包括：目标任务的信息。

工作节点接收主节点返回的任务请求结果，从而获取目标任务的信息。

在一种可能的实现方式中，任务请求结果中还包括任务请求消息中的自增序列号，由此，工作节点与主节点之间可以通过自增序号进行校验等，确定双方通信的正确性。

上述仅为示例说明，在实际实现中，任务请求结果中还可以包括其他信息，以完成对目标任务的调取、信息校验、加密等，本申请对此不做限定。

步骤150：根据目标任务中各任务的信息，采用任务数量个的空闲线程分别执行各任务。

工作节点根据目标任务中的各个任务的信息，采用目标任务对应数量个空闲线程分别执行各个任务。

在一种可能的实现方式中，工作节点在接收到任务请求结果后，对任务请求结果进行解析，并根据解析结果的目标任务中各任务的信息对目标任务中各任务进行封装，将封装后的任务提交给执行线程池中的空闲线程，以采用任务数量个空闲线程分别执行各任务。

综上，本申请实施例提供一种任务处理方法，方法应用于任务调度系统中的任一工作节点。首先，从工作节点对应的执行线程池中确定空闲线程的空闲线程数；并根据空闲线程数，确定待执行的任务数量。接着，向主节点发送任务请求消息，并接收主节点返回的任务请求结果，根据目标任务中各任务的信息，采用任务数量个的空闲线程分别执行各任务。相较于现有技术中采用推模式的任务处理方法（即主节点先将任务放入优先级队列，然后将调度任务推送给工作节点），虽然保证了优先级高的任务会优先推送到工作节点，但是主节点不能感知工作节点的实际负载情况，当工作节点的执行线程池满负荷时会导致任务积压而得不到及时处理，特别是不能保证优先级高的任务先执行。本申请实现的是基于拉模式的任务处理方法，即工作节点可以实时根据自己的空闲线程数（即处理任务的能力）向主节点请求相应的任务数量个任务来执行，从而避免任务在工作节点中排队而导致优先级高的任务得不到及时执行，使得优先级高的任务会比优先级低的任务优先执行；任务优先级一样的情况下，优先提交的任务优先执行。

可选的，在上述图2的基础上，本申请还提供一种任务处理方法的可能实现方式，图3为本申请又一实施例提供的一种任务处理方法的流程图；如图3所示，应用于任务调度系统中的任一工作节点100，步骤110：从工作节点对应的执行线程池中确定空闲线程的空闲线程数，包括：

步骤111：采用预先开启的轮询线程，扫描执行线程池，得到执行线程池中的活跃线程数量。

在一种可能的实现方式中，工作节点在启动后开启轮询线程，对执行线程池进行扫描，从而获取执行线程池中活跃线程的数量。其中轮询线程可以是一个单独的线程，即该线程可以独立与工作节点的任务执行的线程之外，不受工作节点其他任务执行线程的影响。此外，轮询线程可以是定期轮询的，即在工作节点启动之后，依据预设时间间隔（例如可以设置为0.5秒、1秒等）对执行线程池进行扫描，其中，具体的时间间隔可以根据具体的使用情况进行设置，本申请对此不做限定。该预设时间间隔越短，则获取的空闲线程数越能够体现工作节点实时的空闲线程数，进而能够实时的向主节点发送任务请求消息，并获取目标任务。

在一种具体的实现方式中，可以根据ThreadPoolExecutor类的getActiveCount()方法，得到执行线程池中的活跃线程数量。上述仅为示例说明，在实际实现中，还可以有其他的活跃线程数量的获取方式，本申请对此不做限定。

步骤113：根据执行线程池中的总线程数量和活跃线程数量，计算空闲线程数。

在一种可能的实现方式中，通过步骤111得到执行线程池中的活跃线程数量后，根据执行线程池中的总线程数量和活跃线程数量即可计算得到空闲线程数，其中：

空闲线程数n=执行线程池中的总线程数量-活跃线程数量。

通过上述方法可以计算得到执行线程池中的空闲线程数，为本申请的基于拉模式的任务处理方法提供基础。

可选的，在上述图3的基础上，本申请还提供一种任务处理方法的可能实现方式，该方法还包括：

若活跃线程数量等于总线程数量，则确定执行线程池中不存在空闲线程，并休眠第一预设时长。

其中，第一预设时长可以为轮询间隔时长，即上述轮询线程的预设时间间隔。若活跃线程数量等于总线程数量，也就是说通过上述空闲线程数的计算公式计算得到的空闲线程数为0，即执行线程池中不存在空闲线程时，工作节点不能再处理更多的任务，因此不需要从主节点中请求任务；但同时，还需要对工作节点的执行线程池进行监控，从而在出现空闲进程时及时响应，因此令工作节点休眠第一预设时长，并在休眠之后重新确定执行线程池中是否存在空闲线程。

在一种具体的实现方式中，确定执行线程池中不存在空闲线程后，休眠第一预设时长；在第一预设时长结束后，重新扫描执行线程池，并判断当前执行线程池中是否存在空闲线程。重复上述步骤，直到活跃线程数量与总线程数量不相等，即执行线程池中存在空闲线程为止。

需要说明的是，本申请对第一预设时长的具体时间长度不做限定，用户可以根据实际使用需求，均衡任务执行时间、硬件/软件限制等确定此第一预设时长的具体时长；示例的，可以设置第一预设时长为1秒。

可选的，在上述图2的基础上，本申请还提供一种任务处理方法的可能实现方式，该方法还包括：

若在任务请求消息之后的第二预设时长内，未接收到主节点返回的任务请求结果，则发送任务请求消息。

其中，第二预设时长可以为任务请求结果的等待时长，即预设的结果等待时长。参考图2，在工作节点发送任务请求消息之后，若存在主节点未收到任务请求消息，或者主节点出现功能障碍等情况时，可能出现长时间不反馈任务请求结果的情况，在这种情况下，若工作节点一直等待主节点的反馈消息，会浪费大量时间和运算成本。为了解决这类问题，本申请设定了第二预设时长。

在一种可能的实现方式中，工作节点在收到主节点反馈的任务请求结果之前，不会发送新的任务请求消息，如果工作节点在发送任务请求消息之后第二预设时长之内，还未接收到主节点返回的任务请求结果，则重新向主节点发送任务请求消息。

在另一种可能的实现方式中，如果工作节点在发送任务请求消息之后第二预设时长之内，还未接收到主节点返回的任务请求结果，则重新向主节点发送任务请求消息，并开始累积重新发送任务请求消息的次数。当重新发送任务请求消息的次数大于预设次数限制时，则重新确定空闲线程数，并重新发送任务请求消息。

在又一种可能的实现方式中，如存在多个主节点，则工作节点在发送任务请求消息时，随机选择一个主节点发送，此时，若工作节点在发送任务请求消息之后第二预设时长之内，还未接收到主节点返回的任务请求结果，则重新向主节点发送任务请求消息，并累积重新发送次数。当重新发送次数大于预设次数限制时，则重新进行主节点的随机选择，并向新选择的主节点重新发送任务请求消息（新选择的主节点也可以是之前发送任务请求消息的目标主节点）。

在上述各实施方式的基础上，在任务请求消息中还包括自增序列号，工作节点在接收到任务请求结果后，将该任务请求结果（主节点在任务请求结果中包括自增序列号，任务请求结果的自增序列号的值与该任务请求结果对应的任务请求消息的自增序列号的值相同）中包括的自增序列号与工作节点最后发送的自增序列号进行对比，若任务请求结果的自增序列号与最后发送的任务请求消息的自增序列号不匹配（例如任务请求结果的自增序列号小于最后发送的任务请求消息的自增序列号），则不处理此条任务请求结果（或者丢弃该任务请求结果）。通过上述方法保证任务处理方法的稳定性。

需要说明的是，本申请对第二预设时长的具体时间长度不做限定，用户可以根据实际使用需求，均衡主节点响应速度、硬件/软件限制等确定此第二预设时长的具体时长；示例的，可以设置第二预设时长为10秒。

在一种具体的实现方式中，主节点会定时向分布式系统管理服务（zookeeper，zk）中上传心跳信息，在工作节点向主节点发送任务请求消息时，可以从上传了心跳信息的主节点中进行选择。

上述仅为示例说明，在实际实现中，还可以有其他的主节点选择形式，本申请对此不做限定。

可选的，在上述图2的基础上，本申请还提供一种任务处理方法的可能实现方式，图4为本申请另一实施例提供的一种任务处理方法的流程图；如图4所示，该方法包括：

应用于任务调度系统中的任一工作节点100：

步骤160：在各任务提交至执行线程池中的空闲线程之后，向主节点发送任务执行应答，任务执行应答用于使得主节点更新任务优先级列表。

工作节点将各任务提交至执行线程池中的空闲线程后，向主节点发送任务执行应答，通过任务执行应答，向主节点说明任务的执行情况。在一种可能的实现方式中，在任务执行应答中包括：指示任务的信息（例如任务ID等）、每个任务的执行情况（例如成功、失败等状态）。

接收到工作节点100发送的任务执行应答后，应用于任务调度系统中的任一主节点300：

步骤330：接收工作节点发送的任务执行应答。

步骤340：根据任务执行应答，更新任务优先级列表。

主节点在接收工作节点发送的任务执行应答后，根据该任务执行应答，进行任务优先级列表的更新。其中，更新任务优先级列表的方式例如可以为删除任务、修改任务完成状态值（例如在任务优先级列表中增加任务完成状态值complete字段，在任务未执行成功之前，该字段complete=0，任务执行成功后，将complete字段修改为complete=1）等，上述仅为示例说明，在实际实现中还可以有其他的更新方式，本申请对此不做限定。此外，为了后续对已完成任务的统计分析，还可以创建任务完成列表，并根据任务执行应答更改任务完成列表，例如将执行完成的任务加入任务完成列表中，本申请对此不做限定。

在一种可能的实现方式中，主节点可以根据任务执行应答中的指示任务的信息（例如任务ID等），将指示任务的信息指示的任务在任务优先级列表中进行更新（例如根据任务ID在任务优先级列表中删除任务）。

在另一种可能的实现方式中，主节点也可以根据执行应答中的指示任务的信息（例如任务ID等）、每个任务的执行情况，在任务优先级列表中将已经执行成功的任务在任务优先级列表中进行更新。

上述仅为示例说明，在实际实现中，还可以有其他的主节点的更新方式，本申请对此不做限定。

可选的，本申请还提供一种任务处理方法的可能实现方式，应用于任务调度系统中的任一主节点300，步骤320：从预设的任务优先级列表中选择任务数量个的目标任务，包括：

从预设的任务优先级列表中选择任务数量个目标任务，并更改目标任务的任务状态。

若工作节点、主节点采用分布式部署，为了避免可能存在的并发操作（主节点可能向多个工作节点发送同一任务，由此可能出现一个任务被查询多次并执行多次），主节点接收到工作节点发送的任务请求消息后，在根据任务请求消息确定目标任务时，可以对目标任务的任务状态进行更新，通过任务状态标记目标任务已经被选为目标任务（即目标任务为已消费状态），从而避免主节点对目标任务的重复选择。需要说明的是，由于采用分布式部署，上述确定目标任务的操作和更改目标任务状态的操作可以是在同一个事务中操作的，从而避免并发操作的问题。

在一种具体的实现方式中，可以通过增加分布式锁（该分布式锁例如可以由zookeeper实现），或其他类型的排他锁来避免并发操作。本申请对设置分布式锁的具体方式不做限定，在一种可能的实现方式中，增加分布式锁的方式例如可以为修改状态字段，具体来说，主节点在确定目标任务的同时更新目标任务的状态（例如可以修改目标任务的state字段，将state字段值由state=0的等待消费状态，修改为state=1的已消费状态）等。

可选的，在上述实施例的基础上，本申请还提供一种任务处理方法的可能实现方式，应用于任务调度系统中的任一工作节点100，图5为本申请再一实施例提供的一种任务处理方法的流程图；如图5所示，该方法包括：

步骤170：在各任务提交至执行线程池中的空闲线程之后，控制轮询线程休眠第三预设时长后，重新确定空闲线程数。

其中，第三预设时长等于上述第一预设时长，可以为预设轮询间隔时长，即轮询线程的预设时间间隔。工作节点将各任务提交至执行线程池中的空闲线程，控制所述轮询线程休眠第三预设时长后，重新开始步骤110的确定空闲线程数。需要说明的是，在将各任务提交至执行线程池中的空闲线程后，有可能需要进行任务结果反馈、任务结果输出等，如果立即开始进行下一次对空闲线程数的扫描以及任务承接，有可能造成工作节点的任务紊乱、或者主节点由于未及时修改任务优先级列表中各任务状态导致任务重复发送的情况，因此需要给工作节点、主节点留出一定的时间长度（即第三预设时长）进行处理，从而更稳定地进行接下来的任务处理。

需要说明的是，本申请对第三预设时长的具体时间长度不做限定，用户可以根据实际使用需求，均衡主节点的任务状态修改速度、硬件/软件限制等确定此第三预设时长的具体时长；示例的，可以设置第三预设时长为1秒。

下述对用以执行本申请所提供的任务处理装置、任务处理装置、工作节点设备、主节点设备及存储介质等进行说明，其具体的实现过程以及技术效果参见上述，下述不再赘述。

本申请实施例提供一种任务处理装置的可能实现示例，能够执行上述实施例提供的基于工作节点任务处理方法。图6为本申请一实施例提供的一种任务处理装置的示意图。如图6所示，上述任务处理装置600，包括：空闲线程确定模块61、处理模块63、发送模块65、接收模块67、执行模块69；

空闲线程确定模块61，用于从工作节点对应的执行线程池中确定空闲线程的空闲线程数；

处理模块63，用于根据空闲线程数，确定待执行的任务数量；

发送模块65，用于向主节点发送任务请求消息，任务请求消息包括任务数量；任务请求消息用于使得主节点从预设的任务优先级列表中选择任务数量个的目标任务；

接收模块67，用于接收主节点返回的任务请求结果，任务请求结果包括：目标任务的信息；

执行模块69，用于根据目标任务中各任务的信息，采用任务数量个的空闲线程分别执行各任务。

可选的，空闲线程确定模块61，用于采用预先开启的轮询线程，扫描执行线程池，得到执行线程池中的活跃线程数量；根据执行线程池中的总线程数量和活跃线程数量，计算空闲线程数。

可选的，任务处理装置600，还包括：第一等待模块，第一等待模块用于若活跃线程数量等于总线程数量，则确定执行线程池中不存在空闲线程，并休眠第一预设时长。

可选的，任务处理装置600，还包括：第二等待模块，第二等待模块用于若在发送任务请求消息之后的第二预设时长内，未接收到主节点返回的任务请求结果，则重新发送任务请求消息。

可选的，任务处理装置600，还包括：应答模块，应答模块用于在各任务提交至执行线程池中的空闲线程之后，向主节点发送任务执行应答，任务执行应答用于使得主节点更新任务优先级列表。

可选的，任务处理装置600，还包括：第三等待模块，第三等待模块用于在各任务提交至执行线程池中的空闲线程之后，控制轮询线程休眠第三预设时长后，重新确定空闲线程数。

本申请实施例提供还一种任务处理装置的可能实现示例，能够执行上述实施例提供的基于主节点的任务处理方法。图7为本申请另一实施例提供的一种任务处理装置的示意图。如图7所示，上述任务处理装置700，包括：接收模块71，选择模块73，返回模块75；

接收模块71，用于接收工作节点发送的任务请求消息，任务请求消息包括：待执行的任务数量，任务数量为工作节点从工作节点对应的执行线程池中确定空闲线程的空闲线程数，并根据空闲线程数所确定的任务数量；

选择模块73，用于从预设的任务优先级列表中选择任务数量个的目标任务；

返回模块75，用于向工作节点返回任务请求结果，任务请求结果包括：目标任务的信息，任务请求结果用于使得工作节点根据目标任务中各任务的信息，采用任务数量个的空闲线程分别执行各任务。

可选的，任务请求消息中还包括：任务分组标识；选择模块73，用于从任务优先级列表中任务分组标识对应的任务中，选择任务数量个的目标任务。

可选的，上述任务处理装置700，还包括：更新模块；

接收模块71，用于接收工作节点发送的任务执行应答；

更新模块，用于根据任务执行应答，更新任务优先级列表。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路（Application Specific Integrated Circuit，简称ASIC），或，一个或多个微处理器（digital singnal processor，简称DSP），或，一个或者多个现场可编程门阵列（Field Programmable Gate Array，简称FPGA）等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器（CentralProcessing Unit，简称CPU）或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统（system-on-a-chip，简称SOC）的形式实现。

本申请实施例提供一种工作节点设备的可能实现示例，能够执行上述基于工作节点实施例提供的任务处理方法。图8为本申请实施例提供的一种工作节点设备的示意图，该设备可以集成于终端设备或者终端设备的芯片，该终端可以是具备数据处理功能的计算设备。

该工作节点设备包括：处理器801、存储介质802和总线，存储介质存储有处理器可执行的程序指令，当工作节点设备运行时，处理器与存储介质之间通过总线通信，处理器执行程序指令，以执行时执行上述任务处理方法的步骤。具体实现方式和技术效果类似，这里不再赘述。

本申请实施例提供一种主节点设备的可能实现示例，能够执行上述基于主节点实施例提供的任务处理方法。图9为本申请实施例提供的一种主节点设备的示意图，该设备可以集成于终端设备或者终端设备的芯片，该终端可以是具备数据处理功能的计算设备。

该主节点设备包括：处理器901、存储介质902和总线，存储介质存储有处理器可执行的程序指令，当主节点设备运行时，处理器与存储介质之间通过总线通信，处理器执行程序指令，以执行时执行上述任务处理方法的步骤。具体实现方式和技术效果类似，这里不再赘述。

本申请实施例提供一种计算机可读存储介质的可能实现示例，能够执行上述基于工作节点和/或基于主节点实施例提供的任务处理方法，存储介质上存储有计算机程序，计算机程序被处理器运行时执行上述任务处理方法的步骤。

存储在一个存储介质中的计算机程序，可以包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（英文：processor）执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（英文：Read-Only Memory，简称：ROM）、随机存取存储器（英文：Random Access Memory，简称：RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（英文：processor）执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（英文：Read-Only Memory，简称：ROM）、随机存取存储器（英文：Random Access Memory，简称：RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (12)

1.一种任务处理方法，其特征在于，所述方法应用于任务调度系统中的任一工作节点，所述方法包括：

从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数；

根据所述空闲线程数，确定待执行的任务数量；

向主节点发送任务请求消息，所述任务请求消息包括所述任务数量；所述任务请求消息用于使得所述主节点从预设的任务优先级列表中选择所述任务数量个的目标任务；

接收所述主节点返回的任务请求结果，所述任务请求结果包括：所述目标任务的信息；

根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务；

所述根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务，包括：

根据所述任务请求结果，对所述目标任务中的各任务进行封装；

提交封装后的所述各任务到所述执行线程池中的所述空闲线程，以采用所述任务数量个的所述空闲线程分别执行所述各任务。

2.如权利要求1所述的方法，其特征在于，所述从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数，包括：

采用预先开启的轮询线程，扫描所述执行线程池，得到所述执行线程池中的活跃线程数量；

根据所述执行线程池中的总线程数量和所述活跃线程数量，计算所述空闲线程数。

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

若所述活跃线程数量等于所述总线程数量，则确定所述执行线程池中不存在空闲线程，并休眠第一预设时长。

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

若在发送所述任务请求消息之后的第二预设时长内，未接收到所述主节点返回的任务请求结果，则重新发送所述任务请求消息。

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

在所述各任务提交至所述执行线程池中的所述空闲线程之后，向所述主节点发送任务执行应答，所述任务执行应答用于使得所述主节点更新所述任务优先级列表。

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

在所述各任务提交至所述执行线程池中的所述空闲线程之后，控制所述轮询线程休眠第三预设时长后，重新确定所述空闲线程数。

7.一种任务处理方法，其特征在于，所述方法应用于任务调度系统中的任一主节点，所述方法包括：

接收工作节点发送的任务请求消息，所述任务请求消息包括：待执行的任务数量，所述任务数量为所述工作节点从所述工作节点对应的执行线程池中确定空闲线程的空闲线程数，并根据所述空闲线程数所确定的任务数量；

从预设的任务优先级列表中选择所述任务数量个的目标任务；

向所述工作节点返回任务请求结果，所述任务请求结果包括：所述目标任务的信息，所述任务请求结果用于使得所述工作节点根据所述目标任务中各任务的信息，采用所述任务数量个的所述空闲线程分别执行所述各任务；其中，所述任务请求结果用于使得所述工作节点对所述目标任务中的各任务进行封装，并提交封装后的所述各任务到执行线程池的空闲线程中以分别执行所述各任务。

8.如权利要求7所述的方法，其特征在于，所述任务请求消息中还包括：任务分组标识；

所述从预设的任务优先级列表中选择所述任务数量个的目标任务，包括：

从所述任务优先级列表中所述任务分组标识对应的任务中，选择所述任务数量个的所述目标任务。

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

接收所述工作节点发送的任务执行应答；

根据所述任务执行应答，更新所述任务优先级列表。

10.一种工作节点设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的程序指令，当工作节点设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述程序指令，以执行时执行如权利要求1至6任一所述的任务处理方法的步骤。

11.一种主节点设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的程序指令，当主节点设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述程序指令，以执行时执行如权利要求7至9任一所述的任务处理方法的步骤。

12.一种计算机可读存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至6任一所述的任务处理方法的步骤或执行如权利要求7至9任一所述的任务处理方法的步骤。

Images