A load balancing method, device, apparatus and storage medium

Abstract

Embodiments of the present application disclose a load balancing method, device, equipment and storage medium. The technical scheme provided by the embodiments of the present application comprises: sending first load information to a request service end in the same cluster and receiving second load information sent by the request service end in the cluster; determining the load status of each request service end in the cluster according to the first load information and the second load information; determining the priority data of each request service end according to the load status of each request service end, and sending the priority data to the request sending end, so that the request sending end selects a request service end for processing the request from the cluster according to the priority data. Through the above technical scheme, the overload problem of the load balancer caused by a large amount of access traffic through the load balancer in the prior art is solved, and the load balancing effect is optimized.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, and particularly relate to a load balancing method, device, equipment and storage medium. BACKGROUND

[0002] For a service processing system with large traffic, if all requests of the service processing system are processed by a single server, the server load pressure will be too large. In order to alleviate the machine load pressure, a load balancing technology is proposed, which aims to avoid machine overload by distributing the load to the servers in the computer cluster.

[0003] Most of the existing load balancing technologies increase a load balancer in front of the front-end and back-end cluster servers, and the load balancer forwards the requests sent by the front-end to each server in the cluster for processing. However, all the requests received by the front-end need to pass through the load balancer, and when the request traffic is too large, the processing load of the load balancer is exceeded, the load balancer is overloaded, and even a single point failure occurs, which affects the business processing efficiency of the service processing system. SUMMARY

[0004] Embodiments of the present application provide a load balancing method, device, equipment and storage medium, to solve the problem that the load balancer is overloaded when a large amount of request data passes through the load balancer in the prior art, optimize the load balancing effect, avoid single point failure problem in the load balancing process, and improve the stability and processing efficiency of the service processing system.

[0005] In a first aspect, embodiments of the present application provide a load balancing method, comprising:

[0006] sending first load information to a request service end in the same cluster and receiving second load information sent by the request service end in the cluster;

[0007] determining the load status of each request service end in the cluster according to the first load information and the second load information;

[0008] determining the priority data of each request service end according to the load status of each request service end, and sending the priority data to a request sending end, so that the request sending end selects a request service end for processing requests from the cluster according to the priority data.

[0009] In a second aspect, embodiments of the present application provide a load balancing device, comprising

[0010] a load information transmission module configured to send first load information to a request service end in the same cluster and receive second load information sent by the request service end in the cluster;

[0011] a load status determination module configured to determine a load status of each request service end in the cluster according to the first load information and the second load information;

[0012] a priority determination module configured to determine a priority data of each request service end according to the load status of each request service end, and send the priority data to a request sending end, so that the request sending end selects a request service end to process a request from the cluster according to the priority data.

[0013] In a third aspect, an embodiment of the present application provides a load balancing device, comprising: a memory and one or more processors;

[0014] the memory is configured to store one or more programs;

[0015] When the one or more programs are executed by the one or more processors, the one or more processors implement the load balancing method according to the first aspect.

[0016] In a fourth aspect, an embodiment of the present application provides a storage medium containing computer executable instructions, which are used to execute the load balancing method according to the first aspect when executed by a computer processor.

[0017] In the embodiments of the present application, each request service end in the cluster acquires load information of other request service ends in the same cluster, so that any request service end in the cluster can determine load pressure of all request service ends in the cluster. The request sending end sends a request to any request service end in the cluster, the request service end determines priorities of all request service ends in the cluster according to the load pressure of all request service ends, and sends the priority data of the request service end to the request sending end, so that the request sending end sends the request to the request service end with smaller load pressure according to the priority data, and balances the load of the request service ends in the cluster. Through the above technical means, the load balancing effect is achieved through the cooperation of all request service ends in the cluster, without deploying a physical load balancer, and the system architecture is simplified. The overload problem of the load balancer caused by high-concurrency request data passing through the load balancer is solved, the load balancing effect is optimized, the single-point failure problem of the system is avoided, and the system stability and processing efficiency are improved. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 is a flowchart of a load balancing method provided by an embodiment of the present application;

[0019] Figure 2 is a schematic diagram of a load information propagation path provided by an embodiment of the present application;

[0020] Figure 3is a schematic diagram of information interaction between a request sending end and a request service end provided by an embodiment of the present application;

[0021] Figure 4 is a flowchart of another load balancing method provided by an embodiment of the present application;

[0022] Figure 5 is a schematic diagram of a detection message propagation path provided by an embodiment of the present application;

[0023] Figure 6 is a schematic diagram of a reply message propagation path provided by an embodiment of the present application;

[0024] Figure 7 is a schematic diagram of a message propagation path provided by an embodiment of the present application;

[0025] Figure 8 is a structural schematic diagram of a load balancing device provided by an embodiment of the present application;

[0026] Figure 9 is a structural schematic diagram of a load balancing device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to make the objects, technical solutions and advantages of the present application clearer, the following further describes specific embodiments of the present application with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present application and not to limit the present application. In addition, it should be noted that, for the convenience of description, only parts related to the present application are shown in the drawings and not all contents. Before discussing the example embodiments in more detail, it should be mentioned that some example embodiments are described as processes or methods depicted by flowcharts. Although the flowcharts describe each operation (or step) as a sequential process, many of the operations can be implemented in parallel, concurrently or simultaneously. In addition, the order of the operations can be rearranged. The process can be terminated when the operations are completed, but can also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0028] Figure 1 A flowchart of a load balancing method provided by an embodiment of the present application is given. The load balancing method provided by the embodiment of the present application can be executed by a load balancing device, which can be realized by hardware and / or software and integrated in a load balancing equipment.

[0029] The following describes the load balancing method executed by the load balancing device as an example. As shown in Figure 1 the load balancing method includes:

[0030] S110, sending first load information to a request service end in the same cluster and receiving second load information sent by a request service end in the receiving cluster.

[0031] The request service end refers to a service end processing a request, including a backend server and a proxy server, etc. The cluster refers to that a plurality of request service ends in a business processing system are concentrated together to process a request, i.e., each request service end in the cluster can process a request. For example, when high-concurrency request data appears in the business processing system, only one request service end cannot process the high-concurrency request data in time, and therefore the cluster is set to process the high-concurrency request. However, the request service end of the traditional business processing system only has the function of processing a request, and cannot distribute request data. The request sending end sending a request cannot know the load condition of the request service end, and can only randomly distribute the request data when distributing the request data, and cannot balance the load of the request service end. Therefore, the traditional business processing system sets up a physical load balancer between the request sending end and the request service end, and the load balancer is used to uniformly distribute the request data sent by the request sending end to the request service end in the cluster, so as to balance the load of the request service end. The load balancer generally uses LVS (Linux Virtual Server) or HAProxy, but no matter whether LVS or HAProxy is used as the load balancer, the request data needs to pass through the load balancer and then be forwarded to the request service end. This causes that when high-concurrency request data appears, the processing load of the load balancer is exceeded, the load balancer is overloaded, even a single point failure occurs, and the business processing efficiency of the business processing system is affected. To this end, the embodiment proposes that each request service end can propagate its own load condition in the cluster, so that each request service end can know its own load condition and the load conditions of other request service ends in the cluster. The request sending end is informed of the load conditions of all request service ends in the cluster, so that the request sending end preferentially sends a request to a request service end with less load pressure, and balances the load of the request service end in the cluster.

[0032] It should be noted that each request service end is a load balancing device, or each request service end includes a load balancing device. The load balancing method provided by the embodiment is run on each request service end in the cluster, i.e., each request service end runs the corresponding load balancing method through the corresponding load balancing device. When each request service end runs the corresponding load balancing method, the load information is propagated between the request service ends, and the request sending end is informed of the load conditions of all request service ends in the cluster.

[0033] For example, when a request server executes a load balancing method, it sends first load information to other request servers in the cluster and receives second load information from other request servers in the cluster. The first load information refers to the load information of the request server itself, and the second load information refers to the load information of other request servers in the cluster. Load information can be understood as information characterizing the load status of a request server, including the number of requests processed by the request server and the machine's operating load. After each request server receives the load information from all other request servers in the cluster, it can combine this with its own load information to obtain the load information of all request servers in the cluster.

[0034] In this embodiment, each requesting server propagates its own load information to other requesting servers in the cluster based on the Gossip protocol, and also receives load information propagated by other requesting servers based on the Gossip protocol, in order to collect the load information of all requesting servers in the cluster. The Gossip protocol can propagate messages to the entire cluster in a random manner, ensuring data consistency across all nodes within the cluster within a certain time. The nodes in the Gossip protocol are the requesting servers in this embodiment, and the messages propagated in the Gossip protocol are the load information in this embodiment. The message propagation process based on the Gossip protocol is as follows: any node in the cluster randomly selects several surrounding nodes to spread the message; the nodes receiving the message also randomly select several surrounding nodes to spread the message. However, the nodes selected by the receiving node to spread the message do not include the node that sent the message to it; that is, the propagation process is forward propagation. After a period of time, all nodes in the cluster have received the message, achieving node message synchronization.

[0035] For example, Figure 2 This is a schematic diagram of the load information propagation path provided in an embodiment of this application. For example... Figure 2 As shown, request server N1 randomly sends requests to several other request servers in the cluster via the Gossip protocol. Figure 2 In the middle, requesting servers N2 and N3 propagate their own N1 load information, and then the requesting servers N2 and N3 that receive the N1 load information randomly send it to several requesting servers in the cluster. Figure 2 The process involves requesting servers N4 and N5 sending N1 load information until the N1 load information is propagated to all requesting servers in the cluster. This is understandable. Figure 2The propagation process shown in FIG. 1 is that the request server N1 propagates its own N1 load information. Each request server in the cluster propagates its own load information based on the Gossip protocol. For example, the request server N2 also propagates its own load information in the same way as the request server N1, so that other request servers in the cluster can obtain the N2 load information of the request server N2. After all request servers in the cluster propagate their own load information based on the Gossip protocol, each request server collects the load information of all request servers in the cluster. In this embodiment, the load information is propagated by the Gossip protocol, so that each request server can receive the load information propagated by other request servers, thereby avoiding the situation that the load information of a request server cannot be collected due to the disconnection of the direct network between the request servers, and ensuring the reliability of the propagation of the load information.

[0036] Further, since the load condition of the request server changes in real time, in order to ensure that the request server can update the load information of other request servers in the cluster in real time, each request server propagates the load information by the Gossip protocol at a frequency of once per first preset time, thereby ensuring the real-time performance of the load information and avoiding the load imbalance caused by the delay of the load information. In this embodiment, the first preset time is 2 seconds.

[0037] S120, determining the load condition of each request server in the cluster according to the first load information and the second load information.

[0038] For example, each request server can obtain the load information of all request servers in the cluster, associate and save the address information of all request servers with the corresponding load information in a load list, and determine the load condition of each request server through the load list. The address information is the IP address of the request server, which can be used to represent the identity of the request server. When the request server propagates its own load information, the address information of the request server is marked in the load information, so as to inform the request server receiving the load information that the load information is the load information of the request server corresponding to the address information. Further, when determining the load condition of a request server, the address information of the request server in the load list is queried, so as to obtain the load information of the request server, and determine the load condition of the request server according to the load information.

[0039] The load condition can be understood as the load pressure of the request server. For example, the product of the number of requests and the machine running load in the load information of the request server is multiplied to represent the load pressure of the corresponding request server. It can be understood that the number of requests and the machine running load handled by the request server are directly proportional to the load pressure, so the greater the product of the number of requests and the machine running load, the greater the load pressure of the request server.

[0040] S130, priority data of each request service end is determined according to the load status of each request service end, and the priority data is sent to the request sending end, so that the request sending end selects a request service end for processing the request from the cluster according to the priority data.

[0041] Exemplarily, the load pressures of all request service ends in the cluster are compared, and the priorities of the request service ends are determined in the order from small to large according to the load pressures. The request service end with a larger load pressure has a lower priority. The request sending end selects the request service end with the highest priority according to the priorities of all request service ends in the cluster at the current time for connection, and if the connection fails, the request sending end selects the request service end with the second highest priority for connection, until the request sending end is successfully connected with the request service end, and then the request is sent to the request service end for processing. In this embodiment, the priority of the request service end is determined by the load pressure, so that the request sending end preferentially selects the request service end with the smallest load pressure for processing the request, so as to balance the loads of the request service ends in the cluster.

[0042] In this embodiment, since the load status of the request service end changes in real time, the priority of the request service end also changes in real time. Therefore, in this embodiment, after the request service end receives the request information sent by the request sending end, the load status of each request service end is calculated according to the load list at the current time, and then the priority of the request service end is determined. Figure 3 Figure 3 is a schematic diagram of information interaction between the request sending end and the request service end provided by the embodiment of the application. As shown in Figure 3 , the request sending end sends a request to the DNS for obtaining the address information of the request sending end, and the DNS returns the IP address of any request service end Ni in the cluster pre-configured to the request sending end. The request sending end sends a request to the corresponding request service end Ni for obtaining the priority data of the request service end according to the IP address, the request service end Ni receives the request, calculates the priority of each request service end according to the load list at the current time, and returns the priority data to the request sending end. The priority data includes the IP address and the corresponding priority of each request service end. The request sending end selects the request service end Nj with the highest priority for connection, and sends a business request to the request service end Nj after the connection is successful, and the request service end Nj returns the request processing result to the request sending end after processing the business request. It should be noted that Ni and Nj can be the same request service end.

[0043] In one embodiment, a plurality of request sending ends are provided in the business processing system, each of the request sending ends corresponds to an IP address, and some of the request sending ends and some of the request serving ends are in the same IP area. The request sending end sends a request information for obtaining the priority data of the request serving end to the request serving end Ni, and the request information includes the IP address of the request sending end. The request serving end Ni determines the request serving ends in the same area with the request sending end according to the IP address of the request sending end, and determines the priority of the request serving ends in the same area with the request sending end. For example, the score calculation formula of the request serving end is as follows:

[0044]

[0045] Wherein, x and y are the request quantity and the machine running load respectively, k is the same area weight coefficient, generally k = 100, and g is the score of the request serving end. Further, the priority of each request serving end is determined according to the score of the request serving end from small to large, wherein the higher the score of the request serving end is, the lower the priority is. In this embodiment, the priority of the request serving end in the same area with the request sending end is improved by the same area weight system, the load pressure of the request serving end in the same area is basically consistent, the load of the request serving end in the same area is balanced, and the load balancing effect is optimized.

[0046] Moreover, each request serving end in the cluster includes a load list, that is, each request serving end can process the priority data obtaining request sent by the request sending end, the access quality of the request sending end is ensured, the single point failure problem caused by high concurrency request is avoided, and the system stability is improved.

[0047] On the basis of the above embodiment, Figure 4 is a flowchart of another load balancing method provided by the embodiment of the application. As shown in Figure 4 , the load balancing method comprises the following steps.

[0048] S210, performing health check on the request serving ends in the same cluster, and determining the online request serving ends in the cluster according to the check result.

[0049] For example, the request serving end in the cluster will be down due to various factors, if the request is always sent to the request serving end which is down, the real-time performance of the request processing will be affected, the request processing efficiency will be reduced, and even the load imbalance of the whole system will be caused. Moreover, the running resources of the request serving end are wasted by propagating the load information to the request serving end which is down. Therefore, in order to save the running resources and ensure the load balancing of the serving end, the health check needs to be performed on the request serving ends in the cluster, so as to filter out the request serving end which is down and keep the online request serving end.

[0050] In this embodiment, the step of performing a health check on the requesting server in the same cluster specifically includes S2201-S2203:

[0051] S2201. Based on a preset protocol, a probe message is sent to each requesting server in the cluster at a second preset time interval, and the corresponding reply message sent by the requesting server is received.

[0052] In this embodiment, the Gossip protocol is used to propagate health probe messages. For example, each requesting server in the cluster randomly sends probe messages to surrounding requesting servers based on the Gossip protocol. These probe messages are ping messages, used for network diagnostics. After receiving a probe message, each requesting server randomly sends it to surrounding requesting servers until every requesting server in the cluster has received it. The requesting server that receives the probe message also generates a corresponding reply message and propagates it back to the requesting server that initially sent the probe message based on the Gossip protocol. It is understood that if a requesting server in the cluster crashes, it will not receive the probe message and will also be unable to send a reply message.

[0053] In this embodiment, Figure 5 This is a schematic diagram of the probe message propagation path provided in an embodiment of this application. For example... Figure 5 As shown, request server N6 randomly sends requests to several request servers in the cluster. Figure 5 The request servers N7 and N8 in the cluster send an N6 probe message, and then the request servers N7 and N8 that receive the N6 probe message randomly send it to several request servers in the cluster. Figure 5 The requesting servers N9 and N10 send N6 probe messages until the N6 probe messages are propagated to all requesting servers in the cluster. Furthermore, requesting servers N7, N8, N9, and N10 that receive the N6 probe messages generate corresponding N6 reply messages based on the N6 probe messages. Figure 6 This is a schematic diagram of the reply message propagation path provided in an embodiment of this application. For example... Figure 6 As shown, the request server N9 randomly sends requests to several request servers in the cluster. Figure 6 The requesting servers N7 and N10 send the N6 reply message, and then the requesting servers N7 and N10 that receive the N6 reply message randomly send it to several requesting servers in the cluster. Figure 6The request service end N6 sends an N6 reply message until the N6 reply message propagates to all request service ends in the cluster. The request service end N6 receives the N6 reply message returned by the request service end N9 to the N6 probe message, and determines that the request service end N9 does not have a crash. It should be noted that the reply message includes the IP address of the request service end corresponding to the generation of the reply message, and the corresponding request service end is determined to not have a crash according to the IP address in the reply message.

[0054] Further, since the status of the request service end is real-time change, in order to ensure that the request service end can check the health status of other request service ends in the cluster in real time, each request service end will propagate the probe message through the Gossip protocol at a frequency of once per second, to ensure the real-time of health check, and avoid the delay of fault diagnosis to cause the request processing not timely or even load imbalance. In this embodiment, the second preset time is set to 1 second.

[0055] S2202, according to all received reply messages, determine the request service end in the cluster that has a crash.

[0056] Exemplarily, Figure 7 is a schematic diagram of the message propagation path provided by the embodiment of the application. As shown in Figure 7 , the request service end sends a probe message and receives a reply message. The simplified propagation path in Figure 7 is shown in the figure, for example, the request service end N6 sends a probe message to the request service end N7, and receives the reply message returned by the request service end N7. Exemplarily, the request service end N6 receives the reply messages sent by the request service ends N7, N8 and N10, and determines that the request service end N9 does not send a reply message, at this time, the request service end N9 may have a crash or the request service end N9 does not receive the probe message.

[0057] In this embodiment, the step of determining whether the request service end that does not send a reply message has a crash specifically includes S22021-S22024:

[0058] S22021, according to all received reply messages, determine a third request service end that sends a reply message and a fourth request service end that does not send a reply message.

[0059] Exemplarily, referring to Figure 7 , the request service ends N7, N8 and N10 are the third request service ends that send a reply, and the request service end N9 is the fourth request service end that does not send a reply message.

[0060] S22022, randomly send an assistance probe message to the third request service end, so that the third request service end sends a probe message to the fourth request service end.

[0061] For example, the request server N6 randomly sends the assistance probe message to the request servers N7, N8 and N10, so that the request servers N7, N8 and / or N10 receiving the assistance probe message propagate the probe message to the request server N9 based on the Gossip protocol.

[0062] S22023, receiving the assistance reply message sent by the third request server, and determining whether the third request server receives the reply message sent by the fourth request server according to the assistance reply message.

[0063] For example, if the request server N9 does not fail, the request server N9 receives the probe message sent by the request servers N7, N8 and / or N10, and sends the corresponding reply message to the request servers N7, N8 and / or N10. If the request server N9 fails, the request server N9 cannot receive the probe message sent by the request servers N7, N8 and / or N10, and cannot send the reply message to the request servers N7, N8 and / or N10.

[0064] Further, the request servers N7, N8 and / or N10 send the assistance reply message to the request server N6, and the assistance reply message contains the assistance result of whether the request servers N7, N8 and / or N10 receive the reply message sent by the request server N9.

[0065] S22024, when it is determined that the third request server does not receive the reply message sent by the fourth request server, it is determined that the fourth request server fails.

[0066] For example, when the request server N6 determines that the request servers N7, N8 and / or N10 do not receive the reply message sent by the request server N9 according to the assistance result, it is determined that the request server N9 fails. Or, when the request server N6 determines that the request servers N7, N8 and / or N10 receive the reply message sent by the request server N9 according to the assistance result, it is determined that the request server N9 does not fail.

[0067] S2203, generating the online server list of the cluster according to all the request servers in the cluster and the request server that fails.

[0068] For example, after determining the request server that fails in the cluster, the IP addresses of the remaining request servers in the cluster that do not fail are collected to obtain the online server list of the cluster.

[0069] It should be noted that each request server that can normally operate will perform health check on other request servers in the cluster, so each request server that can normally operate can generate an online server list.

[0070] S220, sending first load information to an online request service end in the same cluster and receiving second load information sent by an online request service end in the cluster.

[0071] For example, each online request service end propagates its own load information to other online request service ends in the cluster based on the Gossip protocol and receives load information propagated by other request service ends based on the Gossip protocol to collect load information of all online request service ends in the cluster. In this embodiment, the step of collecting load information by the online request service end specifically includes S2201-S2203:

[0072] S2201, determining an online request service end in the cluster according to an online service end list of the cluster.

[0073] For example, the online request service end at the current time is determined according to the online service end list at the current time, so as to collect load information of the corresponding online request service end.

[0074] S2202, sending first load information to a first request service end at a first preset time interval based on a preset protocol, so that the first request service end sends the first load information to a second request service end, and the first request service end and the second request service end are both online request service ends.

[0075] For example, referring to Figure 2 When the online request service end N1 propagates N1 load information, the online request service end N1 sends the N1 load information to the online request service end N2 and the online request service end N3, and the online request service end N2 and the online request service end N3 are the first request service end. The first request service end can be understood as other online request service ends randomly selected by the online request service end based on the Gossip protocol when propagating its own load information. Further, after the online request service end N2 and the online request service end N3 receive the N1 load information, the online request service end N2 and the online request service end N3 randomly propagate the N1 load information to online request service ends other than the online request service end N1 based on the Gossip protocol, so that the N1 load information spreads to other online request service ends in the cluster. That is, the second request service end refers to other online request service ends other than the self request service end.

[0076] S2203, sequentially receiving second load information sent by each online request service end in the cluster.

[0077] Exemplarily, the online request server N1 receives the N2, N3, N4 and N5 load information propagated by the online request servers N2, N3, N4 and N5 in the cluster when the online request server N1 propagates its own N1 load information to other online request servers in the cluster.

[0078] S230, determining the load status of each online request server in the cluster according to the first load information and the second load information.

[0079] Exemplarily, after collecting the load information of all online request servers in the cluster, the load information of all online request servers is aggregated to obtain a load list, so as to determine the load status of each online request server through the load list. In this embodiment, the step of generating the load list specifically comprises S2301-S2302:

[0080] S2301, determining the request server that initially sends the load information according to the first load information and the second load information.

[0081] Exemplarily, the online request server that initially sends the load information can be understood as the load information being the load information of the online request server itself. As known from the above content, the online request server marks its own address information in the load information when propagating its own load information. The online request server that initially sends the load information can be determined according to the address information in the load information.

[0082] S2302, storing each load information in association with the address information of the corresponding request server to obtain a load list, the load list comprising the load information corresponding to all request servers in the cluster.

[0083] Exemplarily, the address information can be regarded as the identity of the corresponding online request server, so as to represent the online request server. The load information is stored in association with the corresponding address information in the load list, so that the load status of the online request server corresponding to the address information can be determined when the address information in the load list is queried.

[0084] S240, determining the priority data of each online request server according to the load status of each online request server, and sending the priority data to the request sending end, so that the request sending end selects the online request server for processing the request from the cluster according to the priority data.

[0085] In this embodiment, the step of determining the priority data of each online request server specifically comprises S2401-S2402:

[0086] S2401, after receiving the request information sent by the request sending end, the load information of the online request service end in the cluster is obtained from the load list according to the online service end list of the cluster.

[0087] Exemplarily, after receiving the request information sent by the request sending end for obtaining the priority data of all online request service ends in the cluster, the online request service end learns that the request sending end wants to send the service request to the online request service end with smaller load pressure in the cluster, and obtains the load information of each online request service end from the load list.

[0088] S2402, the priority data of the corresponding online request service end is determined according to the load information and the request information.

[0089] Exemplarily, the number of requests and the machine running load in the load information are multiplied to determine the load pressure of the corresponding online request service end. In this embodiment, the address information of the request sending end is included in the request information, the address information corresponding to the request is obtained from the request information, and the priority data of the request service end is determined according to the address information and the address information of the online request service end. Specifically, the score of each online request service end is calculated according to the score calculation formula, the scores of the online request service ends are sorted, the priority of each online request service end is determined, and the priority and IP address of each online service end are packaged to generate the priority data.

[0090] Further, the priority data of each online request service end is sent to the request sending end, so that the request sending end selects the online request service end with the highest priority to connect, and selects the online request service end with the second highest priority to connect when the connection fails, until the connection with the online request service end is successful. Exemplarily, the priority data is sent to the request sending end, so that the request sending end preferentially selects the online request service end with smaller load pressure or in the same large area to process the service request according to the priority order, ensures that the loads of the online request service ends in the same large area are basically consistent, and optimizes the load balancing effect.

[0091] In summary, the load balancing method provided by the embodiment of the application realizes the load balancing effect through the cooperation of all request service ends in the cluster, does not need to deploy a physical load balancer, and simplifies the system architecture. The overload problem of the load balancer caused by high-concurrency request data passing through the load balancer is solved, the load balancing effect is optimized, the single-point failure problem of the system is avoided, and the system stability and processing efficiency are improved. The detection message is propagated through the Gossip protocol to perform health check on the request service ends in the cluster to filter out the request service ends that have occurred downtime, so as to avoid the interference of the request service ends with downtime to the load balancing process and optimize the load balancing effect.

[0092] On the basis of the above embodiment,Figure 8 is a structural schematic diagram of a load balancing device provided by an embodiment of the present application. As shown in Figure 8 the load balancing device includes a load information transmission module 31, a load condition determination module 32, and a priority determination module 33.

[0093] The load information transmission module is configured to send first load information to a request service end in the same cluster and receive second load information sent by a request service end in the receiving cluster.

[0094] The load condition determination module is configured to determine the load condition of each request service end in the cluster according to the first load information and the second load information.

[0095] The priority determination module is configured to determine the priority data of each request service end according to the load condition of each request service end, and send the priority to the request sending end, so that the request sending end selects a request service end to process the request from the cluster according to the priority data.

[0096] In summary, the load balancing device provided by the embodiment of the present application realizes the load balancing effect through the cooperative work of all request service ends in the cluster, does not need to deploy a physical load balancer, and simplifies the system architecture. The problem of overload of the load balancer caused by high-concurrency request data passing through the load balancer is solved, the load balancing effect is optimized, the problem of single-point failure of the system is avoided, and the system stability and processing efficiency are improved.

[0097] An embodiment of the present application further provides a load balancing device, which can integrate the load balancing device provided by the embodiment of the present application. Figure 9 is a structural schematic diagram of a load balancing device provided by an embodiment of the present application. Reference Figure 9 The load balancing device includes an input device 43, an output device 44, a memory 42, and one or more processors 41; the memory 42 is used to store one or more programs; when the one or more programs are executed by the one or more processors 41, the one or more processors 41 implement the load balancing method provided by the above-described embodiments. The load balancing device, device, and computer provided above can be used to execute the load balancing method provided by any of the above-described embodiments, and have the corresponding functions and beneficial effects.

[0098] The embodiment of the present application further provides a storage medium comprising computer executable instructions, which are used to execute the load balancing method provided by the above embodiment when executed by a computer processor. Of course, the storage medium provided by the embodiment of the present application is not limited to the load balancing method as described above, and can also execute the related operations in the load balancing method provided by any embodiment of the present application. The load balancing device, equipment and storage medium provided in the above embodiment can execute the load balancing method provided by any embodiment of the present application, and the technical details not described in the above embodiment can be referred to the load balancing method provided by any embodiment of the present application.

[0099] The above are only the preferred embodiments of the present application and the technical principles applied. The present application is not limited to the specific embodiments described herein, and various obvious changes, re-adjustments and substitutions made by those skilled in the art will not deviate from the protection scope of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and can also include more other equivalent embodiments without deviating from the concept of the present application, and the scope of the present application is determined by the scope of the claims.

Claims

1. A load balancing method, characterized in that, The load balancing method runs on each request server in the cluster, and the load balancing method includes: Based on the Gossip protocol, a probe message is sent to each requesting server in the cluster at a second preset time interval, and a reply message sent by the requesting server is received; based on all received reply messages, the requesting server that has crashed in the cluster is determined; based on all requesting servers in the cluster and the requesting server that has crashed, a list of online servers in the cluster is generated. Send first load information to the requesting servers in the online server list and receive second load information sent by the requesting servers in the cluster; The load status of each request server in the cluster is determined based on the first load information and the second load information, wherein the load status is the load pressure of the corresponding request server; After receiving the request information sent by the request sender, the system determines whether the request sender and the request server are in the same region based on the address information of the request sender in the request information. If they are in the same region, the system determines the score of the request server by multiplying the preset region weight coefficient by the load status. Otherwise, the system determines the score of the request server by the load status. The system sorts the request servers in ascending order of their scores to obtain priority data for each request server. The priority data is then sent to the request sender so that the request sender can select a request server from the cluster to process the request based on the priority data.

2. The load balancing method according to claim 1, characterized in that, The step of determining the request server that has crashed in the cluster based on all received reply messages includes: Based on all received reply messages, identify the third requesting server that sent the reply message and the fourth requesting server that did not send a reply message; A random assist probe message is sent to the third requesting server, so that the third requesting server sends the probe message to the fourth requesting server; Receive the assistance reply message sent by the third requesting server, and determine whether the third requesting server has received the corresponding reply message sent by the fourth requesting server based on the assistance reply message; If the third requesting server does not receive a reply message from the corresponding fourth requesting server, the fourth requesting server is determined to be down.

3. The load balancing method according to claim 1, characterized in that, The step of sending the first load information to the requesting servers in the online server list and receiving the second load information sent by the requesting servers in the cluster includes: Based on the list of online servers in the cluster, determine the online request servers in the cluster; Based on a preset protocol, first load information is randomly sent to the first requesting server at a first preset time interval, so that the first requesting server sends first load information to the second requesting server. Both the first requesting server and the second requesting server are online requesting servers. The system sequentially receives the second load information sent by each online request server in the cluster.

4. The load balancing method according to claim 1, characterized in that, Determining the load status of each request server in the cluster based on the first load information and the second load information includes: Based on the first load information and the second load information, the requesting server that initially sends the load information is determined. The load information includes the number of requests processed by the corresponding requesting server and the machine's operating load. Each load information is associated with and stored with the address information of the corresponding requesting server to obtain a load list, which includes the load information of all requesting servers in the cluster.

5. The load balancing method according to claim 1, characterized in that, The step of sending the priority data to the request sender, so that the request sender selects a request server from the cluster to process the request based on the priority data, includes: The priority data of each online request server in the online server list is sent to the request sending end, so that the request sending end selects the online request server with the highest priority to connect to, and selects the online request server with the second highest priority to connect to if the connection fails, until a connection with the online request server is successfully established.

6. A load balancing device, characterized in that, The load balancer is deployed on each request server in the cluster. The load balancing device is used to send probe messages to each requesting server in the cluster at second preset time intervals based on the Gossip protocol, and to receive the corresponding reply messages sent by the requesting servers. Based on all received response messages, identify the request server that went down in the cluster; Based on all request servers in the cluster and request servers that have crashed, generate a list of online servers for the cluster; The load balancing device also includes: The load information transmission module is configured to send first load information to the requesting server in the online server list and receive second load information sent by the requesting server in the cluster. The load status determination module is configured to determine the load status of each request server in the cluster based on the first load information and the second load information, wherein the load status is the load pressure of the corresponding request server; The priority determination module is configured to, upon receiving request information from a request sender, determine whether the request sender and the request server are in the same region based on the address information of the request sender in the request information. If they are in the same region, the product of a preset region weight coefficient and the load status is used to determine the score of the request server; otherwise, the load status is used to determine the score of the request server. The request servers are then sorted in ascending order of their scores to obtain priority data for each request server. This priority data is sent to the request sender so that the request sender can select a request server from the cluster to process the request based on the priority data. The priority of the request server is inversely proportional to its corresponding load pressure.

7. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the load balancing method as described in any one of claims 1-5.

8. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the load balancing method as described in any one of claims 1-5.

Images