CN114756362A

CN114756362A - 资源配额管理方法及系统、智能终端、存储介质

Info

Publication number: CN114756362A
Application number: CN202210226807.1A
Authority: CN
Inventors: 范泽添; 张明泽; 高伟; 周明伟
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2022-03-09
Filing date: 2022-03-09
Publication date: 2022-07-15

Abstract

本申请公开了一种资源配额管理方法及系统、智能终端、存储介质，该资源配额管理方法包括：获取至少一个项目；将至少一个项目与至少一个命名空间建立关联；将与至少一个命名空间建立关联的项目加载到第一处理队列中；启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中；通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。通过上述方案，本申请的资源配额管理方法能够对多个命名空间中的资源配额进行管理，从而能够实现当前对应有多个命名空间的业务需求。

Description

资源配额管理方法及系统、智能终端、存储介质

技术领域

本申请涉及互联网技术领域，特别是涉及一种资源配额管理方法及系统、智能终端、存储介质。

背景技术

现今，k8s(kubernetes，为容器服务而生的一个可移植容器的编排管理工具)作为一个开源的用于管理云平台中多个主机上的容器化的应用，其目标是让部署容器化的应用简单并且高效，为此k8s提供了应用自动部署，自动重启，自动复制，负载均衡、自动伸缩、维护、扩展机制等功能。

然而，在k8s原生的系统中，通常是基于Namespace(命名空间)来做资源隔离和权限控制的实现，而resourcequota(资源配额)即是管理单个命名空间的，并用来管理pod(一组容器的集合)资源参数limit(限制字段)和request(要求)字段的资源配额，拥有统计和准入校验两种功能。但原生的k8s技术通常都只能对一个命名空间进行使用，而无法对多个命名空间中的资源配额做管理，以致于不能实现当前对应有多个命名空间的业务需求。

发明内容

本申请主要解决的技术问题是提供一种资源配额管理方法及系统、智能终端、存储介质，以解决现有技术中k8s原生的系统无法使用多个命名空间，以致于不能实现当前对应有多个命名空间的业务需求的问题。

为了解决上述问题，本申请第一方面提供了一种多命名空间的配额管理方法，其中，该多命名空间的配额管理方法包括：获取至少一个项目；将至少一个项目与至少一个命名空间建立关联；将与至少一个命名空间建立关联的项目加载到第一处理队列中；启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中；通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，获取至少一个项目的步骤之后，将至少一个项目与至少一个命名空间建立关联之前，还包括：统计至少一个项目对应的至少一个命名空间中的容器集合和的第一配额。

其中，将至少一个项目与至少一个命名空间建立关联的步骤之后，将与至少一个命名空间建立关联的项目加载到第一处理队列中的步骤之前，还包括：获取每一命名空间中的容器集合和的第二配额；将第二配额加载至与其对应的命名空间建立关联的项目中。

其中，通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息的步骤之后，还包括：检测当前是否存在有项目发生变更；响应于存在有第一项目发生变更，将第一项目加载到第一处理队列中，并重新执行启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中的步骤。

其中，通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息的步骤之后，还包括：检测当前是否存在有容器集合和/或发生变更；响应于存在容器集合和/或发生变更，检测发生变更的容器集合和/或对应的命名空间是否关联有项目；响应于发生变更的容器集合和/或对应的命名空间关联有第二项目，对第二项目进行配额变更；将配额变更后的第二项目加载到第一处理队列中，以重新执行启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中的步骤。

其中，通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息的步骤之后，还包括：接收用户输入的配额修改指令，以对应修改至少一个项目的配额上限；将已修改配额上限的第三项目加载到第二处理队列中；启动至少一个第二线程，以将第二处理队列中的至少一个第三项目加载到至少一个第二线程中；通过至少一个第二线程计算第二处理队列中的至少一个第三项目的资源配额信息。

其中，获取至少一个项目的步骤之前，还包括：接收配额求值程序的注册请求，以将配额求值程序加载至循环计算机中；启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中的步骤包括：循环计算机启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中；通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息的步骤包括：循环计算机基于配额求值程序通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息的步骤之后，还包括：每隔设定时间将当前获取的所有项目重新加载到第一处理队列中，并重新执行启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中的步骤。

其中，将至少一个项目与至少一个命名空间建立关联的步骤之后，将与至少一个命名空间建立关联的项目加载到第一处理队列中的步骤之前，还包括：创建容器集合和；检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限；响应于当前创建的容器集合和用户存储请求不超过与其对应的命名空间相关联的项目的配额上限，更新与其对应的命名空间相关联的项目的配额使用信息，并执行将与至少一个命名空间建立关联的项目加载到第一处理队列中的步骤。

其中，资源配额管理方法包括：响应于当前创建的容器集合和用户存储请求超过与其对应的命名空间相关联的项目的配额上限，当前资源创建失败，并返回创建失败的错误信息。

其中，创建容器集合和的步骤之前，还包括：获取容器集合和；判断容器集合和对应的命名空间是否存在有相关联的项目；响应于容器集合和对应的命名空间存在有相关联的项目，执行创建容器集合和的步骤。

其中，创建容器集合和的步骤之后，检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限步骤之前，还包括：将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第三处理队列；启动至少一个第三线程，以将第三处理队列中的项目加载到至少一个第三线程中；通过至少一个第三线程计算第三处理队列中的项目的资源配额信息。

其中，将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第三处理队列的步骤之前，还包括：判断与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目是否正在处理中；响应于与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目正在处理中，将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第一数据队列中，并在其处理完成后，转存到第二数据队列。

其中，资源配额管理方法包括：响应于与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目不在处理中，将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第二数据队列中；将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第三处理队列的步骤包括：从第二数据队列中依次获取与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目，并将其加载到第三处理队列。

为了解决上述问题，本申请第二方面提供了一种资源配额管理系统，其中，该资源配额管理系统包括：自定义控制器，用于获取至少一个项目，以将至少一个项目与至少一个命名空间建立关联；第一处理队列，用于存储由自定义控制器加载的与至少一个命名空间建立关联的项目；循环计算机，用于启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中，并通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，资源配额管理方法还包括资源创建控制器，资源创建控制器用于创建容器集合和，并检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限，以在当前创建的容器集合和用户存储请求不超过与其对应的命名空间相关联的项目的配额上限时，更新与其对应的命名空间相关联的项目的配额使用信息。

为了解决上述问题，本申请第三方面提供了一种智能终端，其中，该智能终端包括相互耦接的存储器和处理器，处理器用于执行存储器中存储的程序指令，以实现上述第一方面的资源配额管理方法。

为了解决上述问题，本申请第四方面提供了一种计算机可读存储介质，其上存储有程序指令，程序指令被处理器执行时，实现上述第一方面的资源配额管理方法。

本发明的有益效果是：区别于现有技术的情况，本申请的资源配额管理方法在获取到至少一个项目时，能够将至少一个项目与至少一个命名空间建立关联，以将与至少一个命名空间建立关联的项目加载到第一处理队列中，并启动至少一个第一线程，进而将第一处理队列中的至少一个项目加载到至少一个第一线程中，以通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息，也便能够对多个命名空间中的资源配额进行管理，从而能够实现当前对应有多个命名空间的业务需求。

附图说明

图1是本申请资源配额管理方法第一实施例的流程示意图；

图2是本申请资源配额管理方法第二实施例的流程示意图；

图3是本申请资源配额管理方法第三实施例的流程示意图；

图4是本申请资源配额管理方法第四实施例的流程示意图；

图5是本申请资源配额管理方法第五实施例的流程示意图；

图6是本申请资源配额管理方法第六实施例的流程示意图；

图7是本申请资源配额管理方法第七实施例的流程示意图；

图8是本申请资源配额管理方法第八实施例的流程示意图；

图9是本申请资源配额管理方法第九实施例的流程示意图；

图10是本申请资源配额管理方法第十实施例的流程示意图；

图11是本申请资源配额管理系统第一实施例的框架示意图；

图12是本申请资源配额管理系统第二实施例的框架示意图；

图13是本申请资源配额管理系统第三实施例的框架示意图；

图14是图13中资源配额管理系统中部分功能单元的框架示意图；

图15是本申请智能终端一实施例的框架示意图；

图16是本申请计算机可读存储介质一实施例的框架示意图。

具体实施方式

为使本申请解决的技术问题、采用的技术方案和达到的技术效果更加清楚，下面将结合附图对本申请实施例的技术方案作进一步的详细描述。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

请参阅图1，图1是本申请资源配额管理方法第一实施例的流程示意图。具体而言，可以包括如下步骤：

S11：获取至少一个项目。

随着容器技术的快速发展，基于k8s的网络服务逐渐取代虚拟机，推动了微服务架构等热门技术的普及和落地。其中，对于互联网公司而言，随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题，而且随着云计算的发展，云端最大的挑战即是应对容器的漂移。在此业务驱动下，k8s问世，提出了一套全新的基于容器技术的分布式架构领先方案，在整个容器技术领域的发展是一个重大突破与创新。但k8s原生的系统通常又无法使用多个命名空间，以致如何实现当前对应有多个命名空间的业务需求，又成为影响用户享受网络服务的一个关键因素。

可理解的是，本实施例中的资源配额管理方法即是基于k8s对资源配额进行管理的方法，以在获取到相应互联网中对应运行，或由用户对应建立的网络业务，也即项目时，能够对应为该项目分配一合适的运行资源，并对该资源进行配额管理。

具体地，获取至少一个待进行资源配额管理的项目。

S12：将至少一个项目与至少一个命名空间建立关联。

进一步地，将至少一个项目与至少一个命名空间分别对应建立关联，比如，命名空间采用特定的标签或标记符与相应的项目建立关联，以在后续处理过程中，能够通过该标签或标记符识别出与某一命名空间相关联的项目。

可理解的是，其中的一个项目能够对应与一个或多个命名空间建立关联，而一个命名空间也可以对应与一个或多个项目建立关联，本申请对此不做限定。

需说明的是，该命名空间，也即namespace，也称“名称空间”，具体是指一套软件开发平台中的各种语言使用的一种代码组织的形式，以区别不同的代码功能，同时也是软件开发平台中所有类的完全名称的一部分。

命名空间是用来组织和重用代码的。如同名字一样的意思，之所以出来这样一个东西，是因为人类可用的单词数太少，并且不同的人写的程序不可能所有的变量都没有重名现象，对于库来说，这个问题尤其严重，如果两个人写的库文件中出现同名的变量或函数(不可避免)，使用起来就有问题了。为了解决这个问题，引入了名字空间这个概念，通过使用“namespace xxx”；你所使用的库函数或变量就是在该名字空间中定义的，这样一来就不会引起不必要的冲突了。

通常来说，命名空间是唯一识别的一套名字，这样当对象来自不同的地方但是名字相同的时候就不会含糊不清了。使用扩展标记语言的时候，XML(可扩展标记语言，标准通用标记语言的子集)的命名空间是所有元素类别和属性的集合。元素类别和属性的名字是可以通过唯一XML命名空间来唯一。

在XML里，任何元素类别或者属性因此分为两部分名字，一个是命名空间里的名字另一个是它的本地名。在XML里，命名空间通常是一个统一资源识别符(URI)的名字。而URI只当名字用。主要目的是为了避免名字的冲突。

而在至少一个项目与至少一个命名空间建立关联后，即可将命名空间中的每一资源，比如，pod(容器集合)和pvc(用户存储请求)的配额信息，汇总到与其建立关联的项目中，从而能够在后续中基于该项目计算出相应的配额信息。

需说明的是，Pod是一个或一个以上的容器(例如Docker容器)组成的，且具有共享存储/网络/UTS/PID的能力，以及运行容器的规范。并且在Kubernetes中，Pod是最小的可被调度的原子单位。

通俗来讲，Pod就是一组容器的集合，在Pod里面的容器共享网络/存储(Kubernetes实现共享一组的Namespace去替代每个container各自的NS，来实现这种能力)，所以它们可以通过Localhost进行内部的通信。虽然网络存储都是共享的，但是CPU和Memory就不是。多容器之间可以有属于自己的Cgroup，也就是说我们可以单独的对Pod中的容器做资源(MEM/CPU)使用的限制。

PersistentVolumeClaim(PVC，用户存储请求)，具体是指是对PV(持久化卷)的申请。PVC通常由普通用户创建和维护。需要为Pod分配存储资源时，用户可以创建一个PVC，指明存储资源的容量大小和访问模式(比如只读)等信息，Kubernetes会查找并提供满足条件的PV。

其中，资源配额限制了一个命名空间中pod和PVC存储最多可以使用的资源总量。同时也可以限制用户允许在该命名空间中创建pod、PVC，以及其他API(ApplicationProgramming Interface，应用程序编程接口)对象的数量，因为到目前为止我们处理最多的资源是CPU(central processing unit，中央处理器)和内存。

S13：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

可理解的是，当多个命名空间共用同一个集群的时候可能会有某一个命名空间使用的资源配额超过其公平配额，导致其他命名空间的资源被占用，因此，还需每一项目对应的资源配额进行计算。

而为了有序的对每一项目进行资源配额计算，还需将与至少一个命名空间建立关联的项目依次加载到第一处理队列中，以能够依据第一处理队列中的项目的加载顺序，在后续依次对每一项目进行资源配额计算。

S14：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

具体地，启动至少一个第一线程，并依次将第一处理队列中的至少一个项目加载到至少一个第一线程中。

需说明的是，线程(英语：thread)是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。

同一进程中的多条线程将共享该进程中的全部系统资源，如虚拟地址空间，文件描述符和信号处理等等。但同一进程中的多个线程有各自的调用栈(call stack)，自己的寄存器环境(register context)，自己的线程本地存储(thread-local storage)。一个进程可以有很多线程，每条线程并行执行不同的任务。

可选地，对应于第一处理队列的第一线程具体可以包括3个、5个或6个等任一合理的数量，本申请对此不做限定。

S15：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

进一步地，通过至少一个第一线程依次计算第一处理队列中的至少一个项目的资源配额信息，以跟踪其中的每一个项目的资源使用情况，以确保其不超过预先设定的资源配额的限制值。

上述方案，通过将至少一个项目与至少一个命名空间建立关联，以将与至少一个命名空间建立关联的项目加载到第一处理队列中，并启动至少一个第一线程，进而将第一处理队列中的至少一个项目加载到至少一个第一线程中，以通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息，也便能够对多个命名空间中的资源配额进行管理，从而能够实现当前对应有多个命名空间的业务需求。

进一步地，在一实施例中，在上述S11之后，S12之前，具体还可以包括：统计至少一个项目对应的至少一个命名空间中的容器集合和的第一配额。

可理解的是，在将至少一个项目与至少一个命名空间建立关联之前，还需首先确定当前所有项目对应的所有命名空间下的总配额情况，以统计至少一个项目对应的至少一个命名空间中的容器集合和用户存储请求的第一配额，以方便命名空间与相应项目建立关联，并以命名空间为维度来获取每个容器集合或用户存储请求的配额信息。

进一步地，在一实施例中，在上述S15之后，具体还可以包括：每隔设定时间将当前获取的所有项目重新加载到第一处理队列中，并重新执行启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中的步骤。

可理解的是，为防止当存在有项目发生变化，比如，项目有增加、删除或修改，或是存在有正在处理的项目中的资源配额发生变化，而未被相应的至少一个进程进行及时的计算时，还可以通过设定每隔设定时间将当前获取的所有项目均重新加载到第一处理队列中，并覆盖第一处理队列中当前存储的项目后，重新执行启动至少一个第一线程，也即进行一次刷新计算，以避免对相应的变化未监测到，或及时处理的情况，以致当前计算出的每一项目的配额信息失效。

可选地，该设定时间具体可以为5分钟、6分钟或10分钟等任一合理时长，本申请对此不做限定。

请参阅图2，图2是本申请资源配额管理方法第二实施例的流程示意图。本实施例的资源配额管理方法是图1中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S21：获取至少一个项目。

其中，S21与图1中的S11相同，具体请参阅S11及其相关的文字描述，在此不再赘述。

S22：统计至少一个项目对应的至少一个命名空间中的容器集合和的第一配额。

可理解的是，在获取到至少一个项目后，为方便后续对每一项目分别进行均衡的资源分配及资源配额计算，还需首先确定当前所有项目对应的所有命名空间下的总配额情况，以统计至少一个项目对应的至少一个命名空间中的容器集合和的第一配额。

S23：将至少一个项目与至少一个命名空间建立关联。

其中，S23与图1中的S12相同，具体请参阅S12及其相关的文字描述，在此不再赘述。

S24：获取每一命名空间中的容器集合和的第二配额。

具体地，在将至少一个项目与至少一个命名空间建立关联后，进而以命名空间为维度通过数据采集器获取每一命名空间中的容器集合和的第二配额。

S25：将第二配额加载至与其对应的命名空间建立关联的项目中。

进一步地，将获取到的第二配额加载至与其对应的命名空间建立关联的项目中，以在后续中能够通过对应加载的至少一个第一线程计算出每一项目对应的命名空间中的容器集合和的第二配额，也即计算得到每一项目的配额信息。

S26：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S27：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S28：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S26、S27以及S28与图1中的S13、S14以及S15相同，具体请参阅S13、S14以及S15及其相关的文字描述，在此不再赘述。

请参阅图3，图3是本申请资源配额管理方法第三实施例的流程示意图。本实施例的资源配额管理方法是图1中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S31：获取至少一个项目。

S32：将至少一个项目与至少一个命名空间建立关联。

S33：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S34：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S35：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S31、S32、S33、S34以及S35与图1中的S11、S12、S13、S14以及S15相同，具体请参阅S11、S12、S13、S14以及S15及其相关的文字描述，在此不再赘述。

S36：检测当前是否存在有项目发生变更。

可理解的是，在当前已获取的至少一个项目发生变更，比如，有新的项目增加、至少部分项目被删除或修改时，相应地，之前对应分配给每一项目的资源配额也将发生变更，因而需要重新进行计算。

具体地，在通过至少一个第一线程依次计算出第一处理队列中的至少一个项目的资源配额信息后，实时监测当前是否存在有项目发生变更。

其中，如果不存在项目发生变更时，则执行S37，如果存在有第一项目发生变更时，则执行S38。

S37：保持对项目的监测。

可理解的是，在确定当前不存在项目发生变更时，则表明之前对应分配给每一项目的资源配额便未发生变更，而无需对当前获取到的项目进行资源配额信息的重复计算，只保持对项目的监测即可。

S38：将第一项目加载到第一处理队列中。

可理解的是，在确定当前存在有第一项目发生变更时，则需重新对第一项目进行资源配额信息的计算，也即将第一项目加载到第一处理队列中，以进而能够重新、并依次循环执行S34-S38，以响应每一次发生的项目变更，对发生变更的第一项目进行资源配额信息的计算。

其中，该第一项目具体是指在当前已获取项目的基础上，发生变更的那一部分项目。则可知，当具体是发生项目新增时，则新增的项目即为第一项目；而发生项目修改时，发生修改的项目即为第一项目；但在当前发生的为项目删除时，则需将未删除的那部分项目确定为第一项目，以能够对应将该第一项目加载至第一处理队列中，重新进行第一项目的资源配额信息的计算。

