WO2024088079A1 - Request processing method and system - Google Patents

Abstract

Provided in the embodiments of the description are a request processing method and system. The request processing method is applied to the request processing system. The system comprises an allocation node and at least two task processing nodes. The method comprises: an allocation node receiving at least two requests to be processed, and receiving task response messages sent by at least two task processing nodes, wherein the task response messages carry a task processing weight; and on the basis of the task processing weights and the at least two requests to be processed, allocating a corresponding set of requests to be processed to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes; and the first task processing node performing task processing on the requests to be processed in the received set of requests to be processed, updating the task processing weights according to the current processing state information in the task processing process, and sending the updated task processing weights to the allocation node on the basis of the task response messages.

Description

Request processing method and system

This application claims priority to the Chinese patent application filed with the China Patent Office on October 24, 2022, with application number 202211304750.9 and application name “Request Processing Method and System”, all contents of which are incorporated by reference in this application.

Technical Field

The embodiments of this specification relate to the field of computer technology, and in particular to a request processing method.

Background technique

With the continuous development of Internet technology, a server may need to call other servers to process the request after receiving it. When the server distributes the request to other servers, in order to improve the request processing efficiency, it will adopt a load balancing method to distribute the corresponding request to each server according to its current processing status.

In the prior art, the server monitors the current processing status of other servers, but this method has a delay problem, resulting in the server being unable to understand the current processing status of other servers in a timely manner, thereby reducing the request processing efficiency.

Summary of the invention

In view of this, an embodiment of this specification provides a request processing method. One or more embodiments of this specification also involve a request processing system, two other request processing methods, two request processing devices, a computing device, a computer-readable storage medium and a computer program to solve the technical defects existing in the prior art.

According to a first aspect of an embodiment of this specification, a request processing method is provided, which is applied to a request processing system, the system comprising a distribution node and at least two task processing nodes, the method comprising:

The allocation node receives at least two pending requests and receives a task response message sent by the at least two task processing nodes, wherein the task response message carries a task processing weight; and

Based on the task processing weight and the at least two pending requests, assigning a corresponding pending request set to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes;

The first task processing node performs task processing on the pending request in the received pending request set, updates the task processing weight according to the current processing status information during the task processing, and sends the updated task processing weight to the allocation node based on the task response message.

According to a second aspect of an embodiment of this specification, a request processing system is provided, the system comprising a distribution node and at least two task processing nodes, wherein:

The allocation node is configured to receive at least two pending requests and receive a task response message sent by the at least two task processing nodes, wherein the task response message carries a task processing weight; and

Based on the task processing weight and the at least two pending requests, assigning a corresponding pending request set to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes;

The first task processing node is configured to perform task processing on the pending requests in the received pending request set, update the task processing weight according to the current processing status information during the task processing, and send the updated task processing weight to the allocation node based on the task response message.

According to a third aspect of an embodiment of this specification, a request processing method is provided, which is applied to a task processing node, including:

Generate a task response message based on the task processing weight, and send the task response message to the allocation node;

receiving a set of pending requests determined by the allocation node for the task processing node, wherein the set of pending requests is determined by the allocation node based on the task processing weight and at least two pending requests received;

Performing task processing on the pending requests in the received pending request set, and updating the task processing weight according to current processing status information during the task processing;

The updated task processing weight is sent to the allocation node based on the task response message.

According to a fourth aspect of an embodiment of this specification, a request processing device is provided, which is applied to a task processing node, including:

A first sending module is configured to generate a task response message based on the task processing weight, and send the task response message to the allocation node;

A receiving module, configured to receive a set of pending requests determined by the allocation node for the task processing node, wherein the set of pending requests is determined by the allocation node based on the task processing weight and at least two pending requests received;

A processing module, configured to perform task processing on the pending requests in the received pending request set, and update the task processing weight according to current processing status information during the task processing;

The second sending module is configured to send the updated task processing weight to the allocation node based on the task response message.

According to a fifth aspect of an embodiment of this specification, a request processing method is provided, which is applied to an allocation node, including:

receiving at least two pending requests and receiving task response messages sent by at least two task processing nodes, wherein the task response messages carry task processing weights;

Based on the task processing weight and the at least two pending requests, a corresponding pending request set is allocated to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes.

According to a sixth aspect of an embodiment of this specification, a request processing device is provided, which is applied to an allocation node, including:

A receiving module is configured to receive at least two pending requests and receive at least two task processing nodes. A task response message, wherein the task response message carries a task processing weight;

The allocation module is configured to allocate a corresponding set of pending requests to a first task processing node among the at least two task processing nodes based on the task processing weight and the at least two pending requests, wherein the first task processing node is one of the at least two task processing nodes.

According to a seventh aspect of an embodiment of this specification, there is provided a computing device, including:

Memory and processor;

The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the above request processing method are implemented.

According to an eighth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the above-mentioned request processing method are implemented.

According to a ninth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned request processing method.

A request processing method provided in an embodiment of the present specification is applied to a request processing system, wherein the system includes an allocation node and at least two task processing nodes, and the method includes: the allocation node receives at least two pending requests, and receives a task response message sent by the at least two task processing nodes, wherein the task response message carries a task processing weight; and based on the task processing weight and the at least two pending requests, allocates a corresponding set of pending requests to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes; the first task processing node performs task processing on the pending requests in the received set of pending requests, updates the task processing weight according to current processing status information during the task processing, and sends the updated task processing weight to the allocation node based on the task response message.

Specifically, the task processing node of the method will actively send the task processing weight determined according to the current processing status information in the task processing process to the allocation node; and the allocation node will quickly and accurately determine the current processing status of each task processing node based on the task processing weight, avoiding delay problems; and when receiving pending requests, it will allocate the pending requests to the corresponding task processing nodes based on the current processing status of each task processing node, thereby improving request processing efficiency.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of request allocation provided by an embodiment of this specification;

FIG2 is an application diagram of a request processing method provided by an embodiment of this specification;

FIG3 is a flow chart of a request processing method provided by an embodiment of this specification;

