用于云服务的资源分配方法、系统和介质与流程

本公开涉及云技术，更具体地说，涉及用于云服务的资源分配方法、系统和介质。

背景技术：

在传统的信息处理方式中，用户对于设备是独享的，即：用户与设备处于同一物理环境中。用户通过操作设备来执行期望的处理任务。在这种情况下，所述设备必须完全具备执行处理任务所需的最小性能。

但是，随着处理任务的复杂度和运算量的不断提高，仅仅依靠本地的设备难以达到期望的性能和效果。在这种情况下，云技术(cloudtechnology)得到了广泛的关注和快速的发展。云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种技术。与传统的信息处理方式不同，云服务通过在云端提供信息处理的能力，来让用户共享云端的高性能设备，从而获得更快的处理速度和更低廉的使用成本。可见，与传统的信息处理方式相比，云端的处理能力是共享的，而不是独占的。不同的用户之间采用分时复用的策略来共享云端的计算资源。

现有的对于云端的资源调度，通常都是某一种资源的获取，例如，为某段数据预留一段内存，为某个文件准备存储空间，为某些计算预留一段运行时间等。可见，现有的云端资源获取方式比较单一，不能满足资源需求复杂的资源分配场景下的资源调度方案。

技术实现要素：

鉴于以上情形，期望提供能够对于资源的多样性搜索和匹配提供快速支持的、用于云服务的资源调度方法、系统和介质。

根据本公开的一个方面，提供了一种用于云服务的资源分配方法，包括：基于来自终端的资源分配请求，确定用于搜索至少一种资源的搜索条件，所述搜索条件包括对于所述至少一种资源中每种资源的资源量需求；获取用于提供所述云服务的多种资源的实时状态信息，其中，所述多种资源中每种资源的实时状态信息被独立地存储，所述多种资源中的每种资源的实时状态信息包括在多个资源提供服务器中该种资源的可用余量信息，并且该种资源的实时状态信息与对应的资源提供服务器的标识被相关联地存储在与该种资源对应的资源信息列表中；基于所述可用余量信息，在所述多个资源提供服务器中确定具有与所述搜索条件匹配的所述至少一种资源的至少一个候选资源提供服务器；基于所确定的至少一个候选资源提供服务器，确定对应所述资源分配请求的至少一组可分配资源，其中每组可分配资源对应于一个候选资源提供服务器；以及基于所述至少一组可分配资源，向所述终端执行资源分配。

另外，在根据本公开实施例的方法中，基于所述可用余量信息，在所述多个资源提供服务器中确定所述至少一个候选资源提供服务器的步骤由资源信息服务器执行，其中，所述资源信息服务器包括主服务器和至少一个从服务器，且所述主服务器和所述至少一个从服务器之间通过同步保持数据的一致性，所述方法还包括：按照第一预定时间间隔，从所述多个资源提供服务器接收对于指示所述各种资源的实时状态的上报数据；将所述上报数据写入所述主服务器；按照第二预定时间间隔，将所述主服务器上存储的用于提供所述云服务的多种资源的实时状态信息同步到所述至少一个从服务器；以及通过所述至少一个从服务器确定具有与所述搜索条件匹配的资源的候选资源提供服务器。

另外，在根据本公开实施例的方法中，对于每个资源提供服务器，其每种资源包括多个子资源，且每种资源的可用余量信息包括所述多个子资源的可用余量信息；其中，所述基于所确定的至少一个候选资源提供服务器，确定对于所述资源分配请求的至少一组可分配资源，包括：基于所述至少一个候选资源提供服务器处的每种资源的各个子资源的可用余量信息，确定满足所述搜索条件的各个资源的至少一个子资源作为所述至少一组可分配资源。

另外，在根据本公开实施例的方法中，所述搜索条件包括针对第一种资源的第一条件和针对第二种资源的第二条件，并且其中所述确定所述至少一个候选资源提供服务器，包括：在资源信息服务器上，基于所述第一条件、所述第一种资源的实时状态信息、所述第二条件、以及所述第二种资源的实时状态信息，在所述多个资源提供服务器中确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。

另外，在根据本公开实施例的方法中，在所述资源信息服务器，通过以下处理来确定所述搜索结果：基于所述第一条件，在与所述第一种资源对应的第一资源信息列表中，筛选满足所述第一条件的候选第一资源集合，在所述候选第一资源集合中，每个候选第一资源的可用余量信息与每个候选第一资源所对应的资源提供服务器的候选标识相关联地存储，并且所述候选标识所对应的资源提供服务器能够提供所述第一种资源和所述第二种资源；基于所述候选标识，在与所述第二种资源对应的第二资源信息列表中，提取候选第二资源集合，在所述候选第二资源集合中，所述候选标识与所述候选标识所对应的资源提供服务器上第二种资源的可用余量信息相关联地存储；基于所述第二条件，在所述候选第二资源集合中，删除不满足所述第二条件的候选标识，并将剩余的候选标识所对应的候选资源提供服务器器作为所述搜索结果。

另外，在根据本公开实施例的方法中，所述第一种资源的分配优先级高于所述第二种资源的分配优先级。

另外，在根据本公开实施例的方法中，在与每一种资源对应的资源信息列表中，按照该种资源的可用余量多少的顺序来排序该种资源所对应的资源提供服务器的标识。

另外，在根据本公开实施例的方法中，基于所述至少一组可分配资源，向终端执行资源分配，包括：当在所述资源信息服务器上存储的多种资源中成功地锁定并扣除从所述至少一组可分配资源中选择的一组资源时，将所选择的一组资源作为待分配资源；向所述终端发送所述待分配资源所对应的目标资源提供服务器的信息。

另外，在根据本公开实施例的方法中，在向用户执行资源分配之后，进一步包括：向所述目标资源提供服务器通知创建用于所述终端的处理进程，其中当所述处理进程被在所述目标资源提供服务器成功创建时，从所述目标资源提供服务器接收用于确认资源已分配的上报数据；当预定时间段内未从所述目标资源提供服务器接收到用于确认资源已分配的上报数据时，更新在所述资源信息服务器上存储的实时状态信息，以释放所述目标资源提供服务器上的所述待分配资源。

另外，在根据本公开实施例的方法中，所述目标资源提供服务器包括目标网关服务器和目标服务提供服务器，并且在向所述目标资源提供服务器通知创建用于所述终端的处理进程之后，所述方法进一步包括：在所述处理进程被在所述目标服务提供服务器上创建之后，由所述目标网关服务器在所述目标服务提供服务器与所述终端之间中转数据。

另外，在根据本公开实施例的方法中，由所述目标网关服务器在所述目标服务提供服务器与所述终端之间中转数据，包括：基于来自所述终端的反馈确认信息，确定网络延迟是否大于预定阈值；当所述网络延迟大于所述预定阈值时，丢弃来自所述目标服务提供服务器的部分数据，并将剩余的数据发送给所述终端。

另外，在根据本公开实施例的方法中，所述资源提供服务器的标识包括第一位置标识和第二位置标识，其中所述第一位置标识指示所述资源提供服务器的逻辑地址，且所述第二位置标识指示在所述资源提供服务器上的不同存储区域，并且其中每组可分配资源对应于一个候选资源提供服务器的同一第一位置标识和同一第二位置标识。

另外，在根据本公开实施例的方法可以进一步包括：定期地从配置数据库读取与所述资源提供服务器相关的配置数据；以及基于所述配置数据，更新所述资源信息服务器中存储的信息。

根据本公开的另一方面，提供了一种用于云服务的资源分配系统，包括：多个资源提供服务器，用于提供实现云服务的各种资源；资源分配服务器，用于基于来自终端的资源分配请求，确定用于搜索至少一种资源的搜索条件，所述搜索条件包括对于所述至少一种资源中每种资源的资源量需求；以及资源信息服务器，用于获取用于提供所述云服务的多种资源的实时状态信息，其中，所述各种资源中每种资源的实时状态信息被独立地存储，所述多种资源中的每种资源的实时状态信息包括在多个资源提供服务器中该种资源的可用余量信息，并且该种资源的实时状态信息与对应的资源提供服务器的标识被相关联地存储在与该种资源对应的资源信息列表中；基于所述可用余量信息，在所述多个资源提供服务器中确定具有与所述搜索条件匹配的所述至少一种资源的至少一个候选资源提供服务器；基于所确定的至少一个候选资源提供服务器，确定对应所述资源分配请求的至少一组可分配资源，其中每组可分配资源对应于一个候选资源提供服务器，其中所述资源分配服务器基于所述至少一组可分配资源，向所述终端执行资源分配。

根据本公开的又一方面，提供了一种计算机可读记录介质，其上存储有计算机程序，当由存储器执行所述计算机程序时，实现上文中所述的方法。

