Request processing method and apparatus, computer device, storage medium, and computer program product

Abstract

A request processing method, executed by a load balancing node in a request processing system, wherein the request processing system comprises a reverse proxy node, a virtual proxy node, and the load balancing node, and request forwarding is performed between the reverse proxy node and the virtual proxy node by means of a plurality of socket nodes. The method comprises: upon receipt of a plurality of traffic requests by the reverse proxy node, determining, from among the plurality of socket nodes, socket nodes available for processing (302); for each socket node available for processing, determining, from the virtual proxy node, a processing instance having a binding relationship with the socket node available for processing, so as to obtain a plurality of processing instances (304); determining, from among the plurality of processing instances, selected processing instances matching socket nodes available for processing (306); and on the basis of multiple pieces of instance running information respectively corresponding to the selected processing instances, respectively distributing the plurality of traffic requests to the selected processing instances, so that the selected processing instances process the distributed traffic requests (308).

Description

Request processing methods, apparatus, computer equipment, storage media, and computer program products

[0001] Related applications

[0002] This application claims priority to Chinese patent application filed on October 28, 2024, application number 202411510926.5, entitled "Method, apparatus, computer device, storage medium and computer program product for processing a request", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer technology, and in particular to a request processing method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0004] With the development of computer technology, NGINX, as a high-performance Hypertext Transfer Protocol (HTTP) and reverse proxy server, provides various load balancing strategies and is widely used in load balancing and high-availability architectures. Currently, NGINX can distribute requests sequentially to each upstream server, ensuring that each server receives approximately the same number of requests. This strategy is suitable for applications with long request processing times because it distributes the load more evenly. However, during peak business periods in real-world applications, the load on each processing node may become inconsistent. If requests are distributed sequentially to each upstream server in this situation, requests may continue to be sent to the heavily loaded processing nodes, leading to processing timeouts and reducing the reliability of request processing. Therefore, ensuring the reliability of request processing is a problem that urgently needs to be solved. Summary of the Invention

[0005] Based on this, a request processing method, apparatus, computer device, storage medium, and computer program product are provided.

[0006] In a first aspect, this application provides a request processing method, which is executed by a load balancing node in a request processing system. The request processing system includes a reverse proxy node, a virtual proxy node, and a load balancing node. The reverse proxy node and the virtual proxy node transfer requests through multiple socket byte points.

[0007] The methods include:

[0008] When a reverse proxy node receives multiple traffic requests, it determines the processable socket from multiple socket byte points.

[0009] For each processable socket byte point, determine the processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node to obtain multiple processing instances;

[0010] From multiple processing instances, select the processing instance that matches the processable socket byte point; and

[0011] Based on the instance running information corresponding to each selected processing instance, multiple traffic requests are distributed to each selected processing instance so that the selected processing instance can process the distributed traffic requests.

[0012] Secondly, this application also provides a request processing apparatus, which is deployed in a load balancing node of a request processing system. The request processing system includes a reverse proxy node, a virtual proxy node, and a load balancing node. The reverse proxy node and the virtual proxy node transfer requests through multiple socket byte points.

[0013] The device includes:

[0014] The node determination module is used to determine the processable socket byte point from multiple socket byte points when the reverse proxy node receives multiple traffic requests.

[0015] The instance determination module is used to determine, for each processable socket byte point, the processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node, and obtain multiple processing instances;

[0016] The target instance determination module is used to determine a selected processing instance that matches a processable socket byte point from a plurality of processing instances; and

[0017] The request distribution processing module is used to distribute multiple traffic requests to each selected processing instance based on the instance running information corresponding to each selected processing instance, so that the selected processing instance can process the distributed traffic requests.

[0018] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0019] When a reverse proxy node receives multiple traffic requests, it determines the processable socket from multiple socket byte points.

[0020] For each processable socket byte point, determine the processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node to obtain multiple processing instances;

[0021] From multiple processing instances, select the processing instance that matches the processable socket byte point; and

[0022] Based on the instance running information corresponding to each selected processing instance, multiple traffic requests are distributed to each selected processing instance so that the selected processing instance can process the distributed traffic requests.

[0023] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0024] When a reverse proxy node receives multiple traffic requests, it determines the processable socket from multiple socket byte points.

[0025] For each processable socket byte point, determine the processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node to obtain multiple processing instances;

[0026] From multiple processing instances, select the processing instance that matches the processable socket byte point; and

[0027] Based on the instance running information corresponding to each selected processing instance, multiple traffic requests are distributed to each selected processing instance so that the selected processing instance can process the distributed traffic requests.

[0028] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0029] When a reverse proxy node receives multiple traffic requests, it determines the processable socket from multiple socket byte points.

[0030] For each processable socket byte point, determine the processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node to obtain multiple processing instances;

[0031] From multiple processing instances, select the processing instance that matches the processable socket byte point; and

[0032] Based on the instance running information corresponding to each selected processing instance, multiple traffic requests are distributed to each selected processing instance so that the selected processing instance can process the distributed traffic requests.

[0033] Details of one or more embodiments of this application are set forth in the following drawings and description. Other features, objects, and advantages of this application will become apparent from the specification, drawings, and claims. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the published drawings without creative effort.

[0035] Figure 1 is an application environment diagram of a request processing method in one embodiment;

[0036] Figure 2 is a schematic diagram of the system architecture of a request processing system in one embodiment;

[0037] Figure 3 is a flowchart of a request processing method in one embodiment;

[0038] Figure 4 is a schematic diagram of a process in one embodiment, which distributes multiple traffic requests to each selected processing instance based on the instance running information corresponding to each selected processing instance.

[0039] Figure 5 is a flowchart illustrating the process of determining the selected matching processing instance from multiple processing instances in one embodiment.

[0040] Figure 6 is a flowchart illustrating the process of determining the selected matching processing instance from multiple processing instances in another embodiment.

[0041] Figure 7 is a complete flowchart of a request processing method in one embodiment;

[0042] Figure 8 is a structural block diagram of a request processing device in one embodiment;

[0043] Figure 9 is an internal structure diagram of a computer device in one embodiment. Detailed Implementation

[0044] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0045] With the development of computer technology, NGINX, as a high-performance Hypertext Transfer Protocol (HTTP) and reverse proxy server, provides various load balancing strategies and is widely used in load balancing and high-availability architectures. Currently, NGINX can distribute requests sequentially to each upstream server, ensuring that each server receives approximately the same number of requests. This strategy is suitable for applications with long request processing times because it distributes the load more evenly. However, during peak business periods in real-world applications, the load on each processing node may become inconsistent. If requests are distributed sequentially to each upstream server in this situation, requests may continue to be sent to the heavily loaded processing nodes, leading to processing timeouts and reducing the reliability of request processing. Therefore, ensuring the reliability of request processing is a problem that urgently needs to be solved.

[0046] To address the aforementioned problems, this application provides a request processing method that improves the reliability of request processing. The request processing method provided in this application can be applied to the application environment shown in Figure 1. In this environment, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another server.

[0047] Specifically, taking server 104 as an example, when the reverse proxy node receives multiple traffic requests, server 104 determines a processable socket from multiple sockets. For each processable socket, it identifies processing instances bound to it from the virtual proxy nodes, resulting in multiple processing instances. Then, it selects the processing instance that matches the processable socket from these multiple processing instances. Based on the instance runtime information corresponding to each selected processing instance, the multiple traffic requests are distributed to the respective selected processing instances, allowing them to process the distributed traffic requests. By binding multiple processing instances to each processable socket and then selecting the appropriate instance, the traffic congestion caused by a single processing instance failure is reduced, improving the reliability of request processing. Furthermore, by providing runtime feedback through the instance runtime information of each processing instance, different numbers of traffic requests can be distributed based on different runtime information, further enhancing the reliability of request processing.

[0048] The terminal 102 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers. The request processing method provided in this embodiment can be applied to various scenarios requiring request processing, including but not limited to download traffic request processing, video traffic request processing, and real-time session traffic request processing.

[0049] Secondly, since the request processing method provided in this application embodiment is specifically applied to the load balancing node in the request processing system, the request processing system includes a reverse proxy node, a virtual proxy node, and a load balancing node. The reverse proxy node and the virtual proxy node exchange requests through multiple sockets. The system architecture of the request processing system is described below, as shown in Figure 2. The request processing system includes a client 201, a reverse proxy node 202 (NGINX), a virtual proxy node 203 (uWSGI), and the load balancing node 204 required in this application embodiment. The virtual proxy node 203 includes multiple processing instances (Workers), and each processing instance processes the distributed requests based on the processing instance service. The reverse proxy node and the virtual proxy node exchange requests through multiple sockets, and each socket is bound to multiple processing instances, meaning that there is a binding relationship between one socket and multiple processing instances. The processing instance service is the foundational service upon which processing instances operate and process the distributed traffic requests. Each processing instance relies on this service to perform specific request processing operations, ensuring the normal processing of traffic requests.

[0050] In a request processing system, a reverse proxy node is a component such as in NGINX. It receives client traffic requests and forwards them to virtual proxy nodes via multiple sockets, playing the role of receiving and forwarding requests. A virtual proxy node, like in uWSGI, is another part of the request processing system. It contains multiple processing instances responsible for processing incoming traffic requests. The reverse proxy node forwards requests to the virtual proxy node via multiple sockets. The load balancer node is the core control component of the request processing system. When the reverse proxy node receives multiple traffic requests, it determines the processable socket from among the multiple sockets, identifies the selected processing instance matching the processable socket, and distributes the traffic requests to the selected processing instances based on their instance runtime information, thereby achieving load balancing and improved reliability in request processing.