FIG4 is a schematic diagram of a concurrent growth rate change of an abnormal server in a request processing method provided by an embodiment of this specification;

FIG5 is a schematic diagram of changes in the number of concurrent requests under different functions of a request processing method provided by an embodiment of this specification;

FIG6 is a schematic diagram of a processing process of a request processing method provided by an embodiment of this specification;

FIG7 is a schematic diagram of the number of concurrent requests on a single machine in a request processing method provided by an embodiment of this specification;

FIG8 is a flowchart of another request processing method provided by an embodiment of this specification;

FIG9 is a flowchart of another request processing method provided by an embodiment of this specification;

FIG10 is a schematic diagram of the structure of a request processing system provided by an embodiment of the present specification;

FIG. 11 is a structural block diagram of a computing device provided by an embodiment of the present specification.

Detailed ways

Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

First, the terms involved in one or more embodiments of this specification are explained.

Service concurrency: The number of instantaneous requests that the server is processing at a certain moment.

Request rate: The total number of requests sent within a certain period of time.

Response speed: The time it takes for a single request to be processed from the beginning to the completion.

Load balancing: Select an optimal address from multiple addresses through a certain algorithm, and when the request volume reaches a certain level, the maximum utilization of all address resources can be achieved.

With the continuous development of Internet technology, a server may need to call other servers to process the request after receiving it; and when the server distributes the request to other servers, in order to improve the efficiency of request processing, it will adopt a load balancing method to distribute the corresponding request to each server according to its current processing status. For example, for most microservice applications, a service provided by a server often needs to act as a consumer and rely on several other services to process the requests it receives, and most services that expose data management capabilities to the outside world need to rely on databases for processing. Refer to Figure 1, which is a request allocation diagram for an order service provided by an embodiment of the present specification; based on part A of Figure 1, it can be seen that the order server relies on a service of the inventory server for inventory deductions, and the inventory server needs to rely on the database for data persistence. Among them, QPS is the request rate, and the ms is the response rate. However, in a production environment, problems such as slow processing from the database and network jitter may cause the services provided by the inventory server to be blocked, resulting in a significant increase in instantaneous concurrency, which will bring extremely serious pressure to the machine and even cause the service to crash. As shown in part B of Figure 1, part B of Figure 1 simulates the request processing in a scenario where the database has a slow processing problem. When there is a problem with the database connection of inventory server A, a single request takes 2000ms to process, which will cause the instantaneous concurrency of inventory service A to reach 840, that is, the dotted part of the figure, causing the upstream order service to even increase from 80 concurrency to 880 concurrency. Half of the user requests take more than 2100ms to process, which has adverse effects on both the user's request experience and the stability of the entire system. Therefore, it can be seen that for most microservice applications, if the server processing performance jitters, the instantaneous concurrency of the server will instantly rise to a very high level due to the slow overall request processing, directly leading to consequences such as service unavailability and even service avalanche.

Based on this, this manual provides three solutions to the problem of instantaneous concurrency growth caused by server-side blocking, namely, a direct unlimited solution, a maximum concurrency limit setting solution, and a load balancing scheduling solution from the client perspective.

However, the above solutions may cause the server to be blocked and cause the instantaneous concurrency to increase. The solution of setting the maximum concurrency limit means that when the instantaneous concurrency of the server reaches a certain amount, it will refuse to accept new requests. This solution sacrifices a certain number of successful requests to ensure the overall performance of the application. This solution will reject new requests after the limit is reached, which will bring a bad experience to users.

The other is to allow the concurrency to increase without any restrictions. The unrestricted solution means that when the concurrency of a single service increases, the processing pool will continue to expand to meet the concurrency needs. Since there is no limit on the expansion, when the number of concurrent requests increases, it will bring certain pressure to the provider. As the pressure increases, the overall processing time of all services will also increase. When the concurrency reaches a certain level, it is likely to cause memory overflow in the process. As shown in part C of Figure 1, the maximum concurrency is set to 100. It can be seen that about 352 requests are rejected per second, which means that the overall concurrency of applications on the entire link will not be particularly high. There are two ways to limit the maximum concurrency. One is that each service has a dedicated concurrency, and the other is that multiple services share a concurrency. If the exclusive concurrency method has a large limit value, it will still cause problems such as memory overflow when multiple services are blocked. If the limit value is too small, it is not suitable for some IO-intensive services. In the shared mode, if a service is blocked, other services in the same service group will not be able to receive new requests, affecting normal requests. Generally, exclusive concurrency is not used by default, and only support based on custom configuration is provided. Therefore, the maximum concurrency limit solution has two major disadvantages: first, it will cause the number of successful requests to decrease, which will bring a bad experience to users; second, abnormal services will also affect normal services when they are restricted, expanding the impact.

The third method is to perform load balancing scheduling from the client's perspective. Load balancing scheduling from the client's perspective means that the consumer perceives the server's indicators such as response time, and selects the optimal server for service granularity on the consumer's single machine. Common algorithms include the minimum active number algorithm and the fastest response algorithm. However, since these algorithms can only schedule traffic from the perspective of a single machine on the consumer's end, they cannot understand the actual single-machine performance of each server in a timely and efficient manner. In addition, algorithms such as the minimum active number and the fastest response rely on similar indicators such as machine configuration and response time within the cluster to be more accurate. It is easy to make misjudgments in complex colocation scenarios.

Based on this, in this specification, a request processing method is provided. This specification also involves a request processing system, another request processing method, a request processing apparatus, a computing device, and a computer-readable storage medium, which are described in detail one by one in the following embodiments.

