Request processing method and apparatus, program, medium, and device

Abstract

The present disclosure provides a request processing method and apparatus, a program, a medium, and a device. The method comprises: in response to receiving one or more network requests sent by a client, determining whether an access token can be distributed to the one or more network requests, wherein the access token indicates the processing authority for the network request; and in response to determining that an access token is not distributed to a target network request among the one or more network requests, on the basis of the priority of the target network request, selectively rejecting to process the target network request. In this way, network requests can be prevented from being rejected indiscriminately, thereby improving user experience.

Description

Methods, apparatus, procedures, media, and devices for request processing Technical Field

[0001] The exemplary embodiments disclosed herein relate generally to the field of computers, and particularly to methods, apparatus, devices, computer-readable storage media, and computer program products for request processing. Background Technology

[0002] Service overload refers to a situation where a server or application exceeds its maximum processing capacity when handling requests, leading to performance degradation or malfunction. Typically, overloaded traffic can be rate-limited or rejected indiscriminately to protect the stability and availability of the server or application. However, when traffic has priority attributes, indiscriminate overload rejection often fails to meet practical needs. Summary of the Invention

[0003] In a first aspect of this disclosure, a method for request processing is provided. The method includes: in response to receiving one or more network requests sent by a client, determining whether the one or more network requests can be issued an access token, the access token indicating permission to process the network request; and in response to determining that a target network request among the one or more network requests has not been issued an access token, selectively denying processing of the target network request based on the priority of the target network request.

[0004] In a second aspect of this disclosure, an apparatus for request processing is provided. The apparatus includes: a determining module configured to, in response to receiving one or more network requests sent by a client, determine whether the one or more network requests can be issued an access token, the access token indicating permission to process the network request; and a processing module configured to, in response to determining that a target network request among the one or more network requests has not been issued an access token, selectively refuse to process the target network request based on the priority of the target network request.

[0005] In a third aspect of this disclosure, an electronic device is provided. The device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the device to perform the method of the first aspect.

[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program that can be executed by a processor to implement the method of the first aspect.

[0007] In a fifth aspect of this disclosure, a computer program product is provided. The computer program product includes computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method of the first aspect.

[0008] It should be understood that the content described in this content section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] The specific embodiments of this application are described in detail below with reference to the accompanying drawings, wherein:

[0010] Figure 1A shows a schematic diagram of an example environment in which embodiments of the present disclosure can be implemented;

[0011] Figure 1B shows a schematic diagram of an example of a rate limiter limiting network requests based on a rate limiting policy;

[0012] Figure 2 shows a schematic diagram of an example of a rate limiter limiting network requests based on a random policy;

[0013] Figure 3 illustrates a schematic diagram of an example of rate limiting for network requests according to some embodiments of the present disclosure;

[0014] Figure 4 illustrates a schematic diagram of a request processing procedure according to some embodiments of the present disclosure;

[0015] Figure 5 shows a flowchart of a request processing procedure according to some embodiments of the present disclosure;

[0016] Figure 6 illustrates a block diagram of a user request processing apparatus according to some embodiments of the present disclosure; and

[0017] Figure 7 shows a block diagram of an electronic device capable of implementing several embodiments of the present disclosure. Detailed Implementation

[0018] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0019] It should be noted that the headings of any section / subsection provided herein are not limiting. Various embodiments are described throughout this document, and embodiments of any type may be included under any section / subsection. Furthermore, embodiments described in any section / subsection may be combined in any way with any other embodiments described in the same section / subsection and / or different sections / subsections.

[0020] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0021] The embodiments of this disclosure may involve user data, data acquisition, and / or use. All of these aspects comply with applicable laws, regulations, and relevant provisions. In the embodiments of this disclosure, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, in implementing the embodiments of this disclosure, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained in accordance with relevant laws and regulations through appropriate means. The specific methods of notification and / or authorization may vary depending on the actual situation and application scenario, and the scope of this disclosure is not limited in this respect.

[0022] In this specification and the embodiments, any processing of personal information will be carried out only under the premise of legality (such as obtaining the consent of the personal information subject, or being necessary for the performance of a contract), and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information other than that necessary for basic functions will not affect the user's use of basic functions.

[0023] The following will describe in detail various example implementations of this scheme with reference to the accompanying drawings.

[0024] Example Environment

[0025] Figure 1A illustrates a schematic diagram of an example environment 100A in which embodiments of the present disclosure can be implemented. As shown in Figure 1A, the example environment 100A may include clients 110-1, 110-2, ..., 110-N and servers 130-1, 130-2, ..., 13-N. For ease of discussion, clients 110-1, 110-2, ..., 110-N may be collectively referred to as client 110 or individually as server 110, and servers 130-1, 130-2, ..., 130-N may be collectively referred to as server 130 or individually as server 130.

[0026] In environment 100A of Figure 1A, various types of applications 120 can run on client 110. Users can interact with applications 120 via client 110 and / or its attached devices.

[0027] In environment 100A of Figure 1A, if application 120 is active, it can send network requests to server 130 via client 110. Server 130 may run a rate limiter 140 and a counter 150. In case of service overload, the rate limiter 140 can restrict or deny network requests sent by client 110. The counter 150 can record the number of network requests passing through the rate limiter 140 or the number of network requests restricted or denied by the rate limiter 140. Figure 1B shows an example 100B of rate limiting network requests based on a rate limiting policy using the rate limiter 140. As shown in Figure 1B, in case of service overload on the server, the rate limiter 140 can selectively deny processing of some network requests based on a rate limiting policy. In some embodiments, the rate limiter 140 may include a distributed rate limiter.

[0028] In some embodiments, client 110 communicates with server 130 to provide services to application 120. Client 110 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, portable gaming terminals, VR / AR devices, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, client 110 can also support any type of user-facing interface (such as "wearable" circuitry).

[0029] Server 130 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. Server 130 may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. Server 130 can provide backend services for application 120 in client 110.

[0030] A communication connection can be established between the server 130 and the client 110. This communication connection can be established via wired or wireless means. The communication connection may include, but is not limited to, Bluetooth, mobile network, Universal Serial Bus (USB), and Wireless Fidelity (WiFi) connections; the embodiments of this disclosure are not limited in this respect. In the embodiments of this disclosure, the server 130 and the client 110 can achieve signaling interaction through their communication connection.

[0031] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure.

[0032] As mentioned above, when a service is overloaded, the rate limiter randomly limits or rejects traffic (network requests) indiscriminately to protect the stability and availability of the server or application. However, when network requests have priority attributes, for example, the impact of rejecting (failing) network request A is greater than the impact of rejecting (failing) network request B. Indiscriminate overload rejection often fails to meet actual needs.

[0033] Taking comment list requests as an example, they can be divided into two categories: normal requests (initiated by the user's click) and preloading requests (initiated by the client based on its own judgment). Preloading requests help users load comment data in advance. When a user clicks the comment button, the comment panel can be opened directly, significantly reducing data loading time and improving the user experience. If a preloading request fails, a normal request will be re-initiated to load the comment data when the user clicks the comment button. Therefore, the impact of a normal request failure on the user is greater than that of a preloading request. In this case, the priority of normal requests can be considered higher than that of preloading requests.

[0034] Referring to Figure 2, which illustrates an example 200 of a rate limiter applying a random policy to network requests, the rate limiter may reject ordinary requests using an indiscriminate overload rejection policy, causing these requests to fail. Ordinary requests have a higher priority than preloaded requests, and their rejection (failure) has a greater impact on the user. By employing a desired rate limiting policy, the rate limiter can reject preloaded requests, thereby mitigating the impact on the user.

[0035] Since preloading requests can significantly increase peak traffic (depending on the recall and precision of the preloading model), some overload protection mechanisms are needed to ensure the overall availability and stability of the server when server resources are insufficient.

[0036] To address this, embodiments of this disclosure propose a request processing scheme. The scheme includes: in response to receiving one or more network requests from a client, determining whether the one or more network requests can be issued an access token, the access token indicating processing authority for the network request; and in response to determining that a target network request among the one or more network requests has not been issued an access token, selectively rejecting processing of the target network request based on its priority. In this way, when a network request has not been issued an access token, on the one hand, rate limiting can be implemented based on the priority of the network requests; on the other hand, selective rejection of network requests based on their priority can prevent indiscriminate rejection, thereby improving user experience. Simultaneously, while allowing processing of high-priority requests, the processing capacity of the server is balanced by subsequently rejecting an equal number of low-priority requests. Furthermore, selective rejection of network requests based on their priority can prevent indiscriminate rejection, thereby improving user experience.

[0037] Example Interaction

[0038] Figure 3 illustrates a schematic diagram of a rate-limiting policy for network requests 300 according to some embodiments of the present disclosure. The rate-limiting policies provided in this disclosure will now be described in detail with reference to Figure 1.

[0039] As shown in Figure 3, after receiving one or more network requests from client 110, rate limiter 140 in server 130 determines whether one or more network requests can be issued access tokens. An access token indicates the processing permission for a network request. That is, if a network request can be issued an access token, rate limiter 140 can allow processing of the network request with an issued access token; if a network request is not issued an access token, rate limiter 140 can refuse processing of the network request without an issued access token.

[0040] When it is determined that a target network request among one or more network requests has not been issued an access token, the rate limiter 140 selectively rejects processing the target network request based on its priority. In some embodiments, network requests may include high-priority network requests and low-priority network requests. The rate limiting policy can selectively reject processing of network requests to minimize the impact on the user. For example, if rejecting a high-priority network request would have a greater impact on the user than rejecting a low-priority network request, then the rate limiter 140 can reject processing of the low-priority network request based on the desired rate limiting policy.

[0041] Figure 4 illustrates a schematic diagram of a request processing procedure 400 according to some embodiments of the present disclosure. The request processing procedure 400 provided by the present disclosure will now be described in detail with reference to Figure 1. The procedure 400 can be implemented at the server 130, particularly at the rate limiter 140 of the server 130.

[0042] In box 410, after receiving one or more network requests from client 110, server 130 requests a token from rate limiter 140. In some embodiments, the network request can be any type of request initiated by client 110, such as including but not limited to: data retrieval requests, data submission requests, resource update requests, resource deletion requests, resource retrieval requests, etc.

[0043] In some embodiments, the rate limiter can be implemented based on the Token Bucket Algorithm (TBA). In this document, the rate limiter may also be referred to as a "token bucket." It should be understood that the token bucket stores a certain number of access tokens, each indicating processing permission for a request. Access tokens in the token bucket can be generated at a fixed rate, and processing a request consumes access tokens. If there are access tokens in the token bucket, one access token can be removed from the token bucket, allowing processing of a request. If there are insufficient access tokens in the token bucket, the request will be rejected or blocked until an available access token becomes available in the token bucket.

[0044] In some embodiments, each server 130 may be configured with one or more token buckets, and all or some of the token buckets in the multiple servers 130 may constitute a distributed rate limiter. The number of access tokens in each token bucket may be a predetermined number, or it may be determined based on the load capacity of the server 130 (e.g., the number of requests processed per unit time).

[0045] Furthermore, in addition to setting one or more token buckets in each server 130, multiple sub-token buckets can be set based on multiple request types. Specifically, a sub-token bucket can be built for each request type, and the number of sub-access tokens contained in each sub-token bucket is determined based on the total number of access tokens and the priority of each of the multiple request types.

[0046] In some embodiments, the total number of sub-access tokens contained in the multiple sub-token buckets is the same as the total number of access tokens. In some embodiments, the priority of each request type is positively correlated with the number of sub-access tokens contained in the sub-token bucket corresponding to that request type. That is, with the total number remaining constant, the higher the priority of the request type, the more sub-access tokens are contained in the sub-token bucket corresponding to that request type.

[0047] Continuing with the comment list request example, assuming application 120 can display a first page and a second page, the first request for comment data on the first page has a higher priority than the second request for comment data on the second page. If the total number of access tokens is 1000, the number of sub-access tokens in the sub-token bucket corresponding to the first request can be 800, and the number of sub-access tokens in the sub-token bucket corresponding to the second request can be 200. It should be understood that the number of sub-access tokens in each sub-token bucket can be set as needed, as long as the priority of each request type is positively correlated with the number of sub-access tokens in the corresponding sub-token bucket.

[0048] After receiving one or more network requests from client 110, server 130 needs to request permission to process those requests, i.e., request an access token from the token bucket. It should be understood that if no sub-token bucket exists, server 130 only needs to request an access token for the network request from the token bucket. If a sub-token bucket exists, server 130 needs to request not only an access token from the token bucket but also a sub-access token from the sub-token bucket corresponding to the request type of the network request.

[0049] In box 420, server 130 determines whether the target network request in one or more network requests sent by client 110 has obtained the access token and the sub-access token in the sub-token bucket.

[0050] As mentioned above, without a sub-token bucket, server 130 only needs to determine whether the target network request in one or more network requests can obtain an access token from the token bucket to determine whether the target network request has obtained a token. With a sub-token bucket, server 130 needs to determine whether the target network request has obtained a token, specifically whether it has obtained an access token from the token bucket and whether it has obtained a sub-access token from the sub-token bucket corresponding to its request type. Only when the target network request has obtained both an access token and a sub-access token can it be determined that the target network request has obtained a token.

[0051] It's important to note that if there are a large number of network requests for a particular request type, causing all the sub-access tokens for that request type to be distributed, then even though all access tokens have been distributed, network requests that have received an access token but not a sub-access token are still considered to have not received a token.

[0052] In some embodiments, server 130 determines that a target network request among one or more network requests has obtained a token, i.e., the target network request has been issued a token, allowing processing of the target network request. In some embodiments, server 130 determines that a target network request among one or more network requests has not obtained a token, i.e., the target network request has not been issued a token (e.g., the number of requests processed by server 130 within a unit of time has reached its limit), and can selectively refuse processing of the target network request based on its priority. Here, "target network request not obtaining a token" means that, in the absence of a sub-token bucket, no access token has been issued; and, in the presence of a sub-token bucket, neither an access token nor any one of the sub-access tokens corresponding to the request type of the target network request has been issued simultaneously.

[0053] In box 430, if it is determined that the target network request has not obtained a token, the server 130 determines whether the target network request is a high-priority network request.

[0054] In some embodiments, each network request can be associated with a corresponding priority tag to identify the priority type of the network request. This priority tag can be added by the client 110 or determined by the server 130. For example, the priority tag can identify whether a network request belongs to high or low priority. For example, the client 110 can add a priority tag to a network request based on its type before sending it. For example, the server 130 can determine the priority tag of a network request based on its type. For example, a preloaded request can be identified as a low-priority request, while a non-preloaded network request can be identified as a high-priority request. High-priority network requests are sometimes referred to as high-priority requests, and low-priority network requests are sometimes referred to as low-priority requests. In some embodiments, the priority of a network request can be divided into more than two levels, and a priority tag can be used to identify whether a network request belongs to first priority, second priority, ..., Nth priority, etc., and to indicate the degree of priority of the first priority, second priority, ..., Nth priority. In this case, the priority level of the network request can be used to determine whether the network request is a high-priority request. For example, the second priority can be used as a reference. Network requests with a priority higher than the second priority can be identified as high-priority requests, and other network requests can be identified as low-priority requests.

[0055] In some embodiments, the priority of a network request can also be determined based on the impact on the user after the request is rejected. For example, if the impact on the user after network request A is rejected by server 130 is greater than the impact after network request B is rejected by server 130, the priority of network request A can be determined to be higher than that of network request B. In this case, network request A can be identified as a high-priority network request, and network request B as a low-priority network request. Of course, other suitable methods can be used to determine the priority of network requests, and the embodiments of this disclosure do not limit this.

[0056] In some embodiments, server 130 may also determine the priority of a target network request based on its source. Continuing with the example of the comment list request above, assuming the first page has a higher priority than the second page, after receiving the first request and the second request, server 130 can determine that the first request is a high-priority request and the second request is a low-priority request based on their sources.

[0057] Taking the priority of the target network request as an example, which includes a first priority and a second priority, and the first priority is higher than the second priority. In some embodiments, the server 130 may allow processing of the target network request in response to determining that the priority of the target network request is the first priority, or may refuse to process the target network request in response to determining that the priority of the target network request is the second priority.

[0058] Continuing with the comment list request example, a normal request (initiated by the user) has the highest priority, while a preload request (initiated by the client in advance) has the second highest priority. If neither the normal request nor the preload request has a token, server 130 can allow processing of a normal request upon receiving it; however, server 130 can refuse to process a preload request. Therefore, without scaling server 130, the comment preload strategy can be pushed to full, ensuring normal load levels for server 130 and downstream devices during peak periods.

[0059] In some embodiments, server 130 may allow processing of a target network request when it determines that no access token has been issued for the target network request and that the target network request is a high-priority request. Simultaneously, in block 440, server 130 may also record the number of target network requests allowed to be processed via counter 150. For example, server 130 may increment the counter value by the number of target network requests allowed to be processed. For instance, the counter value is incremented by 1 each time a target network request is allowed to be processed.

[0060] In box 450, when it is determined that the target network request is a low-priority network request, the server 130 checks whether the counter value is greater than 0. Whether the counter value is greater than 0 or not greater than 0, the server 130 will refuse to process the target network request.

[0061] In some embodiments, at block 460, in response to determining that a counter value is greater than 0 and that processing of a target network request is to be rejected, server 130 may reduce the counter value by the number of target network requests that are rejected. For example, the counter value is decremented by 1 each time a target network request is to be rejected.

[0062] In some embodiments, to prevent all received network requests from being high-priority requests, server 130 may continuously allow processing of network requests, thereby overloading server 130. Overloading can be avoided by setting a predetermined threshold for a counter value. In response to a counter value exceeding the predetermined threshold, server 130 may refuse to process target network requests for which no token has been distributed, thus preventing server 130 from becoming overloaded. For example, the predetermined threshold value may be set based on the load capacity of server 130 or based on the total number of access tokens in the token bucket.

[0063] In this way, when a network request does not receive a token, rate limiting can be implemented based on the request's priority. Furthermore, network requests can be selectively rejected based on their priority, preventing indiscriminate rejection and improving user experience. Simultaneously, while allowing high-priority requests, the server's processing capacity is balanced by subsequently rejecting an equal number of low-priority requests. The ability to selectively reject network requests based on their priority further enhances user experience.

[0064] Example process

[0065] Figure 5 shows a flowchart of a request processing procedure 500 according to some embodiments of the present disclosure. Procedure 500 can be implemented at server 130. Procedure 500 will now be described with reference to Figure 1.

[0066] In box 510, server 130, in response to receiving one or more network requests from client 110, determines whether one or more network requests can be issued an access token, which indicates permission to process the network request.

[0067] In box 520, server 130, in response to determining that a target network request among one or more network requests has not been issued an access token, selectively refuses to process the target network request based on its priority.

[0068] In some embodiments, selectively denying processing of a target network request based on its priority includes: allowing processing of the target network request in response to determining that the target network request has a first priority, or denying processing of the target network request in response to determining that the target network request has a second priority, wherein the first priority is higher than the second priority.

[0069] In some embodiments, process 500 further includes: in response to allowing processing of a target network request, incrementing a counter value by the number of target network requests that are allowed to be processed; and in response to determining that the counter value is greater than 0 and that processing of the target network request is to be rejected, decrementing the counter value by the number of target network requests that are rejected to be processed.

[0070] In some embodiments, process 500 further includes: rejecting processing of a target network request for which no access token has been issued in response to a counter value exceeding a predetermined threshold.

[0071] In some embodiments, process 500 further includes: in response to a target network request being issued an access token, allowing processing of the target network request.

[0072] In some embodiments, process 500 further includes: constructing multiple sub-token buckets corresponding to multiple request types; and determining the number of sub-access tokens contained in each of the multiple sub-token buckets based on the total number of access tokens and the priority of each of the multiple request types.

[0073] In some embodiments, the priority of each request type is positively correlated with the number of sub-access tokens contained in the sub-token bucket corresponding to the request type.

[0074] In some embodiments, the total number of sub-access tokens contained in the multiple sub-token buckets is the same as the total number of access tokens.

[0075] In some embodiments, selectively denying processing of a target network request based on its priority includes: in response to receiving one or more network requests, determining whether the one or more network requests can be distributed with sub-tokens from multiple sub-token buckets based on the request type of each of the one or more network requests; and in response to determining that the target network request has not been distributed with an access token or in response to determining that the target network request has not been distributed with a sub-access token from any sub-token bucket, selectively denying processing of the target network request based on its priority.

[0076] In some embodiments, process 500 further includes: in response to determining that the target network request has been issued an access token and also a sub-access token from any sub-token bucket, allowing processing of the target network request.

[0077] Example devices and equipment

[0078] Embodiments of this disclosure also provide corresponding apparatus for implementing the methods or processes described above. Figure 6 shows a block diagram of a user request processing apparatus 600 according to some embodiments of this disclosure. Apparatus 600 may be implemented as or included in server 130. The various modules / components in apparatus 600 may be implemented by hardware, software, firmware, or any combination thereof.

[0079] The apparatus 600 includes: a determining module 610 configured to, in response to receiving one or more network requests sent by a client, determine whether one or more network requests can be issued an access token, the access token indicating permission to process the network request; and a processing module 620 configured to, in response to determining that a target network request among the one or more network requests has not been issued an access token, selectively deny processing of the target network request based on the priority of the target network request.

[0080] In some embodiments, the processing module 620 is further configured to allow processing of the target network request in response to determining that the priority of the target network request is a first priority, or to refuse processing of the target network request in response to determining that the priority of the target network request is a second priority, wherein the first priority is higher than the second priority.

[0081] In some embodiments, the apparatus 600 further includes a counting module configured to increment a counter value by the number of target network requests allowed to be processed in response to allowing processing of the target network request; and to decrement the counter value by the number of target network requests rejected in response to determining that the counter value is greater than 0 and that processing of the target network request is to be rejected.

[0082] In some embodiments, the processing module 620 is further configured to refuse processing of a target network request for which no access token has been issued in response to a counter value exceeding a predetermined threshold.

[0083] In some embodiments, the processing module 620 is further configured to distribute an access token in response to a target network request, allowing processing of the target network request.

[0084] In some embodiments, the apparatus 600 further includes a construction module configured to construct a plurality of sub-token buckets corresponding to a plurality of request types; and to determine the number of sub-access tokens contained in each of the plurality of sub-token buckets based on the total number of access tokens and the priority of each of the plurality of request types.

[0085] In some embodiments, the priority of each request type is positively correlated with the number of sub-access tokens contained in the sub-token bucket corresponding to the request type.

[0086] In some embodiments, the total number of sub-access tokens contained in the multiple sub-token buckets is the same as the total number of access tokens.

[0087] In some embodiments, the processing module 620 is further configured to, in response to receiving one or more network requests, determine whether one or more network requests can be distributed with sub-tokens from multiple sub-token buckets based on the request type of each of the one or more network requests; and, in response to determining that the target network request has not been distributed with an access token or in response to determining that the target network request has not been distributed with a sub-access token from any sub-token bucket, selectively reject the processing of the target network request based on the priority of the target network request.

[0088] In some embodiments, the processing module 620 is further configured to allow processing of the target network request in response to determining that an access token has been distributed to the target network request and that a sub-access token from any sub-token bucket has also been distributed.

[0089] Figure 7 illustrates a block diagram of an electronic device 700 in which one or more embodiments of the present disclosure may be implemented. It should be understood that the electronic device 700 shown in Figure 7 is merely exemplary and should not constitute any limitation on the functionality and scope of the embodiments described herein. The electronic device 700 shown in Figure 7 may be included in or implemented as the server 130 of Figure 1.

[0090] As shown in Figure 7, the electronic device 700 is in the form of a general-purpose electronic device. Components of the electronic device 700 may include, but are not limited to, one or more processors or processing units 710, memory 720, storage devices 730, one or more communication units 740, one or more input devices 750, and one or more output devices 760. The processing unit 710 may be a physical or virtual processor and is capable of performing various processes according to programs stored in the memory 720. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of the electronic device 700.

[0091] Electronic device 700 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 700, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 720 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 730 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data and can be accessed within electronic device 700.

[0092] Electronic device 700 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 7, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks may be provided. In these cases, each drive may be connected to a bus (not shown) via one or more data media interfaces. Memory 720 may include computer program product 725 having one or more program modules configured to perform various methods or actions of various embodiments of the present disclosure.

[0093] The communication unit 740 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 700 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 700 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0094] Input device 750 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 760 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 700 can also communicate with one or more external devices (not shown) via communication unit 740 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 700, or with any device that enables electronic device 700 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interface (not shown).

[0095] According to an exemplary implementation of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to an exemplary implementation of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0096] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0097] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0098] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0099] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0100] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for request processing, comprising: In response to receiving one or more network requests from a client, determine whether the one or more network requests can be issued an access token, the access token indicating permission to process the network request; as well as In response to determining that the target network request among the one or more network requests has not been issued the access token, processing of the target network request is selectively denied based on the priority of the target network request.

2. The method of claim 1, wherein selectively rejecting processing of the target network request based on its priority includes: In response to determining that the priority of the target network request is first priority, processing of the target network request is permitted, or In response to determining that the priority of the target network request is the second priority, processing of the target network request is rejected, wherein the first priority is higher than the second priority.

3. The method according to claim 1, further comprising: In response to allowing processing of the target network request, the counter value is incremented by the number of target network requests that are allowed to be processed; In response to determining that the counter value is greater than 0 and that processing of the target network request should be rejected, the counter value is reduced by the number corresponding to the rejected target network requests.

4. The method according to claim 3, further comprising: In response to the counter value exceeding a predetermined threshold, processing of the target network request for which the access token has not been issued is rejected.

5. The method according to claim 1, further comprising: In response to the target network request, the access token is issued, allowing processing of the target network request.

6. The method according to claim 1 or 5, further comprising: Construct multiple sub-token buckets corresponding to multiple request types; as well as Based on the total number of access tokens and the respective priorities of the multiple request types, the number of sub-access tokens contained in each of the multiple sub-token buckets is determined.

7. The method of claim 6, wherein the priority of each request type is positively correlated with the number of sub-access tokens contained in the sub-token bucket corresponding to the request type.

8. The method of claim 6, wherein the total number of sub-access tokens contained in the plurality of sub-token buckets is the same as the total number of access tokens.

9. The method of claim 6, wherein selectively rejecting processing of the target network request based on its priority comprises: In response to receiving the one or more network requests, based on the request type of each of the one or more network requests, it is determined whether the one or more network requests can be distributed with sub-tokens from the multiple sub-token buckets; as well as In response to determining that the target network request has not been issued the access token or in response to determining that the target network request has not been issued a sub-access token in any sub-token bucket, processing of the target network request may be selectively denied based on the priority of the target network request.

10. The method of claim 9, further comprising: In response to determining that the target network request is issued the access token and also a sub-access token from any sub-token bucket, processing of the target network request is permitted.

11. An apparatus for request processing, comprising: The determination module is configured to, in response to receiving one or more network requests from a client, determine whether the one or more network requests can be issued an access token, the access token indicating permission to process the network request; as well as The processing module is configured to, in response to determining that a target network request among the one or more network requests has not been issued the access token, selectively deny processing of the target network request based on the priority of the target network request.

12. An electronic device, comprising: At least one processing unit; as well as At least one memory is coupled to at least one processing unit and stores instructions for execution by the at least one processing unit, which, when executed by the at least one processing unit, cause the electronic device to perform the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, the computer program being executable by a processor to implement the method according to any one of claims 1 to 10.

14. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method according to any one of claims 1 to 10.

Images