CN108566424B - 基于服务器资源消耗预测的调度方法、装置和系统 - Google Patents

Abstract

本发明提出一种基于服务器资源消耗预测的调度方法、装置和系统，其中，方法包括：通过从各服务器获取当前资源信息，并根据所承载进程的运行状态信息，来确定对应服务器的待消耗资源信息，进而由各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载，以便基于各服务器的预测负载，采用负载均衡方式，对各服务器进行调度。由于可以预测未来可消耗资源，根据各服务器的当前及预测负载对各服务器进行调度，解决现有技术中调度负载不完全均衡的技术问题。

Description

基于服务器资源消耗预测的调度方法、装置和系统

技术领域

本发明涉及网络技术领域，尤其涉及一种基于服务器资源消耗预测的调度方法、装置和系统。

背景技术

网络对战游戏往往数据处理量比较大，在网络端，为了游戏过程中保持流畅，避免由于服务器负载较大出现卡顿的情况，往往需要对于提供游戏服务的服务器进行调度，使得各台服务器之间大致负载均衡，避免某一台服务器负载较高。

现有技术中，结合场景不同，存在多种不同的调度方式，包括轮询调度、随机调度和基于最小负载调度等多种负载调度方式。但在实际使用过程中发现，现有技术的调度存在准确度不高的问题，各台服务器的负载仍会存在较大差异，整体负载不够稳定均一。

发明内容

本发明旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明提出一种基于服务器资源消耗预测的调度方法，以实现游戏过程稳定、流畅，解决现有技术中服务器的负载调度不均衡的技术问题。

本发明第一方面实施例提出了一种基于服务器资源消耗预测的调度方法，包括：

从各服务器获取当前资源信息，以及所承载进程的运行状态信息；

根据各服务器所承载进程的运行状态信息，确定对应服务器的待消耗资源信息；

根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载；

根据各服务器的预测负载，采用负载均衡方式，对各服务器进行调度。

本发明实施例的调度方法，通过从各服务器获取当前资源信息，并根据所承载进程的运行状态信息，来确定对应服务器的待消耗资源信息，进而由各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载，以便基于各服务器的预测负载，采用负载均衡方式，对各服务器进行调度。由于在确定各服务器负载时，考虑了后续即将发生的资源消耗情况，即待消耗资源信息，使得确定出的负载更加准确。而现有技术中仅考虑当前的已消耗资源情况，在服务器当前的已消耗资源较少，即使后续即将消耗资源较多的情况下，现有技术中依然会增加服务器的调度任务，导致服务器负载过高。可见，本发明实施例根据各服务器的当前资源信息以及待消耗资源信息进行负载预测，据此对各服务器进行调度，解决了现有技术中调度负载不均衡的技术问题。

本发明第二方面实施例提出了一种基于服务器资源消耗预测的调度装置，包括：

获取模块，用于从各服务器获取当前资源信息，以及所承载进程的运行状态信息；

资源确定模块，用于根据各服务器所承载进程的运行状态信息，确定对应服务器的待消耗资源信息；

负载确定模块，用于根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载；

调度模块，用于根据各服务器的预测负载，采用负载均衡方式，对各服务器进行调度。

本发明第三方面实施例提出了一种基于服务器资源消耗预测的调度系统，包括：调度服务器，以及包括与所述调度服务器通信连接的多个代理服务器；

每一台代理服务器，用于承载多个进程，各进程用于执行对应的单局服务逻辑；还用于监测并向所述调度服务器发送当前资源信息，以及所承载进程的运行状态信息；

所述调度服务器，用于从各代理服务器获取当前资源信息，以及所承载进程的运行状态信息，以执行如前述第一方面提供的调度方法，调度多个代理服务器中的一个提供单局服务。

本发明第四方面实施例提出了一种计算机设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行第一方面实施例所述的调度方法。

本发明第五方面实施例提出了一种计算机可读存储介质，当所述存储介质中的指令由处理器被执行时，用于执行第一方面实施例所述的调度方法。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1A轮询调度的示意图；

图1B随机调度的示意图；

图1C基于最小负载调度的示意图；

图2A为本发明实施例所提供的一种基于服务器资源消耗预测的调度方法的流程示意图；

图2B为本发明实施例中游戏的应用场景图；

图3为本发明实施例所提供的另一种基于服务器资源消耗预测的调度方法的流程示意图；

图4为本发明实施例提供的单局调度数学模型示意图；

