Speed limiting method and device of cloud storage gateway, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a speed limiting method and device for a cloud storage gateway, electronic equipment and a storage medium, and relates to the technical field of cloud storage, and the method comprises the steps: when the cloud storage gateway obtains a target request, obtaining a corresponding historical request, and based on a response result corresponding to the historical request, determining the speed of the target request; a sending time interval for the target request is determined, if the sending time interval is reached and a global token and a volume-level token are successfully applied for the target request in sequence, the target request is sent to a cloud server, the generation rate of the global token is controlled by a global speed limiting parameter, and the volume-level token corresponds to a storage volume to which the target request belongs; and the generation rate of the volume-level token is controlled by the volume-level speed limiting parameter, so that refined dynamic speed limiting is realized, a single non-key volume is prevented from occupying all resources, intelligent redistribution can be realized when the total resources are surplus, the optimization of the overall throughput of the system is realized, and the adaptability to a complex environment is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud storage, in particular to a rate limiting method of a cloud storage gateway, a rate limiting device of a cloud storage gateway, an electronic device and a computer readable storage medium. BACKGROUND

[0002] With the popularity and development of cloud computing technology, cloud storage has become an indispensable part of modern information technology architecture, providing a flexible and scalable storage solution for massive data. As a bridge connecting the local environment and remote cloud storage services, the core role of the cloud storage gateway is to present cloud storage services to local users and applications in the form of standard protocols (such as NFS, SMB), while optimizing data access performance through caching, prefetching and other technologies.

[0003] In actual application scenarios, cloud storage gateways need to handle high-concurrency and massive data upload and download requests. When the request load (such as the number of requests per second QPS) continues to rise, the hardware resources (such as CPU, memory, network bandwidth) where the gateway is located may face excessive load pressure. In this case, the system service latency will increase significantly, and in severe cases, it may even lead to service resource depletion and system downtime, thereby affecting the continuity and stability of the business. Therefore, from the perspective of resource protection and efficient utilization, it is crucial to limit the rate of requests sent by the cloud storage gateway to the cloud service (i.e., rate limiting). However, in the process of rate limiting the cloud storage gateway, it often relies too much on pre-set fixed rates and cannot be adjusted adaptively, and the fine-grained control ability is poor, making it difficult to cope with complex production environments. SUMMARY

[0004] The embodiments of the present application provide a rate limiting method, device, electronic device and computer readable storage medium of a cloud storage gateway to solve or partially solve the problems that the cloud storage gateway is difficult to adaptively adjust the transmission rate, has poor fine-grained control ability and is difficult to cope with complex environments when dealing with high-concurrency and massive data transmission.

[0005] The embodiments of the present application disclose a rate limiting method of a cloud storage gateway, comprising: obtaining a target request to be sent to a cloud server and historical requests, and determining a sending time interval for the target request based on response results corresponding to the historical requests; if the sending time interval is reached and global tokens and volume-level tokens are successfully applied for for the target request in sequence, the target request is sent to the cloud server, the generation rate of the global tokens is controlled by a global rate limiting parameter, the volume-level tokens correspond to a storage volume to which the target request belongs, and the generation rate of the volume-level tokens is controlled by a volume-level rate limiting parameter; The global speed-limiting parameter and the volume-level speed-limiting parameter are dynamically determined based on a resource pool-based load state indicator and an actual transmission rate of each storage volume.

[0006] In some possible implementation manners, the sending time interval for the target request is determined based on the response result corresponding to the historical request, including: If the response result of the historical request is that the cloud server returns a corresponding success response, the sending time interval for the target request is shortened. If the response result of the historical request is that the cloud server returns a corresponding error response or request timeout, the sending time interval for the target request is lengthened.

[0007] In some possible implementation manners, the sending time interval for the target request is shortened, including: The current transmission rate is obtained. If the current transmission rate is lower than a first preset threshold, the current transmission rate is adjusted to a first transmission rate in a manner of multiplying the transmission rate, to obtain a first time interval for the target request. If the current transmission rate is greater than or equal to the first preset threshold, the current transmission rate is adjusted to a second transmission rate in a manner of incrementing the transmission rate by a fixed value, to obtain a second time interval for the target request. In some possible implementation manners, the sending time interval for the target request is lengthened, including: The current transmission rate is adjusted to a third transmission rate in a manner of halving the transmission rate, to obtain a third time interval for the target request.

[0008] In some possible implementation manners, if the sending time interval is reached and the global token and the volume-level token are successfully applied for the target request in sequence, the target request is sent to the cloud server, including: If the sending time interval is reached, one or more global tokens corresponding to the target request are applied for from a global token bucket. If the global tokens are successfully applied for from the global token bucket, one or more volume-level tokens corresponding to the target request are applied for from a volume-level token bucket corresponding to a storage volume to which the target request belongs. If the volume-level tokens are successfully applied for from the volume-level token bucket, the target request is sent to the cloud server in response to the global tokens and the volume-level tokens being applied for.

[0009] In some possible implementation manners, the method further includes: Adopt the load state index, calculate the global speed limit reference value corresponding to the global token; Constrain the global speed limit reference value between the preset maximum speed limit value and the minimum speed limit value, obtain the global speed limit parameter corresponding to the global token.

[0010] In some possible implementation manners, the load state index at least includes CPU usage and memory usage, and the adopting the load state index, calculating the global speed limit reference value corresponding to the global token, includes: Adopting the CPU usage, a corresponding first speed value is calculated, the first speed value is positively correlated with the CPU usage, and the growth rate thereof slows down with the increase of the CPU usage; Adopting the memory usage, a corresponding second speed value is calculated, the second speed value is positively correlated with the memory usage, and the growth rate thereof slows down with the increase of the memory usage; Taking the smaller one of the first speed value and the second speed value as the global speed limit reference value corresponding to the global token.

[0011] In some possible implementation manners, further comprising: Obtaining a weight coefficient corresponding to each of the storage volumes; According to the weight coefficient and the global speed limit parameter, an initial volume-level speed limit parameter corresponding to each of the storage volumes is allocated; Obtaining an actual total transmission rate corresponding to all the storage volumes at present; If the actual total transmission rate is less than the global speed limit parameter, then according to the priority corresponding to each of the storage volumes, the volume-level speed limit parameter corresponding to one or more of the storage volumes is sequentially increased.

