CN106209682B - 业务调度方法、装置和系统 - Google Patents

Abstract

本申请公开了业务调度方法、装置和系统。所述方法的一具体实施方式包括：监测等待队列中是否存在业务请求，其中等待队列用于存储待执行的业务请求；响应于确定等待队列中存在业务请求，交换运行队列和等待队列，其中运行队列用于存储当前执行的业务请求；将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过业务处理接口对待处理请求集合进行批量处理；在待处理请求集合中的业务请求处理完毕后，清空交换后的运行队列。该实施方式能够根据业务需求和硬件处理能力自适应调整批处理数量，提升了业务处理效率。

Description

业务调度方法、装置和系统

技术领域

本申请涉及计算机技术领域，具体涉及计算机资源的分配和调度技术领域，尤其涉及业务调度方法、装置和系统。

背景技术

随着计算机网络技术的发展，各类网络业务的数据规模不断增长，业务调度机制在很大程度上影响着业务的处理效率。DNN(Deep Neural Network，深度神经网络)模型可以用于大规模数据的预测业务。这类业务请求并发高，实时性要求高，计算量大，通常利用异构硬件对业务请求进行批处理。在这种调度架构中，按照预先配置的批处理数量将业务请求合并后利用异构硬件进行处理，预先配置的批处理数量与业务的实时性需求和异构硬件的计算能力相关。

然而，由于FPGA(Field－Programmable Gate Array，现场可编程门阵列)/GPU(Graphics Processing Unit，图形处理器)的硬件架构限制，目前的异构硬件无法同时执行多个任务，即业务的多线程并不能提升硬件的效率。而基于上述预先配置的批处理数量对预测业务请求进行处理的方式具有以下缺点：每一类业务都需要增加一个调度层，用于将业务请求合并后统一向异构硬件发起请求，增加了业务使用的难度；在QPS(Query PerSecond，每秒查询率)较小时，批处理数量固定使得请求数必须达到一定数量或达到一定的延时才能进行处理，在等待请求的过程中硬件处于空闲状态，导致资源浪费；在QPS较大时，能够同时处理的业务请求数最大为批处理数量，而异构硬件对大规模请求合并处理的效率远高于依次处理每个请求的效率，因此预先配置批处理数量的方式在一定程度上降低了计算效率，不利于最大化利用硬件的计算能力和适应业务的实时性需求。

发明内容

有鉴于此，期望能够提供一种最大化利用硬件的计算能力并适应业务的实时性需求的业务调度架构，为了解决上述一个或多个技术问题，本申请提供了业务调度方法、装置和系统。

一方面，本申请提供了一种业务请求的调度方法，包括：监测等待队列中是否存在业务请求，其中等待队列用于存储待执行的业务请求；响应于确定等待队列中存在业务请求，交换运行队列和等待队列，其中运行队列用于存储当前执行的业务请求；将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过业务处理接口对待处理请求集合进行批量处理；在待处理请求集合中的业务请求处理完毕后，清空交换后的运行队列。

在一些实施例中，监测等待队列中是否存在业务请求，包括：监测运行队列中是否存在执行中的业务请求；响应于监测出运行队列中不存在执行中的业务请求，查询等待队列以确定等待队列中是否存在业务请求。

在一些实施例中，交换运行队列和等待队列，包括：将运行队列的指针与等待队列的指针交换。

在一些实施例中，方法还包括：将获取的业务请求添加至交换后的等待队列；在清空运行队列之后，方法还包括：根据请求处理结果判断业务请求是否成功处理；若业务请求未成功处理则以预设时间间隔重复将未成功处理的业务请求添加至交换后的等待队列。

在一些实施例中，业务处理接口部署于具有不同硬件架构的多个设备中。

在一些实施例中，方法还包括：响应于确定等待队列中不存在业务请求，按照预设的时间周期查看等待队列中是否存在业务请求。

在一些实施例中，业务处理接口包括深度神经网络模型的输入接口；在将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口之后，方法还包括：将待处理请求集合转换为输入矩阵；基于深度神经网络模型中的各层间矩阵，利用深度神经网络模型中各层的分类函数对输入矩阵进行计算，得出待处理请求集合的矩阵计算结果。

第二方面，本申请提供了一种业务请求的调度装置，包括：监测单元，用于监测等待队列中是否存在业务请求，其中等待队列用于存储待执行的业务请求；交换单元，用于响应于确定等待队列中存在业务请求，交换运行队列和等待队列，其中运行队列用于存储当前执行的业务请求；合并单元，用于将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过业务处理接口对待处理请求集合进行批量处理；清空单元，用于在待处理请求集合中的业务请求处理完毕后，清空交换后的运行队列。

在一些实施例中，监测单元进一步用于按照如下方式监测等待队列中是否存在业务请求：监测运行队列中是否存在执行中的业务请求；响应于监测出运行队列中不存在执行中的业务请求，查询等待队列以确定等待队列中是否存在业务请求。

在一些实施例中，交换单元进一步用于按如下方式交换运行队列和等待队列：将运行队列的指针与等待队列的指针交换。

在一些实施例中，装置还包括：添加单元，用于将获取的业务请求添加至交换后的等待队列；以及判断单元，用于在清空交换后的运行队列之后，根据请求处理结果判断业务请求是否成功处理，并在业务请求未成功处理时以预设时间间隔重复将未成功处理的业务请求添加至交换后的等待队列。

在一些实施例中，业务处理接口部署于具有不同硬件架构的多个设备中。

在一些实施例中，监测单元还用于：响应于确定等待队列中不存在业务请求，按照预设的时间周期查看等待队列中是否存在业务请求。

在一些实施例中，业务处理接口包括深度神经网络模型的输入接口；装置还包括处理单元，用于：在将运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口之后，将待处理请求集合转换为输入矩阵；以及基于深度神经网络模型中的各层间矩阵，利用深度神经网络模型中各层的分类函数对输入矩阵进行计算，得出待处理请求集合的矩阵计算结果。

第三方面，本申请提供了一种业务调度系统，系统包括：业务接收设备，用于接收业务请求并向调度设备发送业务请求；调度设备，用于监测等待队列中是否存在业务请求，响应于确定等待队列中存在业务请求，交换运行队列和等待队列，将运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理设备的业务处理接口，并在待处理请求组中的业务请求处理完毕后，清空运行队列，其中等待队列用于存储待执行的业务请求，运行队列用于存储当前执行的业务请求；业务处理设备，用于对待处理请求集合进行批量处理，并将处理结果返回调度设备。

本申请提供的业务调度方法、装置和系统，通过监测用于存储待执行的业务请求的等待队列中是否存在业务请求，在确定等待队列中存在业务请求时交换用于存储当前执行的业务请求的运行队列和等待队列，随后将运行队列中的业务请求合并后发送至业务处理接口，以通过业务处理接口对待处理请求集合进行批量处理，最后在待处理请求集合中的业务请求处理完毕后清空运行队列，能够根据业务需求和硬件处理能力自适应调整批处理数量，从而提升了业务处理效率。

附图说明

通过阅读参照以下附图所作的对非限制性实施例详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请可以应用于其中的示例性系统架构图；

图2是根据本申请的业务调度方法的一个实施例的流程图；

图3是根据本申请的业务调度方法中的等待队列和运行队列交换的原理示意图；

图4是根据本申请的业务调度方法的另一个实施例的流程图；

图5是根据本申请的业务调度方法的另一个实施例的原理示意图；

图6是根据本申请的业务调度装置的一个实施例的结构示意图；

图7是根据本申请的业务调度系统的一个实施例的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

如图1所示，系统架构100可以包括业务层设备101、102、103，调度层设备104和处理框架层设备105、106、107。调度层设备104用以对业务层设备101、102、103的业务进行调度并分发至处理框架层设备105、106、107。

业务层设备101、102、103用于根据业务需求生成业务请求并将请求发送至调度层设备104进行分发。不同的业务层设备101、102、103分别对应不同的业务类型，可以分别部署在不同的服务器集群中。

调度层设备104可以根据处理框架层设备105、106、107的硬件计算能力和业务层设备101、102、103的业务需求对业务进行调度，将业务请求分发至对应类型的处理框架层设备105、106、107中。

处理框架层设备105、106、107用于对业务请求进行处理，并向业务层设备101、102、103返回对应的处理结果。

需要说明的是，本申请实施例所提供的业务调度方法一般由调度层设备104执行，相应地，业务调度装置一般设置于调度层设备104中。

应该理解，图1中的业务层设备、调度层设备和处理框架层设备均可以为单一的电子设备，例如服务器，也可以为多个电子设备的集合，例如可以为服务器集群，图1业务层设备、调度层设备和处理框架层设备的数目仅仅是示意性的。根据实现需要，可以具有任意数目的业务层设备、调度层设备和处理框架层设备。

继续参考图2，其示出了根据本申请的业务调度方法的一个实施例的流程200。如图2所示，业务调度方法的流程200包括以下步骤：

步骤201，监测等待队列中是否存在业务请求。

在本实施例中，业务调度方法运行于其上的电子设备(例如图1所示调度层设备104)可以预先创建等待队列和运行队列。其中等待队列用于存储待执行的业务请求。运行队列用于存储当前执行的业务请求。待执行的业务请求可以是业务层设备发送的未分发的业务请求，当前执行的业务请求可以是已分发的业务请求。等待队列和运行队列可以以数组的数据结构存储在上述电子设备中。上述电子设备可以为等待队列和运行队列分配存储地址并设置指针。等待队列的指针指向等待队列中第一个元素(即第一个待执行业务请求)的存储地址，运行队列的指针指向运行队中第一个元素(即第一个当前执行的业务请求)的存储地址。

上述电子设备可以查看等待队列，以监测其中是否存在业务请求。当等待队列中存在业务请求时，当前待执行业务请求的数量大于0，上述电子设备需要将待执行的业务请求分发至对应的硬件设备进行处理。

在一些实施例中，上述电子设备可以获取等待队列的长度，若等待队列的长度大于0，则确定等待队列中存在待执行的业务请求；若等待队列的长度为0，则确定等待队列中不存在待执行的业务请求。

在一些可选的实现方式中，在对等待队列的状态进行监测之前，可以首先监测运行队列的状态，即可以采用如下方式监测等待队列中是否存在业务请求：监测运行队列中是否存在执行中的业务请求；响应于监测出运行队列中不存在执行中的业务请求，查询等待队列以确定等待队列中是否存在业务请求。即在确定运行队列中不存在执行中的业务请求时启动对等待队列的状态的监测。进一步地，可以通过运行队列的长度确定运行队列中是否执行中的业务请求。在实际场景中，若运行队列的长度不为0，则运行队列中存在未处理完成的业务请求，这时，可以不执行对等待队列的监控，待运行队列中的业务请求执行完毕后监测等待队列中是否存在业务请求。

步骤202，响应于确定等待队列中存在业务请求，交换运行队列和等待队列。

在本实施例中，若确定等待队列中存在业务请求，可以交换运行队列和等待队列。这时，等待队列成为交换后的运行队列，交换后的运行队列中的业务请求可以被执行，运行队列成为交换后的等待队列。

具体来说，可以通过将等待队列和运行队列中的元素互换来实现两个队列的交换，例如可以提取出等待队列中的元素，添加至运行队列，并将运行队列中的元素添加至等待队列中。

在一些可选的实现方式中，步骤201中上述电子设备在监测出运行队列中不存在执行中的业务请求时查询等待队列以确定等待队列中是否存在业务请求，即在运行队列为空时才启动对等待队列状态的监测，则在步骤202中可以将等待队列中的业务请求添加至运行队列，并清空运行队列来实现等待队列和运行队列的交换。这时，交换后的等待队列为空，交换后的运行队列中的业务请求可以被执行。

在一些实施例中，等待队列和运行队列均有指向其存储位置的指针，可以将运行队列的指针与等待队列的指针交换，从而实现运行队列和等待队列的交换。在将两个队列的指针互换后，无需对业务调度逻辑进行大幅度的改写，仅增加指针交换的逻辑即可。这样使得业务调度进程的开销较小，能够高效地实现队列的交换。

进一步地，等待队列可以包括队头指针，运行队列也包括队头指针。队头指针指向队列中的第一个元素的存储地址。可以交换等待队列的队头指针和运行队列的队头指针。

请参考图3，其示出了根据本申请的业务调度方法中的等待队列和运行队列交换的原理示意图。如图3所示，队列1为交换前的等待队列，包含业务请求C、D、E，队列2为交换前的运行队列，包含业务请求A和B。等待队列指针指向队列1的第一个元素C，运行队列指针指向队列2的第一个元素A。在交换队列时，将等待队列指针和运行队列指针互换，则交换后等待队列指针指向队列2的第一个元素A，运行队列指针指向队列1的第一个元素C。这时队列1成为运行队列，队列1中的元素C、D、E所表示的业务请求可以被执行，队列2成为等待队列，队列2中的元素A和B所表示的业务请求成为待执行的业务请求。

在一些实施例中，若监测出等待队列中不存在业务请求，即未接收到新的业务请求，上述业务调度方法还可以包括：响应于确定等待队列中不存在业务请求，按照预设的时间周期查看等待队列中是否存在业务请求。也就是说，监测出等待队列中不存在业务请求时，可以休眠一预设时间段，例如100微秒，在预设时间段之后重新监测是否接收到新的业务请求。

步骤203，将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过业务处理接口对待处理请求集合进行批量处理。

在本实施例中，业务处理接口可以是用于对业务请求进行处理的输入接口，可以部署于业务调度方法运行于其上的电子设备中，也可以部署于外部设备中。进一步地，业务处理接口可以部署于具有不同硬件架构的多个设备中。具有不同硬件架构的多个设备可以为FPGA、GPU等，各设备的硬件能力不同，对业务请求的处理效率不相同，但无法同时执行多个计算任务。在本实施例中，可以通过业务处理接口接收业务请求，之后将业务请求合并为一个待处理业务集合，则可以在一个计算任务中对待处理业务集合进行处理，从而实现了多个业务请求同时处理。

