HK40042985B - Resource allocation method, device and storage medium - Google Patents

Description

A method, apparatus and storage medium for resource allocation

Background Technology

Currently, to protect shared resources and achieve resource isolation among multiple tenants, resource allocation algorithms are used to reasonably allocate shared resources among multiple tenants. However, there are often sudden surges in requests among multiple tenants. If the resources that a tenant can be allocated are limited, the tasks corresponding to the sudden requests will not be completed in a timely manner, affecting the user experience. If the resources that a tenant can be allocated are limited, the total amount of resources required by multiple tenants at the same time will exceed the shared resources, which can easily trigger a cascading failure of shared resources.

Therefore, existing technologies propose using the token bucket algorithm for shared resource allocation to reasonably distribute resources to each tenant and solve the problems arising from resource allocation in response to sudden resource shortages.

When using the token bucket algorithm for resource allocation, the amount of resources allocated to handle tasks corresponding to sudden requests depends on the capacity of the token bucket. When a sudden request occurs, processing the tasks corresponding to the sudden request can consume all the resources in the token bucket. Unprocessed tasks corresponding to sudden requests need to be processed gradually, limited by the rate at which the token bucket produces resources. When there are a large number of sudden requests, the processing delay is relatively long.

Therefore, increasing the token bucket capacity can reduce processing latency, but it consumes too many resources instantly, exceeding the total resource capacity and causing a resource avalanche effect.

Summary of the Invention

This application provides a method, apparatus, and storage medium for resource allocation, which dynamically allocates shared resources, avoids the avalanche effect of shared resources, and reduces processing latency.

In a first aspect, embodiments of this application provide a method for resource allocation, the method comprising:

In the first token bucket corresponding to the resource type, the newly generated resources are saved according to the preset inflow rate;

When the number of remaining resources in the second token bucket corresponding to the resource type does not reach the preset second upper limit, the resources already saved in the first token bucket are transferred to the corresponding second token bucket according to the first outflow rate, and the first outflow rate is not less than the inflow rate.

The resources stored in the second token bucket are used to allocate the received data processing resources, and the target resources required by the data processing request conform to the resource type.

Secondly, embodiments of this application provide a resource allocation apparatus, the apparatus comprising:

The storage module is used to store the latest generated resources in the first token bucket corresponding to the resource type according to a preset inflow rate;

The transfer module is used to transfer the resources already saved in the first token bucket to the corresponding second token bucket according to the first outflow rate when the number of remaining resources in the second token bucket corresponding to the determined resource type has not reached the preset second upper limit value. The first outflow rate is not less than the inflow rate.

The resources stored in the second token bucket are used to allocate to received data processing requests, and the target resources required by the data processing requests conform to the resource type.

In one possible implementation, the transfer module is further configured to: after saving the newly generated resources in the first token bucket corresponding to the resource type at a preset inflow rate, when it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has reached a preset second upper limit, transfer the resources already saved in the first token bucket to the corresponding second token bucket at a second outflow rate, wherein the second outflow rate is less than the inflow rate.

In one possible implementation, the transfer module is further configured to: after determining that the number of remaining resources in the second token bucket corresponding to the resource type has not reached the preset second upper limit value, and before transferring the resources already saved in the first token bucket to the corresponding second token bucket according to the first outflow rate, select an outflow rate not less than the inflow rate from the preset first outflow rate range as the first outflow rate based on the inflow rate.

In one possible implementation, the transfer module is further configured to: after determining that the number of remaining resources in the second token bucket corresponding to the resource type has reached a preset second upper limit, and before transferring the resources already saved in the first token bucket to the corresponding second token bucket according to the second outflow rate, select an outflow rate less than the inflow rate from the preset second outflow rate range based on the inflow rate as the second outflow rate.

In one possible implementation, the first outflow rate interval and the second outflow rate interval are the same interval, or they are different intervals.

The first outflow rate range and the second outflow rate range are pre-configured by the flow control system.

In one possible implementation, the transfer module is specifically used for:

If the number of remaining resources in the second token bucket does not reach the preset second upper limit, and the number of remaining resources in the first token bucket is not zero, then the resources already saved in the first token bucket are transferred to the corresponding second token bucket in the manner that the first outflow rate is greater than the inflow rate.

If the number of remaining resources in the second token bucket does not reach the preset second upper limit, and the number of remaining resources in the first token bucket is zero, then the resources already saved in the first token bucket are transferred to the corresponding second token bucket in accordance with the first outflow rate being equal to the inflow rate.

In one possible implementation, the transfer module is also used for:

After transferring the resources already saved in the first token bucket to the corresponding second token bucket, when a data processing request is received from the client, the number of remaining resources in the second token bucket associated with the target resource is determined based on the resource type of the target resource required by the data processing request.

If it is determined that the number of remaining resources in the second token bucket is not less than the target number of resources required to send the data processing request, then a batch of resources that meet the target number of resources are obtained from the remaining resources in the second token bucket.

Allocate a batch of resources to the data processing request and send the data processing request.

Thirdly, embodiments of this application provide a resource allocation device, including: a memory and a processor, wherein the memory is used to store computer instructions; and the processor is used to execute the computer instructions to implement the resource allocation method provided in embodiments of this application.

Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which, when executed by a processor, implement the resource allocation method provided in embodiments of this application.

The beneficial effects of this application are as follows:

This application provides a method, apparatus, and storage medium for resource allocation. For each resource type, a corresponding first token bucket and second token bucket are set up. For each resource type, the following steps are performed: resources are saved in the first token bucket according to a preset inflow rate; and the rate at which the resources saved in the first token bucket are transferred to the corresponding second token bucket is determined based on the number of remaining resources in the second token bucket. When it is determined that the number of remaining resources in the second token bucket has not reached a preset second upper limit, the resources saved in the first token bucket are transferred to the corresponding second token bucket at a first outflow rate not less than the inflow rate. The resources saved in the second token bucket are used to allocate to received data processing requests, where the target resources required by the data processing requests conform to the resource type. Therefore, when a data processing request is received, the target resources required for the data processing request are determined, and the associated second token bucket is determined based on the target resources. The resources in the second token bucket are consumed to send the data processing request. When a small number of sudden data processing requests are received, all resources in the second token bucket can be consumed to send the data processing request in a timely manner. When a large number of sudden data processing requests are received, all resources in the second token bucket can be consumed first to send part of the data processing request in a timely manner. Then, resources are forwarded to the second token bucket in a timely manner at a first outflow rate not less than the inflow rate to continue sending the remaining data processing requests. This supports processing sudden data processing requests at a first outflow rate not less than the inflow rate, reducing processing latency, balancing the allocation of shared resources, and avoiding the avalanche effect of shared resources.

Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings.

Attached Figure Description

To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

Figure 1 is a schematic diagram of resource allocation in related technologies;

Figure 2 is a schematic diagram of an application scenario provided by an embodiment of this application;

Figure 3 is a schematic diagram of setting a first token bucket and a second token bucket for a resource type according to an embodiment of this application;

Figure 4 is a flowchart of a resource allocation method provided in an embodiment of this application;

Figure 5 is a schematic diagram of a storage system provided in an embodiment of this application;

Figure 6 is a delay curve of sending a data processing request according to an embodiment of this application;

Figure 7 is a structural diagram of a resource allocation device provided in an embodiment of this application;

Figure 8 is a structural diagram of a computing device provided in an embodiment of this application.

Detailed Implementation

To make the objectives, technical solutions, and beneficial effects of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

1. The terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

2. In simple terms, multi-tenancy means that a single instance can serve multiple organizations. Multi-tenancy technology addresses how to provide the same or even customizable services to most clients within a shared data center using a single system architecture and services, while still ensuring data isolation for customers.

Multi-tenancy technology is a software architecture technique that explores and implements how to share the same system or program components in a multi-user environment while still ensuring data isolation between users. A tenant is a user who uses system or computer computing resources.

3. The token bucket algorithm is one of the most commonly used algorithms in network traffic shaping and rate limiting. Typically, the token bucket algorithm is used to control the amount of data sent over the network and allows for bursty requests.

The token bucket algorithm continuously generates resources at a constant rate. If resources are not consumed, or if the rate of resource consumption is less than the rate of resource generation, the resources in the token bucket will continuously increase, accumulating until the number of resources in the token bucket reaches its upper limit. When the number of resources in the token bucket reaches its upper limit, newly generated resources will overflow from the token bucket, and the resources in the token bucket will be discarded.

4. Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to realize the computing, storage, processing, and sharing of data.

Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

The design concept of the embodiments of this application will be briefly introduced below.

This application addresses resource allocation in multi-tenant shared resource scenarios. Currently, in multi-tenant shared resource scenarios, resource allocation algorithms are typically used to allocate resources among tenants to ensure shared resources and achieve resource isolation between tenants. However, tenants often experience sudden surges in requests. If the resources allocated to a tenant are limited too much, these sudden requests cannot be processed in a timely manner; if the resources allocated to a tenant are limited too much, the total amount of resources needed by multiple tenants simultaneously will exceed the total amount of shared resources, triggering a cascading effect of shared resources, such as network congestion.

To address the issue of resource allocation algorithms failing to allocate resources reasonably to each tenant, related technologies have proposed using a token bucket algorithm for resource allocation. While this algorithm supports a certain degree of burst requests, the number of burst requests it can handle depends on the token bucket's capacity. When a burst request occurs, processing it instantly consumes all remaining resources in the token bucket, but unprocessed burst requests may still exist. These unprocessed burst requests need to be processed incrementally, limited by the resource production rate.

Therefore, when a large number of sudden requests occur, the token bucket has a limited capacity. Even if all the remaining resources in the token bucket are consumed, it is still not enough to process all the sudden requests. The remaining unprocessed sudden requests need to be processed according to the production rate of the resources corresponding to the token bucket, resulting in excessively high processing latency.

Figure 1 illustrates an exemplary resource allocation method in the related art. The token bucket algorithm generates resources at a constant production rate and puts the generated resources into the token bucket. The token bucket has a fixed capacity. When the number of resources in the token bucket exceeds the capacity of the token bucket, the newly added resources will overflow from the token bucket, that is, the newly added resources will be discarded. When a tenant needs to use resources, it will obtain resources from the token bucket.

Therefore, increasing the token bucket capacity can solve the problem of high processing latency caused by a large number of sudden requests. However, increasing the token bucket capacity can consume too many resources at once, potentially exceeding the total resource capacity and causing a cascading failure of shared resources.

In view of this, embodiments of this application provide a resource allocation method that supports burst requests. This resource allocation method is based on setting two token buckets for each resource type, namely a first token bucket and a second token bucket, and dynamically allocating resources through the token bucket algorithm to avoid the avalanche effect of sharing and reduce processing latency.

In this application, data processing requests are sent by consuming resources in the second token bucket. Therefore, for a small number of burst requests, the remaining resources in the second token bucket are consumed to process them in a timely manner. For a large number of burst requests, the resources stored in the first token bucket are transferred to the second token bucket at an outflow rate that is not less than the inflow rate of resources into the first token bucket. A gradient control strategy that decreases over time is also supported.

The remaining resources in the second token bucket are consumed instantly in the first time period to process the sudden requests, that is, to process the sudden requests at the maximum rate in the first time period.

During the second time period, resources are acquired from the first token bucket at an outflow rate greater than the inflow rate corresponding to the resources flowing into the first token bucket. Sudden requests are processed by consuming the acquired resources. Therefore, the rate of processing sudden requests during the second time period is proportional to the outflow rate greater than the inflow rate, that is, the time for processing sudden requests is proportional to the outflow rate greater than the inflow rate.

During the third time period, resources are acquired from the first token bucket at an outflow rate equal to the inflow rate of the resources flowing into the first token bucket. Sudden requests are processed by consuming the acquired resources. Therefore, the rate at which sudden requests are processed during the third time period is proportional to the outflow rate equal to the inflow rate. In other words, the time for processing sudden requests is proportional to the outflow rate equal to the inflow rate.

Therefore, this application does not allocate the resources required to process a large number of sudden requests all at once. Instead, it transfers the resources in the first token bucket to the second token bucket according to a gradient outflow rate. This can better balance the allocation of shared resources and avoid avalanche response of shared resources. In the case of a large number of sudden requests, after consuming the resources in the second token bucket to process some of the sudden requests in time, the remaining unprocessed sudden requests are processed at a production rate greater than that of the resources corresponding to the first token bucket. As the resource production rate increases, the waiting time of sudden requests decreases, thereby reducing processing latency.

After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

Figure 2 provides an exemplary application scenario diagram of an embodiment of this application, which includes a terminal device 20 and a server 21.

The terminal device 20 has various clients installed and running. Each client can receive data processing requests triggered by the user. The terminal device 20 is an electronic device used by the user. This electronic device can be a personal computer, mobile phone, tablet computer, laptop computer, e-book reader, or other computer device with certain computing capabilities and running instant messaging software and websites or social networking software and websites.

Server 21 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms.

In one alternative implementation, the terminal device 20 and the server 21 can communicate via a communication network. The communication network can be a wired network or a wireless network. The terminal device 20 and the server 21 can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this.

In one possible implementation, a data processing request triggered by a user for a client is received. When the data processing request is sent, the necessary resources are allocated to the data processing request so that the data processing request can be successfully sent to the server.

In one possible implementation, this application employs cloud computing to provide services to terminal device 20. Cloud computing is a computing model that distributes computing requests across a resource pool composed of a large number of computers, where each computer can act as a server, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go.

Data on servers is stored using cloud storage. Cloud storage is a new concept that extends and develops from cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to aggregate a large number of storage devices (also called storage nodes) of various types in a network to work together through application software or application interfaces to provide data storage and business access functions.

Currently, the storage method in storage systems is as follows: Logical volumes are created, and during creation, physical storage space is allocated to each logical volume. This physical storage space may consist of a single storage device or the disks of several storage devices. Clients store data on a logical volume, which means storing the data on the file system. The file system divides the data into many parts, each part being an object. Each object contains not only the data but also additional information such as a data identifier (ID). The file system writes each object to the physical storage space of that logical volume, and it records the storage location information of each object. Therefore, when a client requests access to data, the file system can allow the client to access the data based on the storage location information of each object.

The process by which a storage system allocates physical storage space to a logical volume is as follows: the physical storage space is pre-divided into strips according to the capacity estimate of the objects stored in the logical volume (this estimate often has a large margin relative to the actual capacity of the objects to be stored) and the grouping of Redundant Array of Independent Disks (RAID). A logical volume can be understood as a strip, thus allocating physical storage space to the logical volume.

Based on the application scenario in Figure 2, the resource allocation method involved in the embodiments of this application will be illustrated below.

In this embodiment of the application, in order to ensure resource isolation among multiple tenants, a corresponding first token bucket and a second token bucket are set for each resource type corresponding to each tenant. As shown in Figure 3, Figure 3 provides an exemplary schematic diagram of setting a first token bucket and a second token bucket for any resource type in this embodiment of the application.

The resources stored in the first token bucket and the second token bucket are the same.

It should be noted that the resource types include, but are not limited to, at least one of the resource types corresponding to bandwidth resources and the resource types corresponding to input/output operations per second (IOPS) resources; the resources in this application include, but are not limited to, at least one of storage resources and network resources.

In one possible implementation, after setting up corresponding first and second token buckets for each resource type, resources need to be allocated to the first and second token buckets to consume resources to send data processing requests.

Below, we will use a resource type as an example to illustrate this.

Please refer to Figure 4, which exemplarily illustrates a method for resource allocation based on resource type according to an embodiment of this application. This method is applicable to various scenarios requiring shared resource allocation and includes the following steps:

Step S400: In the first token bucket corresponding to the resource type, the newly generated resource is saved according to the preset inflow rate.

Referring to Figure 3, suppose a first token bucket and a second token bucket are set up for bandwidth resources, and bandwidth resources are continuously generated at an inflow rate of Rtoken/s and flow into the first token bucket corresponding to the bandwidth resources, where R is a positive integer.

The inflow rate is the production rate of production resources, which is determined by the flow control system by limiting storage performance parameters; storage performance parameters include, but are not limited to, at least one of bandwidth, IOPS, and throughput.

It should be noted that resources in the token bucket can also be referred to as resources.

Step S401: When it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has not reached the preset second upper limit value, the resources already saved in the first token bucket are transferred to the corresponding second token bucket according to the first outflow rate, and the first outflow rate is not less than the inflow rate.

Referring to Figure 3, according to the outflow rate of B tokens/s, the bandwidth resources stored in the first token bucket are transferred to the corresponding second token bucket. That is, the outflow rate is the rate at which resources flow out of the first token bucket. In this application, the outflow rate is used as the rate at which resources flow into the second token bucket, and the capacity of the second token bucket is smaller than the capacity of the first token bucket.

Since the resources in the second resource are consumed when sending data processing requests, the number of remaining resources in the second token bucket will always be less than the preset second upper limit value. In order to reduce the latency of data processing requests, it is necessary to ensure that the rate of resources flowing into the second token bucket is greater than or equal to the rate of resources flowing into the first token bucket, that is, it is necessary to ensure that the outflow rate of the first token bucket is greater than or equal to the inflow rate of the first token bucket.

In one possible implementation, when the outflow rate of resources from the first token bucket is not less than the inflow rate of resources into the first token bucket, when the rate of resource consumption is less than the inflow rate of resources into the first token bucket, the rate of resource consumption is also less than the outflow rate of resources from the first token bucket. At this time, the outflow rate is greater than the inflow rate, which is greater than the consumption rate of resources. This reduces the amount of resources consumed in the second token bucket. Therefore, if the first outflow rate, which is not less than the inflow rate, continues to transfer resources from the first token bucket to the second token bucket, the resources in the second token bucket will reach their upper limit after a certain period of time. Resources that continue to be transferred to the second token bucket will overflow from the second token bucket, which means that resources that continue to be transferred to the second token bucket will be discarded. At this time, the first token bucket will not reach the preset first upper limit value, ultimately resulting in resource waste.

Therefore, when resources in the first token bucket are transferred to the second token bucket, if the number of remaining resources in the second token bucket corresponding to the resource type has reached the preset second upper limit, in order to avoid resource waste, the resources already saved in the first token bucket are transferred to the corresponding second token bucket according to the second outflow rate, and the second outflow rate is less than the inflow rate.

Therefore, in this embodiment, the rate at which resources flow out of the first token bucket is related to the number of remaining resources in the second token bucket, including the following situations:

Scenario 1: When the number of remaining resources in the second token bucket has not reached the preset second upper limit.

Since sending a data processing request consumes resources in the second token bucket, after determining that the number of remaining resources in the second token bucket corresponding to the resource type has not reached the preset second upper limit, in order to reduce the time for processing data processing requests, it is necessary to ensure that the resources in the first token bucket are transferred to the second token bucket at a relatively high rate, that is, to ensure that the outflow rate of resources from the first token bucket is greater than or equal to the inflow rate of resources into the first token bucket.

In other words, a higher resource acquisition rate reduces the time required to acquire the total amount of resources needed to send a data processing request, thus reducing the time consumed in sending the data processing request.

Since the inflow rate is set by the flow control system based on storage performance parameters and is fixed, it is necessary to determine an outflow rate that is not less than the inflow rate.

At this point, based on the inflow rate, an outflow rate not less than the inflow rate is selected from the preset first outflow rate range as the first outflow rate; and according to the first outflow rate, the resources already stored in the first token bucket are transferred to the corresponding second token bucket.

The first outflow rate range is preset by the flow control system. The upper limit of the first outflow rate range is greater than the rate value corresponding to the inflow rate of resources into the first token bucket. Therefore, any outflow rate greater than or equal to the rate value corresponding to the inflow rate is selected as the first outflow rate in the first outflow rate range.

It should be noted that the lower limit of the first outflow rate interval in this application can be 0, a positive integer less than the rate value corresponding to the inflow rate, or the rate value corresponding to the inflow rate.

In this embodiment of the application, the first outflow rate is related to the number of remaining resources in the first token bucket.

When the number of remaining resources in the first token bucket is not zero:

Since the number of remaining resources in the first token bucket is not zero, in order to speed up the processing of data processing requests, the rate at which resources in the first token bucket are transferred to the second token bucket should be increased. That is, the resources already saved in the first token bucket should be transferred to the corresponding second token bucket in a manner where the first outflow rate is greater than the inflow rate.

In other words, when there are resources remaining in the first token bucket, while adding new resources to the first token bucket, the resources in the first token bucket are transferred to the second token bucket. At this time, not only can all the newly added resources be transferred to the second token bucket, but the remaining resources in the token bucket can also be added, that is, the first outflow rate is greater than the inflow rate.

To process data processing requests more quickly, preferably, the outflow rate corresponding to the upper limit of the first outflow rate range is used as the first outflow rate.

When the number of remaining resources in the first token bucket is zero:

According to the principle that the first outflow rate equals the inflow rate, the resources already stored in the first token bucket are transferred to the corresponding second token bucket;

Since the remaining resources in the first token bucket are zero, in order to speed up the processing of data processing requests, the fastest way to transfer the resources in the first token bucket to the second token bucket is to transfer the newly added resources to the second token bucket as much as the first token bucket is added. In other words, the first outflow rate is equal to the inflow rate.

For example:

Let the inflow rate into the first token bucket be 5 resources/second, the remaining number of resources in the first token bucket be at the preset first upper limit value of 100 resources, the first outflow rate range be [0, 10], and the remaining number of resources in the second token bucket be at the preset second upper limit value of 50 resources.

When a large number of data processing requests need to be sent, assuming the total resources required to send these requests are 260, the first step is to consume 50 resources from the second token bucket to process some of the requests. Then, the highest outflow rate of 10 resources/second is selected from the first outflow rate range as the first outflow rate to transfer 100 resources from the first token bucket to the second token bucket. Simultaneously, the first token bucket generates tokens at an inflow rate of 5 resources/second. Therefore, the time to transfer resources from the first token bucket to the second token bucket at 10 resources/second is 19 seconds. At this point, the remaining resources in the first token bucket are 0, and a total of 190 resources are transferred to the second token bucket at 10 resources/second. Sending the data processing requests has consumed a total of 240 resources. Not all data processing requests are sent at this point. The remaining 20 resources will be used to transfer the newly generated resources from the first token bucket to the second token bucket at an inflow rate of 5 resources/second.

Scenario 2: When the number of remaining resources in the second token bucket has reached the preset second upper limit.

In this embodiment of the application, when the outflow rate of resources leaving the first token bucket is not less than the inflow rate of resources into the first token bucket, and the consumption rate of resources in the second token bucket is less than the inflow rate of resources into the first token bucket:

Since the inflow rate of resources into the second token bucket is equal to the outflow rate of resources out of the first token bucket, and the outflow rate of resources out of the first token bucket is not less than the inflow rate of resources into the first token bucket, the inflow rate into the second token bucket is greater than the outflow rate out of the second token bucket. Under this situation, after a certain period of time, the resources in the second token bucket will reach the preset second upper limit value.

Due to the characteristics of the token bucket algorithm, when the number of remaining resources in the second token bucket reaches the preset second upper limit, if the outflow rate of resources from the first token bucket is not less than the inflow rate of resources into the first token bucket, the resources that continue to be transferred from the first token bucket will overflow from the second token bucket and will no longer be able to be stored in the second token bucket. Instead, the resources that will continue to be stored will be discarded, resulting in the waste of newly added resources in the second token bucket, and the resources in the first token bucket will not reach the preset first upper limit.

In order to ensure that resources are not wasted and to send data processing requests in a timely manner when the consumption rate of resources suddenly increases, thereby reducing processing latency, in this embodiment of the application, after the number of remaining resources in the second token bucket has reached a preset second upper limit, the resources in the first token bucket are accumulated. At this time, the second outflow rate of resources flowing out of the first token bucket can be controlled to be less than the inflow rate of resources flowing into the first token bucket. Since the outflow rate is less than the inflow rate, after a certain period of time, the number of remaining resources in the first token bucket can also reach a preset first upper limit.

Therefore, when the consumption rate in the second token bucket is less than the inflow rate of resources into the first token bucket, after determining that the number of remaining resources in the second token bucket corresponding to the resource type has reached the preset second upper limit, based on the inflow rate, an outflow rate less than the inflow rate is selected from the preset second outflow rate range as the second outflow rate, and the resources already stored in the first token bucket are transferred to the corresponding second token bucket according to the second outflow rate.

The second outflow rate range is preset by the flow control system. The lower limit of the second outflow rate range is less than the rate value corresponding to the inflow rate of resources into the first token bucket. Therefore, any outflow rate less than the rate value corresponding to the inflow rate is selected as the second outflow rate in the second outflow rate range.

It should be noted that, in order to speed up the time when the number of remaining resources in the first token bucket reaches the preset first upper limit, when the number of remaining resources in the second token bucket reaches the preset second upper limit, it is preferable to control the second outflow rate to 0, that is, not to forward resources to the second token bucket.

The following example illustrates the situation where the remaining resources in the second token bucket have not reached the preset second upper limit:

Assume that after a large number of data processing requests have been sent, no further data processing requests arrive. At this point, no resources in the second token bucket need to be consumed, so the resource consumption rate is 0 resources/second. The remaining resources in both the first and second token buckets are 0. Resources are generated and stored in the first token bucket at an inflow rate of 5 resources/second. Since resources in the second token bucket are consumed when sending data processing requests, it is necessary to ensure that there are remaining resources in the second token bucket. Therefore, the latest generated resources in the first token bucket are transferred to the second token bucket at a first outflow rate of 5 resources/second. After 10 seconds, when the remaining resources in the second token bucket reach the preset second upper limit of 50 resources, any further resources transferred to the second token bucket will be discarded, and the remaining resources in the first token bucket will be 0.

As can be seen from the example of the number of remaining resources in the second token bucket not reaching the preset second upper limit, the latency of processing data processing requests is smaller when there are remaining resources in the first token bucket compared to the latency when there are no remaining resources in the first token bucket. Therefore, in order to speed up the processing and avoid resource waste, the resources in the first token bucket will be accumulated. To ensure that there are remaining resources in the first token bucket, the inflow rate needs to be greater than the second outflow rate. In order to make the number of remaining resources in the first token bucket reach the preset first upper limit more quickly, the preferred second outflow rate is 0 resources/second, that is, no resources flow out of the first token bucket.

It should be noted that the preset second upper limit value corresponding to the first token bucket, the preset second upper limit value corresponding to the second token bucket, the first outflow rate range, and the second outflow rate range are all set by the flow control system, and the first outflow rate range and the second outflow rate range are either the same range or different ranges.

In one possible implementation, the preset second upper limit value corresponding to the first token bucket, the preset second upper limit value corresponding to the second token bucket, the inflow rate, the first outflow rate range, and the second outflow rate range are set by the storage system through the flow control system.

The following example uses a cloud block storage (CBS) system as an example. Figure 5 provides a schematic diagram of a CBS storage system in an embodiment of this application.

As shown in Figure 5, CBS cloud disks are a widely used distributed storage system in the cloud. A single storage cluster has more than 10,000 cloud disks, and the resources in the cloud disks are allocated by the storage nodes. The cloud storage system limits the performance parameters of each cloud disk, such as bandwidth, IOPS, and throughput, through a flow control system. Therefore, the flow control system indirectly limits the inflow rate, the first outflow rate range, and the second outflow rate range. The flow control system also limits the first upper limit value corresponding to the first token bucket and the second upper limit value corresponding to the second token bucket.

In this embodiment of the application, after the resources already stored in the first token bucket are transferred to the corresponding second token bucket, the resources stored in the second token bucket are used when sending data processing requests.