图5为本发明实施例所提供的一种基于服务器资源消耗预测的调度装置的结构示意图；

图6为本发明实施例所提供的一种基于服务器资源消耗预测的调度系统的结构示意图；

图7为本发明实施例提供的另一种基于服务器资源消耗预测的调度系统的结构示意图；

图8所示为一个物理机同时运行200个服务器单局资源消耗的情况；

图9为本发明实施例提供了在进行单局服务时调度系统的交互示意图之一；以及

图10为本发明实施例提供的在进行单局服务时调度系统的交互示意图之二。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

在相关技术中，结合场景不同，存在多种不同的调度方式，包括轮询调度、随机调度和基于最小负载调度等多种负载调度方式。

在具体描述本实施例之前，为了便于理解，首先对常用的关键术语进行介绍和解释：

中央处理器(Dedicated Server，DS)，在游戏中称为引擎服务器，决定了游戏效果、流畅度等，用于执行单局服务逻辑。DS可以响应于终端设备所安装客户端的各种请求，提供相应单局游戏服务。

代理服务器(Dedicated Server Agent，DSA)，在游戏中称为单局代理服务器，用于管理DS单局服务。一般来说，代理服务器为一台物理机，其上承载有多个进程，每一个进程对应一个DS，因此，也可以称这个进程为单局引擎，代理服务器用于对多个进程进行管理，以利用所管理的进程为客户端提供相应的单局服务。

调度服务器(Dedicated Server Center，DSCenter)，在游戏中称为单局调度服务器，用于在调度选择DSA服务节点提供DS单局服务。以用于承载游戏服务的调度系统为例，调度服务器可以将游戏相关任务调度至不同的代理服务器执行，从而由调度到的代理服务器利用所管理的进程为客户端提供单局服务。

游戏服务器(GameSvrd)，用于管理游戏数据和实现游戏逻辑的服务。当客户端发起游戏开局请求时，请求调度服务器进行相应调度，以提供最优代理服务器利用其所管理的进程为客户端提供相应单局服务。

服务能力分数(ServiceScore，SS)，是代理服务器服务能力的分数定义，用于在调度选择中作为选择的综合指标。调度服务器参考服务能力分数，为客户端调度最优代理服务器。相关技术中，服务能力分数是根据代理服务器当前资源信息确定的，调度服务器根据服务能力分数，采用预设的调度方式，对各代理服务器进行调度。

相关技术中，存在多种调度方式：

如图1A轮询调度的示意图，是以轮叫的方式调度服务器依次将请求调度不同的代理服务器，即上一次调度选择第i台服务器，则下一次调度选择第(i+1)台服务器。此调度方法的缺点是：由于每个游戏单局的资源消耗、单局游戏时长不一样，轮询调度方式可能会导致不同代理服务器管理的单局数不一样，从而出现负载不均衡的情况。

如图1B随机调度的示意图，是以完全随机的方式依次将请求调度不同的代理服务器。其缺点是导致某些代理服务器繁忙，某些代理服务器相对空闲，从而出现负载不均衡的情况。

如图1C基于最小负载调度的示意图，是当代理服务器上报当前的负载信息到调度服务器后，调度服务器按照负载信息由低到高排序，每次调度执行选择负载最低的代理服务器提供服务。其缺点是只能保证调度分配任务后短时间内的负载准确性，在游戏单局请求分配并发度高时，在两次调度之间，可能会出现负载瞬间变化幅度过大的情况，调度负载不均衡导致游戏过程中出现卡顿。例如：对于代理服务器来说，可能上一秒向调度服务器上报的信息为低消耗，但在下一秒则实际资源消耗就变成了高消耗，导致调度服务器根据获知到的低消耗进行调度时，可能存在调度不准确的情况。

可见，在进行最小负载调度时，仅考虑当前的已消耗资源情况，在代理服务器当前的已消耗资源较少，即使后续即将消耗资源较多的情况下，依然会增加该代理服务器的调度任务，导致其负载过高。

本发明实施例，在确定各服务器负载时，考虑了未来的资源消耗情况，即待消耗资源信息，使得确定出的负载更加准确。下面参考附图描述本发明实施例的调度方法和装置。

图2A为本发明实施例所提供的一种基于服务器资源消耗预测的调度方法的流程示意图。本实施例所提供的方法，可以由调度服务器执行，该调度服务器可以为单台服务器，也可以为服务器集群，本实施例中对此不做限定。另外，本领域技术人员可以知晓，被调度的服务器不仅限于前面提及的用于承载各单局引擎的代理服务器，还可以用于承载其他服务，本实施例中对此不做限定。如图2A所示，方法包括以下步骤：

步骤201，从各服务器获取当前资源信息，以及所承载进程的运行状态信息。

其中，所承载进程的运行状态包括：进程处于待初始化状态、进程处于待启动状态和进程处于运行中状态。

具体地，调度服务器从各被调度的服务器获取当前资源信息，这里的当前资源信息仅包括处于运行中状态、启动中状态或者是运行中状态的进程已消耗的资源量。而发明人实际监测发现，对于待初始化状态和待启动状态的进程在未来一段时间内，即将出现一定的资源消耗量，尤其是待初始化状态的进程在未来的初始化过程中会消耗较大的资源。由于待初始化状态和待启动状态的进程待消耗资源信息并未计入当前资源信息中，因此，调度服务器不仅需要从各服务器获取当前资源信息，还需要确定各进程的运行状态信息，以便据此进行后续一段时间的资源量预测，确定待消耗资源信息。

步骤202，根据各服务器所承载进程的运行状态信息，确定对应服务器的待消耗资源信息。

具体地，调度服务器根据在上一步骤中获取到的运行状态信息，进行计算，从而预测各服务器在后续还需消耗的资源，即待消耗资源信息。在计算待消耗资源信息时，可以根据进程在不同运行状态下统计得到的平均资源消耗情况进行预测。

作为一种可能的实现方式，统计符合同一运行状态信息的进程个数，将进程个数乘以预设的系数，该系数是对历史情况进行统计，根据单个进程符合该运行状态信息的情况下得到的平均消耗资源量。

其中，物理机在承载进程时，存在多种形式的资源消耗，一般来说，系统、中央处理器(Central Processing Unit，CPU)、内存情况对服务器负载情况描述较为准确，对进程运行影响较大，因此，可以针对系统、CPU、内存情况进行分析，确定资源消耗。

进一步，根据不同形式的资源消耗对于负载或者进程运行流畅性的贡献程度，可以为系统负载、CPU资源、内存资源设置不同的权重，以便对系统负载、CPU资源、内存资源进行加权求和，得到多种形式的资源消耗总量。以便根据各进程后续多种形式的资源消耗总量，计算服务器的待消耗资源信息，计算结果更加准确。

步骤203，根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载。

具体地，调度服务器针对每一个被调度的服务器，将当前资源信息和所述待消耗资源信息进行处理，优选地为相加，即可得到该服务器的预测负载。从而预测负载中，不仅包含服务器当前已经发生的负载，而且还包含了对后续负载情况的预测。而在现有技术中，调度服务器仅根据当前已经发生的负载进行调度，未对后续即将产生的负载进行预测，导致调度后各服务器负载不均。

步骤204，根据各服务器的预测负载，采用负载均衡方式，对各服务器进行调度。

具体地，调度服务器依据预测负载，对各服务器进行排序，以确定预测负载最小的服务器，调度预测负载最小的服务器提供服务。其中，服务器用于提供游戏单局服务。由于本实施例中，调度服务器考虑到了后续即将产生的负载，避免了调度后各服务器负载不均的情况，优化了各服务器的负载情况。

作为一种可能的实现方式，调度服务器可以选择负载最轻的服务器进行任务处理。在应用场景为游戏的情况下，如图2B本实施例中游戏的应用场景图，调度服务器具体可以调度预测负载最小的代理服务器响应游戏客户端的相关请求，由被调度到的代理服务器中的进程来为游戏客户端提供单局服务，实现各服务器负载均衡。避免用户在使用游戏客户端进行游戏过程中，由于各服务器负载不均，导致的长时间无响应的情况出现，保证游戏单局战斗过程不会出现卡顿，为用户提供稳定、平滑的游戏体验。

本实施例中，通过从各服务器获取当前资源信息，并根据所承载进程的运行状态信息，来确定对应服务器的待消耗资源信息，进而由各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载，以便基于各服务器的预测负载，采用负载均衡方式，对各服务器进行调度。由于在确定各服务器负载时，考虑了后续即将发生资源消耗情况，即待消耗资源信息，使得确定出的负载更加准确。而现有技术中仅考虑当前的已消耗资源情况，在服务器当前的已消耗资源较少，即使后续即将消耗资源较多的情况下，现有技术中依然会增加服务器的调度任务，导致服务器负载过高。可见，本发明实施例根据各服务器的当前资源信息以及待消耗资源信息进行负载预测，据此对各服务器进行调度，解决了现有技术中调度负载不均衡的技术问题。