在实际场景中，业务处理接口可以部署于已封装业务处理逻辑的平台中。上述平台可以提供对业务处理接口接收到的数据进行业务逻辑的运算，并输出运算结果。

业务处理接口可以支持单个业务请求的处理，也支持多个业务请求的批处理。通常将多个业务请求合并后进行批处理的计算效率远高于单个业务依次执行的计算效率。在现有技术中业务处理接口可接受的批处理数量(batch size)通常为依据业务处理逻辑运行于其上的硬件设备的计算能力和业务的实时性需求所设定的一个固定值。当业务量发生暴涨(即短时间内业务量增长量较大)时无法对batch size进行调整。

在本实施例中，业务处理接口可接收的批处理数量batch size为当前的等待队列中所包含的业务请求的数量。当QPS(Query Per Second，每秒查询率)较高时，等待队列所包含的业务请求的数量较大，此时batch size较大，当QPS较低时，等待队列所包含的业务请求的数量较小，此时batch size较小，由此实现了batch size的自适应调整。

上述电子设备可以将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口。这时业务处理接口接收的batch size为待处理请求集合中的业务请求的数量。

交换后的运行队列中的业务请求可以被合并为一个待处理请求集合，上述已封装业务处理逻辑的平台可以对待处理请求集合进行处理。进一步地，可以利用向量或矩阵等数据形式表示待处理请求集合，利用上述平台提供的业务处理逻辑对合并得到的向量或矩阵进行运算，即可以实现业务请求的批量处理，相较于依次处理每个业务请求的方式，能够明显缩短计算时间，缩短业务请求的处理延时，提升计算效率。

具体来说，上述业务请求可以包括基于DNN模型的多类业务请求，例如包括语音业务请求、图像识别业务请求、内容推送业务请求等，则上述业务处理接口可以包括DNN模型的输入接口。DNN模型可以对输入的矩阵或向量进行多个层级的分类计算，输出分类结果。在进一步的实施例中，在将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口后，上述业务调度方法还包括：将待处理请求集合转换为输入矩阵，基于DNN模型中的各层间矩阵，利用深度神经网络中各层的分类函数对输入矩阵进行计算，得出待处理请求集合的矩阵计算结果。DNN模型一般可以包括多个层，每一层的计算过程是输入的矩阵与该层和上一层之间的连接矩阵相乘，然后利用该层的分类函数进行分类计算，得出该层的隐层矩阵，之后将该层的隐层矩阵作为下一层的输入矩阵，依次进行计算，直至最后一层计算完毕得出的矩阵即为分类结果。其中分类函数可以为激活函数，例如为S型函数sigmod、双曲正切函数tanh、softmax函数等。

步骤204，在待处理请求集合中的业务请求处理完毕后，清空交换后的运行队列。

在通过业务处理接口对待处理请求集合中的业务请求处理完毕后，可以清空当前的运行队列。具体地，可以将运行队列的队头指针和队尾指针均置为初始值。这时，当前的运行队列为空队列，即没有执行中的业务请求。上述电子设备可以在检测到运行队列为空时返回步骤201，立即查询等待队列中是否存在业务请求。

需要说明的是，在本实施例中，执行上述业务调度方法的设备或架构可以独立于发出业务请求的设备。即该业务调度逻辑的部署可以独立于业务请求的生成逻辑，不同类型的业务请求可以利用统一的业务调度逻辑进行调度，由此简化了多类型业务请求并存时业务请求的处理架构，能够提升处理效率。

本实施例所提供的业务调度方法具有以下优势：第一，不需要根据处理业务请求的不同硬件的处理能力和业务请求量等情况设定固定的批处理数量的值，可以在调度过程中根据实际的业务请求量和当前硬件的计算能力确定当前执行的运行队列的长度，即适应性地确定批处理数量，因此发出业务请求的上层设备无需考虑处理业务的硬件架构的计算能力，降低了运维和部署的难度；第二，在调度过程中，监测到等待队列中存在业务请求并且当前运行队列为空时立即交换等待队列和运行队列，并批量处理交换后的运行队列中的业务请求，有效解决了固定的批处理数量由于需要等待固定数量的业务请求导致硬件空闲的问题以及请求量较大以致同时到达的业务请求量超过固定的批注理数量时计算效率无法满足业务需求的问题，提升了硬件计算效率，从而提高了业务处理的实时性。

继续参考图4，其示出了是根据本申请的业务调度方法的另一个实施例的流程图。如图4所示，所述的业务调度方法的流程400，包括以下步骤：

步骤401，监测等待队列中是否存在业务请求。