[0051] As shown in the system architecture diagram in Figure 2, socket byte point-1 is bound to processing instance-1 and processing instance-2, socket byte point-2 is bound to processing instance-3 and processing instance-4, and so on. That is, each socket byte point is bound to at least multiple processing instances. In this embodiment, by setting a timed task on the load balancing node, the instance processing time slice corresponding to each process instance is read periodically at a preset very short time interval (e.g., 1 second) according to the process information corresponding to each process instance. Based on the instance processing time slice, the instance processing utilization rate corresponding to each processing instance is calculated as the running parameter value. The processing weight is configured in real time for the processable socket byte points bound to each processing instance, thereby distributing multiple traffic requests to the processing instances matched by each socket byte point according to the processing weight.

[0052] The following describes the request processing method provided by the exemplary embodiments of this application in conjunction with the application scenarios described above and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown for the purpose of understanding this application, and the embodiments of this application are not limited in any way in this respect.

[0053] The following embodiment illustrates the method: In one embodiment, as shown in Figure 3, a request processing method is provided. This method is applied to a load balancing node belonging to the request processing system shown in Figure 2. The request processing system includes a reverse proxy node, a virtual proxy node, and a load balancing node. The reverse proxy node and the virtual proxy node exchange requests through multiple socket byte points. In this embodiment, the method includes the following steps:

[0054] Step 302: When the reverse proxy node receives multiple traffic requests, determine the processable socket byte point from the multiple socket byte points.

[0055] A socket byte point is a bridge for request forwarding between a reverse proxy node and a virtual proxy node. Each socket byte point is bound to at least multiple processing instances. It can obtain the running status of the bound processing instances in real time. The load balancer node uses this information to select socket byte points that can be processed.

[0056] Specifically, a processable socket is a socket bound to at least one processing instance that is in a normal operating state. When a reverse proxy node receives multiple traffic requests, since the reverse proxy node and the virtual proxy node forward requests through multiple sockets, the load balancer node needs to determine the processable socket from among the multiple sockets used for request forwarding between the reverse proxy node and the virtual proxy node based on the running state of the processing instance bound to the socket. The method for determining the processable socket is described below:

[0057] In one specific embodiment, determining a processable socket byte point from multiple socket byte points includes: determining multiple processing instances that have binding relationships with each socket byte point, and determining the running state of each processing instance; and determining a socket byte point that is bound to at least one processing instance that is in a normal running state as a processable socket byte point.

[0058] Specifically, considering practical applications, traffic requests should be distributed to processing instances that can handle them. Therefore, the sockets bound to each processing instance can obtain the real-time running status of the processing instances, allowing for socket filtering based on the running status of each processing instance. That is, for each socket that forwards requests between the reverse proxy node and the virtual proxy node, the load balancer node obtains multiple processing instances that are bound to it. For example, there are sockets A1, A2, A3, and A4 between the reverse proxy node and the virtual proxy node. Socket A1 is bound to processing instances B1 and B2, A2 to B3 and B4, A3 to B5 and B6, and A4 to B7 and B8. It is understood that a socket byte point can be bound to two or more processing instances, therefore the aforementioned number of binding processing instances should not be construed as a limitation of this application.

[0059] Furthermore, the running status of each processing instance bound to each socket byte point is determined. The running status can be either normal or abnormal. An abnormal running status includes instances that have crashed, malfunctioned, or restarted, preventing the processing instance from handling traffic requests normally. Based on this, processing instances in abnormal running status are identified by checking their running status. If all processing instances bound to a socket byte point are in abnormal running status, the instance is removed. Conversely, if at least one processing instance bound to a socket byte point is in normal running status, that socket byte point is identified as a processable socket byte point.

[0060] For example, processing instances B1, B3, B4, and B5 are all in an abnormal running state, while processing instances B2, B6, B7, and B8 are all in a normal running state. Therefore, socket byte point A1 is bound to a processing instance (i.e., processing instance B2) that is in a normal running state, socket byte point A3 is bound to a processing instance (i.e., processing instance B6) that is in a normal running state, and socket byte point A4 is bound to a processing instance (i.e., processing instances B7 and B8) that are in a normal running state. Therefore, processable socket byte points can be selected from socket byte points A1 to A4, specifically socket byte points A1, A3, and A4.

[0061] Step 304: For each processable socket byte point, determine the processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node to obtain multiple processing instances.

[0062] In this system, processing instances belong to virtual proxy nodes, as shown in the system architecture diagram in Figure 2. Virtual proxy node 203 includes multiple processing instances (Workers), and each processing instance processes the distributed requests based on its service. Specifically, as described above, each socket is bound to multiple processing instances; that is, a binding relationship exists between a socket and multiple processing instances. Based on this, after the load balancing node determines each processable socket, it then determines the processing instances bound to that socket from the virtual proxy nodes for each processable socket.

[0063] For ease of understanding, as shown in the above example, the specific socket byte points that can be processed are socket byte points A1, A3, and A4, and the multiple processing instances that have binding relationships with the aforementioned socket byte points are: processing instance B1, processing instance B2, processing instance B5, processing instance B6, processing instance B7, and processing instance B8.

[0064] Step 306: Select a processing instance that matches the processable socket byte point from multiple processing instances.

[0065] The selected processing instance is a processing instance that is in a normal operating state. Specifically, for each processable socket byte point, after identifying multiple processing instances with binding relationships, the load balancing node selects a processing instance that matches the processable socket byte point from among the aforementioned multiple processing instances. The selected processing instance is at least in a normal operating state. For example, for socket byte point A1, there are two processing instances with binding relationships, B1 and B2. Since processing instance B1 is in an abnormal operating state while processing instance B2 is in a normal operating state, processing instance B2 can be selected as the processing instance that matches socket byte point A1.

[0066] Step 308: Based on the instance running information corresponding to each selected processing instance, distribute multiple traffic requests to each selected processing instance so that the selected processing instance can process the distributed traffic requests.

[0067] Among them, instance runtime information is used to describe the runtime information of the instance in processing requests. That is, instance runtime information can be instance processing utilization (i.e., central processing unit (CPU) utilization), CPU load rate, and memory utilization, etc. The specific determination of instance runtime information needs to be flexibly determined according to the actual situation, and is not limited here.

[0068] Specifically, since the selected processing instances are those in normal operating condition, instance operation information can be collected for each selected processing instance. This information can be collected in real-time or periodically at preset time intervals; there is no limitation here. Based on this, the load balancing node distributes multiple traffic requests to each selected processing instance using the instance operation information it receives. In other words, the load balancing node configures weights for each selected processing instance based on its operation information, and then distributes multiple traffic requests to each selected processing instance based on these weights, allowing each selected processing instance to process the distributed traffic requests. That is, considering that when the instance operation information indicates a low level of processing capability, the configured weight can be higher, meaning more requests can be distributed for processing.

[0069] Secondly, as mentioned above, instance runtime information can include instance processing utilization, CPU load rate, and memory utilization. Since CPU utilization directly reflects the workload of processing resources, we will use instance processing utilization as an example for the following description. In practical applications, CPU load rate and memory utilization can also be collected and calculated in a similar manner, which will not be elaborated upon or limited here. In a specific embodiment, instance runtime information is instance processing utilization, that is, instance processing utilization is CPU utilization.

[0070] Based on this, the methods for obtaining instance running information corresponding to each selected processing instance include: reading the instance processing time slice corresponding to each process information at preset time intervals according to the process information corresponding to each processing instance; and calculating the instance processing utilization rate corresponding to each processing instance through each instance processing time slice.

[0071] The process information refers to the information of the worker processes (processing instance processes) of each processing instance. These worker processes are responsible for handling traffic requests from clients, and each worker process is independent, meaning there is no connection between them. Therefore, the process information describes how each worker process handles traffic requests, such as the number of requests processed and the frequency of processing. Secondly, the preset time interval is the time interval for collecting the instance processing time slices of each worker process. This preset time interval can be based on a timer. The instance processing time slice, also known as the CPU time slice, is the runtime allocated by the CPU to each worker thread; it's the period during which each worker thread is allowed to run. The load balancing node periodically reads the instance processing time slices corresponding to each worker process at the preset time interval based on the process information for each worker instance, and then calculates the instance processing utilization of each worker instance.

[0072] Instance processing utilization is a metric that measures the workload of processing instance resources, usually expressed as CPU utilization. The load balancer node calculates the instance processing utilization based on the instance processing time slice of each processing instance, uses it as a running parameter value, and configures the processing weight of the processable socket bytes bound to each processing instance to achieve reasonable distribution of traffic requests.

[0073] Specifically, by collecting process information for each processing instance, the process information corresponding to each processing instance can be obtained. Based on this, according to the process information corresponding to each processing instance, the instance processing time slice corresponding to each process information is read periodically at preset time intervals. That is, according to the process information of the processing instance, a second-level timer is used to periodically read the CPU time slice of the processing instance process at preset time intervals. System call interfaces (such as the getrusage function in Linux system) can be used to implement the periodic reading of the instance processing time slice corresponding to each process information at preset time intervals. Process information is related to the processing instance process (worker process) of the processing instance. It describes the information of the processing instance process in handling traffic requests, such as the number of traffic requests processed and the frequency of traffic requests processed. The load balancing node reads the instance processing time slice based on the process information and then calculates the instance processing utilization.

[0074] Let T be the total CPU time slices of a certain processing instance within a preset time interval Δt. Then, the instance processing utilization U of this processing instance can be expressed by the formula... The calculation shows that U ranges from (0,1). Using this formula, the instance processing utilization rate for each processing instance is calculated. Specifically, the utilization rate of each processing instance process is precisely calculated using its CPU time slice. This utilization rate information represents the instance processing utilization rate of each individual processing instance.

[0075] For example, taking a preset time interval of 1 second as an example, the second-level timer will collect the CPU time slice of the processing instance process every second, and then calculate the instance processing utilization of each processing instance process based on the CPU time slice of each processing instance process. The aforementioned preset time interval can also be set to 2 seconds or 3 seconds based on the actual situation, and the preset time interval can also be adjusted in real time.

[0076] For each selected processing instance, based on the target process information corresponding to that instance, the processing time slice of each target instance is read periodically at preset time intervals. The instance processing utilization rate of each selected processing instance is then calculated using the processing time slices. The specific method is similar to that described above and will not be repeated here.

[0077] It should be understood that the corresponding examples in the embodiments of this application are used to understand this solution, but should not be construed as specific limitations on this solution.

[0078] In the above request processing method, since multiple processing instances are bound to each processable socket byte point (i.e., multiple processing instances are bound to each processable socket byte point, and then a processing instance is selected from these multiple instances), the traffic congestion caused by the failure of a single processing instance can be reduced, thereby improving the reliability of request processing. Secondly, considering the instance runtime information of each selected processing instance—that is, using the instance runtime information of each processing instance for runtime feedback—different numbers of traffic requests are distributed based on different runtime information, further improving the reliability of request processing.

[0079] In one embodiment, as shown in Figure 4, based on the instance runtime information corresponding to each selected processing instance, multiple traffic requests are distributed to each selected processing instance, including:

[0080] Step 402: Obtain the instance running information corresponding to each selected processing instance; the instance running information includes running parameter values.

[0081] The instance runtime information includes runtime parameter values, which describe the runtime values ​​of the instance. As mentioned in the previous embodiment, instance processing utilization can be CPU utilization, CPU load rate, and memory utilization. Therefore, the runtime parameter values ​​can be CPU utilization values, CPU load rate values, and memory utilization values. Furthermore, since the instance runtime information describes the runtime information of the instance processing requests, and the runtime parameter values ​​describe the runtime values ​​of the instance, a larger runtime parameter value indicates that the instance processes more requests, and a smaller runtime parameter value indicates that the instance processes fewer requests.

[0082] Specifically, the load balancing node obtains the instance running information corresponding to each selected processing instance. That is, as described in the previous embodiment, based on the target process information corresponding to each selected processing instance, it periodically reads the target instance processing time slice corresponding to each target process information at preset time intervals; and calculates the instance processing utilization rate corresponding to each selected processing instance through the target instance processing time slice. The specific method is similar to that described above and will not be repeated here.

[0083] Step 404: Configure processing weights for each selected processing instance using the values ​​of each running parameter; the processing weights are inversely proportional to the running parameter values.

[0084] In this embodiment, the processing weight describes the processing priority of a socket byte point. A higher processing weight indicates a higher processing priority, resulting in more traffic requests being allocated to that socket byte point. Conversely, a lower processing weight indicates a lower processing priority, resulting in fewer traffic requests being allocated to that socket byte point. Considering the runtime parameter values ​​in the instance runtime information of each selected processing instance, since a larger runtime parameter value indicates that the processing instance handles a larger number of requests (avoiding excessive traffic requests allocated to already busy instances), the processing weight in this embodiment is inversely proportional to the runtime parameter value.

[0085] Specifically, load balancing nodes configure processing weights for each selected processing instance based on various runtime parameter values. That is, the larger the runtime parameter value in the instance runtime information of a selected processing instance, the lower the processing weight of the bound socket bytes. Conversely, the smaller the runtime parameter value, the higher the processing weight of the bound socket bytes. Therefore, processing weight is inversely correlated with runtime parameter values. Larger runtime parameter values ​​indicate that the selected processing instance is busier, thus fewer requests should be allocated to it. Larger runtime parameter values ​​also indicate a relatively lower processing weight, meaning fewer requests should be allocated to selected processing instances with lower processing weights. Conversely, smaller runtime parameter values ​​indicate a relatively higher processing weight, meaning more requests should be allocated to selected processing instances with higher processing weights.

[0086] Based on this, the load balancing node calculates the weight ratio of the processable socket byte points bound to the selected processing instance according to the running parameter values ​​in the instance running information of the selected processing instance, and then sets the configured processing weight of the processable socket byte points based on the weight ratio of the processable socket byte points. The aforementioned weight ratio can be calculated using a weighted average method, which will be described in detail below:

[0087] In one specific embodiment, the processing weight is configured for each selected processing instance based on the values ​​of each running parameter, including: summing the values ​​of each running parameter to obtain the total value of the running parameter; and for each selected processing instance, determining the processing weight configured for each selected processing instance based on the total value of the running parameter and the running parameter value matched by the processing instance.

[0088] The total sum of the running parameter values ​​is the sum of the running parameter values ​​in the instance running information of each selected processing instance. Specifically, the load balancing node sums up the running parameter values ​​of each instance to obtain the total sum of the running parameter values. In other words, the load balancing node adds up the running parameter values ​​in the instance running information of each selected processing instance, and the resulting sum is the total sum of the running parameter values.

[0089] For example, if processing instance B2 is the selected processing instance matching socket byte point A1, processing instance B6 is the selected processing instance matching socket byte point A3, and processing instance B7 is the selected processing instance matching socket byte point A4, and the running parameter value C1 in the instance running information of processing instance B2 is 0.3, the running parameter value C2 in the instance running information of processing instance B6 is 0.7, and the running parameter value C3 in the instance running information of processing instance B7 is 0.5, then the summation of the aforementioned running parameters, that is, the summation of the running parameter values ​​C1 of processing instance B2, C2 of processing instance B6, and C3 of processing instance B7, yields a total running parameter value of 1.5 (0.3 + 0.7 + 0.5).

[0090] Furthermore, for each selected processing instance, the load balancing node calculates the processing weight of the bound socket byte point by proportionally calculating the sum of the running parameter values ​​and the running parameter values ​​matched to the processing instance. The method for determining the processing weight is described in detail below.

[0091] In one specific embodiment, summing up the values ​​of each operating parameter to obtain the total value of the operating parameters includes: calculating the difference between each operating parameter value and a preset value to obtain the parameter difference between each operating parameter value, and summing up the parameter differences to obtain the total value of the operating parameters.

[0092] Specifically, the preset value is the maximum value within the range of operating parameter values. That is, if the range of operating parameter values ​​is (0, 1], then the preset value is 1. Secondly, the sum of the operating parameter values ​​is the sum of the differences (i.e., parameter differences) between the operating parameter values ​​in the instance running information of each selected processing instance and the preset value. Specifically, the load balancing node calculates the difference between each operating parameter value and the preset value to obtain the parameter difference for each operating parameter value. Since the operating parameter values ​​are within a range, and the preset value is the maximum value within that range, the load balancing node specifically calculates the parameter difference between the preset value and the operating parameter value, which means subtracting the preset value from the preset value. Operating parameter values. For example, taking a preset value of 1 as an example, we can see that the operating parameter value C1 matched by processing instance B2 is 0.3, the operating parameter value C2 matched by processing instance B6 is 0.7, and the operating parameter value C3 matched by processing instance B7 is 0.5. Therefore, for processing instance B2, the parameter difference D1 between the operating parameter value C1 and the preset value is 0.7 (1-0.3). For processing instance B6, the parameter difference D2 between the operating parameter value C2 and the preset value is 0.3 (1-0.7). For processing instance B7, the parameter difference D3 between the operating parameter value C3 and the preset value is 0.5 (1-0.5).

[0093] Furthermore, the load balancing node sums the differences between each parameter to obtain the total sum of the operating parameter values. Similar to the previous embodiment, the load balancing node adds the differences between the various operating parameter values, and the resulting sum is the total operating parameter value. For example, as shown in the previous example, if parameter difference D1 is 0.7, parameter difference D2 is 0.3, and parameter difference D3 is 0.5, then the total operating parameter value is the result of summing parameter differences D1, D2, and D3, which is 1.5(0.7 + 0.3 + 0.5).

[0094] Based on this, for each selected processing instance, the processing weight configured for each selected processing instance is determined by the sum of the running parameter values ​​and the running parameter values ​​that match the processing instance. This includes: for each selected processing instance, determining the parameter difference between the preset value and the running parameter value that matches the selected processing instance; and configuring the processing weight for each selected processing instance based on the ratio of each parameter difference to the sum of the running parameter values.

[0095] Specifically, for each selected processing instance, the load balancing node determines the parameter difference between the preset value and the running parameter value that matches the processing instance. Similar to the aforementioned embodiments, the load balancing node calculates the difference between each running parameter value and the preset value to obtain the parameter difference for each running parameter value. As shown in the previous example, the parameter difference D1 is 0.7, the parameter difference D2 is 0.3, and the parameter difference D3 is 0.5.

