Intelligent current limiting method based on RateLimiter

Abstract

The invention discloses an intelligent current limiting method based on a RateL imiter, and relates to the technical field of digital information transmission. The method comprises the following steps: step 1, creating an API (Application Program Interface), defining basic information, and defining an input parameter, a maximum concurrency and a current-limiting waiting timeout; 2, registering a service through zk, registering the current cluster service into zk for service discovery, registering and managing through a Java container when the service is started, registering and discovering the service in a static code block, and initializing the total number of the service; and step 3, storage management is carried out through a local map, and localized management of the RateL imiter is realized. According to the invention, through a refined design and an efficient implementation mode, refined current limiting control, flexible configuration management, system performance optimization and good expandability and maintainability are provided, and the system has wide application value and market prospect in practical application due to the advantages.

Description

Technical Field

[0001] The present invention relates to the technical field of digital information transmission, and in particular to an intelligent current limiting method based on RateLimiter. Background Art

[0002] As the system access volume increases, in order to protect the backend service from attacks by excessive requests, the interface access frequency is now controlled.

[0003] The current current limiting solutions are as follows:

[0004] Solution 1: Fixed Window Counter

[0005] Advantages: easy to understand and relatively straightforward to implement; for a fixed window length, the current limiting effect is stable.

[0006] Disadvantages: Burst traffic problems, namely "critical problems", are prone to occur at the boundary of the window. For example, at the end and start of the window, the traffic of the two windows may overlap, resulting in an unexpected number of requests; it is not enough to cope with sudden traffic peaks, which may cause resource waste or request rejection at certain times.

[0007] Solution 2: Sliding Window Counter

[0008] Advantages: Improves the shortcomings of the fixed window algorithm, and makes the flow control smoother and more accurate through the sliding window method; can handle traffic fluctuations more accurately and provide a smoother flow control effect; can dynamically adjust the window size to adapt to different traffic patterns

[0009] Disadvantages: The implementation is relatively complex and requires consideration of the implementation details and performance impact of window sliding. The higher the accuracy of the time interval, the larger the space capacity required by the algorithm.

[0010] Solution 3: Leaky Bucket Algorithm

[0011] Advantages: Processing requests at a fixed rate can maintain the system's processing capacity at a relatively stable level; it has a better control effect on burst traffic and can protect the system from overload in a short period of time.

[0012] Disadvantages: When instantaneous traffic comes, subsequent request traffic will be rejected, which may cause some requests to be discarded. It is not suitable for scenarios where all requests need to be processed as much as possible; the response speed may not be as flexible as other algorithms because the processing rate is fixed.

[0013] Solution 4: Token Bucket Algorithm

[0014] Advantages: It controls the average rate of requests and is suitable for smooth control of traffic. It has a certain buffering capacity for burst traffic and can provide more processing power in a short time. It has high stability and can dynamically adjust the rate of generating tokens to achieve high-precision current limiting.

[0015] Disadvantages: The implementation is relatively complex and it is difficult to handle short-term requests. When a large number of requests arrive in a short period of time, the tokens in the token bucket may be quickly consumed, thus limiting the flow; the time accuracy requirement is high. If the system time is inaccurate, the flow limiting effect may not be ideal; in some cases, if the system is not preheated when it goes online, the request may be mistakenly killed because there are no tokens in the bucket.

[0016] Since the maximum TPS control of the system is implemented dynamically, the concept of maximum concurrency is introduced in the cluster case. When the service is re-released, the number of services in the cluster will change dynamically, resulting in the maximum TPS in the cluster being inconsistent with the configuration in the short term. The reason is that the production of tokens is related to the number of registered clusters in zk, which will reduce the production rate and cause the system to be busy and not meet expectations. The first call after the service is restarted will trigger the creation of the token bucket, which will be locked and all token storage will be reset, resulting in a short period of system busyness.

[0017] Therefore, an intelligent current limiting method based on RateLimiter is proposed. Summary of the invention

[0018] The purpose of the present invention is to solve the problems raised in the above background technology, and provide an intelligent current limiting method based on RateLimiter.

[0019] In order to achieve the above-mentioned purpose, the present invention specifically adopts the following technical solutions:

[0020] An intelligent current limiting method based on RateLimiter, the method comprising the following steps:

[0021] Step 1: Create an API interface, define basic information, input parameters, maximum concurrency, and current limit waiting timeout;

[0022] Step 2: Register the service through ZK and register the current cluster service to ZK for service discovery. When the service starts, register and discover the service in the static code block through Java container registration management, and initialize the total number of services;

[0023] Step 3: Use local map for storage management to realize local management of RateLimiter;

[0024] Step 4: Execute external interface call, and check whether the current interface is configured with current limiting during interface call;

[0025] Step 5: Execute the specific business process of the API, generate a response code for production business processing and return the client request.

[0026] Further, step 3 includes the following steps:

[0027] Step 31: When the service is called, match the unique key through the interface information in step 1 to determine whether there is a RateLimiter corresponding to the key in the current map;

[0028] Step 32: If a RateLimiter corresponding to the key exists, it is returned and used. If a RateLimiter corresponding to the key exists, a RateLimiter is created.

[0029] Furthermore, during the judgment, the double-check lock mode is used to ensure the singleton and thread safety of RateLimiter to avoid repeated creation of RateLimiter with the same key.

[0030] Further, the double check lock mode includes the following steps:

[0031] Step a: When checking for the existence of RateLimiter for the first time, if it does not exist, a lock is used to ensure that only one thread enters the code block that creates RateLimiter;

[0032] Step b: In the second check after locking, if RateLimiter still does not exist, create RateLimiter.

[0033] Furthermore, the production rate of tokens in RateLimiter is the maximum concurrency entered in step one / the total number of services initialized in step two, and the creation result is cached in the local map for subsequent use and unified management.

[0034] Further, in step 4, when the interface is not configured or the configured maximum TPS is 0, the current limiting check is skipped and executed.

[0035] Furthermore, in step 4, when configuring current limiting, the rate of RateLimiter is obtained and verified from the map.

[0036] The beneficial effects of the present invention are as follows:

[0037] The present invention adopts a localized management method of RateLimiter to achieve refined current limiting control. By dynamically calculating the token production rate and performing current limiting verification according to the interface configuration, the system overload is effectively prevented and the stability and availability of the service are guaranteed.

[0038] The present invention allows the interface to configure whether to enable current limiting and parameters such as the maximum TPS, provides a flexible configuration management function, enables customized current limiting strategy settings according to actual needs, and meets the usage requirements in different scenarios;

[0039] The present invention uses a double-check lock mode to ensure the singleton and thread safety of RateLimiter, and uses an asynchronous thread pool to process logs and put log messages into a message queue for queue consumption. The present invention optimizes the performance of the system and improves the concurrent processing capability and response speed of the system.

[0040] The scalability and maintainability of the present invention make it easier and more flexible to expand or upgrade functions in the future. At the same time, the clear module division and interface definition also facilitate system maintenance and troubleshooting.

[0041] The present invention provides refined current limiting control, flexible configuration management, optimized system performance, good scalability and maintainability through refined design and efficient implementation. These advantages make the present invention have broad application value and market prospects in practical applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 It is a timing diagram of API calls of the present invention;

[0043] Figure 2 This is the flow chart of the API calling interface current limiting of the present invention. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings here can be arranged and designed in various different configurations.

[0045] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings. In addition, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0047] In the description of the embodiments of the present invention, it should be noted that the terms "inside", "outside", "upper", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, or are the orientations or positional relationships in which the inventive product is usually placed when used. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention.

[0048] like Figure 1 to Figure 2 As shown, an intelligent current limiting method based on RateLimiter includes the following steps:

[0049] Step 1: Create an API interface:

[0050] Define basic information: API name, interface path, maximum concurrency, current limit waiting timeout, purchasing manager, interface category, data classification, interface timeout, and function description;

[0051] Define input parameters: input parameter definition;

[0052] Maximum concurrency: Maximum TPS processing of the interface current limiting service system;

[0053] Current limiting waiting timeout: the maximum waiting time for obtaining a token.

[0054] Step 2: Register the service through ZK and register the current cluster service to ZK for service discovery. When the service starts, register and discover the service in the static code block through Java container registration management, and initialize the total number of services;

[0055] Step 3: Use local map for storage management to realize local management of RateLimiter;

[0056] Step 4: Execute external interface call, and check whether the current interface is configured with current limiting during interface call;

[0057] Step 5: Execute the specific business process of the API, generate a response code for production business processing and return the client request.

[0058] Step 3 includes the following steps:

[0059] Step 31: When the service is called, match the unique key through the interface information in step 1 to determine whether there is a RateLimiter corresponding to the key in the current map;

[0060] Step 32: If a RateLimiter corresponding to the key exists, it is returned and used. If a RateLimiter corresponding to the key exists, a RateLimiter is created.

[0061] When judging, the double-check lock mode is used to ensure the singleton and thread safety of RateLimiter to avoid repeated creation of RateLimiter with the same key.

[0062] The double check lock mode includes the following steps:

[0063] Step a: When checking for the existence of RateLimiter for the first time, if it does not exist, a lock is used to ensure that only one thread enters the code block that creates RateLimiter;

[0064] Step b: In the second check after locking, if RateLimiter still does not exist, create RateLimiter. This double-check lock mode mechanism not only ensures the uniqueness of the Bean, but also improves the performance of concurrent access.

[0065] The production rate of tokens in RateLimiter is the maximum concurrency entered in step 1 / the total number of services initialized in step 2, and the creation result is cached in the local map for subsequent use and unified management.

[0066] In step 4, when the interface is not configured or the configured maximum TPS is 0, the current limit check is skipped and executed.

[0067] In step 4, when configuring current limiting, obtain and verify the rate of RateLimiter from the map.

[0068] To sum up: the current flow limiting strategy can control the flow of the total entrance, but it cannot specifically limit the flow of certain products. What the present invention aims to solve is to control the total flow by diversion, and perform layered flow limiting through configurability + token bucket algorithm, so that flow management can be achieved in the product dimension in business.

[0069] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions only describe the principles of the present invention. The present invention may be subject to various changes and improvements without departing from the spirit and scope of the present invention. These changes and improvements fall within the scope of the present invention. The scope of protection claimed by the present invention is defined by the attached claims and their equivalents.

Claims

1. An intelligent current limiting method based on RateLimiter, characterized in that: The method comprises the following steps: Step 1: Create an API interface, define basic information, input parameters, maximum concurrency, and current limit waiting timeout; Step 2: Register the service through ZK and register the current cluster service to ZK for service discovery. When the service starts, register and discover the service in the static code block through Java container registration management, and initialize the total number of services; Step 3: Use local map for storage management to realize local management of RateLimiter; Step 4: Execute external interface call, and check whether the current interface is configured with current limiting during interface call; Step 5: Execute the specific business process of the API, generate a response code for production business processing and return the client request.

2. According to claim 1, a method for intelligent current limiting based on RateLimiter is characterized in that: Step 3 includes the following steps: Step 31: When the service is called, match the unique key through the interface information in step 1 to determine whether there is a RateLimiter corresponding to the key in the current map; Step 32: If a RateLimiter corresponding to the key exists, it is returned and used. If a RateLimiter corresponding to the key exists, a RateLimiter is created.

3. According to claim 2, a method for intelligent current limiting based on RateLimiter is characterized in that: When judging, the double-check lock mode is used to ensure the singleton and thread safety of RateLimiter to avoid repeated creation of RateLimiter with the same key.

4. According to the RateLimiter-based intelligent current limiting method of claim 3, it is characterized in that: The double check lock mode includes the following steps: Step a: When checking for the existence of RateLimiter for the first time, if it does not exist, a lock is used to ensure that only one thread enters the code block that creates RateLimiter; Step b: In the second check after locking, if RateLimiter still does not exist, create RateLimiter.

5. According to the RateLimiter-based intelligent current limiting method of claim 4, it is characterized in that: The production rate of tokens in RateLimiter is the maximum concurrency entered in step 1 / the total number of services initialized in step 2, and the creation result is cached in the local map for subsequent use and unified management.

6. The intelligent current limiting method based on RateLimiter according to claim 1, characterized in that: In step 4, when the interface is not configured or the configured maximum TPS is 0, the current limit check is skipped and executed.

7. The intelligent current limiting method based on RateLimiter according to claim 1, characterized in that: In step 4, when configuring current limiting, obtain and verify the rate of RateLimiter from the map.

Images