在本实施例中，业务调度方法运行于其上的电子设备(例如图1所示调度层设备104)可以预先创建等待队列和运行队列。其中等待队列用于存储待执行的业务请求。运行队列用于存储当前执行的业务请求。可以为等待队列和运行队列分配存储地址并设置指针。等待队列的指针指向等待队列中第一个元素(即第一个待执行业务请求)的存储地址，运行队列的指针指向运行队中第一个元素(即第一个当前执行的业务请求)的存储地址。在一些实施例中，可以通过获取等待队列的长度来确定等待队列中是否存在待执行的业务请求，若等待队列的长度为0，则确定等待队列中不存在待执行的业务请求。

在一些可选的实现方式中，可以采用如下方式监测等待队列中是否存在业务请求：监测运行队列中是否存在执行中的业务请求；响应于监测出运行队列中不存在执行中的业务请求，查询等待队列以确定等待队列中是否存在业务请求。即在确定运行队列中不存在执行中的业务请求时启动对等待队列的状态的监测。

步骤402，响应于确定等待队列中存在业务请求，交换运行队列和等待队列。

在本实施例中，若确定等待队列中存在业务请求，可以交换运行队列和等待队列。这时，等待队列成为交换后的运行队列，交换后的运行队列中的业务请求可以被执行，运行队列成为交换后的等待队列。

具体来说，可以通过将等待队列和运行队列中的元素互换来实现两个队列的交换，也可以将运行队列的指针与等待队列的指针交换，从而实现运行队列和等待队列的交换。

步骤403，将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过业务处理接口对待处理请求集合进行批量处理。

在本实施例中，可以通过业务处理接口接收业务请求，之后将业务请求合并为一个待处理业务集合，则可以在一个计算任务中对待处理业务集合进行处理，从而实现了多个业务请求同时处理。业务处理接口可接收的batch size为当前的等待队列中所包含的业务请求的数量。当QPS(Query Per Second，每秒查询率)较高时，等待队列所包含的业务请求的数量较大，此时batch size较大，当QPS较低时，等待队列所包含的业务请求的数量较小，此时batch size较小，由此实现了batch size的自适应调整。

交换后的运行队列中的业务请求可以被合并为一个待处理请求集合，包含上述业务处理接口的已封装业务处理逻辑的平台可以对待处理请求集合进行处理。进一步地，可以利用向量或矩阵等数据形式表示待处理请求集合，利用上述平台提供的业务处理逻辑对合并得到的向量或矩阵进行运算，即可以实现业务请求的批量处理。

步骤404，将获取的业务请求添加至交换后的等待队列。

在通过业务处理接口处理待处理请求的过程中，如果接收到新的业务请求，则可以将新的业务请求添加至交换后的等待队列。

在本实施例中，等待队列和运行队列的队列长度未预先设定，即在添加新的业务请求到当前的等待队列中时，可以将新的业务请求存储至当前等待队列队尾直指针指向的最后一个元素的存储地址的下一个存储地址，并将当前等待队列的队尾指针指向添加的业务请求的存储地址。

需要说明的是，本实施例虽然以特定顺序描述了业务调度方法的流程，但在实际应用中，业务调度方法的流程400中的各步骤的执行顺序可以交换，也可以同时执行其中的两个以上的步骤。例如步骤404可以在步骤401、步骤402或步骤403之前执行，本申请对此不作特殊限定。

步骤405，在待处理请求集合中的业务请求处理完毕后，清空交换后的运行队列。

在通过业务处理接口对待处理请求集合中的业务请求处理完毕后，可以清空当前的运行队列。这时，当前的运行队列为空队列，即没有执行中的业务请求，用于处理业务请求的硬件设备处于空闲状态。

步骤406，根据请求处理结果判断业务请求是否成功处理。

在本实施例中，可以在业务调度线程中执行上述业务调度方法的步骤401至步骤405，在通过业务处理接口对待处理业务集合进行处理完毕后，可以将请求处理结果返回至业务调度线程。并在业务调度线程中判断待处理业务集合中的业务请求是否成功处理。

具体地，在通过上述业务处理接口对待处理请求集合进行计算后，可以生成计算结果，可以根据计算结果判断业务请求是否成功处理。具体地，若计算结果包含分类结果数据，可以确定对应的业务请求已成功处理，若计算结果中不包含有效的分类数据，则可以确定对应的业务请求未成功处理。其中，计算结果可以由业务处理逻辑生成。在一些实施例中，业务处理逻辑可以在对待处理请求集合进行计算的同时生成一个返回值。该返回值用于标识处理的状态。例如处理成功时该返回值为0，若处理失败则该返回值为1。可以通过检查该返回值来快速确认业务请求是否成功处理。进一步地，待处理请求集合中包含多个业务请求，可以检测每个业务请求的返回值，依次判断各业务请求是否成功处理。

步骤407，以预设时间间隔重复将未成功处理的业务请求添加至交换后的等待队列。

若步骤406中检测出未成功处理的业务请求，则可以将该业务请求重新添加至交换后的等待队列，在下一次业务调度流程中将该业务请求作为新到的请求重新进行调度。