[0096] Furthermore, the load balancing node configures the processing weight for each selected processing instance based on the ratio of the difference between each parameter and the sum of the operating parameter values. That is, for each selected processing instance, the load balancing node calculates the ratio by comparing the difference between the operating parameter value matched by the selected processing instance and a preset value, with the sum of the operating parameter values. This ratio is then used to determine the processing weight for each selected processing instance. For ease of understanding, the processing weight calculation method is shown in formula (1):

[0097] Among them, W j Indicates the processing weight of the selected processing instance, CPU j This indicates the runtime parameter values ​​that match the selected processing instance. This represents the sum of the running parameter values.

[0098] Therefore, as shown in the previous example, the parameter difference D1 corresponding to the running parameter value C1 is 0.7, the parameter difference D2 corresponding to the running parameter value C2 is 0.3, and the parameter difference D3 corresponding to the running parameter value C3 is 0.5, while the sum of the running parameter values ​​is 1.5. Thus, for processing instance B2, the processing weight E1 can be obtained as 0.47 (0.7 / 1.5). For processing instance B6, the processing weight E2 can be obtained as 0.2 (0.3 / 1.5). And for processing instance B7, the processing weight E3 can be obtained as 0.33 (0.5 / 1.5).

[0099] Step 406: Distribute multiple traffic requests to the selected processing instances according to their processing weights.

[0100] Specifically, the load balancing node distributes multiple traffic requests to each selected processing instance according to the processing weight. In other words, the load balancing node distributes multiple traffic requests sequentially according to the value of the processing weight, thereby distributing multiple traffic requests to each selected processing instance in sequence.

[0101] When the number of traffic requests cannot be precisely allocated according to their weights, a rounding-down approach can be used to allocate the integer portion of the requests first. The remaining requests are then redistributed to the processing instances with higher processing weights according to their weight ratios. For example, suppose there are 3 selected processing instances with processing weights of 0.4, 0.3, and 0.3, and a total of 10 traffic requests. First, calculate the number of requests to be allocated according to their weights: 4, 3, and 3 respectively. If precise allocation is not possible, allocate 4, 3, and 3 requests respectively. If there are still remaining requests, prioritize allocating them to the processing instance with a processing weight of 0.4.

[0102] In one example, let the total number of traffic requests be N, the number of selected processing instances be m, and the processing weight of the i-th selected processing instance be w. i (i = 1, 2, ..., m), and Then the number of traffic requests n allocated to the i-th selected processing instance i It can be done through formula n i =N×w i The calculation is performed, and then traffic requests are distributed sequentially according to the value of the processing weight, thereby distributing multiple traffic requests to each selected processing instance in turn.

[0103] As described above, the processing weight is inversely related to the running parameter value. The larger the running parameter value, the busier the selected processing instance is in processing requests. Therefore, fewer requests should be assigned to the selected processing instance with a larger running parameter value (i.e., a lower processing weight), while more requests should be assigned to the selected processing instance with a smaller running parameter value (i.e., a higher processing weight).

[0104] For example, as shown in the previous example, the runtime parameter value C1 in the instance runtime information of processing instance B2 is 0.3, the runtime parameter value C2 in the instance runtime information of processing instance B6 is 0.7, and the runtime parameter value C3 in the instance runtime information of processing instance B7 is 0.5. The processing weight E1 for processing instance B2 is 0.47, the processing weight E2 for processing instance B6 is 0.2, and the processing weight E3 for processing instance B7 is 0.33. That is, when distributing multiple traffic requests to processing instances B2, B6, and B7, the traffic requests should be distributed more to processing instance B2, which has the smallest runtime parameter value (and the highest processing weight), then sequentially to processing instance B7, and finally to processing instance B6, which has the largest runtime parameter value (and the lowest processing weight).

[0105] To understand the aforementioned distribution method in detail, the following section describes the sequential distribution of traffic requests:

[0106] In one specific embodiment, multiple traffic requests are distributed to selected processing instances according to their processing weights, including: adjusting the original processing weights of each selected processing instance based on the processing weights configured for each selected processing instance; sorting the processing weights in sequence, and distributing the multiple traffic requests to each selected processing instance in sequence according to the sorting results; the processing weights are proportional to the number of traffic requests distributed.

[0107] The processing weight is directly proportional to the number of traffic requests distributed. As mentioned earlier, the processing weight is inversely related to the running parameter value. A larger running parameter value means the selected processing instance is busier, therefore fewer requests should be allocated to the selected processing instance with the larger running parameter value, which means fewer requests should be allocated to the selected processing instance with the lower processing weight. Conversely, a smaller running parameter value should be allocated to the selected processing instance with the smaller running parameter value, which means more requests should be allocated to the selected processing instance with the higher processing weight.

[0108] Specifically, the load balancing node adjusts the original processing weights of each selected processing instance based on the processing weights configured for that instance. In other words, it replaces the original processing weights of each selected processing instance with the processing weights configured for that instance. Then, the load balancing node sorts the processing weights in ascending order of their values ​​to obtain a sorting result. For example, if the processing weight E1 for instance B2 is 0.47, the processing weight E2 for instance B6 is 0.2, and the processing weight E3 for instance B7 is 0.33, then the sorting result is: Processing weight E1, Processing weight E3, Processing weight E2.

[0109] Furthermore, the load balancer distributes multiple traffic requests sequentially to selected processing instances based on their sorting results. In other words, the load balancer processes traffic requests according to the number of requests, the sorting results, and the ratio between the processing weights. This means that more traffic requests are distributed to selected processing instances with higher processing weights, and fewer traffic requests are distributed to selected processing instances with lower processing weights. For example, if there are 15 traffic requests with the sorting results of processing weight E1, processing weight E3, and processing weight E2, since processing weight E1 is 0.47, processing weight E3 is 0.33, and processing weight E2 is 0.2, 7 of the 15 traffic requests can be distributed to processing instance B2 matching processing weight E1 (0.47), 5 of the 15 traffic requests can be distributed to processing instance B7 matching processing weight E2 (0.33), and 3 of the 15 traffic requests can be distributed to processing instance B6 matching processing weight E3 (0.2).

[0110] It should be understood that the corresponding examples in the embodiments of this application are used to understand this solution, but should not be construed as specific limitations on this solution.

[0111] In this embodiment, the running parameter values ​​are determined by dynamically monitoring the process information of each selected processing instance in real time. These running parameter values ​​reflect the running status of the instance's processing requests, thereby configuring processing weights. This allows for more accurate and real-time request distribution based on processing weights, allocating a corresponding number of traffic requests to each processing weight, thus improving the reliability and timeliness of request processing. Furthermore, distributing traffic requests to each processing weight balances the utilization of each selected processing instance, avoiding the system's bottleneck effect, and providing higher performance and throughput. This fully utilizes host resources, further improving the efficiency and reliability of request processing.

[0112] In one embodiment, as shown in Figure 5, determining a selected processing instance that matches a processable socket byte point from a plurality of processing instances includes:

[0113] Step 502: Select candidate processing instances that are in normal operation from multiple processing instances; normal operation status indicates that the processing instance is in a normal operation state of processing traffic requests.

[0114] Among them, candidate processing instances are candidate processing instances that are in a normal operating state. The operating state can be either a normal operating state or an abnormal operating state. An abnormal operating state is a state in which the processing instance is unable to process traffic requests normally, such as when the processing instance crashes, malfunctions, or restarts. On the other hand, a normal operating state indicates that the processing instance is in a state of normal processing of traffic requests.

[0115] Specifically, for each processable socket byte point, the running status of the processing instances bound to the socket byte point is used to filter and identify processing instances in an abnormal running state. If all processing instances bound to the socket byte point are in an abnormal running state, the processing instance is removed. Conversely, if at least one processing instance bound to the socket byte point is in a normal running state, that processing instance is identified as a candidate processing instance.

[0116] For example, as described above, the socket byte points that can be processed are specifically socket byte points A1, A3, and A4. Processing instances B1 and B5 are both in an abnormal running state, while processing instances B2, B6, B7, and B8 are all in a normal running state. Therefore, for socket byte point A1, the candidate processing instance is processing instance B2. For socket byte point A3, the candidate processing instance is processing instance B6. For socket byte point A4, the candidate processing instances are processing instances B7 and B8.

[0117] Step 504: Select the processing instance that matches the processable socket byte point from among the candidate processing instances.

[0118] Specifically, for each processable socket byte point, after filtering out candidate processing instances that are in normal operating condition, the load balancing node determines the selected processing instance that matches the processable socket byte point from the aforementioned multiple candidate processing instances. The selected processing instance is at least in normal operating condition. Secondly, if there is only one candidate processing instance for a processable socket byte point, this candidate processing instance is determined as the selected processing instance that matches the processable socket byte point. For example, for socket byte point A1, the candidate processing instance is processing instance B2. Since there is only one candidate processing instance, processing instance B2 can be determined as the selected processing instance that matches socket byte point A1. Similarly, for socket byte point A3, the candidate processing instance is processing instance B6. Since there is only one candidate processing instance, processing instance B6 can be determined as the selected processing instance that matches socket byte point A3.

