A rate limiter-based intelligent flow limiting method

Abstract

The application discloses an intelligent flow limiting method based on RateLimiter and relates to the technical field of digital information transmission.The method comprises the following steps: step 1: creating an API interface, defining basic information, defining input parameters, maximum concurrency and flow limiting waiting timeout; step 2: registering the current cluster service in zk for service discovery, registering and discovering the service in a static code block and initializing the total number of services through Java container registration management when the service is started; and step 3: storing and managing through a local map to realize the local management of RateLimiter.The application provides fine flow limiting control, flexible configuration management, optimized system performance, good scalability and maintainability through fine design and efficient implementation, so that the application has wide application value and market prospect in practical application.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of digital information transmission, and particularly relates to an intelligent flow limiting method based on RateLimiter. BACKGROUND

[0002] Due to the increasing system access volume, in order to protect the backend service from being attacked by excessive requests, the interface access frequency is controlled.

[0003] The current existing flow limiting schemes are as follows:

[0004] Scheme one: fixed window counter

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

[0006] Disadvantages: burst traffic problems are prone to occur at the boundary of the window, that is, the "critical problem", for example, at the end and beginning moments of the window, the traffic of two windows may be superimposed, resulting in exceeding the expected request volume; it is insufficient to cope with the peak of burst traffic, and may cause resource waste or request rejection at some moments.

[0007] Scheme two: sliding window counter

[0008] Advantages: the disadvantages of the fixed window algorithm are improved, the flow limiting is smoother and more accurate through the sliding window method; the traffic fluctuation can be more accurately processed, and a smoother flow limiting effect is provided; the window size can be dynamically adjusted to adapt to different traffic patterns

[0009] Disadvantages: the implementation is relatively complex, and the implementation details and performance influence of window sliding need to be considered; the higher the precision of the time interval, the larger the space capacity required by the algorithm.

[0010] Scheme three: leaky bucket algorithm

[0011] Advantages: the requests can be processed at a fixed rate, and the processing capacity of the system can be maintained at a relatively stable level; the burst traffic has a good control effect, and the system can be protected from overload in a short time.

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

[0013] Scheme four: token bucket algorithm

[0014] Advantages: control the average rate of request, suitable for smooth control of traffic; have certain buffer capacity for burst traffic, can provide more processing capacity in a short time; high stability, can dynamically adjust the rate of token generation, and realize high-precision flow limiting.

[0015] Disadvantages: relatively complex to implement, difficult to handle short-time requests. When a large number of requests arrive in a short time, the tokens in the token bucket may be quickly consumed, resulting in flow limiting; high time accuracy is required, and if the system time is not accurate, the flow limiting effect may not be ideal; in some cases, if the system is online without preheating, the request may be mistakenly killed because there are no tokens in the bucket.

[0016] Since the maximum TPS control of the system is dynamically implemented, the concept of maximum concurrency is introduced in the cluster. When the service is reissued, the number of services in the cluster will dynamically change, resulting in inconsistency between the maximum TPS in the cluster and the configuration in the short term. The reason is that the production of tokens is related to the number of registered clusters in zk, and the production rate will decrease, which may cause the system to be busy and not meet the expected situation. The first call after service restart will trigger the creation of the token bucket, which will have a lock and reset all token storage, resulting in a short-term system busy situation.

[0017] Therefore, an intelligent flow limiting method based on RateLimiter is proposed. SUMMARY

[0018] The purpose of the present application is to solve the problems raised in the background art. The present application provides an intelligent flow limiting method based on RateLimiter.

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

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

[0021] Step 1: create an API interface, define basic information, define input parameters, maximum concurrency and flow limiting waiting timeout;

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

[0023] Step 3: store and manage through local map, realize the localization management of RateLimiter;

[0024] Step 4: execute external interface call, and verify whether the current interface is configured with flow limiting when calling the interface;

[0025] Step 5: Perform API specific business process, and the business process generates a response code and returns to 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, and determine whether the RateLimiter corresponding to the key exists in the current map;

[0028] Step 32: If the RateLimiter corresponding to the key exists, return and use it; if the RateLimiter corresponding to the key does not exist, create the RateLimiter.

[0029] Further, in the judgment, a double-checked lock mode is adopted to ensure the singleton and thread safety of the RateLimiter, so as to avoid the repeated creation of the RateLimiter with the same key.

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

[0031] Step a: In the first check of whether the RateLimiter exists, if it does not exist, a lock is used to ensure that only one thread enters the code block for creating the RateLimiter;

[0032] Step b: In the second check after locking, if the RateLimiter still does not exist, the creation operation of the RateLimiter is performed.

[0033] Further, the production rate of the token in the RateLimiter is the maximum concurrency entered in step one or the total number of services initialized in step two, and the creation result of this time is cached to the local map for subsequent use for unified management.

[0034] Further, in step 4, when the interface is not configured or the configured maximum TPS is 0, skip the flow limiting check and execute.

[0035] Further, in step 4, when the flow limiting is configured, the rate of the RateLimiter is obtained and checked from the map.

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

[0037] The application adopts the way of local management of RateLimiter, realizes fine flow control, dynamically calculates the token production rate, and performs flow limiting check according to the interface configuration, effectively prevents system overload, and guarantees the stability and availability of the service;

[0038] The application allows interface configuration to enable current limiting and parameters such as maximum TPS, provides flexible configuration management functions, enables customized current limiting strategy setting according to actual needs, and meets the use requirements in different scenarios.