在进一步的实施例中，可以统计各业务请求未成功处理的次数，在每次清空运行队列时，将未成功处理的业务请求的数量加1，当某一业务请求未成功处理的次数超过预设的阈值，则停止将该业务请求再次添加至等待队列，向发出业务请求的设备返回处理失败的结果。

在本实施例中，上述实现流程中的步骤401、步骤402、步骤403、和步骤405分别与前述实施例中的步骤201、步骤202、步骤203、和步骤204相同，在此不再赘述。

需要说明的是，在实际应用中，上述业务调度方法的流程400中的各个步骤可以在同一个线程中执行，也可以在不同的线程中执行，例如上述步骤401、步骤402、步骤403以及步骤405可以在一个线程中执行，例如在调度线程中执行，步骤404、步骤40/6和步骤407可以在另一个线程中执行，例如在业务请求线程中执行，在利用多个线程执行本实施例提供的方法时，各线程之间可以通过调用接口调用相关的数据。

从图4中可以看出，与图2对应的实施例不同的是，本实施例中的业务调度方法的流程400多出了添加新的业务请求的步骤404以及检查业务请求的处理结果并对处理失败的业务重新发起请求的步骤406和步骤407。通过增加的步骤404、步骤406和步骤407，本实施例表述的方案实现了业务请求的动态、持续性处理，保证了业务调度架构的稳定性，提升了业务请求的处理效率。

继续参考图5，其实出根据本申请的业务调度方法的另一个实施例的原理示意图。如图5所示，在图3的基础上，交换队列1和队列2的指针后，队列1为当前的运行队列，队列2为当前的等待队列。在队列1运行过程中，即在运行队列中的业务请求C、D、E执行的构成中，有新到的业务请求F，这时，可以将新到的业务请求F添加至当前的等待队列，即添加至队列2。在队列1计算完成后，清空队列1，将业务请求C、D、E从当前的运行队列，即队列1中清除，这时队列1为空，队列2中包含新到的业务请求F。接着可以判断业务请求C、D、E是否被成功处理，若判断出业务请求C未成功处理，可以将业务请求C添加至当前的等待队列，即队列2中。在下一个业务调度过程中，可以将运行队列指针指向队列2，指向业务请求F和业务请求C，由此实现了业务请求的持续性处理。

进一步参考图6，作为对上述各图所示方法的实现，本申请提供了一种业务调度装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图6所示，业务调度装置600包括监测单元601、交换单元602，合并单元603以及清空单元604。监测单元601用于监测等待队列中是否存在业务请求，其中等待队列用于存储待执行的业务请求；交换单元602用于响应于确定等待队列中存在业务请求，交换运行队列和等待队列，其中运行队列用于存储当前执行的业务请求；合并单元603用于将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过业务处理接口对待处理请求集合进行批量处理；清空单元604用于在待处理请求集合中的业务请求处理完毕后，清空交换后的运行队列。

在本实施例中，监测单元601可以监测已创建的等待队列的状态，判断其中是否存在待执行的业务请求。具体地，可以监测等待队列的长度，若监测到等待队列的长度不为0则可以确定等待队列中存在业务请求。可选地，监测单元601可以用于按照如下方式监测等待队列中是否存在业务请求：监测运行队列中是否存在执行中的业务请求；响应于监测出运行队列中不存在执行中的业务请求，查询等待队列以确定等待队列中是否存在业务请求。即监测单元601可以同时监测运行队列中是否存在执行中的业务请求，在运行队列中不存在业务请求时确定业务处理硬件处于空闲状态，这时启动对等待队列状态的监测。

交换单元602可以通过将等待队列和运行队列中的元素互换来实现两个队列的交换，例如可以提取出等待队列中的元素，添加至运行队列，并将运行队列中的元素添加至等待队列中。或者可以通过将运行队列的指针与等待队列的指针交换的方式来实现等待队列和运行队列的交换。

合并单元603可以将交换单元602交换后的运行队列(即交换之前的等待队列)中的业务请求进行合并，生成待处理请求集合，以通过业务处理接口对待处理请求集合同时进行处理。具体地，每个业务请求可以用一个向量表示，合并单元603可以将交换后的运行队列中的业务请求合并为一个矩阵。业务处理接口可以部署于具有不同硬件架构的多个设备中。上述多个设备可以对矩阵进行运算，得出的计算结果即为业务请求的处理结果。

在进一步的实施例中，业务处理接口包括DNN模型的输入接口，上述装置600还包括处理单元。处理单元用于：在将运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口之后，将待处理请求集合转换为输入矩阵，基于DNN模型中的各层间矩阵，利用DNN模型中各层的分类函数对所述输入矩阵进行计算，得出待处理请求集合的矩阵计算结果。

