Dynamic balance control method and system for multi-channel load
By allocating unique session identity according to real-time load status in the execution server and storing mapping relationships in the distributed cache, the problem of difficult session persistence in multi-channel network transmission is solved, and efficient session stickiness and load balancing are achieved.
Patent Information
- Application Number
- CN202411584285.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-07
- Publication Date
- 2025-02-14
- Estimated Expiration
- 2044-11-07
AI Technical Summary
In multi-channel network transmission, existing load balancing technologies are difficult to effectively maintain session persistence, resulting in lost session information.
By receiving user requests in the execution server and determining the load balancing policy based on the server's real-time status such as response time, processing capability level and request queue length, each user request is assigned a unique session identity and stored in the distributed cache The mapping relationship between session identity and server instances enables session stickiness and state sharing.
It improves session persistence during multi-channel network transmission, avoids the problem of context loss, and alleviates the load pressure of the system in high concurrency scenarios.
Smart Images

Figure CN119449804A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of load control, and in particular, relates to a dynamic balancing control method and system for multi-channel loads. Background Art
[0002] In large cloud service data centers, tens of thousands of user requests are distributed on different servers every day. This amount of data is very huge. Therefore, load balancing is a very important issue. With the surge in IT business, this balancing solution has received more and more attention. So how to optimize load distribution is a difficult problem that needs to be solved.
[0003] In the related technology, the network load balancing technology ECMP (Equal Cost Multi-Path) can be used. When there are multiple paths with the same cost (cost value), ECMP allows data packets to be dispersed among these paths, so as to improve the bandwidth utilization and redundancy of the network. If a user has two links to access the Internet, two static default routes can be set. The cost values of these two routes are both the default 1, pointing to two different next-hop addresses. When the ECMP function is turned on and the number of links for load balancing is specified, the traffic can be evenly distributed between the two links. At the same time, in order to enable the internal network to communicate with the Internet, the NAT (Network Address Translation) function can be enabled on the firewall interface connecting the two links. In this way, all internal traffic passing through these two links will be converted into public IP addresses and then sent to the Internet.
[0004] However, network load balancing technology also has some problems, such as low session persistence. Session persistence refers to the ability to ensure that the user's interaction state (session) remains consistent between multiple requests during the user's interaction with the network application. In a load balancing environment, especially when using multi-channel network transmission, ensuring session persistence is a key issue because requests may be routed to a different server than the last time, resulting in loss of session information. Summary of the invention
[0005] The present application provides a multi-channel load dynamic balancing control method and system for improving session persistence during multi-channel network transmission.
[0006] In a first aspect, the present application provides a dynamic balancing control method for multi-channel loads, wherein an execution server receives a number of user requests, each session includes a number of corresponding requests, and the number of requests of each session constitutes a number of user requests; The execution server determines the response time, processing capability level and request queue length of the processing server, and determines the load balancing strategy according to the response time, processing capability level and request queue length; The execution server allocates corresponding unique session identities to the plurality of user requests according to the load balancing strategy, and stores the corresponding unique session identities allocated to the plurality of user requests in the distributed cache system; When determining that a new user request is received, the execution server determines whether the new user request has a new unique session identity; if a new unique session identity exists, the execution server determines whether the unique session identity has the same session identity as the new user request; If it exists, the execution server determines the corresponding target application server instance according to the new unique session identity; The execution server receives the target processing result sent by the target application server instance and sends the target processing result to the user; if the target application server instance does not exist, the execution server determines the nearest application server instance, which is the application server instance that processes the user request at the latest time point; The execution server receives the latest processing result sent by the latest application server instance and sends the latest processing result to the user.
[0007] By adopting the above technical solution, the execution server first receives the user request, and calculates the optimal load balancing strategy based on the server's real-time status, such as response time, processing capacity level, and request queue length, and then assigns a unique session identity to each user request. When a new user request arrives, the execution server can quickly find the application server instance that previously processed the session based on its session identity, achieve session stickiness, and avoid the problem of context loss. If the new request carries a brand new session identity, the execution server can also select the one with the latest processing time point from many application server instances to process the request, and directly return to the session with the most recent processing time without performing unnecessary operations. At the same time, by storing the mapping relationship between session identities and server instances in a distributed cache, the system can achieve state sharing, and the failure of any application server instance will not cause the request processing to fail, thereby improving the session persistence during multi-channel network transmission.
[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the execution server determines the response time, processing capability level, and request queue length of the server, and determines a load balancing strategy based on the response time, processing capability level, and request queue length, specifically including: The execution server sends a preset request to each server at a preset frequency and starts timing; When the execution server determines that the preset response has been received, the execution server stops timing to obtain the response time; The execution server determines the number of the plurality of user requests as the request queue length; The execution server determines the load balancing strategy based on response time, processing power level and request queue length.
[0009] By adopting the above technical solution, the load distribution strategy is dynamically adjusted by comprehensively considering multiple influencing factors such as the server's response time, processing power level, and request queue length, thereby achieving precise control of load balancing. Specifically, by sending preset requests at a fixed frequency and counting the response time, the real-time performance of the server is objectively evaluated; by dynamically counting the number of requests, the load pressure of the server is timely grasped; by setting the processing power level, the processing efficiency of the server is quantified. Using the above three key parameters as the basis for determining the load balancing strategy, the system can adaptively adjust the request distribution strategy according to the actual operating status of the server, avoiding the degradation of system performance caused by uneven load and improving the overall performance of the system.
[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the execution server determines a load balancing strategy according to the response time, the processing capability level, and the request queue length, specifically including: The execution server inputs the response time, the processing capability level and the request queue length into the weight proportion function group to obtain the first weight, the second weight and the third weight corresponding to the response time, the processing capability level and the request queue length; The execution server determines a load balancing strategy according to the first weight, the second weight, and the third weight.
[0011] By adopting the above technical solution, firstly, this step comprehensively considers the three core indicators that reflect the performance of the server, namely, response time, processing capacity level and request queue length, and comprehensively describes the real-time load status of the server. By designing reasonable weight proportion functions for the three indicators respectively, the influence of each indicator on the server load is quantitatively evaluated. Secondly, by weighted summing the calculation results of the weight functions of the three indicators, a comprehensive evaluation result that takes into account the response speed, processing capacity and load pressure is obtained as the basis for selecting the load balancing strategy.
[0012] In combination with some embodiments of the first aspect, in some embodiments, the weight proportion function group is: W=ω1W RT F(L)+ω2W CL G(P)+ω3W QL In the formula, RT is the response time, CL is the processing capability level, QL is the request queue function, and W RT is the first weight, W CL is the second weight, W QL is the third weight, T is the time limit, t is the time variable, α is the adjustment factor, e-αt is the attenuation factor, x is a level value in the normal distribution, μ is the mean of the processing capacity level, σ is the standard deviation of the processing capacity level, β and γ are adjustment parameters, L is the system load, L0 is the system load reference value, P is the priority coefficient, k is an integer greater than zero, n is an index variable, ω1, ω2 and ω3 are W respectively. RT , W CL and W QL The corresponding basic weight coefficient satisfies ω1+ω2+ω3=1; e -αt is the attenuation factor. When the response time is larger, W RT The smaller it is, the smaller the first weight is. RT represents the response performance of the server at time t, e -αt Determines the relative weight of early and late response times, ensuring that more recent response times have a greater impact on the weight; is the exponent of the normal distribution function. When CL is equal to μ, W CL Minimum; γ is the midpoint of the function curve. When QL is equal to γ, W QL Equal to 0.5.
[0013] By adopting the above technical solutions, the weight functions of response time, processing capacity level and request queue length are introduced, the influence of each parameter on the load is quantified, and the scientific decision of the balancing strategy is realized. Among them, the calculation function of time integral plus attenuation factor is adopted for the response time weight, which not only takes into account the cumulative effect of response time, but also introduces the dynamic attenuation of time dimension, and objectively evaluates the real-time performance of the server; the probability density function of normal distribution is adopted for the processing capacity level weight, which reasonably describes the central trend and discrete distribution of processing capacity, and accurately estimates the possibility of task completion; the variant form of Logistic function is adopted for the request queue length weight, which flexibly depicts the nonlinear influence of queue length and dynamically predicts the load trend of the server. The calculation results of each weight function are weighted and fused to obtain the policy decision basis that takes into account efficiency, quality and load, which helps to find the optimal balancing solution in complex and changing scenarios.
[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after the execution server determines the response time, processing capability level, and request queue length of the server, and determines the load balancing strategy according to the response time, processing capability level, and request queue length, the method further includes: The execution server obtains historical performance data, including memory usage, graphics card usage, and network throughput; the execution server calculates the historical performance data using a time series analysis method to obtain a predicted processing capacity level; The execution server adjusts the load balancing strategy according to the predicted processing capacity to obtain an updated load balancing strategy.
[0015] By adopting the above technical solutions, firstly, by collecting historical data of key performance indicators such as memory usage, graphics card usage and network throughput of the server, a time series sample of the server load is formed; secondly, the algorithm model of time series analysis is used to decompose the time series samples by trend fitting, cycle identification, random disturbance, etc., accurately describing the inherent law of load evolution; then, the performance indicators are quantitatively predicted according to the extracted fluctuation characteristics, and the predicted processing capacity of the server within a certain time span is obtained; finally, the predicted processing capacity is fed back to the decision-making process of the balancing strategy, and the original strategy is dynamically corrected to generate the optimal load distribution plan that takes into account both the current status and future trends, thereby enhancing the predictability of the load balancing strategy.
[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after the execution server receives several user requests, the method further includes: The execution server determines the formats corresponding to the several user requests; The execution server deletes corresponding user requests having formats different from the preset format, and obtains a plurality of pre-processed user requests; The execution server sets all the pre-processed user requests into a server processing format to obtain the updated user requests.
[0017] By adopting the above technical solution, after receiving the user request, the request format check and preprocessing link is introduced. By filtering non-standard format requests and unifying the server processing format, the accuracy and efficiency of request processing are effectively improved. First, by real-time determination of the user request format, abnormal requests that do not conform to the preset format are discovered in time and eliminated before subsequent processing, thus avoiding the occupation and interference of invalid requests on system resources and ensuring the targeted processing of requests; secondly, by uniformly preprocessing qualified user requests and converting them into a standard format that can be directly processed by the server, the overhead of data conversion during request transmission is reduced and the real-time processing is improved; in addition, with the help of the request preprocessing mechanism, the decoupling of non-standard requests from server processing logic is achieved, which strengthens the cohesion of the system.
[0018] In combination with some embodiments of the first aspect, in some embodiments, the execution server assigns corresponding unique session identities to all user requests through a session identity manager in a session virtualization layer according to a load balancing strategy, and stores all user requests and all unique session identities in a distributed cache system, specifically including: The execution server determines a number of characteristics corresponding to all the number of user requests, the characteristics including data type, urgency and pre-processing time corresponding to the user requests; The execution server classifies the plurality of user requests into a first priority and a second priority according to the plurality of characteristics; The execution server assigns corresponding unique session identities to all the user requests through the session identity manager in the session virtualization layer according to the load balancing strategy, where the unique session identity includes a first priority and a second priority, and the user request corresponding to the first priority is processed earlier than the user request corresponding to the second priority; The execution server stores all several user requests and all unique session identities in a distributed cache system.
[0019] By adopting the above technical solution, firstly, by comprehensively analyzing the multi-dimensional characteristics of user requests, such as data type, urgency, preprocessing time, etc., the resource demand and timeliness requirements of the requests can be accurately grasped, providing a basis for priority division; secondly, the requests are prioritized according to their characteristics, differentiated session identities are set, and the priorities are mapped to the scheduling strategies of the requests, so that the system can flexibly arrange the order of processing according to the urgency and importance of the requests, thereby improving the response speed of key requests; thirdly, the session information of the requests is uniformly allocated and managed through the session identity manager, and the persistence of the request status is realized in combination with the distributed cache, which provides a global perspective for priority control and avoids scheduling conflicts between service nodes; finally, priority-based request scheduling helps to alleviate the load pressure of the system in high concurrency scenarios.
[0020] In a second aspect, an embodiment of the present application provides a dynamic balancing control system for multi-channel loads, the system comprising: one or more processors and a memory; the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and one or more processors call the computer instructions so that the system executes the method described in the first aspect and any possible implementation method of the first aspect.
[0021] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on a system, causes the system to execute the method described in the first aspect and any possible implementation of the first aspect.
[0022] In a fourth aspect, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a system, the system executes the method described in any possible implementation manner in the first aspect.
[0023] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. The present application provides a dynamic balancing control method for multi-channel loads. The execution server first receives user requests and calculates the optimal load balancing strategy based on the real-time status of the server, such as response time, processing capacity level, and request queue length, and then assigns a unique session identity to each user request. When a new user request arrives, the execution server can quickly find the application server instance that previously processed the session based on its session identity, thereby achieving session stickiness and avoiding the problem of context loss. If the new request carries a brand new session identity, the execution server can also select the one with the latest processing time point from among many application server instances to process the request, and directly return to the session with the most recent processing time without performing any unnecessary operations. At the same time, by storing the mapping relationship between session identities and server instances in a distributed cache, the system can achieve state sharing, and the failure of any application server instance will not cause the request processing to fail, thereby improving the session persistence during multi-channel network transmission.
[0024] 2. The present application provides a dynamic balancing control method for multi-channel loads. First, by collecting historical data of key performance indicators such as the server's memory usage, graphics card usage, and network throughput, a time series sample of the server load is formed; secondly, the algorithm model of time series analysis is used to perform trend fitting, cycle identification, random disturbance, and other decompositions on the time series samples, accurately describing the inherent laws of load evolution; then, the performance indicators are quantitatively predicted based on the extracted fluctuation characteristics, and the predicted processing capacity of the server within a certain time span is obtained; finally, the predicted processing capacity is fed back to the decision-making process of the balancing strategy, and the original strategy is dynamically corrected to generate an optimal load distribution plan that takes into account both the current state and future trends, thereby enhancing the predictability of the load balancing strategy.
[0025] 3. The present application provides a method for dynamic balancing control of multi-channel loads. First, by comprehensively analyzing the multi-dimensional characteristics of user requests, such as data type, urgency, preprocessing time, etc., the resource requirements and timeliness requirements of the requests are accurately grasped, providing a basis for priority division; secondly, the requests are prioritized according to their characteristics, differentiated session identities are set, and the priorities are mapped to the scheduling strategies of the requests, so that the system can flexibly arrange the order of processing according to the urgency and importance of the requests, thereby improving the response speed of key requests; thirdly, the session information of the requests is uniformly allocated and managed through the session identity manager, and the persistence of the request status is realized in combination with the distributed cache, which provides a global perspective for priority control and avoids scheduling conflicts between service nodes; finally, priority-based request scheduling helps to alleviate the load pressure of the system in high concurrency scenarios. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] Figure 1 It is a flow chart of a dynamic balancing control method for multi-channel loads in an embodiment of the present application; Figure 2 is another flow chart of a dynamic balancing control method for multi-channel loads in an embodiment of the present application; Figure 3 It is a schematic diagram of the physical device structure of a dynamic balancing control system for multi-channel loads in an embodiment of the present application. DETAILED DESCRIPTION
[0027] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to be used as limitations to the present application. As used in the specification and appended claims of the present application, the singular expressions one, a kind, described, described, described above, this and this are intended to also include plural expressions unless the context clearly indicates otherwise. It should also be understood that the terms used in the present application and / or refer to any or all possible combinations comprising one or more of the listed items.
[0028] In the following, the terms first and second are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of technical features indicated. Thus, features defined as first and second may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, the meaning of multiple is two or more.
[0029] The following describes an application scenario of this application: On a large e-commerce platform, hundreds of millions of users visit the website every day to browse, search, and place orders. In order to provide a high-quality user experience and ensure system stability, the e-commerce platform adopts a distributed deployment solution with multiple computer rooms and multiple server clusters. During peak access periods, the load pressure on each service node increases sharply, and an efficient load balancing mechanism is urgently needed to disperse traffic and improve the system's concurrent processing capabilities.
[0030] The operation and maintenance team decided to introduce ECMP-based network load balancing technology to achieve balanced distribution of traffic among multiple data centers. By configuring equal-cost routing on the core switch and enabling the ECMP function, user requests can be dynamically load-balanced among multiple links, effectively alleviating the pressure on a single node. At the same time, NAT technology is used to achieve conversion of internal and external network addresses, ensuring smooth communication between the data center and the public network.
[0031] However, in actual applications, the team found that load balancing at the network level alone is not perfect enough. Since ECMP uses a stateless message forwarding mechanism, multiple requests from the same user may be assigned to different servers, making it difficult to maintain consistent session status. For example, when a user browses product details, the system records the user's historical browsing history, shopping cart information, and other session data. But if the next request is forwarded to another server, the previous session information will be lost, giving the user a poor experience. In order to solve the above technical problems, the present application provides a multi-channel load dynamic balancing control method and system for improving session persistence during multi-channel network transmission. The following is combined with Figure 1 A dynamic balancing control method for a multi-channel load in an embodiment of the present application is described as follows: See also Figure 1 , which is a flow chart of a dynamic balancing control method for multi-channel loads in an embodiment of the present application.
[0032] S101, the execution server receives several user requests; The execution server receives several user requests from several application service channels through several network interfaces. Each session contains several corresponding requests, and the requests of all sessions constitute several user requests. For example, a user initiates two sessions on the system, one of which is a session on the shopping platform. Then this session may include five user requests: user login, browsing the product list, adding products to the shopping cart, viewing the shopping cart, and checkout. It is understandable that each session will correspond to a different number of user requests.
[0033] After that, the execution server determines the formats corresponding to the several user requests; The execution server deletes corresponding user requests having formats different from the preset format, and obtains a plurality of pre-processed user requests; The execution server sets all the pre-processed user requests into a server processing format to obtain the updated user requests.
[0034] In this step, the execution server receives a large number of user requests from different application service channels through multiple network interfaces. These requests correspond one-to-one to each user, reflecting their real-time needs for system services. In order to ensure the efficiency and accuracy of subsequent processing, the execution server first performs format verification on the received requests, removes those requests that do not conform to the preset format, and only retains pre-processed user requests that meet the requirements. Then, the execution server will uniformly convert these pre-processed requests into a standard processing format that the server can recognize, thereby reducing the data heterogeneity in the request transmission process and improving the interoperability of the system.
[0035] For example, suppose the execution server receives the following three user requests: Request 1: {user_id: 101, request_type: browse, timestamp: 2023-06-0110:30:00} Request 2: {user_name: Tom, ip: 192.168.0.1, request: search, time: 2023-06-0110:31:20} Request 3: {user_id: 102, request_type: order, product_id: 2001, timestamp: 2023-06-0110:32:15} The format of request 2 does not conform to the preset format, it lacks necessary fields and the timestamp format is incorrect, so it will be automatically rejected by the execution server. Requests 1 and 3 meet the format requirements, and the execution server will convert them into the following standard format: Pre-processing request 1: {user_id: 101, request_type: 1, parameters: {}, timestamp: 1685592600} Preprocessed request 3: {user_id: 102, request_type: 3, parameters: {product_id: 2001}, timestamp: 1685592735}.
[0036] S102, the execution server determines the response time, processing capability level and request queue length of the server, and determines a load balancing strategy according to the response time, processing capability level and request queue length; Next, the execution server determines the response time, processing capability level and request queue length of the server, and determines the load balancing strategy according to the response time, processing capability level and request queue length, specifically: sending a preset request to each server at a preset frequency and starting timing; When the execution server determines that the preset response has been received, the execution server stops timing to obtain the response time; The execution server determines the number of the plurality of user requests as the request queue length; The execution server determines a load balancing strategy according to the response time, the processing capability level and the request queue length. Specifically, the response time, the processing capability level and the request queue length are input into a weight proportion function group to obtain a first weight, a second weight and a third weight corresponding to the response time, the processing capability level and the request queue length; The execution server determines a load balancing strategy according to the first weight, the second weight, and the third weight.
[0037] Among them, the weight proportion function group is: W=ω1W RT F(L)+ω2W CL G(P)+ω3W QL In the formula, RT is the response time, CL is the processing capability level, QL is the request queue function, and W RT is the first weight, W CL is the second weight, W QL is the third weight, T is the time limit, t is the time variable, α is the adjustment factor, e -αt is the attenuation factor, x is a level value in the normal distribution, μ is the mean of the processing capacity level, σ is the standard deviation of the processing capacity level, β and γ are adjustment parameters, L is the system load, L0 is the system load reference value, P is the priority coefficient, k is an integer greater than zero, n is an index variable, ω1, ω2 and ω3 are W respectively. RT , W CL and W QL The corresponding basic weight coefficient satisfies ω1+ω2+ω3=1; e -αt is the attenuation factor. When the response time is larger, W RT The smaller it is, the smaller the first weight is. RT represents the response performance of the server at time t, e -αt Determines the relative weight of early and late response times, ensuring that more recent response times have a greater impact on the weight; is the exponent of the normal distribution function. When CL is equal to μ, W CL Minimum; γ is the midpoint of the function curve. When QL is equal to γ, W QL Equal to 0.5.
[0038] After that, the execution server obtains historical performance data, which includes memory usage, graphics card usage, and network throughput; The execution server uses time series analysis methods to calculate the historical performance data and obtain the predicted processing capacity level; The execution server adjusts the load balancing strategy according to the predicted processing capacity to obtain an updated load balancing strategy.
[0039] The execution server obtains three key indicators that reflect the current load status of the server through real-time monitoring and statistics: response time, processing capacity level, and request queue length. Among them, response time indicates the delay of the server responding to the request, processing capacity level indicates the computing performance level of the server, and request queue length reflects the number of pending requests. The execution server sends preset requests to the server at a certain frequency and times it to measure the response time. At the same time, the processing capacity level of the server is evaluated based on historical data and current conditions. The request queue length can be obtained by counting the number of user requests received.
[0040] After obtaining the above three indicators, the execution server uses them as input, substitutes them into the preset weight proportion function group, and calculates the weight coefficient corresponding to each indicator. This set of weight coefficients forms a dynamic load balancing strategy, which comprehensively considers the real-time performance and load pressure of the server and can be used to guide subsequent request scheduling.
[0041] For example, assume that the execution server includes two application servers S1 and S2, and the following data is obtained after detection: S1: response time RT1 = 150ms, processing capacity level CL1 = 4, request queue length QL1 = 80 S2: response time RT2 = 120ms, processing capacity level CL2 = 5, request queue length QL2 = 50 Substituting these data into the weight proportion function and taking parameters α=0.02,β=0.1,γ=60,ω1=0.4,ω2=0.3,ω3=0.3, we get: S1: W_(RT1)=0.38, W_(CL1)=0.80, W_(QL1)=0.73, W1=0.62 S2: W_(RT2)=0.41, W_(CL2)=0.92, W_(QL2)=0.27, W2=0.38 Thus, a load balancing strategy {S1: 62%, S2: 38%} is obtained, that is, 62% of the requests are preferentially allocated to S1 and 38% to S2. This strategy dynamically adapts to the real-time status of the server and can more efficiently utilize system resources. The weighted calculation, time series prediction and other technologies used in step S102 greatly improve the intelligent level of load balancing.
[0042] S103, the execution server assigns corresponding unique session identities to all the user requests according to the load balancing strategy, and stores the corresponding unique session identities to all the user requests in the distributed cache system; The execution server assigns corresponding unique session identities to all the user requests through the session identity manager in the session virtualization layer according to the load balancing strategy, and stores all the user requests and all the unique session identities in the distributed cache system, where all the first user requests correspond to the first unique session identity, and all the second user requests correspond to the second unique session identity. The specific implementation method of this step will be described below and will not be repeated here.
[0043] S104: When the execution server determines that a new user request has been received, it determines whether a new unique session identity exists in the new user request; In this step, the execution server continuously monitors service requests from users. Once a new user request is received, the unique session identity is immediately determined. The key here is to identify new users who initiate requests for the first time and assign them a new session identity.
[0044] In specific implementation, the execution server will extract the user identification information (such as user ID, device ID, etc.) in the new request and compare it with the existing session identity records in the cache system. If no match is found, it means that this is the first request from a new user and a new unique session identity needs to be generated for it.
[0045] For example, suppose the execution server receives the following new user request: {user_id: 1001, device_id: "abc123", timestamp: 1623310202} After querying the cache, it is found that there is no existing session record with user_id=1001 or device_id="abc123" as the identifier, so it is determined that this is the first request from a new user, and a new unique session identity needs to be generated, such as session_id="s_10001".
[0046] This step can be achieved through efficient cache query and unique ID generation algorithms (such as UUID, Snowflake, etc.). This can not only quickly determine the identity of new users, but also avoid the problem of duplicate session ID allocation, ensuring the accuracy of subsequent session management.
[0047] S105, the execution server determines whether there is a session identity in the unique session identity that is the same as the session identity requested by the new user; If there is a new unique session identity, the execution server determines whether there is a session identity in the unique session identity that is the same as the new user request. If there is no new unique session identity, it means that the user request received this time is generated by a new session initiated by the user, and then steps S101-S103 are re-executed.
[0048] Following the previous step, for the identified new user request, the execution server needs to further determine whether the session identity it carries already exists. The purpose of this step is to identify those requests that are from new users but actually belong to existing sessions, so as to achieve session continuity.
[0049] In specific implementation, the execution server compares the session identity carried by the new request (such as session_id in the cookie) with the unique session identity set already in the cache system. If an exact match is found, it means that although the new request comes from a new user, it actually belongs to an existing session and needs to be processed as an existing session.
[0050] For example, assume that the new user request identified in the previous step S104 carries the following Cookie information: session_id = "s_09527", user_id = 1001 After querying the cache, it is found that session_id="s_09527" already exists in the unique session set, so it is determined that the request belongs to a previously established session, although it comes from a new user ID.
[0051] This step can be achieved by using a cache matching algorithm (such as a hash table, Bloom filter, etc.) to achieve fast matching. This can avoid creating session instances for requests of existing sessions and reduce unnecessary system overhead. At the same time, matching based on session IDs can also help accurately associate session contexts when multiple users share, improving user experience.
[0052] S106, the execution server determines the corresponding target application server instance according to the new unique session identity; If it exists, the execution server determines the corresponding target application server instance based on the new unique session identity. For new user requests that are determined to belong to an existing session, the execution server will directly determine the corresponding target application server instance based on its unique session identity. This is possible because during the session creation phase, the execution server has already pre-assigned a server instance to handle each session based on the load balancing strategy, and stored this mapping relationship in the distributed cache system.
[0053] In the specific implementation, the execution server starts with the session ID carried in the request and searches for the corresponding server instance information in the cache system. Once found, the request can be directly forwarded to the instance for processing without repeated server selection and scheduling.
[0054] For example, continuing with the scenario in S105, assume that the following session-instance mapping relationship is stored in the cache system: session_id="s_09527"->instance_id="svr_031" Then, when receiving a new user request carrying session_id="s_09527", the execution server can directly forward it to the application server instance with ID "svr_031".
[0055] This step makes full use of the high-speed reading characteristics of the cache system, allowing the execution server to quickly locate the target server instance based on the session ID. This not only reduces the latency of request distribution, but also maximizes the reuse of previously created session contexts to avoid the overhead of repeated creation. At the same time, since the binding relationship between the session and the instance is predetermined, this static allocation method is also more conducive to maintaining session affinity and improving processing consistency.
[0056] S107, the execution server receives the processing result sent by the application server instance and sends the processing result to the user; in this step, the execution server returns the request processing result generated by the server instance to the corresponding user client, completing a complete request-response process.
[0057] Specifically, the execution server reads the processing result data written by the server in the previous step from the distributed cache, and finds the original user request associated with it based on the session ID. Then, the execution server returns the processing result to the client that initiated the request through the corresponding network interface and communication protocol. While returning the result, the execution server may also perform some post-operations, such as recording request logs, updating monitoring statistics, etc. When the application server instance completes processing the user request, it returns the result to the execution server. After receiving the processing result, the execution server needs to send it to the end user in a timely manner to complete a complete request-response process.
[0058] In specific implementation, the execution server and the application server instance usually use an efficient inter-process communication mechanism (such as RPC, message queue, etc.) to exchange data. After receiving the processing result, the execution server will determine which user terminal the result needs to be returned to based on the source information of the request (such as source IP address, session ID, etc.). Subsequently, the execution server transmits the processing result back through the network connection established with the terminal (such as TCP connection, WebSocket, etc.).
[0059] For example, assume that the application server instance "svr_031" sends a processing result message to the execution server: {session_id: "s_09527", result: {code: 0, msg: "success", data: {...}}} After receiving the result, the execution server queries the corresponding user request information through session_id: {user_ip: "101.32.5.6:2381", user_agent: "Chrome / 91.0",...} Based on this, the execution server sends the result content back to the user's Chrome browser through the TCP connection established on 101.32.5.6:2381, completing the interactive closed loop.
[0060] This step is the end of the request-response process. The execution server plays the role of a coordinator, responsible for transmitting data between the server and the client. To reduce coupling, the server usually uses a different communication protocol from the client, and the execution server needs to complete the protocol conversion between the two. At the same time, in order to improve transmission efficiency, the execution server will also compress and encrypt the result data to ensure communication quality.
[0061] S108, the execution server determines the nearest application server instance; If it does not exist, the execution server determines the nearest application server instance, which is the application server instance that processes the user request at the latest time. For a user request with a new session identity, the execution server needs to select one from the application server instances to process the session. The key here is to determine the server instance that processes the request the latest from the current time point.
[0062] For example, suppose there are three application server instances in the cluster, and the timestamps of their most recent completed request processing are: svr_017:1623305627(10 minutes ago) svr_032:1623309436(1 minute ago) svr_058:1623308293(3 minutes ago) By comparison, we can see that svr_032 has the largest timestamp, which means it has recently completed the request processing, so it will be selected as the processor of this new session request.
[0063] S109: The execution server receives the latest processing result sent by the latest application server instance and sends the latest processing result to the user.
[0064] Similar to step S107, once the new session request is successfully assigned to the nearest application server instance, the instance will create a new session environment, process the user request and generate a processing result. Subsequently, the result will be sent by the instance to the execution server, which will then forward it to the user terminal, completing the closed-loop process of this request.
[0065] The above embodiments have the following beneficial effects: The execution server first receives the user request and calculates the optimal load balancing strategy based on the server's real-time status, such as response time, processing capacity level, and request queue length, and then assigns a unique session identity to each user request. When a new user request arrives, the execution server can quickly find the application server instance that previously processed the session based on its session identity, achieving session stickiness and avoiding the problem of context loss. If the new request carries a brand new session identity, the execution server can also select the one with the latest processing time from among the many application server instances to process the request, and directly return to the session with the most recent processing time without performing any unnecessary operations. At the same time, by storing the mapping relationship between session identities and server instances in a distributed cache, the system can achieve state sharing, and the failure of any application server instance will not cause the request processing to fail, thereby improving the session persistence during multi-channel network transmission.
[0066] Taking into account multiple influencing factors such as the server's response time, processing power level, and request queue length, the load distribution strategy is dynamically adjusted to achieve precise control of load balancing. Specifically, by sending preset requests at a fixed frequency and counting the response time, the real-time performance of the server is objectively evaluated; by dynamically counting the number of requests, the server's load pressure is timely grasped; by setting the processing power level, the server's processing efficiency is quantified. Taking the above three key parameters as the basis for determining the load balancing strategy, the execution server can adaptively adjust the request distribution strategy according to the actual operating status of the server, avoiding the degradation of system performance caused by uneven load and improving the overall performance of the system.
[0067] This step comprehensively considers the three core indicators that reflect server performance, namely response time, processing capacity level and request queue length, and comprehensively describes the real-time load status of the server. By designing reasonable weight proportion functions for the three indicators respectively, the influence of each indicator on the server load is quantitatively evaluated. Secondly, by weighted summing the calculation results of the weight functions of the three indicators, a comprehensive evaluation result that takes into account response speed, processing capacity and load pressure is obtained as the basis for selecting load balancing strategies.
[0068] The weight functions of response time, processing capacity level and request queue length are introduced to quantify the influence of each parameter on the load and realize the scientific decision of the balancing strategy. Among them, the calculation function of time integral plus attenuation factor is adopted for the response time weight, which not only takes into account the cumulative effect of response time, but also introduces the dynamic attenuation of time dimension, and objectively evaluates the real-time performance of the server; the probability density function of normal distribution is adopted for the processing capacity level weight, which reasonably describes the central trend and discrete distribution of processing capacity and accurately estimates the possibility of task completion; the variant form of Logistic function is adopted for the request queue length weight, which flexibly depicts the nonlinear influence of queue length and dynamically predicts the load trend of the server. The calculation results of each weight function are weighted and fused to obtain the policy decision basis that takes into account efficiency, quality and load, which helps to find the optimal balancing solution in complex and changing scenarios.
[0069] By collecting historical data of key performance indicators such as server memory usage, graphics card usage, and network throughput, a time series sample of server load is formed; secondly, the algorithm model of time series analysis is used to decompose the time series samples by trend fitting, cycle identification, random disturbance, etc., accurately describing the inherent law of load evolution; then, the performance indicators are quantitatively predicted based on the extracted fluctuation characteristics, and the predicted processing capacity of the server within a certain time span is obtained; finally, the predicted processing capacity is fed back to the decision-making process of the balancing strategy, and the original strategy is dynamically corrected to generate the optimal load distribution plan that takes into account both the current status and future trends, thereby enhancing the predictability of the load balancing strategy.
[0070] After receiving user requests, we introduced the request format check and preprocessing process. By filtering non-standard format requests and unifying the server processing format, we effectively improved the accuracy and efficiency of request processing. First, by real-time determination of the user request format, we can promptly discover abnormal requests that do not conform to the preset format and remove them before subsequent processing, thus avoiding the occupation and interference of invalid requests on system resources and ensuring the targeted processing of requests. Secondly, by uniformly preprocessing qualified user requests and converting them into a standard format that the server can directly process, we can reduce the data conversion overhead during request transmission and improve the real-time processing. In addition, with the help of the request preprocessing mechanism, we can achieve the decoupling of non-standard requests from server processing logic and strengthen the cohesion of the system.
[0071] In step S103 of the above embodiment, the execution server assigns corresponding unique session identities to all the user requests through the session identity manager in the session virtualization layer according to the load balancing strategy, and stores all the user requests and all the unique session identities in the distributed cache system. Figure 2 Describe how to assign the corresponding unique session identity: See also Figure 2 , is another flow chart of a dynamic balancing control method for multi-channel loads in an embodiment of the present application.
[0072] S201, the execution server determines a number of features corresponding to all a number of user requests; The execution server determines a number of features corresponding to all the number of user requests, the features including data types, urgency and pre-processing time corresponding to the user requests.
[0073] In this step, the execution server conducts an in-depth analysis of all received user requests and extracts multiple feature dimensions related to request priority scheduling. By examining factors such as the type of data carried by the request, the urgency of processing, and the time required for preprocessing, the importance of the request and the timeliness of the response can be more comprehensively evaluated.
[0074] Among them, the data type can reflect the business attributes and complexity of the request. For example, in e-commerce scenarios, the data types involved in operations such as browsing products, adding to shopping carts, and submitting orders vary greatly, and the corresponding processing logic and resource requirements are also different. The urgency reflects the priority processing demands of the request, which can usually be determined by the user's display mark or the execution server's automatic judgment. Some requests with high real-time requirements, such as online payment and inventory query, need to be given a higher urgency. The preprocessing time mainly measures the preparation time of the request before entering the actual processing process, including data verification, field mapping, format conversion and other steps. Too long preprocessing time will slow down the overall response speed of the request, so it is also an important reference factor for determining priority.
[0075] For example, for a batch of newly received user requests, the execution server may extract the following feature information: Request 1: {data_type: browse, urgency_level: 3, preprocess_time: 15} Request 2: {data_type: add_to_cart, urgency_level: 4, preprocess_time: 20} Request 3: {data_type: submit_order, urgency_level: 5, preprocess_time: 10} Request 4: {data_type: browse, urgency_level: 3, preprocess_time: 18} Request 5: {data_type: add_to_cart, urgency_level: 4, preprocess_time: 22} It can be seen that these requests are different in data type, urgency, and preprocessing time. Based on this, the execution server will prioritize the requests and treat them differently in subsequent scheduling. Step S201 reveals the inherent differences of the requests by extracting multi-dimensional features from the original request data, which provides an important basis for realizing a more sophisticated and intelligent load balancing mechanism.
[0076] S202, the execution server classifies a plurality of user requests into a first priority and a second priority according to a plurality of characteristics; The execution server divides all requests into different priorities based on the request features extracted in the previous step, so as to give differentiated resource allocation and scheduling strategies in subsequent processing. Generally, multiple priority levels can be set according to business needs and system load conditions. In this example, they are simplified into two categories: first priority (high priority) and second priority (normal priority).
[0077] Specifically, the execution server will comprehensively evaluate multiple feature dimensions of the request and calculate a comprehensive priority score. Requests with higher scores are classified as the first priority, and requests with lower scores are classified as the second priority. The evaluation function for priority division can be flexibly set according to actual conditions. For example, different weights can be given to different features, and specific threshold conditions can be set. A simple example is: requests with an urgency of 5 and a preprocessing time of less than 20ms are classified as the first priority, and other requests are classified as the second priority.
[0078] For example, based on the request features extracted in the previous step, the execution server may obtain the following priority division results: Request 1: Second priority Request 2: Second priority Request 3: First priority Request 4: Second priority Request 5: Second priority Request 3 is classified into the high priority queue because it has the highest urgency and the shortest preprocessing time, meeting the first priority condition. Other requests do not meet the threshold requirements and are classified into the ordinary second priority.
[0079] S203, the execution server allocates corresponding unique session identities to all the user requests through the session identity manager in the session virtualization layer according to the load balancing strategy; The execution server assigns corresponding unique session identities to all user requests through the session identity manager in the session virtualization layer according to the load balancing strategy. The unique session identity includes a first priority and a second priority. The user request corresponding to the first priority is processed earlier than the user request corresponding to the second priority.
[0080] Based on the request priority division in step S202, the execution server further allocates a unique session identity to each request and clarifies the scheduling order of the request in subsequent processing. Specifically, the session identity manager uses a priority-aware session ID allocation algorithm under the premise of following the load balancing strategy to generate unique identifiers in different formats for first-priority and second-priority requests. For example, a priority prefix can be added to the ID string, or a distinction can be made in the numbering sequence so that the session ID of a high-priority request is ranked first. This ensures that the load is evenly shared among multiple server instances while giving priority to important requests. At the same time, the manager will also record metadata such as the target server and creation time mapped to each session ID, and store them in the distributed cache system to provide support for subsequent session queries and status synchronization.
[0081] For example, for the requests of different priorities divided in the previous step, the session identity manager may perform the following allocation operations: Request 1 → Session ID: normal_session_1685593600_1, metadata: {target_server: S1, priority: normal, create_time: 2023-06-0110:40:00} Request 2 → Session ID: normal_session_1685593700_2, metadata: {target_server: S2, priority: normal, create_time: 2023-06-0110:41:40} Request 3 → Session ID: vip_session_1685593300_1, metadata: {target_server: S1, priority: high, create_time: 2023-06-0110:35:00} Request 4 → Session ID: normal_session_1685593720_3, metadata: {target_server: S1, priority: normal, create_time: 2023-06-0110:42:00} Request 5 → Session ID: normal_session_1685593750_4, metadata: {target_server: S2, priority: normal, create_time: 2023-06-0110:42:30} As you can see, the high-priority request 3 is assigned a special session ID starting with vip, indicating that it will be scheduled for execution first. In addition, the last digits of all session IDs are sorted by priority and creation time, further clarifying the order of request processing. At the same time, the session metadata also records important information such as the priority and target server of each request.
[0082] S204: The execution server stores all user requests and all unique session identities in the distributed cache system.
[0083] The execution server stores the request session identity mapping and related metadata generated in step S203 persistently in the distributed cache system. As a high-speed, horizontally scalable memory data storage, the distributed cache can meet the session query and state access requirements of massive requests with low latency.
[0084] Specifically, the session identity manager uses the session ID corresponding to each request as the key, and the JSON object consisting of the request data and metadata as the value, and writes it to the distributed cache in the form of a key-value pair. By distributing and storing data in multiple cache nodes, the memory space of the cluster can be fully utilized to reduce the storage pressure of a single node. At the same time, the cache system also provides an efficient data distribution and synchronization mechanism to ensure that all server instances can obtain the latest session status data in a timely manner, thereby avoiding status inconsistency problems.
[0085] In the above embodiment, by comprehensively analyzing the multi-dimensional characteristics of user requests, such as data type, urgency, preprocessing time, etc., the resource demand and timeliness requirements of the request are accurately grasped, providing a basis for priority division; secondly, the request is prioritized according to its characteristics, differentiated session identities are set, and the priority is mapped to the scheduling strategy of the request, so that the execution server can flexibly arrange the processing order according to the urgency and importance of the request, thereby improving the response speed of key requests; thirdly, the session information of the request is uniformly allocated and managed through the session identity manager, and the persistence of the request state is realized in combination with the distributed cache, which provides a global perspective for priority control and avoids scheduling conflicts between service nodes; finally, priority-based request scheduling helps to alleviate the load pressure of the system in high concurrency scenarios.
[0086] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.
[0087] As used in the above embodiments, depending on the context, the term when can be interpreted to mean if or after or in response to determining or in response to detecting. Similarly, depending on the context, the phrase upon determining or upon detecting (the stated condition or event) can be interpreted to mean if determining or in response to determining or upon detecting (the stated condition or event) or in response to detecting (the stated condition or event).
[0088] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media integration. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk), etc.
[0089] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.
Claims
1. A dynamic balancing control method for multi-channel loads, characterized in that: include: The execution server receives a plurality of user requests, each session includes a corresponding plurality of requests, and the plurality of requests of each session constitute the plurality of user requests; The execution server determines the response time, processing capability level and request queue length of the processing server, and determines a load balancing strategy according to the response time, the processing capability level and the request queue length; The execution server allocates corresponding unique session identities to the plurality of user requests according to the load balancing strategy, and stores the corresponding unique session identities allocated to the plurality of user requests in the distributed cache system; The execution server, when determining that a new user request is received, determines whether the new user request has a new unique session identity; If the new unique session identity exists, the execution server determines whether there is a session identity in the unique session identity that is the same as the session identity requested by the new user; If it exists, the execution server determines the corresponding target application server instance according to the new unique session identity; The execution server receives the target processing result sent by the target application server instance and sends the target processing result to the user; If not, the execution server determines the nearest application server instance, where the nearest application server instance is the application server instance that processes the user request at the latest time; The execution server receives the latest processing result sent by the latest application server instance and sends the latest processing result to the user.
2. The method according to claim 1, characterized in that The execution server determines the response time, processing capability level and request queue length of the server, and determines a load balancing strategy according to the response time, the processing capability level and the request queue length, specifically including: The execution server sends a preset request to each server at a preset frequency and starts timing; When the execution server determines that a preset response has been received, the execution server stops timing to obtain the response time; The execution server determines the number of the plurality of user requests as the request queue length; The execution server determines a load balancing strategy according to the response time, the processing capability level and the request queue length.
3. The method according to claim 2, characterized in that The execution server determines a load balancing strategy according to the response time, the processing capability level and the request queue length, specifically including: The execution server inputs the response time, the processing capability level and the request queue length into a weight proportion function group to obtain a first weight, a second weight and a third weight corresponding to the response time, the processing capability level and the request queue length; The execution server determines the load balancing strategy according to the first weight, the second weight and the third weight.
4. The method according to claim 3, characterized in that The weight proportion function group is: W=ω1W RT F(L)+ω2W CL G(P)+ω3W QL In the formula, RT is the response time, CL is the processing capability level, QL is the request queue function, and W RT is the first weight, the W CL is the second weight, the W QL is the third weight, T is the time upper limit, t is the time variable, α is the adjustment factor, and e -αt is the attenuation factor, x is a level value in the normal distribution, μ is the mean of the processing capability level, σ is the standard deviation of the processing capability level, β and γ are adjustment parameters, L is the system load, L0 is the system load reference value, P is the priority coefficient, k is an integer greater than zero, n is an index variable, ω1, ω2 and ω3 are the values of W respectively. RT , the W CL and the W QL The corresponding basic weight coefficient satisfies ω1+ω2+ω3=1; The -αt is the attenuation factor. When the response time is larger, the W RT The smaller the value, the smaller the first weight proportion. RT represents the response performance of the server at time t, the e -αt Determines the relative weight of early and late response times, ensuring that more recent response times have a greater impact on the weight; Said is the exponent of the normal distribution function. When the CL is equal to μ, the W CL Minimum; The γ is the midpoint of the function curve. When the QL is equal to the γ, the W QL Equal to 0.
5.
5. The method according to claim 2, characterized in that: After the execution server determines the response time, processing capability level and request queue length of the server, and determines the load balancing strategy according to the response time, the processing capability level and the request queue length, the method further includes: The execution server acquires historical performance data, wherein the historical performance data includes memory usage, graphics card usage and network throughput; The execution server calculates the historical performance data using a time series analysis method to obtain a predicted processing capacity level; the execution server adjusts the load balancing strategy based on the predicted processing capacity to obtain an updated load balancing strategy.
6. The method according to claim 1, characterized in that After the execution server receives a number of user requests, the method further includes: The execution server determines the formats corresponding to the plurality of user requests; The execution server deletes the corresponding user requests whose formats are different from the preset formats, and obtains a plurality of pre-processed user requests; The execution server sets all the pre-processed user requests into a server processing format to obtain the updated user requests.
7. The method according to claim 1, characterized in that The execution server assigns corresponding unique session identities to all the plurality of user requests according to the load balancing strategy, and stores the corresponding unique session identities assigned to all the plurality of user requests in the distributed cache system, specifically including: The execution server determines a number of features corresponding to all the number of user requests, wherein the features include data types, urgency levels, and preprocessing times corresponding to the user requests; The execution server classifies the plurality of user requests into a first priority and a second priority according to the plurality of characteristics; The execution server assigns corresponding unique session identities to all the user requests according to the load balancing strategy, where the unique session identity includes the first priority and the second priority, and the user request corresponding to the first priority is processed earlier than the user request corresponding to the second priority; The execution server stores all the plurality of user requests and all the unique session identities in a distributed cache system.
8. A dynamic balancing control system for multi-channel loads, characterized in that: The system comprises: One or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the system to execute the method as described in any one of claims 1-7.
9. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on a system, the system is caused to execute the method according to any one of claims 1 to 7.
10. A computer program product, characterized in that When the computer program product is run on a system, the system is caused to execute the method according to any one of claims 1 to 7.
Citation Information
Patent Citations
Load balancing method, device and system for server cluster
CN111694663A
Load balancing method and device, medium and electronic equipment
CN116016526A
Load balancing method and device, equipment and storage medium
CN117319406A
Load balancing method and system
US20070198721A1