Referring to FIG. 2, FIG. 2 shows an application schematic diagram of a request processing method provided according to an embodiment of the present specification. It should be noted that the request processing method provided in the present specification adopts a dynamic weight push method, and reduces the call speed of the problematic server by weight scheduling while ensuring that the maximum number of concurrent connections does not exceed expectations. Under the premise of avoiding directly throwing an exception to cause trouble to the user, it can be ensured that the pressure of a single server will not exceed the upper limit. Based on this, referring to FIG. 2, the request processing method provided in the present specification adds a data path of the weight size returned from the server to the consumer in the call link between the order server (which can be used as the consumer) and the inventory server. When the server load is high, the inventory server can push the downgrade weight to the consumer through this data path according to the downgrade weight determined by its own load situation. The next time the consumer initiates a call to multiple inventory servers based on the order request sent by the client, this new weight will be used to distribute the order request, thereby reducing the number of requests received by the server with high load or abnormality, and realizing load balancing. Based on this, this manual provides a request processing method that aims to perform intelligent traffic scheduling of the cluster by reversely pushing adaptive degradation weights through the server, realize service degradation isolation of abnormal single-machine nodes, prevent unlimited expansion of resource occupation, achieve rapid fault convergence, and significantly reduce the impact on users.

Refer to Figure 3, which shows an application flow chart of a request processing method provided according to an embodiment of this specification. The request processing method is applied to a request processing system, the system includes a distribution node and at least two task processing nodes, and the method specifically includes the following steps.

Step 302: The allocation node receives at least two pending requests and receives a task response message sent by the at least two task processing nodes, wherein the task response message carries a task processing weight; and based on the task processing weight and the at least two pending requests, allocates a corresponding set of pending requests to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes.

Among them, the task processing node can be understood as a node that can process pending requests. The task processing node can be a task processing server, for example, the above-mentioned inventory server, logistics server, etc., and the server can be one or more servers. The distribution node can be understood as a server that can distribute the pending requests received or generated by itself to the task processing node associated with it. The distribution node can also be called a consumer end. For example, the distribution node can be the above-mentioned order server, and the order server can receive order requests sent by users through user terminals. Pending requests can be understood as user requests sent by users to the distribution node through terminals, such as order requests, data acquisition requests, etc. Alternatively, the pending request can also be understood as a request generated by the distribution node according to the user request sent by the user. For example, after the user sends a shopping order request to it, the order server needs to send a deduction request to the inventory server after processing the shopping order request, so as to deduct the inventory quantity of the product by calling the service of the inventory server. Avoid the situation where the user places an order after the product is sold out and the inventory quantity has not been reduced. The problem of not being able to obtain goods. The pending request set can be understood as a set consisting of a specific number of pending requests.

The task response message can be understood as a message sent by the task processing node to the allocation node through the data path between the task processing node and the allocation node, and the message carries the task processing weight.

The task processing weight can be understood as a parameter that characterizes the request processing capability of the task processing node itself. The parameter can be any value within a value range, such as any value within the value range of [0,1] or [0,100]. In other words, the task processing node generates a task processing weight based on the current task processing information during its own task processing process. The task processing weight is used to characterize the information about the task processing status of the task processing node itself. It should be noted that in the request processing method provided in this specification, the task processing weight is calculated by the task processing node itself and fed back to the allocation node. Thereby, the channel for feedback from the server to the consumer is opened up by reversely pushing the weight, which provides feasibility for the server to protect itself.

The following uses the application of the request processing method in an e-commerce scenario as an example to illustrate the request processing method, wherein the allocation node is the order server, the task processing node is the inventory server, the pending request is a request for inventory reduction, and the task processing weight can be the weight corresponding to each inventory server. Based on this, the inventory server will determine its own weight based on the current processing status information during its own inventory reduction processing; then generate a weight adjustment message based on the weight information, and send the weight adjustment message to the order server.

The order server receives the weight adjustment message sent by each inventory server, and determines the weight of each inventory server from the weight adjustment message. When a shopping order processing request for a product is received from a user through a client, a request for deduction of inventory for the product is generated, wherein the number of the shopping order processing request is consistent with the number of the request for deduction of inventory. Afterwards, the order server will allocate a specific number of deduction of inventory requests to each inventory server according to the weight of each inventory server, and allocate and send the deduction of inventory requests to the corresponding inventory server. In other words, the request processing method provided in this specification is that the inventory server feeds back its own pressure information by pushing weights, thereby avoiding the problem of reducing the success rate of the service due to direct rejection of the request, ensuring that normal services can continue to be processed, and isolating faults within a single service.

In one embodiment provided in this specification, the request processing method provided in this specification, in the process of request allocation, determines a corresponding number of pending requests for each task processing node according to the task processing weight that characterizes the current processing state of each task processing node, and allocates them to the corresponding task processing node, thereby achieving load balancing for the task processing nodes and realizing intelligent traffic scheduling of the cluster. Specifically, the first task processing node among the at least two task processing nodes allocates the corresponding set of pending requests, including:

The allocation node determines, based on a task processing weight of a first task processing node among the at least two task processing nodes, request set information corresponding to the first task processing node;

Based on the request set information and the at least two pending requests, a pending request set corresponding to the first task processing node is constructed, and the pending request set is sent to the first task processing node.

The request set information can be understood as information for constructing the request set information. The information can be used to indicate the number of pending requests that need to be allocated to each task processing node.

Specifically, determining the request set information corresponding to the first task processing node among the at least two task processing nodes based on the task processing weight of the first task processing node includes:

The allocation node determines a first task processing node among the at least two task processing nodes, and determines a task processing weight of the first task processing node;

Based on the request quantities of the at least two pending requests, the node quantities of the at least two task processing nodes, and the task processing weight, the request processing quantity of the first task processing node is determined, and the request processing quantity is used as request set information.

Specifically, in order to achieve load balancing for task processing nodes and intelligent traffic scheduling of the cluster, the allocation node needs to first determine the first task processing node from at least two task processing nodes in the process of determining the corresponding request processing quantity for each task processing node, and then determine the task processing weight of the first task processing node from the task processing weights recorded by itself.

Afterwards, the allocation node needs to determine the request quantity of the at least two pending requests and the node number of at least two task processing nodes; then based on the request quantity, the node number, and the task processing weight of the first task processing node, calculate the request processing quantity of the pending requests that need to be allocated to it for the task processing weight, and determine the request processing quantity as the request set information required to construct the pending request set.

Using the above example, when the order server determines the number of requests to be allocated to the inventory server, it needs to determine the weight of the inventory server A; then determine the total number of inventory reduction requests and the total number of inventory servers; based on the weight of the inventory server A, the total number of inventory reduction requests, and the total number of inventory servers, calculate the number of requests that the inventory server A needs to allocate. In actual applications, the calculation of the number of requests can be obtained by the following formula (1).

Among them, A represents the total request rate of the order server (consumer end), that is, the number of orders, and B represents the total number of inventory servers. DeWeight represents the weight of each inventory server. The number of requests allocated to each warehouse server can be called the request rate of the inventory server; among them, a normal inventory server can be understood as an inventory server with a weight of 1, and an abnormal inventory server can be understood as an inventory server with a weight less than 1. Based on this, the abnormal inventory server request rate H is downgraded to The normal server request rate is

It should be noted that the request processing method provided in this specification determines the number of requests that need to be allocated to each task processing node through the weight provided by the task processing node. Based on this, substituting the above request rate parameters can obtain an abnormal server concurrency function, such as the following formula (2).

Among them, J represents the concurrency number of the abnormal server; the MaxCon is a preset concurrency number threshold, called the maximum action concurrency number; MinCon is a preset concurrency number threshold, called the minimum action concurrency number; wherein MaxCon is greater than MinCon.

For the convenience of calculation, assuming that the minimum concurrent number of actions can be 200 and the maximum concurrent number of actions can be 400, the abnormal server concurrency function (Formula 2) can be simplified to the following formula (3).

Based on the above abnormal server concurrency function, the change in the concurrency growth rate of the abnormal server can be calculated, see Figure 4, which is a schematic diagram of the change in the concurrency growth rate of the abnormal server in a request processing method provided by an embodiment of this specification. Based on Figure 4, it can be seen that after the total request rate A reaches 400 and the concurrency number reaches 200, the concurrency growth rate of the abnormal server slows down and eventually converges to around the maximum concurrency number of 400.

Specifically, the constructing a request set to be processed corresponding to the first task processing node based on the request set information and the at least two requests to be processed includes:

The allocation node obtains, from the at least two pending requests, a target pending request corresponding to the request processing quantity of the first task processing node;

A set of pending requests corresponding to the first task processing node is constructed based on the target pending request, wherein the set of pending requests includes the target pending request.

Specifically, after determining the number of requests that need to be processed by the first task processing node, the allocation node will obtain a number of pending requests corresponding to the number of requests to be processed by the first task processing node from at least two pending requests, and use the corresponding number of pending requests as target pending requests that need to be allocated to the first task processing node; then, based on the target pending requests, a pending request set corresponding to the first task processing node is constructed, the pending request set includes the target pending requests, and the pending request set is sent to the first task processing node, thereby preventing unlimited expansion of resource occupation, achieving rapid fault convergence, and significantly reducing the impact on users.

In the request processing method provided in this specification, the request to be processed is an order to be processed;

Accordingly, the at least two requests to be processed are based on the task processing weight and the at least two requests to be processed. The first task processing node among the task processing nodes allocates a corresponding set of requests to be processed, including:

The allocation node allocates a corresponding set of pending orders to a first order processing node among the at least two order processing nodes based on the order task processing weight and the at least two pending orders.

The pending order may be understood as a commodity order that needs to be processed, and the order processing node may be understood as a server that can process the commodity order, and the server may be composed of one or more servers.

The allocation node can be understood as a server that allocates the pending order to the order task processing node.

Continuing with the above example, the allocation node is the order allocation server, and the first order processing node can be the product order processing server. Based on this, when the load on the product order server is high, the product order server can determine the downgrade weight based on its own load situation, and push the downgrade weight to the order allocation server. The next time the order allocation server initiates a call to multiple product order processing servers based on the product order request sent by the client, it will use this new weight to allocate product orders, thereby reducing the number of requests received by servers with high or abnormal loads, and achieving load balancing.

Step 304: The first task processing node performs task processing on the pending request in the received pending request set, updates the task processing weight according to the current processing status information during the task processing, and sends the updated task processing weight to the allocation node based on the task response message.

The current processing status information can be understood as information characterizing the current processing status of the first task processing node, or can be understood as information characterizing the current load of the server. For example, the current processing status information can be the current concurrency number of the first task processing node, the memory occupancy rate of the first task processing node, the CPU (central processing unit) occupancy rate, etc.

In which, in the case that the pending request is a request for inventory reduction, the task processing of the pending request can be understood as deducting the commodity inventory data stored in the database associated with the first task processing node based on the inventory reduction request.

Specifically, updating the task processing weight according to the current processing state information during the task processing includes:

The first task processing node monitors current processing status information during the task processing;

When it is determined that the current processing state information satisfies a preset weight update condition, the task processing weight is updated based on the current processing state information and a preset weight update parameter.

It should be noted that the current processing status information may be the current concurrent number of requests. Based on this, determining that the current processing status information meets the preset weight update condition includes:

The first task processing node determines that the current processing status information satisfies a preset weight update condition when determining that the current concurrent request number is greater than or equal to a preset minimum concurrent request threshold.

The preset minimum request concurrency threshold may be understood as a preset value, which may be used by the first task processing node to determine its own load condition, such as the preset minimum request concurrency threshold MinCon. If the current server's concurrent number is less than the minimum concurrent number of actions, no weight downgrade will be performed, and the current server's weight will be kept consistent with other normal server weights. If the current server's concurrent number is higher than the minimum concurrent number of actions, its own weight needs to be recalculated, so as to check its own load in real time to prevent the impact of unlimited expansion of requests on the server.

It should be noted that the current processing state information is the current processing resource information; the current processing resources can be understood as the resources required by the first task processing node to perform task processing, such as the CPU resources and memory resources of the server. The current processing resource information can be understood as information characterizing the usage of the current processing resources, such as the CPU utilization, memory utilization, etc. Based on this, the determination that the current processing state information meets the preset weight update condition includes:

The first task processing node determines that the current processing state information satisfies a preset weight update condition when determining that the current processing resource information is greater than or equal to a preset resource threshold.

The preset resource threshold value may be understood as a preset value, which may be used by the first task processing node to determine its own load condition, for example, a CPU utilization threshold value of 90%.

Continuing with the above example, the request processing method provided in this specification allows the inventory server to detect its own CPU utilization in real time. When it is determined that its own CPU utilization of 95% is greater than or equal to the preset CPU utilization threshold of 90%, it is determined that it is in a load state and needs to adjust its own weight, thereby checking its own load situation in real time to prevent the impact of unlimited expansion of request occupancy on the server.

Specifically, the first task processing node in the request processing method provided in this specification can monitor the current processing status information of its own task processing process in real time; and when it is determined that the current processing status information meets the preset weight update conditions, it can update its own task processing weight based on the current processing status information and the preset weight update parameters.

Wherein, the current processing state information is the current number of concurrent requests, and the preset weight update parameter includes a preset minimum concurrent request threshold and a preset maximum concurrent request threshold; based on this, the task processing weight is updated based on the current processing state information and the preset weight update parameter, including:

The first task processing node determines the preset minimum request concurrency threshold and the preset maximum request concurrency threshold;

Based on the preset minimum request concurrency threshold, the preset maximum request concurrency threshold and the current number of concurrent requests, updated task weight information is obtained, and the task weight information is replaced based on the updated task weight information.

Among them, the preset maximum request concurrency threshold can be understood as a pre-set value, which can be used by the first task processing node to determine its own load situation. The preset maximum request concurrency threshold is greater than the preset minimum request concurrency threshold. It should be noted that the request processing party provided in this specification has designed two adjustment factors, namely the minimum action concurrency number MinCon and the maximum action concurrency number MaxCon; a push data (degradation weight Deweight) and an adjustment method, a custom adjustment curve. In actual applications, if the current server's concurrency is less than the minimum action concurrency number, no weight downgrade will be performed, and the current server weight will be kept consistent with other normal server weights. In addition, the task processing node dynamically controls its own weight in the cluster between the minimum action concurrency number and the maximum action concurrency number. The weight value provides the ability to shield faults when the server is abnormal, and realizes the disaster recovery of the service cluster. By calculating and updating the weight of the server itself, the optimal solution for traffic scheduling between multiple discrete servers can be achieved when there is a single point of abnormality.

If the current server concurrency is higher than the minimum action concurrency, the downgrade weight is determined based on the current concurrency and pushed to the consumer. The downgrade weight decreases as the current concurrency increases. The reduction trend in this reduction process is controlled by a custom adjustment curve, which can be a linear function curve, or can be adjusted to a quadratic function, cubic function, etc. As the number of functions increases, the server performance converges faster.

Using the above example, before the minimum concurrent action number is reached, the processing rate of the server is consistent with the above situation. However, after reaching the minimum concurrent action number, its own weight needs to be downgraded. Therefore, the inventory server needs to determine the preset minimum concurrent action number and maximum concurrent action number, and then recalculate its own downgrade weight based on the minimum concurrent action number, the maximum concurrent action number and the current concurrency number. The server performs capacity assessment based on the current concurrency to make the pushed weight value quasi-real-time and avoid information lag. The downgrade weight can be determined according to the following formula (4).

It should be noted that a linear function is used to facilitate the description of the custom adjustment curve. However, a quadratic function or a decimation function may also be used. Referring to Figure 5, Figure 5 is a schematic diagram of the change in the concurrency number under different functions of a request processing method provided by an embodiment of this specification. Figure 5 is a fitting curve of the concurrency growth when the custom adjustment curve is a linear function, a quadratic function, and a decimation function; based on Figure 5, it can be seen that as the number of functions increases, the concurrency number is less affected by the request rate, and the protection efficiency of the server is higher. In addition, when the current concurrency number reaches the maximum action concurrency number, the downgrade weight is 0, which means that no requests will be accepted, ensuring that the current concurrency number of the machine will never exceed the maximum action concurrency number.

The task processing node in a request processing method provided in this specification will actively send the task processing weight determined according to the current processing status information in the task processing process to the allocation node; and the allocation node will quickly and accurately determine the current processing status of each task processing node based on the task processing weight to avoid delay problems; and when receiving a pending request, it will allocate the pending request to the corresponding task processing node based on the current processing status of each task processing node, thereby improving the request processing efficiency.

The following is combined with Figure 6, taking the application of the request processing method provided by this specification in the order processing scenario as an example to further illustrate the request processing method. Among them, Figure 6 shows a schematic diagram of the processing process of a request processing method provided by an embodiment of this specification; wherein, the order service end (i.e., the consumer end) can receive the product order provided by the user. In the process of processing the product order by the order service end, in order to avoid the problem that the user cannot obtain the product after placing an order because the inventory quantity has not been reduced after the product is sold out. The order service end needs to send a deduction inventory request to the inventory service end (i.e., the service end corresponding to the consumer end), so as to deduct the inventory quantity of the product by calling the service of the inventory service end. Based on this, the process of the order service end calling the deduction inventory service provided by the inventory service end through the deduction inventory request is as follows.

It should be noted that in Figure 6, the total request rate of the order server is A qps, the total number of inventory servers is B (B>1), the response speed of the normal inventory server is C ms, and the response speed of the abnormal inventory server is D ms (D>C). Based on this, it can be determined that before the weight is adjusted, the request rate of each inventory server is The normal number of concurrent connections on the inventory server is The abnormal number of concurrent inventory servers is

Based on this, see Figure 6, B is 2, C is 50, and D is 2000, which means there are 4 inventory servers in total. The response speed of a normal inventory server is 50ms, and the response speed of an abnormal inventory server is 2000ms. The concurrent number growth function of a normal inventory server is: The concurrent growth function of the abnormal inventory server is: See Figure 7, which is a schematic diagram of the single-machine concurrency number in a request processing method provided by an embodiment of the present specification; Figure 7 is obtained by substituting the above-mentioned concurrency growth function into the calculation. As shown in Figure 7, even when the total request rate reaches 8000QPS, the single-machine concurrency number of the normal inventory server is only 100, while the abnormal inventory server has reached 4000, far exceeding the concurrency range limit that the general server can bear. Based on this, after the current concurrency number of the server reaches the minimum action concurrency number MinCon, through the formula Determine the downgrade weight of the abnormal inventory server and send the downgrade weight to the order server.

In the process of sending inventory reduction requests to multiple inventory servers, the order server will determine the corresponding request rate for each inventory server based on the weight provided by the inventory server to represent its own load situation in order to prevent unlimited expansion of resource usage, achieve rapid fault convergence, and significantly reduce the impact on users. Specifically, the downgrade weight is substituted into the formula In the process, the request rate of the abnormal inventory server is determined, that is, the number of inventory deduction requests that need to be allocated to the abnormal server, and the corresponding number of inventory deduction requests are sent to the abnormal inventory server. The request processing method provided in this specification reduces the impact by dynamically sensing and calculating the delay and timely downgrading the problematic server. Referring to Figure 6, by reducing the weight ratio of problematic and normal inventory service providers from 1:1 to 10.5:1, the upstream and downstream status conditions have greatly optimized the average request delay and delay on the user side, and the high concurrency on the entire link has also been alleviated.

It should be noted that, in response to the problems of the above-mentioned unlimited scheme, the scheme with a maximum concurrency limit, and the load balancing scheduling scheme from the client's perspective, the request processing method provided in this specification limits the maximum concurrency by defining two adjustment factors, namely the minimum action concurrency number and the maximum action concurrency number, thereby fundamentally solving the problem of unlimited expansion of resource usage in the unlimited scheme. In addition, the proportion distribution of requests on the consumer side is adjusted by combining weight push with a custom adjustment curve, thus avoiding directly solving the processing of requests. The impact on user experience is reduced by shifting the request target. At the same time, since the abnormal server does not reject all request processing, normal services in the abnormal server can also receive requests normally, thus achieving abnormal shielding between services. In addition, the performance calculation of the server itself is relatively accurate. Real-time and accurate, the server-side current limiting can ensure the efficiency and correctness of downgrade isolation.

In summary, the request processing method provided in this specification protects its own concurrency from the perspective of the server, and greatly optimizes and improves a single server, abnormal services, normal services, overall cluster stability, and user experience.

Referring to FIG. 8 , FIG. 8 shows an application flow chart of another request processing method provided according to an embodiment of the present specification. The request processing method is applied to a task processing node, and the method specifically includes the following steps.

Step 802: Generate a task response message based on the task processing weight, and send the task response message to the allocation node.

Step 804: Receive a set of pending requests determined by the allocation node for the task processing node, wherein the set of pending requests is determined by the allocation node based on the task processing weight and at least two pending requests received.

Step 806: performing task processing on the pending requests in the received pending request set, and updating the task processing weight according to current processing status information during the task processing.

Step 808: Sending the updated task processing weight to the allocation node based on the task response message.

For an explanation of the other request processing method, please refer to the corresponding or corresponding content in the above-mentioned request processing method, which will not be elaborated here.

Another request processing method applied to task processing nodes provided in this specification will actively send the task processing weight determined according to the current processing status information during the task processing process to the allocation node; and the allocation node will quickly and accurately determine the current processing status of each task processing node based on the task processing weight to avoid delay problems; and when receiving pending requests, it will allocate the pending requests to the corresponding task processing nodes based on the current processing status of each task processing node, thereby improving request processing efficiency.

The above is a schematic scheme of another request processing method of this embodiment. It should be noted that the technical scheme of the other request processing method and the technical scheme of the above-mentioned one request processing method belong to the same concept, and the details not described in detail in the technical scheme of the other request processing method can be referred to the description of the technical scheme of the above-mentioned one request processing method.

Referring to FIG. 9 , FIG. 9 shows an application flow chart of another request processing method provided according to an embodiment of the present specification. The request processing method is applied to a distribution node, and the method specifically includes the following steps.

Step 902: receiving at least two pending requests, and receiving task response messages sent by at least two task processing nodes, wherein the task response messages carry task processing weights.

Step 904: Based on the task processing weight and the at least two pending requests, a corresponding pending request set is allocated to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes.

For an explanation of yet another request processing method, please refer to the corresponding or corresponding contents in the above-mentioned one request processing method and another request processing method, and no further details will be given here.

Another request processing method applied to allocation nodes provided in this specification will receive the task processing weight determined by the task processing node based on the current processing status information during the task processing process, and quickly and accurately determine the current processing status of each task processing node based on the task processing weight, thereby avoiding delay problems, and when receiving pending requests, it will allocate pending requests to corresponding task processing nodes based on the current processing status of each task processing node, thereby improving request processing efficiency.

The above is a schematic scheme of another request processing method of this embodiment. It should be noted that the technical scheme of the another request processing method and the technical scheme of the above request processing method belong to the same concept, and the details of the technical scheme of the another request processing method that are not described in detail can all be referred to the description of the technical scheme of the above request processing method.

Corresponding to the above method embodiment, this specification also provides a request processing system embodiment. FIG10 shows a schematic diagram of the structure of a request processing system provided by an embodiment of this specification. As shown in FIG10, the system includes a distribution node 1002 and at least two task processing nodes 1004, wherein:

The allocation node 1002 is configured to receive at least two pending requests and receive task response messages sent by the at least two task processing nodes 1004, wherein the task response messages carry task processing weights; and

Based on the task processing weight and the at least two pending requests, assigning a corresponding pending request set to a first task processing node 1004 of the at least two task processing nodes 1004, wherein the first task processing node 1004 is one of the at least two task processing nodes 1004;

The first task processing node 1004 is configured to perform task processing on the pending requests in the received pending request set, update the task processing weight according to the current processing status information during the task processing, and send the updated task processing weight to the allocation node 1002 based on the task response message.

Optionally, the allocation node 1002 is further configured to determine the request set information corresponding to the first task processing node 1004 based on the task processing weight of the first task processing node 1004 among the at least two task processing nodes 1004;

