A fine-grained traffic limiting method for a distributed system

Abstract

The application discloses a kind of fine flow limiting method of distributed system applied to information technology field, the method is by double channel setting to user channel and application channel, on the basis of double channel, IP dimension, API dimension, frequency dimension and multiple dimensions are limited, to achieve the purpose of fine flow limiting, to effectively provide more accurate, more secure security services to the whole system, further fine division of VIP and non-VIP is carried out to the request party to determine the order of obtaining token, further effectively improve the precision of flow control and guarantee the availability of system under complex task scene, realize the flow control gateway of double channel multidimension, provide effective fine flow limiting method for large-scale distributed system flow control.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information technology, in particular to a fine flow limiting method for a distributed system. BACKGROUND

[0002] Nowadays, the digital economy and the real economy are deeply integrated and developed, so the software system supporting digitization also puts forward the requirement of providing high-availability and high-security services in high-complexity application scenarios. In the field of information technology, large-scale distributed systems can initially realize the above functions, and there are many flow limiting schemes for distributed systems under abnormally large traffic.

[0003] A more excellent technical method is a multi-dimensional flow limiting method, which realizes counting by using a cache database and persistently configures rules to realize system availability. This kind of technology realizes the flow limiting control of the gateway to the business service under the condition of cluster deployment, and realizes a certain degree of traffic peak clipping. However, the prior art does not finely control the traffic source, and it is difficult to realize targeted processing in a complex scenario. Although the coarse-grained traffic peak clipping avoids continuous attacks, it also affects normal requests.

[0004] Therefore, we solve the problem that the prior art cannot finely control the traffic source through the technical scheme. SUMMARY

[0005] The present application aims to improve the flow limiting method in the prior art, and provides a fine flow limiting method for a distributed system compared with the prior art. By setting double channels for user channels and application channels, and limiting multiple dimensions such as IP dimension, API dimension and frequency dimension on the basis of the double channels, the purpose of fine flow limiting is achieved, so that more accurate and safer guarantee services are provided for the entire system. In addition, the requestor is further finely divided into VIP and non-VIP to determine the order of obtaining tokens, which further improves the accuracy of flow control and ensures the availability of the system in complex task scenarios, realizes a double-channel multi-dimensional flow control gateway, and provides an effective fine flow limiting method for large-scale distributed system traffic control.

[0006] A fine flow limiting method for a distributed system, comprising the following steps:

[0007] S1, divide the system function granularity and the subject granularity:

[0008] S11, divide the function modules of the system into different applications, each application is associated with different products, and each product is associated with different APIs;

[0009] S12, in addition to the subdivision of general API, DUBBO service is also divided into a dimension;

[0010] S13, determine the channel and user entity based on the requester;

[0011] S2. Configure dual-channel and multi-dimensional verification rules:

[0012] S21, select one or both of the application channel and the user channel;

[0013] S22, choose one from product dimension, API dimension, channel dimension and microservice dimension;

[0014] S23, channels and dimensions combine to form a flow control rule;

[0015] S24, persist the flow control rules or store them using a caching system;

[0016] S3, client-side encapsulation of channel and dimension attributes;

[0017] S4. Automatically match relevant channel-level flow control rules based on the public information requested by the client:

[0018] S41, based on the client's request content, parse out the corresponding channel information and dimension information;

[0019] S42, Load rule information;

[0020] S43, record request information and verify rule information;

[0021] S44 processes client requests based on the verification results.

[0022] As a further improvement of the present invention, the application is the first level of system function granularity division, and can also be a module in different software systems; the product is the second level of system function granularity division, and can also be a sub-module; the API is the third level of system function granularity division.

[0023] As a further improvement of the present invention, the dual channels include an application channel and a user channel.

[0024] As a further improvement of the present invention, the S23 flow control method includes the following steps:

[0025] S231. If both channels are selected, then flow control will be applied to all requests.

[0026] S232. If only a single channel is selected, then flow control will be applied to all dimensions under that channel.

[0027] S233. If only a single dimension is selected, then traffic control will be applied to all user channels.