在所述方法和系统中，为云服务平台提供了完善的资源记录、资源分配、资源回收等能力。由于将各种资源的实时状态信息独立地存储，且通过键值对(key-value)的方式关联资源提供服务器与相应的可用余量信息，从而可以容易地应对资源类型由于业务的发展而增多所带来的扩展问题。例如，如果业务新增了某种资源，则只需要新增一个key即可。并且，各种资源的更新方式各不相同，分开存储也能单独地更新某种具体资源的变化。例如，除了传统的gpu、cpu、内存和网络带宽等资源外，还可以提供特定的版本匹配、服务器存活检查、地域匹配、标签匹配等。

此外，能够通过redis(一种互联网流行的nosql存储系统)提供的取交集指令，实现所需要的资源的各种过滤。程序代码变得很简单。并且，由于将资源搜索操作全部或部分地交由资源信息服务器来完成，因此这个过程极大地降低了与资源分配服务器之间的交互数据量，而只需要从资源分配服务器接收某些指令并向资源分配服务器发送搜索结果。从而，降低了对带宽的要求并减少了搜索所需的时间。例如，在百万用户在线、十万台服务器、上千万cpu核、几十万gpu卡的规模下，分配资源的时延不超过10ms。

另外，通过在各种资源信息列表中基于各种资源的可用余量来排序，能够筛选出最接近搜索条件的资源，尽可能地减少资源碎片，提高资源的利用率，减少云端资源的闲置。

并且，通过各个资源提供服务器的及时的数据上报，即使资源信息服务器中存储的数据全部丢失，整个系统的状态也能在短时间(如，1分钟)内完全重建。

附图说明

图1示出了本公开的实施例的应用环境；

图2是图示根据本公开的实施例的用于云服务的资源分配方法的过程的流程图；

图3是图示根据本公开的实施例的资源信息写入的过程的流程图；

图4是图示根据本公开的另一种实施例的资源分配方法的过程的流程图；

图5是图示根据本公开实施例的资源分配系统的配置的功能性框图；

图6示出了采用读写分离的资源信息服务器的示意性架构图；

图7示出了用于云服务的资源分配系统的整体架构图；

图8示出了各个服务进程的软件结构图；

图9示出了用于云服务的资源分配系统的部署图；

图10示出了用于云服务的资源分配系统的用例图；以及

图11是根据本公开实施例的一种示例性的计算设备的架构的示意图。

具体实施方式

下面将参照附图对本发明的各个优选的实施方式进行描述。提供以下参照附图的描述，以帮助对由权利要求及其等价物所限定的本发明的示例实施方式的理解。其包括帮助理解的各种具体细节，但它们只能被看作是示例性的。因此，本领域技术人员将认识到，可对这里描述的实施方式进行各种改变和修改，而不脱离本发明的范围和精神。而且，为了使说明书更加清楚简洁，将省略对本领域熟知功能和构造的详细描述。

首先，将简要描述本公开的实施例的应用环境。如图1所示，服务器集群10通过网络30连接到多个终端设备20。所述终端设备20可以是智能终端，例如智能电话、pda(个人数字助理)、台式计算机、笔记本计算机、平板计算机等，也可以是其他类型的终端。所述服务器集群10为下文所述的用于云服务的资源调度系统。所述服务器集群10可以包括多个服务器，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn(contentdeliverynetwork)、以及大数据和人工智能平台等基础云计算服务的云服务器。可以将服务器集群10看作是用于提供云服务的后台服务器。例如，服务器集群10可以经由数据的前端实现与用户的交互。例如，该数据的前端可以是用户所使用的终端设备上安装的数据应用。所述网络30可以是任何类型的有线或无线网络，例如因特网。应当认识到，图1所示的终端设备20的数量是示意性的，而不是限制性的。

另外，图1中所示的服务器集群10还可以作为数据共享系统中的一个节点。数据共享系统是指用于进行节点与节点之间数据共享的系统，该数据共享系统中可以包括多个节点，多个节点可以是指上文中所述的服务器集群10。每个节点在进行正常工作可以接收到输入信息，并基于接收到的输入信息维护该数据共享系统内的共享数据。为了保证数据共享系统内的信息互通，数据共享系统中的每个节点之间可以存在信息连接，节点之间可以通过上述信息连接进行信息传输。例如，当数据共享系统中的任意节点接收到输入信息时，数据共享系统中的其他节点便根据共识算法获取该输入信息，将该输入信息作为共享数据中的数据进行存储，使得数据共享系统中全部节点上存储的数据均一致。

对于数据共享系统中的每个节点，均具有与其对应的节点标识，而且数据共享系统中的每个节点均可以存储有数据共享系统中其他节点的节点标识，以便后续根据其他节点的节点标识，将生成的区块广播至数据共享系统中的其他节点。每个节点中可维护一个如下表所示的节点标识列表，将节点名称和节点标识对应存储至该节点标识列表中。

数据共享系统中的每个节点均存储一条相同的区块链。区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链由多个区块组成。创始块中包括区块头和区块主体，区块头中存储有诸如输入信息特征值、时间戳之类的关于作为一个节点的服务器集群的特征信息，区块主体中存储有输入信息。例如，所述输入信息可以是服务器集群中的资源的实时状态信息。创始块的下一区块以创始块为父区块，下一区块中同样包括区块头和区块主体，区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、时间戳等关于作为一个节点的服务器集群的特征信息，并以此类推，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。通过将不同的服务器集群作为区块链中的一个节点，可以防止服务器集群中的数据的丢失和篡改，提高了数据安全性。

例如，所述云服务可以是云游戏服务。云游戏(cloudgaming)又可称为游戏点播(gamingondemand)，是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thinclient)能运行高品质游戏。在云游戏场景下，游戏并不在玩家游戏终端，而是在云端服务器中运行，并由云端服务器将游戏场景渲染为视频音频流，通过网络传输给玩家游戏终端。玩家游戏终端无需拥有强大的图形运算与数据处理能力，仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。

当然，本公开并不仅限于此。例如，所述云服务也可以是人工智能云服务。所谓人工智能云服务，一般也被称作是aiaas(aiasaservice，中文为“ai即服务”)。具体来说，aiaas平台会把几类常见的ai服务进行拆分，并在云端提供独立或者打包的服务。这种服务模式类似于开了一个ai主题商城：所有的开发者都可以通过api接口的方式来接入使用平台提供的一种或者是多种人工智能服务，部分资深的开发者还可以使用平台提供的ai框架和ai基础设施来部署和运维自已专属的云人工智能服务。在人工智能云服务场景下，人工智能算法并不在用户的终端设备，而是在云端服务器中运行，并由云端服务器将处理结果通过网络传输给用户的终端设备。用户的终端设备无需拥有强大的运算与数据处理能力，仅需拥有基本的数据传输能力即可。可以理解，除此之外，任何其他的分布式计算的应用场景也可以类似地应用于本公开，且包括在本公开的范围内。

接下来，将参照图2描述根据本公开实施例的、用于云服务的资源分配方法。所述资源分配方法是由资源分配系统，即图1中的服务器集群来执行的。资源分配系统可以包括提供实现云服务的各种资源的资源提供服务器、用于执行资源分配的资源分配服务器以及用于记录资源实时状态的资源信息服务器。资源分配方法本质上就是在多个资源提供服务器中搜索最合适的资源分配给终端设备。如图2所示，所述方法包括以下步骤。

首先，在步骤s201，基于来自终端的资源分配请求，确定用于搜索至少一种资源的搜索条件，所述搜索条件包括对于所述至少一种资源中每种资源的资源量需求。该步骤s201可以由下文中将描述的资源分配服务器来执行。例如，在云游戏的应用场景下，来自终端的资源分配请求可以包括期望进行的游戏类型、游戏名称等信息。根据游戏类型、游戏名称等信息来确定所需要的资源量。例如，可以预先存储不同的游戏和相应的资源量需求的关联表，通过查找该关联表来确定资源量需求。例如，所述至少一种资源可以是图形处理单元(gpu)、中央处理单元(cpu)、内存等中的至少一种。

然后，在步骤s202，获取用于提供所述云服务的多种资源的实时状态信息。其中，在资源信息服务器中，所述多种资源中每种资源的实时状态信息被独立地存储，所述多种资源中的每种资源的实时状态信息包括在多个资源提供服务器中该种资源的可用余量信息，并且该种资源的实时状态信息与对应的资源提供服务器的标识被相关联地存储在与该种资源对应的资源信息列表中。其中，所述资源提供服务器的标识可以包括第一位置标识和第二位置标识，其中所述第一位置标识指示所述资源提供服务器的逻辑地址，且所述第二位置标识指示在所述资源提供服务器上的不同存储区域。下面以第一位置标识为ip地址，且第二位置标识为非统一内存访(numa)id为例进行说明。