Based on the request set information and the at least two pending requests, a pending request set corresponding to the first task processing node 1004 is constructed, and the pending request set is sent to the first task processing node 1004 .

Optionally, the allocation node 1002 is further configured to determine a first task processing node 1004 among the at least two task processing nodes 1004, and determine a task processing weight of the first task processing node 1004;

Based on the request quantities of the at least two pending requests, the node quantities of the at least two task processing nodes 1004 and the task processing weight, the request processing quantity of the first task processing node 1004 is determined, and the request processing quantity is used as request set information.

Optionally, the allocation node 1002 is further configured to obtain, from the at least two pending requests, a target pending request corresponding to the request processing quantity of the first task processing node 1004;

A set of pending requests corresponding to the first task processing node 1004 is constructed based on the target pending request, wherein the set of pending requests includes the target pending request.

Optionally, the first task processing node 1004 is further configured to monitor current processing status information during the task processing;

When it is determined that the current processing state information satisfies a preset weight update condition, the task processing weight is updated based on the current processing state information and a preset weight update parameter.

Optionally, the current processing state information is the current number of concurrent requests, and the preset weight update parameters include a preset minimum concurrent request threshold and a preset maximum concurrent request threshold;

Accordingly, the first task processing node 1004 is further configured to determine the preset minimum request concurrency threshold and the preset maximum request concurrency threshold;

Based on the preset minimum request concurrency threshold, the preset maximum request concurrency threshold and the current number of concurrent requests, updated task weight information is obtained, and the task weight information is replaced based on the updated task weight information.

Optionally, the current processing status information is the current concurrent number of requests;

Correspondingly, the first task processing node 1004 is further configured to determine that the current processing state information satisfies a preset weight update condition when it is determined that the current number of concurrent requests is greater than or equal to a preset minimum concurrent request threshold.

Optionally, the current processing state information is current processing resource information;

Correspondingly, the first task processing node 1004 is further configured to determine that the current processing state information satisfies a preset weight update condition when it is determined that the current processing resource information is greater than or equal to a preset resource threshold.

Optionally, the pending request is a pending order;

Correspondingly, the allocation node 1002 is further configured to allocate a corresponding set of pending orders to be processed to the first order processing node among the at least two order processing nodes based on the order task processing weight and the at least two pending orders.

The task processing node of a request processing system provided in this specification will actively send the task processing weight determined according to the current processing status information in the task processing process to the allocation node; and the allocation node will quickly and accurately determine the current processing status of each task processing node based on the task processing weight to avoid delay problems; and when receiving a pending request, it will allocate the pending request to the corresponding task processing node based on the current processing status of each task processing node, thereby improving the request processing efficiency.

The above is a schematic scheme of a request processing system of this embodiment. It should be noted that the technical scheme of the request processing system and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the request processing system can be referred to the description of the technical scheme of the request processing method described above.

Corresponding to the above method embodiment, this specification also provides another request processing device embodiment, wherein the request processing device is applied to a task processing node, and includes:

A first sending module is configured to generate a task response message based on the task processing weight, and send the task response message to the allocation node;

a receiving module configured to receive a set of pending requests determined by the allocation node for the task processing node, The pending request set is determined by the allocation node based on the task processing weight and at least two pending requests received;

A processing module, configured to perform task processing on the pending requests in the received pending request set, and update the task processing weight according to current processing status information during the task processing;

The second sending module is configured to send the updated task processing weight to the allocation node based on the task response message.

Another request processing device applied to task processing nodes provided in this specification will actively send the task processing weight determined according to the current processing status information during the task processing process to the allocation node; and the allocation node will quickly and accurately determine the current processing status of each task processing node based on the task processing weight to avoid delay problems; and when receiving pending requests, it will allocate the pending requests to the corresponding task processing nodes based on the current processing status of each task processing node, thereby improving the request processing efficiency.

The above is a schematic scheme of another request processing device of this embodiment. It should be noted that the technical scheme of the another request processing device and the technical scheme of the another request processing method mentioned above belong to the same concept, and the details of the technical scheme of the another request processing device that are not described in detail can all be referred to the description of the technical scheme of the another request processing method mentioned above.

Corresponding to the above method embodiment, this specification also provides another request processing device embodiment, where the request processing device is applied to an allocation node, including:

A receiving module, configured to receive at least two pending requests and receive task response messages sent by at least two task processing nodes, wherein the task response messages carry task processing weights;

The allocation module is configured to allocate a corresponding set of pending requests to a first task processing node among the at least two task processing nodes based on the task processing weight and the at least two pending requests, wherein the first task processing node is one of the at least two task processing nodes.

Another request processing device applied to allocation nodes provided in this specification will receive the task processing weight determined by the task processing node according to the current processing status information during the task processing process, and quickly and accurately determine the current processing status of each task processing node based on the task processing weight, thereby avoiding delay problems, and when receiving pending requests, it will allocate pending requests to corresponding task processing nodes based on the current processing status of each task processing node, thereby improving request processing efficiency.

The above is a schematic scheme of another request processing device of this embodiment. It should be noted that the technical scheme of the another request processing device and the technical scheme of the another request processing method described above belong to the same concept, and the details not described in detail in the technical scheme of the another request processing device can be referred to the description of the technical scheme of the another request processing method described above.

Fig. 11 shows a block diagram of a computing device 1100 according to an embodiment of the present specification. The components of the computing device 1100 include but are not limited to a memory 1110 and a processor 1120. The processor 1120 is connected to the memory 1110 via a bus 1130, and a database 1150 is used to store data.

The computing device 1100 also includes an access device 1140 that enables the computing device 1100 to communicate via one or more networks 1160. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 1140 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a World Wide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

In one embodiment of the present specification, the above components of the computing device 1100 and other components not shown in FIG. 11 may also be connected to each other, for example, through a bus. It should be understood that the computing device structure block diagram shown in FIG. 11 is only for illustrative purposes and is not intended to limit the scope of the present specification. Those skilled in the art may add or replace other components as needed.

The computing device 1100 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. The computing device 1100 may also be a mobile or stationary server.