[0012] The embodiment of the application further discloses a speed limiting device of a cloud storage gateway, comprising: A request obtaining module is configured to obtain a target request to be sent to a cloud server and a historical request, and determine a sending time interval for the target request based on a response result corresponding to the historical request; A sending module is configured to send the target request to the cloud server if the sending time interval is reached and global tokens and volume-level tokens are successfully applied for for the target request in sequence, a generation rate of the global tokens is controlled by a global speed limit parameter, the volume-level tokens correspond to storage volumes to which the target request belongs, and a generation rate of the volume-level tokens is controlled by a volume-level speed limit parameter. The global speed limit parameter and the volume-level speed limit parameter are dynamically determined based on a load state index of a resource pool and actual transmission rates of the storage volumes.

[0013] In some possible implementation manners, the request obtaining module is specifically configured to: if the response result of the historical request is that the cloud server returns a corresponding success response, shorten the sending time interval for the target request; if the response result of the historical request is that the cloud server returns a corresponding error response or request timeout, lengthen the sending time interval for the target request.

[0014] In some possible implementation manners, the request obtaining module is specifically configured to: obtain a current transmission rate; if the current transmission rate is lower than a first preset threshold, adjust the current transmission rate to a first transmission rate in a manner of multiplying the transmission rate, to obtain a first time interval for the target request; if the current transmission rate is greater than or equal to the first preset threshold, adjust the current transmission rate to a second transmission rate in a manner of incrementing the transmission rate by a fixed value, to obtain a second time interval for the target request; adjust the current transmission rate to a third transmission rate in a manner of halving the transmission rate, to obtain a third time interval for the target request.

[0015] In some possible implementation manners, the sending module is specifically configured to: if the sending time interval is reached, apply one or more global tokens corresponding to the target request to a global token bucket; if the global tokens are successfully applied to the global token bucket, apply one or more volume-level tokens corresponding to the target request to a volume-level token bucket corresponding to a storage volume to which the target request belongs; if the volume-level tokens are successfully applied to the volume-level token bucket, in response to the global tokens and the volume-level tokens being applied, send the target request to the cloud server.

[0016] In some possible implementation manners, the method further includes: a reference value calculation module configured to calculate a global limiting speed reference value corresponding to the global tokens by using the load state indicator; a global limiting speed calculation module configured to constrain the global limiting speed reference value between a preset maximum limiting speed value and a minimum limiting speed value, to obtain the global limiting speed parameter corresponding to the global tokens.

[0017] In some possible implementation manners, the load state indicator at least includes a CPU usage rate and a memory usage rate, and the reference value calculation module is specifically configured to: The CPU usage rate is used to calculate a corresponding first rate value, the first rate value is positively correlated with the CPU usage rate, and the growth rate thereof slows down with the increase of the CPU usage rate. The memory usage rate is used to calculate a corresponding second rate value, the second rate value is positively correlated with the memory usage rate, and the growth rate thereof slows down with the increase of the memory usage rate. The smaller one of the first rate value and the second rate value is taken as a global throttling reference value corresponding to the global token.

[0018] In some possible implementation manners, the method further includes: The weight obtaining module is configured to obtain a weight coefficient corresponding to each of the storage volumes. The volume-level throttling calculation module is configured to allocate an initial volume-level throttling parameter corresponding to each of the storage volumes according to the weight coefficient and the global throttling parameter. The total rate obtaining module is configured to obtain an actual total transmission rate corresponding to all the storage volumes. The adjusting module is configured to, if the actual total transmission rate is less than the global throttling parameter, sequentially increase the volume-level throttling parameter corresponding to one or more of the storage volumes according to the priority corresponding to each of the storage volumes.

[0019] An electronic device is also disclosed, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus. The memory is configured to store a computer program. The processor is configured to execute the program stored on the memory, and implement the method according to the embodiments of the present application.

[0020] A computer readable storage medium is also disclosed, which stores instructions, and when executed by one or more processors, causes the processors to execute the method according to the embodiments of the present application.

[0021] The embodiments of the present application have the following advantages: In this embodiment of the invention, during the rate limiting process between the cloud storage gateway and the cloud server, when the cloud storage gateway obtains a target request to be sent to the cloud server, it can also obtain corresponding historical requests. Based on the response results of the historical requests, it determines the sending time interval for the target request. If the sending time interval is reached, and a global token and a volume-level token are successfully applied for for the target request in sequence, the target request is sent to the cloud server. The generation rate of the global token is controlled by the global rate limiting parameters. The volume-level token corresponds to the storage volume to which the target request belongs, and the generation rate of the volume-level token is controlled by the volume-level rate limiting parameters. In this system, global rate limiting parameters and volume-level rate limiting parameters are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume. By adjusting the sending interval and multi-level token buckets based on the response results, the rate limiting policy can dynamically respond to the cloud server status and the resource pressure of the gateway itself, achieving fine-grained dynamic rate limiting. Furthermore, by combining multi-level token buckets with a monitoring feedback mechanism, it not only prevents a single non-critical volume from occupying all resources, but also intelligently reallocates resources when there is a surplus, avoiding resource idleness, optimizing the overall system throughput, and improving adaptability to complex environments. Attached Figure Description

[0022] Figure 1 This is a flowchart of the steps of a rate limiting method for a cloud storage gateway provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of rate adjustment provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the multi-level token bucket speed limit provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of an application scenario provided in an embodiment of the present invention; Figure 5 This is a structural block diagram of a rate limiting device for a cloud storage gateway provided in an embodiment of the present invention. Detailed Implementation

[0023] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] As an example, with the rapid increase in data traffic and increasingly diverse user demands, cloud storage systems need to handle scenarios involving high-concurrency access and massive data transfer. High concurrency and service load are two key metrics closely monitored by cloud storage, impacting service performance and stability. With limited hardware resources, as the load (requests per second, QPS) continuously increases, computing resources become overloaded, leading to a rapid surge in request latency, ultimately exhausting service resources and causing downtime and unresponsiveness. Therefore, from the perspective of fully utilizing resources and protecting services, request limits are necessary. However, in the process of rate limiting cloud storage gateways, there is often an over-reliance on preset fixed rates, making adaptive adjustments impossible. Furthermore, the fine-grained control capabilities are poor, making it difficult to cope with complex and ever-changing production environments.

[0025] In this invention, during the rate limiting process between the cloud storage gateway and the cloud server, when the cloud storage gateway obtains a target request to be sent to the cloud server, it can simultaneously obtain corresponding historical requests and determine the sending interval for the target request based on the response results of the historical requests. If the sending interval is reached and a global token and a volume-level token are successfully applied for sequentially for the target request, the target request is sent to the cloud server. The generation rate of the global token is controlled by global rate limiting parameters, and the volume-level token corresponds to the storage volume to which the target request belongs, with its generation rate controlled by volume-level rate limiting parameters. In this system, global rate limiting parameters and volume-level rate limiting parameters are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume. By adjusting the sending interval and multi-level token buckets based on the response results, the rate limiting policy can dynamically respond to the cloud server status and the resource pressure of the gateway itself, achieving fine-grained dynamic rate limiting. Furthermore, by combining multi-level token buckets with a monitoring feedback mechanism, it not only prevents a single non-critical volume from occupying all resources, but also intelligently reallocates resources when there is a surplus, avoiding resource idleness, optimizing the overall system throughput, and improving adaptability to complex environments.

