Hotspot parameter flow limiting method and device, storage medium, equipment and program product
By performing real-time traffic statistics and dynamic rate limiting strategies on the request parameters of access requests, the problem of excessive consumption of system resources caused by hot parameters in high-concurrency scenarios is solved, and the efficient and stable operation of the service is achieved.
Patent Information
- Application Number
- CN202410572258.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-05-09
- Publication Date
- 2025-11-11
AI Technical Summary
Existing technologies lack fine-grained management of hot parameters in high-concurrency scenarios, leading to excessive and concentrated consumption of system resources, resulting in response delays and service crashes.
By performing real-time traffic statistics on the request parameters of access requests, hot parameters are identified, and rate limiting operations are dynamically implemented based on the rate limiting policies configured in the interface or real-time traffic, CPU utilization, and average response time. This includes cluster rate limiting mode and single-machine rate limiting mode, enabling fine-grained management of hot parameters.
It enables rapid identification and refined management of hotspot parameters, ensuring that the service maintains efficient and stable operation under different traffic pressures and avoiding system crashes.
Smart Images

Figure CN120935113A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, specifically to a hotspot parameter current limiting method, apparatus, storage medium, device, and program product. Background Technology
[0002] With the rapid development of internet services, ensuring service stability and efficiency is one of the key challenges in system design for today's high-concurrency internet applications. Especially for applications handling a large number of user requests, hot parameters (i.e., specific request parameters that are frequently accessed) can lead to excessive and concentrated consumption of system resources, causing system response delays or even service crashes. To solve this problem and ensure the efficient and stable operation of services, developing an advanced rate limiting strategy is particularly important.
[0003] Current technical solutions mostly focus on directly detecting backend server resource usage to trigger rate limiting policies. While these methods can alleviate server load pressure to some extent, their rate limiting decisions are based on a single criterion and lack the ability to manage hotspot parameters in a refined manner. Summary of the Invention
[0004] This application provides a hotspot parameter rate limiting method, apparatus, storage medium, device, and program product. By performing real-time traffic statistics on the request parameters corresponding to access requests, hotspot parameters can be quickly identified and finely managed. Based on the configuration of the interface corresponding to the hotspot parameter, rate limiting operations can be dynamically implemented to ensure the efficient and stable operation of the service.
[0005] On one hand, embodiments of this application provide a hotspot parameter rate limiting method, the method comprising:
[0006] Obtain the request parameters corresponding to each of the multiple pending access requests;
[0007] Traffic statistics are performed on the request parameters corresponding to each access request to obtain the query rate per second value corresponding to each request parameter;
[0008] The request parameters whose query rate per second reaches a first threshold are identified as hotspot parameters.
[0009] When the interface corresponding to the hotspot parameter is configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to the first rate limiting strategy, whereby the first rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the rate limiting configuration information; or
[0010] When the interface corresponding to the hotspot parameter is not configured with the rate limiting configuration information, rate limiting management is performed on the hotspot parameter according to the second rate limiting strategy. The second rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the query rate per second, CPU utilization, and average response time corresponding to the hotspot parameter.
[0011] On the other hand, embodiments of this application provide a hotspot parameter current limiting device, the device comprising:
[0012] The acquisition unit is used to obtain the request parameters corresponding to each access request from multiple access requests to be processed;
[0013] The statistics unit is used to perform traffic statistics on the request parameters corresponding to each access request to obtain the query rate per second value corresponding to each request parameter.
[0014] The determining unit is used to determine the request parameters whose query rate per second reaches a first threshold as hotspot parameters;
[0015] The first rate limiting unit is configured to manage rate limiting for the hotspot parameter according to a first rate limiting strategy when the interface corresponding to the hotspot parameter is configured with rate limiting information. The first rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the rate limiting configuration information; or
[0016] The second rate limiting unit is used to manage the rate limiting of the hotspot parameter according to the second rate limiting strategy when the interface corresponding to the hotspot parameter is not configured with the rate limiting configuration information. The second rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the query rate per second, CPU utilization and average response time corresponding to the hotspot parameter.
[0017] In some embodiments, the first current limiting unit is specifically used for:
[0018] When the interface corresponding to the hotspot parameter is configured with rate limiting configuration information, obtain the rate limiting mode indicated by the rate limiting configuration information;
[0019] When the rate limiting configuration information indicates a cluster rate limiting mode, rate limiting management is performed on the hotspot parameters based on the cluster rate limiting mode. The cluster rate limiting mode is used to instruct the microservice cluster to manage the rate limiting of the hotspot parameters according to the cluster threshold and cluster threshold mode corresponding to the cluster rate limiting mode; or
[0020] When the rate limiting configuration information indicates that the rate limiting mode is the single-machine rate limiting mode, the hotspot parameters are rate-limited based on the single-machine rate limiting mode. The single-machine rate limiting mode is used to instruct each rate limiting proxy module in the microservice cluster to perform rate limiting management on the hotspot parameters according to the single-machine threshold.
[0021] In some embodiments, the cluster threshold mode is one of a single-machine amortization mode or an overall threshold mode;
[0022] The single-machine rate-limiting mode is used to instruct each rate-limiting proxy module in the microservice cluster to share the cluster threshold to obtain a rate-limited value, and to perform rate-limiting management on the hotspot parameters based on the rate-limited value.
[0023] The overall threshold mode is used to instruct the microservice cluster to perform rate limiting on the first part of the traffic corresponding to the hotspot parameter through the token server, and to perform rate limiting on the second part of the traffic corresponding to the hotspot parameter through each rate limiting proxy module in the microservice cluster, based on the cluster threshold.
[0024] In some embodiments, the second current limiting unit is specifically used for:
[0025] When the interface corresponding to the hotspot parameter is not configured with the rate limiting information, the query rate per second, CPU utilization and average response time corresponding to the hotspot parameter are obtained based on a sliding window.
[0026] Obtain the average response time increment between the average response time of the current sliding window corresponding to the hotspot parameter and the average response time of the previous sliding window;
[0027] Hotspot parameters that have an average response time increment that reaches a preset increment and a CPU utilization rate that is greater than a first utilization rate, or hotspot parameters whose CPU utilization rate is greater than a second utilization rate, are identified as candidate rate limiting parameters, wherein the second utilization rate is greater than the first utilization rate.
[0028] Based on the query rate per second value, the CPU utilization rate and the average response time increment corresponding to the candidate rate limiting parameters, the top N candidate rate limiting parameters are selected from the candidate rate limiting parameters, where N is a positive integer greater than 0.
[0029] Rate limiting management is applied to the access requests corresponding to the top N candidate rate limiting parameters.
[0030] In some embodiments, when the second rate limiting unit selects the top N candidate rate limiting parameters from the candidate rate limiting parameters based on the query rate per second value, the CPU utilization, and the average response time increment corresponding to the candidate rate limiting parameters, it is specifically used for:
[0031] The candidate rate limiting parameters are sorted from largest to smallest according to the query rate per second value corresponding to the candidate rate limiting parameters to obtain the sorted candidate rate limiting parameters.
[0032] The number of rate limiting parameters N is determined based on the CPU utilization rate and the average response time increment corresponding to the candidate rate limiting parameters.
[0033] Based on the number of rate limiting parameters N, the top N candidate rate limiting parameters are selected from the sorted candidate rate limiting parameters.
[0034] In some embodiments, when the second rate limiting unit performs rate limiting management on the access requests corresponding to the top N candidate rate limiting parameters, it is specifically used for:
[0035] Query the target query rate per second value corresponding to the Nth candidate rate limiting parameter among the top N candidate rate limiting parameters;
[0036] For access requests corresponding to candidate rate limiting parameters whose query rate per second is greater than half of the target query rate per second among the top N candidate rate limiting parameters, the requests are rejected; or
[0037] For access requests corresponding to candidate rate limiting parameters whose query rate per second value is less than or equal to half of the target query rate per second value among the top N candidate rate limiting parameters, the requests are allowed.
[0038] In some embodiments, the statistical unit is further configured to:
[0039] Store the query rate per second corresponding to each of the aforementioned request parameters into a mapping table data structure;
[0040] The request parameters in the mapping table data structure are updated based on the memory eviction algorithm.
[0041] In some embodiments, the apparatus further includes:
[0042] The sending unit is used to send the hotspot parameters to the management and control platform so as to display the query rate value per second corresponding to the hotspot parameters on the management and control platform.
[0043] In some embodiments, the sending unit is further configured to send the rate limiting management result corresponding to the hotspot parameter to the management platform, so that the management platform can generate rate limiting alarm information for the denied access requests corresponding to the hotspot parameter based on the rate limiting management result.
[0044] In some embodiments, the acquisition unit is further configured to acquire the rate limiting configuration information issued by the management and control platform, wherein the rate limiting configuration information is a hotspot parameter rate limiting rule configured for the target interface.
[0045] In some embodiments, the acquisition unit is specifically used for:
[0046] For an access request to be processed received by an interface configured with the aforementioned rate limiting information, the request parameters corresponding to the access request are obtained from the access request based on the rate limiting configuration information; or
[0047] For an access request to be processed received by an interface that has not configured the rate limiting information, the request parameters corresponding to the access request are obtained from the access request based on the default parameter information.
[0048] On the other hand, an embodiment of this application provides a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the hotspot parameter rate limiting method as described in any of the above embodiments.
[0049] On the other hand, an embodiment of this application provides a computer device, which includes a processor and a memory. The memory stores a computer program, and the processor executes the hotspot parameter rate limiting method as described in any of the above embodiments by calling the computer program stored in the memory.
[0050] On the other hand, an embodiment of this application provides a computer program product, including computer instructions, which, when executed by a processor, implement the hotspot parameter rate limiting method as described in any of the above embodiments.
[0051] This application embodiment obtains the request parameters corresponding to each access request from multiple pending access requests; performs traffic statistics on the request parameters corresponding to each access request to obtain the query rate per second (QPS) value for each request parameter; identifies request parameters whose QPS value reaches a first threshold as hotspot parameters; when the interface corresponding to the hotspot parameter is configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to a first rate limiting strategy, which is a rate limiting rule for hotspot parameters determined based on the rate limiting configuration information; or, when the interface corresponding to the hotspot parameter is not configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to a second rate limiting strategy, which is a rate limiting rule for hotspot parameters determined based on the query rate per second value, CPU utilization, and average response time corresponding to the hotspot parameter. This application embodiment, by performing real-time traffic statistics on the request parameters of each access request, can quickly identify hotspot parameters with abnormally concentrated traffic. This immediacy helps to quickly locate key factors that may affect system stability, providing an accurate data foundation for subsequent traffic control. Based on whether the interfaces corresponding to the hotspot parameters are configured with preset rate limiting rules, the system can automatically switch to the most suitable rate limiting strategy to dynamically implement rate limiting operations. For interfaces with configured rate limiting information, a customized first rate limiting strategy is directly applied for efficient management. For interfaces without configured rate limiting information or with incomplete configuration, an adaptive second rate limiting strategy is activated based on dynamic indicators such as real-time traffic, CPU utilization, and average response time of the hotspot parameters, making rate limiting decisions more comprehensive and scientific. By distinguishing between interfaces with and without configured rate limiting information and applying different rate limiting strategies to each, fine-grained management of hotspot parameters is achieved, ensuring that the service maintains efficient and stable operation under different traffic pressures. Attached Figure Description
[0052] Figure 1 A schematic diagram illustrating the application scenario of the hotspot parameter flow limiting system provided in the application embodiment.
[0053] Figure 2 A flowchart illustrating the hotspot parameter rate limiting method provided in this application embodiment.
[0054] Figure 3 This is a schematic diagram of a first application scenario for the hotspot parameter rate limiting method provided in this application embodiment.
[0055] Figure 4 This is a schematic diagram of a second application scenario for the hotspot parameter rate limiting method provided in the embodiments of this application.
[0056] Figure 5 This is a schematic diagram of a third application scenario for the hotspot parameter rate limiting method provided in the embodiments of this application.
[0057] Figure 6This is a schematic diagram of the hotspot parameter current limiting device provided in the embodiments of this application.
[0058] Figure 7 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0059] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0060] This application provides a method, apparatus, storage medium, device, and program product for hotspot parameter rate limiting. Exemplarily, the hotspot parameter rate limiting method of this application can be executed by a computer device, which can be a terminal or server, etc. The terminal can be a smartphone, tablet, laptop, desktop computer, smart TV, smart speaker, wearable smart device, personal computer (PC), smart vehicle terminal, etc. The terminal can also include a client, which can be a video client, shopping application client, reading application client, browser client, or instant messaging client, etc. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms.
[0061] The embodiments of this application can be applied to scenarios such as artificial intelligence, cloud technology, traffic control, rate limiting, and advertising services.
[0062] First, some of the nouns or terms that appear in the description of the embodiments of this application are explained as follows:
[0063] Artificial Intelligence (AI) is the theory, methods, technology, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. In other words, AI is a comprehensive technology within computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine that can react in a way similar to human intelligence. AI studies the design principles and implementation methods of various intelligent machines, enabling them to have perception, reasoning, and decision-making capabilities. AI technology is a comprehensive discipline involving a wide range of fields, encompassing both hardware and software technologies. Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, pre-trained model technology, operating / interactive systems, and mechatronics. Pre-trained models, also known as large models or foundational models, can be widely applied to downstream tasks in various areas of AI after fine-tuning. AI software technologies mainly include computer vision, speech processing, natural language processing, and machine learning / deep learning.
[0064] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computing, storage, processing, and sharing. It can also be understood as a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies based on the cloud computing business model. These technologies can form resource pools, providing flexible and convenient on-demand access. Backend services of cloud computing systems require substantial computing and storage resources, such as those used by video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will require robust system support, which can only be achieved through cloud computing. Therefore, cloud computing technology will become a crucial support for data processing across different industries. Cloud computing refers to the delivery and usage model of IT infrastructure, meaning obtaining necessary resources through the network in an on-demand and easily scalable manner. In a broader sense, cloud computing refers to the delivery and usage model of services, meaning obtaining necessary services through the network in an on-demand and easily scalable manner. These services can be IT and software related, internet-related, or other services. Cloud computing is the product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.
[0065] Understandably, cloud computing has rapidly developed due to the growth of the internet, real-time data streams, the diversification of connected devices, and the demands for search services, social networks, mobile commerce, and open collaboration. Unlike previous parallel and distributed computing, cloud computing will fundamentally revolutionize the entire internet model and enterprise management model. Similarly, with the research and advancement of artificial intelligence (AI) technology, AI is being researched and applied in multiple fields, such as smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, autonomous driving, drones, robots, smart healthcare, and smart customer service. It is believed that with technological advancements, AI will be applied in even more fields and play an increasingly important role.
[0066] The solutions provided in this application specifically involve artificial intelligence technology and cloud technology such as hotspot parameter rate limiting, which are illustrated in the following embodiments. Detailed descriptions are provided below. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.
[0067] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario for the hotspot parameter rate limiting system provided in this embodiment. The hotspot parameter rate limiting system mainly includes a management platform 10, a microservice cluster 20, and a data storage layer 30. Data interaction can occur between the management platform 10 and the microservice cluster 20, and between the microservice cluster 20 and the data storage layer 30, via a network.
[0068] The management platform 10, a software system or application typically built on cloud computing infrastructure or traditional IT architecture, is used for rate limiting. Its primary purpose is to ensure the stable operation of services within a microservice cluster by limiting the frequency of access to certain resources to prevent potential system overload. The management platform 10 can provide functions such as traffic data reporting, hotspot traffic display, rate limiting policy distribution, and rate limiting alarms.
[0069] The traffic data reporting function is used to receive traffic data reported by each rate limiting proxy module in the microservice cluster 20. This traffic data may include information such as request rate, request type, request source, and query rate per second (QPS) of request parameters. This traffic data can be collected in real time and can provide immediate feedback on the current system traffic status.
[0070] The hotspot traffic display feature provides a user interface for visually displaying traffic details of hotspot parameters for various services. This display helps administrators quickly identify and analyze traffic patterns, enabling them to make corresponding adjustments.
[0071] The rate limiting policy distribution function is used to configure rate limiting rules for hot parameters for the target interface and distribute the rate limiting configuration information corresponding to the configured hot parameter rate limiting rules to the rate limiting proxy module corresponding to the target interface in the microservice cluster 20.
[0072] The rate limiting alarm function is used to generate rate limiting alarm information. When the traffic in the microservice cluster 20 exceeds the preset threshold or triggers other rate limiting conditions, the management platform 10 will issue rate limiting alarm information. For example, based on the rate limiting management results corresponding to hotspot parameters, rate limiting alarm information can be generated for access requests that are denied according to hotspot parameters. These rate limiting alarm information can be sent through various channels, such as telephone, email, SMS, application logs, or integrated into other management tools. The alarm mechanism can help the team to discover potential performance problems or attacks in a timely manner and take corresponding measures.
[0073] The management platform 10 can be deployed on any terminal device with a display screen, such as a personal computer, workstation, laptop, or professional management dashboard. To effectively utilize the functionality of the management platform 10, the terminal typically needs to be connected to the network environment where the microservice cluster resides and have appropriate permissions to receive data, configure rules, and trigger alarms.
[0074] The microservice cluster 20 is used to deploy services for business applications. As the core carrier for deploying these services, the microservice cluster 20 plays a crucial role in large-scale website operations. It contains tens of thousands of microservices, each focused on implementing a specific business function. These microservices collaborate through complex call chains to jointly support the stable operation of the entire business system.
[0075] To handle high-concurrency, high-load business scenarios, the microservice cluster 20 possesses powerful elastic scaling capabilities. It can dynamically adjust the number of instances for each service based on system load pressure. When the load increases, it can automatically expand service instances to improve processing capacity; when the load decreases, it can automatically shrink instances to save resources. This flexible scaling mechanism ensures that the microservice cluster always maintains optimal performance.
[0076] In the microservice cluster 20, corresponding rate-limiting agent modules can be deployed in each service. These agent modules are tightly integrated with the business services, forming a rate-limiting protection system for the microservices. The main functions of the rate-limiting agent modules include traffic statistics, parameter tracking, and rate-limiting policy execution.
[0077] The traffic statistics function enables the rate-limiting proxy module to collect and analyze key metrics such as queries per second (QPS) and thread count for critical interfaces in the service in real time. This statistical data not only helps administrators understand the service's operational status and performance bottlenecks but also provides crucial information for formulating subsequent rate-limiting strategies.
[0078] Parameter tracking is used to more accurately identify frequently called parameters. Through tracking technology, the rate limiting proxy module can identify which parameters are called most frequently, thus providing data support for formulating rate limiting strategies for these frequently called parameters.
[0079] Among these functions, rate limiting strategy execution is one of the core features of the rate limiting proxy module. When traffic reaches or exceeds a preset threshold, the rate limiting proxy module will perform corresponding operations based on the configured hotspot parameter rate limiting rules, such as allowing requests, rejecting requests, and implementing circuit breaker and degradation strategies. For example, when the query rate per second of a hotspot parameter is greater than or equal to the threshold set by the hotspot parameter rate limiting rule, the request will be rejected; when the query rate per second of a hotspot parameter is less than the threshold set by the hotspot parameter rate limiting rule, the request will be allowed. When the service call failure rate remains high for a period of time, a circuit breaker and degradation strategy can be implemented, that is, temporarily interrupting service calls to avoid further damage to the system. At the same time, degradation strategies can also be implemented, such as returning default values or simplified responses, to ensure service continuity.
[0080] The microservice cluster is typically deployed on a server, which manages and schedules the services uniformly. The server provides powerful computing capabilities and storage resources, ensuring the stable operation of the microservice cluster. Simultaneously, through server management, administrators can easily control and manage each service within the microservice cluster, ensuring they are always in optimal condition.
[0081] The data storage layer 30 provides necessary persistent storage services for the traffic data collected by the various rate-limiting proxy modules in the microservice cluster 20. For example, this data storage layer may include relational databases (such as MySQL) and time-series databases (such as InfluxDB).
[0082] Relational databases are commonly used to store structured data due to their powerful transaction processing capabilities and mature data consistency models. In rate limiting scenarios, MySQL can be used to store rate limiting configuration information for each service or interface, traffic statistics summary data, and rate limiting event records. This data typically has clear field relationships and is suitable for expression using table structures. The advantage of relational databases lies in their support for complex SQL queries, facilitating data analysis and report generation.
[0083] Time-series databases are specifically designed for efficiently processing timestamped data sequences, making them ideal for storing and querying large amounts of real-time traffic statistics. Queries per second (QPS) and thread counts reported by rate-limiting proxy modules are typical examples of time-series data. Databases like InfluxDB optimize write and query speeds, enabling fast handling of high-concurrency writes and providing low-latency data retrieval.
[0084] This application provides a hotspot parameter rate limiting method, which can be executed by a terminal or a server, or by both a terminal and a server. This application uses the hotspot parameter rate limiting method executed by a server as an example for illustration.
[0085] Please see Figures 2 to 5 , Figure 2 This is a flowchart illustrating the hotspot parameter rate limiting method provided in an embodiment of this application. Figures 3 to 5 These are schematic diagrams illustrating application scenarios of the hotspot parameter rate limiting method provided in the embodiments of this application. This method can be applied to, for example... Figure 1 The microservice cluster 20 deployed on the server shown may include the following steps 110 to 150:
[0086] Step 110: Obtain the request parameters corresponding to each access request from the multiple access requests to be processed.
[0087] For example, the various rate-limiting proxy modules in the microservice cluster 20 can monitor key or specific interfaces in the service in real time to receive access requests from clients (such as browsers, mobile applications, or other services). These access requests can be Hypertext Transfer Protocol (HTTP) requests, Application Programming Interface (API) requests, etc.
[0088] For each received access request, the request content needs to be parsed to extract the request parameters. Request parameters may include a Uniform Resource Locator (URL) path, a query string, form data in the request body, a JSON object, or other types of data. JSON is a lightweight data-interchange format.
[0089] In some embodiments, obtaining request parameters corresponding to each access request from a plurality of pending access requests includes:
[0090] For an interface configured with rate limiting information that receives an pending access request, the request parameters corresponding to the access request are obtained from the access request based on the rate limiting configuration information; or
[0091] For pending access requests received by interfaces without configured rate limiting information, the request parameters corresponding to the access request are obtained from the access request based on the default parameter information.
[0092] The process of obtaining request parameters differs depending on whether the interface has rate-limiting configuration information configured. For interfaces with configured rate-limiting information, the corresponding request parameters in the access request are accurately extracted based on this configuration information. Rate-limiting configuration information may include the name, type, and location of parameters that need attention, to ensure that the system can accurately capture critical request parameters. For example, request parameters obtained based on rate-limiting configuration information in hotspot rate-limiting rules can come from the HTTP request header or request body. For example, the obtained request parameter could be a user identifier (uid).
[0093] For interfaces without configured rate limiting information, request parameters are extracted based on default parameters. These default parameters are typically preset by the system according to general specifications or business characteristics, used to cover interfaces without specific configuration information. For example, default parameters can be the most representative, meaningful, and easy-to-implement data tracking parameters. This ensures that the system can still extract necessary request parameters even without explicit configuration. Commonly used default parameters may include the client's Internet Protocol (IP) address, login user identifier (ID), and user terminal device identifier (ID).
[0094] In some embodiments, the method further includes:
[0095] Obtain the rate limiting configuration information issued by the management platform. The rate limiting configuration information consists of rate limiting rules for hotspot parameters configured for the target interface.
[0096] For example, hotspot parameter rate limiting rules can be configured for the target interface in the management platform 10, and the rate limiting configuration information corresponding to the configured hotspot parameter rate limiting rules can be sent to the rate limiting proxy module corresponding to the target interface.
[0097] For example, such as Figure 3 The diagram shows the configuration interface for hotspot parameter rate limiting rules. Rate limiting configuration information may include resource name, rate limiting mode (such as QPS mode), parameter position, key, cluster threshold, option button for whether to cluster, option button for cluster threshold mode (e.g., single-machine sharing or overall threshold), option button for failure degradation, interface configuration entry for advanced options, add button or cancel button, etc.
[0098] For example, the configuration items for the hotspot parameter rate limiting rule are explained below:
[0099]
[0100] In some embodiments, before obtaining the request parameters corresponding to each access request from the multiple access requests to be processed, the method further includes:
[0101] Retrieve multiple pending access requests;
[0102] Multiple access requests are filtered based on a filter to obtain multiple filtered access requests;
[0103] Retrieve the request parameters for each access request from the multiple pending access requests, including:
[0104] Retrieve the request parameters corresponding to each access request from the filtered multiple access requests.
[0105] For example, before retrieving request parameters, it may be necessary to filter the request. This can be done using one or more filters, which can initially filter out the initial parameters of the access request based on specific filtering rules. For example, these filtering rules could be content-based, such as examining data in the access request, like the URL, request headers, or request body, to ensure they conform to the expected format and values. Alternatively, they could be frequency-based control rules, such as limiting the frequency of requests from the same client to prevent service abuse. Initial parameters could include query parameters, form data, path parameters, information in request headers, etc.
[0106] After the filtering process is complete, the request parameters are extracted from the initial parameters of the filtered access requests.
[0107] Step 120: Perform traffic statistics on the request parameters corresponding to each access request to obtain the query rate per second value corresponding to each request parameter.
[0108] In some embodiments, when performing traffic statistics on the request parameters corresponding to each access request to obtain the query rate per second value corresponding to each request parameter, the method further includes:
[0109] Store the query rate per second corresponding to each request parameter into a mapping table data structure;
[0110] The request parameters in the mapping table data structure are updated based on the memory eviction algorithm.
[0111] In some embodiments, updating the request parameters in the mapping table data structure based on a memory eviction algorithm includes:
[0112] When the number of request parameters in the mapping table data structure reaches the mapping table size threshold, the request parameters to be evicted in the mapping table data structure are determined based on the memory eviction algorithm.
[0113] Remove the request parameters to be discarded from the mapping table data structure;
[0114] Store the query rate per second corresponding to the request parameters to be stored into the mapping table data structure.
[0115] In this embodiment, the traffic statistics process includes not only calculating the queries per second (QPS) for the request parameters, but also storing the calculation results in a mapping table (Map) data structure and updating the parameters of the mapping table (Map) based on a memory eviction algorithm. This design ensures that the system can observe the traffic status of each request parameter in real time and accurately, while avoiding excessive consumption of memory resources.
[0116] For example, during traffic statistics, the system calculates the queries per second (QPS) for each different request parameter individually and stores these QPS values in a mapping table, such as a Map<parameter key, QPS>. The parameter key in the mapping table (Map) is the identifier of the request parameter (such as a user identifier uid), and the value is the corresponding QPS value. This data structure allows the system to quickly find and update traffic information for each request parameter.
[0117] For example, the mapping table data structure can be cached in the memory of the rate limiting proxy module, and can also be sent to the data storage layer 30 for persistent storage later.
[0118] However, as system runtime increases, the number of request parameters stored in the mapping table may continuously increase, consuming significant memory resources. To address this issue, the system employs a parameter update mechanism based on a memory eviction algorithm. When the number of request parameters in the mapping table reaches a set mapping table size threshold, a memory eviction algorithm is triggered. For example, this algorithm can be a Least Recently Accessed (LRU) memory eviction policy. Based on the LRU memory eviction policy, it determines which request parameters need to be removed from the mapping table. Then, the system deletes these evictionable request parameters from the mapping table and releases the corresponding memory space.
[0119] While removing old parameters, the newly received request parameters and their corresponding QPS values are also stored in the mapping table. In this way, the mapping table keeps abreast of the latest and most active request parameters, providing accurate basic data for subsequently identifying hot parameters and formulating corresponding rate limiting strategies.
[0120] Step 130: Request parameters whose query rate per second reaches the first threshold are identified as hot parameters.
[0121] The system sets a first threshold, which is determined based on a comprehensive consideration of historical data, business needs, and system capacity. This first threshold is used to distinguish between normal traffic and high-traffic requests.
[0122] First, the system iterates through and compares the request parameters (parameter keys) and their corresponding QPS values stored in the mapping table. The parameter keys in the mapping table are typically identifiers of the request parameters (such as user identifiers, uid), while the values are the corresponding QPS values. These QPS values reflect the real-time traffic of each request parameter and are crucial for determining whether a parameter is a hotspot.
[0123] During the iteration, the system checks whether the QPS value of each request parameter has reached the set first threshold. When the QPS value of a request parameter exceeds the first threshold, the system considers that request parameter to be a hot parameter because it may be experiencing a large number of requests, potentially putting pressure on the system.
[0124] Step 140: When the interface corresponding to the hotspot parameter is configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to the first rate limiting strategy. The first rate limiting strategy is the rate limiting rule for the hotspot parameter determined based on the rate limiting configuration information.
[0125] For example, when a rate-limiting configuration is detected for an interface corresponding to a hot parameter, a rate-limiting management mechanism is triggered. The core of this mechanism lies in precisely managing the rate limit for hot parameters based on a primary rate-limiting strategy. This primary rate-limiting strategy is not fixed; it is dynamically generated based on the rate-limiting configuration information, ensuring the flexibility and specificity of the rate-limiting rules for hot parameters.
[0126] In some embodiments, when the interface corresponding to the hotspot parameter is configured with rate limiting information, rate limiting management of the hotspot parameter is performed according to the first rate limiting strategy, including:
[0127] When the interface corresponding to the hotspot parameter is configured with rate limiting information, obtain the rate limiting mode indicated by the rate limiting configuration information;
[0128] When the rate limiting configuration information indicates a cluster rate limiting mode, rate limiting management is performed on hot parameters based on the cluster rate limiting mode. The cluster rate limiting mode is used to instruct the microservice cluster to manage the rate limiting of hot parameters according to the cluster threshold and the cluster threshold mode corresponding to the cluster rate limiting mode; or
[0129] When the rate limiting configuration information indicates that the rate limiting mode is single-machine rate limiting mode, rate limiting management of hot parameters is performed based on the single-machine rate limiting mode. The single-machine rate limiting mode is used to instruct each rate limiting proxy module in the microservice cluster to manage the rate limiting of hot parameters according to the single-machine threshold.
[0130] In some embodiments, the cluster threshold mode is either a single-machine amortization mode or an overall threshold mode;
[0131] The single-machine rate-limiting mode is used to instruct each rate-limiting proxy module in the microservice cluster to share the cluster threshold to obtain the rate-limited value, and to manage rate-limiting of hot parameters based on the rate-limited value.
[0132] The overall threshold mode is used to instruct the microservice cluster to rate-limit the first part of the traffic corresponding to the hot parameters through the token server, and to rate-limit the second part of the traffic corresponding to the hot parameters through the various rate-limiting proxy modules in the microservice cluster, based on the cluster threshold.
[0133] During rate limiting management, the rate limiting mode specified in the rate limiting configuration information is retrieved. There are two main types of rate limiting modes: cluster rate limiting mode and single-machine rate limiting mode. Each mode has its advantages and is suitable for different scenarios.
[0134] For example, cluster-based rate limiting focuses on traffic control across the entire microservice cluster. When using cluster-based rate limiting, hotspot parameters are rate-limited based on the corresponding cluster threshold and the cluster threshold mode. The cluster threshold is typically set based on the overall system load capacity and business requirements, while the cluster threshold mode further refines the rate limiting strategy. For example, the cluster threshold mode can be a single-machine amortization mode or an overall threshold mode. In single-machine amortization mode, the rate limiting proxy modules in the microservice cluster share the cluster threshold, ensuring that each flow proxy module bears an appropriate traffic load. In overall threshold mode, traffic is distributed to different processing paths based on the cluster threshold; some traffic is rate-limited through a token server, while other traffic is rate-limited through the various rate limiting proxy modules in the microservice cluster.
[0135] like Figure 4 As shown, taking the overall threshold mode in the cluster rate limiting mode as an example, a microservice cluster with N (e.g., N is 10) containers (PODs), for example, the containers (PODs) can be the above... Figure 1The aforementioned rate-limiting proxy module has a cluster rate-limiting threshold of 100 QPS for the cluster rate-limiting mode. Most of the traffic in the hotspot parameters (e.g., 90% of the total traffic across all service instances corresponding to the cluster threshold) is directly handled by the single-machine rate-limiting mode. For example, for these 10 PODs, each POD receives an average of 9 QPS of traffic. The remaining small portion of traffic (e.g., 10%) is centrally controlled through a token server; for example, 10 QPS of traffic shares the token server. In this case, the cluster rate-limiting mode acts as a buffer for the single-machine rate-limiting mode. When the total traffic of the 10 PODs under single-machine rate-limiting reaches 90 QPS, the remaining 10 QPS of traffic can go through the token server corresponding to the cluster rate-limiting mode, meaning these 10 PODs share the 10 QPS of cluster rate-limiting. This method reduces the request pressure on the token server by more than 90%, reducing the risk of external dependencies on the system.
[0136] Unlike cluster-based rate limiting, single-machine rate limiting focuses more on traffic control for individual rate limiting proxy modules. In single-machine rate limiting mode, each rate limiting proxy module manages the rate of access to hotspot parameters based on its corresponding single-machine threshold. The single-machine threshold is usually set based on the processing capacity and load of each rate limiting proxy module, ensuring that each rate limiting proxy module maintains high performance while handling reasonable traffic pressure.
[0137] It is worth noting that, in practical applications, the system also provides a failure degradation mechanism to cope with various complex scenarios. When the token server for cluster rate limiting becomes unavailable, the system will automatically degrade from cluster rate limiting mode to single-machine rate limiting mode, ensuring the continuity and stability of the rate limiting mechanism.
[0138] In summary, step 140 combines the advantages of cluster-based and single-machine rate limiting modes to achieve precise rate limiting management of hot parameters. Simultaneously, by optimizing the rate limiting performance of the cluster mode, the request pressure on the token server is reduced, improving the overall performance and stability of the system.
[0139] Step 150: When the interface corresponding to the hotspot parameter is not configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to the second rate limiting strategy. The second rate limiting strategy is the rate limiting rule for the hotspot parameter determined based on the query rate per second, CPU utilization and average response time corresponding to the hotspot parameter.
[0140] For example, in real-world applications, there are often numerous microservices, each with many interfaces. It's impractical to configure rate limiting rules for every interface. Furthermore, the rate limiting thresholds obtained through load testing may differ from those in actual scenarios, leading to inaccurate rate limiting configurations. Adaptive rate limiting controls application ingress traffic from a holistic perspective. It combines several metrics, such as application Central Processing Unit (CPU) utilization and average response time (RT), with an adaptive secondary flow control strategy to limit the access rate of hotspot parameters (e.g., frequent access from a specific IP address used for fraudulent transactions). This balances system ingress traffic with system load, allowing the system to operate at maximum throughput without impacting access for normal users on non-hotspot parameters.
[0141] In some embodiments, when the interface corresponding to the hotspot parameter is not configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to the second rate limiting strategy, including:
[0142] When the interface corresponding to the hotspot parameter is not configured with rate limiting information, the query rate per second, CPU utilization and average response time corresponding to the hotspot parameter are obtained based on the sliding window.
[0143] Get the average response time increment between the average response time of the current sliding window corresponding to the hotspot parameter and the average response time of the previous sliding window;
[0144] Hot parameters that have an average response time increment that reaches a preset increment and a CPU utilization rate that is greater than a first utilization rate, or hot parameters that have a CPU utilization rate that is greater than a second utilization rate, are identified as candidate rate limiting parameters, wherein the second utilization rate is greater than the first utilization rate.
[0145] Based on the query rate per second, CPU utilization, and average response time increment corresponding to the candidate rate limiting parameters, select the top N candidate rate limiting parameters, where N is a positive integer greater than 0.
[0146] Rate limiting is implemented for the access requests corresponding to the top N candidate rate limiting parameters.
[0147] In practical applications, this dynamic adaptive rate limiting mechanism effectively manages and protects interfaces without explicitly defined rate limiting rules by comprehensively analyzing multiple dimensions of interface access (such as query frequency, system resource consumption, response time changes, etc.), thereby ensuring the stability and performance of the system.
[0148] For interfaces without configured rate limiting information, step 110 will extract request parameters based on default parameter information. Default parameter information is typically preset by the system according to general specifications or business characteristics, used to cover interfaces without specific configuration information. For example, default parameters can be the most representative, most meaningful, and convenient parameters for data tracking. This ensures that the system can still extract necessary request parameters even without explicit configuration. Commonly used default parameters may include the client's Internet Protocol Address (IP) address, login user identifier (ID), and user terminal device identifier (ID).
[0149] Then, for the hotspot parameters corresponding to interfaces without configured rate limiting information, three key metrics corresponding to the hotspot parameters are obtained based on a sliding window: query rate per second (GPS), CPU utilization, and average response time (RT). The sliding window allows the system to collect and update these metrics at fixed time intervals (such as 1 second, 5 seconds, etc.), thereby reflecting the current status of the system in a timely manner.
[0150] The algorithm retrieves the average response time increment between the current sliding window's average response time and the previous sliding window's average response time for the hotspot parameters. This increment reflects the trend in system response time and is a crucial indicator for determining whether the system is under pressure or experiencing anomalies.
[0151] Then, hotspot parameters that meet any of the following conditions will be identified as candidate rate limiting parameters, and these candidate rate limiting parameters will be considered as potential rate limiting targets:
[0152] The average response time increment reaches the preset increment (e.g., 30%), and the CPU utilization is greater than the first utilization (e.g., 80%). This indicates that the system response time has become significantly longer and the CPU load is high, which may be due to certain hotspot parameters.
[0153] When CPU utilization exceeds the second highest utilization (e.g., 90%), it indicates that the system CPU load is already very high. Even if the average response time increment does not reach the preset increment, it is necessary to perform rate limiting on hotspot parameters to reduce system load.
[0154] Then, after determining the candidate rate-limiting parameters, they are sorted according to their corresponding QPS, CPU utilization, and average response time increment, and the top N candidate rate-limiting parameters are selected as the final rate-limiting targets. Here, N is a configurable positive integer representing the number of hot parameters that the system wants to prioritize.
[0155] Then, rate limiting management is applied to the access requests corresponding to the top N candidate rate limiting parameters.
[0156] In actual deployment, preset incremental thresholds (such as 30%) and CPU utilization thresholds (80%, 90%) can be dynamically adjusted based on historical data and system performance management to better adapt to system requirements under different time periods or load conditions.
[0157] The system can continuously collect data on the effects of rate limiting operations (such as improved system stability and changes in user request success rates) and use machine learning algorithms to continuously optimize rate limiting strategies, such as adjusting threshold settings and optimizing parameter selection logic, to achieve more intelligent adaptive rate limiting.
[0158] By combining cloud technology, when a sustained high load is detected, the system can not only protect core services through rate limiting, but also trigger automatic resource scaling, such as increasing the number of instances or adjusting instance specifications, to further enhance the system's processing capacity and stability.
[0159] In some embodiments, the top N candidate rate limiting parameters are selected from the candidate rate limiting parameters based on the query rate per second, CPU utilization, and average response time increment corresponding to the candidate rate limiting parameters, including:
[0160] Sort the candidate rate limiting parameters from largest to smallest according to their corresponding query rate per second values to obtain the sorted candidate rate limiting parameters.
[0161] The number of rate limiting parameters N is determined based on the CPU utilization and average response time increment corresponding to the candidate rate limiting parameters.
[0162] Based on the number of rate limiting parameters N, the top N candidate rate limiting parameters are selected from the sorted candidate rate limiting parameters.
[0163] For example, determining the top N hot parameters that need to be rate-limited, i.e., identifying the top N candidate rate-limiting parameters, is a dynamic and intelligent process. It combines multiple performance metrics (queries per second, CPU utilization, and average response time increment) to comprehensively evaluate the potential impact of hot parameters and select the parameters that need to be rate-limited first.
[0164] First, sort the candidate rate-limiting parameters from largest to smallest based on their corresponding queries per second (QPS) values. The purpose of this step is to identify the parameters accessed most frequently, as they typically have the greatest impact on system performance.
[0165] Then, the number of rate limits, N, is determined based on the CPU utilization and average response time (RT) increments corresponding to the candidate rate-limiting parameters. A dynamic calculation formula is used here, which takes the RT change rate and CPU utilization as input and outputs a value of N that is positively correlated with them. The value of the rate-limiting number N is positively correlated with the RT change rate and CPU utilization. Specifically, the formula for calculating N is:
[0166] N = k * δRT * (1 / (1 - CPU utilization));
[0167] Here, k is a constant estimated based on stress testing, representing the system's baseline performance and current-limiting sensitivity.
[0168] Wherein, δRT is the rate of change of RT, which is the ratio between the average response time of the current sliding window and the average response time of the previous sliding window. For example, if RT increases by 80% (i.e., the average response time increment is 80%), then δRT = 1.8; for example, if RT decreases by 20% (i.e., the average response time increment is -20%), then δRT = 0.8.
[0169] Here, CPU utilization is the current CPU utilization of the system, which is a value between 0 and 1 (for example, 80% CPU utilization is represented as 0.8). For example, when CPU utilization = 80%, the relevant term 1 / (1-CPU utilization) = 5, and when CPU utilization = 90%, the relevant term 1 / (1-CPU utilization) = 10.
[0170] Then, based on the determined value of N, the top N candidate current limiting parameters are selected from the sorted candidate parameters as the final current limiting targets. These top N candidate current limiting parameters will be subject to current limiting management to reduce their impact on system performance.
[0171] In some embodiments, rate limiting management is performed on access requests corresponding to the top N candidate rate limiting parameters, including:
[0172] Query the target query rate per second value corresponding to the Nth candidate rate limiting parameter among the top N candidate rate limiting parameters;
[0173] For access requests corresponding to candidate rate limiting parameters whose query rate per second is greater than half of the target query rate per second among the top N candidate rate limiting parameters, the requests will be rejected; or
[0174] For access requests corresponding to candidate rate limiting parameters whose query rate per second value is less than or equal to half of the target query rate per second value among the top N candidate rate limiting parameters, the requests will be allowed.
[0175] First, the top N candidate rate-limiting parameters were determined through analysis. Next, the target query rate per second (e.g., Mqps) for the Nth candidate parameter was queried and used as a baseline for rate limiting. In the example, if the QPS of the Nth parameter is 100 qps, then this target query rate per second (e.g., Mqps) becomes a critical threshold.
[0176] Based on the target query rate per second (e.g., Mqps), a differentiated rate limiting strategy was adopted. For access requests corresponding to parameters whose QPS exceeded half of Mqps (i.e., exceeding 50 QPS in this example) among the top N candidate rate limiting parameters, the system directly rejected them, thereby quickly reducing the resource consumption of these high-load access requests. Conversely, for access requests corresponding to parameters whose QPS was less than or equal to 50 QPS among the top N candidate rate limiting parameters, they were allowed to proceed. This effectively alleviated system pressure while ensuring that some reasonable requests were processed.
[0177] For example, if the QPS value of the top N hottest parameter is Mqps, a rate-limiting rejection policy is applied to requests with a QPS exceeding Mqps / 2 for the top N parameters. For instance, if N=10 and Mqps=100qps among the top N hottest parameters, meaning the 10th highest QPS in the system is 100qps, rate-limiting should be applied to requests for the top 10 hottest parameters, limiting the QPS of all requests to 50qps. Through continuous adaptive adjustments, hottest parameter requests will be suppressed, thus protecting system stability and not affecting normal requests from non-hottest users.
[0178] In some embodiments, the method further includes:
[0179] The parameters other than the top N candidate rate limiting parameters in the hotspot parameters are identified as parameters to be released;
[0180] Allow access requests corresponding to the parameters to be allowed.
[0181] For parameters awaiting approval—those not selected as top N candidates for rate limiting among the hot parameters—the system adopts an open policy, allowing their corresponding access requests to pass normally. This measure helps maintain service fairness and overall user experience, avoiding the negative effects of a "one-size-fits-all" rate limiting approach.
[0182] In some embodiments, the method further includes:
[0183] Send the hotspot parameters to the management platform so that the query rate per second corresponding to the hotspot parameters can be displayed on the management platform.
[0184] The process begins by collecting traffic data for hotspot parameters, typically including the queries per second (QPS) for each parameter. This data is collected in real time by the rate-limiting proxy module and persistently stored every second (meaning all traffic data acquired per second is stored in the data storage layer) to ensure data accuracy and reliability.
[0185] Then, these hotspot parameters and their corresponding QPS values are sent to the management and control platform. The management and control platform is an interface for centrally managing, controlling, and displaying the system status. It can receive data from various services and provide visualization and analysis functions.
[0186] The management platform can include a dedicated interface to display traffic data for hotspot parameters. For example, bar charts or line graphs can be used to display QPS values for these parameters, allowing administrators to intuitively understand the system's traffic distribution and hotspot conditions.
[0187] For example, such as Figure 5 The graph shows the traffic display effect of the hot parameters. The hot parameters shown in the graph are the user identifiers (uid) of the request body. The horizontal axis is the time axis and the vertical axis is the traffic value (QPS). It shows the traffic of the top five hot parameters, namely uid_1, uid_2, uid_3, uid_4, and uid_5.
[0188] Among them, the hot parameters reported to the management and control platform are all request parameters whose query rate per second reaches the first threshold.
[0189] The first threshold is a preset limit value used to distinguish between normal traffic and high-traffic requests. When the queries per second (QPS) of a request parameter reaches or exceeds this first threshold, the request parameter is identified as a hot parameter and reported to the management platform. For example, the determination of the first threshold is based on the analysis of historical data, consideration of business needs, and assessment of system capacity. Historical data provides the traffic distribution and fluctuations of the system in different time periods, business needs determine the scale of traffic that the system needs to handle in different scenarios, and system capacity limits the maximum traffic that the system can safely and stably handle.
[0190] The primary function of the first threshold is to help the system identify high-traffic requests that may put significant pressure on it, allowing for timely and appropriate countermeasures. By reporting hotspot parameters, administrators can understand the system's real-time traffic status and perform further analysis and processing as needed.
[0191] By analyzing traffic data from hotspot parameters on the management platform, administrators can identify potentially abnormal user access. This traffic data can be represented by queries per second (QPS). These abnormal user accesses typically exhibit unusual traffic patterns, such as an unusually high QPS for a particular user or IP address.
[0192] To address these abnormal user accesses, the system can incorporate risk control strategies. For example, a second threshold can be set, a higher limit than the first threshold, to identify abnormal user access. When the QPS (queries per second) value of a user or IP address, as indicated by the hotspot parameter, exceeds this second threshold, the system considers that user or IP address's access behavior abnormal, i.e., it determines it as abnormal user access. For these abnormal user accesses, the system can take measures such as blocking IP addresses and restricting logins to protect the system's stability and security.
[0193] The determination of the second threshold is usually based on the analysis and evaluation of abnormal user access behavior. These abnormal user accesses typically exhibit unusual traffic patterns, such as abnormally high QPS values or abnormally high access frequency. By analyzing these behavioral patterns, system administrators can set an appropriate threshold to identify abnormal user access.
[0194] The primary function of the second threshold is to help the system identify and respond to unauthorized user access. When the system detects that the QPS (queries per second) of a user or IP address exceeds the second threshold, it will trigger corresponding risk control policies, such as blocking the IP address or restricting logins, to protect the system's stability and security. These measures can effectively reduce the impact of unauthorized user access on the system and ensure its normal operation.
[0195] The second threshold is higher than the first threshold, meaning that only requests with extremely high and clearly abnormal traffic will be identified as abnormal user access. This setting ensures that the system can promptly detect and handle high-traffic requests while avoiding misjudgments and overreactions, thus guaranteeing the system's accuracy and reliability.
[0196] In some embodiments, the method further includes:
[0197] The rate limiting management results corresponding to the hotspot parameters are sent to the management platform, so that the management platform can generate rate limiting alarm information for the access requests that are denied according to the rate limiting management results.
[0198] The system performs rate limiting in real time, allowing or denying access requests based on either the first or second rate limiting policy. Each time an access request is denied, the system records the relevant rate limiting results, which may include information such as the name of the denied hot parameter, the request source, the timestamp of the denial, the number of denied requests, the requester's identifier, and the rate limiting rule hit status.
[0199] These rate limiting management results are then sent to the management platform. This can be achieved in various ways, such as via API calls, message queues, or log file parsing.
[0200] After receiving the rate limiting management results, the management platform will generate rate limiting alarm information based on these results. Rate limiting alarm information typically includes detailed information about the denied access requests. For example, the rate limiting alarm information will record the name of the hot parameter, the rate limiting time, the number of denied requests, and the possible reasons, so that relevant personnel can quickly locate the problem.
[0201] The generated rate limiting alerts will be sent to relevant personnel through multiple channels. This ensures that both system administrators and ordinary users can promptly understand the system's rate limiting status using the method most suitable for them.
[0202] For example, the management platform can send alarm information through various channels, including but not limited to:
[0203] Telephone notification: Directly dial the pre-set emergency contact number, suitable for situations requiring immediate human intervention.
[0204] Email notification: Send detailed alarm reports to the operations team's email address, suitable for post-incident analysis and archiving.
[0205] SMS notification: Quickly send concise alert SMS messages to relevant personnel to ensure they are notified in time, even when they are not at their computers.
[0206] Application Logs: Record alarm information in the system logs to facilitate log analysis and troubleshooting.
[0207] Integration into management tools: It integrates with traditional Internet technology (IT) management systems, directly pushing flow restriction alarm information to the management dashboard to achieve unified management and alarms.
[0208] Personnel receiving rate limiting alerts can take appropriate action based on the specific circumstances. For example, if a certain hot parameter is found to frequently trigger rate limiting, it may be necessary to adjust the system's rate limiting strategy or optimize the service corresponding to that parameter.
[0209] In this way, the system can not only manage the flow restriction in real time, but also notify relevant personnel of the flow restriction situation in a timely manner, thereby making the operation of the entire system more stable and secure.
[0210] In advertising application scenarios, the hotspot parameter traffic limiting method provided in this application embodiment can be used to improve the stability and efficiency of advertising services, while ensuring that user experience is not affected by abnormal advertising traffic. The following is an example based on an advertising application scenario:
[0211] First, the advertising system receives a large number of advertising requests (access requests) from different users and devices. The system needs to extract the request parameters corresponding to each advertising request from these requests, such as user ID, ad slot ID, and ad type.
[0212] Then, by statistically analyzing the query rate per second for each request parameter in real time, it is possible to identify which ad slots or ad types are experiencing abnormally high request frequencies, thereby identifying the request parameters whose query rate per second reaches the first threshold as hot parameters.
[0213] In the advertising system, some key advertising interfaces may have pre-configured hotspot parameter rate limiting rules based on rate limiting configuration information. Once the hotspot parameters corresponding to these interfaces are identified, the system can directly apply the first rate limiting strategy, performing rate limiting management based on the preset rate limiting configuration information.
[0214] For newly added interfaces or interfaces without configured rate limiting rules in the advertising system, the system can automatically switch to a second rate limiting strategy once the corresponding hotspot parameters are identified. This strategy makes rate limiting decisions based on dynamic indicators such as real-time QPS, CPU utilization, and average response time of the hotspot parameters. For example, when a new advertisement goes live, its request volume rises rapidly due to high user attention. The system can automatically adjust the rate limiting threshold based on these dynamic indicators to ensure that the advertising service can maintain low latency and high response speed while handling high traffic.
[0215] For example, taking ad placements as an example, when the ad placement corresponding to the hot topic parameter has already been configured with rate limiting information, the hot topic parameter is rate-limited according to the first rate limiting strategy. When the ad placement corresponding to the hot topic parameter has not been configured with rate limiting information, the hot topic parameter is rate-limited according to the second rate limiting strategy. By distinguishing between ad placements with and without configured rate limiting information and applying different rate limiting strategies, ad traffic can be controlled more precisely, avoiding the impact on user experience or system stability due to excessive ad requests.
[0216] A reasonable traffic limiting strategy can ensure that users can see the ads they are interested in in a timely manner, even under high traffic conditions, thereby improving ad click-through rates and conversion rates. By detecting hotspot parameters and implementing traffic limiting strategies, the advertising system can avoid service crashes caused by sudden traffic surges, ensuring the continuity and effectiveness of ad delivery. The advertising system can dynamically adjust its ad delivery strategy based on real-time data. For example, when abnormally high traffic is detected for a certain ad placement, the system can automatically reduce the ad display frequency of that ad placement and increase the display of other ad placements with lower traffic to balance the overall ad traffic. The collected traffic data can be used to further analyze ad behavior, optimize ad targeting algorithms, and improve ad relevance and attractiveness. Through effective traffic management and traffic limiting, advertising service providers can avoid unnecessary resource waste, such as the additional costs caused by server overload. Traffic limiting strategies can also serve as a means of defending against malicious traffic attacks, protecting the advertising system from malware or distributed denial-of-service (DDoS) attacks. In advertising application scenarios, the embodiments of this application can not only improve the stability of advertising services and user experience, but also optimize advertising effectiveness, achieve cost control, and enhance system security.
[0217] In high-concurrency application services, this application embodiment performs real-time traffic statistics on the request parameters in the access requests, filters out hot parameters, and performs rate limiting management on the access requests corresponding to the hot parameters according to the set threshold, so as to prevent the request traffic of certain hot parameters from being too large, causing the entire system to respond slowly, or even causing the service to become unavailable.
[0218] The embodiments of this application can optimize the memory usage of hotspot parameter traffic statistics based on the least recent access algorithm, thereby ensuring the effective utilization of system resources.
[0219] The embodiments of this application can achieve adaptive rate limiting for situations where rate limiting rules are not configured or are configured inappropriately, thereby providing a safety net for the system and ensuring the continuity and stability of services.
[0220] The embodiments of this application can optimize the rate limiting performance in cluster mode. In cluster mode, the embodiments of this application can significantly reduce the request pressure on the token server, reduce the request volume by more than 90%, thereby improving the overall rate limiting performance.
[0221] This application embodiment can visualize the traffic details of various service hotspot parameters, making it easy to quickly discover and analyze hotspot parameters and help administrators adjust strategies in a timely manner.
[0222] This application's embodiments can also record rate limiting events, facilitating risk control strategy analysis. For example, if a popular user or IP frequently accesses the coupon redemption interface, the system can block that user or IP for a period of time to reduce potential abuse.
[0223] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.
[0224] This application embodiment obtains the request parameters corresponding to each access request from multiple pending access requests; performs traffic statistics on the request parameters corresponding to each access request to obtain the query rate per second (QPS) value for each request parameter; identifies request parameters whose QPS value reaches a first threshold as hotspot parameters; when the interface corresponding to the hotspot parameter is configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to a first rate limiting strategy, which is a rate limiting rule for hotspot parameters determined based on the rate limiting configuration information; or, when the interface corresponding to the hotspot parameter is not configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to a second rate limiting strategy, which is a rate limiting rule for hotspot parameters determined based on the query rate per second value, CPU utilization, and average response time corresponding to the hotspot parameter. This application embodiment, by performing real-time traffic statistics on the request parameters of each access request, can quickly identify hotspot parameters with abnormally concentrated traffic. This immediacy helps to quickly locate key factors that may affect system stability, providing an accurate data foundation for subsequent traffic control. Based on whether the interfaces corresponding to the hotspot parameters are configured with preset rate limiting rules, the system can automatically switch to the most suitable rate limiting strategy to dynamically implement rate limiting operations. For interfaces with configured rate limiting information, a customized first rate limiting strategy is directly applied for efficient management. For interfaces without configured rate limiting information or with incomplete configuration, an adaptive second rate limiting strategy is activated based on dynamic indicators such as real-time traffic, CPU utilization, and average response time of the hotspot parameters, making rate limiting decisions more comprehensive and scientific. By distinguishing between interfaces with and without configured rate limiting information and applying different rate limiting strategies to each, fine-grained management of hotspot parameters is achieved, ensuring that the service maintains efficient and stable operation under different traffic pressures.
[0225] To facilitate better implementation of the hotspot parameter current limiting method of this application embodiment, this application embodiment also provides a hotspot parameter current limiting device. Please refer to... Figure 6 , Figure 6 This is a schematic diagram of the hotspot parameter current limiting device provided in an embodiment of this application. The hotspot parameter current limiting device 200 may include:
[0226] The acquisition unit 210 is used to acquire the request parameters corresponding to each access request from the multiple access requests to be processed;
[0227] The statistics unit 220 is used to perform traffic statistics on the request parameters corresponding to each access request and obtain the query rate per second value corresponding to each request parameter.
[0228] The determination unit 230 is used to determine the request parameters whose query rate per second reaches a first threshold as hot parameters;
[0229] The first rate limiting unit 240 is used to manage rate limiting of the hotspot parameter according to a first rate limiting strategy when the interface corresponding to the hotspot parameter is configured with rate limiting information. The first rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the rate limiting configuration information; or
[0230] The second rate limiting unit 250 is used to manage the rate limiting of hot parameters according to the second rate limiting strategy when the interface corresponding to the hot parameters is not configured with rate limiting information. The second rate limiting strategy is a rate limiting rule for hot parameters determined based on the query rate per second, CPU utilization and average response time corresponding to the hot parameters.
[0231] In some embodiments, the first current limiting unit 240 is specifically used for:
[0232] When the interface corresponding to the hotspot parameter is configured with rate limiting information, obtain the rate limiting mode indicated by the rate limiting configuration information;
[0233] When the rate limiting configuration information indicates a cluster rate limiting mode, rate limiting management is performed on hot parameters based on the cluster rate limiting mode. The cluster rate limiting mode is used to instruct the microservice cluster to manage the rate limiting of hot parameters according to the cluster threshold and the cluster threshold mode corresponding to the cluster rate limiting mode; or
[0234] When the rate limiting configuration information indicates that the rate limiting mode is single-machine rate limiting mode, rate limiting management of hot parameters is performed based on the single-machine rate limiting mode. The single-machine rate limiting mode is used to instruct each rate limiting proxy module in the microservice cluster to manage the rate limiting of hot parameters according to the single-machine threshold.
[0235] In some embodiments, the cluster threshold mode is either a single-machine amortization mode or an overall threshold mode;
[0236] The single-machine rate-limiting mode is used to instruct each rate-limiting proxy module in the microservice cluster to share the cluster threshold to obtain the rate-limited value, and to manage rate-limiting of hot parameters based on the rate-limited value.
[0237] The overall threshold mode is used to instruct the microservice cluster to rate-limit the first part of the traffic corresponding to the hot parameters through the token server, and to rate-limit the second part of the traffic corresponding to the hot parameters through the various rate-limiting proxy modules in the microservice cluster, based on the cluster threshold.
[0238] In some embodiments, the second current limiting unit 250 is specifically used for:
[0239] When the interface corresponding to the hotspot parameter is not configured with rate limiting information, the query rate per second, CPU utilization and average response time corresponding to the hotspot parameter are obtained based on the sliding window.
[0240] Get the average response time increment between the average response time of the current sliding window corresponding to the hotspot parameter and the average response time of the previous sliding window;
[0241] Hot parameters that have an average response time increment that reaches a preset increment and a CPU utilization rate that is greater than a first utilization rate, or hot parameters that have a CPU utilization rate that is greater than a second utilization rate, are identified as candidate rate limiting parameters, wherein the second utilization rate is greater than the first utilization rate.
[0242] Based on the query rate per second, CPU utilization, and average response time increment corresponding to the candidate rate limiting parameters, select the top N candidate rate limiting parameters, where N is a positive integer greater than 0.
[0243] Rate limiting is implemented for the access requests corresponding to the top N candidate rate limiting parameters.
[0244] In some embodiments, when the second rate limiting unit 250 selects the top N candidate rate limiting parameters from the candidate rate limiting parameters based on the query rate per second, CPU utilization, and average response time increment corresponding to the candidate rate limiting parameters, it is specifically used for:
[0245] Sort the candidate rate limiting parameters from largest to smallest according to their corresponding query rate per second values to obtain the sorted candidate rate limiting parameters.
[0246] The number of rate limiting parameters N is determined based on the CPU utilization and average response time increment corresponding to the candidate rate limiting parameters.
[0247] Based on the number of rate limiting parameters N, the top N candidate rate limiting parameters are selected from the sorted candidate rate limiting parameters.
[0248] In some embodiments, when the second rate limiting unit 250 performs rate limiting management on the access requests corresponding to the first N candidate rate limiting parameters, it is specifically used for:
[0249] Query the target query rate per second value corresponding to the Nth candidate rate limiting parameter among the top N candidate rate limiting parameters;
[0250] For access requests corresponding to candidate rate limiting parameters whose query rate per second is greater than half of the target query rate per second among the top N candidate rate limiting parameters, the requests will be rejected; or
[0251] For access requests corresponding to candidate rate limiting parameters whose query rate per second value is less than or equal to half of the target query rate per second value among the top N candidate rate limiting parameters, the requests will be allowed.
[0252] In some embodiments, the second current limiting unit 250 is further configured to:
[0253] The parameters other than the top N candidate rate limiting parameters in the hotspot parameters are identified as parameters to be released;
[0254] Allow access requests corresponding to the parameters to be allowed.
[0255] In some embodiments, the statistical unit 220 is further configured to:
[0256] Store the query rate per second corresponding to each request parameter into a mapping table data structure;
[0257] The request parameters in the mapping table data structure are updated based on the memory eviction algorithm.
[0258] In some embodiments, when the statistics unit 220 performs parameter update processing on the requested parameters in the mapping table data structure based on the memory eviction algorithm, it is specifically used for:
[0259] When the number of request parameters in the mapping table data structure reaches the mapping table size threshold, the request parameters to be evicted in the mapping table data structure are determined based on the memory eviction algorithm.
[0260] Remove the request parameters to be discarded from the mapping table data structure;
[0261] Store the query rate per second corresponding to the request parameters to be stored into the mapping table data structure.
[0262] In some embodiments, the hotspot parameter current limiting device 200 further includes:
[0263] The sending unit is used to send hotspot parameters to the management and control platform so that the query rate per second corresponding to the hotspot parameters can be displayed on the management and control platform.
[0264] In some embodiments, the sending unit is further configured to send the rate limiting management result corresponding to the hotspot parameter to the management platform, so that the management platform can generate rate limiting alarm information for the denied access requests corresponding to the hotspot parameter based on the rate limiting management result.
[0265] In some embodiments, the acquisition unit 210 is further configured to acquire rate limiting configuration information issued by the management and control platform, wherein the rate limiting configuration information is a rate limiting rule for hotspot parameters configured for the target interface.
[0266] In some embodiments, the acquisition unit 210 is specifically used for:
[0267] For an interface configured with rate limiting information that receives an pending access request, the request parameters corresponding to the access request are obtained from the access request based on the rate limiting configuration information; or
[0268] For pending access requests received by interfaces without configured rate limiting information, the request parameters corresponding to the access request are obtained from the access request based on the default parameter information.
[0269] In some embodiments, the acquiring unit 210 is further configured to:
[0270] Retrieve multiple pending access requests;
[0271] Multiple access requests are filtered based on a filter to obtain multiple filtered access requests;
[0272] Retrieve the request parameters corresponding to each access request from the filtered multiple access requests.
[0273] It should be noted that the functions of each unit in the hotspot parameter current limiting device 200 in this application embodiment can be referred to the specific implementation of any embodiment in the above method embodiments, and will not be repeated here.
[0274] Each unit in the above-described device can be implemented entirely or partially through software, hardware, or a combination thereof. Each unit can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each unit.
[0275] For example, the hotspot parameter rate limiting device 200 can be integrated into a terminal or server that has storage and a processor and thus computing power, or the hotspot parameter rate limiting device 200 can be the terminal or server itself.
[0276] In some embodiments, this application also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0277] Figure 7 A schematic structural diagram of the computer device provided in the embodiments of this application, such as Figure 7 As shown, the computer device 300 may include: a communication interface 301, a memory 302, a processor 303, and a communication bus 304. The communication interface 301, memory 302, and processor 303 communicate with each other via the communication bus 304. The communication interface 301 is used for data communication between the device 300 and external devices. The memory 302 can be used to store software programs and modules, and the processor 303 runs the software programs and modules stored in the memory 302, such as the software programs for the corresponding operations in the aforementioned method embodiments.
[0278] In some embodiments, the processor 303 may invoke software programs and modules stored in the memory 302 to perform the following operations:
[0279] The system retrieves request parameters from multiple pending access requests; performs traffic statistics on the request parameters for each access request to obtain the query rate per second (RPS) for each parameter; identifies request parameters with an RPS reaching a first threshold as hot parameters; when the interface corresponding to a hot parameter is configured with rate limiting information, rate limiting is implemented for the hot parameter according to a first rate limiting strategy, which is a rate limiting rule for hot parameters determined based on the rate limiting configuration information; or, when the interface corresponding to a hot parameter is not configured with rate limiting information, rate limiting is implemented for the hot parameter according to a second rate limiting strategy, which is a rate limiting rule for hot parameters determined based on the RPS, CPU utilization, and average response time for the hot parameter.
[0280] In some embodiments, the computer device 300 may be integrated into a terminal or server that has storage and a processor, thus possessing computing capabilities; or the computer device 300 may be the terminal or server. The terminal may be a smartphone, tablet, laptop, smart TV, smart speaker, wearable smart device, personal computer, or other similar device. The server may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.
[0281] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding processes in the methods described above in the embodiments of this application; for brevity, further details are omitted here.
[0282] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding processes in the methods described above in the embodiments of this application. For brevity, these details will not be elaborated further here.
[0283] This application also provides a computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding processes in the methods described above in the embodiments of this application. For brevity, these details will not be elaborated further here.
[0284] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.
[0285] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0286] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0287] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0288] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0289] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
[0290] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0291] In addition, the functional units in the embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0292] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or a server) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0293] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A hotspot parameter current limiting method, characterized in that, The method includes: Obtain the request parameters corresponding to each of the multiple pending access requests; Traffic statistics are performed on the request parameters corresponding to each access request to obtain the query rate per second value corresponding to each request parameter; The request parameters whose query rate per second reaches a first threshold are identified as hotspot parameters. When the interface corresponding to the hotspot parameter is configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to the first rate limiting strategy, whereby the first rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the rate limiting configuration information; or When the interface corresponding to the hotspot parameter is not configured with the rate limiting configuration information, rate limiting management is performed on the hotspot parameter according to the second rate limiting strategy. The second rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the query rate per second, CPU utilization, and average response time corresponding to the hotspot parameter.
2. The hotspot parameter current limiting method as described in claim 1, characterized in that, When the interface corresponding to the hotspot parameter is configured with rate limiting information, rate limiting management is performed on the hotspot parameter according to the first rate limiting strategy, including: When the interface corresponding to the hotspot parameter is configured with rate limiting configuration information, obtain the rate limiting mode indicated by the rate limiting configuration information; When the rate limiting configuration information indicates a cluster rate limiting mode, rate limiting management is performed on the hotspot parameters based on the cluster rate limiting mode. The cluster rate limiting mode is used to instruct the microservice cluster to manage the rate limiting of the hotspot parameters according to the cluster threshold and cluster threshold mode corresponding to the cluster rate limiting mode; or When the rate limiting configuration information indicates that the rate limiting mode is the single-machine rate limiting mode, the hotspot parameters are rate-limited based on the single-machine rate limiting mode. The single-machine rate limiting mode is used to instruct each rate limiting proxy module in the microservice cluster to perform rate limiting management on the hotspot parameters according to the single-machine threshold.
3. The hotspot parameter current limiting method as described in claim 2, characterized in that, The cluster threshold mode is either a single-machine amortization mode or an overall threshold mode; The single-machine rate-limiting mode is used to instruct each rate-limiting proxy module in the microservice cluster to share the cluster threshold to obtain a rate-limited value, and to perform rate-limiting management on the hotspot parameters based on the rate-limited value. The overall threshold mode is used to instruct the microservice cluster to perform rate limiting on the first part of the traffic corresponding to the hotspot parameter through the token server, and to perform rate limiting on the second part of the traffic corresponding to the hotspot parameter through each rate limiting proxy module in the microservice cluster, based on the cluster threshold.
4. The hotspot parameter current limiting method as described in claim 1, characterized in that, When the interface corresponding to the hotspot parameter is not configured with the rate limiting configuration information, rate limiting management is performed on the hotspot parameter according to the second rate limiting strategy, including: When the interface corresponding to the hotspot parameter is not configured with the rate limiting information, the query rate per second, CPU utilization and average response time corresponding to the hotspot parameter are obtained based on a sliding window. Obtain the average response time increment between the average response time of the current sliding window corresponding to the hotspot parameter and the average response time of the previous sliding window; Hotspot parameters that have an average response time increment that reaches a preset increment and a CPU utilization rate that is greater than a first utilization rate, or hotspot parameters whose CPU utilization rate is greater than a second utilization rate, are identified as candidate rate limiting parameters, wherein the second utilization rate is greater than the first utilization rate. Based on the query rate per second value, the CPU utilization rate and the average response time increment corresponding to the candidate rate limiting parameters, the top N candidate rate limiting parameters are selected from the candidate rate limiting parameters, where N is a positive integer greater than 0; Rate limiting management is applied to the access requests corresponding to the top N candidate rate limiting parameters.
5. The hotspot parameter current limiting method as described in claim 4, characterized in that, The step of selecting the top N candidate rate limiting parameters from the candidate rate limiting parameters based on the query rate per second value, the CPU utilization, and the average response time increment corresponding to the candidate rate limiting parameters includes: The candidate rate limiting parameters are sorted from largest to smallest according to the query rate per second value corresponding to the candidate rate limiting parameters to obtain the sorted candidate rate limiting parameters. The number of rate limiting parameters N is determined based on the CPU utilization rate and the average response time increment corresponding to the candidate rate limiting parameters. Based on the number of rate limiting parameters N, the top N candidate rate limiting parameters are selected from the sorted candidate rate limiting parameters.
6. The hotspot parameter current limiting method as described in claim 4, characterized in that, The process of rate limiting access requests corresponding to the top N candidate rate limiting parameters includes: Query the target query rate per second value corresponding to the Nth candidate rate limiting parameter among the top N candidate rate limiting parameters; For access requests corresponding to candidate rate limiting parameters whose query rate per second is greater than half of the target query rate per second among the top N candidate rate limiting parameters, the requests are rejected; or For access requests corresponding to candidate rate limiting parameters whose query rate per second value is less than or equal to half of the target query rate per second value among the top N candidate rate limiting parameters, the requests are allowed.
7. The hotspot parameter current limiting method as described in claim 1, characterized in that, When performing traffic statistics on the request parameters corresponding to each access request to obtain the query rate per second value corresponding to each request parameter, the method further includes: Store the query rate per second corresponding to each of the aforementioned request parameters into a mapping table data structure; The request parameters in the mapping table data structure are updated based on the memory eviction algorithm.
8. The hotspot parameter current limiting method as described in claim 1, characterized in that, The method further includes: The hotspot parameters are sent to the management and control platform so that the query rate per second corresponding to the hotspot parameters can be displayed on the management and control platform.
9. The hotspot parameter current limiting method as described in claim 8, characterized in that, The method further includes: The rate limiting management result corresponding to the hotspot parameter is sent to the management platform, so that the management platform can generate rate limiting alarm information for the denied access requests corresponding to the hotspot parameter based on the rate limiting management result.
10. The hotspot parameter current limiting method as described in claim 8, characterized in that, The method further includes: Obtain the rate limiting configuration information issued by the management and control platform. The rate limiting configuration information is a rate limiting rule for hotspot parameters configured for the target interface.
11. The hotspot parameter current limiting method as described in claim 1, characterized in that, The step of obtaining the request parameters corresponding to each access request from the multiple access requests to be processed includes: For an access request to be processed received by an interface configured with the aforementioned rate limiting information, the request parameters corresponding to the access request are obtained from the access request based on the rate limiting configuration information; or For an access request to be processed received by an interface that has not configured the rate limiting information, the request parameters corresponding to the access request are obtained from the access request based on the default parameter information.
12. A hotspot parameter current limiting device, characterized in that, The device includes: The acquisition unit is used to obtain the request parameters corresponding to each access request from multiple access requests to be processed; The statistics unit is used to perform traffic statistics on the request parameters corresponding to each access request to obtain the query rate per second value corresponding to each request parameter. The determining unit is used to determine the request parameters whose query rate per second reaches a first threshold as hotspot parameters; The first rate limiting unit is configured to manage rate limiting for the hotspot parameter according to a first rate limiting strategy when the interface corresponding to the hotspot parameter is configured with rate limiting information. The first rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the rate limiting configuration information; or The second rate limiting unit is used to manage the rate limiting of the hotspot parameter according to the second rate limiting strategy when the interface corresponding to the hotspot parameter is not configured with the rate limiting configuration information. The second rate limiting strategy is a rate limiting rule for the hotspot parameter determined based on the query rate per second, CPU utilization and average response time corresponding to the hotspot parameter.
13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to perform the hotspot parameter rate limiting method as described in any one of claims 1-11.
14. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, and the processor executing the hotspot parameter rate limiting method as described in any one of claims 1-11 by calling the computer program stored in the memory.
15. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the hotspot parameter rate limiting method according to any one of claims 1-11.