CN117851011A - 任务队列管理方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本发明涉及计算机技术领域，公开了任务队列管理方法、装置、计算机设备及存储介质，本发明将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列；对各任务队列采用多级存储；在内存中查询排队或正在运行的任务信息；对需更改任务状态的任务进行任务状态更改，并在嵌入式数据库中持久化更改后的任务状态；在全功能数据库中筛选已结束的任务信息；在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。本发明将不同状态任务在不同任务队列中维护，以此均摊针对不同状态任务的不同需求产生的查询或维护数据数据结构的压力，能够承受高并发压力且满足了抗故障要求。

Description

任务队列管理方法、装置、计算机设备及存储介质

技术领域

本发明涉及计算机技术领域，具体涉及任务队列管理方法、装置、计算机设备及存储介质。

背景技术

对一个大规模高性能计算集群，经常会出现大量用户同时提交任务的场景。目前广泛使用的Slurm(Simple Linux Utility for Resource Management，Linux集群资源管理和作业调度系统)调度系统的任务提交和调度吞吐量为1秒处理约500个简单批处理作业。而对于任务高吞吐场景，Slurm不能较好地满足需求。

由于任务提交场景要求作业在提交后，如果集群出现故障，任务需要尽可能持续保持运行，已提交任务信息则要求不可以丢失。因此，亟需一个同时能承受高并发压力且能达成前述抗故障要求的任务队列系统。

发明内容

有鉴于此，本发明提供了一种任务队列管理方法、装置、计算机设备及存储介质，以解决现有任务队列无法承受高并发压力且达不到抗故障要求的问题。

第一方面，本发明提供了一种任务队列管理方法，所述方法包括：

将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列；

对各任务队列采用多级存储，其中，所述多级存储包括：内存存储、嵌入式数据库存储和全功能数据库存储，所述排队状态任务队列和所述运行状态任务队列均采用内存存储和嵌入式数据库存储，所述结束状态任务队列采用全功能数据库存储；

响应于排队状态任务队列和运行状态任务队列的任务查询请求，在所述内存中获取所查询的任务的信息；

响应于排队状态任务队列和运行状态任务队列的任务状态更改请求，对需更改任务状态的任务进行任务状态更改，并在所述嵌入式数据库中持久化更改后的任务状态；

响应于结束状态任务队列的任务筛选请求，在所述全功能数据库中获取所筛选的任务的信息；

在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。

本实施例提供的任务队列管理方法，通过对任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列，对各任务队列采用多级存储，将不同状态任务在不同任务队列中维护，以此均摊针对不同状态任务的不同需求产生的查询或维护数据数据结构的压力，提高系统整体吞吐率，能够承受高并发压力。且本实施例在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复，满足了抗故障要求。

在一种可选的实施方式中，所述嵌入式数据库为键值型嵌入式数据库，利用哈希表构建出链表，模拟排队状态任务队列结构和运行状态任务队列结构，其中，所述对各任务队列采用多级存储，包括：

将排队状态任务队列按照排队状态任务顺序存储至键值型嵌入式数据库链表中的第一数据节点，其中，一个任务对应一个数据节点，一个数据节点包括：当前数据节点ID、前一个数据节点ID、后一个数据节点ID和所述任务；

将运行状态任务队列按照运行状态任务顺序存储至键值型嵌入式数据库链表的第二数据节点。

本实施例通过键值型的嵌入式数据库构造的链表，对运行状态任务队列结构和排队状态任务队列结构进行模拟，满足了底层数据接口的通用性和持久化的快速性。

在一种可选的实施方式中，所述链表包括：虚节点和数据节点，其中，

所述虚节点包括队列头和队列尾，所述队列头包括队列头节点ID和队列中第一个数据节点ID，所述队列尾包括队列尾节点ID和队列中最后一个数据节点ID。

本实施例的键值型嵌入式数据库所构建的链表为双向链表，链表中所有节点都有唯一的节点ID，每个节点可以在O(1)的时间复杂度被检索到，提高了检索效率。

在一种可选的实施方式中，所述方法还包括：

在所述排队状态任务队列中的任务需转移到所述运行状态任务队列的情况下，利用嵌入式数据库提供的事务机制来完成转移；

在所述运行状态任务队列的任务需转移到所述结束状态任务队列的情况下，利用预写式日志机制来完成转移。

本实施例在保障高性能的前提下，利用不同类型数据库提供不同程度的一致性保障功能，以满足抗故障需求。

在一种可选的实施方式中，所述利用预写式日志机制来完成转移，包括：

获取所述运行状态任务队列中需转移的任务；

将所述需转移的任务写入结束状态队列缓冲区；

将结束状态队列缓冲区的任务写入所述全功能数据库；

将所述结束状态队列缓冲区的任务删除。

本实施例通过预写式日志机制来完成不同数据库之间的任务转移，保证了跨数据库任务数据转移的原子性，满足了抗故障需求。

在一种可选的实施方式中，所述在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复，包括：

在任务集群需要重启或是遭遇故障恢复的情况下，按照运行状态任务队列、排队状态任务队列、结束状态任务队列缓冲区的恢复顺序进行任务队列恢复。

本实施例在任务集群需要重启或是遭遇故障恢复的情况下，按照上述恢复顺序恢复任务队列，使得任务队列直接恢复至最新状态，减少了时间复杂度。

在一种可选的实施方式中，所述方法还包括：

响应于任务更新操作，获取待更新任务对应的数据节点ID，基于所述待更新任务对应的数据节点ID对所述待更新任务进行更新；

响应于任务检索操作，获取待检索任务对应的数据节点ID，基于所述待检索任务对应的数据节点ID对所述待检索任务进行检索；

响应于任务插入操作，获取所述虚节点的位置，基于所述虚节点的位置完成待插入任务的插入；

响应于任务删除操作，获取待删除任务对应的数据节点ID，基于所述待删除任务对应的数据节点ID对所述待删除任务进行删除。

本实施例通过使用键值型数据库，对于任意给定节点ID，可以在O(1)的时间内检索到对应的任务，并执行对应的操作，减少了时间复杂度，提高了系统整体吞吐率。

第二方面，本发明提供了一种任务队列管理装置，所述装置包括：

任务划分模块，用于将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列；

任务队列多级存储模块，用于对各任务队列采用多级存储，其中，所述多级存储包括：内存存储、嵌入式数据库存储和全功能数据库存储，所述排队状态任务队列和所述运行状态任务队列均采用内存存储和嵌入式数据库存储，所述结束状态任务队列采用全功能数据库存储；

任务信息查询模块，用于响应于排队状态任务队列和运行状态任务队列的任务查询请求，在所述内存中获取所查询的任务的信息；

任务状态更改模块，用于响应于排队状态任务队列和运行状态任务队列的任务状态更改请求，对需更改任务状态的任务进行任务状态更改，并在所述嵌入式数据库中持久化更改后的任务状态；

任务信息筛选模块，用于响应于结束状态任务队列的任务筛选请求，在所述全功能数据库中获取所筛选的任务的信息；

任务队列恢复模块，用于在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。

第三方面，本发明提供了一种基于多级存储的高性能抗故障任务队列系统，所述系统包括：主控节点和计算节点，所述主控节点用于执行上述第一方面或其对应的任一实施方式的任务队列管理方法。

在一种可选的实施方式中，主控节点包括：高并发抗故障任务管理模块、智能任务调度模块、账户权限管理模块、节点状态管理模块及跨节点资源安全模块；

高并发抗故障任务管理模块，用来处理任务提交、管理任务队列情况，将不同状态任务在不同队列中维护，以此均摊针对不同状态任务的不同需求产生的查询或维护数据结构的压力；

智能任务调度模块，用来对排队状态任务进行智能化调度；

账户权限管理模块，用来提供对于不同用户的信息和权限管理功能；

节点状态管理模块，用来对节点进行状态监控和进行安全通信；

跨节点资源安全模块，用来对在各个计算节点上执行的任务进行追踪和资源限制；

计算节点包括计算守护进程，用于执行任务和实施资源限制。

第四方面，本发明提供了一种计算机设备，包括：存储器和处理器，存储器和处理器之间互相通信连接，存储器中存储有计算机指令，处理器通过执行计算机指令，从而执行上述第一方面或其对应的任一实施方式的任务队列管理方法。

第五方面，本发明提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机指令，计算机指令用于使计算机执行上述第一方面或其对应的任一实施方式的任务队列管理方法。

附图说明

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

图1是根据本发明实施例的任务队列管理方法的流程示意图；

图2是根据本发明实施例的基于多级存储的任务队列的架构示意图；

图3是根据本发明实施例的另一任务队列管理方法的流程示意图；

图4是根据本发明实施例的键值型数据库中任务队列节点的示意图；

图5是根据本发明实施例的不同状态的任务队列恢复顺序的示意图；

图6是根据本发明实施例的任务队列管理装置的结构框图；

图7是根据本发明实施例的基于多级存储的高性能抗故障任务队列系统的示意图；

图8是根据本发明实施例的不同负载下CraneSched指令的时延关系图；

图9是本发明实施例的计算机设备的硬件结构示意图。

具体实施方式

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

对一个大规模高性能计算集群，经常会出现大量用户同时提交任务的场景。目前广泛使用的Slurm(Simple Linux Utility for Resource Management，Linux集群资源管理和作业调度系统)调度系统的任务提交和调度吞吐量为1秒处理约500个简单批处理作业。而对于任务高吞吐场景，Slurm不能较好地满足需求。

由于任务提交场景要求作业在提交后，如果集群出现故障，任务需要尽可能持续保持运行，已提交任务信息则要求不可以丢失。因此，亟需一个同时能承受高并发压力且能达成前述抗故障要求的任务队列系统。

本发明实施例提供了一种任务队列管理方法，通过在高性能调度场景下对任务队列采用多级存储的方式达到承受高并发压力且能达成抗故障要求的效果。

根据本发明实施例，提供了一种任务队列管理方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本实施例中提供了一种任务队列管理方法，可用于上述的移动终端，如中央处理单元、服务器等，图1是根据本发明实施例的任务队列管理方法的流程图，如图1所示，该流程包括如下步骤：

步骤S101，将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列。

在大量用户同时提交任务的情况下，根据用户提交的任务的任务状态对任务进行分类，分为排队状态任务队列、运行状态任务队列和结束状态任务队列。

步骤S102，对各任务队列采用多级存储。

其中，多级存储包括：内存存储、嵌入式数据库存储和全功能数据库存储。

图2是根据本发明实施例的基于多级存储的任务队列的架构示意图。如图2所示，排队状态任务队列和运行状态任务队列均采用内存存储和嵌入式数据库存储，结束状态任务队列采用全功能数据库存储。

需要说明的是，排队状态任务队列和运行状态任务队列采用2级存储方式，其中，上面一级为内存存储，下面一级为嵌入式数据库存储。嵌入式数据库存储用来持久化内存存储中的任务数据，两级存储中任务数据完全一致。其中，本实施例中的嵌入式数据库为轻量高性能嵌入式数据库，实现了任务数据的高性能持久化。

进一步需要说明的是，嵌入式数据库任务写入速度接近文件系统，但相对于文件系统，嵌入式数据库提供了事务机制功能。同时，嵌入式数据库不具备强大的查询引擎，在程序内部直接调用，省去了网络栈的开销，因此能以更快的速度写入磁盘。

步骤S103，响应于排队状态任务队列和运行状态任务队列的任务查询请求，在内存中获取所查询的任务的信息。

其中，由于任务信息的查询请求一般只涉及到内存中的排队状态任务和运行状态任务的数据结构的操作，因此，在接收到任务查询请求的情况下，响应于任务查询请求，在内存中获取所查询的任务的信息，可以加速查询和修改。

步骤S104，响应于排队状态任务队列和运行状态任务队列的任务状态更改请求，对需更改任务状态的任务进行任务状态更改，并在嵌入式数据库中持久化更改后的任务状态。

其中，在需要对排队状态任务队列和运行状态任务队列中的某一任务进行任务状态更改的情况下，获取任务状态更改请求中的需更改任务状态的任务，对需更改任务状态的任务进行任务状态更改，并在嵌入式数据库中持久化更改后的任务状态。

其中，任务状态更改可以是由于任务调度将排队状态任务队列中的任务的任务状态更改为运行状态。

需要说明的是，在对排队状态任务队列和运行状态任务队列的任务进行任务数据修改时，对需要任务数据修改的任务进行修改后，也需要在嵌入式数据库中持久化任务数据修改后的任务。

可以理解的是，任务状态更改和任务数据修改一般都是在排队状态任务队列和运行状态任务队列中进行的。

步骤S105，响应于结束状态任务队列的任务筛选请求，在全功能数据库中获取所筛选的任务的信息。

其中，结束状态任务数量可能十分庞大，对于任务的信息持久化到磁盘的速度不敏感，查询较为低频，用于能够容忍相对高一些的查询延迟。但是可能需要根据任务的各种信息对任务进行筛选，因此，结束状态任务队列被存储在全功能数据库中，以便响应于任务筛选请求，在全功能数据库中对结束状态任务队列进行筛选，获得筛选后的任务的信息。需要说明的是，全功能数据库提供了完善的结束状态任务数据分析功能。

步骤S106，在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。

其中，任务集群包括所有任务队列。在高性能计算的场景下，在任务集群需要重启或是遭遇故障恢复的情况下，我们希望的是任务队列系统能够在从多级存储机制中恢复出故障前的任务队列的基础上，根据任务队列中任务状态，动态地将任务队列更新至最新状态。

本实施例通过按照预设恢复顺序对任务队列进行恢复，使得恢复后的任务队列为最新状态。

本实施例提供的任务队列管理方法，通过对任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列，对各任务队列采用多级存储，将不同状态任务在不同任务队列中维护，以此均摊针对不同状态任务的不同需求产生的查询或维护数据数据结构的压力，提高系统整体吞吐率，能够承受高并发压力。且本实施例在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复，满足了抗故障要求。

本实施例针对不同队列之间的任务信息转移，从软件工程的视角，将不同任务队列，设计为具备不同存储层级、支持读写分离的多级任务队列。用户对任务信息的查询大多数为只读查询，因此在内存中维护任务信息能有效地提高查询性能，但由于任务队列又要能满足任务的持久化和抗故障需求和处理少量对于任务信息的变更，因此任务队列也需要被持久化到磁盘上。本实施例将读写分离，设计多级存储结构，满足了多读少写的任务数据查询和修改特征。

在本实施例中提供了一种任务队列管理方法，可用于上述的移动终端，如中央处理单元、服务器等，图3是根据本发明实施例的任务队列管理方法的流程图，如图3所示，该流程包括如下步骤：

步骤S301，将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列。详细请参见图1所示实施例的步骤S101，在此不再赘述。

步骤S302，对各任务队列采用多级存储。

具体地，上述步骤S302包括：

步骤S3021，将排队状态任务队列按照排队状态任务顺序存储至键值型嵌入式数据库链表中的第一数据节点。

考虑到底层数据接口的通用性和持久化的快速性，本实施例嵌入式数据库为键值型嵌入式数据库。键值型嵌入式数据库需要利用哈希表构建出链表，模拟排队状态任务队列结构和运行状态任务队列结构。

其中，将排队状态任务队列中的任务按照排队状态任务的顺序存储至链表中的第一数据节点中。

图4是根据本发明实施例的键值型数据库中任务队列节点的示意图。如图4所示，一个任务对应一个数据节点，一个数据节点包括：当前数据节点ID、前一个数据节点ID、后一个数据节点ID和任务数据本身。

步骤S3022，将运行状态任务队列按照运行状态任务顺序存储至键值型嵌入式数据库链表的第二数据节点。

其中，将运行状态任务队列中的任务按照运行状态任务的顺序存储至链表中的第二数据节点中。

本实施例通过键值型的嵌入式数据库构造的链表，对运行状态任务队列结构和排队状态任务队列结构进行模拟，满足了底层数据接口的通用性和持久化的快速性。

在一个可选的实施方式中，键值型嵌入式数据库中链表包括：虚节点和数据节点，其中，

如图4所示，虚节点包括队列头和队列尾，队列头包括队列头节点ID和队列中第一个数据节点ID，也即图中的首数据节点ID，队列尾包括队列尾节点ID和队列中最后一个数据节点ID，也即图中的尾数据节点ID。

步骤S303，响应于排队状态任务队列和运行状态任务队列的任务查询请求，在内存中获取所查询的任务的信息。

详细请参见图1所示实施例的步骤S103，在此不再赘述。

步骤S304，响应于排队状态任务队列和运行状态任务队列的任务状态更改请求，对需更改任务状态的任务进行任务状态更改，并在嵌入式数据库中持久化更改后的任务状态。

详细请参见图1所示实施例的步骤S104，在此不再赘述。

步骤S305，响应于结束状态任务队列的任务筛选请求，在全功能数据库中获取所筛选的任务的信息。

详细请参见图1所示实施例的步骤S105，在此不再赘述。

步骤S306，在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。

详细请参见图1所示实施例的步骤S106，在此不再赘述。

步骤S307，在排队状态任务队列中的任务需转移到运行状态任务队列的情况下，利用嵌入式数据库提供的事务机制来完成转移。

嵌入式数据库具备两个队列，其中有两个队列间的转移点：一个是排队状态队列到运行状态队列的转移点；另一个是运行状态队列到结束状态队列的转移点，这两个转移点都在嵌入式数据库内部完成，因此使用数据库提供的事务(Transaction)机制保证这几个操作的原子性。

其中，排队状态任务队列中的任务转移到运行状态任务队列是数据库内部的转移，可以利用数据库提供的事务(Transaction)机制保证这几个操作的原子性，排队状态任务队列中的任务在内存中转移到运行状态任务队列可以利用锁机制保证操作的原子性。

步骤S308，在运行状态任务队列的任务需转移到结束状态任务队列的情况下，利用预写式日志机制来完成转移。

由于运行状态任务队列和结束状态任务队列处在不同的数据库中，无法使用数据库提供的事务机制来保证转移的原子性。因此，本实施例提供一个原子保障机制来保障运行状态任务队列的任务转移到结束状态任务队列的原子性。其中，本实施例提供的原子保障机制为预写式日志(WAL，Write-Ahead-Log)机制，该机制能够完成跨数据库任务数据转移的原子性。

本实施例提供的任务队列管理方法，基于现有的不同类型数据库，在保障高性能的前提下，利用它们提供的不同程度的一致性保障功能，即事务机制和预写式日志机制用来保证在出现如节点掉电或程序崩溃等不可恢复故障时，在程序再次启动时，任务队列能够恢复至最近的正确状态。

在一些可选的实施方式中，上述步骤S308包括：

步骤a1，获取运行状态任务队列中需转移的任务。

其中，获取的是运行状态任务队列中需转移到结束状态队列中的任务。

步骤a2，将需转移的任务写入结束状态队列缓冲区。

在获取到需要转移到结束状态队列中的任务之后，将该任务写入结束状态队列缓冲区中。

步骤a3，将结束状态队列缓冲区的任务写入全功能数据库。

结束状态队列缓冲区的任务为需要转移到结束状态队列中的任务，结束状态队列存储在全功能数据库中，因此，将结束状态队列缓冲区的任务写入全功能数据库以完成任务转移。

步骤a4，将结束状态队列缓冲区的任务删除。

在将需要转移到结束状态队列中的任务转移到全功能数据库中存储后，将之前写入结束状态队列缓冲区的任务进行删除。

本实施例中各步骤的原子性由数据库事务的原子性保证。如果在上述步骤任意相邻两步的中间，系统出现故障，则在系统恢复之后继续后续的步骤。由此，整个基于多级存储的任务队列架构的一致性得到保证，具备了抗故障能力。

在一些可选的实施方式中，上述步骤S306包括：

步骤b1，在任务集群需要重启或是遭遇故障恢复的情况下，按照运行状态任务队列、排队状态任务队列、结束状态任务队列缓冲区的恢复顺序进行任务队列恢复。

在故障恢复阶段，任务队列中的任务状态有可能再次发生更新，因此对于不同任务状态的队列的恢复顺序是有一定要求的，必须使得在恢复某个任务状态的任务队列之后，后续新恢复的任务队列中的任务状态即使发生变更，也不会变更为这个前面已经恢复过的任务状态的队列。如果不满足这个要求，则就需要对任务队列重复进行恢复，直至没有任务会发生新的状态变更，这会导致时间复杂度上升。

同时，结束状态任务队列缓冲区中有可能存放还未完全转移至全功能数据库的结束状态任务，对于此部分任务，应当接着完成转移至全功能数据库的操作。

综上可知，运行状态的任务可能更新状态为排队状态或结束状态，排队状态的任务可能更新为结束状态。图5是根据本发明实施例的不同状态的任务队列恢复顺序的示意图。如图5所示，对运行状态任务进行重排队，确认故障前运行状态任务的状态决定回收或恢复。确定这个计算节点是否还在正常运行，如果这个计算节点已经故障或是因其他原因连接不上，则这个任务的状态应该被标记为排队状态，移入排队状态任务队列。如果能正常连接上任务运行的计算节点，则查询这个任务是否已经结束，如果还在运行，则保持这个任务的运行状态，如果查询到任务在故障期间结束或是查询不到任务信息，应当标记任务状态为结束状态，并移入结束状态任务队列缓冲区。同时，对于查询不到是否结束的任务，则有可能该计算节点在主控节点故障期间也遭遇故障重启，针对跨节点任务，应当通知其他计算节点清除相应任务的信息。对于排队状态任务队列，则检查任务是否能满足重排队的要求，如果能顺利重排队，则保持这个任务仍在排队状态队列中，如果因例如配置变更等原因无法顺利重排队，则将这个任务标记为结束状态，并且移入结束状态任务队列缓冲区。对于结束状态任务队列缓冲区，若故障前未成功下移或恢复时重排队失败则进入下一级缓冲区，若成功下移或恢复时重排队成功则将这部分任务移入全功能数据库后，删除此部分任务即可。

本实施例按照运行状态任务队列，排队状态任务队列，结束状态任务队列缓冲区的恢复顺序进行恢复，这样每个任务队列仅需要恢复一次，就可以重建完整的任务队列。

本实施例在任务集群需要重启或是遭遇故障恢复的情况下，按照上述恢复顺序恢复任务队列，使得任务队列直接恢复至最新状态，减少了时间复杂度。

在一些可选的实施方式中，方法还包括：

步骤c1，响应于任务更新操作，获取待更新任务对应的数据节点ID，基于数据节点ID对待更新任务进行更新。

对于数据节点的单点更新操作，由于内存中的每一个任务会包含其在嵌入式数据库中的数据节点ID，因此可以在O(1)的时间内定位到这个数据节点，并对这个数据节点的任务数据进行更新。

步骤c2，响应于任务检索操作，获取待检索任务对应的数据节点ID，基于数据节点ID对待检索任务进行检索。

由于本实施例使用键值型嵌入式数据库，对于任意给定键，其值可以在O(1)的时间内被检索。

步骤c3，响应于任务插入操作，获取虚节点的位置，基于虚节点的位置完成待插入任务的插入。

对于某个队列的任务数据在头尾处的插入操作，由于存在虚节点，可以在O(1)的时间内定位到队列头或队列尾，因此双向链表在头部和尾部的插入和删除时间复杂度也为O(1)。

步骤c4，响应于任务删除操作，获取待删除任务对应的数据节点ID，基于数据节点ID对待删除任务进行删除。

对于某个队列中的任意一个任务数据的删除操作，由于可以在O(1)的时间内定位到这个数据节点，且双向链表的删除数据的复杂度为O(1)，因此总体操作时间复杂度为O(1)。

本实施例通过使用键值型数据库，对于任意给定节点ID，可以在O(1)的时间内检索到对应的任务，并执行对应的操作，减少了时间复杂度，提高了系统整体吞吐率。

在本实施例中还提供了一种任务队列管理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本实施例提供一种任务队列管理装置，如图6所示，包括：

任务划分模块601，用于将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列。

任务队列多级存储模块602，用于对各任务队列采用多级存储，其中，多级存储包括：内存存储、嵌入式数据库存储和全功能数据库存储，排队状态任务队列和运行状态任务队列均采用内存存储和嵌入式数据库存储，结束状态任务队列采用全功能数据库存储。

任务信息查询模块603，用于响应于排队状态任务队列和运行状态任务队列的任务查询请求，在内存中获取所查询的任务的信息。

任务状态更改模块604，用于响应于排队状态任务队列和运行状态任务队列的任务状态更改请求，对需更改任务状态的任务进行任务状态更改，并在嵌入式数据库中持久化更改后的任务状态。

任务信息筛选模块605，用于响应于结束状态任务队列的任务筛选请求，在全功能数据库中获取所筛选的任务的信息。

任务队列恢复模块606，用于在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。

在一些可选的实施方式中，任务队列多级存储模块602，包括：

排队状态任务队列存储单元，用于将排队状态任务队列按照排队状态任务顺序存储至键值型嵌入式数据库链表中的第一数据节点，其中，一个任务对应一个数据节点，一个数据节点包括：当前数据节点ID、前一个数据节点ID、后一个数据节点ID和任务。

运行状态任务队列存储单元，用于将运行状态任务队列按照运行状态任务顺序存储至键值型嵌入式数据库链表的第二数据节点。

在一些可选的实施方式中，装置还包括：

第一转移模块，用于在排队状态任务队列中的任务需转移到运行状态任务队列的情况下，利用嵌入式数据库提供的事务机制来完成转移。

第二转移模块，用于在运行状态任务队列的任务需转移到结束状态任务队列的情况下，利用预写式日志机制来完成转移。

在一些可选的实施方式中，第二转移模块包括：

需转移的任务获取单元，用于获取运行状态任务队列中需转移的任务。

需转移的任务写入单元，用于将需转移的任务写入结束状态队列缓冲区。

任务写入单元，用于将结束状态队列缓冲区的任务写入全功能数据库。

任务删除单元，用于将结束状态队列缓冲区的任务删除。

在一些可选的实施方式中，任务队列恢复模块606包括：

任务队列恢复子单元，用于在任务集群需要重启或是遭遇故障恢复的情况下，按照正在运行状态任务队列、等待调度状态任务队列、结束运行状态任务队列缓冲区的恢复顺序进行任务队列恢复。

在一些可选的实施方式中，装置还包括：

任务更新模块，用于响应于任务更新操作，获取待更新任务对应的数据节点ID，基于待更新任务对应的数据节点ID对待更新任务进行更新。

任务检索模块，用于响应于任务检索操作，获取待检索任务对应的数据节点ID，基于待检索任务对应的数据节点ID对待检索任务进行检索。

任务插入模块，用于响应于任务插入操作，获取虚节点的位置，基于虚节点的位置完成待插入任务的插入。

任务删除模块，用于响应于任务删除操作，获取待删除任务对应的数据节点ID，基于待删除任务对应的数据节点ID对待删除任务进行删除。

上述各个模块和单元的更进一步的功能描述与上述对应实施例相同，在此不再赘述。

本实施例中的任务队列管理装置是以功能单元的形式来呈现，这里的单元是指ASIC(Application Specific Integrated Circuit，专用集成电路)电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。

本发明实施例还提供一种基于多级存储的高性能抗故障任务队列系统，图7是根据本发明实施例的基于多级存储的高性能抗故障任务队列系统的示意图。如图7所示，系统包括：主控节点和计算节点，主控节点用于执行上述实施例示出的方法。

Slurm是目前高性能计算领域最广泛使用的任务调度系统，具有高可伸缩和容错性，功能丰富，但由于使用C语言编写，代码量庞大，面临代码逻辑复杂、代码耦合度高及不易于维护及参与开发的问题。因此，我们从高性能计算任务调度的最基本需求出发，将Slurm现有功能进行提炼、拆分，重新进行系统架构设计，提出一种基于多级存储的高性能抗故障任务队列系统。

其中，该基于多级存储的高性能抗故障任务队列系统为鹤思任务调度系统(CraneSched)。下文将使用CraneSched指代鹤思任务调度系统。

由于本发明任务队列管理方法通过主控节点来执行，因此对系统中计算节点在此不进行具体描述。

在一些可选的实施方式中，主控节点包括：高并发抗故障任务管理模块、智能任务调度模块、账户权限管理模块、节点状态管理模块及跨节点资源安全模块。

高并发抗故障任务管理模块，用来处理任务提交、管理任务队列情况，将不同状态任务在不同队列中维护，以此均摊针对不同状态任务的不同需求产生的查询或维护数据结构的压力。