Therefore, when a data processing request is received from a client, the target resource required to send the data processing request is determined based on the data processing request, the resource type of the target resource is determined, and the number of remaining resources in the second token bucket associated with the target resource required for the data processing request is further determined.

After determining the number of remaining resources in the second token bucket, the number of remaining resources in the second token bucket is compared with the target number of resources required to send the data processing request. It is then determined whether the number of remaining resources in the second token bucket is not less than the target number of resources required to send the data processing request, that is, whether the number of remaining resources in the second token bucket satisfies the requirement to send the data processing request.

Ensure that the number of remaining resources in the second token bucket is not less than the target number of resources required for sending data processing resources:

After determining that the number of remaining resources in the second token bucket is not less than the target number of resources required to send the data processing resources, a batch of resources that meet the target number will be obtained from the remaining resources in the second token bucket, and the batch of resources will be allocated to the data processing resources so as to send the data processing resources by consuming the batch of resources.

For example, if 100M of bandwidth is required to send a data processing request, and the remaining bandwidth in the second token bucket is 200M, then 100M of bandwidth will be allocated from the second token bucket to the data processing request in order to send the data processing request.

It is determined that the number of remaining resources in the second token bucket is less than the target number of resources required for sending data processing resources:

Once it is determined that the number of remaining resources in the second token bucket is less than the target number of resources required to send the data processing resource, consuming all the remaining resources in the second token bucket will not be able to send the data processing request. Therefore, it is necessary to wait until the number of remaining resources in the second token bucket is not less than the target number of resources required to send the data processing resource, and then obtain a batch of resources that meet the target number from the remaining resources in the second token bucket, and allocate the batch of resources to the data processing resource so as to send the data processing resource by consuming the batch of resources.

For example, if a data processing request requires 100M bandwidth, and the remaining bandwidth in the second token bucket is 50M, then 50M bandwidth needs to be transferred from the first token bucket to the second token bucket. If the remaining resources in the second token bucket are not less than 100M bandwidth, then 100M bandwidth will be obtained from the second token bucket and allocated to the data processing request to send the data processing request.

In this embodiment of the application, the time for processing a data processing request, i.e., the time for waiting for the number of remaining resources in the second token bucket to be no less than the target number of resources required to send the data processing request, is determined by the number of remaining resources in the first token bucket and the number of remaining resources in the second token bucket.

When a large number of data processing requests are received, when processing each received data processing request, for any data processing request, the target number of resources required by the data processing request is compared with the number of remaining resources in the second token bucket, and the data processing request is sent according to the comparison result.

When the number of remaining resources in the second token bucket is not less than the target number of resources required to send data processing resources, a batch of resources of the target number of resources can be directly obtained from the second token bucket, allocated to the data processing request, and the data processing resources can be sent.

When the number of remaining resources in the second token bucket is less than the target number of resources required to send data processing resources, and the number of remaining resources stored in the first token bucket is not zero, the resources stored in the first token bucket are transferred to the second token bucket at a first outflow rate greater than the inflow rate. This continues until the number of remaining resources in the second token bucket is not less than the number of resources required for the data processing request. Then, a batch of resources that meet the target number of resources is obtained, allocated to the data processing request, and the data processing resources are sent.

Based on the rate at which resources are acquired from the first token bucket, the waiting time for sending data processing requests can be determined, thus determining the rate and duration of sending data processing requests.

When the number of remaining resources in the second token bucket is less than the target number of resources required to send data processing resources, and the number of remaining resources stored in the first token bucket is zero, the resources stored in the first token bucket are transferred to the second token bucket at a first outflow rate equal to the inflow rate. This continues until the number of remaining resources in the second token bucket is not less than the number of resources required for the data processing request. Then, a batch of resources that meet the target number of resources is obtained, allocated to the data processing request, and the data processing resources are sent.

Based on the rate at which resources are acquired from the first token bucket, the waiting time for sending data processing requests can be determined, thus determining the rate and duration of sending data processing requests.

As shown in Figure 6, Figure 6 provides an exemplary delay curve for sending a large amount of data processing resources according to an embodiment of this application.

To understand Figure 6 in an extreme way, it can be interpreted as follows:

The remaining resources in both the first and second token buckets have reached their limits. When a large number of data processing requests are received, all the remaining resources in the second token bucket are consumed first, and the first part of the data processing request is sent. That is, the first part of the data processing request is sent immediately. Therefore, the latency of sending the first part of the data processing request is the shortest, and the rate P token/s is the maximum.

After sending the first part of the data processing request, if there are still unsent data processing requests among the received requests, since the remaining resources in the first token bucket are not zero, the resources in the first token bucket are transferred to the second token bucket at a first outflow rate greater than the inflow rate. The resources transferred to the second token bucket are used to send the second part of the data processing request. Therefore, sending the second part of the data processing request requires waiting for the resources to meet the requirements for sending the data processing request, which requires waiting time. Thus, the latency Yms for sending the second part of the data processing request is higher than the latency Xms for sending the first part of the data processing request, resulting in increased processing latency. The rate Q token/s for sending the second part of the data processing request is lower than that for the first part of the data processing request.

It should be noted that the rate at which the second part of the data processing request is sent, Q token/s, is the inflow rate of the second token bucket. The inflow rate of the second token bucket is greater than the inflow rate of the first token bucket. In this case, Q token/s is greater than B token/s.

After sending the second part of the data processing request, if there are still unsent data processing requests among the received data processing requests, since the remaining resources in the first token bucket are zero, the resources in the first token bucket are transferred to the second token bucket at a first outflow rate equal to the inflow rate. The resources transferred to the second token bucket are used to send the third part of the data processing request. Because the rate of forwarding resources is reduced, the latency Zms for sending the third part of the data processing request is increased compared to the latency Yms for sending the second part of the data processing request, resulting in an increased processing latency. The rate N tokens/s for sending the third part of the data processing request is reduced compared to the second part of the data processing request.