如上文中所述，例如，用于提供所述云服务的多种资源可以包括gpu、cpu等。可以认为多个资源提供服务器所提供的资源池是一张很大的表，如下表一所示：

在上表一中，资源提供服务器的标识包括资源提供服务器的ip地址和非统一内存访(numa)id。numa是一种用于多处理器的电脑记忆体设计，内存访问时间取决于处理器的内存位置。在numa下，处理器访问它自己的本地存储器的速度比非本地存储器(存储器的地方到另一个处理器之间共享的处理器或存储器)更快。在云服务环境中，一台资源提供服务器对应于一个唯一的ip地址，并且拥有不止一个numa分区，换言之包括多个numaid。在表一中，示出了一台资源提供服务器具有两个numa分区的情况。这里ip是第一位置标识的一种示例，且numaid是第二位置标识的一种示例。另外，在表一中，作为示例，示出了gpu和cpu这两种资源，且可用余量信息为gpu的剩余算力和cpu的剩余算力。

下文中将要描述的搜索资源的过程就是在例如以上所示的表一中执行过滤，可以用伪代码表示如下：

selectip,numaid,gpuid,cpuid

fromresourcepool

wheregpu_remainingcomputingpower>＝requiredgpucomputingpowerandcpu_remainingcomputingpower>＝requiredcpucomputingpower

orderbyremainingcomputingpowerasc

limit1

并且，资源的类型可能随着的业务的发展而不断增多，这时对新资源的搜索就相当于在where部分增加更多的搜索条件。

例如，作为一种可能的实施方式，资源信息服务器可以是redis服务器。redis服务器是一种高性能的nosql系列的非关系型存储系统。在redis服务器中，可以基于键值(key-value)结构来存储上述表一。

例如，在key-value结构中，可以采用二级key。其中，第一级key指示资源种类(例如，gpu、cpu等)，第二级key指示该种资源的所处的资源提供服务器的标识(如，ip地址和numaid)，并且与第二级key相关联地存储对应的实时状态信息(如，剩余算力)作为value。或者，可替代地，第一级key也可以将资源种类与地理区域相结合。举例而言，第一级key可以为cpu_地理区域(如，cpu_广州)。第二级key指示该种资源的所处的资源提供服务器的标识(如，ip地址和numaid)，并且与第二级key相关联地存储对应的实时状态信息(如，剩余算力)作为value。

通过在redis服务器中以key-value结构来存储各种资源的实时状态信息，可以将每一个key看作上表一中的一列，多个key-value就像以列存储的方式来拆分了上表一。当某种资源的实时状态更新时，只需要更新第一级key下面的某个第二级key。并且，当资源的种类随着业务的发展而不断增多时，只需要增加更多的key-value，就可以更容易地扩展资源分配系统。

然后，在步骤s203，基于所述可用余量信息，在所述多个资源提供服务器中确定具有与所述搜索条件匹配的所述至少一种资源的至少一个候选资源提供服务器。

接下来，在步骤s204，基于所确定的至少一个候选资源提供服务器，确定对应所述资源分配请求的至少一组可分配资源，其中每组可分配资源对应于一个候选资源提供服务器。其中，每组可分配资源对应于一个候选资源提供服务器的相同的第一位置标识和第二位置标识。

作为一种可能的实施方式，步骤s203和步骤s204的处理也可以完全由资源信息服务器来执行。在这种情况下，不需要将资源信息服务器上存储的资源信息发送到资源分配服务器，而是直接在资源信息服务器上执行资源搜索处理。在资源信息服务器上，基于所述可用余量信息，在所述多个资源提供服务器中确定所述至少一个候选资源提供服务器。例如，所述搜索条件可以包括针对第一种资源的第一条件和针对第二种资源的第二条件。在这种情况下，在资源信息服务器上，基于所述第一条件、所述第一种资源的实时状态信息、所述第二条件、以及所述第二种资源的实时状态信息，在所述多个资源提供服务器中确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。

作为一种可能的实施方式，在所述资源信息服务器，可以通过以下处理来确定所述搜索结果。

首先，基于所述第一条件，在与所述第一种资源对应的第一资源信息列表中，筛选满足所述第一条件的候选第一资源集合。在所述候选第一资源集合中，每个候选第一资源的可用余量信息与每个候选第一资源所对应的资源提供服务器的候选标识相关联地存储。并且，所述候选标识所对应的资源提供服务器能够提供所述第一种资源和所述第二种资源。假设第一种资源为gpu资源，且第一条件为剩余算力大于等于30。例如，在以redis服务器来实现资源信息服务器的情况下，可以使用redis命令来执行上述筛选。具体地，可以通过以下代码来实现基于第一条件的筛选处理。

##选择gpu算力至少为30的机器列表

zrevrangebyscoregpu

"+inf"##最大值不限

30##最小值30

withscores

limit0100##分页拉取

通过以上代码，在原有的第一资源信息列表的基础上，可以筛选出gpu剩余算力大于等于30的候选第一资源集合。假设第一资源信息列表是包含1000个元素的列表，那么经过基于第一条件的第一次筛选之后，假设获得包含例如400个元素的候选第一资源集合。

例如，在与每一种资源对应的资源信息列表中，可以按照该种资源的可用余量(如，gpu的剩余算力)多少顺序(如，从小到大的顺序)来排序该种资源所对应的资源提供服务器的标识。在采用这样的有序集的情况下，筛选出的候选第一资源集合中的各资源提供服务器的标识也是按照资源的可用余量而有序排列的。例如，在第一种资源为gpu资源且第一条件为剩余算力大于等于30的情况下，在候选第一资源集合中，剩余算力越接近30的gpu所在的资源提供服务器的标识越排在前面。

在候选第一资源集合例如包括400个元素的情况下，如上面的代码所示，可能仅拉取这400个元素中的例如前100个元素进行后续的筛选，只要这100个元素中存在同样满足第二条件的元素即可。因此，有序排列可以确保剩余算力最接近30的资源提供服务器的标识能够被拉取并参与后续的筛选。从而，当期望搜索剩余算力大于等于30的gpu资源时，能够最大可能地从gpu剩余算力最接近30的资源提供服务器中选择候选者，而不是任意地选择(例如，选择gpu剩余算力与30差异大(如，gpu剩余算力80)的资源提供服务器)。这样，有助于最大程度地避免资源碎片的产生，进而提升整体的资源分配系统的资源利用率。

然后，基于所述候选标识，在与所述第二种资源对应的第二资源信息列表中，提取候选第二资源集合，在所述候选第二资源集合中，所述候选标识与所述候选标识所对应的资源提供服务器上第二种资源的可用余量信息相关联地存储。例如，这可以通过以下代码来实现：

zadd${temp_key_gpu}##将候选第一资源集合中的值写入0

0ip1

0ip2

##gpu的集合与cpu的集合取交集，并且把值进行累加。因为之前

gpu的value写入为0，所以交集之后的value是cpu的资源值。

zinterstore${temp_key}_cpu2${temp_key_gpu}cpu

weights1

aggregatesum

在以上代码中，首先通过zadd指令将候选第一资源集合中与各个资源提供服务器的标识对应的gpu的剩余算力清零。由于gpu的资源信息列表与cpu的资源信息列表的格式相同(即，资源提供服务器的标识的格式相同)，因此可以通过zinterstore指令将候选第一资源集合与第二资源信息列表取交集。例如，通过zinterstore指令的取交集操作可以使用的聚合函数为sum，即在做交集操作时将不同集合中相同的成员(相同的服务器标识)所对应的分值(可用余量信息)相加，然后聚合成一个新的集合，即候选第二资源集合。由于在基于第一条件的筛选后，已经将得到的候选第一资源集合中与服务器标识对应的gpu的可用余量信息(如，剩余算力值)清零，因此在候选第二资源集合中，与服务器标识对应的就是cpu的可用余量信息(如，cpu核数)。

然而，这样得到的候选第二资源集合是尚未执行基于第二条件的筛选的集合。因此，接下来，基于所述第二条件，在所述候选第二资源集合中，删除不满足所述第二条件的候选标识，并将剩余的候选标识所对应的候选资源提供服务器作为所述搜索结果。假设第二条件是cpu核数大于等于8。例如，这可以通过以下代码来实现：

#在剩余的集合中，删除不符合条件的记录。假设需要cpu的核数为8

zremrangebyscore${temp_key}_cpu

"-inf"

8##删除cpu的核数小于8的机器

在以上代码中，删除了cpu核数小于8的资源提供服务器的候选标识，并保留cpu核数大于等于8的资源提供服务器的候选标识。