[0119] If there are multiple candidate processing instances for a processable socket byte point, a round-robin load balancing algorithm is needed to determine the selected processing instance from the candidate instances. The method of selection using the round-robin load balancing algorithm will be described in detail in subsequent embodiments and will not be repeated here.

[0120] It should be understood that the corresponding examples in the embodiments of this application are used to understand this solution, but should not be construed as specific limitations on this solution.

[0121] In this embodiment, since multiple processing instances are provided to accept requests, even if one processing instance has a problem, the selected processing instance is determined by selecting a processing instance that is in normal operating condition. This ensures that the selected processing instance is in normal operating condition, avoiding the situation where a single processing instance cannot perform normal traffic processing due to chain restarts, crashes, or other situations, and further improving the high availability and reliability of request processing.

[0122] In one embodiment, as shown in FIG6, determining the selected matching processing instance from a plurality of processing instances includes:

[0123] Step 602: According to the round-robin load balancing algorithm, select the processing instance that matches the processable socket byte point from multiple processing instances.

[0124] Specifically, following the round-robin load balancing algorithm, a selected processing instance matching the processable socket byte point is determined from multiple processing instances. In other words, the round-robin load balancing algorithm selects the processing instance that was not processed during the previous request processing and distribution as the selected processing instance for this request. The round-robin load balancing algorithm can be implemented as follows: Maintain a list of processing instances. During system initialization, all processing instances bound to processable socket byte points are added to the list and sorted according to a preset order (such as the order of processing instance numbers). During operation, the running status of each processing instance is monitored in real time. When the running status of a processing instance changes (e.g., from normal to abnormal or from abnormal to normal), the processing instance list is updated promptly. For example, if a processing instance becomes abnormal, it is temporarily removed from the list; if it recovers to normal, it is added back to the appropriate position in the list. Processing instances are selected sequentially according to the preset order.

[0125] The following describes how to determine the selected processing instance according to the round-robin load balancing algorithm:

[0126] In one specific embodiment, according to the round-robin load balancing algorithm, the selected processing instance that matches the processable socket byte point is determined from multiple processing instances, including: obtaining instance processing information corresponding to each processing instance and the processing order between each processing instance; determining the first processing instance to process the previous traffic request from multiple processing instances according to the instance processing information; taking the next processing instance whose processing order is adjacent to the first processing instance as the second processing instance, and determining the second processing instance as the selected processing instance that matches the processable socket byte point.

[0127] The first processing instance is determined during the round-robin load balancing algorithm process, based on the instance processing information of each processing instance. It is the instance that processes the previous traffic request and forms the basis for determining the next selected processing instance (i.e., the second processing instance). The second processing instance is the processing instance whose processing order is adjacent to the first processing instance during the round-robin load balancing algorithm process. After determining the second processing instance, it is necessary to determine whether it is in a normal operating state. If so, it is determined as the selected processing instance matching the processable socket byte point; otherwise, the process continues to determine the next processing instance based on the processing order until a processing instance in a normal operating state is found.

[0128] The instance processing information refers to the processing instance's handling of each traffic request. For example, for the previously distributed traffic request, processing instance B1, which was in normal operation at the time, processed the previously distributed traffic request. Similarly, processing instance B6, which was in normal operation at the time, processed the previously distributed traffic request.

[0129] Secondly, the processing order among the processing instances is a preset polling order. For example, for socket byte point A1, the processing order between processing instances B1 and B2, which are bound to socket byte point A1, can be: processing instance B1 to processing instance B2 to processing instance B1, a polling order like this. Similarly, the processing order between processing instances B3 and B4, which are bound to socket byte point A2, can be: processing instance B3 to processing instance B4 to processing instance B3, a polling order like this. The processing order between processing instances B5 and B6, which are bound to socket byte point A3, can be: processing instance B5 to processing instance B6 to processing instance B5, a polling order like this. The processing order between processing instances B7 and B8, which are bound to socket byte point A4, can be: processing instance B7 to processing instance B8 to processing instance B7, a polling order like this.

[0130] Specifically, the load balancing node obtains the instance processing information corresponding to each processing instance, as well as the processing order among the processing instances. The instance processing information is obtained based on real-time collected information, while the processing order is a preset order. Based on this, according to the instance processing information, the first processing instance to process the previous traffic request is determined from multiple processing instances, that is, the first processing instance that successfully processed the previous traffic request is determined. At this time, the first processing instance can be in either a normal operating state or an abnormal operating state.

[0131] Furthermore, the load balancer node designates the next processing instance adjacent to the first processing instance as the second processing instance, and identifies the second processing instance as the selected processing instance matching the processable socket byte point. For example, as illustrated in the previous example, for socket byte point A4, the processing instances with a binding relationship are processing instance B7 and processing instance B8. If the instance processing information indicates that the processing instance that successfully processed the previous traffic request is processing instance B7, then processing instance B7 can be identified as the first processing instance. The processing order between processing instances B7 and B8 can be a round-robin order: processing instance B7 to processing instance B8 to processing instance B7. Therefore, the next processing instance adjacent to the first processing instance (processing instance B7) (processing instance B8) is the second processing instance, and the second processing instance (processing instance B8) is identified as the selected processing instance matching the processable socket byte point.

[0132] Understandably, considering that a processing instance cannot process traffic requests when it is in an abnormal operating state, the load balancer node will select the next processing instance adjacent to the first processing instance as the second processing instance. It will then determine whether the second processing instance is in a normal operating state. If so, the second processing instance in a normal operating state will be selected as the processing instance matching the processable socket byte point. Otherwise, if not, it is necessary to further determine the next processing instance adjacent to the second processing instance based on the processing order, and determine whether the next processing instance adjacent to the second processing instance is in a normal operating state, until a next processing instance in a normal operating state is selected. The following describes the specific method for considering the round-robin load balancing algorithm and determining whether the processing instance is in a normal operating state:

[0133] In one specific embodiment, determining the selected processing instance that matches the processable socket byte point from multiple processing instances according to the round-robin load balancing algorithm includes: filtering out candidate processing instances that are in normal operation from multiple processing instances; and determining the selected processing instance that matches the processable socket byte point from each candidate processing instance according to the round-robin load balancing algorithm.

[0134] Among them, candidate processing instances are candidate processing instances that are in a normal operating state. The operating state can be either a normal operating state or an abnormal operating state. An abnormal operating state is a state in which the processing instance is unable to process traffic requests normally, such as when the processing instance crashes, malfunctions, or restarts. On the other hand, a normal operating state indicates that the processing instance is in a state of normal processing of traffic requests.

[0135] Specifically, for each processable socket byte point, the running status of the processing instances bound to the socket byte point is used to filter and identify processing instances in an abnormal running state. If all processing instances bound to the socket byte point are in an abnormal running state, the processing instance is removed. Conversely, if at least one processing instance bound to the socket byte point is in a normal running state, that processing instance is identified as a candidate processing instance.

[0136] For example, as described above, the socket byte points that can be processed are specifically socket byte points A1, A3, and A4. Processing instances B1 and B5 are both in an abnormal running state, while processing instances B2, B6, B7, and B8 are all in a normal running state. Therefore, for socket byte point A1, the candidate processing instance is processing instance B2. For socket byte point A3, the candidate processing instance is processing instance B6. For socket byte point A4, the candidate processing instances are processing instances B7 and B8.

[0137] Furthermore, the load balancing node uses a round-robin algorithm to determine the selected processing instance that matches the processable socket byte point from among the candidate processing instances. At this point, the load balancing node first needs to consider the number of candidate processing instances for each processable socket byte point. That is, if there is only one candidate processing instance for a processable socket byte point, then that candidate processing instance is selected as the matching processing instance. If there are multiple candidate processing instances for a processable socket byte point, then the round-robin algorithm is used to determine the matching processing instance from among the candidate processing instances.

[0138] At this point, similar steps to those in the aforementioned embodiments are executed. The load balancing node obtains the instance processing information corresponding to each processing instance, as well as the processing order among the processing instances. Based on the instance processing information, it determines the first candidate processing instance from multiple candidate processing instances to process the previous traffic request. This first candidate processing instance is guaranteed to be in normal operation at this time. Based on this, the load balancing node designates the next candidate processing instance whose processing order is adjacent to the first candidate processing instance as the second candidate processing instance, and determines the second candidate processing instance as the selected processing instance that matches the processable socket byte point.

[0139] The first candidate processing instance is determined based on the instance processing information of each candidate instance when selecting a processing instance from multiple candidate instances using a round-robin load balancing algorithm. It is guaranteed to be in a normal operating state and serves as the basis for determining the next selected processing instance (i.e., the second candidate processing instance). The second candidate processing instance is the next candidate processing instance whose processing order is adjacent to the first candidate processing instance when selecting a processing instance from multiple candidate instances using the round-robin load balancing algorithm. If the second candidate processing instance is in a normal operating state, it is selected as the processing instance matching the processable socket byte point; otherwise, the process continues to determine the next candidate processing instance based on the processing order until a candidate processing instance in a normal operating state is found.

[0140] For example, as illustrated in the previous example, for socket byte point A4, the candidate processing instances are processing instances B7 and B8. Since there are multiple candidate processing instances, a round-robin load balancing algorithm is needed to determine the selected processing instance that matches the processable socket byte point. Based on this, if the instance processing information indicates that the processing instance that successfully processed the previous traffic request is processing instance B7, then processing instance B7 can be determined as the first processing instance. The processing order between processing instances B7 and B8 can be a round-robin order: processing instance B7 to processing instance B8 to processing instance B7. Therefore, the next processing instance (processing instance B8) adjacent to the first processing instance (processing instance B7) is the second processing instance, and the second processing instance (processing instance B8) is determined as the selected processing instance that matches the processable socket byte point. That is, at this point, the selected processing instance matching socket byte point A4 is processing instance B8.

[0141] It should be understood that the corresponding examples in the embodiments of this application are used to understand this solution, but should not be construed as specific limitations on this solution.

[0142] In this embodiment, by selecting a processing instance that is in a normal operating state, the selected processing instance is guaranteed to be in a normal operating state, avoiding situations where a single processing instance cannot process normal traffic due to chain restarts, crashes, or other reasons. Secondly, when dealing with multiple processing instances, polling among the instances better handles complex online scenarios, further improving the high availability and reliability of request processing.

[0143] Based on the detailed description of the foregoing embodiments, the complete flow of the request processing method in this application embodiment will be described below. In one embodiment, as shown in FIG7, a request processing method is provided. This method is applied to a load balancing node in the request processing system shown in FIG2. The request processing system includes a reverse proxy node, a virtual proxy node, and a load balancing node. The reverse proxy node and the virtual proxy node transfer requests through multiple socket byte points. In this embodiment, the method includes the following steps:

[0144] Step 701: When the reverse proxy node receives multiple traffic requests, determine the multiple processing instances that have binding relationships with each socket byte point, and determine the running status of each processing instance; determine the socket byte point that is bound to at least one processing instance that is in a normal running state as a processable socket byte point.

[0145] Specifically, when a reverse proxy node receives multiple traffic requests, since the reverse proxy node and the virtual proxy node forward requests through multiple sockets, the load balancer node needs to determine the processable sockets from among the multiple sockets forwarding requests between the reverse proxy node and the virtual proxy node based on the running status of the processing instances bound to those sockets. Considering practical applications, traffic requests should be distributed to processing instances that can handle them. Therefore, the sockets bound to each processing instance can obtain the running status of the processing instance in real time, thus allowing for socket filtering based on the running status of each processing instance. In other words, for each socket forwarding requests between the reverse proxy node and the virtual proxy node, the load balancer node obtains multiple processing instances that are bound to each other.

[0146] Furthermore, the running status of each processing instance that has a binding relationship with each socket byte point is determined. Based on the running status of the processing instances bound to each socket byte point, processing instances in an abnormal running state are filtered out. If all processing instances bound to a socket byte point are in an abnormal running state, the processing instance is removed. Conversely, if at least one processing instance bound to a socket byte point is in a normal running state, that socket byte point is determined as a processable socket byte point.

[0147] Step 702: For each processable socket byte point, determine the processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node to obtain multiple processing instances.

[0148] Specifically, as explained above, each socket byte point is bound to multiple processing instances; that is, there is a binding relationship between one socket byte point and multiple processing instances. Based on this, after the load balancing node determines each processable socket byte point, for each processable socket byte point, the processing instances that are bound to the processable socket byte point are determined from the virtual proxy nodes.

[0149] Step 703: Select candidate processing instances that are in normal operation from multiple processing instances.

[0150] Specifically, for each processable socket byte point, the running status of the processing instances bound to the socket byte point is used to filter and identify processing instances in an abnormal running state. If all processing instances bound to the socket byte point are in an abnormal running state, the processing instance is removed. Conversely, if at least one processing instance bound to the socket byte point is in a normal running state, that processing instance is identified as a candidate processing instance.

[0151] Step 704: Obtain the instance processing information corresponding to each candidate processing instance and the processing order between each candidate processing instance; according to the instance processing information, determine the first candidate processing instance to process the previous traffic request from multiple candidate processing instances; take the next processing instance whose processing order is adjacent to the first candidate processing instance as the second candidate processing instance, and determine the second candidate processing instance as the selected processing instance that matches the processable socket byte point.

[0152] Specifically, the load balancing node uses a round-robin algorithm to determine the selected processing instance that matches the processable socket byte point from among the candidate processing instances. First, the load balancing node needs to consider the number of candidate processing instances for each processable socket byte point. If there is only one candidate processing instance for a processable socket byte point, that candidate processing instance is selected as the matching instance. If there are multiple candidate processing instances for a processable socket byte point, the round-robin algorithm is then used to determine the matching instance from among the candidate instances.

[0153] Based on this, the load balancer node obtains the instance processing information corresponding to each processing instance, as well as the processing order among the processing instances. According to this information, it determines the first candidate processing instance from multiple candidate processing instances to process the previous traffic request. This first candidate processing instance is guaranteed to be in normal operation at this point. Based on this, the load balancer node designates the next candidate processing instance whose processing order is adjacent to the first candidate processing instance as the second candidate processing instance, and then selects the second candidate processing instance as the processing instance that matches the processable socket byte point.

[0154] Step 705: Obtain instance running information corresponding to each selected processing instance; instance running information includes running parameter values.

[0155] Specifically, the load balancing node obtains the instance running information corresponding to each selected processing instance. That is, as described in the previous embodiment, based on the target process information corresponding to each selected processing instance, it periodically reads the target instance processing time slice corresponding to each target process information at preset time intervals; and calculates the instance processing utilization rate corresponding to each selected processing instance through the target instance processing time slice. The specific method is similar to that described above and will not be repeated here.

[0156] Step 706: Subtract each running parameter value from the preset value to obtain the parameter difference of each running parameter value, and sum the parameter differences to obtain the total running parameter value; for each selected processing instance, determine the parameter difference between the preset value and the running parameter value that matches the selected processing instance; based on the ratio of each parameter difference to the total running parameter value, configure the processing weight for each selected processing instance.

[0157] The sum of runtime parameter values ​​is the sum of runtime parameter values ​​in the instance runtime information of each selected processing instance. When calculating the processing weight, the load balancer node first sums up each runtime parameter value to obtain the sum, and then determines the processing weight of each selected processing instance based on this sum and the runtime parameter values ​​that match each processing instance. The parameter difference is the difference between a runtime parameter value and a preset value (the maximum value within the range of runtime parameter values). When calculating the processing weight, the load balancer node first calculates the parameter difference between each runtime parameter value and the preset value, then sums these parameter differences to obtain the sum of runtime parameter values, and finally configures the processing weight for each selected processing instance based on the ratio of the parameter difference to the sum of runtime parameter values.

[0158] Specifically, the load balancing node calculates the difference between each operating parameter value and a preset value to obtain the parameter difference for each operating parameter value. Since the operating parameter value falls within a range, and the preset value is the maximum value within that range, the load balancing node calculates the parameter difference between the preset value and the operating parameter value, which is equivalent to subtracting the operating parameter value from the preset value. Further, the load balancing node sums these parameter differences to obtain the total operating parameter value. In other words, similar to the previous embodiment, the load balancing node adds up the parameter differences of each operating parameter value, and the resulting sum is the total operating parameter value.

[0159] Based on this, the load balancing node calculates the difference between each operating parameter value and a preset value to obtain the parameter difference. Then, based on the ratio of each parameter difference to the sum of the operating parameter values, the load balancing node configures the processing weight for each selected processing instance. In other words, for each selected processing instance, the load balancing node calculates the ratio by comparing the parameter difference between the selected processing instance's matched operating parameter value and the preset value to the sum of the operating parameter values, and this ratio is used to configure the processing weight for each selected processing instance.

[0160] Step 707: Adjust the original processing weights of each selected processing instance based on the processing weights configured for each selected processing instance; sort the processing weights in sequence, and distribute multiple traffic requests to each selected processing instance in sequence according to the sorting results; the processing weight is proportional to the number of traffic requests distributed.

[0161] Specifically, the load balancer adjusts the original processing weights of each selected processing instance based on the processing weights configured for that instance. In other words, it replaces the original processing weights of each selected processing instance with the processing weights configured for that instance. Then, the load balancer sorts the processing weights in ascending order of their values ​​to obtain a sorting result.

[0162] Furthermore, the load balancer distributes multiple traffic requests to each selected processing instance in sequence based on the sorting results. In other words, the load balancer processes traffic requests in sequence according to the number of requests and the ratio between the processing weights, thus distributing more traffic requests to selected processing instances with higher processing weights and fewer traffic requests to selected processing instances with lower processing weights.

[0163] It should be understood that the specific implementation methods of steps 701 to 707 are similar to the corresponding embodiments described above, and will not be repeated here.

[0164] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0165] Based on the same inventive concept, this application also provides a request processing apparatus for implementing the request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more request processing apparatus embodiments provided below can be found in the limitations of the request processing method described above, and will not be repeated here.

[0166] In one embodiment, as shown in FIG8, a request processing device is provided. The device is deployed on a load balancing node in a request processing system. The request processing system includes a reverse proxy node, a virtual proxy node, and a load balancing node. The reverse proxy node and the virtual proxy node transfer requests through multiple socket byte points.

[0167] The request processing apparatus includes: a node determination module 802, an instance determination module 804, a target instance determination module 806, and a request dispatch processing module 808, wherein:

[0168] The node determination module 802 is used to determine the processable socket byte point from multiple socket byte points when the reverse proxy node receives multiple traffic requests.

[0169] The instance determination module 804 is used to determine, for each processable socket byte point, a processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node, and obtain multiple processing instances.

[0170] The target instance determination module 806 is used to determine a selected processing instance that matches a processable socket byte point from a plurality of processing instances;

[0171] The request distribution processing module 808 is used to distribute multiple traffic requests to each selected processing instance based on the instance running information corresponding to each selected processing instance, so that the selected processing instance can process the distributed traffic requests.

[0172] In one embodiment, the request distribution processing module 808 is specifically used to obtain instance running information corresponding to each selected processing instance; the instance running information includes running parameter values; the processing weight is configured for each selected processing instance through each running parameter value; the processing weight is inversely proportional to the running parameter value; and multiple traffic requests are distributed to each selected processing instance according to the processing weight.

[0173] In one embodiment, the request distribution processing module 808 is specifically used to sum the values ​​of each running parameter to obtain the total value of the running parameter; for each selected processing instance, the processing weight configured for each selected processing instance is determined by the total value of the running parameter and the running parameter value matched by the processing instance.

[0174] In one embodiment, the request distribution processing module 808 is specifically used to perform subtraction processing on each running parameter value and a preset value respectively to obtain the parameter difference of each running parameter value, and to sum the parameter differences to obtain the total running parameter value; for each selected processing instance, to determine the parameter difference between the preset value and the running parameter value that matches the selected processing instance; and to configure the processing weight for each selected processing instance based on the ratio of each parameter difference to the total running parameter value.

[0175] In one embodiment, the request distribution processing module 808 is specifically used to adjust the original processing weight of each selected processing instance based on the processing weight configured for each selected processing instance; sort the processing weights in sequence, and distribute multiple traffic requests to each selected processing instance in sequence according to the sorting result; the processing weight is proportional to the number of traffic requests distributed.

[0176] In one embodiment, the target instance determination module 806 is specifically used to filter out candidate processing instances that are in normal operation from multiple processing instances; the normal operation state indicates that the processing instance is in a normal operation state of processing traffic requests; and to determine the selected processing instance that matches the processable socket byte point from each candidate processing instance.

[0177] In one embodiment, the target instance determination module 806 is specifically used to determine, from multiple processing instances, a selected processing instance that matches the processable socket byte point according to a round-robin equalization algorithm.

[0178] In one embodiment, the target instance determination module 806 is specifically used to obtain instance processing information corresponding to each processing instance and the processing order between each processing instance; determine the first processing instance to process the previous traffic request from multiple processing instances according to the instance processing information; take the next processing instance whose processing order is adjacent to the first processing instance as the second processing instance, and determine the second processing instance as the selected processing instance that matches the processable socket byte point.

[0179] In one embodiment, the target instance determination module 806 is specifically used to filter out candidate processing instances that are in normal operation from multiple processing instances; and to determine the selected processing instance that matches the processable socket byte point from each candidate processing instance according to the round-robin balancing algorithm.

[0180] In one embodiment, instance runtime information is instance processing utilization;

[0181] The request processing device also includes an information acquisition module;

[0182] The information acquisition module is used to periodically read the instance processing time slices corresponding to each process information according to a preset time interval, based on the process information corresponding to each processing instance; and calculate the instance processing utilization rate corresponding to each processing instance based on the instance processing time slices.

[0183] In one embodiment, the node determination module 802 is used to determine multiple processing instances that have binding relationships with each socket byte point, and to determine the running status of each processing instance; and to determine the socket byte point that is bound to at least one processing instance that is in a normal running state as a processable socket byte point.

[0184] In one embodiment, a computer device is provided, which can be a server or a terminal. This embodiment uses a server as an example, and its internal structure is shown in Figure 9. The computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data related to the embodiments of this application, such as binding relationships. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a request processing method.

[0185] Those skilled in the art will understand that the structure shown in Figure 9 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or may combine certain components, or may have different component arrangements.

[0186] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0187] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0188] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0189] In summary, this application provides a request processing method, apparatus, computer device, computer-readable storage medium, and computer program product. When a reverse proxy node receives multiple traffic requests, the load balancing node determines a processable socket from multiple sockets. Since the processable socket is bound to a processing instance in normal operation, this process, through accurate judgment of the processing instance's running status, avoids distributing traffic requests to nodes that cannot process requests due to hardware failures, software anomalies, or other reasons. From a technical perspective, this reduces the transmission and processing of requests on invalid paths, lowers system communication overhead and processing burden, improves the accuracy of request distribution, and enables requests to reach processable nodes more efficiently, thereby enhancing the reliability of request processing.

[0190] Furthermore, for each processable socket byte point, the load balancing node determines the processing instance bound to it from the virtual proxy node, resulting in multiple processing instances. This multi-instance binding increases resource redundancy in request processing. From a system architecture perspective, this redundancy design constructs a fault tolerance mechanism. When one processing instance fails, other processing instances can seamlessly take over its work, avoiding request processing interruptions due to single-point failures. Technically, this reduces the complex recovery operations required due to processing instance failures, lowers system downtime, enhances system fault tolerance, and thus improves the reliability of request processing.

[0191] After obtaining multiple processing instances, the load balancer node selects the processing instance that matches the processable socket byte point. Since the selected processing instance is in normal operating condition, it can respond to and process distributed traffic requests promptly during the data processing flow. From a system performance perspective, this avoids request backlog and processing delays caused by processing instance anomalies, reduces request queuing time in the system, improves the timeliness and efficiency of request processing, and further enhances the reliability of request processing.

[0192] Based on the instance runtime information corresponding to each selected processing instance, the load balancing node distributes multiple traffic requests to each selected processing instance. Instance runtime information reflects the actual operating status and processing capacity of the processing instance. At the resource allocation level, request distribution based on this information achieves dynamic resource allocation. By monitoring the running status of processing instances in real time, traffic requests can be more rationally distributed to each processing instance, avoiding situations where some processing instances are overloaded while others are idle. From a technical perspective, this improves system resource utilization, reduces resource waste, and further enhances the reliability and efficiency of request processing.

[0193] Furthermore, the load balancer node obtains instance runtime information for each selected processing instance, including runtime parameter values. These runtime parameter values ​​enable real-time and accurate understanding of the processing instance's operational status for data collection and analysis. From a technical implementation perspective, these runtime parameter values ​​provide precise data support for subsequent processing weight configuration, allowing for dynamic adjustments to processing weights based on the actual runtime conditions of the processing instances. This results in more accurate request distribution and improved reliability and timeliness of request processing.

[0194] Based on various operating parameter values, the load balancing node configures a processing weight for each selected processing instance, with the processing weight inversely proportional to the operating parameter value. This configuration method, in its algorithm design, implements an adaptive request allocation strategy. From a system performance optimization perspective, it ensures that requests are more likely to be allocated to processing instances with smaller operating parameter values ​​and relatively idle processing capacity, avoiding the allocation of a large number of requests to already busy processing instances. Technically, this achieves balanced request distribution, reduces the overall system load, and improves the overall system processing capacity and the reliability of request processing.

[0195] The load balancer distributes multiple traffic requests to selected processing instances according to their processing weights. This weighted distribution ensures that the number of traffic requests received by each processing instance matches its processing capacity during data transmission and processing. From a system resource management perspective, this fully leverages the processing power of each instance, improving system resource utilization. Technically, it avoids performance degradation caused by overloading some processing instances, such as slower processing speeds and longer response times, further enhancing the efficiency and reliability of request processing.

[0196] Furthermore, the load balancing node sums the values ​​of each operating parameter to obtain a total sum. Then, for each selected processing instance, its processing weight is determined by combining the total sum of operating parameters with the matching operating parameter values ​​for that instance. This calculation method comprehensively considers the operational status of all selected processing instances in its mathematical model construction. From a technical analysis perspective, this makes the configuration of processing weights more scientific and reasonable, and can more accurately reflect the processing capacity and load of each processing instance in the overall system. During request distribution, based on this scientific configuration of processing weights, more accurate request distribution is achieved, improving the reliability of request processing.

[0197] When calculating the sum of operating parameter values, the load balancing node subtracts each operating parameter value from a preset value, obtains the parameter difference, and sums them. Then, for each selected processing instance, it determines the parameter difference between the preset value and the operating parameter value matching that processing instance, and configures the processing weight based on the ratio of this parameter difference to the sum of the operating parameter values. This calculation method, in terms of algorithmic precision, can more accurately measure the relative processing capacity of each processing instance. From a technical implementation perspective, it makes the configuration of processing weights more refined and accurate, further improving the accuracy of request distribution. During request processing, it reduces the problem of unreasonable request allocation caused by inaccurate processing weight configuration, thereby improving the reliability and efficiency of request processing.

[0198] Furthermore, the load balancing node adjusts the original processing weights of each selected processing instance based on their configured processing weights, sorts the processing weights sequentially, and distributes multiple traffic requests to the selected processing instances according to the sorting results. The processing weight is directly proportional to the number of traffic requests distributed. This distribution method achieves dynamic balanced allocation of requests in the data sorting and allocation algorithms. From the perspective of system performance optimization, this ensures that processing instances with stronger processing capabilities receive more traffic requests first, improving the overall processing efficiency of the system. Technically, it reduces the load difference between processing instances, preventing some processing instances from experiencing performance bottlenecks due to excessive load, and further improving the reliability of request processing.

