CN111045819A - 分布式***的资源请求方法、装置、设备和存储介质 - Google Patents

分布式***的资源请求方法、装置、设备和存储介质 Download PDF

Info

Publication number
CN111045819A
CN111045819A CN201911158069.6A CN201911158069A CN111045819A CN 111045819 A CN111045819 A CN 111045819A CN 201911158069 A CN201911158069 A CN 201911158069A CN 111045819 A CN111045819 A CN 111045819A
Authority
CN
China
Prior art keywords
resource
request
quota
request end
allocated
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201911158069.6A
Other languages
English (en)
Inventor
高华龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Yunkuanzhiye Network Technology Co Ltd
Original Assignee
Beijing Yunkuanzhiye Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Yunkuanzhiye Network Technology Co Ltd filed Critical Beijing Yunkuanzhiye Network Technology Co Ltd
Priority to CN201911158069.6A priority Critical patent/CN111045819A/zh
Publication of CN111045819A publication Critical patent/CN111045819A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提出一种分布式***的资源请求方法、装置、设备和存储介质。分布式***的资源分配方法，包括：为分布式***中的多个请求端分配资源配额；接收多个请求端中的第一请求端发送的资源请求信息；根据资源请求信息，获取第一请求端的资源请求量；其中，在第一请求端的资源需求量小于或等于第一请求端对应的资源配额的情况下，资源请求量为资源需求量；在第一请求端的资源需求量大于第一请求端对应的资源配额的情况下，资源请求量为资源配额；为第一请求端提供资源请求量的资源，并获取第一请求端的资源需求量与对应的资源配额的第一差额；根据第一差额为多个请求端重新分配资源配额。本申请可以提高资源利用率和***效率。

Description