如上文中所述，各个资源信息列表都是按照可用余量的大小的顺序排列的有序集合，并且在基于第一条件的搜索中，可能会仅选择第一资源的剩余算力最接近第一条件的服务器标识，而丢弃与第一条件差异大的服务器标识，因此在存在两个搜索条件，即第一条件和第二条件的情况下，将优先地选择具有最接近第一条件的第一资源的服务器标识，相比之下，基于第二条件的筛选未必得到的都是具有最接近第二条件的第二资源的服务器标识。因此，通常而言，将对于实现云服务而言最重要的资源设置为第一资源，且优先地执行基于针对第一资源的第一条件的筛选。换言之，所述第一种资源的分配优先级高于所述第二种资源的分配优先级。

在上文中，描述了搜索条件包括两个条件的情况。但是，本公开并不仅限于此。也可以包括三个或更多个搜索条件。并且，当包括更多个搜索条件时，仍然通过与上文中类似的处理，逐个地基于各个搜索条件进行筛选。这里需要指出的是，在执行完基于当前条件的筛选后，需要将得到的集合中各成员(即，服务器标识)所对应的分值(即，当前资源的可用余量)清零，以便在执行下一条件的筛选时，考虑下一资源的可用余量。例如，在redis服务器中，可以通过集合自己与自己取交集的方式，来清空所有的value。具体代码如下：

zinterstore${temp_key}_cpu1${temp_key}_cpu

weights0

aggregatesum

其中，由于相同成员的分值相加后需要乘以weights，因此将weights置为0，可以使得通过zinterstore指令执行取交集操作之后，各成员所对应的分值为0。

例如，除了上文中所述的第一条件和第二条件之外，搜索条件还可以进一步包括第三条件。假设第三条件为资源提供服务器的存活时间大于预定时间段(如，60秒)。在这种情况下，在与第三资源对应的第三资源信息列表中，相关联地存储资源提供服务器的标识与存活信息。例如，存活信息中记录了相应的资源提供服务器的最后更新时间戳。如果超过一定的时间未更新，就认为机器已经死机。在通过上文中的cpu过滤且cpu的可用余量信息已被清零后得到的候选第二资源集合的基础上，进一步执行基于第三条件的筛选。具体地，可以通过以下代码来实现基于第三条件的筛选。

zinterstore${temp_key}_alive2${temp_key}_cpu

weights1

aggregatesum

zremrangebyscore${temp_key}_alive

"-inf"

unix_timestamp()-60##删除超过60秒都未更新的机器

与基于第二条件的筛选处理类似地，基于第三条件的筛选同样是首先通过zinterstore指令执行取交集操作，然后再根据第三条件删除不符合条件的成员(即，服务器标识)。

在上文中描述了首先执行基于第一条件的筛选，然后通过取交集操作并在交集中删除不满足第二条件的成员来实现在所述多个资源提供服务器中确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。但是，本公开并不仅限于此。例如，可替代地，也可以并行地执行基于第一条件的筛选和基于第二条件的筛选。然后，将两个筛选后的集合取交集，以确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。

或者，作为一种另可能的实施方式，步骤s203和步骤s204的处理可以由资源分配服务器(更具体地，位于资源分配服务器上的资源分配服务进程)和资源信息服务器彼此配合地完成。在这种情况下，首先由资源分配服务器执行步骤s202的处理，以从资源信息服务器获取各种资源的实时状态信息，然后在资源分配服务器中执行步骤s203中的一部分搜索处理。例如，所述搜索条件可以包括针对第一种资源的第一条件和针对第二种资源的第二条件。在这种情况下，可以在资源分配服务器上执行基于第一条件的筛选。然后将筛选后的结果发送到资源信息服务器，并在资源信息服务器上执行步骤s203中的另一部分的搜索处理，例如，基于第二条件的筛选。最终，由资源信息服务器执行步骤s204的处理，以确定至少一组可分配资源。并且，资源信息服务器将关于确定出的至少一组可分配资源的信息发送到资源分配服务器。基于第一条件的筛选和基于第二条件的筛选的具体处理细节与上文中所述的类似，这里不再赘述。

或者，作为再一种可能的实施方式，步骤s203和步骤s204的处理也可以完全由资源分配服务器来执行。在这种情况下，首先由资源分配服务器执行步骤s202的处理，以从资源信息服务器获取各种资源的实时状态信息。然后，由资源分配服务器执行步骤s203和步骤s204的处理以确定至少一组可分配资源。例如，所述搜索条件可以包括针对第一种资源的第一条件和针对第二种资源的第二条件。在这种情况下，在资源分配服务器上，基于所述第一条件、所述第一种资源的实时状态信息、所述第二条件、以及所述第二种资源的实时状态信息，在所述多个资源提供服务器中确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。

所述资源信息服务器可以包括主服务器和至少一个从服务器，且所述主服务器和所述至少一个从服务器之间通过同步保持数据的一致性。通过配置主服务器和至少一个从服务器，如果主服务器突然由于故障而无法提供服务，则可以立即将其中的一台从服务器设置为主服务器，继续提供服务，从而能够提升整个服务器集群的可用性。例如，在资源信息服务器是redis服务器的情况下，redis服务器可以包括主服务器(redismaster)和从服务器(redisslave)。

另外，为了进一步扩容系统的处理能力，作为一种可能的实施方式，可以将主服务器和至少一个从服务器配置为分别负责不同的处理操作，以便于减轻主服务器的处理压力。例如，可以将上文中所述的步骤s202的读取处理设置为从从服务器中读取各种资源的实时状态信息。另外，可以将步骤s203和步骤s204中的搜索处理设置为由从服务器执行。并且，可以将主服务器配置为执行写入操作。

图3示出了根据本公开实施例的资源信息写入的流程。如图3所示，首先，在步骤s301，位于终端设备处的用户进入云服务应用(如，云游戏应用)并使用云服务(如，进行游戏)。然后，在步骤s302，由资源提供服务器向资源分配服务器中的上报接口上报该进入事件。接下来，在步骤s303，由上报接口向资源信息服务器写入各种资源的实时状态信息。另外，当在步骤s304，用户退出云服务应用时，在步骤s305，资源提供服务器同样地向资源分配服务器中的上报接口上报该退出事件。并且，在步骤s306，由上报接口向资源信息服务器写入各种资源的实时状态信息。以上步骤s301至步骤s306为基于事件的资源信息的写入过程。

在步骤s307，由上报接口检查用户的排队情况。并且，在步骤s308，对于排队用户，由上报接口向资源信息服务器申请资源。

另外，在步骤s309，资源提供服务器执行其所具有各种资源的实时状态信息的统计。并且，在步骤s310，将统计的实时状态信息定时地(例如，按照第一预定时间间隔)上报给资源分配服务器的上报接口。然后，在步骤s311，由上报接口基于所述上报数据对资源信息服务器上存储的信息执行修改。在步骤s312，在资源信息服务器中，修改ip和numa节点上的资源数，并且，在步骤s313中，修改具体的gpu、cpu等资源数。这里，步骤s312和步骤s313的处理可以是在所述主服务器上执行的。最后，在步骤s314，在完成修改后向上报接口返回修改成功的信息。

另外，资源分配服务进程可以在资源分配服务器上实现，并且用于执行与资源分配相关的处理。所述方法还包括资源分配服务进程定期地从配置数据库读取与所述资源提供服务器相关的配置数据。这里，与各种资源的实时状态不同，配置数据是与服务器集群的运营过程中的各种事件相关，例如某些资源提供服务器的上架、下架等，通常是实时性不强的数据。配置数据被单独地存储在配置数据服务器中。然后，基于所述配置数据，更新所述资源信息服务器中存储的信息。例如，当基于所述配置数据确定某一个资源提供服务器被下架时，可以由资源分配服务进程指示资源信息服务器(如，主服务器)以将所述资源信息服务器中存储的、与该资源提供服务器相关联的可用余量信息清零。

并且，按照第二预定时间间隔，将所述主服务器上存储的用于提供所述云服务的多种资源的实时状态信息同步到所述至少一个从服务器。这里的第一预定时间间隔和第二预定时间间隔可以相同，也可以不同，并不特别地限定，可以根据实际设计要求灵活地设置。上述各个上报以及同步的步骤贯穿于云服务提供处理的始终。

作为用于进一步扩容系统的处理能力的另一种方式，可以限定一个区域(如，某一地理区域)内能够处理的终端数量的上限(如，10万台)，以避免单个区域终端数量过大而引起系统过载。当请求资源分配的终端数量超过上限时，使得超出上限的终端进入排队状态以等待进行资源分配。

在上文中所述的步骤s203中，在所述多个资源提供服务器中确定具有与所述搜索条件匹配的所述至少一种资源的至少一个候选资源提供服务器所基于的可用余量信息是指每一种资源的总的可用余量信息。

假设至少一种候选资源包括gpu和cpu的资源。在这种情况下，如上文中所述，独立地存储gpu和cpu资源的实时状态信息，并且所述实时状态信息包括在多个资源提供服务器中gpu资源的总的可用余量信息以及cpu资源的总的可用余量信息，并且该种资源的实时状态信息与对应的资源提供服务器的标识被相关联地存储在与该种资源对应的资源信息列表中。

例如，在上文中以key-value结构来存储各种资源的可用余量信息的情况下，一级key是资源类型，例如，当一级key是gpu资源时，二级key是gpu资源所在的资源提供服务器的标识(指示其位置，如ip地址和numaid)，且与二级key对应的value是该位置处所有gpu资源的总的可用余量信息(如，剩余算力值)。当一级key是cpu资源时，二级key是cpu资源所在的资源提供服务器的标识(指示其位置，如ip地址和numaid)，且与二级key对应的value是该位置处所有cpu资源的总的可用余量信息(如，剩余算力值)。

然而，对于每个资源提供服务器，其每种资源包括多个子资源。例如，在一个资源提供服务器上，可能存在多个gpu卡或者多个cpu核。每种资源的可用余量信息可以包括所述多个子资源的可用余量信息。例如，在资源信息服务器中，如果将上文中所述的key-value结构称作第一种key-value结构，那么还可以进一步包括第二种key-value结构。在第二种key-value结构中，一级key是资源提供服务器的标识(如，ip地址和numaid)，二级key是子资源标识(即，具体的资源，如，gpuid或cpuid等)，且与二级key对应的value是该具体资源的可用余量信息。在确定出至少一个候选资源提供服务器之后，可以通过查找第二种key-value结构，进一步确定与该候选资源服务器对应的各个子资源的可用余量信息。

步骤s203的处理是用于在多个资源提供服务器之中，确定哪个或哪些资源提供服务器可以提供资源。在此基础之上，步骤s204的处理是用于在确定出的、能够提供资源的资源提供服务器中，确定具体使用哪些资源，例如使用哪个或哪些gpu或cpu。具体地，所述基于所确定的至少一个候选资源提供服务器，确定对于所述资源分配请求的至少一组可分配资源，包括：基于所述至少一个候选资源提供服务器处的每种资源的各个子资源的可用余量信息，确定满足所述搜索条件的各个资源的至少一个子资源作为所述至少一组可分配资源。例如，筛选具体的gpu可以通过以下代码实现：

#假设需要30的gpu算力，则筛选出某个具体ip上剩余算力大于等于30的所有gpuid

zrangebyscore${cgs_ip}_${numa}_gpu30“+inf”

筛选cpu的方法与以上筛选gpu的方法类似。另外，在除了对于cpu存在剩余算力的要求之外，还需要满足对核的个数的要求的情况下，可以首先筛选出所有满足cpu剩余算力的cpuid的列表，然后再从中随机地选出要求数量的核。

返回参照图2，在步骤s204之后，处理进行到步骤s205。在步骤s205，基于所述至少一组可分配资源，向所述终端执行资源分配。

例如，基于所述至少一组可分配资源，向终端执行资源分配可以包括以下步骤。

例如，当在同时为多个终端搜索资源时，为了防止多个终端可能同时选中相同的资源提供服务器以及其上的相同资源，在确定出期望选择的资源提供服务器以及其上的一组可分配资源后，且在真正开始分配之前，可以预先在资源信息服务器上锁定并扣除期望选中的资源。如果期望选择的资源提供服务器已被占用，则更换另一个候选的资源提供服务器。如果资源提供服务器上的一组可分配资源已被占用，则更换另一组可分配资源。当在所述资源信息服务器上存储的多种资源中成功地锁定并扣除从所述至少一组可分配资源中选择的一组资源时，将所选择的一组资源作为待分配资源。并且，向所述终端发送所述待分配资源所对应的目标资源提供服务器的信息，以便于终端在后面的处理中建立与目标资源提供服务器的连接。另一方面，如果未能在所述资源信息服务器上存储的多种资源中成功地锁定并扣除所述至少一组可分配资源中的任意一组，则分配失败。

另外，在向用户执行资源分配之后，还可以进一步包括确认待分配的资源是否已经实际地用于创建用于提供服务的进程(如，是否已经创建了玩家的游戏进程)的步骤(图2中未示出)。超过预定时间未用于创建进程的资源将被回收。具体来说，首先向所述目标资源提供服务器通知创建用于所述终端的处理进程。当所述处理进程被在所述目标资源提供服务器成功创建时，从所述目标资源提供服务器接收用于确认资源已分配的上报数据。

另一方面，当由于某些原因(如，终端掉线等)预定时间段内未从所述目标资源提供服务器接收到用于确认资源已分配的上报数据时，更新在所述资源信息服务器上存储的实时状态信息，以释放所述目标资源提供服务器上的所述待分配资源。

资源提供服务器可以包括网关服务器和服务提供服务器这两种类型。并且相应地，资源提供服务器所提供的资源也包括用于实际地实现服务(如，游戏)的服务资源以及用于保障终端与服务器集群之间的通信的带宽资源这两种类型。上文中所述的用于提供gpu、cpu、内存等处理能力的资源提供服务器可以认为属于服务提供服务器。而网关服务器是用于提供带宽资源的服务器。相应地，目标资源提供服务器可以包括目标网关服务器和目标服务提供服务器。

在向所述目标资源提供服务器通知创建用于所述终端的处理进程之后，所述方法进一步包括：在所述目标服务提供服务器上创建所述处理进程；以及由所述目标网关服务器在所述目标服务提供服务器与所述终端之间中转数据。

例如，作为一种可能的实施方式，例如，在云服务包括视频相关功能的场景下，网关服务器可以不只是简单的代理，而是能够根据终端的网络回包来判断网络延迟的情况，并据此来丢弃部分视频帧，以保障视频画面的实时性。具体地，由所述目标网关服务器在所述目标服务提供服务器与所述终端之间中转数据可以包括：基于来自所述终端的反馈确认信息，确定网络延迟是否大于预定阈值；并且当所述网络延迟大于所述预定阈值时，丢弃来自所述目标服务提供服务器的部分数据，并将剩余的数据发送给所述终端。

图4示出了根据本公开的另一种实施例的资源分配方法的流程。在步骤s401，由位于分配服务器中的资源分配服务进程定期地从资源信息服务器中加载配置数据，并且在步骤s402，将加载的配置数据缓存在本地。在步骤s403至步骤s405，响应于终端的资源分配请求，资源分配服务进程通过查询ip数据库来确定终端所在的区域以及运营商。然后，在步骤s406至步骤s411，执行诸如签名检查、解密、游戏停服状态检查、全局停服状态检查、测试逻辑以及在本地缓存中检查各种配置之类的鉴权、参数检查等基本准备工作。在步骤s412至步骤s413，检查排队情况并返回是否已经排到。如果已经排到，则在步骤s414，执行资源搜索操作。

在图4中，示出了完全在资源信息服务器上执行资源搜索操作的情况。在步骤s415至步骤s416，搜索具有各种匹配的资源的资源提供服务器的集合，并且与资源服务器的标识(如，ip+numaid)相关联地返回所有可用的资源。在步骤s417，向资源分配服务返回多组可用的资源。在步骤s418，资源分配服务可以进一步执行其他的业务上的过滤行为。例如，可以基于在步骤s401中加载的配置数据，执行删除黑名单中所列的服务器和/或资源的操作。然后，在步骤s419，选定多组可分配资源。并且，在步骤s420，通过批处理将多组可分配资源的信息发送到资源信息服务器。并且，在步骤s421和步骤s422，执行总资源的锁定和扣除以及具体子资源的锁定和扣除。如果在步骤s421和步骤s422，存在一组成功锁定并扣除的资源，则在步骤s423，向资源分配服务返回指示分配成功的消息，否则返回指示分配失败的消息。并且，如果在s423返回指示分配失败的消息，则在步骤s424，可以尝试在不同的区域执行类似的搜索处理。例如，如果在广州区域内未搜索到合适的资源，则可以进一步在深圳区域内搜索。最后，在s425，向终端设备返回分配成功或失败的信息。

在上文中，详细描述了根据本公开的各种实施例的资源分配方法的具体过程。在上述资源分配方法中，由于将各种资源的实时状态信息独立地存储，且通过键值对(key-value)的方式关联资源提供服务器与相应的可用余量信息，从而可以容易地应对资源类型由于业务的发展而增多所带来的扩展问题。例如，如果业务新增了某种资源，则只需要新增一个key即可。并且，各种资源的更新方式各不相同，分开存储也能单独地更新某种具体资源的变化。例如，除了传统的gpu、cpu、内存和网络带宽等资源外，还可以提供特定的版本匹配、服务器存活检查、地域匹配、标签匹配等。

此外，能够通过redis提供的取交集指令，实现所需要的资源的各种过滤。程序代码变得很简单。并且，由于将资源搜索操作全部或部分地交由资源信息服务器来完成，因此这个过程极大地降低了与资源分配服务器之间的交互数据量，而只需要从资源分配服务器接收某些指令并向资源分配服务器发送搜索结果。从而，降低了对带宽的要求并减少了搜索所需的时间。例如，在百万用户在线、十万台服务器、上千万cpu核、几十万gpu卡的规模下，分配资源的时延不超过10ms。

另外，通过在各种资源信息列表中基于各种资源的可用余量来排序，能够筛选出最接近搜索条件的资源，尽可能地减少资源碎片，提高资源的利用率，减少云端资源的闲置。

并且，通过各个资源提供服务器的及时的数据上报，即使资源信息服务器中存储的数据全部丢失，整个系统的状态也能在短时间(如，1分钟)内完全重建。

接下来，将描述与上文中所示的资源分配方法对应的资源分配系统的具体配置。首先，图5示出了根据本公开实施例的资源分配系统500的配置的功能性框图。如图5所示，资源分配系统500包括：多个资源提供服务器501、资源分配服务器502以及资源信息服务器503。

资源提供服务器501用于提供实现云服务的各种资源。例如，资源提供服务器可以包括网关服务器和服务提供服务器这两种类型。并且相应地，资源提供服务器所提供的资源也包括用于实际地实现服务(如，游戏)的服务资源以及用于保障终端与服务器集群之间的通信的带宽资源这两种类型。上文中所述的用于提供gpu、cpu、内存等处理能力的资源提供服务器可以认为属于服务提供服务器。而网关服务器是用于提供带宽资源的服务器。相应地，目标资源提供服务器可以包括目标网关服务器和目标服务提供服务器。

资源分配服务器502用于基于来自终端的资源分配请求，确定用于搜索至少一种资源的搜索条件，所述搜索条件包括对于所述至少一种资源中每种资源的资源量需求。

资源信息服务器503用于获取用于提供所述云服务的多种资源的实时状态信息，其中，独立地存储所述各种资源中每种资源的实时状态信息，并且对于所述多种资源中的每种资源，所述实时状态信息包括在多个资源提供服务器中该种资源的可用余量信息，并且该种资源的实时状态信息与对应的资源提供服务器的标识被相关联地存储在与该种资源对应的资源信息列表中。其中，所述资源提供服务器的标识可以包括第一位置标识和第二位置标识，其中所述第一位置标识指示所述资源提供服务器的逻辑地址，且所述第二位置标识指示在所述资源提供服务器上的不同存储区域。

例如，作为一种可能的实施方式，资源信息服务器503可以是redis服务器。redis服务器是一种高性能的nosql系列的非关系型存储系统。在redis服务器中，可以基于键值(key-value)结构来存储上述表一。

例如，在key-value结构中，可以采用二级key。其中，第一级key指示资源种类(例如，gpu、cpu等)，第二级key指示该种资源的所处的资源提供服务器的标识(如，ip地址和numaid)，并且与第二级key相关联地存储对应的实时状态信息(如，剩余算力)作为value。或者，可替代地，第一级key也可以将资源种类与地理区域相结合。举例而言，第一级key可以为cpu_地理区域(如，cpu_广州)。第二级key指示该种资源的所处的资源提供服务器的标识(如，ip地址和numaid)，并且与第二级key相关联地存储对应的实时状态信息(如，剩余算力)作为value。

通过在redis服务器中以key-value结构来存储各种资源的实时状态信息，可以将每一个key看作上表一中的一列，多个key-value就像以列存储的方式来拆分了上表一。当某种资源的实时状态更新时，只需要更新第一级key下面的某个第二级key。并且，当资源的种类随着业务的发展而不断增多时，只需要增加更多的key-value，就可以更容易地扩展资源分配系统。

基于所述可用余量信息，在所述多个资源提供服务器中确定具有与所述搜索条件匹配的所述至少一种资源的至少一个候选资源提供服务器；基于所确定的至少一个候选资源提供服务器，确定对于所述资源分配请求的至少一组可分配资源，其中每组可分配资源对应于一个候选资源提供服务器。

这里，需要指出的是，如上文中所述，可以由资源信息服务器503执行资源搜索操作，也可以由资源分配服务器502和资源信息服务器503配合地执行资源搜索操作。例如，基于第一条件的筛选可以在资源分配服务器502上执行，并且基于第二条件的筛选可以在资源信息服务器503上执行。或者，也可以由资源分配服务器502执行资源操作。

在由资源信息服务器503执行资源搜索操作的情况下，不需要将资源信息服务器上存储的资源信息发送到资源分配服务器，而是在资源信息服务器上执行资源搜索处理。在资源信息服务器上，基于所述可用余量信息，在所述多个资源提供服务器中确定所述至少一个候选资源提供服务器。例如，所述搜索条件可以包括针对第一种资源的第一条件和针对第二种资源的第二条件。在这种情况下，在资源信息服务器上，基于所述第一条件、所述第一种资源的实时状态信息、所述第二条件、以及所述第二种资源的实时状态信息，在所述多个资源提供服务器中确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。

作为一种可能的实施方式，在所述资源信息服务器503，可以通过以下处理来确定所述搜索结果。

首先，基于所述第一条件，在与所述第一种资源对应的第一资源信息列表中，筛选满足所述第一条件的候选第一资源集合。在所述候选第一资源集合中，每个候选第一资源的可用余量信息与每个候选第一资源所对应的资源提供服务器的候选标识相关联地存储。假设第一种资源为gpu资源，且第一条件为剩余算力大于等于30。例如，在以redis服务器来实现资源信息服务器的情况下，可以使用redis命令来执行上述筛选。

在原有的第一资源信息列表的基础上，资源信息服务器503可以筛选出gpu剩余算力大于等于30的候选第一资源集合。假设第一资源信息列表是包含1000个元素的列表，那么经过基于第一条件的第一次筛选之后，假设获得包含例如400个元素的候选第一资源集合。

例如，在与每一种资源对应的资源信息列表中，可以按照该种资源的可用余量(如，gpu的剩余算力)的多少的预定顺序(如，从小到大的顺序)来排序该种资源所对应的资源提供服务器的标识。在采用这样的有序集的情况下，资源信息服务器503筛选出的候选第一资源集合中的各资源提供服务器的标识也是按照资源的可用余量而有序排列的。例如，在第一种资源为gpu资源且第一条件为剩余算力大于等于30的情况下，在候选第一资源集合中，剩余算力越接近30的gpu所在的资源提供服务器的标识越排在前面。

在候选第一资源集合例如包括400个元素的情况下，资源信息服务器503可能仅拉取这400个元素中的例如前100个元素进行后续的筛选，只要这100个元素中存在同样满足第二条件的元素即可。因此，有序排列可以确保剩余算力最接近30的资源提供服务器的标识能够被拉取并参与后续的筛选。从而，当期望搜索剩余算力大于等于30的gpu资源时，能够最大可能地从gpu剩余算力最接近30的资源提供服务器中选择候选者，而不是任意地选择(例如，选择gpu剩余算力与30差异大(如，gpu剩余算力80)的资源提供服务器)。这样，有助于最大程度地避免资源碎片的产生，进而提升整体的资源分配系统的资源利用率。

然后，资源信息服务器503基于所述候选标识，在与所述第二种资源对应的第二资源信息列表中，提取候选第二资源集合，在所述候选第二资源集合中，所述候选标识与所述候选标识所对应的资源提供服务器上第二种资源的可用余量信息相关联地存储。

具体地，首先通过zadd指令将候选第一资源集合中与各个资源提供服务器的标识对应的gpu的剩余算力清零。由于gpu的资源信息列表与cpu的资源信息列表的格式相同(即，资源提供服务器的标识的格式相同)，因此可以通过zinterstore指令将候选第一资源集合与第二资源信息列表取交集。例如，通过zinterstore指令的取交集操作可以使用的聚合函数为sum，即在做交集操作时将不同集合中相同的成员(相同的服务器标识)所对应的分值(可用余量信息)相加，然后聚合成一个新的集合，即候选第二资源集合。由于在基于第一条件的筛选后，已经将得到的候选第一资源集合中与服务器标识对应的gpu的可用余量信息(如，剩余算力值)清零，因此在候选第二资源集合中，与服务器标识对应的就是cpu的可用余量信息(如，cpu核数)。