[0199] Furthermore, the load balancer node filters candidate processing instances from multiple processing instances, selecting those that are in normal operating condition. From these candidate instances, it then determines the chosen processing instance that matches the processable socket byte point. This filtering mechanism, in its data selection and decision-making algorithms, ensures that the ultimately selected processing instance is in a normal operating state. From a technical perspective, this avoids distributing traffic requests to abnormal processing instances, reducing the possibility of request processing failures. During system operation, it reduces error handling and retry operations caused by abnormal processing instances, improving the success rate and reliability of request processing.

[0200] Furthermore, the load balancing node selects a processing instance from multiple processing instances that matches the available socket byte points using a round-robin balancing algorithm. In terms of resource scheduling, the round-robin algorithm ensures that each processing instance has the opportunity to process traffic requests sequentially. From a system stability perspective, it avoids any processing instance being under high load for extended periods, achieving balanced utilization of processing instances. Technically, it extends the lifespan of processing instances, reduces hardware damage and software failures caused by overuse of processing instances, and improves the overall stability of the system and the reliability of request processing.

[0201] When determining the selected processing instance using the round-robin load balancing algorithm, the load balancing node obtains the instance processing information and processing order corresponding to each processing instance, determines the first processing instance to process the previous traffic request, and designates the next processing instance whose processing order is adjacent to the first processing instance as the second processing instance and selects it as the selected processing instance. This approach ensures that processing instances process requests sequentially according to a preset order in terms of data processing flow and scheduling algorithm. From a technical perspective, this makes the request processing process more orderly, reducing conflicts and chaos in request processing. During system operation, it reduces errors and data inconsistencies caused by disordered request processing order, improving the efficiency and reliability of request processing.

[0202] Furthermore, the load balancing node first filters candidate processing instances that are in normal operating condition from multiple processing instances, and then selects the chosen processing instance that matches the processable socket byte point from the candidate processing instances according to the round-robin load balancing algorithm. This approach, combining filtering and round-robin load balancing algorithms, ensures both the normal operating condition of the selected processing instance and the balanced use of processing instances. From a technical perspective, this further improves the high availability and reliability of request processing. During system operation, it reduces request processing failures and system performance degradation caused by processing instance anomalies and load imbalances.

[0203] Furthermore, when the instance runtime information is the instance processing utilization rate, the load balancing node periodically reads the instance processing time slices at preset time intervals based on the process information corresponding to each processing instance, and calculates the instance processing utilization rate of each processing instance using these time slices. This method, in terms of data collection and calculation algorithms, can obtain the processing capacity and load status of processing instances in real time and accurately. From a technical perspective, it provides a more scientific and accurate basis for request distribution. During system resource allocation, it enables requests to be more rationally distributed to various processing instances, improving system resource utilization and request processing reliability.

[0204] Furthermore, when determining processable socket byte points, the load balancing node identifies multiple processing instances that are bound to each socket byte point, and determines the running status of each processing instance. Socket byte points bound to at least one processing instance in a normal running state are designated as processable socket byte points. This determination method ensures, in terms of data judgment and decision-making algorithms, that processable socket byte points are connected to normally functioning processing instances. From a technical perspective, this provides a reliable foundation for subsequent request distribution, avoiding the distribution of requests to invalid nodes. During system operation, it reduces request transmission delays and processing failures caused by invalid nodes, improving the reliability of request processing.

[0205] It should be noted that the request processing (including but not limited to object device information, object personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the object or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0206] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based request processing logic devices, etc., and are not limited to these.

[0207] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0208] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A request processing method, the method being executed by a load balancing node in a request processing system, the request processing system including a reverse proxy node, a virtual proxy node, and the load balancing node, wherein the reverse proxy node and the virtual proxy node exchange requests through multiple socket byte points. The method includes: When the reverse proxy node receives multiple traffic requests, it determines the processable socket byte point from the multiple socket byte points. For each of the processable socket byte points, a processing instance that has a binding relationship with the processable socket byte point is determined from the virtual proxy nodes to obtain multiple processing instances; From the plurality of processing instances, a selected processing instance matching the processable socket byte point is determined; and Based on the instance running information corresponding to each of the selected processing instances, the multiple traffic requests are distributed to each of the selected processing instances so that the selected processing instances can process the distributed traffic requests.

2. The method according to claim 1, wherein distributing the plurality of traffic requests to each of the selected processing instances based on the instance running information corresponding to each of the selected processing instances comprises: Obtain the instance runtime information corresponding to each of the selected processing instances; The instance runtime information includes runtime parameter values; Configure processing weights for each selected processing instance using the aforementioned operating parameter values; The processing weight is inversely proportional to the operating parameter value; The multiple traffic requests are distributed to the selected processing instances according to the processing weights.

3. The method according to claim 2, wherein configuring processing weights for each selected processing instance using each of the aforementioned operating parameter values ​​includes: The summation of each of the aforementioned operating parameter values ​​is calculated to obtain the total sum of the operating parameter values. For each selected processing instance, the processing weight configured for each selected processing instance is determined by the sum of the running parameter values ​​and the running parameter values ​​matched by the processing instance.

4. The method according to claim 3, wherein the summation of each of the operating parameter values ​​to obtain the total operating parameter value includes: The difference between each of the operating parameter values ​​and the preset value is calculated to obtain the parameter difference value of each operating parameter value. The sum of the parameter differences is then calculated to obtain the total operating parameter value. The step of determining the processing weight configured for each selected processing instance by using the sum of the running parameter values ​​and the running parameter values ​​matched to the processing instance includes: For each selected processing instance, determine the parameter difference between the preset value and the running parameter value that matches the selected processing instance; Based on the ratio of the differences between each parameter to the sum of the running parameter values, a processing weight is configured for each selected processing instance.

5. The method according to any one of claims 2 to 4, wherein distributing the plurality of traffic requests to each of the selected processing instances according to the processing weight comprises: Based on the processing weights configured for each of the selected processing instances, the original processing weights of each of the selected processing instances are adjusted. The processing weights are sorted sequentially, and the multiple traffic requests are distributed sequentially to the selected processing instances based on the sorting result; the processing weights are proportional to the number of traffic requests distributed.

6. The method according to any one of claims 1 to 5, wherein determining the selected processing instance matching the processable socket byte point from the plurality of processing instances comprises: From the plurality of processing instances, candidate processing instances that are in normal operating condition are selected; The normal operating state indicates that the processing instance is in a normal operating state of processing the traffic request; Selected processing instance that matches the processable socket byte point is determined from each of the candidate processing instances.

7. The method according to any one of claims 1 to 6, wherein determining the selected processing instance matching the processable socket byte point from the plurality of processing instances comprises: According to the round-robin load balancing algorithm, a selected processing instance that matches the processable socket byte point is determined from the plurality of processing instances.

8. The method according to claim 7, wherein determining the selected processing instance matching the processable socket byte point from the plurality of processing instances according to the round-robin load balancing algorithm comprises: Obtain the instance processing information corresponding to each of the processing instances, as well as the processing order between the processing instances; Based on the instance processing information described above, determine the first processing instance that processes the previous traffic request from the plurality of processing instances; The next processing instance whose processing order is adjacent to the first processing instance is taken as the second processing instance, and the second processing instance is determined as the selected processing instance that matches the processable socket byte point.

9. The method according to claim 7 or 8, wherein determining the selected processing instance matching the processable socket byte point from the plurality of processing instances according to the round-robin load balancing algorithm comprises: From the plurality of processing instances, candidate processing instances that are in normal operating condition are selected; According to the round-robin equalization algorithm, a selected processing instance that matches the processable socket byte point is determined from each of the candidate processing instances.

10. The method according to any one of claims 1 to 9, wherein the instance runtime information is instance processing utilization; The methods for obtaining instance runtime information corresponding to each selected processing instance include: Based on the process information corresponding to each of the processing instances, the instance processing time slices corresponding to each of the process information are read periodically at preset time intervals. The instance processing utilization rate is calculated for each of the instance processing time slices.

11. The method according to any one of claims 1 to 10, wherein determining the processable socket byte point from the plurality of socket byte points comprises: Identify multiple processing instances that have binding relationships with each of the socket byte points, and determine the running status of each of the processing instances; A socket byte point that is bound to at least one processing instance that is in normal operation is identified as a processable socket byte point.

12. A request processing apparatus, the apparatus being deployed in a load balancing node of a request processing system, the request processing system including a reverse proxy node, a virtual proxy node and the load balancing node, wherein the reverse proxy node and the virtual proxy node exchange requests through multiple socket byte points. The device includes: The node determination module is used to determine a processable socket byte point from the multiple socket byte points when the reverse proxy node receives multiple traffic requests. The instance determination module is used to determine, for each of the processable socket byte points, a processing instance that has a binding relationship with the processable socket byte point from the virtual proxy node, thereby obtaining multiple processing instances; The target instance determination module is used to determine a selected processing instance that matches the processable socket byte point from the plurality of processing instances; The request distribution processing module is used to distribute the multiple traffic requests to each of the selected processing instances based on the instance running information corresponding to each of the selected processing instances, so that the selected processing instances can process the distributed traffic requests.

13. A computer device comprising a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method according to any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

Images