分布式***的资源请求方法、装置、设备和存储介质
技术领域
本申请涉及分布式***，尤其涉及一种分布式***的资源请求方法、装置、设备和存储介质。
背景技术
伴随着云计算、虚拟化技术、容器技术和微服务等带来的技术变革，分布式***被广泛应用各个行业，各个领域当中。随着分布式***的应用普及，每个具体的应用***所需的不同资源都面临着各自层次的质量管控问题，这些问题由于掌控资源的服务从单一的结点变成了分布式的多个结点，产生了许多新的挑战，其中最大的挑战就是分布式死锁问题。在分布式环境下，由于通讯延迟的不确定性、地域的分布性以及资源和数据的高度共享性等影响因素的存在，使得死锁预防和检测变得极为困难。在分布式计算***中，有两个以上的进程在并发执行，每个进程都在等待被其它的进程所占用的***资源而不能继续运行，即导致***中任何一个进程都无法运行下去，形成死循环，这就产生了死锁。
目前，可以通过破坏死锁产生的条件实现对死锁的预防。例如，规定只有当资源提供端能够满足请求端进程的全部资源请求时才把资源分配给请求端，请求端进程才开始执行，从而不会产生资源等待。但这些方法需要大量的资源预留，资源利用率较低，影响***效率。
发明内容
本申请实施例提供一种分布式***的资源请求方法、装置、设备和存储介质，以解决相关技术存在的问题，技术方案如下：
第一方面，本申请实施例提供了一种分布式***的资源分配方法，包括：
为分布式***中的多个请求端分配资源配额；
接收多个请求端中的第一请求端发送的资源请求信息；
根据资源请求信息，获取第一请求端的资源请求量，其中，在第一请求端的资源需求量小于或等于第一请求端对应的资源配额的情况下，资源请求量为资源需求量；在第一请求端的资源需求量大于第一请求端对应的资源配额的情况下，资源请求量为资源配额；
为第一请求端提供资源请求量的资源，并获取第一请求端的资源需求量与对应的资源配额的第一差额；
根据第一差额为多个请求端重新分配资源配额。
在一种实施方式中，资源请求信息包括资源请求量和第一差额；
在为分布式***中的多个请求端分配资源配额之后，方法还包括：
将分配后的资源配额的信息发送给多个请求端，以使多个请求端根据自身的资源需求量和对应的资源配额确定第一差额以及资源请求量。
在一种实施方式中，根据第一差额为多个请求端重新分配资源配额之前，方法还包括：
确定是否符合预设的配额重分条件，如果符合预设的配额重分条件，则根据第一差额为多个请求端重新分配资源配额；
其中，预设的配额重分条件包括以下多种条件中的至少一种条件：
多个请求端对应的第一差额达到预设的阈值；
当前时间达到预设的周期时间节点；
与多个请求端中的任一请求端之间的连接断开；
与分布式***中的任一请求端建立连接。
在一种实施方式中，根据第一差额为多个请求端重新分配资源配额，包括：
计算能够从多个请求端已经被分配的资源配额中回收的资源配额总量；
根据资源配额总量和多个请求端中的每一请求端对应的第一差额，分别计算每一请求端的待分配资源配额；
根据每一请求端的待分配资源配额，回收或增加每一请求端的资源配额，以使每一请求端被分配到待分配资源配额。
在一种实施方式中，计算能够从多个请求端已经被分配的资源配额中回收的资源配额总量，包括：
根据多个请求端中的每一请求端已经被分配的资源配额和预设的回收比例，计算能够从每一请求端回收的资源配额，以得到能够从多个请求端回收的资源配额总量。
在一种实施方式中，计算能够从多个请求端已经被分配的资源配额中回收的资源配额总量，包括：
计算多个请求端中的每一请求端已经被分配的资源配额与预设的保留配额之间的第二差额；
计算多个请求端对应的第二差额的总和，以得到能够从多个请求端中回收的资源配额总量。
在一种实施方式中，能够从多个请求端中的每一请求端回收的资源配额是相等的。
在一种实施方式中，根据资源配额总量和多个请求端中的每一请求端对应的第一差额，分别计算每一请求端的待分配资源配额，包括：
计算多个请求端对应的第一差额的总和；
根据多个请求端中的每一请求端对应的第一差额与第一差额的总和之间的比例，以及资源配额总量，计算每一请求端的待分配资源配额。
在一种实施方式中，根据资源配额总量和多个请求端中的每一请求端对应的第一差额，分别计算每一请求端的待分配资源配额，包括：
根据多个请求端中的每一请求端对应的第一差额，确定每一请求端对应的差额级别；
根据每一请求端对应的差额级别，确定每一请求端的分配权重；其中，差额级别与分配权重具有预设的映射关系；
计算多个请求端的分配权重的总和；
根据每一请求端的分配权重与分配权重的总和之间的比例，以及资源配额总量，计算每一请求端的待分配资源配额。
在一种实施方式中，根据每一请求端的待分配资源配额，回收或增加每一请求端的资源配额，包括：
对于多个请求端中的第二请求端，确定第二请求端的待分配资源配额与已经被分配的资源配额之间的大小关系；
在第二请求端的待分配资源配额小于已经被分配的资源配额的情况下，通知第二请求端回收其资源配额；
在第二请求端的待分配资源配额大于或等于已经被分配的资源配额的情况下，增加第二请求端的资源配额。
在一种实施方式中，增加第二请求端的资源配额，包括：
如果当前尚未分配的资源配额大于或等于第三差额，从当前尚未分配的资源配额中提取第三差额增加到第二请求端的资源配额中；第三差额为第二请求端的待分配资源配额与第二请求端的保留配额之间的差额；
如果当前尚未分配的资源配额小于第三差额，将当前尚未分配的资源配额全部分配给第二请求端，将第二请求端添加到配额等待列表中。
在一种实施方式中，在通知第二请求端回收其资源配额之后，方法还包括：
根据第二请求端发送的反馈信息，确定从第二请求端回收的资源配额；
使用从第二请求端回收的资源配额，为配额等待列表中的一个或多个请求端分配资源配额。
第二方面，本申请实施例提供了一种分布式***的资源请求方法，包括：
接收资源提供端分配的资源配额；其中，资源配额小于资源提供端的资源总量；
在自身的资源需求量小于或等于资源配额的情况下，确定资源请求量为资源需求量；
在资源需求量大于资源配额的情况下，确定资源请求量为资源配额；
获取资源请求量与资源配额的第一差额；
向资源提供端发送资源请求信息，资源请求信息包括资源请求量和第一差额，资源请求信息用于使资源提供端提供资源请求量的资源，并根据第一差额为资源提供端连接的多个请求端重新分配资源配额。
第三方面，本申请实施例提供一种分布式***的资源请求装置，包括：
初始分配模块，用于为分布式***中的多个请求端分配资源配额；
请求接收模块，用于接收多个请求端中的第一请求端发送的资源请求信息；
第一获取模块，用于根据资源请求信息，获取第一请求端的资源请求量，其中，在第一请求端的资源需求量小于或等于第一请求端对应的资源配额的情况下，资源请求量为资源需求量；在第一请求端的资源需求量大于第一请求端对应的资源配额的情况下，资源请求量为资源配额；
资源提供模块，用于为第一请求端提供资源请求量的资源，并获取第一请求端的资源需求量与对应的资源配额的第一差额；
重新分配模块，用于根据第一差额为多个请求端重新分配资源配额。
第四方面，本申请实施例提供一种分布式***的资源请求装置，包括：
配额接收模块，用于接收资源提供端分配的资源配额；其中，资源配额小于资源提供端的资源总量；
第一定量模块，用于在自身的资源需求量小于或等于资源配额的情况下，确定资源请求量为资源需求量；
第二定量模块，用于在资源需求量大于资源配额的情况下，确定资源请求量为资源配额；
第二获取模块，用于获取资源请求量与资源配额的第一差额；
请求发送模块，用于向资源提供端发送资源请求信息，资源请求信息包括资源请求量和第一差额，资源请求信息用于使资源提供端提供资源请求量的资源，并根据第一差额为资源提供端连接的多个请求端重新分配资源配额。
第五方面，本申请实施例提供了一种设备，该设备包括：存储器和处理器。其中，该存储器和该处理器通过内部连接通路互相通信，该存储器用于存储指令，该处理器用于执行该存储器存储的指令，并且当该处理器执行该存储器存储的指令时，使得该处理器执行上述各方面任一种实施方式中的方法。
第六方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储计算机程序，当计算机程序在计算机上运行时，上述各方面任一种实施方式中的方法被执行。
上述技术方案中的优点或有益效果至少包括：
资源提供端将资源总量分成多份资源配额，分别分配给多个请求端，在请求端请求资源时，为其提供配额范围内的资源，一个请求端不能完全占用资源提供端的全部资源，避免了死锁的产生。并且，动态地根据请求端的资源需求和资源配额之间的差额信息调整每个请求端的资源配额，避免为部分请求端过多地预留配额而造成其他请求端资源请求效率低下，提高了资源利用率和***效率。
上述概述仅仅是为了说明书的目的，并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外，通过参考附图和以下的详细描述，本申请进一步的方面、实施方式和特征将会是容易明白的。
附图说明
在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请公开的一些实施方式，而不应将其视为是对本申请范围的限制。
图1为本申请一实施例的分布式***的资源请求方法的流程图；
图2为本申请一实施例的分布式***的资源请求方法的流程图；
图3为本申请一实施例的分布式***的资源请求方法的流程图；
图4为应用示例中资源配额与更新流程的示意图；
图5为应用示例中配额更新过程示意图；
图6为本申请一实施例的分布式***的资源请求装置的结构框图；
图7为本申请一实施例的分布式***的资源请求装置的结构框图；
图8为本申请一实施例的分布式***的资源请求装置的结构框图；
图9为本申请一实施例的设备的结构框图。
具体实施方式
在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的精神或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的而非限制性的。
在分布式***中，有多个进程在并发执行。根据分布式***中各设备在进程中的处理位置，可以将这些设备分为竞争资源的请求端以及提供资源的资源提供端。请求端和资源提供端是相对的，同一个设备可以作为一个进程中请求资源的请求端，也可以作为其他进程中提供资源的资源提供端。一个资源提供端可以为多个请求端提供资源，一个请求端也可以向多个资源提供端请求资源。
图1示出根据本申请一实施例的分布式***的资源请求方法的流程图。该方法可以由分布式***的资源提供端实现。如图1所示，该方法可以包括：
步骤S101、为分布式***中的多个请求端分配资源配额；
步骤S102、接收多个请求端中的第一请求端发送的资源请求信息；第一请求端可以是多个请求端中的任意请求端；
步骤S103、根据资源请求信息，获取第一请求端的资源请求量，其中，在第一请求端的资源需求量小于或等于第一请求端对应的资源配额的情况下，资源请求量为资源需求量；在第一请求端的资源需求量大于第一请求端对应的资源配额的情况下，资源请求量为资源配额；
步骤S104、为第一请求端提供资源请求量的资源，并获取第一请求端的资源需求量与对应的资源配额的第一差额；
步骤S105、根据第一差额为多个请求端重新分配资源配额。
在上述技术方案中，资源提供端将资源总量分成多份资源配额，分别分配给多个请求端，在请求端请求资源时，仅为其提供配额范围内的资源，一个请求端不能完全占用资源提供端的全部资源，避免了死锁的产生。并且，动态地根据请求端的资源需求和资源配额之间的差额调整每个请求端的资源配额，避免为部分请求端过多地预留配额而造成其他请求端资源请求效率低下，提高了资源利用率和***效率。
作为一种示例，资源请求信息包括资源请求量和第一差额。在步骤S101或步骤S105，为分布式***中的多个请求端分配或者重新分配资源配额之后，方法还包括：
将分配后的资源配额的信息发送给多个请求端，以使多个请求端根据自身的资源需求量和对应的资源配额确定第一差额以及资源请求量。
在上述示例中，请求端知道自己的资源配额，在需要向资源提供端请求资源时，可以根据自己的资源需求量和资源配额，计算自己所能请求到的资源量，在发送资源请求时，携带请求量信息，资源提供端直接按照该请求量提供资源。具体地，在资源需求量大于资源配额时，请求量为资源配额；在资源需求量小于或等于资源配额时，请求量为资源需求量。请求端还可以计算资源需求量和资源配额之间的第一差额，在资源请求中携带请求量和第一差额。资源提供端告知请求端其资源配额，由请求端对请求量和第一差额进行计算，资源提供端可以直接按照请求量为请求端分配资源配额。从而减少了资源提供端的运算量，提高了***的处理效率。
需要说明的是，第一差额可以指资源需求量超过资源配额的数量，在资源需求量小于或等于资源配额的情况下，资源请求中携带的第一差额可以为负值，也可以设置为0。
在另一种示例中，资源提供端可以不将分配后的资源配额的信息发送给请求端，请求端在发起资源请求时携带自身的资源需求量，则资源提供端可以根据请求端的资源需求量和资源配额，确定分配给请求端的资源数量是资源需求量还是资源配额，以及计算第一差额。
作为一种示例性的实施方式，在步骤S105、根据第一差额为多个请求端重新分配资源配额之前，方法还包括：
确定是否符合预设的配额重分条件，如果符合预设的配额重分条件，则根据第一差额为多个请求端重新分配资源配额。
其中，预设的配额重分条件包括以下多种条件中的至少一种条件：
条件一：多个请求端对应的第一差额达到预设的阈值。
示例性地，多个请求端的第一差额达到预设的阈值，可以是多个请求端的第一差额的总和达到了预设的阈值；也可以是其中的一个请求端的第一差额达到了预设的阈值；还可以是其中的多个第一差额达到预设的阈值，例如第一差额达到预设的阈值的请求端个数超过了限额。如果其中的一个请求端的第一差额过高，或者多个请求端中出现了大面积的差额超标，意味着当前的资源配额分配失衡，可以对资源配额进行重分配，以避免影响资源分配效率以至于影响分布式***的全局工作效率。
条件二：当前时间达到预设的周期时间节点。
示例性地，可以以预设的频率为多个请求端的资源配额进行重新分配，即在当前时间达到预设的周期时间节点时进行重分配。可以在资源提供端上线时开始计时，也可以在资源提供端对应的请求端的上线数量超过两个时开始计时。
条件三：与多个请求端中的任一请求端之间的连接断开。
当资源提供端连接有多个请求端时，可以为这多个请求端提供资源，根据本申请实施例，需要为其分配资源配额。当与其中任一请求端之间断开连接时，则不需要为该请求端提供资源以及分配资源配额，原本分配给该请求端的资源配额可以回收用于分配给其他请求端，此时，可以对全局的资源量进行重新分配。
条件四：与分布式***中的任一请求端建立连接。
当资源提供端与分布式***中的任意请求端建立连接时，即有新的请求端上线，则需要为新的请求端分配资源配额，以免新的请求端无法获得资源。示例性地，可以在新的请求端上线时即为多个在线的请求端重新分配资源配额。也可以在全局资源总量中预留一部分用于分配给新上线的请求端，先从全局的预留总配额中提取出分配给新上线的请求端的基础资源配额，再为在线的所有请求端重新分配资源配额。
作为一种示例性实施方式，如图2所示的本申请实施例资源请求方法的流程示意图，步骤S105、根据第一差额为多个请求端重新分配资源配额，可以包括：
步骤S201、计算能够从多个请求端已经被分配的资源配额中回收的资源配额总量；
步骤S202、根据资源配额总量和多个请求端中的每一请求端对应的第一差额，分别计算每一请求端的待分配资源配额；
步骤S203、根据每一请求端的待分配资源配额，回收或增加每一请求端的资源配额，以使每一请求端被分配到待分配资源配额。
在该示例性实施方式中，为多个请求端重新分配资源配额，是对多个请求端已经被分配的资源配额先进行回收，集中在一起再根据每一请求端的资源需求量和当前资源配额的第一差额进行分配，根据全局的资源配额利用情况进行重新分配资源配额，从而资源配额分配更公平，可以提高***的工作效率。在该示例性实施方式中，根据全局的资源配额利用情况明确了每一请求端的待分配资源配额后，再对每一请求端的资源配额进行回收或增加，而不是强制更改每一请求端的资源配额，使得资源重新分配不影响各进程对资源的占用，保障了***进程的运行可靠性。
步骤S201、计算能够从多个请求端已经被分配的资源配额中回收的资源配额总量，可以有多种实施方式。其中一种实施方式是将全部资源配额回收再分配。本申请实施例还提供另外多种示例性实施方式，这些示例性实施方式为多个请求端留有一定的保留配额，以避免请求端的资源配额在多次分配过程中浮动太大，以及避免当一些请求端的需求量小于资源配额，第一差额为负值或零时，可能分不到资源配额，从而造成长期的资源等待。以下是几种示例性方式：
示例一、步骤S201包括：
根据多个请求端中的每一请求端已经被分配的资源配额和预设的回收比例，计算能够从每一请求端回收的资源配额，以得到能够从多个请求端回收的资源配额总量。
在该示例中，按比例回收资源配额。如此，请求端可以留有与之前被分配的资源配额成比例的资源配额。在请求端的资源需求无压力，即第一差额为负值或0时，保留配额可以是该请求端的全部资源配额。也就是说，一个请求端的保留配额可以是这个请求端在全局配额重新分配过程中能够获得的资源配额的最小值。请求端至少可以留有与之前被分配的配额成比例的资源配额，可以使请求端的资源配额的浮动在合理范围内，避免造成配额落差，需要反复调整配额。
示例二、步骤S201包括：
计算多个请求端中的每一请求端已经被分配的资源配额与预设的保留配额之间的第二差额；
计算多个请求端对应的第二差额的总和，以得到能够从多个请求端中回收的资源配额总量。
在该示例中，每一请求端的保留配额都是预设的，每个请求端能够至少持有的资源配额是相等的。
示例三、
能够从多个请求端中的每一请求端回收的资源配额是相等的。
在该示例中，能够从每一请求端回收的资源配额都是相等的，每一请求端等额返还资源配额。
步骤S202、根据资源配额总量和多个请求端中的每一请求端对应的第一差额，分别计算每一请求端的待分配资源配额，也可以有多种示例性实施方式：
示例一、步骤S202包括：
计算多个请求端对应的第一差额的总和；
根据多个请求端中的每一请求端对应的第一差额与第一差额的总和之间的比例，以及资源配额总量，计算每一请求端的待分配资源配额。
在该示例中，资源提供端根据各请求端对应的第一差额与总差额之间的比例，可以采用该比例作为权重确定每一请求端的待分配资源配额，能够精确地根据各请求端的资源需求压力重新分配资源配额。例如，将比例与资源配额总量相乘，得到每一请求端的待分配资源配额。如果为请求端设置了保留配额，可以将比例与资源配额总量相乘后加上保留配额，得到每一请求端的待分配资源配额。
示例二、步骤S202包括：
根据多个请求端中的每一请求端对应的第一差额，确定每一请求端对应的差额级别；
根据每一请求端对应的差额级别，确定每一请求端的分配权重；其中，差额级别与分配权重具有预设的映射关系；
计算多个请求端的分配权重的总和；
根据每一请求端的分配权重与分配权重的总和之间的比例，以及资源配额总量，计算每一请求端的待分配资源配额。
在该示例中，先确定每一请求端对应的差额级别，按级别来确定分配权重，然后采用该分配权重确定每一请求端的待分配资源配额。该示例对请求端的资源需求压力进行级别划分，差额级别相同但第一差额不同的两个以上的请求端能够获得相同的资源配额，第一差额相近的请求端获得的资源配额也相近或相同，避免因偶然的资源占用量突变而导致资源配额反复变化，起到防抖动的效果。示例性地，每一组相邻的差额级别对应的最小差额之间的间距可以是相同的，也可以是不同的。
在一些示例性实施方式中，步骤S203、根据每一请求端的待分配资源配额，回收或增加每一请求端的资源配额，可以包括：
对于多个请求端中的第二请求端，确定第二请求端的待分配资源配额与已经被分配的资源配额之间的大小关系；其中，第二请求端可以是多个请求端中的任意请求端；
在第二请求端的待分配资源配额小于已经被分配的资源配额的情况下，通知第二请求端回收其资源配额；
在第二请求端的待分配资源配额大于或等于已经被分配的资源配额的情况下，增加第二请求端的资源配额。
在上述示例性实施方式中，增加第二请求端的资源配额，可以包括：
如果当前尚未分配的资源配额大于或等于第二请求端的待分配资源配额与第二请求端的保留配额之间的第三差额，从当前尚未分配的资源配额中提取第三差额增加到第二请求端的资源配额中；
如果当前尚未分配的资源配额小于第三差额，将当前尚未分配的资源配额全部分配给第二请求端，将第二请求端添加到配额等待列表中。
示例性地，资源提供端可以将自身的资源总量全部用于为连接的多个请求端分配和重新分配资源配额，也可以留有一部分资源量用于为新上线的请求端分配基础资源配额。资源提供端可以有资源总量的全部或部分作为可动态分配的调整总配额。在重新分配过程中，明确了每一请求端的待分配资源配额后，需要使待分配配额生效。对于每一请求端，如果待分配资源配额相对已分配资源配额下降了，则通知请求端回收其资源配额，以使请求端及时解除对过多资源的占用。如果待分配资源配额相对已分配资源配额上升了，则需要从可动态分配的调整总配额中提取该请求端的待分配资源配额与保留配额之间的差额部分(即第三差额)分配给请求端。但由于资源配额是动态调整的，在请求端未能及时解除对资源的占用和返还资源配额时，实际可分配的资源配额(即当前尚未分配的资源配额)会小于上述可动态分配的调整总配额，因此可能会不足够为请求端分配其待分配的资源配额，则需要将请求端添加到配额等待列表。
进一步地，在通知请求端第二回收其资源配额之后，还包括：
根据第二请求端发送的反馈信息，确定从第二请求端回收的资源配额；
使用从第二请求端回收的资源配额，为配额等待列表中的一个或多个请求端分配资源配额。
在上述技术方案中，请求端返回反馈信息，告知资源提供端当前该请求端可以被回收用于重分配的资源配额有多少，资源提供端即可利用回收的资源配额来为配额等待列表中的一个或多个请求端分配配额。资源等待列表中的请求端获取到足够的资源配额则可从资源等待列表中被移除。
在一些实施方式中，资源提供端将回收的资源配额添加到实际可分配的资源配额中，从实际可分配的资源配额提取部分或全部来为配额等待列表中的请求端分配。作为示例，回收的资源配额也可以优先为新上线的请求端提供基础资源配额。
图3示出根据本申请一实施例的分布式***的资源请求方法的流程图。该方法可以由分布式***的请求端实现。如图3所示，该方法包括：
步骤S301、接收资源提供端分配的资源配额；其中，资源配额小于资源提供端的资源总量；
步骤S302、在自身的资源需求量小于或等于资源配额的情况下，确定资源请求量为资源需求量；
步骤S303、在资源需求量大于资源配额的情况下，确定资源请求量为资源配额；
步骤S304、获取资源请求量与资源配额的第一差额；
步骤S305、向资源提供端发送资源请求信息，资源请求信息包括资源请求量和第一差额，资源请求信息用于使资源提供端提供资源请求量的资源，并根据第一差额为资源提供端连接的多个请求端重新分配资源配额。
上述技术方案，请求端请求资源的数量限制为小于资源总量的资源配额，在请求端请求资源时，仅能获得配额范围内的资源，一个请求端不能完全占用资源提供端的全部资源，避免了死锁的产生。并且，动态地根据请求端的资源需求和资源配额之间的差额信息调整每个请求端的资源配额，避免为部分请求端过多地预留配额而造成其他请求端资源请求效率低下，提高了资源利用率和***效率。
以下给出本申请实施例的应用示例。在该应用实例中的各种技术细节的实施方式应该理解为是可选的，而不是必须的。
在应用示例中，资源提供端上线时，可以为其连接的多个请求端分配预先设定的基础资源配额。
当有新的请求端上线时，资源提供端可执行请求端上线流程。资源提供端的全部资源配额可以划分为预留总配额和调整总配额，调整总配额可以用于动态地根据请求端的资源需求压力分配给请求端，预留总配额可以预留给新上线的请求端，为新上线的请求端配置基础资源配额，以免新上线的请求端完全不能获得资源，产生死锁的可能性。当资源提供端从请求端回收资源配额后，可以将资源配额优先返还给预留总配额，使得资源总配额始终有余量。请求端上线时上线流程包括从预留总配额中给出分配给该上线的请求端的基础资源配额的步骤以及该步骤之后的资源配额计算与更新流程。
其中，请求端的基础资源配额可以为预设的默认值default_token_min。但由于资源提供端并不能感知请求端的上线时间，而请求端占用资源不能及时释放，因此预留总配额并不一定能时刻保持高于该预设的默认值。出于这样的考虑，新上线的请求端的基础配额token_base可以按如下方式计算：
token_base＝min(default_token_min,token_rsvr)，其中，token_rsvr为当前的预留总配额。
图4是资源配额与更新流程的示意图。该流程先计算当前能够从各请求端中回收的总分配配额，还可以计算被各请求端保留的属于各请求端的保留配额。然后，根据请求端的资源需求压力，即第一差额，计算所有请求端的分配权重，以及对应的加权和。遍历每一个请求端，计算请求端的待分配资源配额。具体的计算方式可参考上述步骤202的示例性实施方式。在该应用示例中，可以为每个请求端设置限制配额，如果存在限制配额，则请求端的实际待分配资源配额要更新为限制配额和计算出来的待分配资源配额之中的最小值。然后更新实际可分配的资源配额为原来的可分配资源配额减去该请求端的待分配资源配额。
在存在限制配额的情况下，在遍历完请求端后，实际可分配的资源配额可能大于0，此时，可以将剩余的资源配额全部分配给第一个分配权重不为0的请求端。然后，遍历所有的请求端让资源配额生效。
生效过程可参考图5所示的配额更新过程示意图。遍历每一个请求端，对于当前请求端，判断待分配资源配额是否与已分配的配额相等，如果相等则可以结束对当前请求端的资源配额生效处理。如果不等，则判断资源配额时增加了还是减少了。如果资源配额减少，则通知当前请求端返还资源，该通知中可以携带版本号。如果资源配额增加，则从尚未分配的资源配额中取出资源配额分配给当前请求端。如果当前请求端已获得待分配资源配额，则结束对当前请求端的资源配额生效处理。如果当前请求端不能获得足够的待分配资源配额，则将当前请求端添加到资源配额等待列表。
通知请求端返还资源配额后，可以等待接收请求端的反馈信息。在接收到请求端的反馈信息时，可以先核对版本号是否与通知中的版本号相同，在相同的情况下才将反馈信息中指示的可回收配额回收。回收的资源可以优先补充给预留总配额，在有余量时再补充到实际可分配的资源配额，用于为资源配额等待列表中的请求端分配配额，或者在上述图5所示的配额更新过程中分配给遍历到的请求端。
在请求端下线时，可以将该请求端中的资源配额返还给资源提供端，包括将基础资源配额返还给预留总配额。然后，可以执行图4所示的资源配额计算与更新流程。
需要说明的是，尽管以图4和图5作为应用示例介绍了分布式***的资源请求方法如上，但本领域技术人员能够理解，本申请应不限于此。事实上，用户完全可根据个人喜好和/或实际应用场景灵活设定其中的技术细节。
这样，根据本申请上述实施例，资源提供端将资源总量分成多份资源配额，分别分配给多个请求端，在请求端请求资源时，仅为其提供配额范围内的资源，一个请求端不能完全占用资源提供端的全部资源，避免了死锁的产生。并且，动态地根据请求端的资源需求和资源配额之间的差额信息调整每个请求端的资源配额，避免为部分请求端过多地预留配额而造成其他请求端资源请求效率低下，提高了资源利用率和***效率。
图6示出根据本申请一实施例的分布式***的资源请求装置的结构框图。如图6所示，该装置600可以包括：
初始分配模块601，用于为分布式***中的多个请求端分配资源配额；
请求接收模块602，用于接收多个请求端中的第一请求端发送的资源请求信息；
第一获取模块603，用于根据资源请求信息，获取第一请求端的资源请求量，其中，在第一请求端的资源需求量小于或等于第一请求端对应的资源配额的情况下，资源请求量为资源需求量；在第一请求端的资源需求量大于第一请求端对应的资源配额的情况下，资源请求量为资源配额；
资源提供模块604，用于为第一请求端提供资源请求量的资源，并获取第一请求端的资源需求量与对应的资源配额的第一差额；
重新分配模块605，用于根据第一差额为多个请求端重新分配资源配额。
本申请实施例各装置中的各模块的功能可以参见上述方法中的对应描述，在此不再赘述
在一种实施方式中，资源请求信息包括资源请求量和第一差额。装置600还包括：
配额告知模块，用于将分配后的资源配额的信息发送给多个请求端，以使多个请求端根据自身的资源需求量和对应的资源配额确定第一差额以及资源请求量。
在一种实施方式中，该装置600还包括：
重分判断模块，用于确定是否符合预设的配额重分条件，如果符合预设的配额重分条件，则根据第一差额为多个请求端重新分配资源配额；
其中，预设的配额重分条件包括以下多种条件中的至少一种条件：
多个请求端对应的第一差额达到预设的阈值；
当前时间达到预设的周期时间节点；
与多个请求端中的任一请求端之间的连接断开；
与分布式***中的任一请求端建立连接。
在一种实施方式中，如图7所示的资源请求装置的结构框图所示，重分配模块605包括：
回收总量计算单元701，用于计算能够从多个请求端已经被分配的资源配额中回收的资源配额总量；
预分配单元702，用于根据资源配额总量和多个请求端中的每一请求端对应的第一差额，分别计算每一请求端的待分配资源配额；
配额生效单元703，根据每一请求端的待分配资源配额，回收或增加每一请求端的资源配额，以使每一请求端被分配到待分配资源配额。
在一种实施方式中，回收总量计算单元701包括：
比例回收单元，用于根据多个请求端中的每一请求端已经被分配的资源配额和预设的回收比例，计算能够从每一请求端回收的资源配额，以得到能够从多个请求端回收的资源配额总量。
在一种实施方式中，回收总量计算单元701包括：
回收计算子单元，用于计算多个请求端中的每一请求端已经被分配的资源配额与预设的保留配额之间的第二差额；
总量计算子单元，用于计算多个请求端对应的第二差额的总和，以得到能够从多个请求端中回收的资源配额总量。
在一种实施方式中，能够从多个请求端中的每一请求端回收的资源配额是相等的。
在一种实施方式中，预分配单元702包括：
差额总和计算子单元，用于计算多个请求端对应的第一差额的总和；
第一分配子单元，用于根据多个请求端中的每一请求端对应的第一差额与第一差额的总和之间的比例，以及资源配额总量，计算每一请求端的待分配资源配额。
在一种实施方式中，预分配单元702包括：
差额级别确定子单元，用于根据多个请求端中的每一请求端对应的第一差额，确定每一请求端对应的差额级别；
分配权重确定子单元，用于根据每一请求端对应的差额级别，确定每一请求端的分配权重；其中，差额级别与分配权重具有预设的映射关系；
权重总和计算子单元，用于计算多个请求端的分配权重的总和；
第二分配子单元，用于根据每一请求端的分配权重与分配权重的总和之间的比例，以及资源配额总量，计算每一请求端的待分配资源配额。
在一种实施方式中，配额生效单元703包括：
判断子单元，用于对于多个请求端中的第二请求端，确定第二请求端的待分配资源配额与已经被分配的资源配额之间的大小关系；
回收子单元，用于在第二请求端的待分配资源配额小于已经被分配的资源配额的情况下，通知第二请求端回收其资源配额；
增加子单元，用于在第二请求端的待分配资源配额大于或等于已经被分配的资源配额的情况下，增加第二请求端的资源配额。
在一种实施方式中，增加子单元具体用于：
如果当前尚未分配的资源配额大于或等于第三差额，从当前尚未分配的资源配额中提取第三差额增加到第二请求端的资源配额中；第三差额为第二请求端的待分配资源配额与第二请求端的保留配额之间的差额；
如果当前尚未分配的资源配额小于第三差额，将当前尚未分配的资源配额全部分配给第二请求端，将第二请求端添加到配额等待列表中。
在一种实施方式中，配额生效子单元703还包括：
反馈确定单元，用于根据第二请求端发送的反馈信息，确定从第二请求端回收的资源配额；
第三分配子单元，用于使用从第二请求端回收的资源配额，为配额等待列表中的一个或多个请求端分配资源配额。
图8示出根据本申请一实施例的分布式***的资源请求装置的结构框图。如图8所示，该装置800可以包括：
配额接收模块801，用于接收资源提供端分配的资源配额；其中，资源配额小于资源提供端的资源总量；
第一定量模块802，用于在自身的资源需求量小于或等于资源配额的情况下，确定资源请求量为资源需求量；
第二定量模块803，用于在资源需求量大于资源配额的情况下，确定资源请求量为资源配额；
第二获取模块804，用于获取资源请求量与资源配额的第一差额；
请求发送模块805，用于向资源提供端发送资源请求信息，资源请求信息包括资源请求量和第一差额，资源请求信息用于使资源提供端提供资源请求量的资源，并根据第一差额为资源提供端连接的多个请求端重新分配资源配额。
图9示出根据本申请一实施例的设备的结构框图。如图9所示，该设备包括：存储器910和处理器920，存储器910内存储有可在处理器920上运行的计算机程序。处理器920执行该计算机程序时实现上述实施例中的方法。存储器910和处理器920的数量可以为一个或多个。
该设备还包括：
通信接口930，用于与外界设备进行通信，进行数据交互传输。
如果存储器910、处理器920和通信接口930独立实现，则存储器910、处理器920和通信接口930可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
可选的，在具体实现上，如果存储器910、处理器920及通信接口930集成在一块芯片上，则存储器910、处理器920及通信接口930可以通过内部接口完成相互间的通信。
本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现本申请实施例中提供的方法。
本申请实施例还提供了一种芯片，该芯片包括，包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行本申请实施例提供的方法。
本申请实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行申请实施例提供的方法。
应理解的是，上述处理器可以是中央处理器(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(fieldprogrammablegate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(advanced RISC machines，ARM)架构的处理器。
进一步地，可选的，上述存储器可以包括只读存储器和随机存取存储器，还可以包括非易失性随机存取存储器。该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以包括只读存储器(read-onlymemory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以包括随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用。例如，静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic random access memory，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data date SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhancedSDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行***、装置或设备(如基于计算机的***、包括处理器的***或其他可以从指令执行***、装置或设备取指令并执行指令的***)使用，或结合这些指令执行***、装置或设备而使用。
应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行***执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。
以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (17)

1.一种分布式***的资源分配方法，其特征在于，包括：
为分布式***中的多个请求端分配资源配额；
接收所述多个请求端中的第一请求端发送的资源请求信息；
根据所述资源请求信息，获取所述第一请求端的资源请求量；其中，在所述第一请求端的资源需求量小于或等于所述第一请求端对应的资源配额的情况下，所述资源请求量为所述资源需求量；在所述第一请求端的资源需求量大于所述第一请求端对应的资源配额的情况下，所述资源请求量为所述资源配额；
为所述第一请求端提供所述资源请求量的资源，并获取所述第一请求端的资源需求量与所述对应的资源配额的第一差额；
根据所述第一差额为所述多个请求端重新分配资源配额。
2.根据权利要求1所述的方法，其特征在于，所述资源请求信息包括所述资源请求量和所述第一差额；
在所述为分布式***中的多个请求端分配资源配额之后，所述方法还包括：
将分配后的资源配额的信息发送给所述多个请求端，以使所述多个请求端根据自身的资源需求量和对应的资源配额确定所述第一差额以及所述资源请求量。
3.根据权利要求1所述的方法，其特征在于，所述根据所述第一差额为所述多个请求端重新分配资源配额之前，所述方法还包括：
确定是否符合预设的配额重分条件，如果符合所述预设的配额重分条件，则根据所述第一差额为所述多个请求端重新分配资源配额；
其中，所述预设的配额重分条件包括以下多种条件中的至少一种条件：
所述多个请求端对应的第一差额达到预设的阈值；
当前时间达到预设的周期时间节点；
与所述多个请求端中的任一请求端之间的连接断开；
与所述分布式***中的任一请求端建立连接。
4.根据权利要求1至3任一项所述的方法，其特征在于，所述根据所述第一差额为所述多个请求端重新分配资源配额，包括：
计算能够从所述多个请求端已经被分配的资源配额中回收的资源配额总量；
根据所述资源配额总量和所述多个请求端中的每一请求端对应的所述第一差额，分别计算所述每一请求端的待分配资源配额；
根据所述每一请求端的待分配资源配额，回收或增加所述每一请求端的资源配额，以使所述每一请求端被分配到所述待分配资源配额。
5.根据权利要求4所述的方法，其特征在于，所述计算能够从所述多个请求端已经被分配的资源配额中回收的资源配额总量，包括：
根据所述多个请求端中的每一请求端已经被分配的资源配额和预设的回收比例，计算能够从所述每一请求端回收的资源配额，以得到能够从所述多个请求端回收的资源配额总量。
6.根据权利要求4所述的方法，其特征在于，所述计算能够从所述多个请求端已经被分配的资源配额中回收的资源配额总量，包括：
计算所述多个请求端中的每一请求端已经被分配的资源配额与预设的保留配额之间的第二差额；
计算所述多个请求端对应的第二差额的总和，以得到能够从所述多个请求端中回收的资源配额总量。
7.根据权利要求4所述的方法，其特征在于，能够从所述多个请求端中的每一请求端回收的资源配额是相等的。
8.根据权利要求4所述的方法，其特征在于，所述根据所述资源配额总量和所述多个请求端中的每一请求端对应的所述第一差额，分别计算所述每一请求端的待分配资源配额，包括：
计算所述多个请求端对应的第一差额的总和；
根据所述多个请求端中的每一请求端对应的第一差额与所述第一差额的总和之间的比例，以及所述资源配额总量，计算所述每一请求端的待分配资源配额。
9.根据权利要求4所述的方法，其特征在于，所述根据所述资源配额总量和所述多个请求端中的每一请求端对应的所述第一差额，分别计算所述每一请求端的待分配资源配额，包括：
根据所述多个请求端中的每一请求端对应的第一差额，确定所述每一请求端对应的差额级别；
根据所述每一请求端对应的差额级别，确定所述每一请求端的分配权重；其中，所述差额级别与所述分配权重具有预设的映射关系；
计算所述多个请求端的分配权重的总和；
根据所述每一请求端的分配权重与所述分配权重的总和之间的比例，以及所述资源配额总量，计算所述每一请求端的待分配资源配额。
10.根据权利要求4所述的方法，其特征在于，所述根据所述每一请求端的待分配资源配额，回收或增加所述每一请求端的资源配额，包括：
对于所述多个请求端中的第二请求端，确定所述第二请求端的待分配资源配额与已经被分配的资源配额之间的大小关系；
在所述第二请求端的待分配资源配额小于已经被分配的资源配额的情况下，通知所述第二请求端回收其资源配额；
在所述第二请求端的待分配资源配额大于或等于已经被分配的资源配额的情况下，增加所述第二请求端的资源配额。
11.根据权利要求10所述的方法，其特征在于，所述增加所述第二请求端的资源配额，包括：
如果当前尚未分配的资源配额大于或等于第三差额，从当前尚未分配的资源配额中提取所述第三差额增加到所述第二请求端的资源配额中；所述第三差额为所述第二请求端的待分配资源配额与所述第二请求端的保留配额之间的差额；
如果当前尚未分配的资源配额小于所述第三差额，将当前尚未分配的资源配额全部分配给所述第二请求端，将所述第二请求端添加到配额等待列表中。
12.根据权利要求11所述的方法，其特征在于，在通知所述第二请求端回收其资源配额之后，所述方法还包括：
根据所述第二请求端发送的反馈信息，确定从所述第二请求端回收的资源配额；
使用从所述第二请求端回收的资源配额，为所述配额等待列表中的一个或多个请求端分配资源配额。
13.一种分布式***的资源请求方法，其特征在于，包括：
接收资源提供端分配的资源配额；其中，所述资源配额小于所述资源提供端的资源总量；
在自身的资源需求量小于或等于所述资源配额的情况下，确定资源请求量为所述资源需求量；
在所述资源需求量大于所述资源配额的情况下，确定资源请求量为所述资源配额；
获取所述资源请求量与所述资源配额的第一差额；
向所述资源提供端发送资源请求信息，所述资源请求信息包括所述资源请求量和所述第一差额，所述资源请求信息用于使所述资源提供端提供所述资源请求量的资源，并根据所述第一差额为所述资源提供端连接的多个请求端重新分配资源配额。
14.一种分布式***的资源请求装置，其特征在于，包括：
初始分配模块，用于为分布式***中的多个请求端分配资源配额；
请求接收模块，用于接收所述多个请求端中的第一请求端发送的资源请求信息；
第一获取模块，用于根据所述资源请求信息，获取所述第一请求端的资源请求量，其中，在所述第一请求端的资源需求量小于或等于所述第一请求端对应的资源配额的情况下，所述资源请求量为所述资源需求量；在所述第一请求端的资源需求量大于所述第一请求端对应的资源配额的情况下，所述资源请求量为所述资源配额；
资源提供模块，用于为所述第一请求端提供所述资源请求量的资源，并获取所述第一请求端的资源需求量与所述对应的资源配额的第一差额；
重新分配模块，用于根据所述第一差额为所述多个请求端重新分配资源配额。
15.一种分布式***的资源请求装置，其特征在于，包括：
配额接收模块，用于接收资源提供端分配的资源配额；其中，所述资源配额小于所述资源提供端的资源总量；
第一定量模块，用于在自身的资源需求量小于或等于所述资源配额的情况下，确定资源请求量为所述资源需求量；
第二定量模块，用于在所述资源需求量大于所述资源配额的情况下，确定资源请求量为所述资源配额；
第二获取模块，用于获取所述资源请求量与所述资源配额的第一差额；
请求发送模块，用于向所述资源提供端发送资源请求信息，所述资源请求信息包括所述资源请求量和所述第一差额，所述资源请求信息用于使所述资源提供端提供所述资源请求量的资源，并根据所述第一差额为所述资源提供端连接的多个请求端重新分配资源配额。
16.一种设备，其特征在于，包括：包括处理器和存储器，所述存储器中存储指令，所述指令由处理器加载并执行，以实现如权利要求1至13任一项所述的方法。
17.一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-13中任一项所述的方法。
CN201911158069.6A 2019-11-22 2019-11-22 分布式***的资源请求方法、装置、设备和存储介质 Pending CN111045819A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911158069.6A CN111045819A (zh) 2019-11-22 2019-11-22 分布式***的资源请求方法、装置、设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911158069.6A CN111045819A (zh) 2019-11-22 2019-11-22 分布式***的资源请求方法、装置、设备和存储介质

Publications (1)

Publication Number Publication Date
CN111045819A true CN111045819A (zh) 2020-04-21

Family

ID=70233154

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911158069.6A Pending CN111045819A (zh) 2019-11-22 2019-11-22 分布式***的资源请求方法、装置、设备和存储介质

Country Status (1)

Country Link
CN (1) CN111045819A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113886078A (zh) * 2021-09-28 2022-01-04 江苏安超云软件有限公司 基于动态阈值机制实现配额统一管理的方法及应用
CN117369891A (zh) * 2023-12-06 2024-01-09 苏州元脑智能科技有限公司 一种服务器的启动运行方法、装置、服务器及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104468755A (zh) * 2014-11-27 2015-03-25 中国联合网络通信集团有限公司 实现应用性能保障的方法和装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104468755A (zh) * 2014-11-27 2015-03-25 中国联合网络通信集团有限公司 实现应用性能保障的方法和装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113886078A (zh) * 2021-09-28 2022-01-04 江苏安超云软件有限公司 基于动态阈值机制实现配额统一管理的方法及应用
CN117369891A (zh) * 2023-12-06 2024-01-09 苏州元脑智能科技有限公司 一种服务器的启动运行方法、装置、服务器及存储介质
CN117369891B (zh) * 2023-12-06 2024-02-27 苏州元脑智能科技有限公司 一种服务器的启动运行方法、装置、服务器及存储介质

Similar Documents

Publication Publication Date Title
US10361928B2 (en) Cluster instance management system
US9588789B2 (en) Management apparatus and workload distribution management method
CN108667748B (zh) 一种控制带宽的方法、装置、设备和存储介质
CN109684074B (zh) 物理机资源分配方法及终端设备
US7698529B2 (en) Method for trading resources between partitions of a data processing system
US20090055835A1 (en) System and Method for Managing License Capacity in a Telecommunication Network
WO2011142031A1 (ja) リソース管理方法、リソース管理装置およびプログラム
JP2004021982A (ja) コンピュータ・システム・リソースを動的に割り当てる方法およびシステム
KR101696698B1 (ko) 상호 의존 관계가 있는 컴포넌트 분배 및 관리 방법
CN110750336B (zh) 一种OpenStack虚拟机内存热扩容方法
CN114780225B (zh) 一种分布式模型训练***、方法及装置
CN107343023B (zh) 一种Mesos管理集群中的资源分配方法、装置及电子设备
CN109587220B (zh) 负载均衡方法、装置、计算机设备和存储介质
WO2019170011A1 (zh) 任务分配方法及装置、分布式存储***
CN111045819A (zh) 分布式***的资源请求方法、装置、设备和存储介质
CN104158841A (zh) 计算资源分配方法
CN113032102A (zh) 资源重调度方法、装置、设备和介质
US9563532B1 (en) Allocation of tasks in large scale computing systems
CN112163734B (zh) 基于云平台整定计算资源动态调度方法及装置
KR101702218B1 (ko) 역경매 방식 자원할당 장치를 포함하는 하이브리드 클라우드 서버 및 그 자원 할당 방법 및 시스템
CN115168017B (zh) 一种任务调度云平台及其任务调度方法
CN111813564B (zh) 集群资源管理方法、装置及容器集群管理***
JP6721106B2 (ja) 第１の制御装置、装置、方法、プログラム、記録媒体、及びシステム
CN111352710A (zh) 进程管理方法及装置、计算设备、存储介质
CN115442369B (zh) 一种服务资源调度的方法、装置、存储介质及电子设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination