Server load balancing method and device, medium and program product

Abstract

The invention provides a server load balancing method and device, a medium and a program product, and a specific implementation mode of the application comprises the steps that after a load balancer receives a task request, attributes such as basic types (authentication, authorization and charging), priorities and protocol versions of the request are analyzed firstly; meanwhile, the resource utilization rate, response time, health state and other information of the server cluster are monitored in real time, a dynamic strategy decision tree is constructed based on the data, in addition, the load balancer sends a health check request to the server regularly, whether the server breaks down or not is judged according to the state information returned by the server, and the service life of the server is prolonged. And if a fault exists, removing the fault from the request allocation list to ensure that the request is always allocated to the available server. According to the method, the dynamic adjustment of the load balancing strategy and the update of the request allocation list are realized, and the resource utilization rate of the server is improved so as to cope with the rapidly changed request load and flow mode.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a server load balancing method, device, medium and program product. BACKGROUND

[0002] Traditional server load balancing methods usually adopt fixed load balancing strategies, such as simple polling method, without fully considering the attribute differences of requests and real-time state of servers. In actual application, different types of requests (such as authentication, authorization and charging) have different requirements for processing speed and resource consumption, and there are significant differences in request priorities.

[0003] Therefore, there is an urgent need for a method that can dynamically adjust load balancing based on real-time data of request attributes and server state, in order to improve server resource utilization and cope with rapidly changing request load and traffic patterns. SUMMARY

[0004] To this end, the present application provides a server load balancing method, system, electronic device and computer program product to at least partially solve the above technical problems.

[0005] The present application provides a server load balancing method, comprising the following method steps: In response to receiving a task request, the load balancer selects a target server, specifically, the load balancer selects an available target server from a request distribution list based on a preset load balancing strategy; The load balancer forwards the task request to the target server; Wherein, the request distribution list is updated regularly, specifically: the load balancer regularly sends a health check request to one or more servers in the server cluster, the one or more servers respond to the health check request and return their own state information, the load balancer determines whether the one or more servers have faults based on the state information, and if so, removes the one or more servers from the request distribution list.

[0006] Another aspect of the present application also provides a server load balancing device, comprising: a selection module, configured to respond to a task request, the load balancer selects a target server, specifically, the load balancer selects an available target server from a request distribution list based on a preset load balancing strategy; A request forwarding module is configured to forward the task request to the target server by the load balancer; An updating module is configured to periodically send a health check request to one or more servers in the server cluster, the one or more servers respond to the health check request and return self state information, and the load balancer determines whether the one or more servers are faulty based on the state information, and if so, removes the one or more servers from the request distribution list.

[0007] In another aspect, the application provides an electronic device, comprising at least one processor, and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the server load balancing method as described above.

[0008] In another aspect, the application provides a computer readable storage medium having stored thereon computer program instructions executable by a processor to implement the server load balancing method as described above.

[0009] In another aspect, the application provides a computer program product comprising a computer program executable by a processor to implement the server load balancing method as described above.

[0010] In the scheme provided by the embodiments of the application, after receiving a task request, the load balancer first analyzes the basic types (authentication, authorization, and charging) of the request, priority, and protocol version, and simultaneously monitors resource utilization, response time, and health status of the server cluster in real time. Based on these data, a dynamic policy decision tree is constructed, for example, high-priority online examination authentication requests are preferentially distributed to servers with high performance and low load by using the "minimum connection number + response time weighted" strategy, and low-priority requests are distributed to servers by using the polling and weighted polling strategies according to the server state. In addition, the load balancer periodically sends a health check request to the server, determines whether the server is faulty according to the state information returned by the server, and removes the server from the request distribution list if the server is faulty, thereby ensuring that the request is always distributed to an available server. The method realizes dynamic adjustment of the load balancing strategy and updating of the request distribution list, and improves the resource utilization of the server and the stability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the application, the following will briefly introduce the drawings needed in the embodiments. It should be understood that the following drawings only show some of the embodiments of the application, and therefore should not be considered as limiting the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0012] Other features, objects, and advantages of the application will become more apparent from the following detailed description when read in connection with the following drawings: Figure 1 A server load balancing method provided by an embodiment of the application.

[0013] Figure 2 A server load balancing device provided by an embodiment of the application.

[0014] Figure 3 A device provided by an embodiment of the application.

[0015] Figure 4 A system architecture provided by an embodiment of the application. DETAILED DESCRIPTION

[0016] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0017] In a typical configuration of the present application, the devices of the terminal and the service network each include one or more processors (CPU), input / output interfaces, network interfaces and memories.

[0018] The memory can include non-permanent memory in a computer readable medium, random access memory (RAM) and / or non-volatile memory such as read only memory (ROM) or flash memory (flash RAM). The memory is an example of the computer readable medium.

[0019] The computer readable medium includes permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. The information can be computer program instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic disk storage or other magnetic storage device, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0020] Currently widely used RADIUS solutions mainly include single RADIUS servers and DNS-based load balancing. Due to the large user base, high request volume, and lack of smooth transition methods for daily product upgrades and iterations, service stability cannot be guaranteed. DNS-based load balancing uses DNS resolution to distribute requests to different RADIUS servers, achieving load balancing and failover. However, DNS-based load balancing lacks real-time performance and precise control, making it difficult to handle complex load balancing strategies. Existing technologies have limitations in handling real-time requests and dynamic load adjustments, making it difficult to cope with rapidly changing request loads and traffic patterns.

[0021] To address the aforementioned problems, this application proposes a server load balancing method. The technical solution of this application will be described in detail below with reference to various embodiments.

[0022] like Figure 1 As shown in the diagram, this invention discloses a server load balancing method, which includes the following steps: Step S10: In response to receiving a task request, the load balancer selects a target server. Specifically, the load balancer selects an available target server from the request allocation list based on a preset load balancing strategy.

[0023] In some embodiments, preferably, the load balancing strategy is set based on task request attributes and / or server cluster status, wherein the task request attributes include at least one of request base type, request priority, or request protocol version. Before selecting a target server, the load balancer further includes parsing the request task, including: base type identification: the base type includes authentication, authorization, or accounting; priority labeling: determining the request priority based on user attributes and / or business tags carried by the request task; and protocol version identification: identifying the RADIUS protocol version followed by the request task.

[0024] Specifically, such as Figure 4 The system architecture diagram shown is for illustrative purposes. The system includes user terminals (including PC and mobile terminals), switches / ACs, and different cloud platforms, namely Tencent Cloud and Alibaba Cloud. The different cloud platforms include load balancers (CLB load balancer for Tencent Cloud and SLB load balancer for Alibaba Cloud), RADIUS server clusters, and control centers. Data synchronization is also included between the two cloud platforms.

[0025] For example, a user can send a relevant request through a user terminal. The task request is received by the load balancer through a switch. After receiving the task request, the load balancer first performs a comprehensive analysis of the task request to obtain key attribute information. For example, taking online education as an application scenario (unless otherwise specified, the examples below all use online education as an example), the analysis of the task request specifically includes: Basic type identification: This determines whether the request type is authentication, authorization, or billing. For example, when a student enters their account and password to log in to an online examination system, this request is identified as "authentication"; when a student clicks to enter a paid course learning page, the request is marked as "authorization" to verify whether they have the right to learn the course; after a student completes the course, the platform calculates the learning time and deducts fees, and the corresponding request is "billing". It is understood that, depending on the actual application scenario, the basic type can also include other types, and this application does not impose any restrictions.

[0026] Priority Tagging: Priority is determined based on user attributes or business tags carried in the request. For ongoing online exams, student authentication requests are marked as "high priority" because they are crucial for the exam to proceed normally; ordinary course learning authorization requests are marked as "medium priority"; and requests for students to submit supplementary assignments are marked as "low priority" because they have lower timeliness requirements.

[0027] Protocol version identification: The load balancer detects the RADIUS protocol version (e.g., v2 / v3) followed by the request. If it is the newer v3 version, the load balancer will prioritize servers that support the features of that version of the protocol to ensure that the request can be processed efficiently. For RADIUS v2 requests sent by older devices, the requests are redirected to a subset of servers that are compatible with the v2 protocol to avoid reduced efficiency of newer version servers due to compatibility issues.

[0028] Step S20: The load balancer forwards the task request to the target server.

[0029] In some embodiments, the load balancer encapsulates the original request data before forwarding the task request to ensure the integrity and accuracy of the data during transmission. For example, this may include: Add a forwarding identifier: Add a special forwarding identifier to the task request so that the target server can identify that the request was forwarded by the load balancer, distinguishing it from requests that come directly from the client. For example, add the field "LB-Forwarded: True" to the request header to facilitate subsequent processing by the target server.

[0030] Supplementing metadata: Key attribute information obtained during request parsing, such as the basic request type (authentication, authorization, or accounting), priority flags, and protocol version, is appended to the request as metadata. For example, for high-priority authentication requests for online exams, the load balancer will add metadata such as "Priority:High," "Request-Type:Authentication," and "Protocol-Version:RADIUS v3" to the request, enabling the target server to quickly understand the core characteristics of the request and process it accordingly.

[0031] Data verification processing: The encapsulated request data is verified by calculating the hash value of the data or using methods such as cyclic redundancy check (CRC) to generate a check code and append it to the end of the request. After receiving the request, the target server can use the check code to verify whether the data has been lost or tampered with during transmission, thus ensuring the validity of the request.

[0032] Preferably, the request allocation list is updated periodically, specifically: the load balancer periodically sends health check requests to one or more servers in the server cluster, the one or more servers respond to the health check requests and return their own status information, the load balancer determines whether the one or more servers are faulty based on the status information, and if so, removes the one or more servers from the request allocation list.

[0033] In some embodiments, exemplarily, the load balancer sends health check requests to some or all servers in the server cluster at preset time intervals. The interval setting can take into account the frequency of server performance fluctuations and system resource consumption. It is understood that an interval that is too short will increase network load, while an interval that is too long may cause faulty servers to process requests for extended periods, affecting service quality. In practice, the load balancer can use round-robin or random methods to select target servers to send requests to. For example, in a cluster containing 20 servers, the load balancer initially randomly selects 5 servers for checking, then selects another 5 for the next check, and so on, cyclically covering all servers to ensure that each server is checked periodically.

[0034] Upon receiving a health check request, the selected server will perform a comprehensive check of its own status and report the results back to the load balancer. The reported status information covers several key dimensions, including, for example: Hardware resource status: This includes CPU utilization, remaining memory, disk space usage, and network bandwidth usage. For example, if a server reports that its CPU utilization is 90% and its remaining memory is less than 10%, this indicates that the server may be facing a resource bottleneck and its ability to handle new tasks is limited.

[0035] Software service status: This primarily checks whether the RADIUS service process is running normally and whether related dependent components have crashed. If the RADIUS service process responsible for handling authentication requests on the server terminates unexpectedly, the server will clearly indicate this exception in the feedback information.

[0036] Network connectivity status: By using the ping command or specific network probing protocols, the network connectivity between the server and the load balancer, other servers, and indicators such as network latency and packet loss rate can be detected.

[0037] After receiving the status information from the server, the load balancer will analyze it according to preset fault diagnosis rules, such as: Resource threshold assessment: Certain threshold standards are set for hardware resource status. For example, if CPU utilization exceeds 85% for two consecutive checks, or memory availability falls below 5%, the server is considered to have a resource failure. During peak exam periods on online education platforms, if a server experiences sustained high CPU load due to a large number of students simultaneously logging in and authenticating, this assessment will be triggered.

[0038] Service anomaly assessment: If the RADIUS service process is detected to be malfunctioning, or if a critical software component displays an error code, the server is directly identified as experiencing a service failure, regardless of whether other indicators are normal. For example, if the billing service program on the server crashes and cannot process billing requests for student course purchases, the server will be marked as faulty.

[0039] Network problem assessment: When network latency exceeds the normal range (e.g., exceeding 500ms) or packet loss rate exceeds a certain threshold (e.g., 15%), the server is considered to be experiencing a network failure. If a server experiences frequent request transmission interruptions due to unstable link between itself and the load balancer caused by network equipment failure, it will be identified as a server with a network failure.

[0040] Upon confirming a fault, the load balancer removes the server from the request allocation list. Subsequent task requests will no longer be assigned to this server. Simultaneously, the load balancer sends a fault alert to the operations team, detailing the faulty server's ID, fault type, and status information to facilitate rapid problem identification and repair. After the server is repaired, operations personnel manually or through an automated process add it back to the request allocation list, allowing it to participate in task allocation again. Furthermore, the load balancer performs additional health checks on servers re-added to the list to ensure they are fully recovered before assigning tasks.

[0041] Preferably, the load balancer monitors the server cluster status in real time, including at least server resource utilization monitoring, server response time monitoring, and server health status assessment.

[0042] For example, load balancers monitor the network in real time and dynamically obtain the status of the server cluster through methods such as heartbeat detection and performance metric capture. Resource utilization monitoring: Real-time collection of server resource usage such as CPU, memory, disk I / O, and network bandwidth. If a server's CPU utilization is found to exceed 80% for 30 consecutive seconds, it is immediately marked as "high load".

[0043] Response Time Tracking: Set a response timer for each request to track the average response time of the server in processing various types of requests. If the average response time of a server in processing authentication requests suddenly increases from 20ms to 50ms, a policy adjustment alert will be triggered.

[0044] Health status assessment: A combination of periodic health checks and real-time anomaly detection is used. If a server fails three consecutive health checks, or if an anomaly such as a service process crash or network interruption occurs, it is immediately removed from the request allocation list, and the operations and maintenance personnel are notified.

[0045] Preferably, in some embodiments, the load balancer constructs a dynamic load balancing strategy decision tree based on real-time data of task request attributes and server status.

[0046] The root node of the decision tree is the "request attribute". First-level branches extend from the root node, classifying requests according to their basic type (authentication, authorization, accounting), priority (high, medium, low), and protocol version. For example, when a request is received, the decision tree first determines that it is an authentication request, and then enters the "authentication request" branch; if the authentication request is of high priority, it further enters the "high priority authentication request" sub-branch.

[0047] Based on the first-level branch, the second-level branch, combined with server status information, determines the specific load balancing strategy: High-priority authentication request branch: If there are servers in the high-performance server cluster with fewer than 1000 connections and an average response time of less than 30ms, a "minimum number of connections + response time weighting" strategy will be adopted to distribute requests to the server that meets the criteria and has the fewest connections. This will ensure that students can quickly pass the certification and enter the examination system, avoiding the impact of long waiting times on the exam.

[0048] If high-performance servers are all under high load (connection count > 1500 or CPU utilization > 90%), requests will be routed to the fastest-responding node in the low-performance virtual machine cluster to ensure timely processing of exam certification requests.

[0049] Medium-priority course learning authorization request branch: When the overall server load is less than 60%, a "round-robin strategy" is adopted to distribute requests to the servers in the request allocation list in sequence, thereby balancing the load of each server, making full use of server resources, and allowing students to access course content smoothly.

[0050] If the average response time of a server in processing course learning authorization requests is detected to be too long (e.g., exceeding 50ms), the "minimum response time strategy" will be switched to prioritize the server with the fastest current response time to improve the students' course learning experience.

[0051] Low-priority billing request branch: When the overall server load is less than 60%, a "weighted round-robin (storage IO weight)" strategy is implemented for billing requests. The weight is allocated according to the storage IO capacity of the server, and the request is preferentially allocated to the server with good storage performance and low load, so as to ensure the stable operation of billing operations such as course learning time statistics and fee settlement.

[0052] If the storage server load is greater than 80%, the "dynamic splitting + connection balancing" strategy will be enabled to split large file billing tasks (such as batch student course fee settlement data) into smaller chunks and distribute them to servers with the fewest connections and moderate storage performance for parallel processing, thereby speeding up the processing of billing tasks.

[0053] Preferably, in some embodiments, the load balancer continuously updates the decision tree as requests continue to flow in and server status changes in real time: Upon receiving new request attributes or server status changes, the decision tree reassesses the appropriateness of the current branching strategy. For example, during an exam, if a high-performance server experiences a sudden increase in load due to a large number of authentication requests, the decision tree will immediately adjust the distribution strategy for subsequent authentication requests, diverting them to other servers with lower loads.

[0054] The effectiveness of the current strategy is evaluated by monitoring metrics such as request processing success rate, average response time, and server load balancing. If a strategy is found to cause a decrease in the success rate of billing request processing, the decision tree will backtrack and adjust the relevant branch strategies, such as optimizing the task chunk size or server selection rules of the "dynamic splitting + connection balancing" strategy, continuously optimizing the decision tree structure and strategies to improve the overall system performance.

[0055] By constructing a dynamic policy decision tree, the load balancer can flexibly and intelligently select the optimal load balancing strategy in online education scenarios based on real-time data of request attributes and server status, effectively improving the system's response speed, stability, and resource utilization.

[0056] Figure 2A server load balancing device 200 is shown. This device embodiment is similar to... Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0057] like Figure 2 As shown, the server load balancing device 200 provided in this application embodiment includes: The selection module 201 is used to select a target server in response to receiving a task request. Specifically, the load balancer selects an available target server from the request allocation list based on a preset load balancing strategy. Request forwarding module 202 is used by the load balancer to forward the task request to the target server; The update module 203 is used for the load balancer to periodically send health check requests to one or more servers in the server cluster. The one or more servers respond to the health check requests and return their own status information. The load balancer determines whether the one or more servers are faulty based on the status information. If so, the load balancer removes the one or more servers from the request allocation list.

[0058] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0059] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0060] Figure 3The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 300 includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on a program stored in a Read Only Memory (ROM) 302 or a program loaded from a storage portion 308 into a Random Access Memory (RAM) 303. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0061] The following components are connected to I / O interface 305: an input section 306 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; a storage section 308 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 309 performs communication processing via a network such as the Internet.

[0062] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 301, it performs the functions defined in the methods of this application.

[0063] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0064] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0065] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0066] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0067] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0069] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0070] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or page components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0071] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0072] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0073] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0075] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A method of server load balancing, characterized by, The method comprises the following steps: In response to receiving a task request, the load balancer selects a target server, specifically, the load balancer selects an available target server from a request distribution list based on a preset load balancing strategy; The load balancer forwards the task request to the target server; The request distribution list is periodically updated, specifically, the load balancer periodically sends a health check request to one or more servers in the server cluster, the one or more servers respond to the health check request and return their state information, and the load balancer determines whether the one or more servers have failed based on the state information, and if so, removes the one or more servers from the request distribution list.

2. The server load balancing method of claim 1, wherein: The load balancing strategy is set based on task request attributes and / or server cluster state, and the task request attributes include at least one of request basis type, request priority, or request protocol version.

3. The server load balancing method of claim 2, wherein: Before the load balancer selects a target server, the load balancer also includes parsing the request task, including basis type identification: the basis type includes authentication, authorization, or charging, priority marking: determining the request priority based on user attributes and / or service labels carried by the request task, and protocol version identification: identifying the RADIUS protocol version followed by the request task.

4. The method of claim 3, wherein, Further comprising: The load balancer monitors the server cluster state in real time, and the server cluster state includes at least server resource utilization monitoring, server response time monitoring, and server health state evaluation.

5. The method of claim 2, wherein the server load balancing is performed by a network device. Further comprising: The load balancing strategy is specifically that the load balancer constructs a dynamic load balancing strategy decision tree based on task request attributes and server state; Wherein the root node of the decision tree is the request attribute, the first branch and the second branch are based on the classification of the basis type, priority, or protocol version, and the second branch determines the specific strategy based on the first branch and the server state.

6. The method of claim 5, wherein, Further comprising: The specific strategy includes, based on the authentication type, priority, and server state, using one or more combinations of the minimum connection number, response time weighted strategy, round robin strategy, minimum response time strategy, weighted round robin strategy, dynamic splitting, or connection number balancing.

7. A server load balancing apparatus, characterized by, It comprises: A selection module for selecting a target server by the load balancer in response to receiving a task request, specifically, the load balancer selects an available target server from a request distribution list based on a preset load balancing strategy; A request forwarding module for forwarding the task request to the target server by the load balancer; An updating module is configured to periodically send a health check request to one or more servers in the server cluster, the one or more servers respond to the health check request and return self status information, and the load balancer determines whether the one or more servers are faulty based on the status information, and if so, removes the one or more servers from the request distribution list. 8.An electronic device, comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-4. 9.A computer readable medium having stored thereon computer program instructions executable by a processor to implement the method of any one of claims 1-4. 10.A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1-4.

Images