Flow limiting method, device, storage medium and program product

Abstract

This application relates to the field of Internet technology and discloses a rate limiting method, device, storage medium, and program product. The method includes: receiving a request for accessing a distributed search engine cluster. When at least one request characteristic information meets a preset allowance condition, the request is allowed. The request characteristic information includes one or more of the following: request type, request index, and the IP address of the client sending the first request. Conversely, when none of the request characteristic information meets the preset allowance condition, the rate limiting characteristic information corresponding to the request is matched with one or more preset rate limiting rules, and the request is intercepted or allowed based on the matching result. The rate limiting characteristic information includes the request's request characteristic information, or it includes the request characteristic information of the request and a fingerprint ID generated based on the request body content of the request. In this way, abnormal requests accessing the distributed search engine cluster can be rate-limited, thereby ensuring the stability of the cluster.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a rate limiting method, device, storage medium, and program product. Background Technology

[0002] Elasticsearch (ES) is a distributed search engine widely used in scenarios such as log analysis, full-text search, and data statistics. In real-world production environments, ES clusters typically need to handle a large number of concurrent requests. However, during operation, occasional abnormal requests may consume too many time slices of the cluster, causing a sharp spike in the utilization of the central processing unit (CPU). This, in turn, increases the overall service response latency of the ES cluster, resulting in normal requests not receiving timely responses and severely impacting the overall availability of the ES cluster. Summary of the Invention

[0003] This application provides a rate limiting method, device, storage medium, and program product that can rate limit abnormal requests accessing a distributed search engine cluster, thereby ensuring the stability of the distributed search engine cluster.

[0004] Firstly, this application provides a rate limiting method, the method comprising: receiving a first request for accessing a distributed search engine cluster. If at least one request feature information corresponding to the first request satisfies a preset allowable condition, the first request is allowed; wherein the request feature information includes one or more of a request type, a request index, and the client's Internet Protocol (IP) address of the first request. If none of the request feature information corresponding to the first request satisfies the preset allowable condition, the rate limiting feature information corresponding to the first request is matched with one or more preset rate limiting rules, and the first request is intercepted or allowed based on the matching result; wherein the rate limiting feature information includes the request feature information corresponding to the first request, or the rate limiting feature information includes the request feature information corresponding to the first request and a fingerprint identifier (identity, ID) of the first request, the fingerprint ID of the first request being generated based on the request body content of the first request.

[0005] Therefore, in this application, one or more factors such as request type, client IP address, request index, and fingerprint ID can be combined to determine whether to rate limit requests. This allows for a more accurate distinction between normal and abnormal requests, improving the accuracy of rate limiting for abnormal requests. Furthermore, rate limiting abnormal requests can prevent cluster CPU utilization from spiked due to abnormal requests consuming excessive time slices, thereby improving cluster service response speed and ensuring timely responses to normal requests, thus guaranteeing the overall availability of the cluster.

[0006] In one possible implementation of the first aspect above, allowing the first request when at least one request feature information corresponding to the first request meets the preset allow conditions includes: allowing the first request when the request type of the first request does not belong to a preset rate-limiting request type; or, allowing the first request when the client IP address corresponding to the first request is included in a preset IP address whitelist, wherein the IP address whitelist includes one or more client IP addresses; or, allowing the first request when all request indices of the first request are within a preset index whitelist, wherein the index whitelist includes one or more request indices.

[0007] In one possible implementation of the first aspect above, when none of the request feature information corresponding to the first request meets the preset allow conditions, the rate limiting feature information corresponding to the first request is matched with one or more preset rate limiting rules, and the first request is blocked or allowed according to the matching result, including: when the request type of the first request belongs to the rate limiting request type, the IP address whitelist does not include the client IP address corresponding to the first request, and at least one request index of the first request is not in the index whitelist, the rate limiting feature information corresponding to the first request is matched with one or more preset rate limiting rules, and the first request is blocked or allowed according to the matching result.

[0008] In one possible implementation of the first aspect above, the method further includes: if the request type of the first request is a search request and the rate limiting rule corresponding to the search request has a fingerprint ID, then the rate limiting feature information includes the request feature information corresponding to the first request and the fingerprint ID of the first request; or, if the request type of the first request is a structured query language (SQL) request, the rate limiting feature information includes the request feature information corresponding to the first request and the fingerprint ID of the first request.

[0009] In this way, for complex request types such as Search requests or SQL requests, more accurate traffic control can be achieved by combining request feature information and the fingerprint ID corresponding to the request body for rate limiting judgment, avoiding the occurrence of misjudgment or missed judgment of rate limiting caused by relying solely on basic request feature information.

[0010] In one possible implementation of the first aspect described above, the rate-limiting feature information includes request feature information corresponding to the first request and the fingerprint ID of the first request. When the request type of the first request is a rate-limited request type, the client IP address corresponding to the first request is not included in the IP address whitelist, and at least one request index of the first request is not in the index whitelist, the rate-limiting feature information corresponding to the first request is matched with one or more preset rate-limiting rules, and the first request is blocked or allowed based on the matching result. This includes: when the request type of the first request is a rate-limited request type, the client IP address corresponding to the first request is not included in the IP address whitelist, and the i-th request index among the multiple request indices of the first request is not in the index whitelist, obtaining the first rate-limiting feature information corresponding to the i-th request index based on the client IP address corresponding to the first request, the i-th request index, and the fingerprint ID of the first request, where i is a positive integer. Matching the first rate-limiting feature information corresponding to the i-th request index with one or more rate-limiting rules, and allowing or denying the client access to the data resource indicated by the i-th request index based on the matching result.

[0011] This avoids directly intercepting all client requests, thus enabling more granular and precise traffic control.

[0012] In one possible implementation of the first aspect above, the following is included: when the request type of the first request is a rate-limited request type, the IP address whitelist does not include the client IP address corresponding to the first request, at least one request index of the first request is not in the index whitelist, and the j-th request index among the multiple request indices of the first request is in the index whitelist, the client is allowed to access the data resource indicated by the j-th request index, where j is a positive integer.

[0013] This avoids directly intercepting all client requests, thus enabling more granular and precise traffic control.

[0014] In one possible implementation of the first aspect described above, matching the first rate-limiting feature information corresponding to the i-th request index with one or more rate-limiting rules, and allowing or denying client access to the data resource indicated by the i-th request index based on the matching result, includes: matching the first rate-limiting feature information with one or more rate-limiting rules. If the first rate-limiting feature information successfully matches the first rate-limiting rule among the one or more rate-limiting rules, a non-empty rate limiter context corresponding to the first rate-limiting feature information is obtained; if the first rate-limiting feature information fails to match any of the rate-limiting rules among the one or more rate-limiting rules, an empty rate limiter context is obtained; based on the non-empty rate limiter context or the empty rate limiter context, client access to the data resource indicated by the i-th request index is allowed or denied.

[0015] In one possible implementation of the first aspect above, obtaining a non-empty rate limiter context corresponding to the first rate limiting feature information when it successfully matches the first rate limiting rule in one or more rate limiting rules includes: if the i-th request index, client IP address, and fingerprint ID in the first rate limiting feature information all successfully match the request index, client IP address, and fingerprint ID in the first rate limiting rule, then determining whether the first rate limiting rule contains a non-empty rate limiter context; if the first rate limiting rule contains a rate limiter context, obtaining a non-empty rate limiter context; if the first rate limiting rule does not contain a rate limiter context, initializing and generating a non-empty rate limiter context; or, obtaining an empty rate limiter context when the first rate limiting feature information fails to match each of the rate limiting rules in one or more rate limiting rules includes: obtaining an empty rate limiter context when the i-th request index, client IP address, and fingerprint ID in the first rate limiting feature information all fail to match the request index, client IP address, and fingerprint ID in each of the rate limiting rules.

[0016] In one possible implementation of the first aspect above, allowing or denying client access to the data resource indicated by the i-th request index based on a non-empty rate limiter context or an empty rate limiter context includes: allowing the client to access the data resource indicated by the i-th request index when the rate limiter context corresponding to the first rate limiting feature information is empty; obtaining the rate limiter corresponding to the rate limiter context when the rate limiter context corresponding to the first rate limiting feature information is not empty; and, throwing an exception and denying the client access to the data resource indicated by the i-th request index when the rate limiter is not empty; and determining whether to rate limit the request corresponding to the i-th request index through the rate limiter when the rate limiter is not empty; wherein, when rate limiting the request corresponding to the i-th request index is applied, throwing an exception and denying the client access to the data resource indicated by the i-th request index.

[0017] In one possible implementation of the first aspect above, if the request type of the first request is a Search request and the rate limiting rule corresponding to the Search request has a fingerprint ID, the fingerprint ID of the first request is generated in the following way: the string of the first request is deserialized into a structured object; a depth-first traversal is performed on the structured object to obtain a fingerprint template; the keys in the fingerprint template are sorted lexicographically to obtain a normalized string; and a hash calculation is performed on the normalized string to obtain the fingerprint ID of the first request.

[0018] In one possible implementation of the first aspect above, the above-mentioned depth-first traversal processing of the structured object to obtain the fingerprint template includes: processing the leaf nodes in the traversed structured object to obtain processed leaf nodes; obtaining the fingerprint template based on the non-leaf nodes in the structured object and each processed leaf node; wherein, the above-mentioned processing of the traversed leaf nodes to obtain processed leaf nodes includes: if the value of the traversed leaf node is not an array type, replacing the value of the leaf node with a preset mask symbol to obtain the processed leaf node; and / or if the value of the traversed leaf node is an array and the array is not empty, retaining the first element in the array and removing other elements in the array other than the first element to obtain the processed leaf node; and / or if the value of the traversed leaf node is an empty array, retaining the empty array.

[0019] In one possible implementation of the first aspect above, if the request type of the first request is an SQL request, the fingerprint ID of the first request is generated in the following way: the SQL parameters in the first request are replaced with preset mask symbols to obtain the request fingerprint; the request fingerprint is hashed to obtain the fingerprint ID of the first request.

[0020] In a second aspect, this application also provides an electronic device, comprising: at least one memory and at least one processor, wherein the memory is coupled to the processor; the memory is used to store computer program code / instructions; when the computer program code / instructions are executed by the processor, the electronic device performs the current limiting method mentioned in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application also provides a readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the current limiting method mentioned in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application also provides a computer program product, comprising: computer instructions that, when executed on an electronic device, cause the electronic device to perform the current limiting method mentioned in the first aspect and any possible implementation thereof.

[0023] The beneficial effects of the second to fourth aspects mentioned above can be referred to the relevant descriptions in the first aspect and any possible implementation of the first aspect, which will not be repeated here. Attached Figure Description

[0024] Figure 1 According to some embodiments of this application, a flowchart of a flow limiting method is shown;

[0025] Figure 2 According to some embodiments of this application, a flowchart of another rate limiting method is shown;

[0026] Figure 3 According to some embodiments of this application, a flowchart is shown to determine whether the rate limiting feature information matches the rate limiting rules;

[0027] Figure 4 According to some embodiments of this application, a schematic diagram of the hardware structure of an electronic device is shown. Detailed Implementation

[0028] The illustrative embodiments of this application include, but are not limited to, a current limiting method, apparatus, storage medium, and program product.

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0030] As mentioned earlier, in an Elasticsearch cluster, occasional abnormal requests may consume too much time slice, causing the cluster's CPU utilization to spike. This, in turn, increases the response latency of the Elasticsearch cluster service, resulting in normal requests not receiving timely responses and severely impacting the overall availability of the Elasticsearch cluster.

[0031] Currently, to ensure the stability of Elasticsearch (ES) clusters, rate limiting strategies are typically implemented for abnormal requests. Specifically, for requests accessing the ES cluster, the load balancing (LB) component at the upper layer of the ES cluster can perform rate limiting judgment and control based on the uniform resource locator (URL) path of the request. For example, if a rate limiting rule is set for a certain URL path, the LB component will rate limit all requests using that URL path, thereby preventing the ES cluster from becoming overloaded or the service from becoming unavailable due to a few abnormal requests.

[0032] However, the load balancer (LB) component can only identify the URL path of a request and applies the same strategy (such as rate limiting for all requests or normal execution for all requests) to requests with the same URL path. Therefore, when multiple requests access the Elasticsearch cluster using the same URL path, if rate limiting rules are pre-set for that URL path, the LB component will still apply rate limiting to all requests, even if some are legitimate. It is clear that the current rate limiting method cannot distinguish between legitimate and abnormal requests, resulting in insufficient accuracy and difficulty in effectively intercepting and precisely protecting against abnormal requests.

[0033] For example, rate limiting rules can be pre-set for the URL path "GET / user_info / _search". In a real-world business scenario, there might be a normal request "GET / user_info / _search{ "query":{"term": {"age": 20}}}" and an abnormal request "GET / user_info / _search{ "size": 10000,"sort": ["timestamp"]}". Since both requests have the same URL path "GET / user_info / _search", the load balancer (LB) component will rate limit both requests. It's clear that the LB component cannot accurately distinguish between normal and abnormal requests when rate limiting, resulting in insufficient accuracy in rate limiting.

[0034] To address the aforementioned issues, this application provides a rate limiting method. Specifically, upon receiving a first request for accessing a distributed search engine cluster (such as an Elasticsearch cluster), it can be first determined whether the request characteristic information of the first request meets preset allowance conditions. The request characteristic information may include one or more of the following: request type, request index, and the Internet Protocol (IP) address of the client sending the first request. If at least one of the request characteristic information corresponding to the first request meets the preset allowance conditions, the first request can be allowed. Conversely, if none of the request characteristic information corresponding to the first request meets the preset allowance conditions, the rate limiting characteristic information corresponding to the first request can be matched with one or more preset rate limiting rules, and the first request can be intercepted or allowed based on the matching result. The rate limiting characteristic information may include the request characteristic information corresponding to the first request, or it may also include the request characteristic information corresponding to the first request and the fingerprint ID of the first request, which can be generated based on the request body content of the first request.

[0035] Therefore, in this application, one or more factors such as request type, client IP address, request index, and fingerprint ID can be combined to determine whether to rate limit requests. This allows for a more accurate distinction between normal and abnormal requests, improving the accuracy of rate limiting for abnormal requests. Furthermore, rate limiting abnormal requests can prevent cluster CPU utilization from spiked due to abnormal requests consuming excessive time slices, thereby improving cluster service response speed and ensuring timely responses to normal requests, thus guaranteeing the overall availability of the cluster.

[0036] It is understood that the rate limiting method provided in this application can be applied to servers or cloud environments that have deployed distributed search engine clusters (such as Elasticsearch clusters). For example, the cloud environment mentioned in this application can be Linux. TM Server, Windows TM A server or other server that can provide simultaneous access for multiple devices, or a server cluster consisting of one or more servers located in multiple regions, data centers, or servers, may be included in this application. This application does not limit the specific form of the cloud application.

[0037] The following is based on Figure 1 The flowchart shown provides a brief introduction to the rate limiting method mentioned in the embodiments of this application. For example, this rate limiting method can be applied to the cloud or a server. Figure 1 As shown, specifically, the method is as follows:

[0038] S11: The first request for accessing the distributed search engine cluster has been received.

[0039] For example, the distributed search engine cluster can be an Elasticsearch (ES) cluster, and the first request can be an ES request.

[0040] S12: If at least one request feature information corresponding to the first request meets the preset release conditions, the first request is released.

[0041] In some embodiments, the first request can be parsed to obtain request type information. For example, request characteristic information may include, but is not limited to, one or more of the following: request type (such as a Search request or a Get request), request index (such as the name of the requested data table), and the IP address of the client that sent the first request.

[0042] In some embodiments, preset allowance conditions may refer to the request type not belonging to a preset rate-limited request type, all request indices being within the index whitelist, or the client IP address being within the IP address whitelist, etc. The specific content of the preset allowance conditions and the specific process for determining whether the first request meets the preset allowance conditions are described in detail below.

[0043] For example, developers can pre-set one or more rate-limited request types. These rate-limited request types may include, but are not limited to, Search requests, Get requests, BulkShard requests, UpdateByQuery requests, DeleteByQuery requests, SearchScroll requests, SQL requests, and one or more other request types. If the request type of the first request does not belong to a preset rate-limited request type, the distributed search engine cluster can directly allow the first request. Conversely, if the request type of the first request belongs to a preset rate-limited request type, it indicates that the first request may be an abnormal request. In this case, further judgment is needed, such as determining whether the client IP sending the first request is on an IP whitelist, to further determine whether the first request needs to be blocked. See details for further information. Figure 2 As shown, details will not be elaborated here.

[0044] As another example, developers can pre-configure an IP address whitelist, which can include one or more client IP addresses. In this case, if the client IP address sending the first request is within the pre-defined whitelist, the distributed search engine cluster can directly allow the first request. Conversely, if the client IP address sending the first request is not within the pre-defined whitelist, it indicates that the first request may be an abnormal request. In this case, further judgment is needed, such as determining whether the indexes requested in the first request are within the index whitelist, in order to further determine whether the first request needs to be blocked. See details for further information. Figure 2 As shown, details will not be elaborated here.

[0045] As another example, developers can pre-set an index whitelist, which can include one or more request indexes. In this case, if all request indexes in the first request are within the pre-set IP address whitelist, the distributed search engine cluster can directly allow the first request. Conversely, if at least one request index in the first request is not within the pre-set index whitelist—for example, if the first request includes multiple request indexes (e.g., for accessing multiple data tables) but one of them is not in the whitelist—it indicates that the first request may be an abnormal request. In this case, further judgment is needed, such as determining whether some request indexes are within the whitelist, to further determine whether the entire request content of the first request needs to be blocked. See details for further information. Figure 2 As shown, details will not be elaborated here.

[0046] In summary, if any of the request characteristics of the first request meets the corresponding preset release conditions, the first request can be considered a normal request. In this case, the first request can be released and executed directly.

[0047] It is understood that the specific implementation process of the rate limiting method is not limited in the embodiments of this application. For example, if the distributed search engine cluster is an Elasticsearch (ES) cluster, the method provided in the embodiments of this application can be implemented by designing an ES plugin in the actual implementation process. For example, the ES plugin can be developed by implementing the ES ActionFilter interface. Then, after enabling the ES plugin, ES requests can be preprocessed in the Transport layer of the ES cluster, such as determining whether the ES request meets the preset allow conditions.

[0048] S13: If none of the request feature information corresponding to the first request meets the preset release conditions, the rate limiting feature information corresponding to the first request is matched with one or more preset rate limiting rules, and the first request is blocked or released according to the matching result.

[0049] In some embodiments, if none of the request feature information of the first request meets the preset allow conditions mentioned in S12 above, for example, if the request type of the first request is a rate-limited request type, the preset IP address whitelist does not include the client IP address corresponding to the first request, and at least one request index of the first request is not in the preset index whitelist, then the first request may be an abnormal request. In this case, the distributed search engine cluster can match the rate-limiting feature information corresponding to the first request with one or more preset rate-limiting rules, and further determine whether it is necessary to intercept all request content of the first request based on the matching result.

[0050] In some embodiments, the rate-limiting feature information of the first request may include request feature information and a fingerprint ID of the first request. The fingerprint ID is typically generated based on the request body content of the first request to uniquely identify the request body. For example, if the first request type is a search request and the rate-limiting rule corresponding to the search request is configured with a fingerprint ID, then the rate-limiting feature information of the first request can include both the request feature information and the fingerprint ID. Similarly, if the first request type is a Structured Query Language (SQL) request, then the rate-limiting feature information of the first request can also include both the request feature information and the fingerprint ID. Thus, for complex request types such as search requests or SQL requests, combining the request feature information and the fingerprint ID corresponding to the request body for rate-limiting judgment can achieve more accurate traffic control, avoiding misjudgments or omissions caused by relying solely on basic request feature information. The specific generation process of the fingerprint ID used to uniquely identify the request body can be found in [reference needed]. Figure 2 The details will not be elaborated here.

[0051] Alternatively, in some embodiments, the rate-limiting feature information of the first request may only include the request feature information of the first request. For example, if the request type of the first request is a DeleteByQuery request or a BulkShard request, since the request body of these request types usually does not have a significant load impact on the distributed search engine cluster, it is not necessary to generate a fingerprint ID based on the request body of the first request. In this case, the rate-limiting feature information of the first request may only include the request feature information of the first request. In this way, for request types whose request bodies do not have a significant load impact on the distributed search engine cluster (such as DeleteByQuery requests or BulkShard requests), it is not necessary to calculate and generate a fingerprint ID for the request body. Instead, rate-limiting judgment can be performed based solely on the request feature information, thereby reducing system computational overhead and improving processing efficiency.

[0052] For ease of explanation, the following example uses a rate limiting rule that configures a fingerprint ID and the rate limiting feature information of the first request that includes the fingerprint ID to illustrate the specific process of determining whether to rate limit the first request by combining the rate limiting feature information of the first request with the preset rate limiting rule.

[0053] In some embodiments, the first request may include one or more request indexes, such as for requesting one or more data tables. In this case, after determining that the request type of the first request belongs to a preset rate-limited request type (such as a Search request), that the IP address whitelist does not include the client IP address corresponding to the first request, and that at least one request index is not in the index whitelist, although the cloud or server cannot directly allow the entire request content of the first request, it can first sequentially determine whether each request index of the first request is in the index whitelist in order to determine whether the request content corresponding to a certain request index can be directly allowed.

[0054] Specifically, for a request index that is within the index whitelist, the client can directly access the data resource corresponding to that index. Conversely, for one or more request indexes not within the index whitelist (referred to as abnormal request indexes), the rate-limiting feature information corresponding to each abnormal request index can be obtained. This information is then matched against the rate-limiting rules to determine whether access to the data resource (such as a table) indicated by the abnormal request index is permitted. This avoids directly intercepting all client requests, thus achieving more granular and precise traffic control.

[0055] For example, if the first request includes four request indexes, namely request index A, request index B, request index C and request index D, which are used to indicate data table A1, data table B1, data table C1 and data table D1 respectively, and if none of the request feature information meets the preset release conditions mentioned in S12 above, the cloud or server can determine whether these four request indexes are in the index whitelist.

[0056] For example, if it is determined that request index A (as an example of the j-th request index, where j is a positive integer) and request index C (as an example of the j-th request index) are in the index whitelist, it means that the client can be allowed to access the data resource indicated by request index A (such as data table A1) and the data resource indicated by request index C (such as data table C1).

[0057] For example, if it is determined that request index B (as an example of the i-th request index, where i is a positive integer) and request index D (as an example of the i-th request index) are not in the index whitelist, then the rate limiting feature information corresponding to request index B (as an example of the first rate limiting feature information) can be obtained based on the client IP address of the first request, request index B, and the fingerprint ID of the first request. For example, the rate limiting feature information can be represented as {IP: ××, Index: B, ID: ××}. Similarly, based on the client IP address of the first request, request index D, and the fingerprint ID of the first request, the rate limiting feature information corresponding to request index D (as an example of the first rate limiting feature information) can be obtained. For example, the rate limiting feature information can be represented as {IP: ××, Index: D, ID: ××}.

[0058] Then, the rate-limiting feature information corresponding to request index B can be matched with the preset rate-limiting rules, and the client's access to the data resource indicated by request index B (such as data table B1) can be allowed or denied based on the matching result. Similarly, the rate-limiting feature information corresponding to request index D can be matched with the preset rate-limiting rules, and the client's access to the data resource indicated by request index D (such as data table D1) can be allowed or denied based on the matching result. For example, each rate-limiting rule can be represented as {IP: ××, Index: ××, ID: ××}. If a rate-limiting feature is not exactly the same as all the rate-limiting rules, the match fails, and the client can be directly allowed to access the data resource indicated by the request index in that rate-limiting feature. Conversely, if a rate-limiting feature is exactly the same as a rate-limiting rule, the match succeeds, and the rate-limiting policy can be executed. The rate-limiting policy includes allowing or blocking; for details, please refer to [reference needed]. Figure 2 As previously stated, I will not repeat myself.

[0059] Therefore, based on the above method, if none of the request feature information meets the preset release conditions mentioned in S12 and the entire request content of the first request cannot be directly released, it is also possible to determine whether the data resource indicated by a certain request index can be accessed at the request index level. In this way, it is possible to avoid directly intercepting all request content of the client, thereby achieving more granular and precise traffic control.

[0060] It is understood that in the above processing, the rate limiting rule is configured with a fingerprint ID, and the rate limiting feature information of the first request includes the fingerprint ID. In other embodiments, if the rate limiting rule is not configured with a fingerprint ID and the rate limiting feature information of the first request does not include a fingerprint ID, the same method can be used, except for the difference in the fingerprint ID, to determine whether to rate limit the first request by combining the rate limiting feature information of the first request with the preset rate limiting rule. This application will not elaborate on this further.

[0061] In summary, the rate limiting method provided in this application can combine multiple factors to determine whether to rate limit requests, enabling a more accurate and granular distinction between normal and abnormal requests, thus improving the accuracy of rate limiting for abnormal requests. Furthermore, rate limiting abnormal requests can prevent cluster CPU utilization spikes due to abnormal requests consuming excessive time slices, thereby improving cluster service response speed, ensuring timely responses to normal requests, and guaranteeing the overall availability of the cluster.

[0062] The following is combined Figure 2 The flowchart shown illustrates the specific processing logic of the rate limiting method mentioned in the embodiments of this application. For example, this rate limiting method can be applied to the cloud or a server. Figure 2 As shown, specifically, the method is as follows:

[0063] S21: Enable rate limiting function.

[0064] In some embodiments, after enabling the rate limiting function corresponding to the rate limiting method mentioned in this application, the following steps S22 to S219 can be executed to implement the rate limiting method provided in this application.

[0065] S22: Determine if the request type is a preset rate-limited request type. If yes, proceed to S23; otherwise, proceed to S219.

[0066] For example, developers can pre-set one or more rate-limited request types. For instance, rate-limited request types may include, but are not limited to, one or more request types such as Search request, Get request, BulkShard request, UpdateByQuery request, DeleteByQuery request, SearchScroll request, and SQL request.

[0067] In some embodiments, the first request can be parsed to obtain its request type. If the request type of the first request does not belong to a preset rate-limiting request type, it indicates that the first request is a normal request, and the distributed search engine cluster can directly allow the first request. Conversely, if the request type of the first request belongs to a preset rate-limiting request type, it indicates that the first request may be an abnormal request. In this case, S23 needs to be executed to further determine the first request.

[0068] S23: Determine if the client's IP address is in the IP address whitelist. If not, proceed to S24; if yes, proceed to S219.

[0069] For example, developers can also pre-set an IP address whitelist, which can include one or more client IP addresses. In this case, if the client IP address sending the first request is within the pre-set whitelist, it indicates that the first request is a normal request, and the distributed search engine cluster can directly allow it. Conversely, if the client IP address sending the first request is not within the pre-set whitelist, it indicates that the first request may be an abnormal request, and in this case, S24 needs to be executed to further determine the first request.

[0070] In some embodiments, if the distributed search engine cluster is an Elasticsearch (ES) cluster, the ES source code can be customized during the actual implementation process. The client IP address can be obtained from the header and added to the ActionRequest, so that the client IP address of the first request can be obtained when the first request is judged.

[0071] S24: Determine whether all requested indexes are in the index whitelist. If not, proceed to S25; if yes, proceed to S219.

[0072] For example, developers can also pre-set an index whitelist, which can include one or more request indexes. In this case, if all request indexes of the first request are within the pre-set IP address whitelist, the first request is considered a normal request, and the distributed search engine cluster can directly allow it. Conversely, if at least one request index of the first request is not within the pre-set index whitelist, the first request may be an abnormal request, and in this case, S25 needs to be executed for further evaluation of the first request.

[0073] S25: Determine whether the request type of the first request is a Search request and whether a fingerprint ID is configured in the rate limiting rule. If yes, proceed to S26; otherwise, proceed to S27.

[0074] In some embodiments, if the request type of the first request is a Search request and a fingerprint ID is configured in the rate limiting rule corresponding to the Search request, then S26 can be executed to calculate the request ID of the first request; otherwise, if the request type of the first request is not a Search request and / or there is no fingerprint ID in the rate limiting rule, then S27 can be executed to determine whether the first request is an SQL request.

[0075] S26: Calculate the fingerprint ID of the first request.

[0076] In some embodiments, when the first request is a Search request and the request ID of the first request (which can be called the JSON fingerprint ID) is calculated, the string of the first request (such as a JSON string) can first be deserialized into a structured object (such as a JSONObject object). Then, a depth-first search (DFS) process can be performed on the structured object to obtain the fingerprint template. The specific process of obtaining the fingerprint template is described below.

[0077] Specifically, we can first use the Depth-First Search (DFS) algorithm to visit all child nodes of the structured object layer by layer, and then process the leaf nodes (also called terminal nodes) to obtain the processed leaf nodes. For example, when traversing a leaf node, if the value of the leaf node is not an array type (such as String, Number, or Boolean), the value of the leaf node can be replaced with a preset mask symbol (such as replacing it with the mask symbol "?"). Another example is that if the value of a leaf node is an array and the array is not empty, all elements in the array except the first element can be removed, keeping only the first element. Yet another example is that if the value of a leaf node is an array and the array is empty, the empty array can be retained. In this way, by processing the leaf nodes, we can obtain the processed leaf nodes.

[0078] Then, a fingerprint template can be obtained based on the non-leaf nodes in the structured object and the processed leaf nodes. The structural topology of the non-leaf nodes can remain unchanged. It is understood that data anonymization can be performed before obtaining the fingerprint template to meet data privacy protection requirements; this application does not impose any limitations on this.

[0079] After obtaining the fingerprint template using the methods described above, the template can be parsed to extract all the keys, and then sorted lexicographically to obtain a normalized string. The normalized string can then be hashed to obtain the JSON fingerprint ID for the first request. For example, the SHA-256 secure hash algorithm can be used for cryptographic hashing, and the resulting fixed-length digest is the JSON fingerprint ID for the first request.

[0080] Thus, the JSON request ID of the first request can be calculated using the method described above.

[0081] S27: Determine whether the request type of the first request is an SQL request. If yes, proceed to S28; otherwise, proceed to S29.

[0082] S28: Calculate the fingerprint ID of the first request.

[0083] In some embodiments, when the first request is an SQL request and the request ID (which may be called the SQL fingerprint ID) of the first request is calculated, the SQL parameter values ​​in the first request can be replaced with a preset mask symbol (such as replacing it with the mask symbol "?") to obtain the request fingerprint. For example, if the first request includes "select id, name from test_index_1 where id = 3", the SQL parameter value "3" can be replaced with the mask symbol "?", thus obtaining the request fingerprint "select id, name from test_index_1 where id = ?". Then, a hash calculation can be performed on the request fingerprint to obtain the SQL fingerprint ID of the first request. For example, the secure hash algorithm SHA-256 can be used for cryptographic hash calculation, and the calculated fixed-length digest is the SQL fingerprint ID of the first request.

[0084] Thus, the SQL request ID of the first request can be calculated using the method described above.

[0085] S29: Are there any unprocessed request indexes? If yes, proceed to S210; otherwise, end the processing logic.

[0086] In some embodiments, the first request may include one or more request indexes, such as for requesting one or more data tables. In this case, it can be first determined whether each request index of the first request is within the index whitelist in order to determine whether the request content corresponding to a certain request index can be directly allowed. After all request indexes have been processed, the processing logic can be terminated.

[0087] S210: Determine whether the currently requested index is in the index whitelist. If yes, proceed to S211; otherwise, proceed to S212.

[0088] S211: Allow the client to access the data resource indicated by the currently requested index.

[0089] For details, please refer to the above. Figure 1 As described in S13, it will not be repeated here.

[0090] In some embodiments, after completing the relevant processing of the current requested index, it is also necessary to execute S29 to determine whether there are any unprocessed requested indexes.

[0091] S212: Obtain the rate limiting feature information corresponding to the current request index (as an example of the i-th request index) (as an example of the first rate limiting feature information).

[0092] In some embodiments, for one or more request indices not in the index whitelist (which may be referred to as abnormal request indices), the rate limiting feature information corresponding to each abnormal request index can be obtained. See the above for details. Figure 1 As described in S13, it will not be repeated here.

[0093] S213: Match the current limiting feature information with one or more preset current limiting rules to obtain the current limiter context.

[0094] The following example uses the first current limiting feature information, combined with... Figure 3 The process of matching first rate-limiting feature information with one or more preset rate-limiting rules to obtain the rate limiter context is described. For example, this method can be applied to the cloud or a server. Figure 3 As shown, specifically, the method is as follows:

[0095] S213a: Obtain the first rate limiting feature information and the preset rate limiting rules.

[0096] S213b: Are there any uncompared rate limiting rules? If yes, execute S213c; otherwise, execute S213i.

[0097] In some embodiments, the first rate limiting feature information can be matched with each rate limiting rule sequentially. If no match is found and there are still unmatched rate limiting rules, S213c can be executed to continue the comparison. If all matches fail and all comparisons are completed, the process can be terminated, and an empty rate limiter context can be obtained. For details, please refer to S213i below, which will not be elaborated here.

[0098] S213c: Determine whether the request index in the first rate limiting feature information matches the request index in the current rate limiting rule. If yes, execute S213d; otherwise, execute S213b.

[0099] In some embodiments, if the request index in the first rate limiting feature information matches (e.g., is the same) the request index in a rate limiting rule (such as the first rate limiting rule), then S213d can be executed to further determine whether other elements in the first rate limiting feature information are the same as other elements in the rate limiting rule. Conversely, if the request index in the first rate limiting feature information fails to match the request index in the current rate limiting rule, it indicates that the first rate limiting feature information fails to match the current rate limiting rule, and then S213b can be executed to match with the next rate limiting rule.

[0100] S213d: Determine whether the client IP address in the first rate limiting feature information matches the client IP address in the current rate limiting rule. If yes, execute S213e; otherwise, execute S213b.

[0101] In some embodiments, if the client IP address in the first rate limiting feature information matches (e.g., is the same) the client IP address in a rate limiting rule (such as the first rate limiting rule), then S213e can be executed to further determine whether other elements in the first rate limiting feature information are the same as other elements in the rate limiting rule. Conversely, if the client IP address in the first rate limiting feature information fails to match the client IP address in the current rate limiting rule, it indicates that the first rate limiting feature information fails to match the current rate limiting rule, and then S213b can be executed to match with the next rate limiting rule.

[0102] S213e: Determine whether the fingerprint ID in the first rate limiting feature information matches the fingerprint ID address in the current rate limiting rule. If yes, execute S213f; otherwise, execute S213b.

[0103] In some embodiments, if the fingerprint ID in the first rate limiting feature information matches (e.g., is the same) the fingerprint ID in a rate limiting rule (such as the first rate limiting rule), then S213f can be executed. Conversely, if the fingerprint ID in the first rate limiting feature information fails to match the fingerprint ID in the current rate limiting rule, it means that the first rate limiting feature information fails to match the current rate limiting rule, and then S213b can be executed to match with the next rate limiting rule.

[0104] S213f: Upon a request where the first rate limiting feature information successfully matches the first rate limiting rule, determine whether the first rate limiting rule contains a non-empty rate limiter context. If yes, execute S213g; otherwise, execute S213h.

[0105] In some embodiments, if, through the steps S213c to S213e described above, the request index, client IP address, and fingerprint ID in the first rate limiting feature information all match the request index, client IP address, and fingerprint ID in the first rate limiting rule, then the first rate limiting feature information and the first rate limiting rule are successfully matched. At this point, it can be determined whether the first rate limiting rule contains a non-empty rate limiter context. The rate limiter context information can refer to runtime environment information required to execute rate limiting, such as the current request number, time window information, etc.

[0106] S213g: Get a non-empty current limiter context.

[0107] In some embodiments, when it is determined through S213f above that the first rate limiting rule contains a non-empty rate limiter context, the non-empty rate limiter context can be obtained directly.

[0108] S213h: Generate a non-empty current limiter context.

[0109] In some embodiments, when it is determined by S213f above that the first rate limiting rule does not contain a non-empty rate limiter context, a non-empty rate limiter context can be initialized and generated.

[0110] S213i: Obtain an empty current limiter context.

[0111] In some embodiments, if the request index, client IP address, and fingerprint ID in the first rate limiting feature information fail to match the request index, client IP address, and fingerprint ID in each rate limiting rule, it indicates that the first rate limiting feature information fails to match each rate limiting rule, thereby obtaining an empty rate limiter context.

[0112] In summary, when matching the first rate-limiting feature information with each rate-limiting rule, if the first rate-limiting feature information successfully matches a certain rate-limiting rule (such as the first rate-limiting rule), a non-empty rate-limiter context can be obtained. If the first rate-limiting feature information fails to match any of the rate-limiting rules, an empty rate-limiter context can be obtained. Furthermore, after obtaining the rate-limiter context, step S213 can be executed to determine whether client access to the data resource indicated by the request index in the first rate-limiting feature information is allowed or denied based on the non-empty or empty rate-limiter context.

[0113] It is understood that S213a to S213i can be executed for any rate limiting feature information corresponding to any request index, and this application will not elaborate on this.

[0114] S214: Determine if the current limiter context is empty. If not, execute S215; if yes, execute S211.

[0115] In some embodiments, when the rate limiter context is empty, it indicates that the first rate limiting feature information fails to match each rate limiting rule, and S211 can be executed to directly allow the client to access the data resource indicated by the request index in the first rate limiting feature information.

[0116] S215: Obtain the current limiter corresponding to the current limiter context.

[0117] In some embodiments, when it is determined through the above S214 that the current limiter context is not empty, the current limiter (also referred to as the current limiter instance) corresponding to the current limiter context can be obtained.

[0118] S216: Determine if the current limiter is empty. If not, proceed to S217; if yes, proceed to S218.

[0119] In some embodiments, when the rate limiter is empty, an exception can be thrown directly and the client can be denied access to the data resource indicated by the currently requested index.

[0120] S217: Determine whether to rate-limit the request corresponding to the current request index. If yes, proceed to S218; otherwise, proceed to S211.

[0121] In some embodiments, when the rate limiter is not empty, it can be used to determine whether to rate-limit the request corresponding to the current request index. For example, concurrent token detection can be performed using rateLimiter.tryAcquire(). If token acquisition fails, it indicates that the request corresponding to the request index needs to be rate-limited. In this case, an exception can be thrown and the client's access to the data resource indicated by the current request index can be denied. Alternatively, if the token is successfully acquired, it indicates that the request corresponding to the current request index does not need to be rate-limited, and S211 can be executed to directly allow the client to access the data resource indicated by the request index in the first rate-limiting feature information. Here, concurrent token detection refers to controlling the number of requests that can pass simultaneously through a token bucket. If token acquisition fails, it indicates that the current number of concurrent requests has reached the rate-limiting threshold, and the system denies the execution of the current request or performs rate-limiting and waiting processing on the current request; if the token is successfully acquired, it indicates that the request can be executed.

[0122] S218: Throws an exception message.

[0123] For example, an HTTP 429 semantic exception can be thrown, such as an EsRejectedExecutionException.

[0124] In some embodiments, after completing the relevant processing of the current requested index, it is also necessary to execute S29 to determine whether there are any unprocessed requested indexes.

[0125] S219: The first request is determined to be a normal request.

[0126] In some embodiments, if the first request is a normal request, the distributed search engine cluster can directly allow the first request.

[0127] In summary, the rate limiting method provided in this application can combine multiple factors to determine whether to rate limit requests, enabling a more accurate and granular distinction between normal and abnormal requests, thus improving the accuracy of rate limiting for abnormal requests. Furthermore, rate limiting abnormal requests can prevent cluster CPU utilization spikes due to abnormal requests consuming excessive time slices, thereby improving cluster service response speed, ensuring timely responses to normal requests, and guaranteeing the overall availability of the cluster.

[0128] Furthermore, in some embodiments, this application also provides a readable storage medium storing instructions. When executed on an electronic device, the instructions cause the electronic device to implement the current limiting method mentioned in this application.

[0129] Furthermore, in some embodiments, this application also provides a computer program product, including computer instructions. These computer instructions, when executed on an electronic device, cause the electronic device to implement the current limiting method mentioned in this application.

[0130] Furthermore, in some embodiments, this application also provides an electronic device. The electronic device includes at least one memory and at least one processor, with the memory coupled to the processor. The memory stores computer program code / instructions, which, when executed by the processor, enable the electronic device to implement the current limiting method mentioned in this application.

[0131] For example, such as Figure 4 As shown, this application provides a structural schematic diagram of an electronic device, which may be, for example, a cloud platform or a server. Figure 4 As shown, the electronic device 400 includes a processor 401, a communication interface 402, a memory 403, and a communication bus 404.

[0132] The memory 403 stores a computer program that can run on the processor 401. The memory 403 and the processor 401 communicate through the communication interface 402 and the communication bus 404.

[0133] Processor 401 may include general-purpose processors, including central processing units, neural network processors, etc.; it may also be digital signal processing (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0134] The memory 403 may include random access memory (RAM) or non-volatile memory, etc. Optionally, the memory 403 may also be at least one storage device located remotely from the processor 401.

[0135] The communication bus 404 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. This communication bus 404 can be divided into an address bus, a data bus, a control bus, etc.

[0136] It should be noted that the connection method between units / modules in the accompanying drawings provided in this application is only one example. In other embodiments, units / modules can be directly connected via buses, signal lines, or connectors, or they can be indirectly connected.

[0137] Furthermore, some structural or methodological features may be shown in a specific arrangement and / or order in the accompanying drawings provided in this application. However, it should be understood that such a specific arrangement and / or order may not be necessary. For example, in other embodiments, these features may be arranged in a manner and / or order different from that shown in the drawings. In addition, including structural or methodological features in a particular figure does not imply that such features are required in all embodiments; for example, in other embodiments, these features may be omitted or may be combined with other features.

[0138] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0139] The embodiments disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0140] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried on or stored thereon by one or more transient or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors.

[0141] It should be noted that in the examples and description of this application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0142] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made thereto without departing from the scope of this application.

Claims

1. A current limiting method, characterized in that, include: The first request for accessing the distributed search engine cluster has been received. If at least one request feature information corresponding to the first request meets a preset release condition, the first request is released; the request feature information includes one or more of the following: request type, request index, and Internet Protocol IP address of the client that sent the first request; If none of the request feature information corresponding to the first request meets the preset allowable condition, the rate limiting feature information corresponding to the first request is matched with one or more preset rate limiting rules, and the first request is blocked or allowed based on the matching result; wherein, The rate limiting feature information includes the request feature information corresponding to the first request, or the rate limiting feature information includes the request feature information corresponding to the first request and the fingerprint ID of the first request, wherein the fingerprint ID of the first request is generated based on the request body content of the first request.

2. The method according to claim 1, characterized in that, The step of releasing the first request when at least one request feature information corresponding to the first request meets a preset release condition includes: If the request type of the first request does not belong to the preset rate-limited request type, allow the first request; or, If the client IP address corresponding to the first request is included in the preset IP address whitelist, the first request is allowed; wherein, the IP address whitelist includes one or more client IP addresses; or, If all request indices of the first request are within a preset index whitelist, the first request is allowed; wherein the index whitelist includes one or more request indices.

3. The method according to claim 2, characterized in that, When none of the request feature information corresponding to the first request meets the preset allowable condition, the rate limiting feature information corresponding to the first request is matched with one or more preset rate limiting rules, and the first request is blocked or allowed based on the matching result, including: If the request type of the first request belongs to the rate-limited request type, the IP address whitelist does not include the client IP address corresponding to the first request, and at least one request index of the first request is not in the index whitelist, the rate-limiting feature information corresponding to the first request is matched with one or more preset rate-limiting rules, and the first request is blocked or allowed according to the matching result.

4. The method according to claim 3, characterized in that, include: If the first request is a search request and the rate limiting rule corresponding to the search request has a fingerprint ID, the rate limiting feature information includes the request feature information corresponding to the first request and the fingerprint ID of the first request; or, If the request type of the first request is a Structured Query Language (SQL) request, the rate limiting feature information includes the request feature information corresponding to the first request and the fingerprint ID of the first request.

5. The method according to claim 4, characterized in that, Corresponding to the rate-limiting feature information including the request feature information corresponding to the first request and the fingerprint ID of the first request, the step of matching the rate-limiting feature information corresponding to the first request with one or more preset rate-limiting rules and blocking or allowing the first request based on the matching result when the request type of the first request belongs to the rate-limiting request type, the client IP address corresponding to the first request is not included in the IP address whitelist, and at least one request index of the first request is not in the index whitelist, includes: If the request type of the first request belongs to the rate-limiting request type, the IP address whitelist does not include the client IP address corresponding to the first request, and the i-th request index among the multiple request indices of the first request is not in the index whitelist, the first rate-limiting feature information corresponding to the i-th request index is obtained based on the client IP address corresponding to the first request, the i-th request index, and the fingerprint ID of the first request, where i is a positive integer; The first rate limiting feature information corresponding to the i-th request index is matched with one or more rate limiting rules, and the client is allowed or denied access to the data resource indicated by the i-th request index based on the matching result.

6. The method according to claim 5, characterized in that, include: If the request type of the first request belongs to the rate-limited request type, the IP address whitelist does not include the client IP address corresponding to the first request, at least one request index of the first request is not in the index whitelist, and the j-th request index among the multiple request indexes of the first request is in the index whitelist, then the client is allowed to access the data resource indicated by the j-th request index, where j is a positive integer.

7. The method according to claim 5, characterized in that, The step of matching the first rate-limiting feature information corresponding to the i-th request index with one or more rate-limiting rules, and allowing or denying the client access to the data resource indicated by the i-th request index based on the matching result, includes: The first rate limiting feature information is matched with one or more rate limiting rules; If the first rate limiting feature information is successfully matched with the first rate limiting rule in one or more rate limiting rules, a non-empty rate limiter context corresponding to the first rate limiting feature information is obtained. If the first rate limiting feature information fails to match any of the rate limiting rules in the one or more rate limiting rules, an empty rate limiter context is obtained. Based on the non-empty rate limiter context or the empty rate limiter context, allow or deny the client access to the data resource indicated by the i-th request index.

8. The method according to claim 7, characterized in that, When the first rate limiting feature information successfully matches the first rate limiting rule among one or more rate limiting rules, obtaining the non-empty rate limiter context corresponding to the first rate limiting feature information includes: If the i-th request index, client IP address, and fingerprint ID in the first rate limiting feature information all match the request index, client IP address, and fingerprint ID in the first rate limiting rule, then determine whether the first rate limiting rule contains the non-empty rate limiter context. If the first rate limiting rule contains the rate limiter context, obtain the non-empty rate limiter context; If the first rate limiting rule does not contain the rate limiter context, initialize and generate the non-empty rate limiter context; or, The step of obtaining an empty rate limiter context when the first rate limiting feature information fails to match any of the rate limiting rules in the one or more rate limiting rules includes: If the i-th request index, client IP address, and fingerprint ID in the first rate limiting feature information fail to match the request index, client IP address, and fingerprint ID in each of the rate limiting rules, an empty rate limiter context is obtained.

9. The method according to claim 7, characterized in that, The permission or denial of client access to the data resource indicated by the i-th request index based on the non-empty rate limiter context or the empty rate limiter context includes: When the rate limiter context corresponding to the first rate limiting feature information is empty, the client is allowed to access the data resource indicated by the i-th request index; If the current limiter context corresponding to the first current limiting feature information is not empty, obtain the current limiter corresponding to the current limiter context; and... If the rate limiter is empty, an exception message is thrown and the client is denied access to the data resource indicated by the i-th request index; When the rate limiter is not empty, the rate limiter determines whether to rate limit the request corresponding to the i-th request index; wherein... If rate limiting is applied to the request corresponding to the i-th request index, an exception is thrown and the client is denied access to the data resource indicated by the i-th request index.

10. The method according to claim 4, characterized in that, If the first request is a Search request and the rate limiting rule corresponding to the Search request contains a fingerprint ID, the fingerprint ID of the first request is generated in the following way: The string from the first request is deserialized into a structured object; A depth-first traversal is performed on the structured object to obtain a fingerprint template; The keys in the fingerprint template are sorted lexicographically to obtain a normalized string; The normalized string is hashed to obtain the fingerprint ID of the first request.

11. The method according to claim 10, characterized in that, The process of performing a depth-first traversal on the structured object to obtain a fingerprint template includes: The leaf nodes in the traversed structured object are processed to obtain the processed leaf nodes; The fingerprint template is obtained based on the non-leaf nodes in the structured object and the processed leaf nodes. The process of processing the traversed leaf nodes to obtain the processed leaf nodes includes: If the value of a leaf node encountered during traversal is not an array type, replace the value of the leaf node with a preset mask symbol to obtain the processed leaf node; and / or If the value of the leaf node encountered during traversal is an array and the array is not empty, retain the first element of the array and remove all other elements except the first element to obtain the processed leaf node; and / or, If the value of a leaf node encountered during traversal is an empty array, retain the empty array.

12. The method according to claim 4, characterized in that, If the first request is an SQL request, the fingerprint ID of the first request is generated in the following way: Replace the SQL parameters in the first request with preset mask symbols to obtain the request fingerprint; The fingerprint of the request is hashed to obtain the fingerprint ID of the first request.

13. An electronic device, characterized in that, include: At least one memory and at least one processor, the memory being coupled to the processor; the memory being used to store computer program code / instructions; when the computer program code / instructions are executed by the processor, causing the electronic device to implement the current limiting method as described in any one of claims 1 to 12.

14. A readable storage medium, characterized in that, The readable storage medium stores instructions that, when executed on an electronic device, cause the electronic device to implement the current limiting method as described in any one of claims 1 to 12.

15. A computer program product, characterized in that, include: Computer instructions, when executed on an electronic device, cause the electronic device to perform the current limiting method as described in any one of claims 1 to 12.

Images