智能任务调度模块，用来对排队状态任务进行智能化调度。

账户权限管理模块，用来提供对于不同用户的信息和权限管理功能。

节点状态管理模块，用来对节点进行状态监控和进行安全通信。

跨节点资源安全模块，用来对在各个计算节点上执行的任务进行追踪和资源限制。

计算节点包括计算守护进程，用于执行任务和实施资源限制。

本发明的任务队列管理方法通过高并发抗故障任务管理模块执行，主要分为3个部分：1.多级任务缓存，即任务信息一共有内存、嵌入式数据库、全功能数据库三级存储结构，通过多级存储提供整体任务队列操作的高并发性能；2.一致性保障算法，保证任务信息在多级缓存存储结构之间进行移动时，数据库在故障重启后仍能保持内部信息正确自洽，不出现致命性错误；3.故障恢复机制，使得主控节点遭遇突发性故障重启之后，能正确基于重启后计算节点的任务运行情况和多级缓存队列恢复后的任务信息重建各个任务队列。

以下通过性能测试来描述利用本发明任务队列管理方法之后，在面临高并发压力时，CraneSched系统的响应速度。

其中，测试在250个物理机上进行，系统环境为CentOS 7.9，其中每个物理节点上有两个型号为Intel(R)Xeon(R)Gold 6458Q的CPU(64核心)，内存容量为512GB。在每个物理节点通过mininet模拟出40个虚拟节点，计算节点总量为10000。

测试时通过CraneSched的前端提交任务指令cbatch持续提交任务，将任务队列中的数量维持在不同量级进行测试，并测量不同指令提交的时延，此指标可以反应任务队列系统在高负载时的响应速度。示例性地，表1示出不同负载下CraneSched指令的时延。

表1

其中cbatch、ccancel涉及不同队列的写操作，其他指令为只读操作。示例性地，图8是根据本发明实施例的不同负载下CraneSched指令的时延关系图。如图8所示，CraneSched对于队列的写操作指令在高负载情况下表现良好，时延和任务数量的关系基本为线性上升；对于队列读操作的时间和任务数量基本无关，总是维持在一个很低的水平，其中，表1中作业数为任务数量。

经上述性能测试可知，鹤思系统的任务队列管理的吞吐量，已经在高压力提交和调度方面超过Slurm系统的吞吐量。

本发明实施例还提供一种计算机设备，具有上述图6所示的任务队列管理装置。

请参阅图9，图9是本发明可选实施例提供的一种计算机设备的结构示意图，如图9所示，该计算机设备包括：一个或多个处理器901、存储器902，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相通信连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在计算机设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在一些可选的实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个计算机设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图9中以一个处理器901为例。

处理器901可以是中央处理器，网络处理器或其组合。其中，处理器901还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路，可编程逻辑器件或其组合。上述可编程逻辑器件可以是复杂可编程逻辑器件，现场可编程逻辑门阵列，通用阵列逻辑或其任意组合。

其中，所述存储器902存储有可由至少一个处理器901执行的指令，以使所述至少一个处理器901执行实现上述实施例示出的方法。

存储器902可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据计算机设备的使用所创建的数据等。此外，存储器902可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些可选的实施方式中，存储器902可选包括相对于处理器901远程设置的存储器，这些远程存储器可以通过网络连接至该计算机设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

存储器902可以包括易失性存储器，例如，随机存取存储器；存储器也可以包括非易失性存储器，例如，快闪存储器，硬盘或固态硬盘；存储器902还可以包括上述种类的存储器的组合。

该计算机设备还包括通信接口903，用于该计算机设备与其他设备或通信网络通信。

本发明实施例还提供了一种计算机可读存储介质，上述根据本发明实施例的方法可在硬件、固件中实现，或者被实现为可记录在存储介质，或者被实现通过网络下载的原始存储在远程存储介质或非暂时机器可读存储介质中并将被存储在本地存储介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件的存储介质上的这样的软件处理。其中，存储介质可为磁碟、光盘、只读存储记忆体、随机存储记忆体、快闪存储器、硬盘或固态硬盘等；进一步地，存储介质还可以包括上述种类的存储器的组合。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现上述实施例示出的方法。

虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (12)

1.一种任务队列管理方法，其特征在于，所述方法包括：

将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列；

对各任务队列采用多级存储，其中，所述多级存储包括：内存存储、嵌入式数据库存储和全功能数据库存储，所述排队状态任务队列和所述运行状态任务队列均采用内存存储和嵌入式数据库存储，所述结束状态任务队列采用全功能数据库存储；

响应于排队状态任务队列和运行状态任务队列的任务查询请求，在所述内存中获取所查询的任务的信息；

响应于排队状态任务队列和运行状态任务队列的任务状态更改请求，对需更改任务状态的任务进行任务状态更改，并在所述嵌入式数据库中持久化更改后的任务状态；

响应于结束状态任务队列的任务筛选请求，在所述全功能数据库中获取所筛选的任务的信息；

在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。

2.根据权利要求1所述的方法，其特征在于，所述嵌入式数据库为键值型嵌入式数据库，利用哈希表构建出链表，模拟排队状态任务队列结构和运行状态任务队列结构，其中，所述对各任务队列采用多级存储，包括：

将排队状态任务队列按照排队状态任务顺序存储至键值型嵌入式数据库链表中的第一数据节点，其中，一个任务对应一个数据节点，一个数据节点包括：当前数据节点ID、前一个数据节点ID、后一个数据节点ID和所述任务；

将运行状态任务队列按照运行状态任务顺序存储至键值型嵌入式数据库链表的第二数据节点。

3.根据权利要求2所述的方法，其特征在于，所述链表包括：虚节点和数据节点，其中，

所述虚节点包括队列头和队列尾，所述队列头包括队列头节点ID和队列中第一个数据节点ID，所述队列尾包括队列尾节点ID和队列中最后一个数据节点ID。

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

在所述排队状态任务队列中的任务需转移到所述运行状态任务队列的情况下，利用嵌入式数据库提供的事务机制来完成转移；

在所述运行状态任务队列的任务需转移到所述结束状态任务队列的情况下，利用预写式日志机制来完成转移。

5.根据权利要求4所述的方法，其特征在于，所述利用预写式日志机制来完成转移，包括：

获取所述运行状态任务队列中需转移的任务；

将所述需转移的任务写入结束状态队列缓冲区；

将结束状态队列缓冲区的任务写入所述全功能数据库；

将所述结束状态队列缓冲区的任务删除。

6.根据权利要求1所述的方法，其特征在于，所述在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复，包括：

在任务集群需要重启或是遭遇故障恢复的情况下，按照运行状态任务队列、排队状态任务队列、结束状态任务队列缓冲区的恢复顺序进行任务队列恢复。

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

响应于任务更新操作，获取待更新任务对应的数据节点ID，基于所述待更新任务对应的数据节点ID对所述待更新任务进行更新；

响应于任务检索操作，获取待检索任务对应的数据节点ID，基于所述待检索任务对应的数据节点ID对所述待检索任务进行检索；

响应于任务插入操作，获取所述虚节点的位置，基于所述虚节点的位置完成待插入任务的插入；

响应于任务删除操作，获取待删除任务对应的数据节点ID，基于所述待删除任务对应的数据节点ID对所述待删除任务进行删除。

8.一种任务队列管理装置，其特征在于，所述装置包括：

任务划分模块，用于将任务按照任务状态进行划分，获得排队状态任务队列、运行状态任务队列和结束状态任务队列；

任务队列多级存储模块，用于对各任务队列采用多级存储，其中，所述多级存储包括：内存存储、嵌入式数据库存储和全功能数据库存储，所述排队状态任务队列和所述运行状态任务队列均采用内存存储和嵌入式数据库存储，所述结束状态任务队列采用全功能数据库存储；

任务信息查询模块，用于响应于排队状态任务队列和运行状态任务队列的任务查询请求，在所述内存中获取所查询的任务的信息；

任务状态更改模块，用于响应于排队状态任务队列和运行状态任务队列的任务状态更改请求，对需更改任务状态的任务进行任务状态更改，并在所述嵌入式数据库中持久化更改后的任务状态；

任务信息筛选模块，用于响应于结束状态任务队列的任务筛选请求，在所述全功能数据库中获取所筛选的任务的信息；

任务队列恢复模块，用于在任务集群需要重启或是遭遇故障恢复的情况下，按照预设恢复顺序进行任务队列恢复。

9.一种基于多级存储的高性能抗故障任务队列系统，其特征在于，所述系统包括：主控节点和计算节点，所述主控节点用于执行上述权利要求1-7任一项所述的任务队列管理方法。

10.根据权利要求9所述的基于多级存储的高性能抗故障任务队列系统，其特征在于，主控节点包括：高并发抗故障任务管理模块、智能任务调度模块、账户权限管理模块、节点状态管理模块及跨节点资源安全模块；

高并发抗故障任务管理模块，用来处理任务提交、管理任务队列情况，将不同状态任务在不同队列中维护，以此均摊针对不同状态任务的不同需求产生的查询或维护数据结构的压力；

智能任务调度模块，用来对排队状态任务进行智能化调度；

账户权限管理模块，用来提供对于不同用户的信息和权限管理功能；

节点状态管理模块，用来对节点进行状态监控和进行安全通信；

跨节点资源安全模块，用来对在各个计算节点上执行的任务进行追踪和资源限制；

计算节点包括计算守护进程，用于执行任务和实施资源限制。

11.一种计算机设备，其特征在于，包括：

存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行权利要求1至7中任一项所述的任务队列管理方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机指令，所述计算机指令用于使计算机执行权利要求1至7中任一项所述的任务队列管理方法。