[0039] The application ensures the singleton and thread safety of the RateLimiter by using a double-check lock mode, processes logs by using an asynchronous thread pool, and puts log messages into a message queue for queuing consumption, thereby optimizing the performance of the system and improving the concurrent processing capability and response speed of the system.

[0040] The scalability and maintainability of the application make it easier and more flexible to extend or upgrade functions in the future, and clear module division and interface definition also help maintain and troubleshoot the system.

[0041] The application provides fine-grained flow control, flexible configuration management, optimized system performance, and good scalability and maintainability through fine-grained design and efficient implementation, and these advantages make the application have wide application value and market prospects in practical applications. BRIEF DESCRIPTION OF DRAWINGS

[0042] Fig. 1 is the API call timing diagram of the application;

[0043] Fig. 2 is the API call interface flowchart of the application. DETAILED DESCRIPTION

[0044] To make the purposes, technical solutions and advantages of the embodiments of the application clearer, the technical solutions in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, not all the embodiments. The components of the embodiments of the application described and shown in the drawings can be arranged and designed in various different configurations.

[0045] Therefore, the detailed description of the embodiments of the application provided in the drawings below is not intended to limit the scope of the claimed application, but only represents selected embodiments of the application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the application without creative labor are within the scope of protection of the application.

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

[0047] In the description of the embodiments of the present application, it should be noted that the terms "inner", "outer", "upper", and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, or the orientation or positional relationship in which the product of the present application is usually placed, and are only for the convenience of describing the present application and simplifying the description, and therefore cannot be understood as indicating or implying that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application.

[0048] As shown in Figs. 1-2 A RateLimiter-based intelligent flow limiting method, the method comprising the following steps:

[0049] Step 1: Create API interface:

[0050] Define basic information: API name, interface path, maximum concurrency, flow limiting waiting timeout, procurement manager, interface category, data classification, interface timeout, function description;

[0051] Define input parameters: input parameter definition;

[0052] Maximum concurrency: maximum TPS processing of interface flow limiting service system;

[0053] Flow limiting waiting timeout: maximum waiting time for obtaining token.

[0054] Step 2: Register the current cluster service in zk for service discovery, when the service starts, register and manage through Java container, register and discover in static code block, and initialize the total number of services;

[0055] Step 3: Store and manage through local map to realize the localization management of RateLimiter;

[0056] Step 4: Execute external interface call, and verify whether the current interface is configured with flow limiting when calling the interface;

[0057] Step 5: Execute API specific business process, produce business processing to generate response code and return to client request.

[0058] Step 3 comprises the following steps:

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

[0060] Step 32: If the RateLimiter corresponding to the key exists, return and use it; if the RateLimiter corresponding to the key does not exist, create the RateLimiter.

[0061] In the judgment, the double-check lock mode is adopted to ensure the singleton and thread safety of the RateLimiter, so as to avoid the repeated creation of the RateLimiter with the same key.

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

[0063] Step a: In the first check of whether the RateLimiter exists, if the RateLimiter does not exist, the lock is used to ensure that only one thread enters the code block for creating the RateLimiter;

[0064] Step b: In the second check after the lock is added, if the RateLimiter still does not exist, the creation operation of the RateLimiter is performed. The double-check lock mode mechanism ensures the uniqueness of the Bean and improves the performance of concurrent access.

[0065] The production rate of the token in the RateLimiter is the maximum concurrency entered in step one or the total number of services initialized in step two, and the creation result of this time is cached to the local map for subsequent use for unified management.

[0066] In step 4, when the interface is not configured or the maximum TPS is configured as 0, the flow limiting check is skipped and the execution is performed.

[0067] In step 4, when the flow limiting is configured, the rate of the RateLimiter is obtained and checked from the map.

[0068] In summary: the current flow limiting strategy can control the total flow, but cannot limit the flow of certain products. The invention can control the total flow, and can perform hierarchical flow limiting through the configurable + token bucket algorithm, so as to achieve the flow management of the product dimension on the business.

[0069] The above shows and describes the basic principles, main features and advantages of the present application. Those skilled in the art should understand that the present application is not limited to the above-mentioned embodiments, and the above-mentioned embodiments and descriptions in the specification are only the principles of the present application. Various changes and improvements can be made without departing from the spirit and scope of the present application, and these changes and improvements all fall within the scope of the claimed present application. The scope of protection of the present application is defined by the appended 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; The basic information includes: API name, interface path, maximum concurrency, current limit waiting timeout, purchasing manager, interface category, data classification, interface timeout, and function description; Step 2: Register the service through ZK and register the current cluster service in 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: Implement local management of RateLimiter by using local map for storage management; Step 4: Execute the external interface call and check whether the current interface is configured with current limiting. Step 5: Execute the API specific business process, generate a response code for the production business process and return it to the client request; The step 3 comprises the following steps: Step 31: When the service is called, the unique key is matched by 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 no RateLimiter corresponding to the key exists, a RateLimiter is created. The token production rate in RateLimiter is the maximum concurrency entered in step 1 or 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; In step 4, if the interface is not configured or the configured maximum TPS is 0, skip the current limit check and execute; In step 4, when configuring current limiting, obtain and verify the rate of RateLimiter from the map.

2. The intelligent current limiting method based on RateLimiter according to claim 1, characterized in that: When making a 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.

3. The intelligent current limiting method based on RateLimiter according to claim 2, 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.

Images