基于服务质量资源的调度方法及装置与流程

1.本公开涉及互联网技术领域，尤其涉及一种基于服务质量资源的调度方法及装置。


背景技术：

2.随着移动互联网云计算的发展，分布式存储技术作为底层技术基石，在多租户模式下能够满足不同租户的存储服务质量需求至关重要。分布式存储系统需要在性能、可靠性等得到保证的前提下，解决对有限的存储空间和输入输出资源进行调度按需分配，满足不同租户的资源服务需求，从而系统整体对外提供更友好的存储服务。因此，如何进行基于服务质量(quality of service，qos)资源的调度且满足不同租户需求的调度公平性，保证不同租户、不同类型的请求对应的响应延迟以及平衡系统的调度开销和整体吞吐对于分布式存储系统来说极其重要。
3.目前，常基于mclock进行调度，针对接收到的每个请求会生成时钟标签，再基于每个请求对应的时钟标签进行调度，当调度了一个请求出队之后，需要更新其他相关的多个请求的时钟标签。采用该方式进行调度生成以及更新时钟标签所需计算开销较大，容易阻塞调度。


技术实现要素：

4.为了解决上述技术问题，本公开提供了一种基于服务质量资源的调度方法及装置。
5.第一方面，本公开提供一种基于服务质量资源的调度方法，包括：
6.获取各租户分别对应的请求队列，并为各所述租户分别对应的请求队列的队首请求生成时钟标签；所述时钟标签包括预留标签、权重标签以及上限标签；其中，客户端用于承载一个或多个租户，服务端用于维护客户端承载的不同租户的请求队列；
7.基于各所述租户分别对应的请求队列中队首请求的时钟标签分别创建预留二叉堆、权重二叉堆以及上限二叉堆；所述预留二叉堆中各树结点对应的时钟标签值为相应队首请求的预留标签值，所述权重二叉堆中各树结点对应的时钟标签值为相应队首请求的权重标签值，所述上限二叉堆中各树结点对应的时钟标签值分别为相应队首请求的上限标签值；
8.基于所述预留二叉堆、所述权重二叉堆以及所述上限二叉堆中各树结点对应的时钟标签值调度目标租户对应的请求队列将队首请求出队，并更新下一个请求为队首请求以及为更新后的队首请求生成时钟标签。
9.在一些实施例中，还包括：基于所述更新后的队首请求的时钟标签调整所述目标租户分别在所述预留二叉堆、所述权重二叉堆以及所述上限二叉堆对应的树结点的位置。
10.在一些实施例中，还包括：
11.接收租户发送的新增请求；
12.若所述租户对应的请求队列为空，则将所述新增请求插入所述租户对应的请求队列中，并基于所述新增请求的到达时间为所述新增请求生成时钟标签；
13.若所述租户对应的请求队列非空，则将所述新增请求插入所述租户对应的请求队列的队尾。
14.在一些实施例中，还包括：
15.基于所述新增请求对应的时钟标签调整所述租户分别在所述预留二叉堆、所述权重二叉堆以及所述上限二叉堆中对应的树结点的位置。
16.在一些实施例中，还包括：
17.获取所述权重二叉堆的根结点的权重标签值；
18.根据所述根结点的权重标签值和当前时间之间的时间差，调整所述新增请求所属租户对应的树结点在所述权重二叉堆中的位置。
19.在一些实施例中，所述生成时钟标签，包括：
20.基于相应队首请求所请求的数据块大小进行归一化处理得到所述队首请求对应的归一化每秒读写次数(input/output operations per second，iops)；
21.根据所述队首请求对应的归一化iops、目标iops以及当前时间戳生成所述队首请求的时钟标签。
22.在一些实施例中，所述生成时钟标签，包括：
23.根据所述队首请求所请求的数据块大小、目标带宽以及当前时间戳生成所述队首请求的时钟标签。
24.在一些实施例中，所述生成时钟标签，包括：基于物理时钟时间戳生成时钟标签。
25.在一些实施例中，所述时钟标签采用有符号的整数数据类型表示。
26.第二方面，本公开提供一种基于服务质量资源的调度装置，包括：
27.获取模块，用于获取各租户分别对应的请求队列；其中，客户端用于承载一个或多个租户，服务端用于维护客户端承载的不同租户的请求队列；
28.时钟标签处理模块，用于并为各所述租户分别对应的请求队列的队首请求生成时钟标签；所述时钟标签包括预留标签、权重标签以及上限标签；
29.二叉堆处理模块，用于基于各所述租户分别对应的请求队列中队首请求的时钟标签分别创建预留二叉堆、权重二叉堆以及上限二叉堆；所述预留二叉堆中各树结点对应的时钟标签值为相应队首请求的预留标签值，所述权重二叉堆中各树结点对应的时钟标签值为相应队首请求的权重标签值，所述上限二叉堆中各树结点对应的时钟标签值分别为相应队首请求的上限标签值；
30.调度模块，用于基于所述预留二叉堆、所述权重二叉堆以及所述上限二叉堆中各树结点对应的时钟标签值调度目标租户对应的请求队列将队首请求出队，并更新下一个请求为队首请求；
31.所述时钟标签处理模块，还用于为更新后的队首请求生成时钟标签。
32.第三方面，本公开提供一种电子设备，包括：存储器和处理器；
33.所述存储器被配置为存储计算机程序指令；
34.所述处理器被配置为执行所述计算机程序指令，使得所述电子设备实现如第一方面以及第一方面任一项所述的基于服务质量资源的调度方法。
35.第四方面，本公开提供了一种可读存储介质，包括：计算机程序指令；电子设备的至少一个处理器运行所述计算机程序指令，使得所述电子设备实现如第一方面以及第一方面任一项所述的基于服务质量资源的调度方法。
36.第五方面，本公开提供了一种计算机程序产品，电子设备运行所述计算机程序产品，使得所述电子设备实现如第一方面以及第一方面任一项所述的基于服务质量资源的调度方法。
37.本公开提供一种基于服务质量资源的调度方法及装置，其中，该方法通过获取各租户对应的请求队列，并为各请求队列的队首请求生成时钟标签，再基于各请求队列的队首请求生成时钟标签创建预留二叉堆、权重二叉堆以及上限二叉堆；再基于预留二叉堆、权重二叉堆以及上限二叉堆调度目标租户的队首请求出队，并更新下一个请求为队首请求以及为更新后的队首请求生成时钟标签。采用本公开的方法，每个租户对应的请求队列的队首请求生成时钟标签，与传统为每个请求生成时钟标签相比，大大减小了生成时钟标签计算开销；此外，在调度一个请求出队之后，为更新的队首请求生成时钟标签，无需如传统方式中修改该租户的请求队列中所有请求的时钟标签，大大降低了更新时钟标签带来的计算开销。
附图说明
38.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
39.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
40.图1为本公开一实施例提供的基于服务质量资源的调度方法的流程示意图；
41.图2为本公开提供的二级映射队列的结构示意图；
42.图3为基于图2所示的二级映射队列构建的预留二叉堆、权重二叉堆以及上限二叉堆的结构示意图；
43.图4为本公开另一实施例提供的基于服务质量资源的调度方法的流程示意图；
44.图5为本公开另一实施例提供的基于服务质量资源的调度方法的流程示意图；
45.图6为本公开一实施例提供的基于服务质量资源的调度装置的结构示意图。
具体实施方式
46.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
47.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
48.目前常采用mclock算法进行qos调度，为了更加清楚，这里首先对基于mclock算法的qos调度进行详细介绍：
49.从逻辑结构上mclock划分为客户端(client)和服务端(server)两部分。
50.客户端：表示某个或者某类客户端，驻留在实际的客户端或者服务端，客户端负责租户qos参数的下发、收集请求的完成信息等等，qos参数包括该租户对应的id、预留配额、权重配额、上限配额等，基于三个配额参数从而实现限高保低和权重调度。
51.服务端：完成具体的输入输出调度，且服务端会针对每个租户维护一请求队列。其中，服务端会为接收到的请求生成时钟标签，包括：预留标签(r标签)、权重标签(p标签)以及上限标签(l标签)，通过公式(1)生成时钟标签，公式(1)如下所示：
[0052][0053]
公式(1)中，上标r表示租户的第r个请求，currenttime表示请求到达的时间，基于公式(1)可知，某个租户第r各请求对应的预留标签、权重标签以及上限标签是基于第r-1个请求对应的预留标签、权重标签以及上限标签生成。其中，对于该租户的第1个请求的时钟标签初始设定为该请求的到达时间。
[0054]
参阅上述公式(1)可知，预留标签是基于请求的预留配额为请求分配的时间标签，权重标签是基于请求的权重配额为请求分配的时间标签，上限标签基于请求的上限配额为请求分配的时间标签；其中，预留配额表示服务端需要提供的最低的资源；上限配额表示服务端可以为请求提供的最高的资源上限；权重配额表示在服务端满足所有请求的预留配额的情况下处理未达到上限配额的请求时请求所占用的资源比例。通过上述公式(1)可以将预配额、权重配额以及上限配额通过时间表示。因此，预留标签相当于表示了请求对应的预留配额所占用的时间长度；权重标签相当于表示了请求对应的权重配额所占用的时间长度；上限标签相当于表示了请求对应的上限配额所占用的时间长度。以iops为例，某个请求的预留配额可以为1000iops，上限配额可以为2000iops，权重配额可以为3，其中，权重配额所对应的数值越大，表示其所占用的资源比例越高。预留配额和上限配额还可以通过带宽表示。
[0055]
在分布式场景下，可通过公式(2)生成请求的时钟标签，公式(2)如下所示：
[0056][0057]
在分布式场景下，客户端会记录每个服务器完成的请求个数，在向服务器下发租户对应的请求时，携带距离上次下发请求以来收到完成的请求个数的增量，并且是除目标服务器之外，其他服务器完成的请求数之和，其中，ρ表示距上次请求预留阶段的增量，δ表示距上次请求完成的所有增量。
[0058]
采用mclock算法进行基于qos资源的调度分为两个阶段调度：预留阶段和权重阶段。
[0059]
预留阶段：查询r标签值小于或等于currenttime的请求进行调度。
[0060]
权重阶段：预留阶段所有符合约束的请求调度完成后进入权重阶段，在l标签值小
于或等于currenttime的请求集合中选择p标签值最小的请求进行调度，当一个租户的请求在权重阶段被调度，当前队列中所有该租户的请求的预留标签值需要减去1/ri，这样该租户的预留配额不会被权重部分影响，确保调度公平性。
[0061]
其中，在预留阶段和权重进行调度时这里的currenttime(当前时间)是指调度时间，是真正进行调度时的时间戳，与请求到达的时间无关。
[0062]
需要强调的是，由于权重标签值是相对的，因此，当有新增租户加入或者已存在的客户端从空闲恢复至活跃，每当新增请求到来，需要对所有租户的请求的p标签值进行校准调整，具体需要对每个请求的p标签值加上一个差值，这个差值为当前时间与最小p标签值之间的差，确保所有租户请求的调度公平性，避免该活跃租户的请求调度产生饥饿。
[0063]
采用mclock算法进行基于qos资源的调度，至少存在以下问题：
[0064]
1、在权重阶段每当调度了一个请求，需要对该租户的所有请求的预留标签值进行调整，当租户的请求数量较大，调整预留标签值必然开销很大，可能会阻塞调度，从而会阻塞所有的请求，进而导致所有租户的请求延迟和整体吞吐均无法保证。
[0065]
2、有新增租户或者已存在的租户从空闲恢复至活跃时，需要校准调整所有请求的权重标签值，开销也必然很大。
[0066]
3、每个租户的工作负载(workload)较为复杂，所请求的数据块大小常常波动较大，如何据此衡量输入输出资源的消耗，统一处理会导致调度公平性较差。
[0067]
4、调度器的开销和吞吐是评估调度效果最重要的基础保障，基于传统的mclock算法进行调度无法方便直观地评估调度器的调度效果。其中，调度器可以理解为服务端中具体执行基于qos资源的调度的功能模块。
[0068]
基于上述问题，本公开提供一种基于服务质量资源的调度方法及装置，其中，采用本公开的方法，服务端会为每个租户对应的请求队列的队首请求生成时钟标签，与传统为每个请求生成时钟标签相比，大大减小了生成时钟标签计算开销；此外，在调度一个请求出队之后，服务端为更新的队首请求生成时钟标签，无需如传统方式中修改该租户的请求队列中所有请求的时钟标签，大大降低了更新时钟标签带来的计算开销。
[0069]
需要说明的是，在传统的mclock算法以及dmclock算法中，一个客户端可以理解为一个租户，而本公开提供的方法中，租户为逻辑租户，一个客户端可以承载一个或多个租户，其中，可以预先将请求进行分类，客户端发送的统一的一类请求对应一个租户，客户端会在发送请求时携带租户的标识，服务端在进行调度时是以租户为单位进行调度。
[0070]
示例性地，本公开提供的基于服务质量资源的调度方法可以由本公开提供的基于服务质量资源的调度装置执行，基于服务质量资源的调度装置可通过任意的软件和/或硬件的方式实现。例如，可以但不限于为：服务器、物联网服务器、云服务器、服务器集群等电子设备，本公开对电子设备的类型不做限定。
[0071]
接下来将通过几个具体实施例对本公开提供的基于服务质量资源的调度方法进行详细介绍。下述实施例中，以基于服务质量资源调度装置(以下简称为调度器)为例进行举例说明。
[0072]
图1为本公开一实施例提供的基于服务质量资源的调度方法的流程示意图。请参阅图1所示，本实施例的方法包括：
[0073]
s101、获取各租户分别对应的请求队列，并为各所述租户分别对应的请求队列的
队首请求生成时钟标签，所述时钟标签包括预留标签、权重标签以及上限标签。
[0074]
其中，调度器的实现包含两级映射队列，其中，第一级为依客户端创建的客户端队列，每个客户端可以承载一个或者多个租户，因此，第一级也可以理解为是依客户端所承载的租户建立的租户队列，第二级为服务端侧真实的请求队列，其中，本公开中以单个租户的请求队列为标识。调度器可以为每个租户的请求队列的队首请求生成三个时钟标签，分别为预留标签ri、权重标签wi以及上限标签li，其中，下标i表示队首请求所属租户的编号，用于标识租户。
[0075]
示例性地，如图2所示，假设有5个租户，分别为租户1至租户5，依客户端承载的租户会创建第一级队列；假设租户1和租户2各自分别发送了4个请求，租户3至租户5的请求队列类似，图2中未示出租户3至租户5的请求队列，此外，租户1至租户5分别对应的请求队列中队首请求包含相应时钟标签，位于队首请求之后的其他请求无时钟标签，请继续参阅图2所示，租户1对应的三个时钟标签分别为(r1，w1，l1)，租户2对应的三个时钟标签分别为(r2，w2，l2)，图2中未示出租户3至租户5分别对应的请求队列的时钟标签。
[0076]
其中，调度器接收到某个租户的队首请求时，可以将队首请求中携带的qos参数代入前文所述的公式(1)或者公式(2)得到队首请求对应的时钟标签。
[0077]
s102、基于各租户分别对应的请求队列中队首请求的时钟标签分别创建预留二叉堆、权重二叉堆以及上限二叉堆。
[0078]
调度队列采用二叉堆实现的优先级队列来组织管理，且二叉堆的底层基于缓存友好的线性结构存储实现，建堆方式对小堆顶，分别构建预留二叉堆、权重二叉堆和上限二叉堆。其中，预留二叉堆、权重二叉堆和上限二叉堆中的树结点均指向一租户对应的请求队列，树结点在相应二叉堆中的位置基于队首请求的时钟标签值确定。
[0079]
1、预留二叉堆：创建预留二叉堆时，基于租户对应的请求队列的队首请求的预留标签值的大小确定租户对应的树结点在二叉堆中的位置，其中，预留标签值越小，则租户对应的树结点位置越靠近根结点，预留标签值越大，则租户对应的树结点位置越靠近叶子结点。预留二叉堆的根结点对应的预留标签值最小。
[0080]
2、权重二叉堆：创建权重二叉堆时，依上限标签值和权重标签值共同决定租户对应的树结点在权重二叉堆中的位置。其中，权重二叉堆中的所有树结点包含一个代表是否满足出队条件的ready标签，ready标签基于队首请求的上限标签值确定，若上限标签值小于或等于当前时间，则ready标签为ture，若上限标签值大于当前时间，则ready标签值为false；权重标签值越小且ready标签为ture的租户对应的树结点在权重二叉堆中的位置越靠近根结点，权重标签值越大且ready标签为false的租户对应的树结点在权重二叉堆中的位置越靠近叶子结点。权重二叉堆的根结点对应的权重标签值最小。
[0081]
3、上限二叉堆：创建上限二叉堆时，依上限标签值决定租户对应的树结点在上限二叉堆中的位置。上限二叉堆中的所有树结点包含一个代表是否满足出队条件的ready标签(与权重二叉堆的结点上的ready标签一致)，上限标签值越小的租户对应的树结点在上限二叉堆中的位置越靠近根结点，上限标签值越大的租户对应的树结点在上限二叉堆中的位置越靠近叶子结点。上限二叉堆的根结点对应的上限标签值最小。
[0082]
示例性地，图3示出了基于图2所示的二级映射队列创建的预留二叉堆、权重二叉堆以及上限二叉堆的结构示意图，参阅图3所示位于最左侧的二叉堆为预留二叉堆，位于中
间的二叉堆为权重二叉堆，位于最右侧的二叉堆为上限二叉堆，预留二叉堆中各树结点的时钟标签值为相应队首请求的预留标签值，权重二叉堆中各树结点的时钟标签值为相应队首请求的权重标签值，上限二叉堆中各树节点的时钟标签值为相应队首请求的上限标签值。观察图3所示的三个二叉堆，可知，由于租户的请求队列中队首请求对应的预留标签值、权重标签值以及上限标签值不同，因此，同一租户在不同二叉堆中的所对应的树结点的位置是不同的。
[0083]
s103、基于预留二叉堆、权重二叉堆以及上限二叉堆中各树结点对应的时钟标签值调度目标租户对应的请求队列的队首请求出队，并更新下一个请求为队首请求以及为更新后的队首请求生成时钟标签。
[0084]
调度请求出队，即选择合理的租户，并从其请求队列中取走队首元素的过程。结合前文mclock算法的介绍可知，调度分为两阶段：预留阶段和权重阶段。
[0085]
预留阶段：遍历预留二叉堆，从根结点开始，判断预留二叉堆中的各树结点的队首请求的预留标签值是否小于或等于当前时间(调度时间)，以此作为是否满足出队条件的依据，如果满足，则确定相应结点对应的租户为目标租户，并调度目标租户对应的请求队列中的队首请求出队。
[0086]
权重阶段：从上限二叉堆的根结点开始，遍历各树结点上的队首请求的上限标签值是否小于或等于当前时间(调度时间)，即基于上限标签值判断是否满足出队条件，并设置满足出队条件的ready标签为true，以决定其是否可以参与随后的权重竞争，该遍历直至根结点不满足出队条件。其中，权重竞争是指对所有满足上限条件(ready标签为true)的租户，依据其队首请求的权重标签值，调整租户对应的树结点在权重二叉堆中的位置的过程，最终位于权重二叉堆根结点的租户胜出成为目标租户，最后调度目标租户的请求队列的队首请求出队。
[0087]
需要说明的是，胜出的租户在上限二叉堆中的树结点的位置调整和在权重二叉堆中的树结点的位置调整是同步进行的，即基于上限标签值对租户对应的树结点逐个判断时同步调整该租户对应的树结点在权重二叉堆中的位置，最终权重二叉堆中符合出队条件的树结点都上移至上层，最后从权重二叉堆中选择符合出队条件的目标租户对应的结点(即根结点)，并将目标租户对应的结点的队首请求出队。
[0088]
在调度目标租户的队首请求出队之后，目标租户的请求队列会发生变化，在队首请求出队之后，若请求队列非空，则请求队列中与已经出队的队首请求相邻的下一个请求会成为该请求队列新的队首请求，因此，需要为更新后的队首请求生成时钟标签，调度器可以采用前述公式(1)或者公式(2)将相关qos参数代入公式生成更新后的队首请求的时钟标签。
[0089]
本实施例的方法，通过为各租户对应的请求队列的队首请求生成时钟标签，与传统为每个请求生成时钟标签相比，大大减小了生成时钟标签计算开销；此外，在调度一个请求出队之后，为更新的队首请求生成时钟标签，无需如传统方式中修改该租户的请求队列中所有请求的时钟标签，大大降低了更新时钟标签带来的计算开销。
[0090]
在图1所示实施例中，步骤s101以及步骤s103中均涉及到生成时钟标签，本公开提供的方法，为队首请求生成时钟标签采用物理时钟时间戳进行计算，且时间戳可以采用精度更高的纳秒级的时间戳，以适配面向微秒级延迟的分布式存储系统。
[0091]
其中，物理时钟对应的真实世界的时间，通常可以由操作系统提供，以物理时钟时间戳来计算请求的时钟标签，可观测性更好，可读性更高，对于评估调度器的调度效果和问题排查也十分友好方便。
[0092]
此外，生成的时钟标签可以采用整型(int)数据类型表示，例如，int 64。采用整型数据类型表示，相对浮点数标识，对cpu更友好开销更小，能够提高时钟标签生成效率。
[0093]
图4为本公开另一实施例提供的基于服务质量资源的调度方法的流程示意图。请参阅图4所示，本实施例提供的方法在图1所示实施例的基础上，步骤s103之后，还包括：
[0094]
s104、基于所述更新后的队首请求的时钟标签调整目标租户在预留二叉堆、权重二叉堆以及上限二叉堆中对应的树结点位置。
[0095]
预留二叉堆、权重二叉堆以及上限二叉堆中的树结点并不是孤立的，而是指向同一个租户的请求队列，从任何一个租户对应的请求队列出队一个队首请求后，由于队首请求改变导致相应租户对应的树结点的时钟标签发生变化，都会影响租户对应的树结点在三个二叉堆中的位置。因此，出队一个队首请求后需要调整目标租户对应的树结点(根结点)分别在预留二叉堆、权重二叉堆以及上限二叉堆中的结点位置。
[0096]
具体调整如下：
[0097]
在预留阶段出队一个请求，需要调整租户对应的树结点在预留二叉堆中的位置，做小顶堆调整，也需要对该租户在权重二叉堆以及上限二叉堆中的树结点做小顶堆调整。即，在预留节点出队目标租户的队首请求之后，需要调整目标租户分别在预留二叉堆、权重二叉堆以及上限二叉堆中所对应的树结点的位置。
[0098]
在权重阶段出队了一个请求，需要调整租户对应的树结点在权重二叉堆中的位置，也需要考虑对预留二叉堆产生的影响，传统方式中，需要将出队的该租户对应的请求队列内持有的所有请求的预留标签值减去1/ri的时间间隔，并调整该租户对应的树结点至合适的位置。通过减去1/ri的时间间隔，保证预留配额不受权重配额影响，确保预留配额的调度公平性，防止该租户在预留阶段可能导致饥饿。
[0099]
而本实施例中，无需对该租户对应的请求队列内持有的所有请求全部进行调整，优先对该租户的队首请求的预留标签值进行更新，开销极小，更新队首请求的预留标签值后，并调整该租户的队首请求所对应的结点在预留二叉堆中的位置。即本实施例中，在权重阶段出队目标租户的队首请求之后，基于更新后的队首请求的权重标签值和上限标签值分别调整目标租户在权重二叉堆和上限二叉堆中所对应的树结点的位置，并将更新后的队首请求的预留标签值减去1/ri的时间间隔，再调整目标租户在预留二叉堆中对应的树结点的位置。
[0100]
相比而言，传统的方式需要更新该租户对应的请求队列内持有的所有请求的预留标签值，采用本公开的方法，更新队首请求的预留标签值即可，开销极小，在该租户的请求数量较大时，效果更加明显。
[0101]
本实施例，通过在调度租户的队首请求出队之后，为更新后的队首请求生成时钟标签，基于新生成的时钟标签及时更新目标租户分别在预留二叉堆、权重二叉堆以及上限二叉堆中对应的树结点的位置，由于优先对租户的队首请求的时钟标签值进行更新用于调整其在预留二叉堆、权重二叉堆以及上限二叉堆中的位置，开销极小。
[0102]
图1至图4所示实施例主要介绍了如何调度请求出队以及在出队一个请求之后对
三个二叉堆进行调整更新的实现方式。接下来将通过图5所示实施例介绍如何入队接收到的请求。
[0103]
图5为本公开另一实施例提供的基于服务质量资源的调度方法的流程示意图。请参阅图5所示，本实施例的方法包括：
[0104]
s501、接收租户发送的新增请求。
[0105]
新增请求携带租户的id以及qos参数。接收到新增请求后，需要基于租户的id将新增请求添加至租户对应的请求队列中，因此，首先先判断租户对应的请求队列是否为空，若租户对应的请求队列为空，则执行步骤s502；若租户对应的请求队列非空，则执行步骤s503。
[0106]
s502、将所述新增请求插入所述租户对应的请求队列中，并基于所述新增请求的到达时间为所述请求生成时钟标签。
[0107]
其中，若发送新增请求的租户为新增租户，则需要在二级映射队列的第一级队列中添加新增租户，且生成第二级的请求队列，并将该新增请求插入该租户的请求队列中，新增请求即为该租户的请求队列中的队首请求。若发送新增请求的租户的所有请求已被全部调度出队，二级映射队列的第一级队列中包含该租户，但该租户对应的第二级的请求队列为空，将该新增请求插入相应请求队列中即可，新增请求即为该租户的请求队列中的队首请求。
[0108]
之后，调度器可以基于前文所述的公式(1)或者公式(2)为该新增请求生成时钟标签。类似地，可以采用物理时钟时间戳生成时钟标签，且时钟标签采用整数数据类型表示。
[0109]
s503、将新增请求插入所述租户对应的请求队列的队尾。
[0110]
由于该租户对应的请求队列中存在未被调度出队的请求，因此，将新增请求插入相应请求队列的队尾即可，且调度器无需为新增请求生成时钟标签，保证该请求队列的队首请求的时钟标签是就绪的即可。
[0111]
当接收到新增请求时，通过将新增请求入队，并在新增请求对应的租户的请求队列为空时，为作为队首请求的新增请求生成时钟标签，能够大大减小生成时钟标签的计算开销。
[0112]
在图5所示实施例的基础上，可选地，s503之后，还可以包括：
[0113]
s504、基于新增请求对应的时钟标签调整所述租户分别在预留二叉堆、权重二叉堆以及上限二叉堆中所对应的树结点的位置。
[0114]
若发送新增请求的租户为新增租户，则需要将该新增租户作为一个新结点加入预留二叉堆、权重二叉堆以及上限二叉堆中，新结点先插入二叉堆尾部，再基于该租户对应的队首请求(即新增请求)的时钟标签将新结点调整至合适的位置。针对预留二叉堆，调整时，以新结点的队首请求的预留标签值为依据，做小顶堆调整，最终根结点的预留标签值最小；针对权重二叉堆，该二叉堆中的树结点有两种状态，可基于ready标签区分，对新结点的位置进行调整时，首先确定队首请求的ready标签的状态，分别以满足出队条件(ready标签为true)、权重标签值大小的优先顺序做小顶堆调整；针对上限二叉堆，以不满足出队条件(ready标签为false)、上限标签值大小的优先顺序做小顶堆调整。
[0115]
若发送新增请求的租户为已有租户，且该租户对应的请求队列为空，则三个二叉堆中会存在该租户对应的树结点，基于新增请求对应的时钟标签的值调整租户对应的树结
点在三个二叉堆中的位置即可，调整方式与基于新增租户的时钟标签调整树结点在二叉堆中的位置类似，简明起见，此处不再赘述。
[0116]
若发送新增请求的租户的请求队列非空，请求队列中队首请求的三个时钟标签的值不会发生变化，因此，该情况下，无需调整。
[0117]
可选地，还可以包括：
[0118]
s505、获取权重二叉堆的根结点的权重标签值，根据所述根结点的权重标签值和当前时间得到权重差值。
[0119]
s506、基于所述权重差值对发送新增请求的租户对应权重标签值进行校准，并基于校准的权重标签值调整发送所述新增请求的租户在所述权重二叉堆中所对应的树结点的位置。
[0120]
本公开中，若发送新增请求的租户为新增租户，或者，发送新增请求的租户为已存在的租户，且该租户由空闲恢复至活跃状态，为了保证调度公平性，需要对相关请求的权重标签做校准调整。示例性地，可根据预设时长是否有请求到达作为判断租户空闲或者活跃的条件，预设时长可以配置，如预设时长为5分钟、6分钟等，本公开对于预设时长不作限定。或者，也可以基于其他配置参数确定租户的状态为空闲或者活跃。
[0121]
确定有租户满足上述任一条件时，对该租户对应的权重二叉堆进行调整。首先，获取权重二叉堆的堆顶的队首请求(即根结点的队首请求)的权重标签值，记为min_weight_tag，且根结点对应的租户不是发送新增请求的租户时，计算min_weight_tag与currenttime之间的时间差，该时间差即为权重差值，将时间差加至新增请求对应的租户的队首请求的权重标签值上，对发送新增请求的租户进行调整，将发送新增请求的租户与其他租户拉齐，避免请求饥饿。
[0122]
在另一些实施例中，还可以获取处于权重二叉堆处于上层的多个树结点的权重标签值，计算多个树结点的权重标签值的平均值，再计算得到平均值与当前时间的时间差，该时间差即为权重差值，将时间差加至新增请求对应的租户的队首请求的权重标签值上，对发送新增请求的租户进行调整，将发送新增请求的租户与其他租户拉齐，避免请求饥饿。
[0123]
本公开并不需要如传统方式那样立即对所有请求的权重标签进行调整，而是随着调度过程中权重二叉堆的调整进行，具体地，在进行调整的过程中，由于更新后的队首请求的时钟标签生成会依赖出队的前一个请求，而前一个请求的时钟标签中已经加上了之前计算的时间差，因此，为更新后的队首请求生成时钟标签时相当于也加上了之前计算的时间差，因此不会产生额外的开销。
[0124]
在图1至图5所示实施例中，由于不同请求所请求的io数据块(简称为数据块)大小不同，在带宽限定条件下，大块io数据块相比小块io数据块需要更大的传输延迟，换言之，小块io数据块相比大块io数据块对于延迟更加敏感，因此，需要优先保证小块io数据块的服务质量，避免小块io数据块被大块io数据块阻塞，因此，本公开可以基于请求对应的归一化iops或者请求所需的带宽对时钟标签进行优化调整，保证小块io数据块和大块io数据库的调度顺序更合理化，从而保证不同io大小下的服务质量。
[0125]
1、iops：基于设定的io数据块大小对请求所请求的数据块大小进行归一化处理得到归一化iops，基于归一化iops和qos参数计算时钟标签。可通过如下公式(3)得到基于iops优化后的时钟标签：
[0126][0127]
公式(3)中，n表示归一化iops；rsr、psr、lsr分别表示基于iops优化后的预留标签、权重标签和上限标签；rs、ws、ls分别表示预留标签对应的目标iops、权重标签对应的目标iops、上限标签对应的目标iops；ρ表示距上次请求预留阶段的增量，δ表示其他服务器完成的请求增量。公式(3)中下标i表示租户的编号。
[0128]
在公式(3)中，rs、ws、ls的值可以相同也可以不同，本公开对此不作限定。
[0129]
示例性地，假设小块io数据块定义为iosize小于或者等于8kb，以此为基准对大块io数据块做归一化处理，则1mb的大块io数据块为128倍得小块io数据块对应的iops，上述n取值为128。
[0130]
2、带宽：带宽以所请求的数据块大小进行处理，基于所请求的数据块大小和qos参数计算时钟标签。可通过如下公式(4)得到基于带宽优化后的时钟标签：
[0131][0132]
其中，size表示所请求的数据块大小，rbr、pbr、lbr分别表示基于带宽优化后的预留标签、权重标签和上限标签；rb、wb、lb分别表示预留标签对应的目标带宽、权重标签对应的目标带宽、上限标签对应的目标带宽；ρ表示距上次请求预留阶段的增量，δ表示其他服务器完成的请求增量。公式(4)中下标i表示租户的编号。
[0133]
在公式(4)中，rb、wb、lb的值可以相同也可以不同，本公开对此不作限定。
[0134]
通过将大小数据块所需iops归一化，基于归一化iops对时钟标签进行优化或者基于带宽对时钟标签进行优化，能够实现工作负载自适应，保证不同租户之间、租户自身的调度公平和服务质量。
[0135]
上述图1至图5所示实施例中，为各请求队列的队首请求、更新的队首请求以及新增请求生成时钟标签时，可采用公式(4)或者公式(5)中任一方式实现。
[0136]
在一个具体实施例中，调度器运行在轮询模式(polling模式)时，测试得到的性能开销如下表1所示：
[0137]
表1
[0138][0139]
其中，有效出队表示本次调度拿到请求。p50表示50分位的延迟，p99和p999分别表
示99％和99.9％分位的延迟。
[0140]
结合表1所示的数据可知，本公开提供的基于服务质量资源的调度方法能够在多租户模式下，根据针对不同租户设定的预留配额、权重配额、上限配额等配置，实现较好的限高保底的效果，也能够实现按权重调度，不同大小的请求也能够达到自适应，兼顾响应延迟和调度公平。
[0141]
图6为本公开一实施例提供的基于服务质量资源的调度装置的结构示意图。请参阅图6所示，本实施例提供的基于服务质量资源的600包括：
[0142]
获取模块601，用于获取各租户分别对应的请求队列；其中，客户端用于承载一个或多个租户，服务端用于维护客户端承载的不同租户的请求队列。
[0143]
时钟标签处理模块602，用于并为各所述租户分别对应的请求队列的队首请求生成时钟标签；所述时钟标签包括预留标签、权重标签以及上限标签；
[0144]
二叉堆处理模块603，用于基于各所述租户分别对应的请求队列中队首请求的时钟标签分别创建预留二叉堆、权重二叉堆以及上限二叉堆；所述预留二叉堆中各树结点对应的时钟标签值为相应队首请求的预留标签值，所述权重二叉堆中各树结点对应的时钟标签值为相应队首请求的权重标签值，所述上限二叉堆中各树结点对应的时钟标签值分别为相应队首请求的上限标签值。
[0145]
调度模块604，用于基于所述预留二叉堆、所述权重二叉堆以及所述上限二叉堆中各树结点对应的时钟标签值调度目标租户对应的请求队列将队首请求出队，并更新下一个请求为队首请求。
[0146]
所述时钟标签处理模块602，还用于为更新后的队首请求生成时钟标签。
[0147]
在一些实施例中，二叉堆处理模块603，还用于基于所述更新后的队首请求的时钟标签调整所述目标租户分别在所述预留二叉堆、所述权重二叉堆以及所述上限二叉堆对应的树结点的位置。
[0148]
在一些实施例中，获取模块601，还用于接收租户发送的新增请求，以及，若所述租户对应的请求队列为空，则将所述新增请求插入所述租户对应的请求队列中，并基于所述新增请求的到达时间为所述新增请求生成时钟标签；若所述租户对应的请求队列非空，则将所述新增请求插入所述租户对应的请求队列的队尾。
[0149]
在一些实施例中，二叉堆处理模块603，还用于基于所述新增请求对应的时钟标签调整所述租户分别在所述预留二叉堆、所述权重二叉堆以及所述上限二叉堆中对应的树结点的位置。
[0150]
在一些实施例中，二叉堆处理模块603，还用于获取所述权重二叉堆的根结点的权重标签值；根据所述根结点的权重标签值和当前时间之间的时间差，调整所述新增请求所属租户对应的树结点在所述权重二叉堆中的位置。
[0151]
在一些实施例中，时钟标签处理模块602，具体用于基于相应队首请求所请求的数据块大小进行归一化处理得到所述队首请求对应的归一化每秒读写次数；以及，根据所述队首请求对应的归一化iops、目标iops以及当前时间戳生成所述队首请求的时钟标签。
[0152]
在一些实施例中，时钟标签处理模块602，具体用于根据所述队首请求所请求的数据块大小、目标带宽以及当前时间戳生成所述队首请求的时钟标签。
[0153]
在一些实施例中，时钟标签处理模块602，具体用于基于物理时钟时间戳生成时钟
标签。
[0154]
在一些实施例中，所述时钟标签采用有符号的整数数据类型表示。
[0155]
本实施例提供的基于服务质量资源的调度装置可以用于实现前述任一方法实施例的技术方案，其实现原理以及技术效果类似，可参照前述方法实施例的详细描述，简明起见，此处不再赘述。
[0156]
示例性地，本公开提供一种电子设备，包括：一个或多个处理器；存储器；以及一个或多个计算机程序；其中一个或多个计算机程序被存储在存储器中；一个或多个处理器在执行一个或多个计算机程序时，使得电子设备实现前文实施例的基于服务质量资源的调度方法。
[0157]
示例性地，本公开提供一种芯片系统，芯片系统应用于包括存储器、传感器的电子设备；芯片系统包括：处理器；当处理器执行前文实施例的基于服务质量资源的调度方法。
[0158]
示例性地，本公开提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器使得电子设备执行时实现前文实施例的基于服务质量资源的调度方法。
[0159]
示例性地，本公开提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行前文实施例的基于服务质量资源的调度方法。
[0160]
在上述实施例中，全部或部分功能可以通过软件、硬件、或者软件加硬件的组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本公开实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如，固态硬盘(solid state disk，ssd))等。
[0161]
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0162]
以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。