请参阅图4，图4是本申请资源配额管理方法第四实施例的流程示意图。本实施例的资源配额管理方法是图1中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S41：获取至少一个项目。

S42：将至少一个项目与至少一个命名空间建立关联。

S43：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S44：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S45：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S41、S42、S43、S44以及S45与图1中的S11、S12、S13、S14以及S15相同，具体请参阅S11、S12、S13、S14以及S15及其相关的文字描述，在此不再赘述。

S46：检测当前是否存在有容器集合和/或发生变更。

可理解的是，在当前已对应为至少一个项目分配出的资源配额，比如，存在有容器集合和/或发生变更时，则表明当前至少有部分项目的资源配额发生了变更，因此对应查找出资源配额发生变更的项目，并重新对其进行资源配额信息的计算。

具体地，在通过至少一个第一线程依次计算出第一处理队列中的至少一个项目的资源配额信息后，实时监测当前是否存在有容器集合和/或发生变更。

其中，如果不存在容器集合和/或发生变更时，则执行S47，如果存在有容器集合和/或发生变更时，则执行S48。

S47：保持监测。

可理解的是，在确定当前不存在容器集合和/或发生变更时，则表明之前对应分配给每一项目的资源配额未发生变更，而无需对当前获取到的项目进行资源配额信息的重复计算，只保持对容器集合和/或的监测即可。

S48：检测发生变更的容器集合和/或对应的命名空间是否关联有项目。

可理解的是，在确定存在有容器集合和/或发生变更时，则表明当前存在有部分项目的资源配额发生了变更，但还需区分出当前发生变更的项目是否是之前已与至少一个命名空间建立关联的项目。

具体地，在确定存在有容器集合和/或发生变更时，检测发生变更的容器集合和/或对应的命名空间是否与之前获取的至少一个项目建立有关联。

其中，如果不存在与发生变更的容器集合和/或对应的命名空间有关联的项目时，则执行S49，如果存在有第二项目与发生变更的容器集合和/或对应的命名空间建立有关联时，则执行S410。

S49：不做处理。

具体地，在确定发生变更的容器集合和/或对应的命名空间并不关联之前获取的任一项目时，则不进行资源配额信息的重复计算。

S410：对第二项目进行配额变更。

具体地，当确定存在有第二项目与发生变更的容器集合和/或对应的命名空间建立有关联时，则将该第二项目进行配额变更，也即将变更后的资源配额加载，也即汇总至第二项目对象中，以方便后续对第二项目进行资源配额信息的计算。

S411：将配额变更后的第二项目加载到第一处理队列中。

进一步地，将配额变更后的第二项目加载到第一处理队列中，以进而能够重新、并依次循环执行S44-S411，以响应每一次发生的容器集合和/或的变更，而对相应的配额变更后的第二项目进行资源配额信息的计算。

请参阅图5，图5是本申请资源配额管理方法第五实施例的流程示意图。本实施例的资源配额管理方法是图1中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S51：获取至少一个项目。

S52：将至少一个项目与至少一个命名空间建立关联。

S53：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S54：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S55：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S51、S52、S53、S54以及S55与图1中的S11、S12、S13、S14以及S15相同，具体请参阅S11、S12、S13、S14以及S15及其相关的文字描述，在此不再赘述。

S56：接收用户输入的配额修改指令，以对应修改至少一个项目的配额上限。

可理解的是，在获取到至少一个项目时，其中的每一项目均对应默认设置有一资源配额上限，也即对应为每一项目分配的资源将不能超过该资源配额上限，但在实际的网络服务中，当存在有项目需要超过该资源配额上限，才能够进行有效运行时，则需由用户进行相应的特定的适应性修改操作。

具体地，接收用户对应输入的配额修改指令，以对应修改至少一个项目的配额上限，以使其中的每一项目能够对应占用的资源配额更多。

S57：将已修改配额上限的第三项目加载到第二处理队列中。

可理解的是，在将已修改配额上限的项目确定为第三项目时，则可知，该第三项目对应占用的资源配额，比如其动态和静态中的限额也将与之前不一致，因此需重新进行配额的统计。

具体地，将已修改配额上限的第三项目加载到第二处理队列中。

S58：启动至少一个第二线程，以将第二处理队列中的至少一个第三项目加载到至少一个第二线程中。

进一步地，启动至少一个第二线程，并依次将第二处理队列中的至少一个第三项目加载到至少一个第二线程中。

可选地，对应于第二处理队列的第二线程具体可以包括3个、5个或6个等任一合理的数量，本申请对此不做限定。

可选地，该第二处理队列可以同于第一处理队列，也可以是不同于第一处理队列的另一独立的处理队列，本申请对此不做限定。

S59：通过至少一个第二线程计算第二处理队列中的至少一个第三项目的资源配额信息。

又进一步地，通过至少一个第二线程依次计算第二处理队列中的至少一个第三项目的资源配额信息，以跟踪其中的每一个第三项目的资源使用情况。

请参阅图6，图6是本申请资源配额管理方法第六实施例的流程示意图。本实施例的资源配额管理方法是图1中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S61：接收配额求值程序的注册请求，以将配额求值程序加载至循环计算机中。

可理解的是，为了在后续能够对每一获取到的项目进行资源配额信息的计算，还需首先加载或建立一套配额求值程序，比如，容器集合求值程序和/或求值程序。

具体地，接收用户对应输入的配额求值程序的注册请求，以进而将该配额求值程序加载至循环计算机中。

S62：获取至少一个项目。

S63：将至少一个项目与至少一个命名空间建立关联。

S64：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

其中，S62、S63以及S64与图1中的S11、S12以及S13相同，具体请参阅S11、S12以及S13及其相关的文字描述，在此不再赘述。

S65：循环计算机启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

具体地，在将与至少一个命名空间建立关联的项目加载到第一处理队列中后，进而在循环计算机汇总对应启动至少一个第一线程，以将第一处理队列中的至少一个项目依次加载到至少一个第一线程中。

S66：循环计算机基于配额求值程序通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

进一步地，该循环计算机在对应加载有配额求值程序后，即可基于该配额求值程序通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息，以跟踪其中的每一个项目的资源使用情况，以确保其不超过预先设定的资源配额的限制值。

请参阅图7，图7是本申请资源配额管理方法第七实施例的流程示意图。本实施例的资源配额管理方法是图1中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S71：获取至少一个项目。

S72：将至少一个项目与至少一个命名空间建立关联。

其中，S71和S72与图1中的S11和S12相同，具体请参阅S11和S12及其相关的文字描述，在此不再赘述。

S73：创建容器集合和用户存储请求。

可理解的是，在将至少一个项目与至少一个命名空间建立关联后，为保证每一项目能够进行有效运行，还需对应为每一项目进行运行资源的分配。

具体地，创建合适资源量的容器集合和用户存储请求。

S74：检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限。

可理解的是，每一容器集合和在创建后，均对应有属于一命名空间，该命名空间又对应关联有一当前获取的项目，而该项目对应分配的资源需要限制在其配额上限之内，也即当前创建的容器集合和在并入其对应的项目已占用的资源中后，不能超过其对应的项目的配额上限。

具体地，在创建容器集合和后，检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限。

其中，如果当前创建的容器集合和用户存储请求超过与其对应的命名空间相关联的项目的配额上限时，则执行S75，如果当前创建的容器集合和用户存储请求不超过与其对应的命名空间相关联的项目的配额上限时，则执行S76。

S75：当前资源创建失败，并返回创建失败的错误信息。

可理解的是，在当前创建的容器集合和超过相应项目的配额上限时，则不能对应分配给该项目，因此本次资源创建也将失败，而需对应返回创建失败的错误信息，以告知用户。

S76：更新与其对应的命名空间相关联的项目的配额使用信息。

具体地，在确定当前创建的容器集合和未超过相应项目的配额上限时，则需更新与其对应的命名空间相关联的项目的配额使用信息，以进而能够重新对该项目进行资源配额信息的计算。

S77：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S78：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S79：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S77、S78以及S79与图1中的S13、S14以及S15相同，具体请参阅S13、S14以及S15及其相关的文字描述，在此不再赘述。

请参阅图8，图8是本申请资源配额管理方法第八实施例的流程示意图。本实施例的资源配额管理方法是图7中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S81：获取至少一个项目。

S82：将至少一个项目与至少一个命名空间建立关联。

其中，S81和S82与图7中的S71和S72相同，具体请参阅S71和S72及其相关的文字描述，在此不再赘述。

S83：获取容器集合和用户存储请求。

具体地，在将至少一个项目与至少一个命名空间建立关联后，获取容器集合和，以等待分别给相应的项目。

S84：判断容器集合和对应的命名空间是否存在有相关联的项目。

可理解的是，当前获取到的容器集合和对应的命名空间在存在有与之关联的项目时，才可对应分配给该项目，也即能够有效进行分配，而得到创建，否则视为无效资源而放弃创建。

具体地，在获取到容器集合和后，进一步确定该容器集合和对应的命名空间是否存在有相关联的项目。

其中，如果不存在与当前获取的容器集合和对应的命名空间相关联的项目时，则执行S85，如果存在有与当前获取的容器集合和对应的命名空间相关联的项目时，则执行S86。

S85：不进行资源创建。

可理解的是，当确定不存在与当前创建的容器集合和对应的命名空间相关联的项目时，则表明当前获取的容器集合和无法得到有效分配，因而需不进行资源创建。

S86：创建容器集合和用户存储请求。

S87：检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限。

S88：当前资源创建失败，并返回创建失败的错误信息。

S89：更新与其对应的命名空间相关联的项目的配额使用信息。

S810：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S811：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S812：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S86、S87、S88、S89、S810、S811以及S812与图7中的S73、S74、S75、S76、S77、S78以及S79相同，具体请参阅S73、S74、S75、S76、S77、S78以及S79及其相关的文字描述，在此不再赘述。

请参阅图9，图9是本申请资源配额管理方法第九实施例的流程示意图。本实施例的资源配额管理方法是图7中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S91：获取至少一个项目。

S92：将至少一个项目与至少一个命名空间建立关联。

S93：创建容器集合和用户存储请求。

其中，S91、S92以及S93与图7中的S71、S72以及S73相同，具体请参阅S71、S72以及S73及其相关的文字描述，在此不再赘述。

S94：将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第三处理队列。

可理解的是，在将至少一个项目与至少一个命名空间建立关联，并对应创建容器集合和用户存储请求后，还需对与该容器集合和用户存储请求相对应的项目的资源配额信息进行计算。

具体地，将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第三处理队列。

S95：启动至少一个第三线程，以将第三处理队列中的项目加载到至少一个第三线程中。

进一步地，启动至少一个第三线程，并依次将第三处理队列中的项目加载到至少一个第三线程中。

可选地，对应于第三处理队列的第三线程具体可以包括3个、5个或6个等任一合理的数量，本申请对此不做限定。

S96：通过至少一个第三线程计算第三处理队列中的项目的资源配额信息。

又进一步地，通过至少一个第三线程依次计算第三处理队列中的项目的资源配额信息，以跟踪其中的每一个项目的资源使用情况，以确保其不超过预先设定的资源配额的限制值。

S97：检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限。

S98：当前资源创建失败，并返回创建失败的错误信息。

S99：更新与其对应的命名空间相关联的项目的配额使用信息。

S910：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S911：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S912：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S96、S97、S98、S99、S910、S911以及S912与图7中的S73、S74、S75、S76、S77、S78以及S79相同，具体请参阅S73、S74、S75、S76、S77、S78以及S79及其相关的文字描述，在此不再赘述。

请参阅图10，图10是本申请资源配额管理方法第十实施例的流程示意图。本实施例的资源配额管理方法是图9中的资源配额管理方法的一细化实施例的流程示意图，包括如下步骤：

S101：获取至少一个项目。

S102：将至少一个项目与至少一个命名空间建立关联。

S103：创建容器集合和用户存储请求。

其中，S101、S102以及S103与图9中的S91、S92以及S93相同，具体请参阅S91、S92以及S93及其相关的文字描述，在此不再赘述。

S104：判断与当前创建的容器集合和用户存储对应的命名空间相关联的项目是否正在处理中。

可理解的是，为保证能够对多个项目进行有序，且有效的资源配额信息的计算，还需对应确定当前需进行资源配额信息计算的项目是否正在处理中。

具体地，在创建容器集合和用户存储请求后，进一步判断与当前创建的容器集合和用户存储对应的命名空间相关联的项目是否正在处理中。

其中，如果当前创建的容器集合和用户存储对应的命名空间相关联的项目正在处理中，则执行S105，如果当前创建的容器集合和用户存储对应的命名空间相关联的项目不在处理中，则执行S106。