[0026] Reference Figure 1 The diagram illustrates a flowchart of a rate-limiting method for a cloud storage gateway provided in an embodiment of the present invention, which may specifically include the following steps: Step 101: Obtain the target request to be sent to the cloud server and the historical requests, and determine the sending time interval for the target request based on the response results corresponding to the historical requests; A cloud storage gateway can be a hardware and software integrated device or a pure software entity deployed in a user's local data center or private cloud environment. It can act as an intelligent bridge and security proxy between local applications and remote cloud storage services. It presents a standardized local storage interface (such as NFS, SMB / CIFS) to local applications, while using cloud storage protocols to communicate with the cloud server to the backend, thereby achieving seamless, secure, and high-performance access to unlimited cloud storage capacity.

[0027] Optionally, the cloud storage gateway, as a key middleware layer, can have its core functions implemented by multiple closely cooperating components, such as a request receiving and protocol conversion engine, a data processing layer, and a local cache manager.

[0028] The request receiving and protocol conversion engine can serve as a "front-end service" of the cloud storage gateway, responsible for listening to and receiving network requests from local applications. The core function of this engine is to perform bidirectional protocol conversion: on the one hand, it converts standard file protocols (such as NFS READ and WRITE operations or SMB file operations) into logical request objects that the gateway can recognize and process; on the other hand, when interaction with the cloud is required, it can convert these internal logical requests into object storage protocols that the remote cloud service can recognize (for example, converting file operations into GET and PUT operations for AWS S3 or corresponding API calls for Alibaba Cloud OSS).

[0029] The data processing layer acts as a "data optimization and security processing" layer. Before data is uploaded to the cloud or after it is downloaded from the cloud to the local machine, this layer performs a series of key data processing operations. These mainly include: encryption—encrypting data using user-managed keys to ensure that data stored in the cloud cannot be deciphered even if accessed without authorization, thus guaranteeing data confidentiality; compression—reducing data volume using efficient compression algorithms, thereby significantly reducing the network bandwidth required during transmission and the final storage space consumed in the cloud; and deduplication—identifying and eliminating redundant content at the data block level, which is particularly effective for scenarios such as backups, maximizing storage efficiency and transmission volume. While these operations bring significant benefits, they are all computationally intensive tasks that continuously consume the gateway's valuable CPU computing cycles and memory resources. Therefore, in the architecture of this invention, the resource usage of this layer (i.e., load status indicators, such as CPU utilization and memory utilization) is collected in real time by the monitoring and feedback module and serves as a key input for calculating the global rate limit parameter, directly determining the overall rate limit of requests sent by the gateway to the cloud.

[0030] Finally, the local cache manager is a core component ensuring a high-performance experience for the gateway. It manages the gateway's local storage media (such as high-speed SSDs or large-capacity HDDs), forming an intelligent, high-performance caching layer. The local cache manager operates in two modes: in write caching mode, user-written data is first quickly and persistently written to the local cache, the gateway immediately returns a success message to the application, and then the data is asynchronously and in batches uploaded to the cloud in the background. This mechanism greatly improves the application's write response speed and user experience. In read caching mode, frequently accessed data (hot data) is retained in the local cache, and subsequent read requests can directly retrieve it from the local high-speed storage, thus avoiding the high latency caused by downloading from the cloud. The existence of caching fundamentally changes the data flow pattern. In this invention, precisely because of the existence of caching, the rate limiting mechanism does not apply to all data accesses, but selectively applies to the "outbound" data flow between the gateway and the cloud server. Specifically, only read requests that miss the local cache and write requests that need to be asynchronously refreshed to the cloud will consume uplink bandwidth resources to the cloud and trigger the adaptive rate limiting process of this invention, thereby enabling the rate limiting system to manage the most critical network paths more accurately and efficiently.

[0031] In some feasible implementations, the core modules involved in rate limiting management by a cloud storage gateway may include an AIMD module, a multi-level token bucket module, and a monitoring and feedback module. The AIMD module acts as the first line of defense for rate limiting, operating at the level of individual request flows. It dynamically adjusts the time interval between requests by monitoring the response results from the cloud server, achieving rapid congestion avoidance and recovery. The multi-level token bucket module acts as the second line of defense for rate limiting, operating at the level of concurrent requests. It performs fine-grained rate shaping and priority scheduling of requests through global and volume-level token buckets. The monitoring and feedback module, acting as the "management center" of the rate limiting strategy, periodically collects the gateway resource status and the actual traffic of each volume, dynamically calculates and adjusts the token bucket parameters, achieving macro-level adaptive resource allocation.

[0032] In this embodiment of the invention, when the cloud storage gateway obtains the target request to be sent to the cloud server, it can obtain the corresponding historical requests, and then determine the sending time interval for the target request based on the response result corresponding to the historical request. In this way, the sending time interval is adjusted by the response result, so that the rate limiting policy can dynamically respond to the state of the cloud server. This realizes the leap from "static configuration" to "dynamic perception and adaptation", which significantly improves the robustness of the cloud storage gateway in uncertain environments.

[0033] The response results include successful responses and failure responses. A "successful response" means that the cloud server successfully processed the request and returned a success status code (e.g., in the HTTP protocol, status code 200 means OK), which means that the previous communication link and cloud service were normal. A "failure response" means that the cloud server failed to process the request for some reason and returned an error or failure status, such as explicit error codes (e.g., 4xx client error, 5xx server error), request timeout: if no response is received from the cloud server within the predetermined time, the gateway will determine it as a timeout failure, or network connection interruption. Based on the response results returned by the cloud server, the cloud storage gateway can not only mechanically control the sending rhythm, but also adjust the rhythm according to the actual processing capacity of the cloud server and the corresponding feedback such as network status. This realizes the leap from "static configuration" to "dynamic perception and adaptation", which significantly improves the robustness of the cloud storage gateway in uncertain environments.

[0034] In some feasible implementations, if the response result of a historical request is a successful response from the cloud server, the sending interval for the target request is shortened; if the response result of a historical request is an error response or a request timeout from the cloud server, the sending interval for the target request is extended. This adjusts the sending interval based on the response result, enabling the rate limiting policy to dynamically respond to the cloud server's status. This achieves a leap from "static configuration" to "dynamic perception and adaptation," significantly improving the robustness of the cloud storage gateway in uncertain environments.

[0035] During the adjustment of the sending time interval, the cloud storage gateway can obtain the current transmission rate. If the current transmission rate is lower than a first preset threshold, it adjusts the current transmission rate to a first transmission rate by doubling the transmission rate, thus obtaining a first time interval for the target request. If the current transmission rate is greater than or equal to the first preset threshold, it adjusts the current transmission rate to a second transmission rate by incrementing the transmission rate by a fixed value, thus obtaining a second time interval for the target request. Therefore, when the response result is a "successful response," the cloud storage gateway can shorten the sending time interval corresponding to the target request, increasing the sending rate. Conversely, when the response result is a "failed response," the cloud storage gateway can adjust the current transmission rate to a third transmission rate by halving the transmission rate, thus obtaining a third time interval for the target request. By reducing the rate, the sending time interval is increased, ensuring that the request can be successfully responded to by the cloud server, thereby improving the request response success rate.

[0036] In some examples, the AIMD module can be responsible for dynamically adjusting the sending interval, its role being to dynamically control the rhythm of request issuance. Specifically, when the cloud storage gateway starts up, a base sending interval can be set for each request stream (or each target volume, etc.). t 0, and calculate the corresponding initial transmission rate. v min Optionally, v min It can provide a lower, safer detection rate.

[0037] When a successful response (such as HTTP 200 OK) is received from the cloud server, it indicates that the current network and cloud server processing capabilities are good, and the sending rate can be appropriately increased. The cloud storage gateway can then maintain a current transmission rate. v current and a maximum rate threshold v max By setting an acceleration switching threshold, such as 0.8× v max Then the corresponding interval shortening strategy can be executed: Phase 1: Multiplicative Increasing Window (MI): When v current <0.8× v max At this time, a multiplicative windowing method is used. Each time a successful response is received, the rate is doubled, i.e. v new =2× v current This helps cloud storage gateways quickly recover from a low-speed state to a higher operating rate. For example, suppose... v min =1 MB / s, v max =10 MB / s. Therefore, the rate change is: 1→2→4→8 MB / s.

[0038] Phase Two: Additive Windowing (AI): When v current ≥0.8× v max When the speed reaches 8MB / s, switch to additive windowing. Each time a successful response is received, increase the rate by a fixed value. v x (e.g., 0.5 MB / s), that is v new = v current + v xBased on this process, overly aggressive growth near the limit rate can be effectively avoided, preventing shocks to the system. For example, the rate change is: 8→8.5→9→9.5→10MB / s.

[0039] In the above process, the transmission time interval tinterval is inversely proportional to the transmission rate. For a fixed-size request block, tinterval = block size / v current The system then dynamically adjusts the waiting time for the next request based on the calculated new rate.

[0040] Accordingly, when a request fails to respond (e.g., HTTP 5xx error, connection timeout), it indicates network or cloud server congestion, requiring an immediate and significant reduction in request frequency to avoid exacerbating the congestion. In this process, the cloud storage gateway can employ a multiplicative windowing (MD) strategy. Upon detecting a failed response, the current transmission rate is immediately halved. v new = v current / 2, for example, if the rate at which the failure occurs is 10 MB / s, then the rate changes as follows: 10 → 5 → 2.5 → 1.25 MB / s, until it drops to v min .

[0041] Step 102: If the specified sending time interval is reached, and a global token and a volume-level token are successfully applied for sequentially for the target request, then the target request is sent to the cloud server. The generation rate of the global token is controlled by a global rate limiting parameter, and the volume-level token corresponds to the storage volume to which the target request belongs, and the generation rate of the volume-level token is controlled by a volume-level rate limiting parameter. The global rate limiting parameter and the volume-level rate limiting parameter are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume.

[0042] When the cloud storage gateway dynamically determines the corresponding sending interval for a target request, and this sending interval is reached, the cloud storage gateway can request the corresponding token from the global token bucket and the volume-level token bucket. If a global token and a volume-level token are obtained for the target request in sequence, the target request can be sent to the cloud server. During the token request process, the generation rate of the global token is controlled by global rate limiting parameters, and the volume-level token corresponds to the storage volume to which the target request belongs, with the generation rate of the volume-level token controlled by volume-level rate limiting parameters. The global rate limiting parameters and volume-level rate limiting parameters are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume. By adjusting the sending interval and multi-level token buckets based on the response results, the rate limiting policy can dynamically respond to the cloud server status and the gateway's own resource pressure, achieving fine-grained dynamic rate limiting. Furthermore, the combination of multi-level token buckets and monitoring feedback mechanisms prevents a single non-critical volume from consuming all resources and intelligently reallocates resources when there is surplus, avoiding resource idleness, optimizing the overall system throughput, and improving adaptability to complex environments.

[0043] Optionally, the cloud storage gateway supports concurrent processing of multiple volumes. To address scenarios with varying volume importance and usage frequency, the cloud storage gateway can specifically create a global token bucket with a token generation rate... R total This can be dynamically determined by the monitoring feedback algorithm described later. Furthermore, the cloud storage gateway can also create a volume-level token bucket for each storage volume (such as "Volume-Financial DB" or "Volume-Video Surveillance"). The initial token generation rate for each volume-level token bucket... R i According to its weight w i Proportional allocation, i.e. R i = w i × R total Optionally, the weights can be set by the user based on the actual business importance, and this invention does not impose any restrictions on this.

[0044] In some feasible implementations, if the specified sending time interval is reached, one or more global tokens corresponding to the target request are requested from the global token bucket. If a global token is successfully obtained from the global token bucket, one or more volume-level tokens corresponding to the target request are requested from the volume-level token bucket corresponding to the storage volume to which the target request belongs. If a volume-level token is successfully obtained from the volume-level token bucket, the target request is sent to the cloud server in response to obtaining both the global token and the volume-level token. Conversely, if a global token cannot be obtained from the global token bucket, the target request is blocked and needs to continue waiting to obtain a global token. If a global token is successfully obtained from the global token bucket, but a volume-level token cannot be obtained from the volume-level token bucket, the target request is also blocked and needs to continue waiting to obtain a volume-level token. Thus, the cloud storage gateway can intelligently adjust the global rate limit and the rate limit of each volume in real time, ensuring stable system operation while optimizing the user experience.

[0045] In its implementation, once a target request passes through the AIMD module of the cloud storage gateway and reaches its designated sending time, the cloud storage gateway can request global tokens from the global token bucket. This includes requesting one global token for a single object and requesting multiple global tokens in proportion to the batch size. If the current number of tokens in the global token bucket is insufficient, it indicates that the target request is blocked and needs to wait until enough tokens are generated in the global token bucket. Based on the request for global tokens, this ensures that the total pressure on the cloud service from the entire gateway does not exceed [a certain threshold]. R total If a global token is successfully obtained for the target request, the cloud storage gateway can further request a corresponding number of volume-level tokens from the volume-level token bucket to which the target request belongs (such as the token bucket of "Volume-Financial DB"). If there are insufficient tokens in the volume-level token bucket, the target request will also be blocked and will need to wait until enough tokens are generated in the volume-level token bucket, thus ensuring that non-critical volumes cannot occupy the bandwidth of critical volumes. Based on the above token application, the cloud storage gateway will only allow the target request to be sent to the cloud server if and only if both levels of tokens are successfully obtained. This allows the cloud storage gateway to intelligently adjust the global rate limit and the rate limit of each volume in real time, ensuring stable system operation while optimizing user experience.

[0046] For example, suppose there is a global speed limit. R total =100 MB / s, "Volume - Financial DB" has a weight of 0.6, and "Volume - Video Surveillance" has a weight of 0.4. Therefore: The initial speed limit for "Volume-Finance DB" is 100 × 0.6 = 60 MB / s.

[0047] The initial speed limit for "Volume-Video Surveillance" is 100 × 0.4 = 40 MB / s.

[0048] Even if the "Volume-Video Surveillance" has a large amount of data to transmit, its maximum speed cannot exceed 40 MB / s, thus reserving a guaranteed bandwidth of 60 MB / s for the "Volume-Financial DB".

[0049] Specifically, for the global token bucket and volume-level token bucket, adjustments can be made using dynamic rate limiting parameters to achieve adaptive rate limiting based on resource pool load and actual transmission rates. In practice, a global rate limiting baseline value corresponding to the global token can be calculated based on load status indicators. This baseline value is then constrained between a preset maximum and minimum rate limiting value to obtain the global rate limiting parameters for the global token. Simultaneously, by obtaining the weight coefficients for each storage volume and assigning initial volume-level rate limiting parameters to each volume according to these weight coefficients and the global rate limiting parameters, the actual total transmission rate for all storage volumes is obtained. If the actual total transmission rate is less than the global rate limiting parameters, the volume-level rate limiting parameters for one or more storage volumes are increased sequentially according to their priority.

[0050] Optionally, for the global rate limit benchmark, the load status indicators include at least CPU utilization and memory utilization. The cloud storage gateway can use CPU utilization to calculate the corresponding first rate value. The first rate value is positively correlated with CPU utilization, and its growth rate slows down as CPU utilization increases. Then, it can use memory utilization to calculate the corresponding second rate value. The second rate value is positively correlated with memory utilization, and its growth rate slows down as memory utilization increases. Then, the smaller of the first rate value and the second rate value is used as the global rate limit benchmark value corresponding to the global token.

[0051] In some feasible implementations, the calculation of the global rate limit parameter shows that the rate limit value is positively correlated with the system load, but it cannot increase linearly and infinitely. When the load approaches its limit, the rate limit can tend to level off to prevent the system from being overwhelmed. Specifically, the cloud storage gateway can use a quadratic function to simulate this adjustment process, and the calculation formula can be: R total =Min(α1*U cpu -β1*U cpu ²,α2*U mem -β2*U mem ²), where α1, β1, α2, β2, etc. can be parameters for system capacity optimization, thus the formula can reflect the characteristics of "positive correlation but slowed growth".

[0052] For example, assuming α1=3, β1=0.02, when Ucpu=50%, the first rate value=3. 0.5 0.02 0.25 = 1.5 0.005 = 1.495; when Ucpu = 80%, the first speed value = 3. 0.8 0.02 0.64 = 2.4 0.0128 = 2.3872. It can be seen that when CPU utilization increases from 50% to 80% (an increase of 30%), the rate of increase from 1.495 to 2.387 (an increase of approximately 0.892) is slower. Furthermore, the calculated... R total Compared with the preset absolute upper and lower limits [ R min , R max Compare them to ensure they are within a reasonable range, that is... R total = Max(Min( R total , R max ), R min ).

[0053] After calculating the corresponding global speed limit parameters through the above process, the volume-level speed limit parameters can be dynamically determined based on the newly calculated global speed limit parameters. R total and corresponding weights w i Calculate the baseline speed limit for each volume. R i = w i × R total Next, calculate the actual total transfer rate of all current volumes. V total =∑ V i ,if V total < R total (Indicating sufficient total bandwidth), dynamic fine-tuning is then initiated. The cloud storage gateway can check each volume sequentially according to its priority (usually determined by weight, with higher weights taking precedence). For each checked volume, its rate limit can be increased by an increment Δv (e.g., 5MB / s). R inew =max( V i +Δv, R ioldThis is equivalent to encouraging the volume to use more bandwidth when possible. After each adjustment, the bandwidth is recalculated. V total If there is still surplus, continue to adjust the volume of the next priority, and so on, until the resources are fully utilized or all volumes have been adjusted.

[0054] For example, following the calculation process of the aforementioned global speed limit parameters, let's assume the target time... R total =100MB / s, actual speed of the "Financial DB" volume V 1 = 50 MB / s (below its speed limit of 60), "Video Surveillance" volume V 2 = 40 MB / s (reaching its speed limit of 40). At this time, V total If 90 < 100, the cloud storage gateway can first increase the rate limit of the high-priority "Financial DB" volume: R 1new =max(50+5,60)=60MB / s (because its actual speed is still lower than the new speed limit, no further traffic was triggered). Subsequently, the cloud storage gateway increased the speed limit for the "Video Surveillance" volume: R 2new =max(40+5,40)=45MB / s. Ultimately, the "Video Surveillance" volume can transmit at a maximum rate of 45 MB / s, improving overall bandwidth utilization. This allows the cloud storage gateway to intelligently adjust global and individual volume rate limits in real time based on the actual pressure on the resource pool and the actual transmission rate of each volume, thereby optimizing the user experience while ensuring stable system operation.

[0055] It should be noted that the embodiments of the present invention include, but are not limited to, the examples described above. It is understood that those skilled in the art can make further settings according to actual needs under the guidance of the ideas in the embodiments of the present invention, and the present invention does not limit such settings.

[0056] In this embodiment of the invention, during the rate limiting process between the cloud storage gateway and the cloud server, when the cloud storage gateway obtains a target request to be sent to the cloud server, it can also obtain corresponding historical requests. Based on the response results of the historical requests, it determines the sending time interval for the target request. If the sending time interval is reached, and a global token and a volume-level token are successfully applied for for the target request in sequence, the target request is sent to the cloud server. The generation rate of the global token is controlled by the global rate limiting parameters. The volume-level token corresponds to the storage volume to which the target request belongs, and the generation rate of the volume-level token is controlled by the volume-level rate limiting parameters. In this system, global rate limiting parameters and volume-level rate limiting parameters are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume. By adjusting the sending interval and multi-level token buckets based on the response results, the rate limiting policy can dynamically respond to the cloud server status and the resource pressure of the gateway itself, achieving fine-grained dynamic rate limiting. Furthermore, by combining multi-level token buckets with a monitoring feedback mechanism, it not only prevents a single non-critical volume from occupying all resources, but also intelligently reallocates resources when there is a surplus, avoiding resource idleness, optimizing the overall system throughput, and improving adaptability to complex environments.

[0057] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the following examples are provided for illustrative purposes: As an example, a cloud storage gateway includes an optimized AIMD module and a corresponding multi-level token module. The AIMD module can dynamically adjust the sending interval of the target request based on the response result. For details, refer to... Figure 2 The diagram illustrates the rate adjustment provided in this embodiment of the invention. During the initialization phase, a base time interval t0 can be set as the default interval for sending all types of requests, and the initial transmission rate v is calculated. min When a request-response condition is met, using only the additive windowing (AI) strategy in the AIMD algorithm can lead to a longer time required to achieve high-speed transmission. Therefore, a combination of multiplicative windowing (MI) and AI can be used. MI can be used initially, and AI can be switched off just before reaching the threshold to prevent excessive network stress. For example, initially using MI, the transmission rate is 2v... min 4v min Wait until the threshold of 0.8v is reached. max Then, additive windowing is used, with the rate increasing sequentially to 0.8V. max +v x 0.8V max +2v x Wait until v is reached. max Request to start with v max It transmits at a constant speed.

[0058] Correspondingly, when a request fails to respond (e.g., due to network issues, timeouts, etc.), the cloud storage gateway assumes that continuing to send requests within a short period is likely to fail again, further increasing the pressure on the resource pool. Therefore, a multiplicative windowing (MD) strategy can be adopted to dynamically adjust the request time interval. In specific implementation, when a request fails to respond consecutively, the corresponding transmission rate decreases from v max Decrease sequentially to v max / 2、v max / 4、v max / 8 etc., until v min , will be v min The system continuously sends requests at a certain rate to detect when the service will be restored. This strategy aims to reduce the frequency of requests, alleviate the system load, and provide a buffer time for network recovery or troubleshooting.

[0059] When the system successfully receives a response at the target time, it means that the cloud storage is in a normal state or has restored its normal processing capacity. To handle the backlog of tasks, the system adopts the same strategy as described above to shorten the request interval. This continues until v is reached. max , starting with v max If the data is transmitted at a constant rate, then the processing efficiency of cloud storage can be considered to have reached the expected level.

[0060] Through the above process, this adaptive request time interval adjustment mechanism can dynamically adjust the frequency of request sending based on the response status of cloud storage, thereby ensuring system stability and optimal resource utilization while achieving efficient data transmission.

[0061] After adjusting the corresponding sending time interval through the above process, when the specified sending time is reached, the cloud storage gateway can request the corresponding token from the global token bucket and volume-level token bucket for the target request to be sent. The cloud storage gateway supports concurrent processing of multiple volumes. To address scenarios with varying volume importance and usage frequency, and to achieve volume-level rate limiting control, this embodiment of the invention creates global and individual volume token buckets. The global token bucket ensures that the total rate of all requests sent to the cloud storage is controllable, while the volume token bucket limits the rate of individual volumes. Based on the global token bucket and volume-level token bucket, this two-level control strategy provides a more flexible rate limiting method, ensuring fine-grained resource management and allocation. (Refer to...) Figure 3 This diagram illustrates a multi-level token bucket rate limiting method provided in an embodiment of the present invention, including: During the initialization phase, the cloud storage gateway can set corresponding rate limits for the token buckets globally and for each volume. Let's assume an initial global rate limit. And set a ratio according to the importance of each volume, and calculate the initial volume-level rate limit according to the ratio. , Next, based on the number of requests, requests can be categorized into batch requests and single object requests. For single object requests, one token is requested at a time, while for batch requests, multiple tokens are requested at once. When a target request is ready to be sent, the cloud storage gateway first requests a certain number of tokens from the global token bucket. If the number of tokens in the current token bucket is greater than 0, the token request is successful, and the system will continue to request tokens from the corresponding volume's token bucket. If the token bucket has 0 tokens, the request fails, and the request will be blocked until a token from the global token bucket is successfully obtained before attempting to request tokens from the volume's token bucket. Only after both levels of tokens are successfully obtained can the request be allowed to execute the sending task.

[0062] Furthermore, in addition to allowing users to manually adjust the rate limit, the cloud storage gateway can also achieve adaptive rate limiting by combining resource pool load indicators and actual transmission rates from the monitoring module. First, a global rate limit value is calculated based on multiple indicators of resource load status; second, rate limits are allocated to each volume proportionally; finally, the rate limit for each volume is dynamically adjusted based on the actual transmission rate of each volume as reported by monitoring, thus making fuller use of resources. The corresponding implementation process may include: 1. Provide a monitoring system for real-time monitoring of resource pool performance metrics: CPU utilization, memory utilization, and transfer rate of each volume.

[0063] 2. During the initialization phase, no rate limit is set, and the status of the resource pool is monitored.

[0064] 3. Calculate the global speed limit, where This is the global speed limit value. For CPU utilization, For memory usage, This is the maximum speed limit. This is the minimum speed limit. , , , These are parameters, which should be adjusted according to the actual situation, including:

[0065]

[0066]

[0067] 4. Based on the calculated global rate limit value, the rate limit adjustment mechanism is automatically triggered to adjust the global rate limit, and then the rate limit for each volume is automatically allocated according to the volume's weight ratio. These are the speed limits for Volume 1 and Volume 2, respectively. and Here are the weighting coefficients, where:

[0068]

[0069] 5. Based on the actual transmission rate of each volume , Calculate the actual total transmission rate. The rate limit for each volume is dynamically adjusted. The calculation is performed iteratively according to volume priority, assuming... Greater than Then Volume 1 has higher priority than Volume 2. When hour, Obtain again If it still satisfies , then calculate This adjustment avoids the problem of the actual transmission rate being much lower than the rate limit due to unreasonable weight settings or different peak and trough times in the transmission of different volumes.

[0070] Using the methods described above, the cloud storage gateway can intelligently adjust the global rate limit and the rate limit of each volume in real time based on the actual pressure of the resource pool and the actual transmission rate of each volume, thereby optimizing the user experience while ensuring stable system operation.

[0071] In summary, referring to the above process Figure 4 The diagram illustrates an application scenario provided in an embodiment of the present invention. In the corresponding application scenario, the adaptive rate limiting process of the cloud storage gateway includes: Phase 1: Concurrent Task Triggering and AIMD Rate Control 1. Thread pool concurrent task execution: The process begins with the thread pool of the cloud storage gateway, which is responsible for concurrently processing multiple data transmission tasks (such as file upload and download) that need to interact with cloud storage.

[0072] 2. Improved AIMD module intervention: Requests in each task first enter the improved AIMD module.

[0073] Monitoring and Decision Making: This module monitors the response results (success or failure) of historical requests.

[0074] Adaptive Adjustment: Based on monitoring results, it adaptively adjusts the sending interval of the next request. Its strategy is: If the historical response is successful, the interval is gradually shortened (accelerated).

[0075] If a historical response fails (e.g., timeout, error), the interval is significantly extended (deceleration) to quickly alleviate congestion.

[0076] Interval check: The module checks whether the sending interval has been reached. Only requests that have reached the predetermined interval are allowed to proceed to the next module. This achieves preliminary, coarse-grained control over the request sending rhythm.

[0077] Phase Two: Token Bucket Resource Shaping and Scheduling 3. Enter the token bucket module: Requests controlled by AIMD intervals enter the multi-level token bucket module for more refined rate shaping and resource scheduling.

[0078] 4. Monitoring feedback and global rate limiting: This module works in conjunction with the monitoring module to adaptively adjust the global rate limit. The monitoring module provides feedback on the stress status of resource pools (such as CPU and memory) and the actual transfer rate of each storage volume.

[0079] Based on this data, the system dynamically calculates and sets a global rate limit, which controls the total outbound bandwidth of the entire gateway to cloud services.

[0080] 5. Request a global token: The request first requires requesting a global token.

[0081] If the request fails: the request is blocked and waits until a new global token becomes available. This ensures that the total request rate does not exceed the global limit.

[0082] If the application is successful: Request to proceed to the next level of control.

[0083] Phase 3: Volume-level fine-grained control and request sending 6. Volume-level rate limiting and token application: After a global token application is successful, the system will adaptively adjust the volume rate limit of the storage volume to which the request belongs, based on the preset weight and monitoring feedback.

[0084] Then, a request was made to apply for a volume-level token.

[0085] If the request fails: the request is also blocked and waits, which prevents a single non-critical volume from occupying all resources and ensures that resources are allocated according to importance.

[0086] If the application is successful: the request has been granted final permission to send.

[0087] Phase 4: Request Execution and Result Feedback 7. Send a request to cloud storage: The request to successfully obtain two levels of tokens is finally sent to cloud storage.

[0088] 8. Response result feedback: After processing the request, cloud storage returns a response (success or failure).

[0089] This response will be immediately fed back to the AIMD module, serving as the basis for its subsequent adjustment of the transmission time interval, thus forming a complete, closed-loop adaptive control loop.

[0090] In summary, the overall request processing flow is roughly as follows: Multiple thread pools process tasks concurrently, and requests are sent to the cloud through a rate-limiting module.

[0091] Improved AIMD module: Requests in each task are sent to the next module at regular intervals, which are adaptively adjusted based on the response from the cloud.

[0092] Multi-level token bucket module: All requests sequentially request tokens from the global and volume-level token buckets, and are sent to the cloud upon successful request. The rate limiting of the token bucket module can be adaptively adjusted based on the resource pool pressure status of the monitoring module and the actual transmission rate.

[0093] Based on the above process, the technical solutions involved in the embodiments of the present invention have at least the following technical effects: 1. Adaptive Rate Limiting Algorithm: Combining the improved AIMD algorithm and multi-level token bucket algorithm, the rate limiting parameters of the cloud storage gateway are adaptively adjusted based on the response results of the cloud server, the resource pool pressure status of the monitoring module, and the actual rate. This avoids overloading the cloud storage gateway due to excessive requests and improves the stability and reliability of the system.

[0094] 2. Improved AIMD Module: The AIMD strategy has been improved by combining multiplicative and additive windowing to reduce network congestion. The request sending interval is adjusted in real time based on the cloud server's response, improving request processing speed and system throughput.

[0095] 3. Multi-level token bucket module: Assign weights based on the importance of the volume to achieve flexible and personalized rate limiting strategies, ensure high-priority processing of critical business operations, and improve user satisfaction.

[0096] 4. By combining the resource pool pressure status of the monitoring module and the feedback of the actual transmission rate of each volume, the global and volume rate limits are dynamically adjusted according to the adaptive rate limiting algorithm to achieve optimal resource allocation and efficient utilization. At the same time, it avoids the problem that the actual transmission rate is much lower than the rate limit due to unreasonable weight settings or different transmission peak and trough times for different volumes.

[0097] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0098] Reference Figure 5 The diagram illustrates a structural block diagram of a rate-limiting device for a cloud storage gateway provided in an embodiment of the present invention, which may specifically include the following modules: The request acquisition module 501 is used to acquire the target request to be sent to the cloud server and historical requests, and to determine the sending time interval for the target request based on the response results corresponding to the historical requests. The sending module 502 is used to send the target request to the cloud server if the sending time interval is reached and a global token and a volume-level token are successfully applied for sequentially for the target request. The generation rate of the global token is controlled by a global rate limiting parameter, and the volume-level token corresponds to the storage volume to which the target request belongs. The generation rate of the volume-level token is also controlled by a volume-level rate limiting parameter. The global rate limiting parameter and the volume-level rate limiting parameter are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume.

[0099] In some feasible implementations, the request acquisition module is specifically used for: If the response result of the historical request is that the cloud server returns a corresponding success response, then the sending time interval for the target request is shortened. If the response result of the historical request is that the cloud server returns a corresponding error response or the request times out, then the sending interval for the target request is extended.

[0100] In some feasible implementations, the request acquisition module is specifically used for: Get the current transmission rate; If the current transmission rate is lower than the first preset threshold, the current transmission rate is adjusted to the first transmission rate by doubling the transmission rate, thereby obtaining the first time interval for the target request; If the current transmission rate is greater than or equal to the first preset threshold, the current transmission rate is adjusted to a second transmission rate by incrementing the transmission rate by a fixed value, thereby obtaining a second time interval for the target request; The current transmission rate is adjusted to a third transmission rate by halving the transmission rate, thereby obtaining a third time interval for the target request.

[0101] In some feasible implementations, the sending module is specifically used for: If the specified sending time interval is reached, then request one or more global tokens corresponding to the target request from the global token bucket; If the global token is successfully obtained from the global token bucket, then one or more volume-level tokens corresponding to the target request are requested from the volume-level token bucket corresponding to the storage volume to which the target request belongs. If the volume-level token is successfully obtained from the volume-level token bucket, the target request is sent to the cloud server in response to obtaining both the global token and the volume-level token.

[0102] Among some feasible implementation methods are: The baseline value calculation module is used to calculate the global rate limit baseline value corresponding to the global token using the load status index. The global speed limit calculation module is used to constrain the global speed limit benchmark value between a preset maximum speed limit value and a minimum speed limit value to obtain the global speed limit parameter corresponding to the global token.

[0103] In some feasible implementations, the load status indicators include at least CPU utilization and memory utilization, and the baseline value calculation module is specifically used for: Using the CPU utilization rate, a corresponding first rate value is calculated. The first rate value is positively correlated with the CPU utilization rate, and its growth rate slows down as the CPU utilization rate increases. Using the memory utilization rate, a corresponding second rate value is calculated. The second rate value is positively correlated with the memory utilization rate, and its growth rate slows down as the memory utilization rate increases. The smaller of the first rate value and the second rate value is used as the global rate limit reference value corresponding to the global token.

[0104] Among some feasible implementation methods are: The weight acquisition module is used to acquire the weight coefficients corresponding to each of the storage volumes. The volume-level rate limiting calculation module is used to allocate corresponding initial volume-level rate limiting parameters to each of the storage volumes according to the weighting coefficients and the global rate limiting parameters. The total rate acquisition module is used to acquire the actual total transmission rate corresponding to all the current storage volumes; The adjustment module is used to, if the actual total transmission rate is less than the global rate limit parameter, sequentially increase the volume-level rate limit parameter corresponding to one or more of the storage volumes according to their respective priorities.

[0105] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0106] In addition, this invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described cloud storage gateway rate limiting method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0107] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described cloud storage gateway rate limiting method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0108] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0109] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, EEPROM, Flash, and eMMC, etc.) containing computer-usable program code.

[0110] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0113] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0114] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0115] The above provides a detailed description of a cloud storage gateway rate limiting method and a cloud storage gateway rate limiting device provided by the present invention. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for limiting the speed of a cloud storage gateway, characterized in that, include: Obtain the target request to be sent to the cloud server and historical requests, and determine the sending time interval for the target request based on the response results corresponding to the historical requests; If the specified sending time interval is reached, and a global token and a volume-level token are successfully requested for the target request in sequence, then the target request is sent to the cloud server. The generation rate of the global token is controlled by the global rate limiting parameter, and the volume-level token corresponds to the storage volume to which the target request belongs, and the generation rate of the volume-level token is controlled by the volume-level rate limiting parameter. The global rate limiting parameter and the volume-level rate limiting parameter are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume.

2. The method according to claim 1, characterized in that, Determining the sending time interval for the target request based on the response results corresponding to the historical requests includes: If the response result of the historical request is that the cloud server returns a corresponding success response, then the sending time interval for the target request is shortened. If the response result of the historical request is that the cloud server returns a corresponding error response or the request times out, then the sending interval for the target request is extended.

3. The method according to claim 2, characterized in that, The shortening of the sending time interval for the target request includes: Get the current transmission rate; If the current transmission rate is lower than the first preset threshold, the current transmission rate is adjusted to the first transmission rate by doubling the transmission rate, thereby obtaining the first time interval for the target request; If the current transmission rate is greater than or equal to the first preset threshold, the current transmission rate is adjusted to a second transmission rate by incrementing the transmission rate by a fixed value, thereby obtaining a second time interval for the target request; Wherein, extending the sending time interval for the target request includes: The current transmission rate is adjusted to a third transmission rate by halving the transmission rate, thereby obtaining a third time interval for the target request.

