Multi-machine hot standby method and device, electronic equipment and computer readable storage medium

Abstract

The invention discloses a multi-machine hot standby method and device, electronic equipment and a computer readable storage medium, and is applied to any cluster node in a distributed cluster, the cluster node can be configured to be a master node or slave nodes, when the cluster node is configured to be the master node, other cluster nodes are configured to be slave nodes, and when the cluster node is configured to be the slave nodes, the other cluster nodes are configured to be the slave nodes. The method comprises the following steps: determining a self node type according to pre-configuration information; if the node is the slave node, heartbeat monitoring is carried out on the master node, and when a heartbeat signal sent by the master node is not monitored, a voting request is initiated to other slave nodes, so that a new master node is determined in the distributed cluster according to voting results of the other slave nodes; and if the distributed cluster is the master node, sending a synchronization request to each slave node in the distributed cluster when the client request is processed, so as to determine whether to execute a data synchronization operation corresponding to the client request according to the request response of each slave node. According to the scheme, the double-master phenomenon in the multi-machine hot standby process can be effectively solved, and the data consistency of the master equipment and the standby equipment is ensured.

Description

Technical Field

[0001] The present application relates to the technical field of data backup, and in particular to a multi-machine hot standby method, and also to a multi-machine hot standby device, electronic equipment, computer-readable storage medium, and computer program product. Background Art

[0002] With the advent of the big data era, user terminal components are unable to meet the processing needs of large amounts of data, which led to the concept of cloud platforms. Cloud platforms can provide users with instant software services and development environments, reducing the cost of user use and program development.

[0003] As the name implies, multi-machine hot standby means that there is a master node (Master) and a slave node (Slave) in the cloud platform system. The master node is responsible for processing all write operations, while the slave node is responsible for replicating the data on the master node. When the master node fails, the slave node can take over the work of the master node to ensure data availability. However, the existing multi-machine hot standby implementation method has certain defects, that is, there is no reliable arbitration node. When a failure occurs, it is impossible to confirm which node is normal, and it is easy to have a dual master phenomenon, affecting data consistency.

[0004] Therefore, how to effectively solve the dual-master phenomenon in the multi-machine hot standby process and ensure the data consistency of the master and standby devices is an urgent problem to be solved by technical personnel in this field. Summary of the invention

[0005] The purpose of the present application is to provide a multi-machine hot standby method, which can effectively solve the dual-master phenomenon in the multi-machine hot standby process and ensure the data consistency of the master and standby devices; another purpose of the present application is to provide a multi-machine hot standby device, electronic device, computer-readable storage medium and computer program product, all of which have the above-mentioned beneficial effects.

[0006] In a first aspect, the present application provides a multi-machine hot standby method, which is applied to any cluster node in a distributed cluster, where the cluster node can be configured as a master node or a slave node. When the cluster node is configured as the master node, other cluster nodes in the distributed cluster are configured as slave nodes. The method includes:

[0007] Determine the node type based on pre-configured information;

[0008] If the node type is the slave node, the heartbeat of the master node is monitored, and when the heartbeat signal sent by the master node cannot be detected, a voting request is initiated to other slave nodes, so as to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes;

[0009] If the node type itself is the master node, when processing a client request, a synchronization request is sent to each of the slave nodes in the distributed cluster to determine whether to execute the data synchronization operation corresponding to the client request based on the request response of each of the slave nodes.

[0010] Optionally, heartbeat monitoring is performed on the master node, and when a heartbeat signal sent by the master node cannot be monitored, a voting request is initiated to other slave nodes to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes, including:

[0011] Performing the heartbeat monitoring on the master node using a primary communication path;

[0012] When the heartbeat signal sent by the master node cannot be received through the main communication path within a first preset time period, switching the current communication path from the main communication path to the slave communication path;

[0013] Performing the heartbeat monitoring on the master node using the slave communication path;

[0014] When the heartbeat signal sent by the master node fails to be received within a second preset time period through the slave communication path, entering a waiting state;

[0015] Performing the heartbeat monitoring on the master node by using the master communication path and the slave communication path in the waiting state, and counting the duration of the waiting state;

[0016] When the duration exceeds a preset time threshold, the voting request is initiated to each of the other slave nodes to determine the new master node in the distributed cluster according to the voting results of each of the other slave nodes.

[0017] Optionally, performing the heartbeat monitoring on the master node by using the primary communication path includes:

[0018] Using the TCP communication path as the main communication path, and using the main communication path to perform the heartbeat monitoring on the master node;

[0019] Performing the heartbeat monitoring on the master node by using the slave communication path includes:

[0020] The UDP communication path and / or the serial communication path are used as the slave communication path, and the slave communication path is used to perform the heartbeat monitoring on the master node.

[0021] Optionally, determining a new master node in the distributed cluster according to the voting results of each of the other slave nodes includes:

[0022] Determine the cluster node with the highest number of votes according to the voting results of each of the other slave nodes;

[0023] Determine whether the proportion of votes obtained by the cluster node with the highest number of votes reaches a first preset proportion;

[0024] If the proportion of the obtained votes reaches the first preset proportion, the cluster node with the highest number of votes is used as the new master node;

[0025] If the proportion of the obtained votes does not reach the first preset proportion, return to the step of initiating voting requests to other slave nodes to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes.

[0026] Optionally, the multi-machine hot standby method further includes:

[0027] When the heartbeat signal sent by the master node is monitored, determining timestamp information and node status information of the master node according to the heartbeat signal;

[0028] Verifying the timestamp information and the node status information;

[0029] When the timestamp information and / or the node status information verification fails, the step of initiating a voting request to each other slave node to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes is executed.

[0030] Optionally, determining whether to perform a data synchronization operation corresponding to the client request according to the request response of each slave node includes:

[0031] Determining whether the proportion of the number of request responses reaches a second preset proportion according to the request responses of each of the slave nodes;

[0032] If the proportion of the number of request responses reaches the second preset proportion, executing the data synchronization operation corresponding to the client request;

[0033] If the proportion of the request response quantity does not reach the second preset proportion, the data synchronization operation corresponding to the client request is abandoned.

[0034] Optionally, executing a data synchronization operation corresponding to the client request includes:

[0035] Determining synchronization data corresponding to the client request;

[0036] Compressing and / or encrypting the synchronization data to obtain target synchronization data;

[0037] The target synchronization data is sent to each of the slave nodes to achieve data synchronization.

[0038] In a second aspect, the present application further discloses a multi-machine hot standby device, which is applied to any cluster node in a distributed cluster, wherein the cluster node can be configured as a master node or a slave node. When the cluster node is configured as the master node, the other cluster nodes in the distributed cluster are configured as the slave nodes. The device includes:

[0039] A determination module, used to determine the node type according to pre-configured information;

[0040] A monitoring module, configured to perform heartbeat monitoring on the master node if the node type is the slave node, and initiate a voting request to other slave nodes when the heartbeat signal sent by the master node cannot be detected, so as to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes;

[0041] The synchronization module is used to send a synchronization request to each slave node in the distributed cluster when processing a client request if its own node type is the master node, so as to determine whether to execute the data synchronization operation corresponding to the client request according to the request response of each slave node.

[0042] In a third aspect, the present application further discloses an electronic device, comprising:

[0043] Memory for storing computer programs;

[0044] A processor is used to implement the steps of any one of the multi-machine hot standby methods described above when executing the computer program.

[0045] In a fourth aspect, the present application further discloses a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the multi-machine hot standby methods described above are implemented.

[0046] In a fifth aspect, the present invention further discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of any one of the multi-machine hot standby methods described above.

[0047] The present application provides a multi-machine hot standby method, which is applied to any cluster node in a distributed cluster. The cluster node can be configured as a master node or a slave node. When the cluster node is configured as the master node, the other cluster nodes in the distributed cluster are configured as the slave nodes. The method includes: determining the node type of itself according to pre-configuration information; if the node type of itself is the slave node, performing heartbeat monitoring on the master node, and when the heartbeat signal sent by the master node cannot be detected, initiating a voting request to other slave nodes, so as to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes; if the node type of itself is the master node, then when processing a client request, sending a synchronization request to each of the slave nodes in the distributed cluster, so as to determine whether to execute the data synchronization operation corresponding to the client request according to the request response of each of the slave nodes.

[0048] By applying the technical solution provided by the present application, a multi-machine hot standby solution is implemented based on a distributed cluster. Any cluster node in the distributed cluster can be configured as a master node, and the remaining cluster nodes are configured as slave nodes. Each slave node monitors the heartbeat of the master node. When the heartbeat signal of the master node cannot be detected, the master node can be considered abnormal. At this time, a new master node can be selected in the distributed cluster by voting; and for the master node, data consistency between the master and standby nodes can be ensured by performing data synchronization operations. It can be seen that the technical solution effectively solves the dual-master phenomenon that may occur in the multi-machine hot standby process through the heartbeat monitoring mechanism and the cluster node voting mechanism, thereby ensuring the data consistency of the master and standby devices.

[0049] In one embodiment of the present application, when a cluster node is configured as a slave node, if the heartbeat signal sent by the master node can be received normally, before determining that the master node is normal, the heartbeat signal can be verified first, specifically, the timestamp information of the heartbeat signal and the node status information of the master node are verified. Only when both are verified can it be truly determined that the master node is normal. Otherwise, the master node is still considered abnormal, and a voting mechanism needs to be initiated to select a new master node in the distributed cluster to effectively ensure the stability and security of the distributed cluster.

[0050] The multi-machine hot standby device, electronic device, computer-readable storage medium and computer program product provided in this application also have the above-mentioned technical effects, and this application will not elaborate on them here. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the prior art and the embodiments of the present application, the drawings required for use in the description of the prior art and the embodiments of the present application are briefly introduced below. Of course, the drawings described below in relation to the embodiments of the present application are only part of the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without creative work, and the obtained other drawings also belong to the protection scope of the present application.