S105：将与当前创建的容器集合和用户存储对应的命名空间相关联的项目加载到第一数据队列中，并在其处理完成后，转存到第二数据队列。

具体地，在确定当前创建的容器集合和用户存储对应的命名空间相关联的项目正在处理中时，可先将其加载到第一数据队列中，并在其处理完成后，转存到第二数据队列。

S106：将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第二数据队列中。

具体地，在确定当前创建的容器集合和用户存储对应的命名空间相关联的项目不在处理中时，便可将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目依次加载到第二数据队列中。

S107：从第二数据队列中依次获取与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目，并将其加载到第三处理队列。

进一步地，从第二数据队列中依次获取与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目，并将其加载到第三处理队列，以等待后续依次对第三处理队列中的项目进行资源配额信息的计算。

S108：启动至少一个第三线程，以将第三处理队列中的项目加载到至少一个第三线程中。

S109：通过至少一个第三线程计算第三处理队列中的项目的资源配额信息。

S1010：检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限。

S1011：当前资源创建失败，并返回创建失败的错误信息。

S1012：更新与其对应的命名空间相关联的项目的配额使用信息。

S1013：将与至少一个命名空间建立关联的项目加载到第一处理队列中。

S1014：启动至少一个第一线程，以将第一处理队列中的至少一个项目加载到至少一个第一线程中。

S1015：通过至少一个第一线程计算第一处理队列中的至少一个项目的资源配额信息。

其中，S108、S109、S1010、S1011、S1012、S1013、S1014以及S1015与图9中的S95、S96、S97、S98、S99、S910、S911以及S912相同，具体请参阅S95、S96、S97、S98、S99、S910、S911以及S912及其相关的文字描述，在此不再赘述。

请参阅图11，图11是本申请资源配额管理系统第一实施例的框架示意图。该资源配额管理系统111包括：自定义控制器1111，用于获取至少一个项目，以将至少一个项目与至少一个命名空间建立关联；第一处理队列1112，用于存储由自定义控制器1111加载的与至少一个命名空间建立关联的项目；循环计算机1113，用于启动至少一个第一线程，以将第一处理队列1112中的至少一个项目加载到至少一个第一线程中，并通过至少一个第一线程计算第一处理队列1112中的至少一个项目的资源配额信息。

上述方案，通过将至少一个项目与至少一个命名空间建立关联，以将与至少一个命名空间建立关联的项目加载到第一处理队列1112中，并启动至少一个第一线程，进而将第一处理队列1112中的至少一个项目加载到至少一个第一线程中，以通过至少一个第一线程计算第一处理队列1112中的至少一个项目的资源配额信息，也便能够对多个命名空间中的资源配额进行管理，从而能够实现当前对应有多个命名空间的业务需求。

在一些实施例中，自定义控制器1111具体还可以用于：统计至少一个项目对应的至少一个命名空间中的容器集合和的第一配额。

在一些实施例中，自定义控制器1111具体还可以用于：获取每一命名空间中的容器集合和的第二配额；将第二配额加载至与其对应的命名空间建立关联的项目中。

在一些实施例中，自定义控制器1111具体还可以用于：检测当前是否存在有项目发生变更，并在有第一项目发生变更时，将第一项目加载到第一处理队列1112中，并重新执行启动至少一个第一线程，以将第一处理队列1112中的至少一个项目加载到至少一个第一线程中的步骤。

在一些实施例中，自定义控制器1111具体还可以用于：检测当前是否存在有容器集合和/或发生变更，并在有容器集合和/或发生变更，检测发生变更的容器集合和/或对应的命名空间是否关联有项目，并在发生变更的容器集合和/或对应的命名空间关联有第二项目，对第二项目进行配额变更；将配额变更后的第二项目加载到第一处理队列1112中，以重新执行启动至少一个第一线程，以将第一处理队列1112中的至少一个项目加载到至少一个第一线程中的步骤。

在一些实施例中，自定义控制器1111具体还可以用于：接收用户输入的配额修改指令，以对应修改至少一个项目的配额上限；将已修改配额上限的第三项目加载到第二处理队列中；启动至少一个第二线程，以将第二处理队列中的至少一个第三项目加载到至少一个第二线程中；通过至少一个第二线程计算第二处理队列中的至少一个第三项目的资源配额信息。

在一些实施例中，自定义控制器1111具体还可以用于：接收配额求值程序的注册请求，以将配额求值程序加载至循环计算机1113中；循环计算机1113启动至少一个第一线程，以将第一处理队列1112中的至少一个项目加载到至少一个第一线程中；循环计算机1113基于配额求值程序通过至少一个第一线程计算第一处理队列1112中的至少一个项目的资源配额信息。

在一些实施例中，自定义控制器1111具体还可以用于：每隔设定时间将当前获取的所有项目重新加载到第一处理队列1112中，并重新执行启动至少一个第一线程，以将第一处理队列1112中的至少一个项目加载到至少一个第一线程中的步骤。

请参阅图12，图12是本申请资源配额管理系统第二实施例的框架示意图。本实施例的资源配额管理系统是在图11中的资源配额管理系统的基础上，资源配额管理系统121还包括资源创建控制器1214。

其中，资源创建控制器1214具体用于创建容器集合和，并检测当前创建的容器集合和用户存储请求是否超过与其对应的命名空间相关联的项目的配额上限，以在当前创建的容器集合和用户存储请求不超过与其对应的命名空间相关联的项目的配额上限时，更新与其对应的命名空间相关联的项目的配额使用信息。

在一些实施例中，资源创建控制器1214具体还可以用于：在当前创建的容器集合和用户存储请求超过与其对应的命名空间相关联的项目的配额上限时，当前资源创建失败，并返回创建失败的错误信息。

在一些实施例中，资源创建控制器1214具体还可以用于：获取容器集合和；判断容器集合和对应的命名空间是否存在有相关联的项目，并在容器集合和对应的命名空间存在有相关联的项目，执行创建容器集合和的步骤。

在一些实施例中，资源创建控制器1214具体还可以用于：将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第三处理队列；启动至少一个第三线程，以将第三处理队列中的项目加载到至少一个第三线程中；通过至少一个第三线程计算第三处理队列中的项目的资源配额信息。

在一些实施例中，资源创建控制器1214具体还可以用于：判断与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目是否正在处理中，并在与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目正在处理中，将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第一数据队列中，并在其处理完成后，转存到第二数据队列。

在一些实施例中，资源创建控制器1214具体还可以用于：在与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目不在处理中，将与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目加载到第二数据队列中；从第二数据队列中依次获取与当前创建的容器集合和用户存储请求对应的命名空间相关联的项目，并将其加载到第三处理队列。

可理解的是，在本实施例中，自定义控制器1211、第一处理队列1212以及循环计算机1213分别与自定义控制器1111、第一处理队列1112以及循环计算机1113相同，具体请参阅图11及相关文字内容，在此不再赘述。

请参阅图13，图13是本申请资源配额管理系统第三实施例的框架示意图。

可理解的是，在本实施例中，该资源配额管理系统具体包括项目资源配额控制器131、项目资源配额客户端132、数据中心133、核心资源交互组件134、项目资源变化监视器135、项目管理控制器136、配额管理控制器137、第一资源变更控制器138、项目资源监视器139、第一处理队列1310、第二处理队列1311、第一处理线程1312、第二处理线程1313、循环计算器1314以及项目资源注册处1315，且配额管理控制器137进一步包括容器集合监视器1371和用户存储请求监视器1372，而项目资源注册处1315进一步包括容器集合求值程序13151和用户存储请求求值程序13152。

其中，项目管理控制器136用于统计当前获取的项目下所有命名空间中pod和pvc配额，且该命名空间需用标签来与每一项目建立关联，以通过求值程序数据采集器，以命名空间为维度，获取每个pod或pvc的信息，最终汇总到项目对象中。

可理解的是，项目数据来源具体分为如下三部分：

1)通过项目资源变化监视器135监控项目对象的新增和修改动作，以将项目放进第一处理队列1310中；

2)通过项目资源变化监视器135监控pod、pvc的更新和删除，如果其对应的命名空间已关联项目，则将该项目放到第二处理队列1311中。

3)定时将当前获取的所有项目重新同步一遍，以将所有项目对象放入到第一处理队列1310和/或第二处理队列1311中。

其中，循环计算器1314具体为获取每种资源使用量的功能单元，而每种资源有自己的统计方式，如处理器能够从pod的limit(限制)字段中获取，局域网统计方式是从其他crd(CustomResourceDefinition，自定义资源)中查询。而项目资源注册处1315便是将自定义的资源统计方式，比如，容器集合求值程序13151和用户存储请求求值程序13152注册到循环计算器1314中，以使该循环计算器1314能够基于该容器集合求值程序13151和用户存储请求求值程序13152进行相应的资源配额信息的计算。

项目管理控制器136用于将当前所有的项目都加入到第一处理队列1310中；配额管理控制器137用于将与发生变化的资源配额(pod，pvc)所对应的命名空间相关联的项目加入到第二处理队列1311中，并获取资源配额。第一处理队列1310用于将其对应存储的项目放入到第一处理线程1312中，进行资源配额信息的计算，且第一处理队列1310中的项目所对应的资源配额上限能够被用户修改，而如果有项目的资源配额上限被修改，则其静态和动态的限额将不一致，而需要重新统计配额；第二处理队列1311用于将其对应存储的项目放入到第二处理线程1313中，进行资源配额信息的计算；第一处理线程1312和第二处理线程1313分别用于对第一处理队列1310和第二处理队列1311中的项目进行资源配额信息计算，且具体是默认并发5个线程来处理。

请继续参阅图14，图14是图13中资源配额管理系统中部分功能单元的框架示意图。

可理解的是，该资源配额管理系统还包括资源创建控制器1316、数据队列1317、脏数据队列1318、第三处理队列1319以及第三处理线程1320。

其中，该资源创建控制器1316用于对资源的创建过程进行校验，以防止创建的资源超过了相应项目的资源配额上限。且对所有资源的创建，均需要进行监控，并将相应的项目放入到第三处理队列1319中。

具体地，资源创建控制器1316用于对新建的资源，比如，pod和pvc等进行判断，以确定是否需要准入检查，且在创建对象后，会进入到资源创建控制器1316中后，会有专门的第三处理线程1320来进行处理，获取所在的命名空间的项目，并进行配额资源信息的计算，在自定义资源项目下，其申请的资源是否已经超过项目的配额上限了，如果超过了就返回创建失败的错误；如果成功，则通过该校验，并更新项目中的配额使用信息。

数据队列1317，用于存储需要处理的项目；脏数据队列1318用于在有新增的项目，且该项目此时正在处理中时，则放到脏数据队列1318中，以在执行完后，将脏数据队列1318中的项目放入到数据队列1317中。

第三处理队列1319用于校验当前申请的资源和项目统计配额是否超过限额。

请参阅图15，图15是本申请智能终端一实施例的框架示意图。该智能终端141包括相互耦接的存储器1411和处理器1412，处理器1412用于执行存储器1411中存储的程序指令，以实现上述任一资源配额管理方法实施例的步骤。

在一个具体的实施场景中，智能终端141可以包括但不限于：计算机、平板电脑、智能手机以及智能手表等任一合理的智能终端中的一种，本申请对此不做限定。

具体而言，处理器1412用于控制其自身以及存储器1411以实现上述任一视频显示方法实施例的步骤。处理器1412还可以称为CPU(Central Processing Unit，中央处理单元)。处理器1412可能是一种集成电路芯片，具有信号的处理能力。处理器1412还可以是通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器1412可以由集成电路芯片共同实现。

请参阅图16，图16是本申请计算机可读存储介质一实施例的框架示意图。计算机可读存储介质151存储有能够被处理器运行的程序指令1511，程序指令1511用于实现上述任一资源配额管理方法实施例的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法、装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims

1.一种多命名空间的资源配额管理方法，其特征在于，所述资源配额管理方法包括：

获取至少一个项目；

将至少一个所述项目与至少一个命名空间建立关联；

将与至少一个所述命名空间建立关联的所述项目加载到第一处理队列中；

启动至少一个第一线程，以将所述第一处理队列中的至少一个所述项目加载到至少一个所述第一线程中；

通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息。

2.根据权利要求1所述的资源配额管理方法，其特征在于，所述获取至少一个项目的步骤之后，所述将至少一个所述项目与至少一个命名空间建立关联之前，还包括：

统计至少一个所述项目对应的至少一个所述命名空间中的所述容器集合和所述的第一配额。

3.根据权利要求2所述的资源配额管理方法，其特征在于，所述将至少一个所述项目与至少一个命名空间建立关联的步骤之后，所述将与至少一个所述命名空间建立关联的所述项目加载到第一处理队列中的步骤之前，还包括：

获取每一所述命名空间中的所述容器集合和所述的第二配额；

将所述第二配额加载至与其对应的所述命名空间建立关联的所述项目中。

