CN112612604A - 基于Actor模型的任务调度方法、装置 - Google Patents

Abstract

本申请公开了一种基于Actor模型的任务调度方法、装置。该方法包括：在当前任务触发后，对当前任务进行初始化，并在初始化完成后，将当前任务的状态修改为待运行状态；将待运行状态以第一消息的形式发送给第一Actor；通过第一Actor根据第一消息判断当前任务是否处于已就绪状态，并在判定出当前任务处于已就绪状态，将已就绪状态以第二消息的形式发送给第二Actor；通过第二Actor根据第二消息确定执行当前任务的执行节点，并将当前任务的状态修改为已分发状态，以及将已分发状态以第三消息的形式发送给第三Actor；通过第三Actor根据第三消息将当前任务发送给执行节点，以通过执行节点执行当前任务。本申请无需借助锁便可以实现任务的调度。

Description

基于Actor模型的任务调度方法、装置

技术领域

本申请涉及视频技术领域，尤其涉及一种基于Actor模型的任务调度方法、装置。

背景技术

现有的任务调度系统在进行任务调度时，常常因为多线程或多进程并发访问某个临界资 源而陷入死锁，这时可通过对该临界资源进行加锁，来建立线程或进程之间的互斥同步机制， 以保障临界资源的完整性和一致性。单机的进程同步和线程同步有很多可用的互斥方案，比 如互斥锁、信号量和条件变量等。但这些单机下的互斥方案在多机上是无法使用的，因为分 布式系统的组件运行在不同的机器上，使得其不在统一的运行环境中。

分布式任务调度中，常常通过分布式锁解决对临界资源的互斥访问，比如Redis分布式 锁和Zookeeper分布式锁的等。

但是分布式锁的实现比较复杂，且维护比较麻烦，需要较多维护成本，且基于分布式锁 的实现方式也可能会出现抢锁的问题，不能做到状态隔离。

发明内容

有鉴于此，现提供一种基于Actor模型的任务调度方法、装置、计算机设备及计算机可 读存储介质，以解决现有的任务调度系统通过分布式锁解决临界资源的互斥访问的实现方式 仍可能会出现抢锁，及不能做到状态隔离的问题。

本申请提供了一种基于Actor模型的任务调度方法，所述Actor模型包括第一Actor、第 二Actor及第三Actor，所述方法包括：

在当前任务触发后，对所述当前任务进行初始化，并在初始化完成后，将所述当前任务 的状态修改为待运行状态；

将所述待运行状态以第一消息的形式发送给所述第一Actor；

通过所述第一Actor根据所述第一消息判断所述当前任务是否处于已就绪状态，并在判 定出所述当前任务处于已就绪状态，将所述已就绪状态以第二消息的形式发送给所述第二 Actor；

通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当 前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息的形式发送给所述第三 Actor；

通过所述第三Actor根据所述第三消息将所述当前任务发送给所述执行节点，以通过所 述执行节点执行所述当前任务。

可选地，所述Actor模型还包括第四Actor，所述通过所述第二Actor根据所述第二消 息确定执行所述当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将 所述已分发状态以第三消息的形式发送给所述第三Actor包括：

通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当 前任务的状态修改为已分发状态，以及将所述已分发状态以第四消息的方式发送给所述第四 Actor；

通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中在 当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈值， 则将所述已分发状态以第三消息的形式发送给所述第三Actor。

可选地，所述Actor模型还包括第五Actor，所述通过所述第四Actor根据所述第四消 息判断创建所述当前任务的用户所拥有的任务中在当前时刻正被执行的任务数量是否超过 第一预设阈值，若判定出未超过所述第一预设阈值，则将所述已分发状态以第三消息的形式 发送给所述第三Actor包括：

通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中在 当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈值， 将所述已分发状态以第五消息的方式发送给所述第五Actor；

通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务中在当前 时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设阈值，则将 所述已分发状态以第三消息的形式发送给所述第三Actor。

可选地，所述Actor模型还包括第六Actor，所述通过所述第五Actor根据所述第五消 息判断所述用户所在的部门所拥有的任务中在当前时刻正被执行的任务数量是否超过第二 预设阈值，若判定出未超过所述第二预设阈值，则将所述已分发状态以第三消息的形式发送 给所述第三Actor包括：

通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务中在当前 时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设阈值，则将 所述已分发状态以第六消息的形式发送给所述第六Actor；

通过所述第六Actor根据所述第六消息将所述当前任务存储至预设的队列中，并将所述 已分发状态以第三消息的形式发送给所述第三Actor。

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