[0028] S234. After creating flow control rules based on channels and dimensions, configure filters, i.e., validation rules, for high-precision control, such as request frequency, IP, maximum number of connections from clients, configuration of request connection queue length, and maximum queue waiting time.

[0029] As a further improvement of the present invention, the method for loading rule information in S42 includes the following steps:

[0030] S421. Before persisting or storing the flow control rules in step S24, load the flow control rules into the real-time operation of the flow control module.

[0031] S422. During loading, the information should be categorized according to channel information and dimension information;

[0032] S423. Based on the rule information, load the specified number of tokens into the caching system;

[0033] S424. Obtain the latest flow control rules from the persistent storage and caching system, and check for updates. When loading new rules, classify them according to channel and dimension information, and replace or add them to the current rule set. Update the token count in the caching system to ensure consistency with the new rules. After updating the cache, broadcast or notify all relevant flow control modules and service instances that the rules have been updated so that they can also update accordingly.

[0034] As a further improvement of the present invention, information classification during loading is performed to facilitate retrieval without excessively affecting the response time of the entire software system.

[0035] As a further improvement of the present invention, the method for recording request information and verifying rule information in S43 includes the following steps:

[0036] S431. If the request fails, record the number of errors in the distributed cache storage system; if the request succeeds, proceed to the next step.

[0037] S432. Based on the channel and dimension information in the request, match the response processor, and then attempt to retrieve the specified token from the caching system;

[0038] S433. If a token is available, consume one token; otherwise, proceed to the filtering channel for processing.

[0039] Optionally, the filtering channel in step S433 includes a customer group classification module, which includes VIP and non-VIP units. The customer group classification module is connected to the final processing module upon power-on, which includes a rejection unit and a priority queuing unit. Dividing customers into VIP and non-VIP is to further segment the requesters, thereby achieving the effect of precise segmentation and allowing VIPs to have priority in obtaining tokens. This plays an auxiliary role in fine-grained rate limiting, thereby ensuring the availability of the system in complex task scenarios.

[0040] Optionally, the customer group classification module is located at the front end of the filtering channel and is used to classify the requester's customer group by parsing the customer information in the request; the final processing module is located downstream of the customer group classification module, directly connected to the output of the customer group classification module, and decides whether to reject the request or prioritize it based on the classification result of the customer group classification module.

[0041] Optionally, the processing method for the filtering channel includes the following steps:

[0042] S4331. When a customer sends a request and there is no available token, the request is transferred to the filtering channel. First, the customer group classification module divides the requester into VIP customers and non-VIP customers.

[0043] S4332. After the customer group is divided, it enters the final processing module for final result processing. If it is divided into non-VIP customers, the rejection unit directly rejects the request. If it is divided into VIP customers, it is included in the queue by the priority queuing unit to wait for the issuance of tokens.

[0044] Optionally, the method by which the customer group classification module divides requesters into VIP and non-VIP groups includes the following steps:

[0045] A. Parse user identification information;

[0046] B. Verify user identity;

[0047] C. Determine VIP status based on the membership level field.

[0048] Optionally, S4332 includes the following steps:

[0049] S4332.1, Non-VIP customer request processing: For requests from non-VIP customers, if there is no available token, a denial-of-service response will be returned directly through the rejection unit;

[0050] S4332.2 VIP Customer Request Processing: For VIP customer requests, if there is no available token, the request is added to the queue in the priority queuing unit. The priority queuing unit manages the VIP customer request queue and ensures that VIP customer requests can be processed first when a token is released. The VIP customer requests in the queue periodically check the token availability. Once a token is available, the request is immediately taken out of the queue for processing.

[0051] Compared with the prior art, the advantages of this invention are:

[0052] This solution implements a dual-channel configuration for user and application channels. Building upon this dual-channel approach, it further restricts traffic across multiple dimensions, including IP, API, and frequency, achieving refined rate limiting. This provides more precise and secure protection for the entire system. Furthermore, by further refining the classification of requesters into VIP and non-VIP categories to determine the order in which tokens are acquired, it effectively improves the precision of traffic control and ensures system availability in complex task scenarios. This dual-channel, multi-dimensional flow control gateway provides an effective and refined rate limiting method for large-scale distributed systems. Attached Figure Description