4.根据权利要求1所述的资源配额管理方法，其特征在于，所述通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息的步骤之后，还包括：

检测当前是否存在有所述项目发生变更；

响应于存在有第一项目发生变更，将所述第一项目加载到所述第一处理队列中，并重新执行所述启动至少一个第一线程，以将所述第一处理队列中的至少一个所述项目加载到至少一个所述第一线程中的步骤。

5.根据权利要求1所述的资源配额管理方法，其特征在于，所述通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息的步骤之后，还包括：

检测当前是否存在有所述容器集合和/或所述发生变更；

响应于存在所述容器集合和/或所述发生变更，检测发生变更的所述容器集合和/或所述对应的所述命名空间是否关联有所述项目；

响应于发生变更的所述容器集合和/或所述对应的所述命名空间关联有第二项目，对所述第二项目进行配额变更；

将配额变更后的所述第二项目加载到所述第一处理队列中，以重新执行所述启动至少一个第一线程，以将所述第一处理队列中的至少一个所述项目加载到至少一个所述第一线程中的步骤。

6.根据权利要求1所述的资源配额管理方法，其特征在于，所述通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息的步骤之后，还包括：

接收用户输入的配额修改指令，以对应修改至少一个所述项目的配额上限；

将已修改配额上限的第三项目加载到第二处理队列中；

启动至少一个第二线程，以将所述第二处理队列中的至少一个所述第三项目加载到至少一个所述第二线程中；

通过至少一个所述第二线程计算所述第二处理队列中的至少一个所述第三项目的资源配额信息。

7.根据权利要求1所述的资源配额管理方法，其特征在于，所述获取至少一个项目的步骤之前，还包括：

接收配额求值程序的注册请求，以将所述配额求值程序加载至循环计算机中；

所述启动至少一个第一线程，以将所述第一处理队列中的至少一个所述项目加载到至少一个所述第一线程中的步骤包括：

所述循环计算机启动至少一个所述第一线程，以将所述第一处理队列中的至少一个所述项目加载到至少一个所述第一线程中；

所述通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息的步骤包括：

所述循环计算机基于所述配额求值程序通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息。

8.根据权利要求1所述的资源配额管理方法，其特征在于，所述通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息的步骤之后，还包括：

每隔设定时间将当前获取的所有所述项目重新加载到所述第一处理队列中，并重新执行所述启动至少一个第一线程，以将所述第一处理队列中的至少一个所述项目加载到至少一个所述第一线程中的步骤。

9.根据权利要求1所述的资源配额管理方法，其特征在于，所述将至少一个所述项目与至少一个命名空间建立关联的步骤之后，所述将与至少一个所述命名空间建立关联的所述项目加载到第一处理队列中的步骤之前，还包括：

创建所述容器集合和所述；

检测当前创建的所述容器集合和所述用户存储请求是否超过与其对应的所述命名空间相关联的所述项目的配额上限；

响应于当前创建的所述容器集合和所述用户存储请求不超过与其对应的所述命名空间相关联的所述项目的配额上限，更新与其对应的所述命名空间相关联的所述项目的配额使用信息，并执行所述将与至少一个所述命名空间建立关联的所述项目加载到第一处理队列中的步骤。

10.根据权利要求9所述的资源配额管理方法，其特征在于，所述资源配额管理方法包括：

响应于当前创建的所述容器集合和所述用户存储请求超过与其对应的所述命名空间相关联的所述项目的配额上限，当前资源创建失败，并返回创建失败的错误信息。

11.根据权利要求9所述的资源配额管理方法，其特征在于，所述创建所述容器集合和所述的步骤之前，还包括：

获取所述容器集合和所述；

判断所述容器集合和所述对应的所述命名空间是否存在有相关联的所述项目；

响应于所述容器集合和所述对应的所述命名空间存在有相关联的所述项目，执行所述创建所述容器集合和所述的步骤。

12.根据权利要求9所述的资源配额管理方法，其特征在于，所述创建所述容器集合和所述的步骤之后，所述检测当前创建的所述容器集合和所述用户存储请求是否超过与其对应的所述命名空间相关联的所述项目的配额上限步骤之前，还包括：

将与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目加载到第三处理队列；

启动至少一个第三线程，以将所述第三处理队列中的所述项目加载到至少一个所述第三线程中；

通过至少一个所述第三线程计算所述第三处理队列中的所述项目的资源配额信息。

13.根据权利要求12所述的资源配额管理方法，所述将与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目加载到第三处理队列的步骤之前，还包括：

判断与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目是否正在处理中；

响应于与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目正在处理中，将与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目加载到第一数据队列中，并在其处理完成后，转存到第二数据队列。

14.根据权利要求13所述的资源配额管理方法，其特征在于，所述资源配额管理方法包括：

响应于与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目不在处理中，将与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目加载到第二数据队列中；

所述将与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目加载到第三处理队列的步骤包括：

从所述第二数据队列中依次获取与当前创建的所述容器集合和所述用户存储请求对应的所述命名空间相关联的所述项目，并将其加载到所述第三处理队列。

15.一种资源配额管理系统，其特征在于，所述资源配额管理系统包括：

自定义控制器，用于获取至少一个项目，以将至少一个所述项目与至少一个命名空间建立关联；

第一处理队列，用于存储由所述自定义控制器加载的与至少一个所述命名空间建立关联的所述项目；

循环计算机，用于启动至少一个第一线程，以将所述第一处理队列中的至少一个所述项目加载到至少一个所述第一线程中，并通过至少一个所述第一线程计算所述第一处理队列中的至少一个所述项目的资源配额信息。

16.根据权利要求15所述的资源配额管理系统，其特征在于，

所述资源配额管理方法还包括资源创建控制器，所述资源创建控制器用于创建所述容器集合和所述，并检测当前创建的所述容器集合和所述用户存储请求是否超过与其对应的所述命名空间相关联的所述项目的配额上限，以在当前创建的所述容器集合和所述用户存储请求不超过与其对应的所述命名空间相关联的所述项目的配额上限时，更新与其对应的所述命名空间相关联的所述项目的配额使用信息。

17.一种智能终端，其特征在于，所述智能终端包括相互耦接的存储器和处理器，所述处理器用于执行所述存储器中存储的程序指令，以实现如权利要求1-14中任一项所述的资源配额管理方法。

18.一种计算机可读存储介质，其上存储有程序指令，其特征在于，所述程序指令被处理器执行时，实现如权利要求1-14中任一项所述的资源配额管理方法。