清空单元604可以在通过业务处理接口对待处理请求集合中的业务请求处理完毕后，清空当前的运行队列。具体地，清空单元604可以将运行队列的队头指针和队尾指针均置为初始值。

在一些实施例中，上述装置600还可以包括添加单元和判断单元，其中添加单元用于将获取的业务请求添加至交换后的等待队列；判断单元，用于在清空交换后的运行队列之后，根据请求处理结果判断业务请求是否成功处理，并在业务请求未成功处理时以预设时间间隔重复将未成功处理的业务请求添加至交换后的等待队列。

在一些实施例中，上述监测单元601还用于响应于确定等待队列中不存在业务请求，按照预设的时间周期查看等待队列中是否存在业务请求。即监测单元601可以对等待队列定期监测。

应当理解，装置600中记载的诸单元与参考图2描述的方法中的各个步骤相对应。由此，上文针对业务调度方法描述的操作和特征同样适用于装置600及其中包含的单元，在此不再赘述。装置600中的相应单元可以与终端设备和/或服务器中的单元相互配合以实现本申请实施例的方案。

本领域技术人员可以理解，上述业务调度装置600还包括一些其他公知结构，例如处理器、存储器等，为了不必要地模糊本公开的实施例，这些公知的结构在图6中未示出。

本申请上述实施例提供的业务调度装置，能够自动监测等待队列的状态，可以根据业务需求和硬件处理能力自适应调整运行队列中业务请求的数量，从而提升了业务处理效率。

请参考图7，其示出了根据本申请的业务调度系统的一个实施例的结构示意图。如图7所示，业务调度系统700包括：业务接收设备701、调度设备702以及业务处理设备703。

业务接收设备701用于接收业务请求并向调度设备发送业务请求。在本实施例中，业务接收设备可以是具有业务接口的设备，可以接收外部设备发送的业务请求，也可以根据用户操作生成业务请求，之后可以将业务请求发送至调度设备。业务接收设备可以是用于生成各种业务请求的设备，例如语音业务设备、内容推荐业务设备等。

调度设备702用于监测等待队列中是否存在业务请求，响应于确定等待队列中存在业务请求，交换运行队列和所述等待队列，将运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理设备的业务处理接口，并在待处理请求组中的业务请求处理完毕后，清空运行队列，其中等待队列用于存储待执行的业务请求，运行队列用于存储当前执行的业务请求。

调度设备702中包含业务调度逻辑，用于对业务接收设备发送的业务请求进行调度，具体地，调度设备可以监测预先创建的等待队列中是否存在待执行的业务请求，在确定等待队列中存在待执行的业务请求时交换运行队列和等待队列，并将交换后的运行队列中的业务请求合并，之后发送至业务处理设备703进行处理。业务处理设备703可以用于对待处理请求集合进行批量处理，并将处理结果返回调度设备702。调度设备702在业务处理设备返回处理结果后清空当前的运行队列。

本实施例提供的调度设备702所执行的方法与上述实施例描述的业务调度方法200一致，上述业务调度方法可以结合一些硬件结构(例如存储器等)应用于调度设备702中。因此，上文针对业务调度方法描述的操作和特征也可以适用于调度设备，此处不再赘述。

需要说明的是，本申请上述实施例提供的业务调度系统中的业务接收设备、调度设备以及业务处理设备可以分别部署于业务处理系统中的不同服务器集群中，与现有的将调度逻辑与业务接收逻辑部署于同一服务器集群的方案相比，将调度逻辑与业务接收逻辑分离，可以降低业务接收设备与业务处理设备之间的耦合性要求，降低了业务接收设备利用业务处理设备进行业务请求处理的难度，且这种系统架构有利于简化运维，在修改调度策略时无需重新部署业务接收逻辑，只需对调度逻辑进行调整即可。

本申请上述实施例提供的业务调度方法可以应用于利用GPU、FPGA等硬件架构进行业务处理的系统中。其中GPU和FPGA可以包括计算单元和存储单元，通过PCI-E接口与系统主机的CPU进行通信。可以通过PCI-E接口从主机的CPU获取待处理数据并将处理结果通过PCI-E接口返回主机的CPU。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括监测单元、交换单元、合并单元和清空单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，监测单元还可以被描述为“用于监测等待队列中是否存在业务请求的单元”。

作为另一方面，本申请还提供了一种非易失性计算机存储介质，该非易失性计算机存储介质可以是上述实施例中所述装置中所包含的非易失性计算机存储介质；也可以是单独存在，未装配入终端中的非易失性计算机存储介质。上述非易失性计算机存储介质存储有一个或者多个程序，当所述一个或者多个程序被一个设备执行时，使得所述设备：监测等待队列中是否存在业务请求，其中所述等待队列用于存储待执行的业务请求；响应于确定所述等待队列中存在业务请求，交换运行队列和所述等待队列，其中所述运行队列用于存储当前执行的业务请求；将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过所述业务处理接口对所述待处理请求集合进行批量处理；在所述待处理请求集合中的业务请求处理完毕后，清空所述交换后的运行队列。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (13)