[0052] Figure 1 A flowchart of a multi-machine hot standby method provided in this application;

[0053] Figure 2 A flowchart of another multi-machine hot standby method provided by this application;

[0054] Figure 3 A schematic diagram of the structure of a multi-machine hot standby device provided in this application;

[0055] Figure 4 A schematic diagram of the structure of an electronic device provided in this application. DETAILED DESCRIPTION

[0056] The core of the present application is to provide a multi-machine hot standby method, which can effectively solve the dual-master phenomenon in the multi-machine hot standby process and ensure the data consistency of the master and standby devices; another core of the present application is to provide a multi-machine hot standby device, electronic device, computer-readable storage medium and computer program product, all of which have the above-mentioned beneficial effects.

[0057] In order to describe the technical solutions in the embodiments of the present application more clearly and completely, the technical solutions in the embodiments of the present application will be introduced below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0058] An embodiment of the present application provides a multi-machine hot standby method.

[0059] Please refer to Figure 1 , Figure 1A flow chart of a multi-machine hot standby method provided in the present application, the multi-machine hot standby method is applied to any cluster node in a distributed cluster, the cluster node can be configured as a master node or a slave node, obviously, when the cluster node is configured as a master node, other cluster nodes in the distributed cluster will be configured as slave nodes; when the cluster node is configured as a slave node, there must be another cluster node in the distributed cluster that is configured as a master node, and the other cluster nodes are also configured as slave nodes; the multi-machine hot standby method provided in the embodiment of the present application may include the following S101 to S103.

[0060] S101: Determine the node type according to pre-configuration information;

[0061] Specifically, this step aims to determine the node type based on the pre-configuration information, that is, to determine whether it is configured as a slave node or a master node. Specifically, developers can deploy a multi-machine hot standby script in each cluster node that needs to perform multi-machine hot standby. The multi-machine hot standby script carries pre-configuration information about the corresponding cluster node. When the cluster node starts running, the multi-machine hot standby script is executed, and the node type can be determined based on the pre-configuration information. More specifically, the cluster node that contains a floating IP in the pre-configuration information is the master node, and the cluster node that does not contain a floating IP is the slave node.

[0062] It is understandable that the above-mentioned cluster nodes that need to perform multi-machine hot standby can be all cluster nodes in the distributed cluster, or can be part of the cluster nodes in the distributed cluster. More specifically, the cluster nodes deployed with the multi-machine hot standby script are the cluster nodes that need to perform multi-machine hot standby. It should be noted that the number of cluster nodes that need to perform multi-machine hot standby is at least 3, in order to facilitate the implementation of the subsequent voting mechanism. In one possible implementation, the cluster nodes that need to perform multi-machine hot standby in the distributed cluster follow the Raft protocol (a distributed protocol) to ensure data consistency between the cluster nodes.

[0063] S102: If the node type is a slave node, the heartbeat of the master node is monitored, and when the heartbeat signal sent by the master node cannot be detected, a voting request is initiated to other slave nodes to determine a new master node in the distributed cluster according to the voting results of other slave nodes;

[0064] Specifically, each slave node in the distributed cluster (here refers to the cluster node configured as a slave node that needs to perform multi-machine hot standby, the same below) can perform real-time / scheduled heartbeat monitoring on the master node. Obviously, if the slave node fails to detect the heartbeat signal of the master node, it can be determined that the master node is abnormal. If the slave node can normally detect the heartbeat signal of the master node, it can be determined that the master node is normal. Among them, when the master node is determined to be abnormal, the master node can be reselected in the distributed cluster through a voting mechanism, that is, the slave node that fails to detect the heartbeat signal initiates a voting request to each other slave node, so that each slave node starts voting, so that a new master node can be determined in the distributed cluster based on the voting results of each other slave node. For example, the cluster node with the highest number of votes can be used as the new master node.

[0065] In one embodiment of the present application, heartbeat monitoring is performed on the master node, and when a heartbeat signal sent by the master node cannot be monitored, a voting request is initiated to other slave nodes to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes, which may include:

[0066] Use the primary communication path to monitor the heartbeat of the master node;

[0067] When a heartbeat signal sent by the master node cannot be received through the main communication path within a first preset time period, switching the current communication path from the main communication path to the slave communication path;

[0068] Use the slave communication path to monitor the heartbeat of the master node;

[0069] When a heartbeat signal sent by the master node is not received through the slave communication path within a second preset time period, entering a waiting state;

[0070] In the waiting state, the heartbeat monitoring of the master node is performed using the master communication path and the slave communication path, and the duration of the waiting state is counted;

[0071] When the duration exceeds a preset time threshold, a voting request is initiated to each other slave node to determine a new master node in the distributed cluster according to the voting results of each other slave node.

[0072] The embodiment of the present application provides a heartbeat monitoring mechanism based on a master-slave communication path to effectively ensure the accuracy of heartbeat monitoring and further ensure the stability of the distributed cluster. Specifically, firstly, the main communication path is used for heartbeat monitoring. If the heartbeat signal of the master node cannot be monitored within the preset first time period, the slave communication path is used for heartbeat monitoring. If the heartbeat signal of the master node cannot be monitored within the preset second time period, the waiting state of the preset time threshold is entered, and the master-slave communication path is used to perform heartbeat monitoring at the same time in this waiting state. If the heartbeat signal of the master node still cannot be monitored, it can be determined that the master node is abnormal and a vote can be initiated. Otherwise, the master node is considered normal. It can be seen that the technical solution reserves sufficient heartbeat monitoring paths and heartbeat monitoring times for heartbeat monitoring to effectively ensure the accuracy of heartbeat monitoring and further ensure the stability of the distributed cluster.

[0073] It should be noted that the specific values ​​of the first preset time period, the second preset time period, and the preset time threshold do not affect the implementation of the present technical solution, and can be set by technicians according to actual needs, and the present application does not limit this. Similarly, the specific form of the master-slave communication path is not unique. For example, in one possible implementation:

[0074] Using the main communication path to perform heartbeat monitoring on the master node may include: using a TCP (Transmission Control Protocol) communication path as the main communication path, and using the main communication path to perform heartbeat monitoring on the master node;

[0075] Using the slave communication path to perform heartbeat monitoring on the master node may include: using a UDP (User Datagram Protocol) communication path and / or a serial communication path as a slave communication path, and using the slave communication path to perform heartbeat monitoring on the master node.

[0076] Furthermore, the multi-machine hot standby method may also include:

[0077] Recording path information of a communication path where heartbeat monitoring fails, wherein the communication path includes a primary communication path and / or a secondary communication path;

[0078] The path information is uploaded to the system management platform so that the system management platform can repair the communication path where the heartbeat monitoring fails according to the path information.

[0079] The multi-machine hot standby provided in the embodiment of the present application can further implement the repair operation of abnormal communication paths. For the master-slave node, it can count and record the path information of the communication path where its own heartbeat monitoring fails, and then upload it to the system management platform in a regular / real-time manner, so that the system management platform can perform communication path repair operations based on the path information of these abnormal communication paths. More specifically, the system management platform can perform this communication path repair operation at an appropriate time. For example, the communication path repair operation can be performed when the cluster load is low to effectively ensure the stability of the distributed cluster. Among them, different types of communication paths can correspond to different repair methods, which will not be repeated in this application.

[0080] In one embodiment of the present application, determining a new master node in a distributed cluster according to the voting results of other slave nodes may include:

[0081] Determine the cluster node with the highest number of votes based on the voting results of other slave nodes;

[0082] Determine whether the proportion of votes obtained by the cluster node with the highest number of votes reaches a first preset proportion;

[0083] If the proportion of votes obtained reaches the first preset proportion, the cluster node with the highest number of votes will be used as the new master node;

[0084] If the proportion of the obtained votes does not reach the first preset proportion, the process returns to the step of initiating a voting request to other slave nodes to determine a new master node in the distributed cluster according to the voting results of the other slave nodes.

[0085] The embodiment of the present application provides a method for determining a new master node in a distributed cluster based on the voting results of each slave node, that is, the cluster node with the highest number of votes and a first preset proportion of votes is used as the new master node, otherwise the voting mechanism is retriggered. In a possible implementation, the first preset proportion can be 50%.

[0086] S103: If the node type is a master node, when processing a client request, a synchronization request is sent to each slave node in the distributed cluster to determine whether to execute the data synchronization operation corresponding to the client request according to the request response of each slave node.

[0087] Specifically, the master node in the distributed cluster is used to connect with the client and process client requests. To achieve multi-machine hot standby, the master node can send synchronization requests to each slave node in the distributed cluster during the process of processing client requests, so as to achieve data synchronization between the master and slave nodes in the distributed cluster. In this process, the master node can determine whether to execute the data synchronization operation corresponding to the client request based on the request response of each slave node. For example, the data synchronization operation can be executed only when more than half of the slave nodes agree to data synchronization, so as to ensure data consistency between multiple devices (master and slave nodes).

[0088] In one embodiment of the present application, determining whether to perform a data synchronization operation corresponding to a client request according to a request response of each slave node may include:

[0089] Determine whether the proportion of the number of request responses reaches a second preset proportion according to the request responses of each slave node;

[0090] If the proportion of the number of request responses reaches a second preset proportion, the data synchronization operation corresponding to the client request is executed;

[0091] If the proportion of the number of request responses does not reach the second preset proportion, the data synchronization operation corresponding to the client request is abandoned.

[0092] The embodiment of the present application provides a method for determining whether to execute the data synchronization operation corresponding to the client request according to the request response of each slave node, that is, when it is determined that the proportion of the number of request responses reaches a second preset ratio, the data synchronization operation is executed, otherwise the data synchronization operation is abandoned. In a possible implementation, the second preset ratio can be specifically 50%.

[0093] In one embodiment of the present application, executing a data synchronization operation corresponding to a client request may include:

[0094] Determine the synchronization data corresponding to the client request;

[0095] Compressing and / or encrypting the synchronization data to obtain target synchronization data;