The processor 1120 is used to execute the following computer executable instructions, which implement the steps of the above-mentioned request processing method when executed by the processor.

The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the computing device can be found in the description of the technical scheme of the request processing method described above.

An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which can implement the steps of the above-mentioned request processing method when executed by a processor.

The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the storage medium can be found in the description of the technical scheme of the request processing method described above.

An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned request processing method.

The above is a schematic scheme of a computer program of this embodiment. It should be noted that the technical scheme of the computer program and the technical scheme of the request processing method described above are of the same concept, and the details not described in detail in the technical scheme of the computer program can be found in the description of the technical scheme of the request processing method described above.

The above description is of certain embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or The latter may be beneficial.

The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

It should be noted that, for the convenience of description, the aforementioned method embodiments are all described as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the described action sequence, because according to the embodiments of this specification, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims (14)

1. A request processing method is applied to a request processing system, the system comprising a distribution node and at least two task processing nodes, the method comprising:

   The allocation node receives at least two pending requests and receives a task response message sent by the at least two task processing nodes, wherein the task response message carries a task processing weight; and

   Based on the task processing weight and the at least two pending requests, assigning a corresponding pending request set to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes;

   The first task processing node performs task processing on the pending request in the received pending request set, updates the task processing weight according to the current processing status information during the task processing, and sends the updated task processing weight to the allocation node based on the task response message.
2. According to the request processing method of claim 1, allocating a corresponding set of pending requests to a first task processing node among the at least two task processing nodes based on the task processing weight and the at least two pending requests comprises:

   The allocation node determines, based on a task processing weight of a first task processing node among the at least two task processing nodes, request set information corresponding to the first task processing node;

   Based on the request set information and the at least two pending requests, a pending request set corresponding to the first task processing node is constructed, and the pending request set is sent to the first task processing node.
3. According to the request processing method of claim 2, determining the request set information corresponding to the first task processing node among the at least two task processing nodes based on the task processing weight of the first task processing node comprises:

   The allocation node determines a first task processing node among the at least two task processing nodes, and determines a task processing weight of the first task processing node;

   Based on the request quantities of the at least two pending requests, the node quantities of the at least two task processing nodes, and the task processing weight, the request processing quantity of the first task processing node is determined, and the request processing quantity is used as request set information.
4. According to the request processing method of claim 3, constructing a set of pending requests corresponding to the first task processing node based on the request set information and the at least two pending requests comprises:

   The allocation node obtains, from the at least two pending requests, a target pending request corresponding to the request processing quantity of the first task processing node;

   A set of pending requests corresponding to the first task processing node is constructed based on the target pending request, wherein the set of pending requests includes the target pending request.
5. According to the request processing method of claim 1, the updating of the task processing weight according to the current processing status information during the task processing process comprises:

   The first task processing node monitors current processing status information during the task processing;

   When it is determined that the current processing state information satisfies a preset weight update condition, the task processing weight is updated based on the current processing state information and a preset weight update parameter.
6. According to the request processing method of claim 5, the current processing status information is the current number of concurrent requests, and the preset weight update parameters include a preset minimum concurrent request threshold and a preset maximum concurrent request threshold;

   Accordingly, the updating of the task processing weight based on the current processing state information and the preset weight update parameter includes:

   The first task processing node determines the preset minimum request concurrency threshold and the preset maximum request concurrency threshold;

   Based on the preset minimum request concurrency threshold, the preset maximum request concurrency threshold and the current number of concurrent requests, updated task weight information is obtained, and the task weight information is replaced based on the updated task weight information.
7. According to the request processing method of claim 5, the current processing status information is the current concurrent number of requests;

   Accordingly, the determining that the current processing state information satisfies a preset weight update condition includes:

   The first task processing node determines that the current processing status information satisfies a preset weight update condition when determining that the current concurrent request number is greater than or equal to a preset minimum concurrent request threshold.
8. According to the request processing method of claim 5, the current processing state information is current processing resource information;

   Accordingly, the determining that the current processing state information satisfies a preset weight update condition includes:

   The first task processing node determines that the current processing state information satisfies a preset weight update condition when determining that the current processing resource information is greater than or equal to a preset resource threshold.
9. The request processing method according to claim 1, wherein the request to be processed is an order to be processed;

   Accordingly, allocating a corresponding set of pending requests to a first task processing node among the at least two task processing nodes based on the task processing weight and the at least two pending requests includes:

   The allocation node allocates a corresponding set of pending orders to a first order processing node among the at least two order processing nodes based on the order task processing weight and the at least two pending orders.
10. A request processing method, applied to a task processing node, comprising:

    Generate a task response message based on the task processing weight, and send the task response message to the allocation node;

    receiving a set of pending requests determined by the allocation node for the task processing node, wherein the set of pending requests is determined by the allocation node based on the task processing weight and at least two pending requests received;

    Performing task processing on the pending requests in the received pending request set, and updating the task processing weight according to current processing status information during the task processing;

    The updated task processing weight is sent to the allocation node based on the task response message.
11. A request processing method, applied to an allocation node, comprising:

    receiving at least two pending requests and receiving task response messages sent by at least two task processing nodes, wherein the task response messages carry task processing weights;

    Based on the task processing weight and the at least two pending requests, a corresponding pending request set is allocated to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes.
12. A request processing system, the system comprising a distribution node and at least two task processing nodes, wherein:

    The allocation node is configured to receive at least two pending requests and receive a task response message sent by the at least two task processing nodes, wherein the task response message carries a task processing weight; and

    Based on the task processing weight and the at least two pending requests, assigning a corresponding pending request set to a first task processing node among the at least two task processing nodes, wherein the first task processing node is one of the at least two task processing nodes;

    The first task processing node is configured to perform task processing on the pending requests in the received pending request set, update the task processing weight according to the current processing status information during the task processing, and send the updated task processing weight to the allocation node based on the task response message.
13. A computing device comprising:

    Memory and processor;

    The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the request processing method according to claim 10 or the steps of the request processing method according to claim 11 are implemented.
14. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the request processing method of claim 10 or the steps of the request processing method of claim 11.