通过所述第三Actor接收所述执行节点返回的所述当前任务的执行状态信息，并在所述 执行状态信息为执行失败状态时，将所述执行失败状态以第七消息的形式发送给所述第一 Actor。

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

对所述Actor模型中的所有Actor进行监控，并在监控到Actor出现故障时，调用预设 的恢复策略对出现故障的Actor进行处理，以使出现故障的Actor恢复正常。

可选地，当所述Actor模型中的Actor检测到当前待消费的消息数量大于预设数量时， 则对相同状态的消息进行压缩处理。

本申请还提供了一种基于Actor模型的任务调度装置，所述Actor模型包括第一Actor、 第二Actor及第三Actor，其特征在于，包括：

初始化模块，用于在当前任务触发后，对所述当前任务进行初始化，并在初始化完成后， 将所述当前任务的状态修改为待运行状态；

第一发送模块，用于将所述待运行状态以第一消息的形式发送给所述第一Actor；

第二发送模块，用于通过所述第一Actor根据所述第一消息判断所述当前任务是否处于 已就绪状态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第二消息的形 式发送给所述第二Actor；

第三发送模块，用于通过所述第二Actor根据所述第二消息确定执行所述当前任务的执 行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息的 形式发送给所述第三Actor；

第四发送模块，用于通过所述第三Actor根据所述第三消息将所述当前任务发送给所述 执行节点，以通过所述执行节点执行所述当前任务。

本申请还提供了一种计算机设备，所述计算机设备，包括存储器、处理器以及存储在所 述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现 上述方法的步骤。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被 处理器执行时实现上述方法的步骤。

上述技术方案的有益效果：

本申请实施例中，通过在任务触发后，对任务进行初始化，并在完成初始化后将任务状 态以消息的形式给所述第一Actor；通过所述第一Actor根据所述第一消息判断所述当前任 务是否处于已就绪状态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第 二消息的形式发送给所述第二Actor；通过所述第二Actor根据所述第二消息确定执行所述 当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态 以第三消息的形式发送给所述第三Actor；通过所述第三Actor根据所述第三消息将所述当 前任务发送给所述执行节点，以通过所述执行节点执行所述当前任务。本实施例中，由于各 个Actor之间是通过消息的方式来进行通信的，而通过消息通信的好处就是不会产生数据竞 争的问题，因此，本申请可以无需借助锁便可以实现任务的调度。此外，由于Actor模型中 的各个Actor之间的状态是相互隔离的，以及各个Actor之间通过消息进行交互，因此，本 申请也可以避免基于分布式锁的实现方式也可能会出现抢锁的问题以及可以实现调度高并 发、异步化，任务进行高效流转，减少系统开销。

附图说明

图1为本申请实施例实现本申请实施例的基于Actor模型的任务调度方法的调度系统的 架构示意图；

图2为本申请所述的基于Actor模型的任务调度方法的一种实施例的流程图；

图3为本申请通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节 点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息的形式 发送给所述第三Actor的步骤细化流程示意图；

图4为本申请通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥 有的任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第 一预设阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor的步骤细化流程 示意图；

图5为本申请通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的 任务中在当前时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预 设阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor的步骤细化流程示意 图；

图6为本申请所述的基于Actor模型的任务调度装置的一种实施例的程序模块图；

图7为本申请实施例提供的执行基于Actor模型的任务调度方法的计算机设备的硬件结 构示意图。

具体实施方式

以下结合附图与具体实施例进一步阐述本申请的优点。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时， 除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述 的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书 中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公 开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除 非上下文清楚地表示其它含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多 个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信 息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公 开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信 息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响 应于确定”。

在本申请的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序， 仅用于方便描述本申请及区别每一步骤，因此不能理解为对本申请的限制。

图1示意性示出了实现本申请实施例的基于Actor模型的任务调度方法的调度系统的架 构示意图。其中，Actor模型也可以称为参与者模型。在示例性的实施例中，该调度系统包 括基础层、策略层、状态机层、消息层。其中，基础层用于提供基础工具与监控功能；策略 层用于配置调度策略；状态机层包括多个Actor，用于进行任务状态流转；消息层用于对消 息进行存储。在本实施例中，用户可以在策略层配置策略，这样，状态机层可以根据策略层 配置的策略进行任务处理流转。基础层中的监控服务可以时刻监控状态机的状态，以保障调 度系统的稳定性。调度系统中的各个层具体可以由不同的组件组成，包括Actor管理器、消 息箱、消息处理器、消息执行器、监控管理等。其中，

Actor管理器：用于统一管理调度系统中的若干Actor，其中，这些Actor的关系为平等 或包含关系；

消息箱：每个actor均有独自的消息箱，作为存储接受待处理的消息；

消息处理器：处理业务消息，由业务系统来实现。

消息执行器：每个类型消息有对应单个或多个处理器，每个actor可以在各自消息处理 方法中调用对应的处理器；

监控管理：对每个actor做诊断与监控，若出现异常，可以自动调用恢复策略，使系统 具备自愈能力。

参阅图2，其为本申请一实施例的基于Actor模型的任务调度方法的流程示意图。在本 实施例中，Actor模型是一个概念模型，用于处理并发计算，Actor模型包括三个Actor，分 别为第一Actor、第二Actor及第三Actor。其中，每一个Actor是一个最基本的计算单元， 它能接收一个消息并且基于其执行计算。Actor之间相互隔离，它们不互相共享内存，它们 通过各自的地址相互发送消息。此外，每个Actor都有一个mailbox，用于存储消息，Actor 之间通过消息进行流转计算。当Actor收到消息后首先存储在自己的mailbox中，然后Actor 从自己的mailbox中顺序消费消息，并在处理结束后可以向其他Actor发送消息。

可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。从图中可以看 出，本实施例中所提供的基于Actor模型的任务调度方法包括：

步骤S20、在当前任务触发后，对所述当前任务进行初始化，并在初始化完成后，将所 述当前任务的状态修改为待运行状态。

具体地，若当前任务满足触发条件，该当前任务会被触发。其中，所述触发条件可以为 用户设定的时间，比如，若用户设定当前任务在每天早上10点执行，则在每天早上10点的 时候，该当前任务就会被触发。

在本实施例中，在当前任务触发后，可以创建当前任务的实例实现任务的初始化。

需要说明的是，所述当前任务仅仅指的是当前时刻需要执行的任务。所述待运行状态指 的的是任务完成初始化后所处的状态。

步骤S21，将所述待运行状态以第一消息的形式发送给所述第一Actor。

具体地，由于Actor在进行数据处理与计算是基于消息实现的，因此，在本实施例中， 在进行任务状态的流转时，需要将任务状态打包成消息(Message)的格式才能实现任务状态的 流转，即在将待运行状态流转至第一Actor时，需要将该待运行状态打包成第一消息，然后， 将该第一消息发送给第一Actor。

第一Actor在接收到该第一消息后，会将其存储至自己的Mailbox(邮箱)中。

其中，所述第一Actor也可以称为JobContextKeeper，是一个用于任务初始化后进行任 务等待的Actor。

步骤S22，通过所述第一Actor根据所述第一消息判断所述当前任务是否处于已就绪状 态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第二消息的形式发送给 所述第二Actor。

具体地，所述第一Actor顺序从其自己的Mailbox中消费消息，并在消费到所述第一消 息时，会检测当前任务所依赖的所有上游是否已经运行成功，即该当前任务所依赖的所有上 游都准备好了。若检测到当前任务所依赖的所有上游都已经运行成功，则可以判定当前任务 处于已就绪状态。

在本实施例中，在判定出所述当前任务处于已就绪状态后，第一Actor即可以通过第二 消息的方式将所述已就绪状态发送给所述第二Actor，从而实现任务状态的流转。

需要说明的是，已就绪状态指的是任务满足运行(执行)条件后所处的状态。

其中，所述第二Actor也可以称为JobAllocate，是一个用于任务分发的Actor。

步骤S23，通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点， 并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息的形式发送 给所述第三Actor。

具体地，所述第二Actor顺序从其自己的Mailbox中消费消息，并在消费到所述第二消 息时，会确定执行所述当前任务的执行节点。在一实施方式中，所述第二Actor在确定所述 执行节点时，可以根据所有执行节点的状态来确定执行所述当前任务的执行节点。具体而言， 所述第二Actor可以查询所以执行节点的状态来确定各个执行节点是否处于空闲状态，若执 行节点处于空闲状态，则可以从处于空闲状态的执行节点中选择出一个执行节点来执行所述 当前任务。在另一实施方式中，所述第二Actor在确定所述执行节点时，也可以根据所有执 行节点的负载情况来确定执行所述当前任务的执行节点。具体而言，所述第二Actor可以查 询所以执行节点的负载情况来获取各个执行节点当前的负载情况，之后可以对各个执行节点 的负载情况进行排序，最后选择负载最低的执行节点作为执行所述当前任务的执行节点。

在本实施例中，在将所述当前任务的状态修改为已分发状态后，第二Actor即可以通过 第三消息的方式将所述已分发状态发送给所述第三Actor，从而实现任务状态的流转。

其中，所述第三Actor也可以称为Dispatcher，是一个用于派发任务到执行节点的Actor。

需要说明的是，已分发状态指的是确定执行任务的执行节点后所处的状态。所述执行节 点为调度系统中对任务进行执行的机器。

在一示例性的实施例中，参照图3，所述Actor模型还包括第四Actor，所述通过所述第 二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当前任务的状态修 改为已分发状态，以及将所述已分发状态以第三消息的形式发送给所述第三Actor包括：

步骤S30，通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点， 并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第四消息的方式发送 给所述第四Actor。

具体地，当执行当前任务需要较多的资源时，则所述第二Actor在已分发状态发给所述 第三Actor之前，可以先将所述已分发状态以第四消息的方式发送给所述第四Actor，以便 所述第四Actor根据该第四消息判定是否需要对当前任务进行限流处理。

步骤S31，通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有 的任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一 预设阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor。

具体地，所述第四Actor顺序从其自己的Mailbox中消费消息，并在消费到所述第四消 息时，会判断创建所述当前任务的用户所拥有的任务中在当前时刻正被执行的任务数量是否 超过第一预设阈值，若判定出未超过所述第一预设阈值，则将所述已分发状态以第三消息的 形式发送给所述第三Actor。

其中，所述第四Actor也可以称为UserQueue，是一个用于对用户级别任务进行限流的 Actor。

作为示例，假设创建所述当前任务的用户所拥有的任务总共有20个，且在当前时刻正 在被执行的任务数量为N个，若N值小于或者等于所述第一预设阈值n，则判定出未超过所 述第一预设阈值，所述第四Actor会将所述已分发状态以第三消息的形式发送给所述第三 Actor；若N值大于所述第一预设阈值n，则判定出超过所述第一预设阈值，所述第四Actor 不会将所述已分发状态以第三消息的形式发送给所述第三Actor，而会继续判断创建所述当 前任务的用户所拥有的任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，直到 判定出未超过所述第一预设阈值，才会将所述已分发状态以第三消息的形式发送给所述第三 Actor。

需要说明的是，所述第一预设阈值可以为默认值，也可以由用户根据实际情况进行设定 与修改，其具体的值在本实施例中不作限定，作为示例，所述第一预设阈值n＝15。

本实施例中，通过第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的 任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，并在判定出未超过所述第一 预设阈值，才会将所述已分发状态以第三消息的形式发送给所述第三Actor，以实现任务状 态的流转，在判定出超过所述第一预设阈值时，不会将所述已分发状态以第三消息的形式发 送给所述第三Actor，从而实现用户级别的任务限流。

在一示例性的实施例中，参照图4，所述Actor模型还包括第五Actor，所述通过所述第 四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中在当前时刻正被执 行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈值，则将所述已分发 状态以第三消息的形式发送给所述第三Actor包括：

步骤S40，通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有 的任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一 预设阈值，将所述已分发状态以第五消息的方式发送给所述第五Actor。

具体地，当执行当前任务需要较多的资源时，为了进一步对当前任务进行限流处理，则 在判定出未超过所述第一预设阈值，可以先将所述已分发状态以第五消息的方式发送给所述 第五Actor，由五Actor判定是否需要将所述已分发状态以第三消息的形式发送给所述第三 Actor。

其中，所述第五Actor也可以称为DepartmentQueue，是一个用于对部门级别任务进行 限流进行限流的Actor。

步骤S41，通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任 务中在当前时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设 阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor。

具体地，所述第五Actor顺序从其自己的Mailbox中消费消息，并在消费到所述第五消 息时，会判断所述用户所在的部门所拥有的任务中在当前时刻正被执行的任务数量是否超过 第二预设阈值，若判定出未超过所述第二预设阈值，则将所述已分发状态以第三消息的形式 发送给所述第三Actor。

作为示例，假设所述用户1属于部门A，部门A中除了用户1之外，还有用户2与用户3，则该部门A所拥有的任务数量则为用户1、用户2及用户3所创建的任务数量之和。作 为示例，部门A所拥有的任务总共有150个，且在当前时刻正在被执行的任务数量为M个， 若M值小于或者等于所述第二预设阈值m，则判定出未超过所述第二预设阈值，所述第五 Actor会将所述已分发状态以第三消息的形式发送给所述第三Actor；若M值大于所述第二 预设阈值m，则判定出超过所述第二预设阈值，所述第五Actor不会将所述已分发状态以第 三消息的形式发送给所述第三Actor，而会继续判断所述用户所在的部门所拥有的任务中在 当前时刻正被执行的任务数量是否超过第二预设阈值，直到判定出未超过所述第二预设阈 值，才会将所述已分发状态以第三消息的形式发送给所述第三Actor。

需要说明的是，所述第二预设阈值可以为默认值，也可以由用户根据实际情况进行设定 与修改，其具体的值在本实施例中不作限定，作为示例，所述第二预设阈值n＝60。

本实施例中，通过第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务 中在当前时刻正被执行的任务数量是否超过第二预设阈值，并在判定出未超过所述第二预设 阈值，才会将所述已分发状态以第三消息的形式发送给所述第三Actor，以实现任务状态的 流转，在判定出超过所述第二预设阈值时，不会将所述已分发状态以第三消息的形式发送给 所述第三Actor，从而实现部门级别的任务限流。

在一示例性的实施例中，参照图5，所述Actor模型还包括第六Actor，所述通过所述第 五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务中在当前时刻正被执行的 任务数量是否超过第二预设阈值，若判定出未超过所述第二预设阈值，则将所述已分发状态 以第三消息的形式发送给所述第三Actor包括：

步骤S50，通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任 务中在当前时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设 阈值，则将所述已分发状态以第六消息的形式发送给所述第六Actor。

具体地，当当前需要执行的任务存在多个时，为了避免任务在执行过程中出现抢锁的问 题，则判定出未超过所述第二预设阈值，可以先将所述已分发状态以第六消息的方式发送给 所述第六Actor。

其中，所述第六Actor也可以称为ExecuteQueue，是一个用于对资源队列级别任务进行 调度的Actor。

步骤S51，通过所述第六Actor根据所述第六消息将所述当前任务存储至预设的队列中， 并将所述已分发状态以第三消息的形式发送给所述第三Actor。

具体地，所述第六Actor顺序从其自己的Mailbox中消费消息，并在消费到所述第六消 息时，将所述当前任务存储至预设的队列中，这样，在第三Actor顺序从其自己的Mailbox 中消费消息，并在消费到所述第三消息时，即可以从队列中顺序取出存储在其中的任务，然 后，将任务发给执行节点进行执行，并在执行节点执行任务成功后，继续从队列中取出下一 个任务发给执行节点进行执行。

本实施例中，通过所述第六Actor根据所述第六消息将所述当前任务存储至预设的队列 中进行缓存，使得第三Actor在将任务发给执行节点执行时，可以按照顺序从队列中取出任 务，从而可以避免任务在执行过程中出现抢锁的问题。

步骤S24，通过所述第三Actor根据所述第三消息将所述当前任务发送给所述执行节点， 以通过所述执行节点执行所述当前任务。

具体地，所述第三Actor顺序从其自己的Mailbox中消费消息，并在消费到所述第三消 息时，会将当前任务发送给执行节点，这样，该执行节点可以执行所述当前任务。

本申请实施例中，通过在任务触发后，对任务进行初始化，并在完成初始化后将任务状 态以消息的形式给所述第一Actor；通过所述第一Actor根据所述第一消息判断所述当前任 务是否处于已就绪状态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第 二消息的形式发送给所述第二Actor；通过所述第二Actor根据所述第二消息确定执行所述 当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态 以第三消息的形式发送给所述第三Actor；通过所述第三Actor根据所述第三消息将所述当 前任务发送给所述执行节点，以通过所述执行节点执行所述当前任务。本实施例中，由于各 个Actor之间是通过消息的方式来进行通信的，而通过消息通信的好处就是不会产生数据竞 争的问题，因此，本申请可以无需借助锁便可以实现任务的调度。此外，由于Actor模型中 的各个Actor之间的状态是相互隔离的，以及各个Actor之间通过消息进行交互，因此，本 申请也可以避免基于分布式锁的实现方式也可能会出现抢锁的问题，以及可以实现调度高并 发、异步化，任务进行高效流转，减少系统开销。

在一示例性的实施例中，所述方法还包括：

通过所述第三Actor接收所述执行节点返回的所述当前任务的执行状态信息，并在所述 执行状态信息为执行失败状态时，将所述执行失败状态以第七消息的形式发送给所述第一 Actor。