然而，这样得到的候选第二资源集合是尚未执行基于第二条件的筛选的集合。因此，接下来，基于所述第二条件，在所述候选第二资源集合中，删除不满足所述第二条件的候选标识，并将剩余的候选标识所对应的候选资源提供服务器作为所述搜索结果。假设第二条件是cpu核数大于等于8，则删除了cpu核数小于8的资源提供服务器的候选标识，并保留cpu核数大于等于8的资源提供服务器的候选标识。

各个资源信息列表都是按照可用余量的大小的顺序排列的有序集合，并且在基于第一条件的搜索中，可能会仅选择第一资源的剩余算力最接近第一条件的服务器标识，而丢弃与第一条件差异大的服务器标识，因此在存在两个搜索条件，即第一条件和第二条件的情况下，将优先地选择具有最接近第一条件的第一资源的服务器标识，相比之下，基于第二条件的筛选未必得到的都是具有最接近第二条件的第二资源的服务器标识。因此，通常而言，将对于实现云服务而言最重要的资源设置为第一资源，且优先地执行基于针对第一资源的第一条件的筛选。换言之，所述第一种资源的分配优先级高于所述第二种资源的分配优先级。

在上文中，描述了搜索条件包括两个条件的情况。但是，本公开并不仅限于此。也可以包括三个或更多个搜索条件。并且，当包括更多个搜索条件时，仍然通过与上文中类似的处理，逐个地基于各个搜索条件进行筛选。

在上文中描述了资源信息服务器503首先执行基于第一条件的筛选，然后通过取交集操作并在交集中删除不满足第二条件的成员来实现在所述多个资源提供服务器中确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。但是，本公开并不仅限于此。例如，可替代地，资源信息服务器503也可以并行地执行基于第一条件的筛选和基于第二条件的筛选。然后，将两个筛选后的集合取交集，以确定具有满足所述第一条件的所述第一种资源且具有满足所述第二条件的所述第二种资源的候选资源提供服务器，作为搜索结果。

所述资源信息服务器503可以包括主服务器和至少一个从服务器，且所述主服务器和所述至少一个从服务器之间通过同步保持数据的一致性。通过配置主服务器和至少一个从服务器，如果主服务器突然由于故障而无法提供服务，则可以立即将其中的一台从服务器设置为主服务器，继续提供服务，从而能够提升整个服务器集群的可用性。例如，在资源信息服务器是redis服务器的情况下，redis服务器可以包括主服务器(redismaster)和从服务器(redisslave)。

另外，为了进一步扩容系统的处理能力，作为一种可能的实施方式，可以将主服务器和至少一个从服务器配置为分别负责不同的处理操作，以便于减轻主服务器的处理压力。例如，可以将从服务器配置为用于读取各种资源的实时状态信息。并且，可以将主服务器配置为执行写入操作。图6示出了采用读写分离的资源信息服务器的示意性架构图。在图6中，当接收到对于资源信息服务器的操作指令时，首先经由网关服务器601来对接收到的操作指令进行分析，以确定其是写指令还是读指令。当确定所述操作指令是写指令时，由主服务器602执行该操作。而当确定所述操作指令是读指令时，由从服务器603来执行该操作。另外，可以进一步将从服务器配置为执行搜索处理。

资源信息服务器503在所述多个资源提供服务器501中确定具有与所述搜索条件匹配的所述至少一种资源的至少一个候选资源提供服务器所基于的可用余量信息是指每一种资源的总的可用余量信息。假设至少一种候选资源包括gpu和cpu的资源。在这种情况下，如上文中所述，在资源信息服务器503中，独立地存储gpu和cpu资源的实时状态信息，并且所述实时状态信息包括在多个资源提供服务器中gpu资源的总的可用余量信息以及cpu资源的总的可用余量信息，并且该种资源的实时状态信息与对应的资源提供服务器的标识被相关联地存储在与该种资源对应的资源信息列表中。

例如，在上文中以key-value结构来存储各种资源的可用余量信息的情况下，一级key是资源类型，例如，当一级key是gpu资源时，二级key是gpu资源所在的资源提供服务器的标识(指示其位置，如ip地址和numaid)，且与二级key对应的value是该位置处所有gpu资源的总的可用余量信息(如，剩余算力值)。当一级key是cpu资源时，二级key是cpu资源所在的资源提供服务器的标识(指示其位置，如ip地址和numaid)，且与二级key对应的value是该位置处所有cpu资源的总的可用余量信息(如，剩余算力值)。

然而，对于每个资源提供服务器501，其每种资源包括多个子资源。例如，在一个资源提供服务器501上，可能存在多个gpu卡或者多个cpu核。每种资源的可用余量信息可以包括所述多个子资源的可用余量信息。例如，在资源信息服务器503中，如果将上文中所述的key-value结构称作第一种key-value结构，那么还可以进一步包括第二种key-value结构。在第二种key-value结构中，一级key是资源提供服务器的标识(如，ip地址和numaid)，二级key是子资源标识(即，具体的资源，如，gpuid或cpuid等)，且与二级key对应的value是该具体资源的可用余量信息。在确定出至少一个候选资源提供服务器之后，可以通过查找第二种key-value结构，进一步确定与该候选资源服务器对应的各个子资源的可用余量信息。

在资源信息服务器503确定出在多个资源提供服务器之中，哪个或哪些资源提供服务器可以提供资源之后，资源信息服务器503还需要在确定出的、能够提供资源的资源提供服务器中，确定具体使用哪些资源，例如使用哪个或哪些gpu或cpu。具体地，资源信息服务器503可以被配置为：基于所述至少一个候选资源提供服务器处的每种资源的各个子资源的可用余量信息，确定满足所述搜索条件的各个资源的至少一个子资源作为所述至少一组可分配资源。

在确定出至少一组可分配资源后，所述资源分配服务器502基于所述至少一组可分配资源，向所述终端执行资源分配。

例如，当在同时为多个终端搜索资源时，为了防止多个终端可能同时选中相同的资源提供服务器以及其上的相同资源，在确定出期望选择的资源提供服务器以及其上的一组可分配资源后，且在真正开始分配之前，可以预先在资源信息服务器上锁定并扣除期望选中的资源。如果期望选择的资源提供服务器已被占用，则更换另一个候选的资源提供服务器。如果资源提供服务器上的一组可分配资源已被占用，则更换另一组可分配资源。所述资源分配服务器502可以通过执行以下处理来基于所述至少一组可分配资源，向终端执行资源分配：当在所述资源信息服务器上存储的各种资源的实时状态信息中成功地锁定并扣除从所述至少一组可分配资源中选择的一组资源时，将所选择的一组资源作为待分配资源；向所述终端发送所述待分配资源所对应的目标资源提供服务器的信息，以便于终端在后面的处理中建立与目标资源提供服务器的连接。另一方面，如果未能在所述资源信息服务器上存储的各种资源的实时状态信息中成功地锁定并扣除所述至少一组可分配资源中的任意一组，则分配失败。

另外，在向用户执行资源分配之后，所述资源分配服务器502还可以进一步被配置为确认待分配的资源是否已经实际地用于创建用于提供服务的进程。具体地，所述资源分配服务器502进一步被配置为：向所述目标资源提供服务器通知创建用于所述终端的处理进程；当所述处理进程被在所述目标资源提供服务器成功创建时，从所述目标资源提供服务器发送用于确认资源已分配的上报数据；当预定时间段内未从所述目标资源提供服务器接收到用于确认资源已分配的上报数据时，向所述资源信息服务器发送指令以更新在所述资源信息服务器上存储的实时状态信息，以释放所述目标资源提供服务器上的所述待分配资源。

目标资源提供服务器可以包括目标网关服务器和目标服务提供服务器。在向所述目标资源提供服务器通知创建用于所述终端的处理进程之后，在所述目标服务提供服务器上创建所述处理进程；并且由所述目标网关服务器在所述目标服务提供服务器与所述终端之间中转数据。

例如，作为一种可能的实施方式，例如，在云服务包括视频相关功能的场景下，网关服务器可以不只是简单的代理，而是能够根据终端的网络回包来判断网络延迟的情况，并据此来丢弃部分视频帧，以保障视频画面的实时性。具体地，由所述目标网关服务器在所述目标服务提供服务器与所述终端之间中转数据可以包括：基于来自所述终端的反馈确认信息，确定网络延迟是否大于预定阈值；并且当所述网络延迟大于所述预定阈值时，丢弃来自所述目标服务提供服务器的部分数据，并将剩余的数据发送给所述终端。

图7示出了用于云服务的资源分配系统的整体架构图。整个系统可以包含四大流程：初始化过程、数据上报过程、资源分配过程和服务实现过程。

1.在初始化过程

首先，在1.1的运营配置过程中，管理员在部署完成整个架构的各种服务器后，配置系统的各项参数。然后，在1.2，将各种配置数据通过数据库进行存储。接下来，在1.3，定期加载配置数据。资源分配系统的核心的业务服务是资源分配服务，资源分配服务器需要与运营过程中的各种事件紧密关联，例如某些服务器的上架、下架等操作。因此资源分配服务需要定期加载配置数据库的内容到本地缓存。

2.数据上报过程

在2.1的带宽数据上报中，终端在云服务环境中需要的一项很重要的资源就是带宽，而为用户提供高速网络接入的服务就是网关服务器。所以网关服务器需要定期(一般为1分钟)将自身的带宽情况上报给资源写服务。

在2.2的服务资源数据上报中，终端在云服务环境中需要的资源除了带宽，还包括cpu、内存、gpu等。服务提供服务器是真正执行服务进程的服务器，服务提供服务器通过其中的上报进程，定期将自身的cpu占用率、内存占用情况、gpu占用率等信息上报给资源写服务。

在2.3的索引写入中，资源写服务收集来自网关服务器的带宽信息，以及来自服务提供服务器的cpu、内存、gpu等信息，按照一定的索引结构(如，上文中所述的key-value结构)，将信息写入主服务器(redismaster)。

在2.4的主从同步中，redismaster会将自身变更数据通过网络发送给从服务器(redisslave)。主从同步保障了数据一致性，且读请求如果从从服务器获取数据，则能够有效减轻主服务器的压力；并且，如果主服务器突然因故障无法提供服务，可以立即把其中一台从服务器设置为主节点，继续提供服务——进而提升存储群集的可用性。

3.资源分配过程

在3.1，由终端设备处的用户发起资源分配请求。用户通过云服务客户端的特定入口(一般是点击应用图标)发起资源分配的请求。因为云服务环境中，服务进程是运行于服务器端的，所以用户在接受服务前需要先申请服务提供服务器上的资源，并创建服务进程。这里云服务客户端与服务器之间的通讯通常采用https协议。

在3.2，通常提供接入能力的云负载均衡系统(cloudloadbalance，clb)组件把密文的https协议转换为明文的、用于内网通讯的http协议。

在3.3，在鉴权后发起分配请求。分配接入服务负责用户鉴权、参数检查等基本工作，并且把资源分配请求进一步转发给资源分配服务进行处理。

在3.4，资源分配服务从资源信息服务器(从服务器)拉取各种资源，并确定合适的资源(特定的区域、特定服务需要的cpu个数、内存容量、gpu算力等)。

在3.5，筛选到合适的资源后，资源分配服务把当前玩家锁定的资源写入主服务器。

在3.6，资源分配服务通知目标服务提供服务器创建用户的服务进程。如果正常创建，目标服务提供服务器通过数据上报来确认资源分配成功。如果因为某些原因未成功分配资源，则资源写服务会定期检查预分配的资源，超过一定时间未确认的资源将会被回收。

4.服务过程

在4.1，终端连接网关服务器。在终端连接到网关服务器后，一边把自己的键盘鼠标手柄等输入信息通过网络发送给网关服务器；一边从网关服务器接收服务数据，如画面编码后的视频流。

在4.2，网关服务器将终端的输入转发给目标服务提供服务器。目标服务提供服务器收到终端输入的信息后，把这些输入再转发给终端的服务进程。服务进程根据终端输入动态产生新的服务数据，例如，新的视频画面，并把新的视频画面编码为视频流。

在4.3，目标服务提供服务器把包含多个视频帧的视频流发给网关服务器，并由网关服务器进一步转发给终端。网关服务器可以不只是简单的网络代理，它能够根据终端的网络回包来判断网络延迟的情况，并据此来智能低丢掉部分视频帧，保障视频画面的实时性。

图8示出了上文中所述的各个服务进程，如资源分配服务、资源写服务等的软件结构图。如图8所示，所述软件结构至下而上包括基础层、运行环境层、存储逻辑层、业务逻辑层和接口层。基础层包括：日志、监控和各种工具函数。运行环境层包括：数据库、配置文件、redis、本地缓存等。这里，需要注意的是，运行环境层需要抽象为独立接口，并且在业务处理中作为参数传入。这样后续可以在mock测试的时候替换环境层的对象，实现不依赖于运行环境的单元测试。存储逻辑层封装了redis的一些常用操作，并且把部分对象的存储逻辑封装在这个层次的组件中。业务逻辑层是具体地实现业务逻辑的层。接口层用于对外提供api接口的层面，处理协议解析、参数检查、鉴权、安全检查等工作。

图9示出了用于云服务的资源分配系统的部署图。如图9所示，所述资源分配系统包括网关服务器901、逻辑服务器902-903、存储服务器904-907。逻辑服务器902-903可以是上文中所述的资源分配服务器，并且上文中所述的资源分配服务、资源写服务、分配接入服务等可以在逻辑服务器上实现。这些服务可以在相同的逻辑服务器上实现，也可以在不同的逻辑服务器上实现。存储服务器904-907可以实现上文中所述的用于存储资源的实时状态信息的资源信息服务器以及用于存储配置数据的配置数据库。

图10示出了用于云服务的资源分配系统的用例图。所述用例图能够说明资源分配系统的使用角色和基本的需求。在资源提供服务器的角度上，需要定时地上报机器负载，并且在终端用户进入和退出时进行上报。当终端用户进入时，需要进一步创建服务进程并确认资源。当终端用户退出时，需要及时地释放资源，并通过定时器来检查服务器是否死机。在终端用户的角度上，希望能够查询分配状态，分配到资源并查询接入测速资源。另外，在测试的角度上，需要获得指定的资源进行测试。在运维的角度上，需要上架服务器、下架服务器和修改配置。

此外，根据本公开实施例的方法或设备也可以借助于图11所示的计算设备1100的架构来实现。如图11所示，计算设备1100可以包括总线1110、一个或多个cpu1120、只读存储器(rom)1130、随机存取存储器(ram)1140、连接到网络的通信端口1150、输入/输出组件1160、硬盘1170等。计算设备1100中的存储设备，例如rom1130或硬盘1170可以存储本公开提供的信息处理方法的处理和/或通信使用的各种数据或文件以及cpu所执行的程序指令。当然，图11所示的架构只是示例性的，在实现不同的设备时，根据实际需要，可以省略图11示出的计算设备中的一个或多个组件。

本公开的实施例也可以被实现为计算机可读存储介质。根据本公开实施例的计算机可读存储介质上存储有计算机可读指令。当所述计算机可读指令由处理器运行时，可以执行参照以上附图描述的根据本公开实施例的用于云服务的资源分配方法。所述计算机可读存储介质包括但不限于例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。

迄今为止，已经参照图1至图11详细描述了根据本公开实施例的用于云服务的资源分配方法和系统。在所述方法和系统中，为云服务平台提供了完善的资源记录、资源分配、资源回收等能力。由于将各种资源的实时状态信息独立地存储，且通过键值对(key-value)的方式关联资源提供服务器与相应的可用余量信息，从而可以容易地应对资源类型由于业务的发展而增多所带来的扩展问题。例如，如果业务新增了某种资源，则只需要新增一个key即可。并且，各种资源的更新方式各不相同，分开存储也能单独地更新某种具体资源的变化。例如，除了传统的gpu、cpu、内存和网络带宽等资源外，还可以提供特定的版本匹配、服务器存活检查、地域匹配、标签匹配等。

此外，能够通过redis提供的取交集指令，实现所需要的资源的各种过滤。程序代码变得很简单。并且，由于将资源搜索操作全部或部分地交由资源信息服务器来完成，因此这个过程极大地降低了与资源分配服务器之间的交互数据量，而只需要从资源分配服务器接收某些指令并向资源分配服务器发送搜索结果。从而，降低了对带宽的要求并减少了搜索所需的时间。例如，在百万用户在线、十万台服务器、上千万cpu核、几十万gpu卡的规模下，分配资源的时延不超过10ms。

另外，通过在各种资源信息列表中基于各种资源的可用余量来排序，能够筛选出最接近搜索条件的资源，尽可能地减少资源碎片，提高资源的利用率，减少云端资源的闲置。

并且，通过各个资源提供服务器的及时的数据上报，即使资源信息服务器中存储的数据全部丢失，整个系统的状态也能在短时间(如，1分钟)内完全重建。

需要说明的是，在本说明书中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

最后，还需要说明的是，上述一系列处理不仅包括以这里所述的顺序按时间序列执行的处理，而且包括并行或分别地、而不是按时间顺序执行的处理。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的硬件平台的方式来实现，当然也可以全部通过软件来实施。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

以上对本发明进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。