4. The method according to claim 1, characterized in that, If the specified sending time interval is reached, and a global token and a volume-level token are successfully requested sequentially for the target request, then the target request is sent to the cloud server, including: If the specified sending time interval is reached, then request one or more global tokens corresponding to the target request from the global token bucket; If the global token is successfully obtained from the global token bucket, then one or more volume-level tokens corresponding to the target request are requested from the volume-level token bucket corresponding to the storage volume to which the target request belongs. If the volume-level token is successfully obtained from the volume-level token bucket, the target request is sent to the cloud server in response to obtaining both the global token and the volume-level token.

5. The method according to claim 1, characterized in that, Also includes: Using the load status index, calculate the global rate limit benchmark value corresponding to the global token; The global speed limit reference value is constrained between the preset maximum speed limit value and the minimum speed limit value to obtain the global speed limit parameter corresponding to the global token.

6. The method according to claim 5, characterized in that, The load status indicators include at least CPU utilization and memory utilization. The calculation of the global rate limit benchmark value corresponding to the global token using the load status indicators includes: Using the CPU utilization rate, a corresponding first rate value is calculated. The first rate value is positively correlated with the CPU utilization rate, and its growth rate slows down as the CPU utilization rate increases. Using the memory utilization rate, a corresponding second rate value is calculated. The second rate value is positively correlated with the memory utilization rate, and its growth rate slows down as the memory utilization rate increases. The smaller of the first rate value and the second rate value is used as the global rate limit reference value corresponding to the global token.

7. The method according to claim 1, characterized in that, Also includes: Obtain the weight coefficients corresponding to each of the storage volumes; Each storage volume is assigned a corresponding initial volume-level rate limit parameter according to the weighting coefficient and the global rate limit parameter. Obtain the actual total transfer rate corresponding to all the aforementioned storage volumes; If the actual total transmission rate is less than the global rate limit parameter, then according to the priority of each storage volume, the volume-level rate limit parameter corresponding to one or more storage volumes will be increased in sequence.

8. A rate limiting device for a cloud storage gateway, characterized in that, include: The request acquisition module is used to acquire the target request to be sent to the cloud server and historical requests, and to determine the sending time interval for the target request based on the response results corresponding to the historical requests. The sending module is used to send the target request to the cloud server if the sending time interval is reached and a global token and a volume-level token are successfully applied for sequentially for the target request. The generation rate of the global token is controlled by a global rate limiting parameter, and the volume-level token corresponds to the storage volume to which the target request belongs. The generation rate of the volume-level token is also controlled by a volume-level rate limiting parameter. The global rate limiting parameter and the volume-level rate limiting parameter are dynamically determined based on the load status indicators of the resource pool and the actual transmission rate of each storage volume.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-7.

Images