[0096] Send the target synchronization data to each slave node to achieve data synchronization.

[0097] In order to effectively ensure the security and synchronization efficiency of synchronized data, the data to be synchronized can be compressed and / or encrypted first to achieve data synchronization. Among them, the compression method and encryption method do not affect the implementation of this technical solution, and can be set by technical personnel according to actual needs. This application does not limit this. In one possible implementation method, the compression method can be specifically the lz4 algorithm (one of the fastest compression algorithms currently), and the encryption algorithm can be specifically any symmetric encryption algorithm.

[0098] It can be seen that the multi-machine hot standby method provided in the embodiment of the present application implements a multi-machine hot standby solution based on a distributed cluster. Any cluster node in the distributed cluster can be configured as a master node, and the remaining cluster nodes are configured as slave nodes. Each slave node performs heartbeat monitoring on the master node. When the heartbeat signal of the master node cannot be detected, it can be considered that the master node is abnormal. At this time, a new master node can be selected in the distributed cluster by voting; and for the master node, data synchronization operations can be performed to ensure data consistency between the master and standby nodes. It can be seen that the technical solution effectively solves the dual-master phenomenon that may occur in the multi-machine hot standby process through the heartbeat monitoring mechanism and the cluster node voting mechanism, thereby ensuring the data consistency of the master and standby devices.

[0099] Based on the above embodiments:

[0100] In one embodiment of the present application, the multi-machine hot standby method may further include:

[0101] When a heartbeat signal sent by the master node is detected, the timestamp information and the node status information of the master node are determined according to the heartbeat signal;

[0102] Verify timestamp information and node status information;

[0103] When the timestamp information and / or node status information verification fails, a step of initiating a voting request to each other slave node is executed to determine a new master node in the distributed cluster according to the voting results of each other slave node.

[0104] The multi-machine hot standby method provided in the embodiment of the present application can further implement the validity verification of the heartbeat signal to effectively ensure the legal security of the heartbeat signal, and further ensure the stability and security of the distributed cluster. Specifically, if the slave node can normally receive the heartbeat signal sent by the master node, the timestamp information and the node status information of the master node can be parsed therefrom first, and the two can be verified, wherein, for the timestamp information, the current timestamp can be used to verify it to determine whether the current timestamp is after the time node corresponding to the timestamp information; for the node status information, it can be determined whether it is in a normal state. Further, when both are verified, the master node can be considered to be in a normal state, otherwise the master node is still considered abnormal, and the voting mechanism can be triggered.

[0105] It can be seen that in the embodiment of the present application, when the cluster node is configured as a slave node, if the heartbeat signal sent by the master node can be received normally, before determining that the master node is normal, the heartbeat signal can be verified first, specifically, the timestamp information of the heartbeat signal and the node status information of the master node can be verified. Only when both are verified can it be truly determined that the master node is normal. Otherwise, the master node is still considered abnormal, and a voting mechanism needs to be initiated to select a new master node in the distributed cluster to effectively ensure the stability and security of the distributed cluster.

[0106] Based on the above embodiments, an embodiment of the present application provides another multi-machine hot standby method.

[0107] Please refer to Figure 2 , Figure 2 A flowchart of another multi-machine hot standby method provided in this application is as follows:

[0108] 1. For multiple cluster nodes after the virtualization platform is deployed, deploy executable multi-machine hot standby scripts.

[0109] 2. As the deployment of each cluster node is completed, the corresponding database services are also deployed.