具体地，执行节点在对当前任务进行执行时，会返回对任务的执行状态信息给所述第三 Actor。所述第三Actor在接收到所述执行任务状态信息后，会判断该执行状态信息是否为执 行失败状态，若是，则会将该执行失败状态以第七消息的形式发送给所述第一Actor，以便 可以再次对所述当前任务进行执行。

其中，所述执行状态信息可以包括执行成功、执行失败、执行失效等状态，其中当执行 状态信息不为执行成功时，即可以判定该执行状态信息为执行失败状态，之后，所述第三 Actor即会将所述执行失败状态以第七消息的形式发送给所述第一Actor，以便该当前任务可 以再次重头开始进行执行。

在一示例性的实施例中，所述方法还包括：

对所述Actor模型中的所有Actor进行监控，并在监控到Actor出现故障时，调用预设 的恢复策略对出现故障的Actor进行处理，以使出现故障的Actor恢复正常。

具体地，所述恢复策略为用于对当前出现故障的Actor进行恢复的机制，在一实施例中， 所述恢复策略可以为对出现故障的Actor进行初始化，以使出现故障的Actor恢复正常。在 另一实施方式中，该恢复策略也可以为对调度系统的内部状态重置，然后重新分配资源，生 成一个新的Actor来替代该出现故障的Actor。

在一示例性的实施例中，所述方法还包括：

当所述Actor模型中的Actor检测到当前待消费的消息数量大于预设数量时，则对相同 状态的消息进行压缩处理。

具体地，当Actor检测到其自身邮箱中待消费的消息数量大于预设数量时，为了加快任 务状态的流转，可以对当前待消费的消息中具有相同状态的信息进行压缩处理，然后将最新 的消息发送给下一个Actor进行处理。

需要说明的是，本实施例中的压缩处理指的是将相同状态的消息除了最新的消息之外都 进行丢弃，或者将相同状态的消息进行标记，以便在对这些相同状态的消息进行处理时，可 以只处理一条最新的消息。

参阅图6所示，是本申请基于Actor模型的任务调度装置60一实施例的程序模块图。

本实施例中，所述Actor模型包括第一Actor、第二Actor及第三Actor，所述基于Actor 模型的任务调度装置60包括一系列的存储于存储器上的计算机程序指令，当该计算机程序 指令被处理器执行时，可以实现本申请各实施例的基于Actor模型的任务调度功能。在一些 实施例中，基于该计算机程序指令各部分所实现的特定的操作，基于Actor模型的任务调度 装置60可以被划分为一个或多个模块。例如，在图6中，所述基于Actor模型的任务调度 装置60可以被分割成初始化模块61、第一发送模块62、第二发送模块63、第三发送模块 64及第四发送模块65。其中：

初始化模块61，用于在当前任务触发后，对所述当前任务进行初始化，并在初始化完成 后，将所述当前任务的状态修改为待运行状态

第一发送模块62，用于将所述待运行状态以第一消息的形式发送给所述第一Actor。

第二发送模块63，用于通过所述第一Actor根据所述第一消息判断所述当前任务是否处 于已就绪状态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第二消息的 形式发送给所述第二Actor；

第三发送模块64，用于通过所述第二Actor根据所述第二消息确定执行所述当前任务的 执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息 的形式发送给所述第三Actor；

第四发送模块65，用于通过所述第三Actor根据所述第三消息将所述当前任务发送给所 述执行节点，以通过所述执行节点执行所述当前任务

在一示例性的实施方式中，所述Actor模型还包括第四Actor，所第三发送模块64，还 用于通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当 前任务的状态修改为已分发状态，以及将所述已分发状态以第四消息的方式发送给所述第四 Actor；通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中 在当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈 值，则将所述已分发状态以第三消息的形式发送给所述第三Actor。

在一示例性的实施方式中，所述Actor模型还包括第五Actor，所第三发送模块64，还 用于通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中在 当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈值， 将所述已分发状态以第五消息的方式发送给所述第五Actor；通过所述第五Actor根据所述 第五消息判断所述用户所在的部门所拥有的任务中在当前时刻正被执行的任务数量是否超 过第二预设阈值，若判定出未超过所述第二预设阈值，则将所述已分发状态以第三消息的形 式发送给所述第三Actor。

在一示例性的实施方式中，所述Actor模型还包括第六Actor，所第三发送模块64，还 用于通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务中在当前 时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设阈值，则将 所述已分发状态以第六消息的形式发送给所述第六Actor；通过所述第六Actor根据所述第 六消息将所述当前任务存储至预设的队列中，并将所述已分发状态以第三消息的形式发送给 所述第三Actor。