[0053] Figure 1 This is a flowchart of the method of the present invention;

[0054] Figure 2 This is a sequence diagram of the current limiting method of the present invention;

[0055] Figure 3 This is a schematic diagram of the module of the present invention. Detailed Implementation

[0056] The embodiments will be described clearly and completely with reference to the accompanying drawings. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0057] Example 1:

[0058] For a fine-grained rate limiting method for distributed systems, please refer to [link / reference]. Figures 1-2 This includes the following steps:

[0059] S1. Divide the system into functional granularity and main granularity.

[0060] Specifically, the steps in S1 for dividing the system into functional granularity and subject granularity include:

[0061] S11. Divide the system's functional modules into different applications, associate each application with a different product, and associate each product with a different API;

[0062] S12. In addition to the general API, the DUBBO service is also divided into a dimension. The DUBBO service is used to realize communication between remote call microservices, so as to achieve the purpose of fine-grained traffic protection for the system.

[0063] S13. Determine the channel or user entity based on the different requesters.

[0064] Specifically, the application described in S11 is the first level of system function granularity division, and can also be a module in different software systems; the product is the second level of system function granularity division, and can also be a sub-module; the API is the third level of system function granularity division.

[0065] Specifically, the system function granularity described in S1 also includes main objects such as users and developers.

[0066] S2. Configure dual-channel and multi-dimensional verification rules.

[0067] Specifically, the dual-channel system includes an application channel and a user channel. The channel defines the scope of traffic control, allowing for the option of controlling traffic for all application channels or only for specific user channels. For example, banking systems often face seasonal traffic peaks and sudden business requests due to concentrated transactions or subsidy applications during the grain purchase season. Traffic limiting rules can be configured separately for different user groups, such as farmers or enterprise users. This combination of dual channels and multiple dimensions enables the system to perform macro-level traffic control at the application and user layers, as well as achieve micro-level precise control through specific dimensions, effectively addressing the challenges of seasonal traffic fluctuations and sudden business requests.

[0068] Specifically, the multi-dimensional approach includes product, API, channel, and microservice dimensions. These dimensions provide fine-grained divisions for traffic control, allowing traffic control to be customized according to different business scenarios.

[0069] S21. Select one or both of the application channel and the user channel.

[0070] Specifically, the selection of channels is based on business needs, system architecture, and scalability.

[0071] S22. Choose one from the product dimension, API dimension, channel dimension, and microservice dimension.

[0072] Specifically, the selection of dimensions is based on factors such as granularity, traffic characteristics, and performance considerations.

[0073] S23. Channels and dimensions are combined to form a flow control rule, which is flexible and can define complex flow control strategies according to actual needs.

[0074] Specifically, the structure and mechanism of flow control rules describe how to create flow control rules by combining different channels and dimensions. These rules are used to finely control traffic in distributed systems to prevent system overload and ensure service quality.

[0075] Specifically, the method for composing flow control rules in S23 includes the following steps:

[0076] S231. If both channels are selected, then traffic control will be applied to all requests. The selection of this channel can be based on considerations for system security protection during special periods. Special periods can be determined based on the system's situation, such as when an application's interface needs to be upgraded or data changed. In this case, traffic control can be applied to all requests to avoid system overload. Special periods can also be determined based on pre-agreed peak traffic periods, such as when certain applications experience excessive requests during a certain period. To avoid a large number of requests arriving at the server in a short time and causing downtime, the request volume can be controlled in advance.

[0077] S232. If only a single channel is selected, then flow control will be applied to all dimensions under that channel.

[0078] S233. If only a single dimension is selected, such as the product dimension or the API dimension, then traffic control will be applied to all user channels.

[0079] S234. After creating flow control rules based on channels and dimensions, filters, i.e., validation rules, can be configured for high-precision control, such as request frequency, IP, maximum number of connections from the client, configuration of the length of the request connection queue, and maximum queue waiting time.