It should be noted that the rate at which the third part of the data processing request is sent, N tokens/s, is the inflow rate of the second token bucket. The inflow rate of the second token bucket is equal to the inflow rate of the first token bucket. At this time, N tokens/s is equal to B tokens/s.

In this embodiment of the application, if a new data processing request is received before the third part of the data processing request has been sent, the latency of processing the data processing request at a rate of N tokens/s will continue to increase.

It should be noted that the sum of the first part of the data processing requests, the second part of the data processing requests, and the third part of the data processing requests constitutes the large number of data processing requests received.

In this application, when data processing resources are received, the resources in the second token bucket are consumed to send the data processing resources. When a small burst of data processing resources is received, all resources in the second token bucket can be consumed to send the data processing resources in a timely manner. When a large burst of data processing resources is received, all resources in the second token bucket can be consumed first to send the data processing resources in a timely manner. At the same time, resources are forwarded to the second token bucket in a timely manner at a first outflow rate not less than the inflow rate. This supports processing bursts of data processing resources at a first outflow rate not less than the inflow rate, reducing processing latency and better balancing the allocation of shared resources, avoiding the avalanche effect of shared resources.

Based on the same inventive concept, this application also provides a resource allocation device 700, as shown in FIG7. The device 700 includes: a storage module 701 and a transfer module 702; wherein:

The storage module 701 is used to store the latest generated resources in the first token bucket corresponding to the resource type according to a preset inflow rate;

The transfer module 702 is used to transfer the resources already saved in the first token bucket to the corresponding second token bucket according to the first outflow rate when the number of remaining resources in the second token bucket corresponding to the determined resource type has not reached the preset second upper limit value. The first outflow rate is not less than the inflow rate.

The resources stored in the second token bucket are used to allocate to received data processing requests. The resource type of the target resource required by the data processing request includes the resource type.

In one possible implementation, the transfer module 702 is also used for:

After the newly generated resources are saved in the first token bucket corresponding to the resource type according to the preset inflow rate, when it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has reached the preset second upper limit, the resources saved in the first token bucket are transferred to the corresponding second token bucket according to the second outflow rate, where the second outflow rate is less than the inflow rate.

In one possible implementation, the transfer module 702 is also used for:

After determining that the number of remaining resources in the second token bucket corresponding to the resource type has not reached the preset second upper limit, before transferring the resources already saved in the first token bucket to the corresponding second token bucket according to the first outflow rate, an outflow rate not less than the inflow rate is selected from the preset first outflow rate range based on the inflow rate as the first outflow rate.

In one possible implementation, the transfer module 702 is also used for:

After determining that the number of remaining resources in the second token bucket corresponding to the resource type has reached the preset second upper limit, before transferring the resources saved in the first token bucket to the corresponding second token bucket according to the second outflow rate, based on the inflow rate, an outflow rate less than the inflow rate is selected from the preset second outflow rate range as the second outflow rate.

In one possible implementation, the first outflow rate interval and the second outflow rate interval are the same interval, or they are different intervals.

The first outflow rate range and the second outflow rate range are pre-configured by the flow control system.

In one possible implementation, the transfer module 702 is specifically used for:

If the number of remaining resources in the second token bucket does not reach the preset second upper limit, and the number of remaining resources in the first token bucket is not zero, then the resources already saved in the first token bucket are transferred to the corresponding second token bucket in the manner that the first outflow rate is greater than the inflow rate.

If the number of remaining resources in the second token bucket does not reach the preset second upper limit, and the number of remaining resources in the first token bucket is zero, then the resources already saved in the first token bucket are transferred to the corresponding second token bucket in accordance with the first outflow rate being equal to the inflow rate.

In one possible implementation, the transfer module 702 is also used for:

When a data processing request is received from a client, the number of remaining resources in the second token bucket associated with the target resource is determined based on the resource type of the target resource required by the data processing request.

If it is determined that the number of remaining resources in the second token bucket is not less than the target number of resources required to send the data processing request, then a batch of resources that meet the target number of resources are obtained from the remaining resources in the second token bucket.

Allocate a batch of resources to the data processing request and send the data processing request.

For ease of description, the above sections are divided into units (or modules) according to their functions and described separately. Of course, in implementing this application, the functions of each unit (or module) can be implemented in one or more software or hardware components.

After introducing the resource allocation method and apparatus of the exemplary embodiments of this application, the computing device for resource allocation of another exemplary embodiment of this application will be introduced next.

Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

In one possible implementation, the resource allocation computing device provided in this application embodiment may include at least a processor and a memory. The memory stores program code, which, when executed by the processor, causes the processor to perform any step of the resource allocation method in the various exemplary embodiments of this application.

The resource allocation computing device 800 according to this embodiment of the present application will now be described with reference to FIG8. The resource allocation computing device 800 of FIG8 is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present application.

As shown in Figure 8, the components of the computing device 800 may include, but are not limited to: at least one processor 801, at least one memory 802, and a bus 803 connecting different system components (including memory 802 and processor 801).

Bus 803 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or a local bus using any of the various bus structures.

The memory 802 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 8021 and/or cache memory 8022, and may further include read-only memory (ROM) 8023.

The memory 802 may also include a program/utility 8025 having a set (at least one) of program modules 8024, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