基于前述实施例，为了清楚说明预测负载的计算过程，本实施例提供了另一种基于服务器资源消耗预测的调度方法，图3为本发明实施例所提供的另一种基于服务器资源消耗预测的调度方法的流程示意图，如图3所示，在游戏场景中，该调度方法，包括以下步骤：

步骤301，调度服务器周期性从各被调度的代理服务器获取当前资源信息，以及处于不同运行状态的进程数量。

其中，当前资源信息包括：已消耗系统负载、已消耗CPU资源和已消耗内存资源。

具体地，各代理服务器统计承载的各进程的运行状态，将处于不同运行状态的进程数量作为运行状态信息，周期性发送至调度服务器。另外，各代理服务器分类型进行资源消耗量统计，从而获得已消耗系统负载、已消耗CPU资源和已消耗内存资源，将已消耗系统负载、已消耗CPU资源和已消耗内存资源作为当前资源信息随运行状态信息，一同周期性发送至调度服务器。

步骤302，调度服务器针对每一台被调度的代理服务器，根据当前资源信息，以及处于不同运行状态的进程数量计算各台代理服务器的预测负载。

具体地，针对每一台代理服务器，将所述处于待初始化状态的进程数量与第一系数相乘，得到所述第一资源量；其中，所述第一系数，是根据单个进程在初始化过程中的消耗资源量统计得到。将所述处于待启动状态的进程数量与第二系数相乘，得到所述第二资源量；其中，所述第二系数，是根据单个进程在启动过程中的消耗资源量统计得到。调度服务器对各代理服务器的第一资源量和第二资源量求和，确定对应代理服务器的待消耗资源信息。进而，调度服务器将代理服务器的当前资源信息，与对应代理服务器的待消耗资源信息求和，得到该代理服务器的预测负载。

进一步的，下面通过举例说明如何统计得到第一系数和第二系数，需要说明的是，文中描述的实施例是示例性的，列举数据与实际有出入，旨在用于解释本发明，而不能理解为对本发明的限制。

监测一台服务器在不同时段的系统负载，以及对应同一时段内处于不同状态下的进程数量，分别将初始化过程、启动过程的资源消耗情况作为未知参量，也就是所述第一系数和第二系数，分别设为X、Y。

例如，监测服务器在第1s、2s时处于各状态的进程数。在第1s时，假设初始化进程数量、启动中进程数量、运行中进程数量分别为10、20、30，对应时段的系统负载所占比重为80％。可以得到方程式10X+20Y＝80％-30Z，其中Z为运行中状态的进程资源消耗情况。

类似地，在第2s时，假设初始化进程数量、启动中进程数量、运行中进程数量分别为5、10、30，对应时段的系统负载所占比重为70％，得到方程式5X+10Y＝70％-30Z。

如此反复得到多个方程式后，对多个方程式联立即可得到X、Y，即初始化过程、启动过程的资源消耗情况。具体地，如图4所示，针对每一个代理服务器预测负载均包括3个部分：

第一部分，系统的预测负载。

具体地，系统的预测负载＝系统负载已消耗资源量+系统负载消耗的第一资源量+系统负载消耗的第二资源量。

其中，系统负载消耗的第一资源量，是处于待初始化状态的进程即将对系统负载消耗的资源量，通过处于待初始化状态的进程数量乘以系统负载对应的第一系数得到。其中，系统负载对应的第一系数是对处于待初始化状态的进程在初始化过程中消耗的系统负载进行统计得到的。

系统负载消耗的第二资源量，是处于待启动状态的进程即将对系统消耗的资源量，通过处于待初始化状态的进程数量乘以系统负载对应的第二系数得到。其中，系统负载对应的第二系数是对处于待初始化状态的进程在启动过程中消耗的系统负载进行统计得到的。

系统负载消耗的第一资源量和系统负载消耗的第二资源量之和，可以称为系统的待消耗资源信息。

例如，在单局调度服务过程中，可以计算负载分数，通过负载分数衡量系统的预测负载，计算负载分数的公式如下：

LoadScore＝(CurLoad+FutureInitLoad+FutureStartingLoad)*LoadFactor

其中，LoadScore为负载分数，对应于上文的系统的预测负载；CurLoad为当前负载，对应于上文中的系统负载已消耗资源量；FutureInitLoad为即将初始化单局负载消耗值，对应于上文中系统负载消耗的第一资源量；FutureStartingLoad为即将拉起单局负载消耗值，对应于上文的系统负载消耗的第二资源量；LoadFactor表示当前负载所占权重。具体地，FutureInitLoad＝FutureInitLoadPerGame(初始化负载消耗)*FutureInitGameNum(初始化单局数)。

FutureStartingLoad＝FutureStartingLoadPerGame(为即将拉起单局负载消耗)*FutureStartingGameNum(为即将拉起单局数)。

第二部分，CPU的预测负载。

具体地，CPU的预测负载＝CPU已消耗资源量+CPU消耗的第一资源量+CPU消耗的第二资源量。

其中，CPU消耗的第一资源量，是处于待初始化状态的进程即将对CPU消耗的资源量，通过处于待初始化状态的进程数量乘以CPU资源对应的第一系数得到。其中，CPU资源对应的第一系数是对处于待初始化状态的进程在初始化过程中消耗的CPU资源进行统计得到的。

CPU消耗的第二资源量，是处于待启动状态的进程即将对CPU消耗的资源量，通过处于待初始化状态的进程数量乘以CPU资源对应的第二系数得到。其中，CPU资源对应的第二系数是对处于待初始化状态的进程在启动过程中消耗的CPU资源进行统计得到的。

CPU消耗的第一资源量和CPU消耗的第二资源量之和，可以称为CPU的待消耗资源信息。

例如，可以计算CPU的负载分数，通过负载分数衡量CPU的预测负载，计算负载分数的公式如下：

CurCPUScore＝(CurCPU+FutureInitCPU+FutureStartingCPU)*CPUFactor

其中，CurCPUScore表示CPU当前的负载分数，对应于上文中CPU的预测负载；CurCPU为当前的CPU负载，对应于上文中CPU已消耗资源量；FutureInitCPU为即将初始化单局CPU消耗值，对应于上文中指的CPU消耗的第一资源量；FutureStartingCPU即将拉起单局CPU消耗值；CPUFactor为CPU所占权重。

具体地，FutureInitCPU＝FutureInitCPUPerGame(初始化CPU消耗)*FutureInitGameNum(初始化单局数)。

FutureStartingCPU＝FutureStartingCPUPerGame(即将拉起单局CPU消耗)*FutureStartingGameNum(即将拉起单局数)。

第三部分，内存的预测负载。

具体地，内存的预测负载＝内存已消耗资源量+内存消耗的第一资源量+内存消耗的第二资源量。

其中，内存消耗的第一资源量，是处于待初始化状态的进程即将对内存消耗的资源量，通过处于待初始化状态的进程数量乘以内存资源对应的第一系数得到。其中，内存资源对应的第一系数是对处于待初始化状态的进程在初始化过程中消耗的内存资源进行统计得到的。

内存消耗的第二资源量，是处于待启动状态的进程即将对内存消耗的资源量，通过处于待初始化状态的进程数量乘以内存资源对应的第二系数得到。其中，内存资源对应的第二系数是对处于待初始化状态的进程在启动过程中消耗的内存资源进行统计得到的。

内存消耗的第一资源量和内存消耗的第二资源量之和，可以称为内存的待消耗资源信息。

例如，可以计算内存的负载分数，通过负载分数衡量内存的预测负载，计算负载分数的公式如下：

CurMemScore＝(CurMem+FutureInitMem+FutureStartingMem)*MEMFactor

其中，CurMemScore为当前的内存负载分数，对应于上文的内存的预测负载；CurMem为当前的内存消耗，对应于内存已消耗资源量；FutureInitMem为即将初始化单局内存消耗值，对应于上文提出的内存消耗的第一资源量；FutureStartingMem为即将拉起单局内存消耗值，对应于上文提出的内存消耗的第二资源量；MEMFactor为内存所占的权重。

具体地，FutureInitMem＝FutureMemPerGame(单局内存消耗)*FutureInitGameNum(初始化单局数)

FutureStartingMem＝FutureMemPerGame(单局内存消耗)*FutureStartingGameNum(即将拉起单局数)

最后，代理服务器的预测负载＝系统的预测负载*系统权重+CPU的预测负载*CPU权重+内存的预测负载*内存权重。系统权重、CPU权重和内存权重用于指示对运行流畅性影响大小，影响越大，则权重取值越大。

例如，上述示例中计算出了系统的负载、CPU的负载和内存的负载，通过相加即可得到服务能力分数，对应于上文提出的代理服务器的预测负载。计算公式如下：

ServiceScore＝CurLoadScore+CurCPUScore+CurMemScore

步骤303，当通过游戏服务器获取到终端设备发送的开局请求时，调度服务器从各台代理服务器中调度预测负载最小的代理服务器，提供单局服务。

本实施例中，分别针对系统、CPU和内存分别进行预测负载的计算，并根据系统、CPU和内存对运行流畅性影响大小确定系统权重、CPU权重和内存权重，据此对系统、CPU和内存的预测负载进行加权求和，从而使得计算出的代理服务器的预测负载更加准确。

图5为本发明实施例提供的一种基于服务器资源消耗预测的调度装置的结构示意图。

如图5所示，该调度装置包括：获取模块51、资源确定模块52、负载确定模块53、调度模块54。

获取模块51，用于从各服务器获取当前资源信息，以及所承载进程的运行状态信息。

其中，资源信息包括系统负载信息、CPU资源信息和内存资源信息中的一个或多个组合。

资源确定模块52，用于根据各服务器所承载进程的运行状态信息，确定对应服务器的待消耗资源信息。

具体地，针对每一台服务器，根据所述运行状态信息中处于待初始化状态的进程数量，确定处于待初始化状态的进程需消耗的第一资源量；根据所述运行状态信息中处于待启动状态的进程数量，确定处于待启动状态的进程需消耗的第二资源量；对所述第一资源量和所述第二资源量求和，以得到所述服务器的待消耗资源信息。

其中，根据所述运行状态信息中处于待初始化状态的进程数量，确定处于待初始化状态的进程需消耗的第一资源量，包括：将所述处于待初始化状态的进程数量与第一系数相乘，得到所述第一资源量；其中，所述第一系数，是根据单个进程在初始化过程中的消耗资源量计算得到。

其中，根据所述运行状态信息中处于待启动状态的进程数量，确定处于待启动状态的进程需消耗的第二资源量，包括：将所述处于待启动状态的进程数量与第二系数相乘，得到所述第二资源量；其中，所述第二系数，是根据单个进程在启动过程中的消耗资源量计算得到。

负载确定模块53，用于根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载；

具体地，针对每一台服务器，将所述当前资源信息中已消耗系统负载，与所述待消耗资源信息中待消耗系统负载进行处理，优选地为相加，得到系统的预测负载；将所述当前资源信息中已消耗CPU资源，与所述待消耗资源信息中待消耗CPU资源进行处理，优选地为相加，得到CPU的预测负载；将所述当前资源信息中已消耗内存资源，与所述待消耗资源信息中待消耗内存资源进行处理，优选地为相加，得到内存的预测负载；根据所述系统的预测负载、CPU的预测负载和内存的预测负载，进行加权求和，得到对应服务器的预测负载。

调度模块54，用于根据各服务器的预测负载，采用负载均衡方式，对各服务器进行调度。

具体地，对各服务器进行调度，是依据预测负载，对各服务器进行排序，以确定预测负载最小的服务器，调度预测负载最小的服务器提供服务。其中，服务器用于提供游戏单局服务。

需要说明的是，前述对调度方法实施例的解释说明也适用于该实施例的调度装置，此处不再赘述。

为了实现上述实施例，本发明还提出一种基于服务器资源消耗预测的调度系统。

图6为本发明实施例提供的一种基于服务器资源消耗预测的调度系统的结构示意图。

如图6所示，该调度系统包括代理服务器61和调度服务器62。

调度服务器62与所述代理服务器61通信连接，代理服务器61可以为多个。

每一台代理服务器61，用于承载多个进程，各进程用于执行对应的单局服务逻辑；还用于监测并向所述调度服务器发送当前资源信息，以及所承载进程的运行状态信息。

作为一种可能的实现方式，代理服务器61具体为一台物理机，承载有至少一个进程601。代理服务器61会将已消耗系统负载信息、CPU资源信息和内存资源信息，以及所承载进程的运行状态信息上传到调度服务器62。

调度服务器62，用于从各代理服务器61获取当前资源信息，以及所承载进程的运行状态信息，以执行前述实施例提供的调度方法，调度多个代理服务器61中的一个提供单局服务。

进一步地，图7为本发明实施例提供的另一种基于服务器资源消耗预测的调度系统的结构示意图，在图6的基础上还进一步包括：终端设备64和游戏服务器63。

终端设备64，用于发起开局请求。

游戏服务器63，与所述终端设备和所述调度服务器62通信连接，具体用于接收到所述开局请求时，请求所述调度服务器调度多个代理服务器中的一个为所述终端设备提供单局服务。

代理服务器61，与所述终端设备64通信连接，具体用于当所述调度服务器62调度到提供单局服务时，从承载的进程中选择一个进程与所述终端设备64交互，为所述终端设备64提供单局服务。

本实施提供的代理服务器61执行前述实施例提供的调度方法时，如图8所示为一个物理机同时运行200个服务器单局资源消耗的情况，图8显示CPU消耗在50％左右，因此，整个游戏过程比较稳定，流畅。

为了清楚说明前述实施例提供的调度系统，图9为本发明实施例提供了在进行单局服务时调度系统的交互示意图之一。

如图9所示，该单局调度服务包括以下步骤：

步骤901，终端设备向游戏服务器发起开局请求。

步骤902，游戏服务器请求所述调度服务器调度多个代理服务器中的一个为终端设备提供单局服务。

步骤903，调度服务器获取各调度服务器的上报信息。

其中，上报信息包括当前资源信息，以及所承载单局服务进程的运行状态信息。

步骤904，调度服务器根据上报信息选择负载最轻的代理服务器为终端设备提供单局服务。

具体地，通过根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载。建立可量化的数学模型，选择最优的引擎服务节点通过代理服务器与终端设备交互，为所述终端设备提供单局服务。

步骤905，被调度到的代理服务器利用承载的进程为终端设备进行单局服务，以执行开局过程。

为了清楚说明各代理服务器上报信息以及调度服务器调度过程，图10为本发明实施例提供的在进行单局服务时调度系统的交互示意图之二；如图10所示，方法包括以下步骤：

步骤1001，代理服务器监控自身的系统、CPU、内存情况，向调度服务器发送上报信息。

上报信息包括：系统、CPU、内存已消耗资源，以及处于不同运行状态的单局进程数目。

步骤1002，调度服务器根据代理服务器上报信息，计算出服务能力分数，并按照服务能力分数值升序排列得到代理服务器列表。

其中，服务能力分数可以为各代理服务器的预测负载的取值。

具体地，通过图4建立的数学模型以及代理服务器上报的负载、CPU预测负载、内存预测负载信息，计算出对应代理服务器的预测负载。

步骤1003，终端设备通过游戏服务器向调度服务器发送开局请求。

步骤1004，调度服务器选择服务能力分数最小的代理服务器。

步骤1005，调度服务器通过游戏服务器向终端设备发送服务能力分数最小的代理服务器的网络地址。

步骤1006，终端设备根据该网络地址与对应代理服务器交互，执行开局过程。

具体地，游戏服务器与所述终端设备和所述调度服务器通信连接，当接收到所述开局请求时，请求所述调度服务器调度多个代理服务器中的一个为所述终端设备提供单局服务。

由于每个游戏单局的资源消耗、单局游戏时长不一样，轮询调度或者随机调度方式可能会导致DS机器上的单局数不一样，这样会导致某些代理服务器繁忙，某些代理服务器相对空闲，负载不均衡。

为了实现上述实施例，本发明还提出另一种计算机设备，包括：处理器，以及用于存储所述处理器可执行指令的存储器。

其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如本发明前述实施例提出的调度方法。

为了实现上述实施例，本发明还提出一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如本发明前述实施例提出的调度方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (14)

1.一种基于服务器资源消耗预测的调度方法，其特征在于，方法包括以下步骤：

根据接收到开局请求的游戏服务器发送的请求，从各服务器获取当前资源信息，以及所承载单局服务进程的运行状态信息，所承载单局服务进程的运行状态信息包括待初始化状态信息和待启动状态信息；

根据各服务器所承载单局服务进程的待初始化状态信息和待启动状态信息，确定对应服务器的待消耗资源信息；

根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载；

根据各服务器的预测负载，采用负载均衡方式，对各服务器进行调度，确定用于执行所述开局请求对应的单局服务的服务器。

2.根据权利要求1所述的调度方法，其特征在于，所述根据各服务器所承载进程的运行状态信息，确定对应服务器的待消耗资源信息，包括：

针对每一台服务器，根据所述运行状态信息中处于待初始化状态的进程数量，确定处于待初始化状态的进程需消耗的第一资源量；

根据所述运行状态信息中处于待启动状态的进程数量，确定处于待启动状态的进程需消耗的第二资源量；

对所述第一资源量和所述第二资源量求和，以得到所述服务器的待消耗资源信息。

3.根据权利要求2所述的调度方法，其特征在于，所述根据所述运行状态信息中处于待初始化状态的进程数量，确定处于待初始化状态的进程需消耗的第一资源量，包括：

将所述处于待初始化状态的进程数量与第一系数相乘，得到所述第一资源量；其中，所述第一系数，是根据单个进程在初始化过程中的消耗资源量计算得到。

4.根据权利要求2所述的调度方法，其特征在于，所述根据所述运行状态信息中处于待启动状态的进程数量，确定处于待启动状态的进程需消耗的第二资源量，包括：

将所述处于待启动状态的进程数量与第二系数相乘，得到所述第二资源量；其中，所述第二系数，是根据单个进程在启动过程中的消耗资源量计算得到。

5.根据权利要求1所述的调度方法，其特征在于，所述资源信息包括系统负载信息、CPU资源信息和内存资源信息中的一个或多个组合。

6.根据权利要求5所述的调度方法，其特征在于，所述根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载，包括：

针对每一台服务器，将所述当前资源信息中已消耗系统负载，与所述待消耗资源信息中待消耗系统负载求和，得到系统的预测负载；

将所述当前资源信息中已消耗CPU资源，与所述待消耗资源信息中待消耗CPU资源求和，得到CPU的预测负载；

将所述当前资源信息中已消耗内存资源，与所述待消耗资源信息中待消耗内存资源求和，得到内存的预测负载；

根据所述系统的预测负载、CPU的预测负载和内存的预测负载，进行加权求和，得到对应服务器的预测负载。

7.根据权利要求1-6任一项所述的调度方法，其特征在于，所述采用负载均衡方式，对各服务器进行调度，包括：

依据所述预测负载，对各服务器进行排序，以确定所述预测负载最小的服务器；

调度所述预测负载最小的服务器提供服务。

8.根据权利要求1-6任一项所述的调度方法，其特征在于，所述服务器用于提供游戏单局服务。

9.一种基于服务器资源消耗预测的调度装置，其特征在于，所述装置包括：

获取模块，用于根据接收到开局请求的游戏服务器发送的请求，从各服务器获取当前资源信息，以及所承载单局服务进程的运行状态信息，所承载单局服务进程的运行状态信息包括待初始化状态信息和待启动状态信息；

资源确定模块，用于根据各服务器所承载单局服务进程的运行状态信息，确定对应服务器的待消耗资源信息；

负载确定模块，用于根据各服务器的当前资源信息和所述待消耗资源信息，得到各服务器的预测负载；

调度模块，用于根据各服务器的预测负载，采用负载均衡方式，对各服务器进行调度，确定用于执行所述开局请求对应的单局服务的服务器。

10.一种基于服务器资源消耗预测的调度系统，其特征在于，包括：调度服务器，以及包括与所述调度服务器通信连接的多个代理服务器；

每一台代理服务器，用于承载多个进程，各进程用于执行对应的单局服务逻辑；还用于监测并向所述调度服务器发送当前资源信息，以及所承载进程的运行状态信息；

所述调度服务器，用于从各代理服务器获取当前资源信息，以及所承载进程的运行状态信息，以执行如权利要求1-8中任一项所述的调度方法，调度多个代理服务器中的一个提供单局服务。

11.根据权利要求10所述的调度系统，其特征在于，所述调度系统还包括：

终端设备，用于发起开局请求；

游戏服务器，与所述终端设备和所述调度服务器通信连接，用于接收到所述开局请求时，请求所述调度服务器调度多个代理服务器中的一个为所述终端设备提供单局服务；

所述代理服务器，与所述终端设备通信连接，具体用于当所述调度服务器调度到提供单局服务时，从承载的进程中选择一个进程与所述终端设备交互，为所述终端设备提供单局服务。

12.根据权利要求10或11所述的调度系统，其特征在于，所述代理服务器包括至少一台物理机。

13.一种计算机设备，其特征在于，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如权利要求1-8中任一所述的调度方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-8中任一所述的调度方法。

Images