[0080] Specifically, flow control rules are not limited to a single channel or a certain dimension. Dual channels and multiple dimensions can also be combined to achieve customized control to the greatest extent possible. This is the only way to protect the security of the software system and improve its availability and stability.

[0081] S24. Persistently store flow control rules, or directly use the caching system for storage.

[0082] Specifically, persistent storage ensures that the original flow control strategy can be restored after a system restart or failure recovery. Because the data is stored on a reliable non-volatile medium, it provides strong consistency guarantees, and the rules are also stored in the caching system for fast access. Persistent storage has a slower read and write speed, especially when dealing with a large number of concurrent requests. It is highly dependent on hardware resources, and frequent read and write operations may increase the I / O burden. It is suitable for scenarios that require long-term data storage or scenarios with high data consistency requirements, such as user data, order information, and financial transaction systems.

[0083] Specifically, caching systems offer very high read and write performance, enabling rapid response to a large number of concurrent requests. By caching frequently used data, they reduce database query requests, thereby alleviating the database load. However, the data in the cache may differ from the data in persistent storage, especially during data updates. Furthermore, cached data is temporary, and data may be lost if the caching system fails or restarts. It is suitable for scenarios with extremely high read and write performance requirements or those needing to respond quickly to query requests, such as high-concurrency web applications and product queries on e-commerce websites.

[0084] S3, client-side encapsulation of channel and dimension attributes.

[0085] S4. Automatically match relevant channel-level flow control rules based on the public information requested by the client.

[0086] Specifically, the matching steps for the flow control rules described in S4 include:

[0087] S41. Based on the client's request content, parse out the corresponding channel information and dimension information;

[0088] S42. Load rule information;

[0089] S43. Record the request information and verify the rule information;

[0090] S44. Process client requests based on the verification results.

[0091] Specifically, the loading method for S42 includes the following steps:

[0092] S421. Before persisting the flow control rules in step S24 and storing them using a caching system, load the flow control rules into the real-time operation of the flow control module.

[0093] S422. During loading, the information should be categorized according to channel information and dimension information;

[0094] S423. Based on the rule information, load the specified number of tokens into the caching system;

[0095] S424. Obtain the latest flow control rules from the persistent storage and caching system, and check for updates. When loading new rules, classify them according to channel and dimension information, and replace or add them to the current rule set. Update the token count in the caching system to ensure consistency with the new rules. After updating the cache, broadcast or notify all relevant flow control modules and service instances that the rules have been updated so that they can also update accordingly.

[0096] Specifically, the rule loading described in S421 involves loading flow control rules into the flow control module during system runtime and classifying them according to channel and dimension information. This way, when a client request arrives, the corresponding rule can be quickly found for matching.

[0097] Specifically, the information classification during S422 loading is for easy retrieval without excessively affecting the response time of the entire software system.

[0098] Specifically, the method for S43 to record request information and verify rule information includes the following steps:

[0099] S431. If the request fails, record the number of errors in the distributed cache storage system; if the request succeeds, proceed to the next step.

[0100] S432. Based on the channel, dimension and other information in the request, match the response processor, and then try to obtain the specified token from the caching system;

[0101] S433. If a token is available, consume one token; otherwise, proceed to the filtering channel for processing.

[0102] Specifically, the filtering channel in step S433 is used to process requests that do not meet the conditions for direct passage.

[0103] Example 2:

[0104] Based on Example 1, please refer to Figure 3 The filtering channel in step S433 includes a customer group classification module, which comprises VIP and non-VIP units. This module is connected to a final processing module, which includes a rejection unit and a priority queuing unit. Dividing customers into VIP and non-VIP categories further segments the requesters, achieving precise segmentation and prioritizing VIPs for token acquisition. This aids in refined rate limiting, ensuring system availability in complex scenarios. For example, a banking system uses the customer group classification module to mark agricultural business entities as VIP units and other entities as non-VIP units. During peak grain purchasing seasons, agricultural business entities' customers automatically enter a priority queue, skipping routine verification during token issuance to ensure priority access to token resources. Requests from other entities are rejected during peak business periods.

[0105] Specifically, the customer group classification module is located at the very front of the filtering channel and is the first processing unit when a request enters without a usable token. The customer group classification module is tightly integrated with step S433 as a branch processing logic when a request does not have a token. The customer group classification module is used to classify the requester's customer group. By parsing customer information in the request, such as user ID and membership level, it distinguishes between VIP customers and non-VIP customers, which helps the system to take different processing strategies based on the value or priority of the customer, and achieve more refined rate limiting management.

[0106] Specifically, the final processing module is located downstream of the customer group classification module and performs further processing based on the customer group classification results. The final processing module is directly connected to the output of the customer group classification module, receives the classification results, and decides whether to reject the request or prioritize it based on the results. The final processing module performs final processing on the request based on the output of the customer group classification module. For non-VIP customers, the request is rejected directly to save system resources, while for VIP customers, they are included in the priority queuing queue to wait for the issuance of tokens, ensuring that VIP customers can receive a better service experience.

[0107] Specifically, for requests from non-VIP customers, the rejection unit will directly return a rejection response and terminate the request process.

[0108] Specifically, the priority queuing unit adds VIP customer requests to a dedicated priority queue, waiting for the release of system resources (i.e., tokens). Once a token becomes available, the request is retrieved from this queue for processing.

[0109] Specifically, the processing method for the filtering channel includes the following steps:

[0110] S4331. When a customer sends a request and there is no available token, the request is transferred to the filtering channel. First, the customer group classification module divides the requester into VIP customers and non-VIP customers.

[0111] S4332. After the customer group is divided, it enters the final processing module for final result processing. If it is divided into non-VIP customers, the rejection unit directly rejects the request. If it is divided into VIP customers, it is included in the queue by the priority queuing unit to wait for the issuance of tokens.

[0112] Specifically, the specific division method of S4331 includes the following steps:

[0113] S4331.1 Request Header Parsing: When the client sends a request, it may include the user's identification information, such as user ID, token, membership level, etc., in the corresponding part of the HTTP request header information or other communication protocols. The server first parses this request information to obtain the user's basic identity data.

[0114] S4331.2 User Information Verification: Use the parsed user ID or Token to verify the user's identity in the server's user information system. During the verification process, it can check whether the user exists in the database and whether the Token has expired, etc.

[0115] S4331.3 VIP Status Judgment: After the user information is verified, determine whether the user is a VIP customer based on the membership level field or other fields indicating VIP status in the user information. If the user is a VIP customer, record their VIP status and prepare to send their request to the priority processing queue. If the user is not a VIP, prepare to proceed with the subsequent non-VIP processing.

[0116] Specifically, the operation method of S4332 includes the following steps:

[0117] S4332.1, Non-VIP customer request processing: For non-VIP customer requests, if there is no available token, a rejection response will be returned directly through the rejection unit, which may include a retry suggestion time. At the same time, relevant logs can be recorded on the server side for subsequent analysis and optimization.

[0118] S4332.2 VIP Customer Request Processing: For VIP customer requests, if there is no available token, the request is added to the queue in the priority queuing unit. The priority queuing unit can manage the VIP customer request queue according to certain strategies, such as FIFO or priority queues, to ensure that VIP customer requests can be processed first when tokens are released. VIP customer requests in the queue can periodically check token availability, and once a token is available, the request is immediately taken out of the queue for processing.

[0119] Specifically, the request processing involves the system first parsing the channel and dimension information in the request when a client request arrives, and then loading the corresponding rules for verification. If the request conforms to the flow control rules and there is an available token, the request is allowed to continue processing. If it does not conform to the rules and there is no available token, the request is processed according to the policy in the filtering channel, such as rejecting the request or queuing it first.

[0120] The above description is only the best implementation method adopted by the present invention in combination with current practical needs, but the scope of protection of the present invention is not limited thereto.

Claims