[0110] 3. In the multi-machine hot standby script, an available floating IP is configured to implement the master node ( Figure 2 As shown in the leader node) configuration, and specify multiple cluster node IPs to implement slave nodes ( Figure 2 The floating IP is the entry address for the client to access the cloud management platform (distributed cluster). By logging in to this entry address, you can perform operations such as access management on the cloud management platform.

[0111] 4. Log in to one of the cluster nodes through SSH (Secure Shell) to trigger the execution of the multi-machine hot standby script, which includes an execution module that converts ordinary computing to management plus computing and a distributed data consistency cluster module based on the Raft protocol.

[0112] The execution module for converting ordinary computing to management plus computing is mainly used to convert ordinary cluster nodes into management nodes, which are the master nodes in the Raft cluster and are responsible for processing client requests, managing log replication, communicating with other cluster nodes, and managing and maintaining cloud management platforms. Among them, the Raft protocol is a strongly consistent, decentralized, and highly available distributed protocol that can be used to solve distributed consistency problems.

[0113] The distributed data consistency cluster module based on the Raft protocol is mainly used to deploy the Raft protocol consistency cluster. After the master node is elected, when the master node receives a client request, it appends the client request as a log entry to the local log and sends the log entry to other slave nodes for replication. Obviously, when most slave nodes have replicated a log entry, the log entry is considered to be committed, thereby ensuring the data consistency and reliability of each cluster node in the Raft cluster.

[0114] 5. The multi-machine hot standby script is deployed successfully. The multi-machine hot standby script also includes a monitoring switching module, which detects the communication status between cluster nodes through a heartbeat mechanism. When the master node fails, other slave nodes will trigger a new master node election process and elect a new master node to continue to provide services. At this time, you can switch the floating IP to the new master node and start the management service of the cloud management platform. The new master node will automatically synchronize the latest data status to ensure the continuity and consistency of the service.

[0115] 6. The communication status between cluster nodes can be monitored by heartbeat. The heartbeat monitoring mechanism of three redundant communication paths, TCP / IP, UDP, and serial port, can be used. Each slave node can perform heartbeat master detection through TCP communication, and can also perform heartbeat backup detection through other communication methods, namely UDP and serial port. When the main communication method fails, the system can quickly switch to the backup communication method to ensure the continuity and reliability of heartbeat monitoring. When both the main and backup path detections fail, it is considered that the master node communication is abnormal.

[0116] 7. Heartbeat monitoring mechanism: The slave node can regularly send heartbeat signals to the master node through the main communication method and the backup communication method. The heartbeat signal contains the status information and timestamp of the master node.

[0117] Heartbeat reception and judgment: After receiving the heartbeat signal from the master node, the slave node judges the communication status of the master node based on the timestamp and node status information in the message. If the heartbeat signal of the master node is not received for multiple consecutive times (such as 3 times), it is considered that the master node may be failed.

[0118] Communication path switching: When the primary communication path fails, the master and slave nodes will automatically switch to the backup communication path for heartbeat monitoring and data synchronization. At the same time, the system will also record the failed communication path information and try to restore the communication path at an appropriate time.

[0119] 8. Log transmission: In order to further reduce the network bandwidth usage, log entries can be compressed using the lz4 algorithm before transmission. The lz4 algorithm is currently the most efficient compression algorithm based on comprehensive analysis and can effectively ensure data synchronization efficiency.

[0120] It can be seen that the multi-machine hot standby method provided in the embodiment of the present application implements a multi-machine hot standby solution based on a distributed cluster. Any cluster node in the distributed cluster can be configured as a master node, and the remaining cluster nodes are configured as slave nodes. Each slave node performs heartbeat monitoring on the master node. When the heartbeat signal of the master node cannot be detected, it can be considered that the master node is abnormal. At this time, a new master node can be selected in the distributed cluster by voting; and for the master node, data synchronization operations can be performed to ensure data consistency between the master and standby nodes. It can be seen that the technical solution effectively solves the dual-master phenomenon that may occur in the multi-machine hot standby process through the heartbeat monitoring mechanism and the cluster node voting mechanism, thereby ensuring the data consistency of the master and standby devices.

[0121] An embodiment of the present application provides a multi-machine hot standby device.

[0122] Please refer to Figure 3 , Figure 3 This is a structural diagram of a multi-machine hot standby device provided by the present application, which is applied to any cluster node in a distributed cluster. The cluster node can be configured as a master node or a slave node. When the cluster node is configured as a master node, other cluster nodes in the distributed cluster are configured as slave nodes. The multi-machine hot standby device may include:

[0123] Determination module 1, used to determine the node type according to pre-configuration information;

[0124] Monitoring module 2 is used for monitoring the heartbeat of the master node if the node type is a slave node, and when failing to detect the heartbeat signal sent by the master node, initiating a voting request to other slave nodes, so as to determine a new master node in the distributed cluster according to the voting results of other slave nodes;

[0125] The synchronization module 3 is used to send a synchronization request to each slave node in the distributed cluster when processing a client request if its own node type is a master node, so as to determine whether to execute the data synchronization operation corresponding to the client request according to the request response of each slave node.

[0126] It can be seen that the multi-machine hot standby device provided in the embodiment of the present application realizes a multi-machine hot standby solution based on a distributed cluster. Any cluster node in the distributed cluster can be configured as a master node, and the remaining cluster nodes are configured as slave nodes, and each slave node performs heartbeat monitoring on the master node. When the heartbeat signal of the master node cannot be detected, it can be considered that the master node is abnormal. At this time, a new master node can be selected in the distributed cluster by voting; and for the master node, the data consistency between the master and standby nodes can be ensured by performing data synchronization operations. It can be seen that the technical solution effectively solves the dual-master phenomenon that may occur in the multi-machine hot standby process through the heartbeat monitoring mechanism and the cluster node voting mechanism, thereby ensuring the data consistency of the master and standby devices.

[0127] In one embodiment of the present application, the monitoring module 2 may include:

[0128] A first monitoring unit, configured to perform heartbeat monitoring on the master node using a primary communication path;

[0129] A switching unit, configured to switch the current communication path from the main communication path to the slave communication path when a heartbeat signal sent by the master node cannot be received through the main communication path within a first preset time period;

[0130] A second monitoring unit, configured to perform heartbeat monitoring on the master node using a slave communication path;

[0131] A waiting unit, configured to enter a waiting state when a heartbeat signal sent by the master node is not received through the slave communication path within a second preset time period;

[0132] A statistical unit, used for performing heartbeat monitoring on the master node by using the master communication path and the slave communication path in the waiting state, and counting the duration of the waiting state;

[0133] The determination unit is used to initiate a voting request to each other slave node when the duration exceeds a preset time threshold, so as to determine a new master node in the distributed cluster according to the voting results of each other slave node.

[0134] In one embodiment of the present application, the first monitoring unit may be specifically configured to use the TCP communication path as the primary communication path, and perform heartbeat monitoring on the master node using the primary communication path;

[0135] The second monitoring unit may be specifically configured to use the UDP communication path and / or the serial communication path as a slave communication path, and utilize the slave communication path to perform heartbeat monitoring on the master node.

[0136] In one embodiment of the present application, the above-mentioned determination unit can be specifically used to determine the cluster node with the highest votes based on the voting results of each other slave node; determine whether the proportion of votes obtained by the cluster node with the highest votes reaches a first preset proportion; if the proportion of votes obtained reaches the first preset proportion, then use the cluster node with the highest votes as the new master node; if the proportion of votes obtained does not reach the first preset proportion, return to the step of initiating a voting request to other slave nodes to determine the new master node in the distributed cluster based on the voting results of each other slave node.

[0137] In one embodiment of the present application, the multi-machine hot standby device may also include a verification module, which is used to determine the timestamp information and the node status information of the master node according to the heartbeat signal when a heartbeat signal sent by the master node is monitored; verify the timestamp information and the node status information; when the timestamp information and / or the node status information verification fails, execute the step of initiating a voting request to each other slave node to determine a new master node in the distributed cluster according to the voting results of each other slave node.

[0138] In one embodiment of the present application, the above-mentioned synchronization module 3 can be specifically used to determine whether the proportion of the number of request responses reaches a second preset proportion based on the request responses of each slave node; if the proportion of the number of request responses reaches the second preset proportion, the data synchronization operation corresponding to the client request is executed; if the proportion of the number of request responses does not reach the second preset proportion, the data synchronization operation corresponding to the client request is abandoned.

[0139] In one embodiment of the present application, the synchronization module 3 can be specifically used to determine the synchronization data corresponding to the client request; compress and / or encrypt the synchronization data to obtain target synchronization data; and send the target synchronization data to each slave node to achieve data synchronization.

[0140] For an introduction to the device provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0141] An embodiment of the present application provides an electronic device.