1.一种业务请求的调度方法，其特征在于，所述方法包括：

监测运行队列中是否存在执行中的业务请求，其中所述运行队列用于存储当前执行的业务请求；

响应于监测出所述运行队列中不存在执行中的业务请求，查询所述等待队列以确定所述等待队列中是否存在业务请求，其中所述等待队列用于存储待执行的业务请求；

响应于确定所述等待队列中存在业务请求，交换运行队列和所述等待队列；

将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过所述业务处理接口对所述待处理请求集合进行批量处理；

在所述待处理请求集合中的业务请求处理完毕后，清空所述交换后的运行队列。

2.根据权利要求1所述的方法，其特征在于，所述交换运行队列和所述等待队列，包括：

将所述运行队列的指针与所述等待队列的指针交换。

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

将获取的业务请求添加至交换后的等待队列；

在所述清空所述运行队列之后，所述方法还包括：

根据请求处理结果判断所述业务请求是否成功处理；

若所述业务请求未成功处理则以预设时间间隔重复将未成功处理的业务请求添加至所述交换后的等待队列。

4.根据权利要求3所述的方法，其特征在于，所述业务处理接口部署于具有不同硬件架构的多个设备中。

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

响应于确定等待队列中不存在业务请求，按照预设的时间周期查看所述等待队列中是否存在业务请求。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述业务处理接口包括深度神经网络模型的输入接口；

在将所述交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口之后，所述方法还包括：

将所述待处理请求集合转换为输入矩阵；

基于所述深度神经网络模型中的各层间矩阵，利用所述深度神经网络模型中各层的分类函数对所述输入矩阵进行计算，得出所述待处理请求集合的矩阵计算结果。

7.一种业务请求的调度装置，其特征在于，所述装置包括：

监测单元，用于监测运行队列中是否存在执行中的业务请求，响应于监测出所述运行队列中不存在执行中的业务请求，查询所述等待队列以确定所述等待队列中是否存在业务请求，其中，所述运行队列用于存储当前执行的业务请求，所述等待队列用于存储待执行的业务请求；

交换单元，用于响应于确定所述等待队列中存在业务请求，交换运行队列和所述等待队列；

合并单元，用于将交换后的运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口，以通过所述业务处理接口对所述待处理请求集合进行批量处理；

清空单元，用于在所述待处理请求集合中的业务请求处理完毕后，清空所述交换后的运行队列。

8.根据权利要求7所述的装置，其特征在于，所述交换单元进一步用于按如下方式交换所述运行队列和所述等待队列：

将所述运行队列的指针与所述等待队列的指针交换。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

添加单元，用于将获取的业务请求添加至交换后的等待队列；以及

判断单元，用于在所述清空所述交换后的运行队列之后，根据请求处理结果判断所述业务请求是否成功处理，并在所述业务请求未成功处理时以预设时间间隔重复将未成功处理的业务请求添加至所述交换后的等待队列。

10.根据权利要求9所述的装置，其特征在于，所述业务处理接口部署于具有不同硬件架构的多个设备中。

11.根据权利要求7所述的装置，其特征在于，所述监测单元还用于：

响应于确定等待队列中不存在业务请求，按照预设的时间周期查看所述等待队列中是否存在业务请求。

12.根据权利要求7-11任一项所述的装置，其特征在于，所述业务处理接口包括深度神经网络模型的输入接口；

所述装置还包括处理单元，用于：

在将所述运行队列中的业务请求合并后生成待处理请求集合并发送至业务处理接口之后，将所述待处理请求集合转换为输入矩阵；以及

基于所述深度神经网络模型中的各层间矩阵，利用所述深度神经网络模型中各层的分类函数对所述输入矩阵进行计算，得出所述待处理请求集合的矩阵计算结果。

13.一种业务调度系统，其特征在于，所述系统包括：

业务接收设备，用于接收业务请求并向所述调度设备发送所述业务请求；

调度设备，用于监测运行队列中是否存在执行中的业务请求，响应于监测出所述运行队列中不存在执行中的业务请求，查询所述等待队列以确定所述等待队列中是否存在业务请求，响应于确定所述等待队列中存在业务请求，交换运行队列和所述等待队列，将所述运行队列中的业务请求合并后生成待处理请求集合并发送至所述业务处理设备的业务处理接口，并在所述待处理请求组中的业务请求处理完毕后，清空所述运行队列，其中所述等待队列用于存储待执行的业务请求，所述运行队列用于存储当前执行的业务请求；

业务处理设备，用于对所述待处理请求集合进行批量处理，并将处理结果返回所述调度设备。