The computing device 800 can also communicate with one or more external devices 804 (e.g., keyboard, pointing device, etc.), one or more devices that enable a user to interact with the computing device 800, and/or any device that enables the computing device 800 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via the input/output (I/O) interface 805. Furthermore, the computing device 800 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and/or public networks, such as the Internet) via a network adapter 806. As shown in Figure 8, the network adapter 806 communicates with other modules used in the computing device 800 via a bus 803. It should be understood that, although not shown in Figure 8, other hardware and/or software modules can be used in conjunction with the computing device 800, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

In some possible implementations, various aspects of the resource allocation method provided in this application may also be implemented in the form of a program product, which includes program code that, when the program product is run on a computer device, causes the computer device to perform the steps in the resource allocation method according to the various exemplary embodiments of this application described above.

The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

The SMS sending control program product of the embodiments of this application can be a portable compact disc read-only memory (CD-ROM) and include program code, and can run on a computing device.

A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java and C++, as well as conventional procedural programming languages such as the "C" language or similar programming languages.

It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and/or one step may be broken down into multiple steps.

Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims (8)

1. A method for resource allocation, characterized in that the method includes: In the first token bucket corresponding to the resource type, the newly generated resources are stored according to the preset inflow rate. Each resource type is set with a corresponding first token bucket and a second token bucket, wherein the resources stored in the first token bucket and the second token bucket are the same. When it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has not reached a preset second upper limit, the resources already stored in the first token bucket are transferred to the corresponding second token bucket according to the first outflow rate, wherein the first outflow rate is not less than the inflow rate; wherein, the resources stored in the second token bucket are used to allocate to received data processing requests, and the resource type of the target resource required by the data processing request includes the resource type; so that for a large number of burst requests, the resources stored in the first token bucket are transferred to the second token bucket at an outflow rate not less than the inflow rate of resources flowing into the first token bucket; When it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has reached the preset second upper limit, the resources already stored in the first token bucket are transferred to the corresponding second token bucket according to the second outflow rate, where the second outflow rate is less than the inflow rate; so that small burst requests can be processed in a timely manner by consuming the remaining resources in the second token bucket, forming a gradient control strategy that decreases over time. 2. The method as described in claim 1, characterized in that, after determining that the number of remaining resources in the second token bucket corresponding to the resource type has not reached a preset second upper limit value, and before transferring the resources already stored in the first token bucket to the corresponding second token bucket according to the first outflow rate, the method further includes: Based on the inflow rate, an outflow rate not less than the inflow rate is selected from a preset first outflow rate range as the first outflow rate; After determining that the number of remaining resources in the second token bucket corresponding to the resource type has reached the preset second upper limit, and before transferring the resources already stored in the first token bucket to the corresponding second token bucket according to the second outflow rate, the process further includes: Based on the inflow rate, an outflow rate less than the inflow rate is selected from a preset second outflow rate range as the second outflow rate. 3. The method as described in claim 2, wherein the first outflow rate interval and the second outflow rate interval are the same interval or are different intervals; The first outflow rate range and the second outflow rate range are pre-configured by the flow control system. 4. The method as described in claim 1, characterized in that, when it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has not reached a preset second upper limit, the resources already stored in the first token bucket are transferred to the corresponding second token bucket according to the first outflow rate, specifically including: If the number of remaining resources in the second token bucket does not reach the preset second upper limit value, and the number of remaining resources in the first token bucket is not zero, then the resources already saved in the first token bucket are transferred to the corresponding second token bucket in the manner that the first outflow rate is greater than the inflow rate. If the number of remaining resources in the second token bucket does not reach the preset second upper limit value, and the number of remaining resources in the first token bucket is zero, then the resources already saved in the first token bucket are transferred to the corresponding second token bucket in a manner that the first outflow rate is equal to the inflow rate. 5. The method as described in claim 1, characterized in that, after transferring the resources already stored in the first token bucket to the corresponding second token bucket, it further includes: When a data processing request is received from a client, the number of remaining resources in the second token bucket associated with the target resource is determined based on the resource type of the target resource required by the data processing request. If it is determined that the number of remaining resources in the second token bucket is not less than the target number of resources required to send the data processing request, then a batch of resources that meet the target number of resources are obtained from the remaining resources in the second token bucket. Allocate the batch of resources to the data processing request and send the data processing request. 6. A resource allocation apparatus, characterized in that the apparatus comprises: The storage module is used to store the latest generated resources in the first token bucket corresponding to the resource type according to a preset inflow rate. Each resource type is set with a corresponding first token bucket and a second token bucket, wherein the resources stored in the first token bucket and the second token bucket are the same. The transfer module is used to transfer the resources already stored in the first token bucket to the corresponding second token bucket according to a first outflow rate when it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has not reached a preset second upper limit value. The first outflow rate is not less than the inflow rate. This is to enable the transfer of resources stored in the first token bucket to the second token bucket at an outflow rate not less than the inflow rate of resources flowing into the first token bucket in response to a large number of sudden requests. The resources stored in the second token bucket are used to allocate to received data processing requests, wherein the target resources required by the data processing requests conform to the resource type. The transfer module is also used for: After the newly generated resources are saved in the first token bucket corresponding to the resource type at a preset inflow rate, when it is determined that the number of remaining resources in the second token bucket corresponding to the resource type has reached the preset second upper limit, the resources saved in the first token bucket are transferred to the corresponding second token bucket at a second outflow rate, wherein the second outflow rate is less than the inflow rate; so that small burst requests can be processed in a timely manner by consuming the remaining resources in the second token bucket, forming a gradient control strategy that decreases over time. 7. A resource allocation device, characterized in that the device comprises: a memory and a processor, wherein the memory is used to store computer instructions; and the processor is used to execute the computer instructions to implement the method as described in any one of claims 1-5. 8. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the method as described in any one of claims 1-5.