[0142] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application, and the electronic device may include:

[0143] A memory 11, used for storing computer programs;

[0144] The processor 10 can implement the steps of any one of the above-mentioned multi-machine hot standby methods when executing a computer program.

[0145] like Figure 4, which is a schematic diagram of the composition structure of an electronic device, the electronic device may include: a processor 10, a memory 11, a communication interface 12 and a communication bus 13. The processor 10, the memory 11 and the communication interface 12 all communicate with each other through the communication bus 13.

[0146] In the embodiment of the present application, the processor 10 may be a central processing unit (CPU), an application specific integrated circuit, a digital signal processor, a field programmable gate array or other programmable logic devices, etc.

[0147] The processor 10 may call a program stored in the memory 11. Specifically, the processor 10 may execute operations in an embodiment of the multi-machine hot standby method.

[0148] The memory 11 is used to store one or more programs, which may include program codes, and the program codes include computer operation instructions. In the embodiment of the present application, the memory 11 at least stores programs for implementing the following functions:

[0149] Determine the node type based on pre-configured information;

[0150] If the node type is a slave node, it will monitor the heartbeat of the master node, and if it fails to detect the heartbeat signal sent by the master node, it will initiate a voting request to other slave nodes to determine a new master node in the distributed cluster based on the voting results of other slave nodes;

[0151] If the node type is a master node, when processing a client request, it sends a synchronization request to each slave node in the distributed cluster to determine whether to execute the data synchronization operation corresponding to the client request based on the request response of each slave node.

[0152] In a possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function, etc.; the data storage area may store data created during use.

[0153] In addition, the memory 11 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0154] The communication interface 12 may be an interface of a communication module, and is used to connect to other devices or systems.

[0155] Of course, it should be noted that Figure 4 The structure shown does not constitute a limitation on the electronic device in the embodiment of the present application. In actual applications, the electronic device may include Figure 4More or fewer components than shown, or combinations of certain components.

[0156] An embodiment of the present application provides a computer-readable storage medium.

[0157] The computer-readable storage medium provided in the embodiment of the present application stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned multi-machine hot standby methods can be implemented.

[0158] Among them, the computer-readable storage medium can be any available medium that can be stored in a computer or a data storage device such as a server or data center that includes one or more available media integrated. For example, it can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape, etc.), an optical medium (such as a DVD) or a semiconductor medium (such as a solid-state hard disk) and other media that can store computer program codes.

[0159] For an introduction to the computer-readable storage medium provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0160] An embodiment of the present application provides a computer program product.

[0161] The computer program product provided in the embodiment of the present application includes a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of any of the above-mentioned multi-machine hot standby methods can be implemented.

[0162] Specifically, in the above embodiments, all or part of them can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of them can be implemented in the form of a computer program product.

[0163] Among them, the computer program product may include one or more computer programs / instructions, and when the computer program / instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application may be generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line, etc.) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0164] For an introduction to the computer program product provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.

[0165] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0166] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0167] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0168] The technical solution provided by the present application is described in detail above. The principle and implementation method of the present application are described in detail using specific examples herein, and the description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.

Claims

1. A multi-machine hot standby method, characterized in that: Applied to any cluster node in a distributed cluster, the cluster node can be configured as a master node or a slave node. When the cluster node is configured as the master node, other cluster nodes in the distributed cluster are configured as the slave nodes. The method includes: Determine the node type based on pre-configured information; If the node type is the slave node, the heartbeat of the master node is monitored, and when the heartbeat signal sent by the master node cannot be detected, a voting request is initiated to other slave nodes, so as to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes; If the node type itself is the master node, when processing a client request, a synchronization request is sent to each of the slave nodes in the distributed cluster to determine whether to execute the data synchronization operation corresponding to the client request based on the request response of each of the slave nodes.

2. The multi-machine hot standby method according to claim 1, characterized in that: Performing heartbeat monitoring on the master node, and when failing to monitor the heartbeat signal sent by the master node, initiating a voting request to other slave nodes, so as to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes, including: Performing the heartbeat monitoring on the master node using a primary communication path; When the heartbeat signal sent by the master node cannot be received through the main communication path within a first preset time period, switching the current communication path from the main communication path to the slave communication path; Performing the heartbeat monitoring on the master node using the slave communication path; When the heartbeat signal sent by the master node fails to be received within a second preset time period through the slave communication path, entering a waiting state; Performing the heartbeat monitoring on the master node by using the master communication path and the slave communication path in the waiting state, and counting the duration of the waiting state; When the duration exceeds a preset time threshold, the voting request is initiated to each of the other slave nodes to determine the new master node in the distributed cluster according to the voting results of each of the other slave nodes.

3. The multi-machine hot standby method according to claim 2, characterized in that: Performing the heartbeat monitoring on the master node using the primary communication path includes: Using the TCP communication path as the main communication path, and using the main communication path to perform the heartbeat monitoring on the master node; Performing the heartbeat monitoring on the master node by using the slave communication path includes: The UDP communication path and / or the serial communication path are used as the slave communication path, and the slave communication path is used to perform the heartbeat monitoring on the master node.

4. The multi-machine hot standby method according to claim 1, characterized in that: Determining a new master node in the distributed cluster according to the voting results of each of the other slave nodes includes: Determine the cluster node with the highest number of votes according to the voting results of each of the other slave nodes; Determine whether the proportion of votes obtained by the cluster node with the highest number of votes reaches a first preset proportion; If the proportion of the obtained votes reaches the first preset proportion, the cluster node with the highest number of votes is used as the new master node; If the proportion of the obtained votes does not reach the first preset proportion, return to the step of initiating voting requests to other slave nodes to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes.

5. The multi-machine hot standby method according to any one of claims 1 to 4, characterized in that: Also includes: When the heartbeat signal sent by the master node is monitored, determining timestamp information and node status information of the master node according to the heartbeat signal; Verifying the timestamp information and the node status information; When the timestamp information and / or the node status information verification fails, the step of initiating a voting request to each other slave node to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes is executed.

6. The multi-machine hot standby method according to claim 1, characterized in that: Determining whether to execute the data synchronization operation corresponding to the client request according to the request response of each slave node includes: Determining whether the proportion of the number of request responses reaches a second preset proportion according to the request responses of each of the slave nodes; If the proportion of the number of request responses reaches the second preset proportion, executing the data synchronization operation corresponding to the client request; If the proportion of the request response quantity does not reach the second preset proportion, the data synchronization operation corresponding to the client request is abandoned.

7. The multi-machine hot standby method according to claim 1, characterized in that: Executing the data synchronization operation corresponding to the client request includes: Determining synchronization data corresponding to the client request; Compressing and / or encrypting the synchronization data to obtain target synchronization data; The target synchronization data is sent to each of the slave nodes to achieve data synchronization.

8. A multi-machine hot standby device, characterized in that: Applied to any cluster node in a distributed cluster, the cluster node can be configured as a master node or a slave node, when the cluster node is configured as the master node, other cluster nodes in the distributed cluster are configured as the slave nodes, the device includes: A determination module, used to determine the node type according to pre-configured information; A monitoring module, configured to perform heartbeat monitoring on the master node if the node type is the slave node, and initiate a voting request to other slave nodes when the heartbeat signal sent by the master node cannot be detected, so as to determine a new master node in the distributed cluster according to the voting results of each of the other slave nodes; The synchronization module is used to send a synchronization request to each slave node in the distributed cluster when processing a client request if its own node type is the master node, so as to determine whether to execute the data synchronization operation corresponding to the client request according to the request response of each slave node.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the multi-machine hot standby method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the multi-machine hot standby method according to any one of claims 1 to 7 are implemented.

Images