1. A fine-grained rate limiting method for distributed systems, characterized in that, Includes the following steps: S1. Divide the system into functional granularity and main granularity: S11 divides the system's functional modules into different applications, with each application associated with a different product, and each product associated with a different API; S12, in addition to the detailed general API, also divides DUBBO services into a dimension; S13, determine the channel and user entity based on the requester; S2. Configure dual-channel and multi-dimensional verification rules: S21, select one or both of the application channel and the user channel; S22, choose one from product dimension, API dimension, channel dimension and microservice dimension; S23, channels and dimensions combine to form a flow control rule; S231. If both channels are selected, then flow control will be applied to all requests. S232. If only a single channel is selected, then flow control will be applied to all dimensions under that channel. S233. If only a single dimension is selected, then traffic control will be applied to all user channels. S234. After creating flow control rules based on channels and dimensions, configure filters, i.e., verification rules, for high-precision control. S24, persist the flow control rules or store them using a caching system; S3, client-side encapsulation of channel and dimension attributes; S4. Automatically match relevant channel-level flow control rules based on the public information requested by the client: S41, based on the client's request content, parse out the corresponding channel information and dimension information; S42, Load rule information; S43, record request information and verify rule information; S431. If the request fails, record the number of errors in the distributed cache storage system; if the request succeeds, proceed to the next step. S432. Based on the channel and dimension information in the request, match the response processor, and then attempt to retrieve the specified token from the caching system; S433. If there is a usable token, consume one token; if there is no usable token, proceed to the filtering channel for processing. The processing method for the filter channel includes the following steps: S4331. When a customer sends a request and there is no available token, the request is transferred to the filtering channel. First, the customer group classification module divides the requester into VIP customers and non-VIP customers. S4332. After the customer group is divided, it enters the final processing module for final result processing. If it is divided into non-VIP customers, the rejection unit directly rejects the request. If it is divided into VIP customers, it is included in the queue by the priority queuing unit to wait for the issuance of tokens. Once a token is available, the request is immediately taken out of the queue for processing. S44 processes client requests based on the verification results.

2. The fine-grained rate limiting method for a distributed system according to claim 1, characterized in that, The application described in step S11 is the first level of system function granularity; the product is the second level of system function granularity; and the API is the third level of system function granularity.

3. The fine-grained rate limiting method for a distributed system according to claim 1, characterized in that, The method for loading rule information in S42 includes the following steps: S421. Before persisting or storing the flow control rules in step S24, load the flow control rules into the real-time operation of the flow control module. S422. Classify based on channel information and dimension information during loading; S423. Based on the rule information, load the specified number of tokens into the caching system; S424. Obtain the latest flow control rules from the persistent storage and caching system and check for updates. When loading new rules, classify them by channel and dimension information, replace or add them to the current rule set, update the token count of the caching system to match the new rules, and broadcast or notify the relevant flow control modules and service instances after updating the cache.

4. The fine-grained rate limiting method for a distributed system according to claim 1, characterized in that, The filtering channel in step S433 includes a customer group classification module, which includes a VIP unit and a non-VIP unit. The customer group classification module is connected to a final processing module when powered on, and the final processing module includes a rejection unit and a priority queuing unit.

5. A fine-grained rate limiting method for a distributed system according to claim 4, characterized in that, The customer group classification module is located at the front end of the filtering channel and is used to classify the requester's customer group by parsing the customer information in the request. The final processing module is located downstream of the customer group classification module and is directly connected to the output of the customer group classification module. It determines whether to reject the request or prioritize it based on the classification result of the customer group classification module.

6. A fine-grained rate limiting method for a distributed system according to claim 5, characterized in that, The method by which the customer group classification module divides requesters into VIP and non-VIP groups includes the following steps: A. Parse user identification information; B. Verify user identity; C. Determine VIP status based on the membership level field.

7. A fine-grained rate limiting method for a distributed system according to claim 1, characterized in that, S4332 includes the following steps: S4332.1, Non-VIP customer request processing: For requests from non-VIP customers, if there is no available token, a denial-of-service response will be returned directly through the rejection unit; S4332.2 VIP Customer Request Processing: For VIP customer requests, if there are no available tokens, the request is added to the queue in the priority queuing unit. The priority queuing unit manages the VIP customer request queue and ensures that VIP customer requests can be processed first when tokens are released. The VIP customer requests in the queue periodically check token availability.

Images