A throttling method and related apparatus for limiting erroneous requests
By dynamically quantifying the rate limiting intensity by tracking response status codes and request times, the problem of false rate limiting in traditional rate limiting solutions is solved, enabling accurate identification of erroneous requests and improving system stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING SOHU NEW MEDIA INFORMATION TECH
- Filing Date
- 2026-04-27
- Publication Date
- 2026-05-29
AI Technical Summary
Traditional rate limiting solutions cannot distinguish between request quality, resulting in normal requests being mistakenly limited due to sudden traffic surges, while malicious requests with high error rates are not effectively isolated.
By tracking the response status code and request time of the target request, the rate limiting intensity is dynamically quantified, and adaptive rate limiting is achieved by combining rate limiting parameters and database records.
Accurately identify erroneous requests, reduce the error rate, and improve system stability and resilience.
Smart Images
Figure CN122120032A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software technology, and in particular to a rate limiting method and related apparatus for limiting erroneous requests. Background Technology
[0002] With the increasing popularity of microservice architectures, the stability and protection capabilities of API gateways, as the entry point for all traffic, are crucial. Rate limiting is one of the core functions of a gateway, used to prevent malicious attacks and traffic overload.
[0003] Traditional rate limiting schemes (such as token buckets or fixed window counters) limit requests based on request frequency only, and cannot distinguish request quality. This results in normal requests being mistakenly limited due to sudden traffic surges, while malicious requests with high error rates are not effectively isolated. Summary of the Invention
[0004] In view of the above problems, this application provides a rate limiting method and related apparatus for restricting erroneous requests, so as to achieve adaptive rate limiting based on error type and request behavior. The specific solution is as follows:
[0005] The first aspect of this application provides a rate limiting method for restricting erroneous requests, the rate limiting method for restricting erroneous requests comprising:
[0006] Obtain the target request to be forwarded from the front end;
[0007] The current rate-limiting intensity of the target request is determined by tracking the response status code and request time, and rate-limiting operation is performed on the target request based on the current rate-limiting intensity.
[0008] In one possible implementation, determining the current rate-limiting intensity of the target request by tracking its response status code and request time, and performing rate-limiting operations on the target request based on the current rate-limiting intensity, includes:
[0009] The database storage content is read, which includes rate limiting parameters and rate limiting records of erroneous requests. The rate limiting parameters include a heat half-life parameter, a first heat threshold for lifting rate limiting, a second heat threshold for executing rate limiting, a first heat auto-increment parameter for request failure, a second heat auto-increment parameter for request delay, and a response status code weight. The second heat threshold is greater than the first heat threshold. The rate limiting records include rate limiting status, historical rate limiting heat of the last failed request, and historical request time.
[0010] If the target request is an erroneous request and the rate limiting status of the target request is blocked, the intermediate rate limiting status after time decay is determined based on the heat half-life parameter, the historical rate limiting heat of the target request, and the historical request time.
[0011] If the intermediate rate limiting heat is less than or equal to the first heat threshold, the rate limiting status of the target request is updated to non-blocking status and the target request is forwarded to the service backend;
[0012] Receive the first current response status code returned by the service backend for the target request;
[0013] If the first current response status code indicates that the request has failed, the first basic rate limiting intensity for the failed request is determined based on the first heat increment parameter, the current request time of the target request, the current response time of the first current response status code, the heat over-limit time threshold, and the second heat increment parameter.
[0014] The first basic rate limiting intensity is amplified by using the response status code weight corresponding to the first current response status code;
[0015] The current rate limiting intensity is determined based on the amplified result of the first basic rate limiting intensity and the intermediate rate limiting intensity. If the current rate limiting intensity is greater than the second intensity threshold, the target request is rate-limited, and the rate limiting record of the target request is updated in the database. The rate limiting status of the target request is updated to a blocked state, the historical rate limiting intensity of the target request is updated to the current rate limiting intensity, and the historical request time of the target request is updated to the current request time.
[0016] In one possible implementation, the step of determining the current rate-limiting intensity of the target request by tracking the response status code and request time of the target request, and performing rate-limiting operations on the target request based on the current rate-limiting intensity, further includes:
[0017] If the target request does not belong to the erroneous request, or if the target request belongs to the erroneous request and its rate limiting state is non-blocking, the target request is forwarded to the service backend;
[0018] Receive the second current response status code returned by the service backend for the target request;
[0019] If the second current response status code indicates that the request has failed, the second basic rate limiting intensity for the failed request is determined based on the first intensity increment parameter, the current request time of the target request, the current response time of the second current response status code, and the second intensity increment parameter.
[0020] The second basic rate limiting intensity is amplified by using the response status code weight corresponding to the second current response status code;
[0021] The amplified result of the second basic rate limiting heat is used as the current rate limiting heat. If the current rate limiting heat is greater than the second heat threshold, the target request is rate-limited, and the rate limiting record of the target request is updated in the database. The rate limiting status of the target request is updated to blocked status, the historical rate limiting heat of the target request is updated to the current rate limiting heat, and the historical request time of the target request is updated to the current request time.
[0022] In one possible implementation, the rate limiting parameters further include a third popularity threshold for clearing records, the third popularity threshold being less than the first popularity threshold. The step of updating the rate limiting status of the target request to a non-blocking state and forwarding the target request to the service backend if the intermediate rate limiting popularity is less than or equal to the first popularity threshold includes:
[0023] If the intermediate rate limiting threshold is greater than the third rate limiting threshold and less than or equal to the first rate limiting threshold, the rate limiting status of the target request is updated to non-blocking status and the target request is forwarded to the service backend.
[0024] If the intermediate rate limiting intensity is less than or equal to the third intensity threshold, the rate limiting record of the target request in the database is cleared, and the target request is forwarded to the service backend.
[0025] In one possible implementation, the rate limiting record further includes historical response status codes from previous failed requests. The step of determining the current rate limiting intensity of the target request by tracking its response status code and request time, and performing rate limiting operations on the target request based on the current rate limiting intensity, further includes:
[0026] If the intermediate rate limiting intensity is greater than the first intensity threshold, the rate limiting status of the target request is kept in a blocked state, and the historical response status code of the target request is returned to the front end.
[0027] In one possible implementation, the step of determining the current rate-limiting intensity of the target request by tracking the response status code and request time of the target request, and performing rate-limiting operations on the target request based on the current rate-limiting intensity, further includes:
[0028] If the first current response status code indicates that the request was successful, the rate limiting record for the target request in the database is cleared.
[0029] A second aspect of this application provides a rate limiting device for limiting erroneous requests, the rate limiting device for limiting erroneous requests comprising:
[0030] The request receiving module is used to obtain the target request to be forwarded from the front end;
[0031] The rate limiting module is used to determine the current rate limiting intensity of the target request by tracking the response status code and request time of the target request, and to perform rate limiting operation on the target request based on the current rate limiting intensity.
[0032] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the rate-limiting method for limiting erroneous requests described in the first aspect or any implementation thereof.
[0033] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:
[0034] The memory is used to store computer programs;
[0035] The processor is used to execute the computer program to enable the electronic device to implement the rate limiting method for limiting erroneous requests as described in the first aspect or any implementation thereof.
[0036] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the rate limiting method for limiting erroneous requests described in the first aspect or any implementation thereof.
[0037] By employing the above technical solution, this application provides a rate limiting method and related apparatus for restricting erroneous requests, comprising: acquiring a target request to be forwarded from the front end; determining the current rate limiting intensity of the target request by tracking the response status code and request time; and performing rate limiting operations on the target request based on the current rate limiting intensity. This application identifies error types by tracking the response status code of the request, dynamically quantifies the rate limiting intensity of the request by combining the request time, and then triggers rate limiting based on this intensity. This allows for accurate identification of erroneous requests, reduces the false rate limiting rate, and improves system stability. Attached Figure Description
[0038] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.
[0039] Figure 1 A flowchart illustrating a rate limiting method for restricting erroneous requests, provided as an embodiment of this application;
[0040] Figure 2A partial flowchart illustrating a rate limiting method for restricting erroneous requests, provided as an embodiment of this application;
[0041] Figure 3 This is another part of a flowchart illustrating a rate limiting method for restricting erroneous requests, provided as an embodiment of this application.
[0042] Figure 4 A schematic diagram of a flow limiting device for limiting erroneous requests is provided in an embodiment of this application;
[0043] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0044] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.
[0045] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.
[0046] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.
[0047] To achieve adaptive rate limiting based on error type and request behavior, embodiments of this application provide a rate limiting method for restricting erroneous requests. The rate limiting method for restricting erroneous requests according to embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0048] See Figure 1 , Figure 1 This is a flowchart illustrating a rate-limiting method for restricting erroneous requests, provided as an embodiment of this application. Figure 1As shown in the figure, the rate limiting method for restricting erroneous requests provided in this application embodiment can be applied to an API gateway, which can be implemented based on OpenResty. The rate limiting method for restricting erroneous requests is integrated into the API gateway through Lua scripts and can include steps S101 to S102, which are described in detail below.
[0049] S101, obtain the target request to be forwarded from the front end.
[0050] In this embodiment, the gateway API receives a target request to be forwarded from the front end, records the current request time of the target request, and filters the IP of the target request based on a stored blacklist. If the IP of the target request is in the blacklist, the gateway API performs rate limiting on the target request, that is, refuses to forward the target request to the service backend. If the IP of the target request is not in the blacklist, the gateway API executes the subsequent step S102.
[0051] S102, determine the current rate limiting intensity of the target request by tracking the response status code and request time of the target request, and perform rate limiting operation on the target request based on the current rate limiting intensity.
[0052] In this embodiment, the gateway API can identify whether a target request is an erroneous request by tracking the response status code. Furthermore, it combines the request time to identify the frontend's request behavior. The current rate-limiting intensity of the target request is quantified by comprehensively considering both the response status code and the request time. In other words, different erroneous requests represented by different response status codes and different request times result in different current rate-limiting intensity. Further, when the current rate-limiting intensity meets the corresponding rate-limiting conditions, such as reaching a corresponding intensity threshold, the target request is rate-limited and no longer forwarded to the service backend.
[0053] In one possible implementation, rate limiting parameters, erroneous request rate limiting records, and the aforementioned blacklist can be stored in a database such as Redis, supporting real-time updates and enabling hot policy updates. Furthermore, configuring a half-life parameter in the rate limiting parameters allows the rate limiting intensity to decay naturally over time, avoiding prolonged congestion; configuring a intensity threshold enables adaptive rate limiting; configuring an auto-incrementing intensity parameter and an over-limit time threshold allows the rate limiting intensity to dynamically adjust based on the number of failures, request latency, etc. More failures and longer request times will cause the rate limiting intensity to rise faster, preventing resource abuse; configuring response status code weights allows 500 consecutive errors to accumulate intensity quickly, while other errors accumulate at a more gradual rate.
[0054] See Figure 2 , Figure 2 This is a partial flowchart illustrating a rate-limiting method for restricting erroneous requests, provided as an embodiment of this application. Figure 2 As shown in the embodiment of this application, a rate limiting method for restricting erroneous requests is provided. Step S102, "determining the current rate limiting heat of the target request by tracking the response status code and request time of the target request, and performing rate limiting operation on the target request based on the current rate limiting heat", may include steps S201 to S207. These steps are described in detail below.
[0055] S201, Read the stored content of the database. The stored content includes rate limiting parameters and rate limiting records of erroneous requests. The rate limiting parameters include a popularity half-life parameter, a first popularity threshold for lifting rate limiting, a second popularity threshold for implementing rate limiting, a first popularity auto-increment parameter for request failure, a second popularity auto-increment parameter for request delay, a popularity over-limit time threshold, and a response status code weight. The second popularity threshold is greater than the first popularity threshold. The rate limiting records include the rate limiting status, the historical rate limiting popularity of the last failed request, and the historical request time.
[0056] In this embodiment of the application, the API gateway can read the stored content of the database, which includes rate limiting parameters and rate limiting records of at least one erroneous request. The rate limiting parameters support real-time updates, including the popularity half-life parameter (e.g., set to 60, meaning the rate limiting popularity decreases by half every 60 seconds), the first popularity threshold for lifting rate limiting (e.g., set to 8, meaning the rate limiting popularity is directly forwarded to the service backend when it drops to 8), the second popularity threshold for implementing rate limiting (e.g., set to 16, meaning the rate limiting popularity is no longer forwarded to the service backend when it rises to 16), the first popularity auto-increment parameter for request failure (e.g., set to 1, meaning each failed request increases the rate limiting popularity by 1), the second popularity auto-increment parameter for request latency (e.g., set to 0.1, meaning 0.1 increases the rate limiting popularity per second), the popularity over-limit time threshold (e.g., set to 30, meaning the popularity increases with time within 30 seconds of request latency, and after 30 seconds, the request latency no longer has any impact on the popularity), and the response status code weight (e.g., set to 4 for 500 error requests, meaning the rate limiting popularity is amplified by 4 times when the response status code is 500).
[0057] In addition, the rate limiting records are stored in Redis with a data type of Redis hash. The key is the resource ID of the erroneous request, and the hash field includes the rate limiting status of the error type (indicating whether it is blocked), the historical rate limiting heat of the last failed request (i.e., the rate limiting heat of the erroneous request when the last request failed), and the historical request time (i.e., the request time of the erroneous request when the last request failed).
[0058] S202, if the target request is an erroneous request and the rate limiting status of the target request is blocked, determine the intermediate rate limiting status after time decay based on the heat half-life parameter, the historical rate limiting heat of the target request, and the historical request time.
[0059] In this embodiment of the application, after obtaining the target request, the API gateway can determine whether the stored content has a rate-limiting record for the target request, that is, whether the target request is an erroneous request. If the target request is an erroneous request and the rate-limiting status of the target request is blocked, the intermediate rate-limiting heat after time decay is calculated according to the following formula (1):
[0060] (1);
[0061] in, Indicates the intermediate current-limiting heat level; This indicates the historical popularity of traffic restrictions; This indicates the time difference between the current time and the time of the historical request. This represents the thermal half-life parameter.
[0062] S203, if the intermediate rate limiting heat is less than or equal to the first heat threshold, update the rate limiting status of the target request to non-blocking status and forward the target request to the service backend.
[0063] In this embodiment of the application, the API gateway compares the intermediate rate limiting heat with the first heat threshold. If the intermediate rate limiting heat is less than or equal to the first heat threshold, it indicates that the rate limiting needs to be lifted. At this time, the rate limiting status of the target request is updated from the blocked state to the non-blocked state, and the target request is forwarded to the service backend.
[0064] Additionally, if the intermediate rate limit exceeds the first rate limit threshold, the system remains blocked and the target request is not forwarded to the service backend.
[0065] S204, the first current response status code returned by the service backend for the target request.
[0066] In this embodiment of the application, after the API gateway forwards the target request to the service backend, it waits for the service backend to respond and receives the current response status code (i.e., the first current response status code) returned by the service backend for the target request.
[0067] S205, if the first current response status code indicates that the current request has failed, determine the first basic rate limiting temperature for the failed request based on the first heat increment parameter, the current request time of the target request, the current response time of the first current response status code, the heat exceeding the time threshold, and the second heat increment parameter.
[0068] In this embodiment of the application, if the first response status code indicates that the request has failed, that is, the target request is an erroneous request, the API gateway calculates the first basic rate limiting heat of the failed request according to the following formula (2):
[0069] (2);
[0070] in, This indicates the first basic flow restriction popularity; This represents the first auto-incrementing parameter for popularity; Indicates the current response time; Indicates the current request time; This indicates the time threshold for exceeding the heat limit; This represents the second auto-incrementing parameter for popularity.
[0071] S206, the first basic rate limiting intensity is amplified by using the response status code weight corresponding to the first current response status code.
[0072] In this embodiment of the application, the API gateway amplifies the first basic rate limiting intensity as follows (3):
[0073] (3);
[0074] in, This represents the amplified result of the first basic current-limiting heat. This indicates the response status code weight. In practical applications, the response status code weight can be set only for specific error requests. For example, the basic rate limiting intensity of 500 error requests can be increased by 4 times, while other error requests are not amplified.
[0075] S207, determine the current rate limiting intensity based on the amplified result of the first basic rate limiting intensity and the intermediate rate limiting intensity, and if the current rate limiting intensity is greater than the second intensity threshold, rate limit the target request and update the rate limiting record of the target request in the database. The rate limiting status of the target request is updated to the blocked status, the historical rate limiting intensity of the target request is updated to the current rate limiting intensity, and the historical request time of the target request is updated to the current request time.
[0076] In this embodiment of the application, the API gateway calculates the current rate-limiting heat of the target request according to the following formula (4):
[0077] (4);
[0078] in, This indicates the current popularity level due to traffic restrictions.
[0079] Furthermore, the API gateway compares the current rate-limiting intensity with the second intensity threshold. If the current intensity exceeds the second intensity threshold, rate limiting is triggered, and the target request is no longer forwarded to the service backend. Additionally, the API gateway updates the target request's storage record in the database, specifically updating the rate-limiting status to "blocked," the historical rate-limiting intensity to the current intensity, and the historical request time to the current request time. Moreover, if the current rate-limiting intensity is not greater than the second intensity threshold, rate limiting is not triggered, and the target request is directly forwarded to the service backend.
[0080] In one possible implementation, to reduce database resource consumption, the rate limiting parameters are configured with a heat threshold to clear rate limiting records. In this regard, an embodiment of this application provides a rate limiting method for restricting erroneous requests, wherein the rate limiting parameters further include a third heat threshold for clearing records. The third heat threshold is less than the first heat threshold. For example, the third heat threshold is set to 0.01, meaning that when the rate limiting heat drops to 0.01, the corresponding rate limiting record is deleted. Accordingly, step S203, "If the intermediate rate limiting heat is less than or equal to the first heat threshold, update the rate limiting status of the target request to a non-blocking state and forward the target request to the service backend," can take the following steps:
[0081] If the intermediate rate limiting threshold is greater than the third threshold and less than or equal to the first threshold, the rate limiting status of the target request is updated to non-blocking and the target request is forwarded to the service backend.
[0082] If the intermediate rate limiting threshold is less than or equal to the third threshold, clear the rate limiting record of the target request in the database and forward the target request to the service backend.
[0083] In this embodiment, if the intermediate rate-limiting heat value is greater than the third heat value threshold and less than or equal to the first heat value threshold, the API gateway updates the rate-limiting status of the target request to a non-blocking state and then forwards the target request to the service backend. If the intermediate rate-limiting heat value is less than or equal to the third heat value threshold, the API gateway clears the rate-limiting record of the target request in the database and then forwards the target request to the service backend.
[0084] In one possible implementation, the rate limiting record may also include historical response status codes from previous failed requests. This allows the historical response status codes to be returned to the frontend when the rate limiting status of the target request is blocked. In this regard, an embodiment of this application provides a rate limiting method for restricting erroneous requests. The rate limiting record also includes historical response status codes from previous failed requests. Accordingly, step S102, "determining the current rate limiting intensity of the target request by tracking the response status code and request time of the target request, and performing rate limiting operations on the target request based on the current rate limiting intensity," further includes the following steps:
[0085] If the intermediate rate limiting intensity is greater than the first intensity threshold, keep the rate limiting status of the target request in a blocked state and return the historical response status codes of the target request to the front end.
[0086] In this embodiment of the application, if the intermediate rate limiting heat is greater than the first heat threshold, it means that there is no need to lift the rate limiting. At this time, the API gateway keeps the rate limiting status of the target request in a blocked state and returns the historical response status code of the target request to the front end.
[0087] In one possible implementation, to reduce database resource consumption, the gateway API can clear the rate-limiting record of the target request from the database when the first current response status code indicates that the request was successful. To this end, this application provides a rate-limiting method for limiting erroneous requests, wherein step S102, "determining the current rate-limiting intensity of the target request by tracking the response status code and request time of the target request, and performing rate-limiting operations on the target request based on the current rate-limiting intensity," may further include the following steps:
[0088] If the first current response status code indicates that the request was successful, clear the rate limiting record for the target request in the database.
[0089] In one possible implementation, for normal requests or erroneous requests in a non-blocking state, the API gateway does not need to calculate intermediate rate-limiting heat and directly forwards them to the service backend to perform rate limiting. See also Figure 3 , Figure 3 This is another part of the flowchart illustrating a rate-limiting method for restricting erroneous requests, provided as an embodiment of this application. For example... Figure 3 As shown in the embodiment of this application, a rate limiting method for restricting erroneous requests is provided. Step S102, "determine the current rate limiting heat of the target request by tracking the response status code and request time of the target request, and perform rate limiting operation on the target request based on the current rate limiting heat", may also include steps S301 to S305. These steps are described in detail below.
[0090] S301: If the target request is not an erroneous request, or if the target request is an erroneous request and its rate limiting status is non-blocking, forward the target request to the service backend.
[0091] In this embodiment of the application, if the API gateway determines that the target request is not an erroneous request, or if the target request is an erroneous request and its rate limiting status is non-blocking, then the target request is directly forwarded to the service backend.
[0092] S302, the second current response status code returned by the service backend for the target request.
[0093] In this embodiment of the application, after the API gateway forwards the target request to the service backend, it waits for the service backend to respond and receives the current response status code (i.e., the second current response status code) returned by the service backend for the target request.
[0094] S303, if the second current response status code indicates that the current request has failed, determine the second basic rate limiting intensity for the failed request based on the first intensity increment parameter, the current request time of the target request, the current response time of the second current response status code, and the second intensity increment parameter.
[0095] In this embodiment of the application, if the second current response status code indicates that the current request has failed, that is, the target request is an erroneous request, the API gateway calculates the second basic rate limiting heat of the current request failure according to the above formula (2). This embodiment of the application will not elaborate further on this.
[0096] S304, amplify the second basic current limiting intensity by using the response status code weight corresponding to the second current response status code.
[0097] In this embodiment of the application, the API gateway can amplify the second basic rate limiting intensity according to the above formula (3), which will not be elaborated further in this embodiment of the application.
[0098] S305, take the amplified result of the second basic rate limiting heat as the current rate limiting heat, and if the current rate limiting heat is greater than the second heat threshold, rate limit the target request and update the rate limiting record of the target request in the database. The rate limiting status of the target request is updated to the blocked state, the historical rate limiting heat of the target request is updated to the current rate limiting heat, and the historical request time of the target request is updated to the current request time.
[0099] In this embodiment, the API gateway uses the amplified result of the second basic rate limiting heat as the current rate limiting heat. It compares the current rate limiting heat with the second heat threshold. If the current rate limiting heat is greater than the second heat threshold, rate limiting needs to be triggered, and the target request will no longer be forwarded to the service backend. If the target request in step S301 is not an erroneous request, it is treated as a new erroneous request, and a rate limiting record for the target request is generated in the database. In this record, the rate limiting status is blocked, the historical rate limiting heat is the current rate limiting heat, and the historical request time is the current request time. If the target request in step S301 is an erroneous request and its rate limiting status is non-blocking, the rate limiting status in the record is updated to blocked, the historical rate limiting heat is updated to the current rate limiting heat, and the historical request time is updated to the current request time. Furthermore, if the current rate limiting heat is not greater than the second heat threshold, rate limiting is not triggered, and the target request is directly forwarded to the service backend.
[0100] Based on the above description, the rate limiting method provided in this application for restricting erroneous requests identifies the error type by tracking the response status code of the request, dynamically quantifies the rate limiting intensity of the request by combining the request time, and then triggers rate limiting based on this intensity. This allows for accurate identification of erroneous requests, reduces the false rate of rate limiting, and improves system stability. Furthermore, the rate limiting parameters in the database can be updated at any time, supporting adjustments to the rate limiting strategy according to the load, thus improving adaptability. Finally, it can be plugged in to integrate functions such as blacklists, providing rich layers of defense and enhanced resilience.
[0101] The above describes a rate limiting method for restricting erroneous requests provided by embodiments of this application. The following describes the apparatus for implementing the above-described rate limiting method for restricting erroneous requests.
[0102] See Figure 4 , Figure 4 This is a schematic diagram of a rate-limiting device for limiting erroneous requests, provided as an embodiment of this application. Figure 4 As shown in the figure, an embodiment of this application provides a rate limiting device for limiting erroneous requests, comprising:
[0103] The request receiving module 401 is used to obtain the target request to be forwarded from the front end.
[0104] The rate limiting module 402 is used to determine the current rate limiting intensity of the target request by tracking the response status code and request time of the target request, and to perform rate limiting operation on the target request based on the current rate limiting intensity.
[0105] In one possible implementation, the current limiting module 402 is specifically used for:
[0106] The system reads the database's stored content, which includes rate limiting parameters and rate limiting records for erroneous requests. Rate limiting parameters include a heat half-life parameter, a first heat threshold for lifting rate limiting, a second heat threshold for implementing rate limiting, a third heat threshold for clearing rate limiting records, a first heat increment parameter for failed requests, a second heat increment parameter for request delays, a heat exceeding the limit time threshold, and a response status code weight. The second heat threshold is greater than the first heat threshold. Rate limiting records include the rate limiting status, the historical rate limiting heat of the last failed request, and the historical request time. If the target request is an erroneous request and its rate limiting status is blocked, the system determines the intermediate rate limiting heat after time decay based on the heat half-life parameter, the historical rate limiting heat of the target request, and the historical request time. If the intermediate rate limiting heat is less than or equal to the first heat threshold, the rate limiting status of the target request is updated to non-blocking, and the target request is forwarded. The system provides the service backend with the first current response status code returned by the service backend for the target request. If the first current response status code indicates that the request has failed, it determines the first basic rate limiting intensity for the failed request based on the first auto-incrementing intensity parameter, the current request time of the target request, the current response time of the first current response status code, the intensity exceeding the time threshold, and the second auto-incrementing intensity parameter. It amplifies the first basic rate limiting intensity using the response status code weight corresponding to the first current response status code. Based on the amplification result of the first basic rate limiting intensity and the intermediate rate limiting intensity, it determines the current rate limiting intensity. If the current rate limiting intensity is greater than the second intensity threshold, it rate limits the target request and updates the rate limiting record of the target request in the database. The rate limiting status of the target request is updated to blocked, the historical rate limiting intensity of the target request is updated to the current rate limiting intensity, and the historical request time of the target request is updated to the current request time.
[0107] In one possible implementation, the current limiting module 402 is also used for:
[0108] If the target request is not an erroneous request, or if the target request is an erroneous request and its rate limiting status is non-blocking, the target request is forwarded to the service backend; the second current response status code returned by the service backend for the target request is received; if the second current response status code indicates that the request has failed, the second basic rate limiting heat for the failed request is determined based on the first heat increment parameter, the current request time of the target request, the current response time of the second current response status code, and the second heat increment parameter; the second basic rate limiting heat is amplified using the response status code weight corresponding to the second current response status code; the amplified result of the second basic rate limiting heat is used as the current rate limiting heat, and if the current rate limiting heat is greater than the second heat threshold, the target request is rate-limited, and the rate limiting record of the target request is updated in the database. The rate limiting status of the target request is updated to blocking, the historical rate limiting heat of the target request is updated to the current rate limiting heat, and the historical request time of the target request is updated to the current request time.
[0109] In one possible implementation, the rate limiting parameters also include a third popularity threshold for clearing records. This third popularity threshold is less than the first popularity threshold. It is used to update the rate limiting status of the target request to a non-blocking state and forward the target request to the rate limiting module 402 in the service backend if the intermediate rate limiting popularity is less than or equal to the first popularity threshold. Specifically, it is used for:
[0110] If the intermediate rate limiting threshold is greater than the third threshold and less than or equal to the first threshold, the rate limiting status of the target request is updated to non-blocking and the target request is forwarded to the service backend.
[0111] If the intermediate rate limiting threshold is less than or equal to the third threshold, clear the rate limiting record of the target request in the database and forward the target request to the service backend.
[0112] In one possible implementation, the rate limiting record also includes the historical response status code of the last failed request. Rate limiting module 402 is also used for:
[0113] If the intermediate rate limiting intensity is greater than the first intensity threshold, keep the rate limiting status of the target request in a blocked state and return the historical response status codes of the target request to the front end.
[0114] In one possible implementation, the current limiting module 402 is also used for:
[0115] If the first current response status code indicates that the request was successful, clear the rate limiting record for the target request in the database.
[0116] It should be noted that the detailed functions of each module in the embodiments of this application can be found in the corresponding disclosure of the above-mentioned rate limiting method embodiments for limiting erroneous requests, and will not be repeated here.
[0117] This application also provides an electronic device in its embodiments. See also... Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device in this embodiment may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0118] like Figure 5 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. When the electronic device is powered on, the RAM 503 also stores various programs and data required for the operation of the electronic device. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.
[0119] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, memory cards, hard drives, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.
[0120] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the rate-limiting methods provided in this application for limiting erroneous requests.
[0121] This application also provides a computer-readable storage medium carrying one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the rate limiting methods for limiting erroneous requests provided in this application.
[0122] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.
[0123] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0124] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.
[0125] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).
Claims
1. A rate limiting method for restricting erroneous requests, characterized in that, The rate limiting method for restricting erroneous requests includes: Obtain the target request to be forwarded from the front end; The current rate-limiting intensity of the target request is determined by tracking the response status code and request time of the target request, and rate-limiting operation is performed on the target request based on the current rate-limiting intensity.
2. The rate limiting method for limiting erroneous requests according to claim 1, characterized in that, The step of determining the current rate-limiting intensity of the target request by tracking the response status code and request time, and performing rate-limiting operations on the target request based on the current rate-limiting intensity, includes: The database storage content is read, which includes rate limiting parameters and rate limiting records of erroneous requests. The rate limiting parameters include a popularity half-life parameter, a first popularity threshold for lifting rate limiting, a second popularity threshold for implementing rate limiting, a first popularity auto-increment parameter for request failure, a second popularity auto-increment parameter for request delay, a popularity over-limit time threshold, and a response status code weight. The second popularity threshold is greater than the first popularity threshold. The rate limiting records include rate limiting status, historical rate limiting popularity of the last failed request, and historical request time. If the target request is an erroneous request and the rate limiting status of the target request is blocked, the intermediate rate limiting status after time decay is determined based on the heat half-life parameter, the historical rate limiting heat of the target request, and the historical request time. If the intermediate rate limiting heat is less than or equal to the first heat threshold, the rate limiting status of the target request is updated to non-blocking status and the target request is forwarded to the service backend; Receive the first current response status code returned by the service backend for the target request; If the first current response status code indicates that the request has failed, the first basic rate limiting intensity for the failed request is determined based on the first heat increment parameter, the current request time of the target request, the current response time of the first current response status code, the heat over-limit time threshold, and the second heat increment parameter. The first basic rate limiting intensity is amplified by using the response status code weight corresponding to the first current response status code; The current rate limiting intensity is determined based on the amplified result of the first basic rate limiting intensity and the intermediate rate limiting intensity. If the current rate limiting intensity is greater than the second intensity threshold, the target request is rate-limited, and the rate limiting record of the target request is updated in the database. The rate limiting status of the target request is updated to a blocked state, the historical rate limiting intensity of the target request is updated to the current rate limiting intensity, and the historical request time of the target request is updated to the current request time.
3. The rate limiting method for restricting erroneous requests according to claim 2, characterized in that, The step of determining the current rate-limiting intensity of the target request by tracking the response status code and request time, and performing rate-limiting operations on the target request based on the current rate-limiting intensity, further includes: If the target request does not belong to the erroneous request, or if the target request belongs to the erroneous request and its rate limiting state is non-blocking, the target request is forwarded to the service backend; Receive the second current response status code returned by the service backend for the target request; If the second current response status code indicates that the request has failed, the second basic rate limiting intensity for the failed request is determined based on the first intensity increment parameter, the current request time of the target request, the current response time of the second current response status code, and the second intensity increment parameter. The second basic rate limiting intensity is amplified by using the response status code weight corresponding to the second current response status code; The amplified result of the second basic rate limiting heat is used as the current rate limiting heat. If the current rate limiting heat is greater than the second heat threshold, the target request is rate-limited, and the rate limiting record of the target request is updated in the database. The rate limiting status of the target request is updated to blocked status, the historical rate limiting heat of the target request is updated to the current rate limiting heat, and the historical request time of the target request is updated to the current request time.
4. The rate limiting method for restricting erroneous requests according to claim 2, characterized in that, The rate limiting parameters also include a third popularity threshold for clearing records, the third popularity threshold being less than the first popularity threshold. The step of updating the rate limiting status of the target request to a non-blocking state and forwarding the target request to the service backend if the intermediate rate limiting popularity is less than or equal to the first popularity threshold includes: If the intermediate rate limiting threshold is greater than the third rate limiting threshold and less than or equal to the first rate limiting threshold, the rate limiting status of the target request is updated to non-blocking status and the target request is forwarded to the service backend. If the intermediate rate limiting intensity is less than or equal to the third intensity threshold, the rate limiting record of the target request in the database is cleared, and the target request is forwarded to the service backend.
5. The rate limiting method for limiting erroneous requests according to claim 2, characterized in that, The rate limiting record also includes historical response status codes from previous failed requests. The step of determining the current rate limiting intensity of the target request by tracking its response status code and request time, and performing rate limiting operations on the target request based on the current rate limiting intensity, further includes: If the intermediate rate limiting intensity is greater than the first intensity threshold, the rate limiting status of the target request is kept in a blocked state, and the historical response status code of the target request is returned to the front end.
6. The rate limiting method for limiting erroneous requests according to claim 2, characterized in that, The step of determining the current rate-limiting intensity of the target request by tracking the response status code and request time, and performing rate-limiting operations on the target request based on the current rate-limiting intensity, further includes: If the first current response status code indicates that the request was successful, the rate limiting record for the target request in the database is cleared.
7. A rate limiting device for limiting erroneous requests, characterized in that, The rate limiting device for limiting erroneous requests includes: The request receiving module is used to obtain the target request to be forwarded from the front end; The rate limiting module is used to determine the current rate limiting intensity of the target request by tracking the response status code and request time of the target request, and to perform rate limiting operation on the target request based on the current rate limiting intensity.
8. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the rate-limiting method for limiting erroneous requests as described in any one of claims 1 to 6.
9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is configured to execute the computer program to enable the electronic device to implement the rate limiting method for limiting erroneous requests as described in any one of claims 1 to 6.
10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the rate limiting method for limiting erroneous requests as described in any one of claims 1 to 6.