在一示例性的实施方式中，基于Actor模型的任务调度装置60还包括接收模块。

所述接收模块，用于通过所述第三Actor接收所述执行节点返回的所述当前任务的执行 状态信息，并在所述执行状态信息为执行失败状态时，将所述执行失败状态以第七消息的形 式发送给所述第一Actor。

在一示例性的实施方式中，基于Actor模型的任务调度装置60还包括监控模块。

所述监控模块，用于对所述Actor模型中的所有Actor进行监控，并在监控到Actor出 现故障时，调用预设的恢复策略对出现故障的Actor进行处理，以使出现故障的Actor恢复 正常。

在一示例性的实施方式中，当所述Actor模型中的Actor检测到当前待消费的消息数量 大于预设数量时，则对相同状态的消息进行压缩处理。

本申请实施例中，通过在任务触发后，对任务进行初始化，并在完成初始化后将任务状 态以消息的形式给所述第一Actor；通过所述第一Actor根据所述第一消息判断所述当前任 务是否处于已就绪状态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第 二消息的形式发送给所述第二Actor；通过所述第二Actor根据所述第二消息确定执行所述 当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态 以第三消息的形式发送给所述第三Actor；通过所述第三Actor根据所述第三消息将所述当 前任务发送给所述执行节点，以通过所述执行节点执行所述当前任务。本实施例中，由于各 个Actor之间是通过消息的方式来进行通信的，以及各个Actor之间通过消息进行交互，因 此，本申请也可以避免基于分布式锁的实现方式也可能会出现抢锁的问题，以及可以实现调 度高并发、异步化，任务进行高效流转，减少系统开销。

图7示意性示出了根据本申请实施例的适于实现基于Actor模型的任务调度方法的计算 机设备20的硬件架构示意图。本实施例中，计算机设备20是一种能够按照事先设定或者存 储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是平板电脑、笔记本电脑、 台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务 器，或者多个服务器所组成的服务器集群)等。如图7所示，计算机设备20至少包括但不 限于：可通过系统总线相互通信链接存储器120、处理器121、网络接口123。其中：

存储器120至少包括一种类型的计算机可读存储介质，该可读存储介质可以是易失性的， 也可以是非易失性的，具体而言，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例 如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、 只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、 磁性存储器、磁盘、光盘等。在一些实施例中，存储器120可以是计算机设备20的内部存 储模块，例如该计算机设备20的硬盘或内存。在另一些实施例中，存储器120也可以是计 算机设备20的外部存储设备，例如该计算机设备20上配备的插接式硬盘，智能存储卡(Smart MediaCard，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card) 等。当然，存储器120还可以既包括计算机设备20的内部存储模块也包括其外部存储设备。 本实施例中，存储器120通常用于存储安装于计算机设备20的操作系统和各类应用软件， 例如基于Actor模型的任务调度方法的程序代码等。此外，存储器120还可以用于暂时地存 储已经输出或者将要输出的各类数据。

处理器121在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、 控制器、微控制器、微处理器、或其它数据处理芯片。该处理器121通常用于控制计算机设 备20的总体操作，例如执行与计算机设备20进行数据交互或者通信相关的控制和处理等。 本实施例中，处理器121用于运行存储器120中存储的程序代码或者处理数据。

网络接口123可包括无线网络接口或有线网络接口，该网络接口123通常用于在计算机 设备20与其它计算机设备之间建立通信链接。例如，网络接口123用于通过网络将计算机 设备20与外部终端相连，在计算机设备20与外部终端之间的建立数据传输通道和通信链接 等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，简称为GSM)、宽带码分多址(Wideband CodeDivision Multiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线 网络。

需要指出的是，图7仅示出了具有部件120～122的计算机设备，但是应理解的是，并不 要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器120中的基于Actor模型的任务调度方法可以被分割为一 个或者多个程序模块，并由一个或多个处理器(本实施例为处理器121)所执行，以完成本 申请。

本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质其上存储有计算机 程序，计算机程序被处理器执行时实现实施例中的基于Actor模型的任务调度方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD 或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储 器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁 性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部 存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可 以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡 (Smart MediaCard，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外 部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统 和各类应用软件，例如实施例中的基于Actor模型的任务调度方法的程序代码等。此外，计 算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也 可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于 一个地方，或者也可以分布到至少两个网络单元上。可以根据实际的需要筛选出其中的部分 或者全部模块来实现本申请实施例方案的目的。本领域普通技术人员在不付出创造性的劳动 的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域普通技术人员可以清楚地了解到各实施方式可借助 软件加通用硬件平台的方式来实现，当然也可以通过硬件。本领域普通技术人员可以理解实 现上述实施例方法中的全部或部分流程是可以通过计算机程序来指令相关的硬件来完成，所 述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实 施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory， ROM)或随机存储记忆体(RandomAccessMemory，RAM)等。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参 照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以 对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替 换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种基于Actor模型的任务调度方法，其特征在于，所述Actor模型包括第一Actor、第二Actor及第三Actor，所述方法包括：

在当前任务触发后，对所述当前任务进行初始化，并在初始化完成后，将所述当前任务的状态修改为待运行状态；

将所述待运行状态以第一消息的形式发送给所述第一Actor；

通过所述第一Actor根据所述第一消息判断所述当前任务是否处于已就绪状态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第二消息的形式发送给所述第二Actor；

通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息的形式发送给所述第三Actor；

通过所述第三Actor根据所述第三消息将所述当前任务发送给所述执行节点，以通过所述执行节点执行所述当前任务。

2.根据权利要求1所述的基于Actor模型的任务调度方法，其特征在于，所述Actor模型还包括第四Actor，所述通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息的形式发送给所述第三Actor包括：

通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第四消息的方式发送给所述第四Actor；

通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor。

3.根据权利要求2所述的基于Actor模型的任务调度方法，其特征在于，所述Actor模型还包括第五Actor，所述通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor包括：

通过所述第四Actor根据所述第四消息判断创建所述当前任务的用户所拥有的任务中在当前时刻正被执行的任务数量是否超过第一预设阈值，若判定出未超过所述第一预设阈值，将所述已分发状态以第五消息的方式发送给所述第五Actor；

通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务中在当前时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor。

4.根据权利要求3所述的基于Actor模型的任务调度方法，其特征在于，所述Actor模型还包括第六Actor，所述通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务中在当前时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设阈值，则将所述已分发状态以第三消息的形式发送给所述第三Actor包括：

通过所述第五Actor根据所述第五消息判断所述用户所在的部门所拥有的任务中在当前时刻正被执行的任务数量是否超过第二预设阈值，若判定出未超过所述第二预设阈值，则将所述已分发状态以第六消息的形式发送给所述第六Actor；

通过所述第六Actor根据所述第六消息将所述当前任务存储至预设的队列中，并将所述已分发状态以第三消息的形式发送给所述第三Actor。

5.根据权利要求1所述的基于Actor模型的任务调度方法，其特征在于，所述方法还包括：

通过所述第三Actor接收所述执行节点返回的所述当前任务的执行状态信息，并在所述执行状态信息为执行失败状态时，将所述执行失败状态以第七消息的形式发送给所述第一Actor。

6.根据权利要求1至5任一项所述的基于Actor模型的任务调度方法，其特征在于，所述方法还包括：

对所述Actor模型中的所有Actor进行监控，并在监控到Actor出现故障时，调用预设的恢复策略对出现故障的Actor进行处理，以使出现故障的Actor恢复正常。

7.根据权利要求1所述的基于Actor模型的任务调度方法，其特征在于，当所述Actor模型中的Actor检测到当前待消费的消息数量大于预设数量时，则对相同状态的消息进行压缩处理。

8.一种基于Actor模型的任务调度装置，所述Actor模型包括第一Actor、第二Actor及第三Actor，其特征在于，包括：

初始化模块，用于在当前任务触发后，对所述当前任务进行初始化，并在初始化完成后，将所述当前任务的状态修改为待运行状态；

第一发送模块，用于将所述待运行状态以第一消息的形式发送给所述第一Actor；

第二发送模块，用于通过所述第一Actor根据所述第一消息判断所述当前任务是否处于已就绪状态，并在判定出所述当前任务处于已就绪状态，将所述已就绪状态以第二消息的形式发送给所述第二Actor；

第三发送模块，用于通过所述第二Actor根据所述第二消息确定执行所述当前任务的执行节点，并将所述当前任务的状态修改为已分发状态，以及将所述已分发状态以第三消息的形式发送给所述第三Actor；

第四发送模块，用于通过所述第三Actor根据所述第三消息将所述当前任务发送给所述执行节点，以通过所述执行节点执行所述当前任务。

9.一种计算机设备，所述计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的基于Actor模型的任务调度方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现权利要求1至7任一项所述的基于Actor模型的任务调度方法的步骤。

Images