CN116527590A - Distributed current limiting implementation method and device for cloud native gateway - Google Patents
Distributed current limiting implementation method and device for cloud native gateway Download PDFInfo
- Publication number
- CN116527590A CN116527590A CN202310524807.4A CN202310524807A CN116527590A CN 116527590 A CN116527590 A CN 116527590A CN 202310524807 A CN202310524807 A CN 202310524807A CN 116527590 A CN116527590 A CN 116527590A
- Authority
- CN
- China
- Prior art keywords
- token
- gateway
- bucket
- current limiting
- tokens
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 28
- 230000004083 survival effect Effects 0.000 claims abstract description 21
- 230000007246 mechanism Effects 0.000 claims abstract description 15
- 238000011084 recovery Methods 0.000 claims abstract description 14
- 230000009471 action Effects 0.000 claims abstract description 9
- 238000012545 processing Methods 0.000 claims description 6
- 238000011144 upstream manufacturing Methods 0.000 claims description 6
- 230000005012 migration Effects 0.000 claims description 4
- 238000013508 migration Methods 0.000 claims description 4
- 238000004064 recycling Methods 0.000 claims description 3
- 238000004891 communication Methods 0.000 abstract description 2
- 230000006870 function Effects 0.000 description 4
- 238000013500 data storage Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000011217 control strategy Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/215—Flow control; Congestion control using token-bucket
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
- H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Abstract
The invention discloses a distributed current limiting realization method and device of a cloud native gateway, which relate to the technical field of computer communication, and the realization method comprises the following operations: deploying a Redis cluster in a Kubernetes cluster; selecting a Zset data type in Redis as a resource type of the current limiting token; configuring a flow limiting rule, and setting the number of token buckets and the token generation rate based on a sliding window; setting survival time for each token bucket, and automatically recovering the expired token bucket by using a Redis resource recovery mechanism; setting the globally unique key carried by the token as a key of the Zset; taking the generated sequence number of the token in each token bucket as a Value, and executing a consumption token action by using an API (application program interface) of the Zset data structure when consuming the token; the set rules count and limit the traffic requested by the API. The invention also discloses a distributed current limiting device which is used for executing the method, and after the distributed gateway is deployed, the accurate limitation of the flow peak value in any unit time period can be realized.
Description
Technical Field
The invention relates to the technical field of computer communication, in particular to a distributed current limiting realization method and device of a cloud native gateway.
Background
With the continuous development of cloud technology, container technology represented by Kubernetes is becoming a new interface for cloud computing.
In the service scene of high availability and multiple instances, how to ensure accurate distributed current limiting by the cloud native gateway service becomes a basic problem of the cloud native gateway. Common current limiting schemes include frequency limiting and current limiting based on a leaky bucket algorithm and total current limiting based on a token bucket, but the schemes can cause different problems. The current limiting strategy based on the leaky bucket algorithm needs to be locked every time when being realized under a distributed architecture, so as to ensure the flow control strategy of the leaky bucket algorithm; the token bucket based throttling policy may cause the total amount of traffic before and after the token bucket reset action to exceed a set number of times of throttling per unit time.
Based on the method, the distributed current limiting implementation method and the device of the cloud primary gateway are designed and developed to ensure accurate flow limitation in a current limiting unit time.
Disclosure of Invention
Aiming at the needs and the shortcomings of the prior art, the invention provides a distributed current limiting implementation method and device of a cloud native gateway.
Firstly, the invention discloses a distributed current limiting implementation method of a cloud primary gateway, which solves the technical problems and adopts the following technical scheme:
a distributed current limiting implementation method of a cloud native gateway comprises the following operations:
(1) Deploying a Redis cluster in the Kubernetes cluster to serve as a CAS current-limiting data storage center of the gateway;
(2) Selecting a Zset data type in Redis as a resource type of the current limiting token;
(3) Configuring a flow limiting rule, and setting the number of token buckets and the token generation rate based on a sliding window;
(4) Setting survival time for each token bucket, and automatically recovering the expired token bucket by using a Redis resource recovery mechanism;
(5) Each token carries a global unique key, the global unique key carried by the token is set as a key of the Zset, and uniqueness of the API request is ensured;
(6) Taking the generated sequence number of the token in each token bucket as a Value, and executing a consumption token action by using an API (application program interface) of the Zset data structure when consuming the token;
(7) The set rules count and limit the traffic requested by the API.
Optionally, executing (3), configuring a throttling rule based on a sliding window algorithm and a token bucket algorithm, and creating a token through a leader instance in the distributed gateway;
when creating the token, confirming the token generation rate r in advance, and calculating according to the current limiting rule r=n/t to obtain: the flow limiting time unit t and the allowed pass times n of unit time are set, meanwhile, the number slot of the token barrels in the sliding window is set to be 4 by default, the maximum number of tokens in each token barrel is n/4, the effective time of each token barrel is t/4, and the survival time of each token barrel is t/4;
after the token bucket is created, whether the tokens in the token bucket are used or not, the token bucket is automatically destroyed after t/4 time units.
Optionally, performing (4) wherein the survival time of each token bucket is consistent with the validity period of the tokens therein;
when the tokens in the token bucket expire, whether the tokens are consumed or not, the token bucket is automatically recovered by a resource recovery mechanism of the Redis.
Optionally, the rule for executing the setting of (7) is specifically as follows:
when the API request is recorded each time, calculating a token bucket corresponding to the current time according to the current request time, attempting to acquire a token from the bucket, namely invalidating keys with the smallest score in the Zset, calculating the quantity of invalidated tokens, if the smallest score keys are invalidated successfully, successfully acquiring the token by the current request, if the quantity of invalidated tokens is 0, intercepting the request and not allowing the passage if no token exists in the current token bucket.
Optionally, after executing (1) - (7), the current limiting flow of the distributed current limiting implementation method is as follows:
after the distributed gateway is deployed, a gateway leader message is created in the Redis by the gateway example started first, the default validity period of the message is T s, and after the leader message is written in the gateway example started first, the residual gateway example looks up the existing leader and the leader message is not created again;
the gateway instance written into the leader message is called a leader instance, the leader instance maintains the creation of a token bucket and the generation of a token, the leader message in Redis is renewed every interval T-1s, the residual gateway service checks whether the leader message in Redis exists or not every T s, if not, the writing is carried out, and the gateway instance newly written with the leader message is updated into a new leader instance;
after the current limiting rule is configured, initializing token barrels in the time window firstly according to the delineated time window, filling the rest token barrels one by one according to the current limiting rate, and dividing the newly generated token barrels into a token consumption range by time window migration along with discarding of old token barrels, wherein during the period, a leader instance can continuously create tokens, and presetting the tokens into the latest token barrels in advance;
after entering the cluster, the flow is transferred to one gateway instance through load balancing, the gateway instance determines a flow limiting rule corresponding to the request destination API according to parameters carried by the request, and obtains a token in a token bucket corresponding to the current time according to the flow limiting rule, and after the token is successfully obtained, the passing request is directly transferred to a corresponding service, and meanwhile, the request without the token is directly returned to a requester to protect upstream services.
Secondly, the distributed current limiting implementation device of the cloud primary gateway solves the technical problems as follows:
a distributed current limit implementation device of a cloud native gateway, comprising:
the deployment module is used for deploying the Redis cluster in the Kubernetes cluster and is used as a CAS current-limiting data storage center of the gateway;
the selecting module is used for selecting the Zset data type in the Redis as the resource type of the current limiting token;
the configuration module is used for configuring the flow limiting rule to set the number of token buckets and the token generation rate based on the sliding window;
the setting and calling module is used for setting survival time for each token bucket and automatically recovering the expired token bucket by utilizing a Redis resource recovery mechanism;
the setting processing module is used for setting the global unique key carried by the token as the key of the Zset, so as to ensure the uniqueness of the API request;
the token processing module is used for taking the generated sequence number of the token in each token bucket as a Value, and executing the action of consuming the token by using an API (application program interface) of the Zset data structure when consuming the token;
and the rule setting module is used for setting rules, counting and limiting the flow requested by the API.
Optionally, the related configuration module configures the flow restriction rule based on a sliding window algorithm and a token bucket algorithm;
the configuration module calls a leader instance in the gateway to create a token;
when the leader instance creates the token, the configuration module needs to confirm the token generation rate r in advance, and the token generation rate r is calculated according to the current limiting rule r=n/t: the flow limiting time unit t and the allowed pass times n of unit time are set, meanwhile, the number slot of the token barrels in the sliding window is set to be 4 by default, the maximum number of tokens in each token barrel is n/4, the effective time of each token barrel is t/4, and the survival time of each token barrel is t/4;
after the token bucket is created, whether the tokens in the token bucket are used or not, the token bucket is automatically destroyed after t/4 time units.
Optionally, the survival time set by the related setting calling module for each token bucket is consistent with the validity period of the tokens in the token bucket;
when the tokens in the token bucket expire, whether the tokens are consumed or not, the setting calling module can call a resource recycling mechanism of the Redis to automatically recycle the expired token bucket.
Optionally, the rules set by the related rule setting module are specifically as follows:
when the API request is recorded each time, calculating a token bucket corresponding to the current time according to the current request time, attempting to acquire a token from the bucket, namely invalidating keys with the smallest score in the Zset, calculating the quantity of invalidated tokens, if the smallest score keys are invalidated successfully, successfully acquiring the token by the current request, if the quantity of invalidated tokens is 0, intercepting the request and not allowing the passage if no token exists in the current token bucket.
The distributed current limiting implementation method and device of the cloud native gateway have the beneficial effects that compared with the prior art:
(1) According to the invention, by using the Redis cluster deployed in the Kubernetes cluster as a main realization component of the current limiting function, the cloud primary biochemistry of gateway current limiting service and the high suitability of the gateway current limiting service to the cluster environment are ensured, and the basic requirement of the current large environment on service ecology is met; by selecting the ZSET in the Redis as the data type of the storage current limiting pool, and simultaneously using the function of the data type as much as possible during the current limiting operation, the complexity brought by the custom data storage rule is reduced, the occurrence probability of abnormality is reduced, the robustness of the function is increased, and the QPS loss is reduced; by limiting the data volume in each token bucket, the upstream service security is protected to the maximum extent; by configuring the flow limiting rule and presetting the token bucket, the token generation and the token use are decoupled, so that the extra operation in the flow limiting process is reduced, and the QPS loss is lightened; by setting the effective period for the resource, the invalid occupation of the resource is avoided, and the high utilization rate of the resource and a good resource recovery mechanism are achieved; the realization of a sliding window algorithm is added in the current limiting rule, so that the access quantity of the API is ensured to be limited in the current limiting rule set by a user in the current limiting time window, the accurate limitation of the flow is realized, and the safe operation of the upstream service is protected;
(2) The invention can solve the problem of flow limitation under the gateway distributed multi-instance architecture, solve the problem of instantaneous flow overrun after the current limiting strategy is changed, solve the problem of unsmooth request under the current limiting strategy and realize the accurate limitation of the flow peak value in any unit time period.
Drawings
FIG. 1 is a flow chart of a method according to a first embodiment of the invention;
FIG. 2 is a block diagram of a module connection according to a second embodiment of the present invention;
fig. 3 is a logic diagram of implementing distributed current limiting after implementing the implementation method of the first embodiment or using the implementation apparatus of the second embodiment.
Detailed Description
In order to make the technical scheme, the technical problems to be solved and the technical effects of the invention more clear, the technical scheme of the invention is clearly and completely described below by combining specific embodiments.
Embodiment one:
with reference to fig. 1, this embodiment proposes a distributed current limiting implementation method of a cloud native gateway, where the implementation method includes the following operations:
(1) Redis clusters are deployed in the Kubernetes cluster as CAS-limited data storage centers for gateways.
Redis (Remote Dictionary Server) is an open source log-type, key-Value database written in the C language, supporting network, and capable of being based on memory and persistent, and provides multiple language APIs. Redis may support higher concurrency than conventional local throttling, and use of Redis may maximally mitigate the additional delay that the throttling incurs to user requests.
(2) The Zset data type in Redis is selected as the resource type of the current limiting token.
ZSet (sorted set) as an ordered list of string type elements, the stored data members have the property of not allowing repetition, while each member element is associated with a score (the score may repeat), redis orders the members in the collection from small to large by score.
(3) A throttling rule is configured, and the number of token buckets and the token generation rate are set based on a sliding window.
Configuring a current limiting rule based on a sliding window algorithm and a token bucket algorithm, and creating a token through a leader instance in the distributed gateway;
when creating the token, confirming the token generation rate r in advance, and calculating according to the current limiting rule r=n/t to obtain: the flow limiting time unit t and the allowed pass times n of unit time are set, meanwhile, the number slot of the token barrels in the sliding window is set to be 4 by default, the maximum number of tokens in each token barrel is n/4, the effective time of each token barrel is t/4, and the survival time of each token barrel is t/4;
after the token bucket is created, whether the tokens in the token bucket are used or not, the token bucket is automatically destroyed after t/4 time units. Compared with the traditional token bucket algorithm, the method and the device can fully use new tokens by combining a sliding window algorithm, optimize the token failure mode, and automatically recover the failure tokens based on Redis without adding additional resource recovery logic.
(4) And setting survival time for each token bucket, and automatically recovering the expired token bucket by using a Redis resource recovery mechanism.
The survival time of each token bucket is consistent with the validity period of the tokens in the token bucket;
when the tokens in the token bucket expire, whether the tokens are consumed or not, the token bucket is automatically recovered by a resource recovery mechanism of the Redis, so that the survival of the effective tokens and the timely cleaning of the invalid tokens are ensured; meanwhile, by setting the survival time, a resource recovery mechanism of the Redis can be used, so that additional resource recovery operation is reduced, additional operation requests for the Redis are reduced, and the memory burden is lightened; compared with the conventional token bucket algorithm, redundant data is reduced, storage resource waste is avoided, resource utilization rate is improved, and long-time occupation of storage resources is reduced.
(5) Each token carries a global unique key, the global unique key carried by the token is set as a key of the Zset, the uniqueness of each request in the current limiting resource pool is ensured, and the tokens in the token bucket are ensured not to be consumed repeatedly; compared with the conventional current limiting, the method and the device reserve the global unique key of the token, and can ensure that the problems of repeated counting and the like cannot occur through the global unique key, and ensure the accuracy of the current limiting function.
(6) And taking the generated sequence number of the token in each token bucket as a Value, and executing the action of consuming the token by using an API (application program interface) of the Zset data structure when consuming the token.
Because the tokens in each token bucket are provided with global unique keys, the Key score generated at the same time is higher according to the generation time, so that the number of the tokens in each token bucket accords with the current limiting rule, and each Key also needs to carry the token serial number in the token bucket on the basis of using uuid, and the format is as follows: uuid+token number.
The generated serial number of the token in each token bucket is used as a Value, so that the newly generated token can be guaranteed to have a larger score in each token bucket, meanwhile, old tokens with small scores are preferentially consumed when the token is consumed by the flow, in addition, the token serial number is used as the score, the tokens can be easily ordered, and therefore the execution of the consumption token action is convenient as much as possible by using an API (application program interface) of the Zset data structure when the token is consumed.
(7) The set rule counts and limits the flow requested by the API, and the set rule is specifically as follows:
when the API request is recorded each time, calculating a token bucket corresponding to the current time according to the current request time, attempting to acquire a token from the bucket, namely invalidating keys with the smallest score in the Zset, calculating the quantity of invalidated tokens, if the smallest score keys are invalidated successfully, successfully acquiring the token by the current request, if the quantity of invalidated tokens is 0, intercepting the request and not allowing the passage if no token exists in the current token bucket.
With reference to fig. 3, after executing (1) - (7), the current limiting flow of the distributed current limiting implementation method is as follows:
after the distributed gateway is deployed, a gateway leader message is created in the Redis by the gateway example started first, the default validity period of the message is T s, and after the leader message is written in the gateway example started first, the residual gateway example looks up the existing leader and the leader message is not created again;
the gateway instance written into the leader message is called a leader instance, the leader instance maintains the creation of a token bucket and the generation of a token, the leader message in Redis is renewed every interval T-1s, the residual gateway service checks whether the leader message in Redis exists or not every T s, if not, the writing is carried out, and the gateway instance newly written with the leader message is updated into a new leader instance;
after the current limiting rule is configured, initializing token barrels in the time window firstly according to the delineated time window, filling the rest token barrels one by one according to the current limiting rate, and dividing the newly generated token barrels into a token consumption range by time window migration along with discarding of old token barrels, wherein during the period, a leader instance can continuously create tokens, and presetting the tokens into the latest token barrels in advance;
after entering the cluster, the flow is transferred to one gateway instance through load balancing, the gateway instance determines a flow limiting rule corresponding to the request destination API according to parameters carried by the request, and obtains a token in a token bucket corresponding to the current time according to the flow limiting rule, and after the token is successfully obtained, the passing request is directly transferred to a corresponding service, and meanwhile, the request without the token is directly returned to a requester to protect upstream services.
Embodiment two:
with reference to fig. 2, this embodiment proposes a distributed current limiting implementation device of a cloud native gateway, which includes:
the deployment module is used for deploying the Redis cluster in the Kubernetes cluster and is used as a CAS current-limiting data storage center of the gateway;
the selecting module is used for selecting the Zset data type in the Redis as the resource type of the current limiting token;
the configuration module is used for configuring the flow limiting rule to set the number of token buckets and the token generation rate based on the sliding window;
the setting and calling module is used for setting survival time for each token bucket and automatically recovering the expired token bucket by utilizing a Redis resource recovery mechanism;
the setting processing module is used for setting the global unique key carried by the token as the key of the Zset, so as to ensure the uniqueness of the API request;
the token processing module is used for taking the generated sequence number of the token in each token bucket as a Value, and executing the action of consuming the token by using an API (application program interface) of the Zset data structure when consuming the token;
and the rule setting module is used for setting rules, counting and limiting the flow requested by the API.
In this embodiment, the configuration module configures the throttling rules based on a sliding window algorithm and a token bucket algorithm. The configuration module calls a leader instance in the gateway to create a token; when the leader instance creates the token, the configuration module needs to confirm the token generation rate r in advance, and the token generation rate r is calculated according to the current limiting rule r=n/t: the flow limiting time unit t and the allowed pass times n are set, meanwhile, the number slot of the token barrels in the sliding window is set to be 4 by default, the maximum number of tokens in each token barrel is n/4, the effective time of each token barrel is t/4, and the survival time of each token barrel is t/4. After the token bucket is created, whether the tokens in the token bucket are used or not, the token bucket is automatically destroyed after t/4 time units.
In this embodiment, the survival time set by the call setting module for each token bucket is consistent with the validity period of the tokens therein. When the tokens in the token bucket expire, whether the tokens are consumed or not, the setting calling module can call a resource recycling mechanism of the Redis to automatically recycle the expired token bucket.
In this embodiment, the rule set by the rule setting module is specifically as follows:
when the API request is recorded each time, calculating a token bucket corresponding to the current time according to the current request time, attempting to acquire a token from the bucket, namely invalidating keys with the smallest score in the Zset, calculating the quantity of invalidated tokens, if the smallest score keys are invalidated successfully, successfully acquiring the token by the current request, if the quantity of invalidated tokens is 0, intercepting the request and not allowing the passage if no token exists in the current token bucket.
With reference to fig. 3, using the distributed current limiting implementation device of this embodiment, the flow for implementing distributed current limiting is as follows:
after the distributed gateway is deployed, a gateway leader message is created in the Redis by the gateway example started first, the default validity period of the message is T s, and after the leader message is written in the gateway example started first, the residual gateway example looks up the existing leader and the leader message is not created again;
the gateway instance written into the leader message is called a leader instance, the leader instance maintains the creation of a token bucket and the generation of a token, the leader message in Redis is renewed every interval T-1s, the residual gateway service checks whether the leader message in Redis exists or not every T s, if not, the writing is carried out, and the gateway instance newly written with the leader message is updated into a new leader instance;
after the current limiting rule is configured, initializing token barrels in the time window firstly according to the delineated time window, filling the rest token barrels one by one according to the current limiting rate, and dividing the newly generated token barrels into a token consumption range by time window migration along with discarding of old token barrels, wherein during the period, a leader instance can continuously create tokens, and presetting the tokens into the latest token barrels in advance;
after entering the cluster, the flow is transferred to one gateway instance through load balancing, the gateway instance determines a flow limiting rule corresponding to the request destination API according to parameters carried by the request, and obtains a token in a token bucket corresponding to the current time according to the flow limiting rule, and after the token is successfully obtained, the passing request is directly transferred to a corresponding service, and meanwhile, the request without the token is directly returned to a requester to protect upstream services.
In summary, by adopting the method and the device for realizing the distributed current limiting of the cloud primary gateway, the accurate limitation of the flow peak value in any unit time period can be realized, the problem of flow limitation under the gateway distributed multi-instance architecture is solved, the problem of instantaneous flow overrun after the current limiting strategy is changed is solved, and the problem of unsmooth request under the current limiting strategy is solved.
The foregoing has outlined rather broadly the principles and embodiments of the present invention in order that the detailed description of the invention may be better understood. Based on the above-mentioned embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of the present invention.
Claims (9)
1. The distributed current limiting implementation method of the cloud native gateway is characterized by comprising the following operations:
(1) Deploying a Redis cluster in the Kubernetes cluster to serve as a CAS current-limiting data storage center of the gateway;
(2) Selecting a Zset data type in Redis as a resource type of the current limiting token;
(3) Configuring a flow limiting rule, and setting the number of token buckets and the token generation rate based on a sliding window;
(4) Setting survival time for each token bucket, and automatically recovering the expired token bucket by using a Redis resource recovery mechanism;
(5) Each token carries a global unique key, the global unique key carried by the token is set as a key of the Zset, and uniqueness of the API request is ensured;
(6) Taking the generated sequence number of the token in each token bucket as a Value, and executing a consumption token action by using an API (application program interface) of the Zset data structure when consuming the token;
(7) The set rules count and limit the traffic requested by the API.
2. The method for implementing distributed throttling of a cloud native gateway according to claim 1, wherein (3) is executed, a throttling rule is configured based on a sliding window algorithm and a token bucket algorithm, and a token is created through a leader instance in the distributed gateway;
when creating the token, confirming the token generation rate r in advance, and calculating according to the current limiting rule r=n/t to obtain: the flow limiting time unit t and the allowed pass times n of unit time are set, meanwhile, the number slot of the token barrels in the sliding window is set to be 4 by default, the maximum number of tokens in each token barrel is n/4, the effective time of each token barrel is t/4, and the survival time of each token barrel is t/4;
after the token bucket is created, whether the tokens in the token bucket are used or not, the token bucket is automatically destroyed after t/4 time units.
3. The method of claim 1, wherein (4) is performed, and the survival time of each token bucket is consistent with the validity period of the tokens in the token bucket;
when the tokens in the token bucket expire, whether the tokens are consumed or not, the token bucket is automatically recovered by a resource recovery mechanism of the Redis.
4. The distributed current limiting implementation method of the cloud native gateway according to claim 1, wherein the rule set by executing (7) is specifically as follows:
when the API request is recorded each time, calculating a token bucket corresponding to the current time according to the current request time, attempting to acquire a token from the bucket, namely invalidating keys with the smallest score in the Zset, calculating the quantity of invalidated tokens, if the smallest score keys are invalidated successfully, successfully acquiring the token by the current request, if the quantity of invalidated tokens is 0, intercepting the request and not allowing the passage if no token exists in the current token bucket.
5. The method for implementing distributed current limiting of a cloud native gateway according to any one of claims 1 to 4, wherein after executing (1) - (7), a current limiting flow of the method for implementing distributed current limiting is as follows:
after the distributed gateway is deployed, a gateway leader message is created in the Redis by the gateway example started first, the default validity period of the message is T s, and after the leader message is written in the gateway example started first, the residual gateway example looks up the existing leader and the leader message is not created again;
the gateway instance written into the leader message is called a leader instance, the leader instance maintains the creation of a token bucket and the generation of a token, the leader message in Redis is renewed every interval T-1s, the residual gateway service checks whether the leader message in Redis exists or not every T s, if not, the writing is carried out, and the gateway instance newly written with the leader message is updated into a new leader instance;
after the current limiting rule is configured, initializing token barrels in the time window firstly according to the delineated time window, filling the rest token barrels one by one according to the current limiting rate, and dividing the newly generated token barrels into a token consumption range by time window migration along with discarding of old token barrels, wherein during the period, a leader instance can continuously create tokens, and presetting the tokens into the latest token barrels in advance;
after entering the cluster, the flow is transferred to one gateway instance through load balancing, the gateway instance determines a flow limiting rule corresponding to the request destination API according to parameters carried by the request, and obtains a token in a token bucket corresponding to the current time according to the flow limiting rule, and after the token is successfully obtained, the passing request is directly transferred to a corresponding service, and meanwhile, the request without the token is directly returned to a requester to protect upstream services.
6. A distributed current limiting implementation device for a cloud native gateway, comprising:
the deployment module is used for deploying the Redis cluster in the Kubernetes cluster and is used as a CAS current-limiting data storage center of the gateway;
the selecting module is used for selecting the Zset data type in the Redis as the resource type of the current limiting token;
the configuration module is used for configuring the flow limiting rule to set the number of token buckets and the token generation rate based on the sliding window;
the setting and calling module is used for setting survival time for each token bucket and automatically recovering the expired token bucket by utilizing a Redis resource recovery mechanism;
the setting processing module is used for setting the global unique key carried by the token as the key of the Zset, so as to ensure the uniqueness of the API request;
the token processing module is used for taking the generated sequence number of the token in each token bucket as a Value, and executing the action of consuming the token by using an API (application program interface) of the Zset data structure when consuming the token;
and the rule setting module is used for setting rules, counting and limiting the flow requested by the API.
7. The distributed current limiting implementation apparatus of a cloud primary gateway according to claim 6, wherein the configuration module configures the current limiting rule based on a sliding window algorithm and a token bucket algorithm;
the configuration module calls a leader instance creation token in the gateway;
when the leader instance creates the token, the configuration module needs to confirm the token generation rate r in advance, and the token generation rate r is calculated according to the current limiting rule r=n/t: the flow limiting time unit t and the allowed pass times n of unit time are set, meanwhile, the number slot of the token barrels in the sliding window is set to be 4 by default, the maximum number of tokens in each token barrel is n/4, the effective time of each token barrel is t/4, and the survival time of each token barrel is t/4;
after the token bucket is created, whether the tokens in the token bucket are used or not, the token bucket is automatically destroyed after t/4 time units.
8. The distributed current limiting implementation apparatus of a cloud native gateway according to claim 6, wherein the set call module sets a survival time for each token bucket to be consistent with a validity period of a token therein;
when the tokens in the token bucket expire, the setting calling module can call the resource recycling mechanism of the Redis to automatically recycle the expired token bucket no matter whether the tokens are consumed or not.
9. The distributed current limiting implementation device of the cloud native gateway according to claim 6, wherein the rule set by the rule setting module is specifically as follows:
when the API request is recorded each time, calculating a token bucket corresponding to the current time according to the current request time, attempting to acquire a token from the bucket, namely invalidating keys with the smallest score in the Zset, calculating the quantity of invalidated tokens, if the smallest score keys are invalidated successfully, successfully acquiring the token by the current request, if the quantity of invalidated tokens is 0, intercepting the request and not allowing the passage if no token exists in the current token bucket.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310524807.4A CN116527590A (en) | 2023-05-11 | 2023-05-11 | Distributed current limiting implementation method and device for cloud native gateway |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310524807.4A CN116527590A (en) | 2023-05-11 | 2023-05-11 | Distributed current limiting implementation method and device for cloud native gateway |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116527590A true CN116527590A (en) | 2023-08-01 |
Family
ID=87408021
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310524807.4A Pending CN116527590A (en) | 2023-05-11 | 2023-05-11 | Distributed current limiting implementation method and device for cloud native gateway |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116527590A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116743833A (en) * | 2023-08-16 | 2023-09-12 | 雄安国创中心科技有限公司 | Method and device for enhancing communication capability and network control capability of terminal and service |
-
2023
- 2023-05-11 CN CN202310524807.4A patent/CN116527590A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116743833A (en) * | 2023-08-16 | 2023-09-12 | 雄安国创中心科技有限公司 | Method and device for enhancing communication capability and network control capability of terminal and service |
| CN116743833B (en) * | 2023-08-16 | 2023-11-03 | 雄安国创中心科技有限公司 | Method and device for enhancing communication capability and network control capability of terminal and service |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10552372B2 (en) | Systems, methods, and computer-readable media for a fast snapshot of application data in storage | |
| US11080260B2 (en) | Concurrent reads and inserts into a data structure without latching or waiting by readers | |
| CN114189478B (en) | Distributed current limiting implementation method and system based on sliding window algorithm | |
| US11263136B2 (en) | Fault tolerant systems and methods for cache flush coordination | |
| Elnozahy | Manetho: fault tolerance in distributed systems using rollback-recovery and process replication | |
| US20190384775A1 (en) | Active Transaction List Synchronization Method and Apparatus | |
| US9830333B1 (en) | Deterministic data replication with conflict resolution | |
| US11080262B1 (en) | Optimistic atomic multi-page write operations in decoupled multi-writer databases | |
| CN116527590A (en) | Distributed current limiting implementation method and device for cloud native gateway | |
| CN110968417B (en) | Method, apparatus, system and computer storage medium for managing storage units | |
| US10606489B2 (en) | Sidefiles for management of data written via a bus interface to a storage controller during consistent copying of data | |
| Douglis | Transparent process migration in the Sprite operating system | |
| CN115525221A (en) | Data updating method, device, equipment and medium | |
| CN111143383A (en) | Data updating method and device, electronic equipment and storage medium | |
| US11449241B2 (en) | Customizable lock management for distributed resources | |
| CN111857939A (en) | Method, system, electronic device and storage medium for deleting and pushing mirror image | |
| US7051051B1 (en) | Recovering from failed operations in a database system | |
| CN110413207B (en) | Method, apparatus and program product for reducing data recovery time of a storage system | |
| US11494099B2 (en) | Method, device, and computer program product for managing storage system | |
| US11281391B2 (en) | Method, device, and computer program for migrating backup system | |
| US11099945B2 (en) | Method, device, and computer program product for backing up data | |
| CN113297003A (en) | Method, electronic device and computer program product for managing backup data | |
| US20240152529A1 (en) | Multi-geography orchestration | |
| US11698914B1 (en) | Serverless managed bulk import on a global NoSQL database with selective back pressure | |
| US11809717B2 (en) | Data managing method, an electric device, and a computer program product for efficient management of services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |