Address switching method, system, device, equipment, storage medium and program product

Abstract

The invention relates to an address switching method, system and device, equipment, a storage medium and a program product. The method comprises the following steps: on the basis that distributed coordination service is deployed on each node in a distributed cluster, calling a distributed coordination service process through each slave node in the distributed cluster, monitoring the running state of a current master node in the distributed cluster, and when the running state of the current master node is an abnormal state, calling a distributed coordination service process through each slave node in the distributed cluster; judging whether the running duration of the current master node reaches a preset switching cooling period or not, and then determining a new master node according to the running state index data of each slave node except the current master node in the distributed cluster under the condition that the running duration of the current master node reaches the switching cooling period; and completing the switching of the virtual network address of the distributed cluster from the current main node to the new main node. By adopting the method, the service stability of the distributed cluster system can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an address switching method, system, apparatus, device, storage medium, and program product. Background Technology

[0002] In a cluster system, multiple nodes in the cluster work together to provide services to clients through a Virtual Internet Protocol Address (VIP).

[0003] In related technologies, VIPs are typically bound to the master node of a cluster. Clients access the cluster through the VIP. When the master node fails, the cluster will automatically migrate the VIP to a standby node to ensure that client access is not affected and to provide continuous service to the client.

[0004] However, the address switching methods in related technologies have technical problems with service instability. Summary of the Invention

[0005] Therefore, it is necessary to provide an address switching method, system, device, equipment, storage medium, and program product that can ensure the stability of distributed cluster system services in response to the above-mentioned technical problems.

[0006] In a first aspect, this application provides an address switching method, applied to a distributed coordination service process in any slave node of a distributed cluster, wherein a distributed coordination service is deployed on each node of the distributed cluster; the method includes:

[0007] Monitor the running status of the current master node in the distributed cluster;

[0008] If the current master node is in an abnormal running state, determine whether the current master node's running time has reached the preset switching cooldown period.

[0009] If the current master node's runtime reaches the switching cooldown period, a new master node is determined based on the running status indicators of each slave node in the distributed cluster, excluding the current master node, and the virtual network address of the distributed cluster is switched from the current master node to the new master node.

[0010] In the address switching method provided in this application embodiment, based on the deployment of a distributed coordination service on each node in the distributed cluster, each slave node in the distributed cluster calls the distributed coordination service process to monitor the running status of the current master node in the distributed cluster. If the current master node's running status is abnormal, it determines whether the current master node's runtime has reached a preset switching cooldown period. Then, if the current master node's runtime has reached the switching cooldown period, a new master node is determined based on the running status indicators of each slave node in the distributed cluster (excluding the current master node), and the virtual network address of the distributed cluster is switched from the current master node to the new master node. In this method, each slave node in the distributed cluster calls the distributed coordination service process. If the current master node is in an abnormal state, it further determines whether the current master node's runtime has reached the switching cooldown period. If the switching cooldown period has been reached, the selection of a new master node and the address switching of the new master node are executed; otherwise, the current master node is not switched. This avoids frequent switching of the virtual network address of the distributed cluster, thus ensuring that the virtual network address of the distributed cluster can run relatively stably and persistently on the current master node, improving the service stability of the distributed cluster. Furthermore, when determining the new master node, the operating status indicators of each slave node are used as the basis. This makes the determined new master node more reliable and reasonable, so that the virtual network address can continue to run smoothly on the new master node after switching to it, thereby ensuring the service stability of the distributed cluster.

[0011] In one embodiment, monitoring the running status of the current master node in the distributed cluster includes:

[0012] According to the preset sampling period, collect multiple different types of operational status indicator data of the current master node;

[0013] If multiple different types of operating status indicators for the current master node are all less than or equal to the corresponding indicator thresholds, then the operating status of the current master node is determined to be normal.

[0014] If any type of operational status indicator data of the current master node is greater than the corresponding indicator threshold, and the abnormal frequency of the operational status indicator data exceeds the preset frequency threshold, then the operational status of the current master node is determined to be abnormal.

[0015] In the address switching method provided in this application embodiment, multiple different types of operating status indicator data of the master node are collected according to a preset sampling period. Based on the comparison results of the operating status indicator data and the corresponding indicator threshold, and combined with whether the abnormal frequency exceeds the preset threshold, the current operating status of the master node is comprehensively determined, so as to achieve accurate and dynamic monitoring of the operating status of the master node.

[0016] In one embodiment, determining a new master node based on the operational status metrics of all slave nodes in the distributed cluster, excluding the current master node, includes:

[0017] Retrieve multiple operational status metrics from each slave node (excluding the current master node) from the storage table of the distributed cluster; the storage table includes operational status metrics reported by each node in the distributed cluster.

[0018] According to the preset indicator weights, the multiple operating status indicator data of each slave node are weighted to obtain the status quantification value of each slave node; the status quantification value of each slave node represents the degree of association between each slave node and the new master node.

[0019] Candidate master nodes are determined based on the status quantization values ​​of each slave node, and the candidate master nodes are reported to the storage table;

[0020] The new master node is determined based on the reporting time of each candidate master node in the storage table.

[0021] In the address switching method provided in this application embodiment, the running status of each slave node is quantitatively analyzed by combining preset weights and the running status index data of each slave node to determine the candidate master node, ensuring a high correlation between the candidate master node and the new master node, and finally selecting the new master node based on the reporting time, thus ensuring the timeliness and orderliness of the election of the new master node and improving the automatic switching efficiency when the master node of the distributed cluster is abnormal.

[0022] In one embodiment, determining candidate master nodes based on the state quantization values ​​of each slave node includes:

[0023] The state quantization values ​​of each slave node are sorted to obtain the slave node sequence corresponding to each slave node;

[0024] Based on the sequence of slave nodes, candidate master nodes are determined from the slave nodes.

[0025] In the address switching method provided in this application embodiment, the state quantization values ​​of each slave node are sorted to obtain the slave node sequence corresponding to each slave node, so as to intuitively distinguish the state of each slave node. Then, based on this, a candidate master node is determined from each slave node. The entire determination process is logically clear and based on reliable evidence, and is suitable for distributed cluster systems.

[0026] In one embodiment, determining a candidate master node from the slave nodes based on the slave node sequence of each slave node includes:

[0027] Based on the slave node sequence of each slave node, standby nodes with state quantization values ​​greater than the preset state quantization threshold are selected from each slave node.

[0028] Retrieve the historical failure rate of each standby node from the storage table; the storage table includes the historical failure rate of each node in the distributed cluster.

[0029] The standby node corresponding to the lowest historical failure rate is identified as the candidate master node.

[0030] In the address switching method provided in this application embodiment, based on the slave node sequence of each slave node, a standby node with a state quantization value greater than a preset state quantization threshold is selected from each slave node to ensure the reliability of the current performance of the standby node. Then, based on the historical failure rate of each standby node, the risk of future failure of each standby node is assessed. The candidate master node determined in this way has the characteristics of reliable performance and low failure probability, providing a reliable basis for the subsequent determination of a new master node.

[0031] In one embodiment, before determining a new master node based on the running status indicator data of each slave node in the distributed cluster other than the current master node, the method further includes:

[0032] Get the number of active nodes in the distributed cluster; active nodes are nodes in the distributed cluster that are running.

[0033] If the number of active nodes is less than or equal to half the total number of nodes in the distributed cluster, a cluster environment anomaly report is generated; the cluster environment anomaly report is used to indicate the operation and maintenance of the nodes in the distributed cluster.

[0034] If the number of active nodes is greater than half the total number of nodes in the distributed cluster, a new master node is determined based on the running status indicators of each slave node in the distributed cluster, excluding the current master node.

[0035] In the address switching method provided in this application embodiment, when the number of active nodes in the distributed cluster is less than or equal to half of the total number of nodes in the distributed cluster, a cluster environment anomaly report is generated in a timely manner to trigger cluster node operation and maintenance, thereby preventing the spread of cluster failures; when the number of active nodes in the distributed cluster is greater than half of the total number of nodes in the distributed cluster, a new master node is determined to ensure that the election process of the new master node is carried out in a cluster availability environment, thereby improving the reliability of the new master node.

[0036] In one embodiment, the method further includes:

[0037] When the new master node is a slave node to which it belongs, the new master node is bound to the virtual network address of the distributed cluster. When the new master node is connected to the network, the address resolution protocol message is broadcast to refresh the master node address cached by each upper-layer device of the distributed cluster.

[0038] Monitor the running status of the new master node when it is not a slave node to which it belongs.

[0039] In the address switching method provided in this application embodiment, when the new master node is a slave node to which it belongs, the upper-layer device address cache is refreshed quickly by binding a virtual network address and broadcasting a message, ensuring that network requests inside and outside the distributed cluster are seamlessly switched to the new master node and guaranteeing network continuity during the master node switching process; when the new master node is not a slave node to which it belongs, the running status of the new master node is monitored to avoid service interruption caused by failure or abnormality of the new master node.

[0040] In one embodiment, the method further includes:

[0041] When the virtual network address is switched from the current master node to the new master node, a resource synchronization instruction is sent to the corresponding business layer system in the distributed cluster; the resource synchronization instruction is used to instruct the business layer system to send the business requests sent by the client to the new master node for processing.

[0042] In the address switching method provided in this application embodiment, when the virtual network address is switched from the current master node to the new master node, a resource synchronization instruction is sent to the corresponding business layer system in the distributed cluster to instruct the business layer system to send the business request sent by the client to the new master node for processing, so that the client can complete the processing of the client's business request without being aware of the change of the master node.

[0043] Secondly, this application also provides a distributed cluster system, which includes a master node and multiple slave nodes, and each node in the distributed cluster system is deployed with a distributed coordination service; each slave node in the distributed cluster calls the distributed coordination service process to execute the steps of the method in any of the embodiments of the first aspect above.

[0044] Thirdly, this application also provides an address switching device, comprising:

[0045] The status monitoring module is used to monitor the running status of the current master node in the distributed cluster;

[0046] The timing judgment module is used to determine whether the current master node's runtime has reached the preset switching cooldown period when the current master node's running state is abnormal.

[0047] The address switching module is used to determine a new master node based on the running status indicators of each slave node in the distributed cluster (excluding the current master node) if the current master node's runtime reaches the switching cooldown period, and to complete the switching of the virtual network address of the distributed cluster from the current master node to the new master node.

[0048] Fourthly, this application also provides a computer device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method in any of the embodiments of the first aspect described above.

[0049] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method in any of the embodiments of the first aspect described above.

[0050] In a sixth aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method in any of the embodiments of the first aspect described above.

[0051] The aforementioned address switching method, system, device, equipment, storage medium, and program product, based on the deployment of a distributed coordination service on each node in the distributed cluster, monitors the running status of the current master node by having each slave node in the distributed cluster call the distributed coordination service process. If the current master node is in an abnormal state, it determines whether the current master node's runtime has reached a preset switching cooldown period. Then, if the current master node's runtime has reached the switching cooldown period, a new master node is determined based on the running status indicators of all slave nodes in the distributed cluster (excluding the current master node), and the virtual network address of the distributed cluster is switched from the current master node to the new master node. In this method, each slave node in the distributed cluster calls the distributed coordination service process. If the current master node is in an abnormal state, it further determines whether the current master node's runtime has reached the switching cooldown period. If the switching cooldown period has been reached, a new master node is selected and its address is switched; otherwise, the current master node is not switched. This avoids frequent switching of the virtual network address of the distributed cluster, thus ensuring that the virtual network address of the distributed cluster can run relatively stably and persistently on the current master node, improving the service stability of the distributed cluster. Furthermore, when determining the new master node, the operating status indicators of each slave node are used as the basis. This makes the determined new master node more reliable and reasonable, so that the virtual network address can continue to run smoothly on the new master node after switching to it, thereby ensuring the service stability of the distributed cluster. Attached Figure Description

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

[0053] Figure 1 This is a schematic diagram of the architecture of a distributed cluster system in one embodiment;

[0054] Figure 2 This is a flowchart illustrating an address switching method in one embodiment;

[0055] Figure 3 This is a flowchart illustrating the steps for determining the master node status in one embodiment;

[0056] Figure 4 This is a flowchart illustrating the steps for determining a new master node in one embodiment;

[0057] Figure 5 This is a flowchart illustrating the steps for determining candidate master nodes in one embodiment;

[0058] Figure 6 This is a flowchart illustrating the steps for determining the cluster environment in one embodiment;

[0059] Figure 7 This is a schematic diagram illustrating the address switching process in a scenario where a new master node is determined, as shown in one embodiment.

[0060] Figure 8 This is a structural block diagram of an address switching device in one embodiment;

[0061] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0063] It should be noted that the terms "comprising" and "having," and any variations thereof, as used in this application, are intended to cover non-exclusive inclusion. The term "multiple" as used in this application refers to two or more. The term "and / or" as used in this application refers to one of the solutions, or any combination of multiple solutions.

[0064] Before describing the technical solution of this application, let me first explain the technical framework of this application:

[0065] A Virtual Internet Protocol Address (VIP) in a virtual network is a logical IP address that is not attached to a specific network interface card (NIC) or physical host. It is commonly used to achieve load balancing, high availability failover, and service takeover across multiple nodes. VIPs typically ensure service availability by dynamically binding and unbinding them from backend service nodes. For example, in a high-availability system, when the primary node fails, a transparent switchover can be achieved by quickly transferring the VIP to a new available node, ensuring uninterrupted client access. Especially in multi-node cluster systems, the dynamic migration mechanism of VIPs is crucial for achieving "automatic primary / standby failover" or "active-passive hot standby." Therefore, how to achieve precise control and efficient migration of VIPs without interrupting business operations has become a core challenge in high-availability architectures.

[0066] Existing open-source distributed coordination frameworks possess capabilities such as distributed locks, leader election mechanisms, configuration management, and naming services, and are commonly used to build distributed systems with consistency guarantees. These frameworks employ a leader-follower architecture, using broadcast protocols to ensure strong consistency; all write operations can only be initiated by the leader. In distributed cluster systems, multiple service instances often need to share certain state information or make consistent decisions under certain conditions, such as leader election, service registration, and configuration change notifications. The data node mechanism and real-time node data change awareness mechanism provided by these open-source distributed coordination frameworks allow clients to perform lightweight yet reliable collaboration through methods such as creating ephemeral nodes and real-time awareness.

[0067] Currently, in actual production environments, to achieve high availability of service IPs, open-source distributed coordination frameworks are typically used as coordination components, combined with a VIP mechanism to build a master-slave cluster architecture. The basic process is as follows: each node registers a temporary ordered node on the distributed coordination service, which automatically selects the node with the smallest number as the master node. The master node provides services after binding to the VIP, while other nodes remain in a listening state. If the master node fails (e.g., process crash, network interruption), its temporary node in the distributed coordination service disappears. Slave nodes detect the change and re-participate in the master election. The new master node takes over the VIP, achieving service migration. Existing technical solutions have advantages such as simple implementation, few dependencies, and fast response speed, and are widely used in small to medium-sized container clusters and distributed service control components. However, this mechanism also has at least the following problems:

[0068] (1) The health judgment mechanism is too crude. Traditional solutions judge the node status by whether the temporary nodes registered on the distributed coordination service are alive or not, relying on session timeout. However, if the production environment is in a certain fault state, such as high CPU load, reduced disk I / O capability, or abnormal network card packet loss, the ZooKeeper session may still be maintained, which will cause the system to fail to recognize that the node has lost its business processing capability.

[0069] (2) Inability to dynamically evaluate node quality. In the master selection logic of existing technologies, all healthy slave nodes are treated equally, lacking a performance-based selection strategy. For example, a node with extremely slow response but not disconnected may be wrongly selected as the master, thus binding the VIP and causing external requests to be blocked.

[0070] (3) It is easy to cause "false primary switch" or "frequent jitter". If a switching cooling mechanism is not set, when the network jitters for a short time or the resource load fluctuates instantaneously, the primary switch may be repeatedly triggered, resulting in a decrease in service stability.

[0071] In summary, while existing VIP failover solutions initially possess the capability for rapid master switchover, there is still significant room for improvement in areas such as refined operation and maintenance, service quality awareness, and high availability assurance. Therefore, this application provides a more intelligent and robust address failover method that can sense the node's operational status and dynamically adjust the master switchover logic, thereby enhancing the stability and reliability of virtual addresses.

[0072] The address switching method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown. Figure 1 This is a schematic diagram of a distributed cluster system. The distributed cluster system includes one master node and multiple slave nodes. Each node in the distributed cluster system is deployed with a distributed coordination service. Each slave node in the distributed cluster calls the distributed coordination service process to perform the following steps: monitor the running status of the current master node in the distributed cluster; if the running status of the current master node is abnormal, determine whether the running time of the current master node has reached the preset switching cooldown period; if the running time of the current master node has reached the switching cooldown period, determine the new master node based on the running status index data of each slave node in the distributed cluster other than the current master node, and complete the switching of the virtual network address of the distributed cluster from the current master node to the new master node.

[0073] In one exemplary embodiment, such as Figure 2 As shown, an address switching method is provided, applied to the distributed coordination service process in any slave node of a distributed cluster, where each node in the distributed cluster has a distributed coordination service deployed. The method includes the following steps:

[0074] S201 monitors the current running status of the master node in the distributed cluster.

[0075] A distributed cluster consists of one master node and multiple slave nodes. Each node is equipped with a distributed coordination service. The distributed coordination service on each node in the distributed cluster synchronizes messages and allows each node to obtain the status information of other nodes in the distributed cluster except itself.

[0076] When the distributed cluster is in operation, the current master node reports its running status to the distributed coordination service it has deployed. The distributed coordination services deployed on each node in the distributed cluster synchronize the running status of the current master node to the status maintenance table of their respective nodes. In this case, the slave nodes in the distributed cluster can determine the running status of the current master node from the status maintenance table.

[0077] In another application scenario, the running status is determined by the slave node based on multiple running status indicators reported by the current master node. In this case, the slave node can call the distributed coordination service process to compare the multiple running status indicators of the current master node with the corresponding status indicator thresholds, and determine the running status of the current master node based on the comparison results.

[0078] S202, if the current master node is in an abnormal running state, determine whether the current master node's running time has reached the preset switching cooldown period.

[0079] The switching cooldown period refers to the lower limit of the interval for switching master nodes in a distributed cluster. It is preset before the distributed cluster system runs, such as 600 seconds or 1200 seconds.

[0080] If the current master node is in an abnormal running state, obtain the time when the current master node is bound to the virtual network address as the current master node's runtime, and compare the current master node's runtime with the preset switching cooldown period. If the runtime is greater than the switching cooldown period, then proceed to the master election step. If the runtime is less than or equal to the switching cooldown period, continue to wait until the current master node's runtime reaches the switching cooldown period, and then proceed to the next master election step.

[0081] It should be noted that if the current master node is running normally, it means that there is no need to switch the master node, and therefore no need to determine the current master node's runtime. Instead, the slave node continues to monitor the current master node's running status.

[0082] S203, if the current master node's runtime reaches the switching cooldown period, then a new master node is determined based on the running status index data of each slave node in the distributed cluster other than the current master node, and the virtual network address of the distributed cluster is switched from the current master node to the new master node.

[0083] If the current master node is in an abnormal state and the current master node's runtime reaches the switching cooldown period, a strategy for determining a new master node is executed. In this embodiment, the stability of each slave node is quantitatively evaluated based on the running status index data of each slave node in the distributed cluster other than the current master node, and the most stable slave node is determined as the new master node. Then, the virtual network address is switched from the current master node to the new master node.

[0084] In this embodiment, based on the deployment of a distributed coordination service on each node of the distributed cluster, each slave node in the distributed cluster calls the distributed coordination service process to monitor the running status of the current master node in the distributed cluster. If the current master node's running status is abnormal, it determines whether the current master node's runtime has reached a preset switching cooldown period. Then, if the current master node's runtime has reached the switching cooldown period, a new master node is determined based on the running status indicators of all slave nodes in the distributed cluster except the current master node, and the virtual network address of the distributed cluster is switched from the current master node to the new master node. In this method, each slave node in the distributed cluster calls the distributed coordination service process. If the current master node is in an abnormal state, it further determines whether the current master node's runtime has reached the switching cooldown period. If the switching cooldown period has been reached, a new master node is selected and its address is switched; otherwise, the current master node is not switched. This avoids frequent switching of the virtual network address of the distributed cluster, thus ensuring that the virtual network address of the distributed cluster can run relatively stably and persistently on the current master node, improving the service stability of the distributed cluster. Furthermore, when determining the new master node, the operating status indicators of each slave node are used as the basis. This makes the determined new master node more reliable and reasonable, so that the virtual network address can continue to run smoothly on the new master node after switching to it, thereby ensuring the service stability of the distributed cluster.

[0085] In an exemplary embodiment, one possible implementation of the aforementioned step S201, "monitoring the running status of the current master node in the distributed cluster," is described, such as... Figure 3 As shown, it includes the following steps:

[0086] S301 collects multiple different types of operating status indicators of the current master node according to the preset sampling period.

[0087] Among them, the operational status indicators refer to key metrics related to the operational status of the master node, including CPU utilization, disk I / O latency, network latency, packet loss rate, HTTP interface return timeouts or status code operations, etc. In this embodiment of the application, when collecting multiple different types of operational status indicators of the master node, the sampling period for each slave node can be the same or different, and the sampling period can be configured to be in the range of 5 seconds to 10 seconds.

[0088] S302, if multiple different types of operating status indicators of the current master node are all less than or equal to the corresponding indicator thresholds, then the operating status of the current master node is determined to be normal.

[0089] Taking the operating status indicators, including CPU utilization, disk I / O latency, and packet loss rate, as an example, if the current master node's CPU utilization does not exceed the CPU utilization threshold (e.g., 90%), the disk I / O latency does not exceed the set latency threshold, and the packet loss rate is less than the preset packet loss rate threshold, then the current master node's operating status is determined to be normal.

[0090] S303, if the current master node's operating status indicator data of any type is greater than the corresponding indicator threshold, and the abnormal frequency of the operating status indicator data exceeds the preset frequency threshold, then the current master node's operating status is determined to be abnormal.

[0091] If any type of operational status indicator data of the current master node is greater than the corresponding indicator threshold, it can be preliminarily determined that the current master node is initially abnormal. Further, the abnormal frequency of the current master node is judged. If the abnormal frequency of the operational status indicator data exceeds the preset frequency threshold, the operational status of the current master node is determined to be abnormal.

[0092] Continuing with the example of operational status indicators including CPU utilization, disk I / O latency, and packet loss rate, if the current master node's CPU utilization exceeds the CPU utilization threshold (e.g., 90%), or the disk I / O latency does not exceed the set latency threshold, or the packet loss rate is less than the preset packet loss rate threshold, then the abnormal frequency of the current master node is further judged. If the abnormal frequency of the operational status indicator data exceeds the preset frequency threshold, such as the number of consecutive CPU abnormalities being greater than or equal to 3, or two network jitters occurring within 10 seconds, then the current master node's operational status is determined to be abnormal.

[0093] In practical applications, it is also possible that the current master node's operational status metric data of any type is greater than the corresponding metric threshold, but the abnormal frequency of the operational status metric data does not exceed the preset frequency threshold. In this scenario, the current master node's operational status is determined to be a fluctuating state, which does not meet the conditions for switching masters in a distributed cluster.

[0094] In this embodiment, multiple different types of operating status indicators of the master node are collected according to a preset sampling period. Based on the comparison results of the operating status indicators with the corresponding indicator thresholds, and combined with whether the abnormal frequency exceeds the preset threshold, the current operating status of the master node is comprehensively determined, thereby realizing accurate and dynamic monitoring of the operating status of the master node.

[0095] If the current master node is in an abnormal state, and its runtime meets the switchover cooldown period, it means the distributed cluster has met the master-switching timeframe. Therefore, a new master node can be determined, and subsequent master-switching operations can be performed. In an exemplary embodiment, such as... Figure 4 As shown, the process of determining a new master node based on the operational status metrics of all slave nodes in the distributed cluster, excluding the current master node, includes the following steps:

[0096] S401 retrieves multiple running status indicator data from the storage tables of the distributed cluster, excluding the current master node.

[0097] The storage table includes operational status metrics reported by each node in the distributed cluster. In this embodiment, all nodes in the distributed cluster jointly maintain a storage table, and each node can read data from the storage table.

[0098] Each slave node reads multiple running status indicator data from the storage table of all slave nodes (including itself) except the current master node.

[0099] S402, according to the preset index weights, the multiple operating status index data of each slave node are weighted to obtain the status quantification value of each slave node; the status quantification value of each slave node represents the degree of association between each slave node and the new master node.

[0100] For any slave node, the multiple operational status indicators of the slave node are normalized, and then the multiple operational status indicators of the slave node are weighted and summed according to the preset indicator weights to determine the state quantification value of the slave node.

[0101] Before weighting the multiple operational status metrics of each slave node, the operational status of each slave node can be evaluated based on these metrics, filtering out slave nodes in abnormal states to reduce the computational burden of determining a new master node. The method for obtaining the operational status of each slave node can be found in the master node's operational status acquisition method described in the previous embodiments, and will not be repeated here.

[0102] S403: Determine the candidate master node based on the status quantization value of each slave node, and report the candidate master node to the storage table.

[0103] Optionally, the state quantization values ​​of each slave node are sorted, and the slave node with the largest state quantization value is determined as a candidate master node and then reported to the storage table.

[0104] Optionally, from each slave node, a set of backup nodes whose state quantization value is greater than the preset state quantization threshold is selected, and any slave node in the backup node set is determined as a candidate master node and reported to the storage table.

[0105] It is important to emphasize that the storage table includes candidate master nodes reported by each slave node. Due to the differences between different slave nodes in the distributed cluster, the strategy for determining candidate master nodes and the time for reporting candidate master nodes will also differ. Therefore, the reporting time of each candidate master node in the storage table is also different.

[0106] S404 determines the new master node based on the reporting time of each candidate master node in the storage table.

[0107] Considering the timeliness of information reported by each slave node, the reporting time of each candidate master node is compared to determine the latest reporting time, and the candidate master node corresponding to the latest reporting time is determined as the new master node.

[0108] In this embodiment, the running status of each slave node is quantitatively analyzed by combining preset weights and the running status index data of each slave node to determine the candidate master node, ensuring a high correlation between the candidate master node and the new master node, and finally selecting the new master node based on the reporting time, thus ensuring the timeliness and orderliness of the election of the new master node and improving the efficiency of automatic switching when the master node of the distributed cluster is abnormal.

[0109] As can be seen from the foregoing embodiments, when selecting a new master node, unlike the related technologies where the first to detect a master node anomaly registers as the new master node, this embodiment determines candidate master nodes based on multiple operational status indicators of each slave node. The new master node is then selected from these candidate master nodes to ensure its suitability. Therefore, the candidate master nodes determined by each slave node are crucial for determining the new master node. Based on this, the feasible methods for slave nodes to determine candidate master nodes are described below.

[0110] In one exemplary embodiment, such as Figure 5 As shown, the candidate master node is determined based on the state quantization values ​​of each slave node, including the following steps:

[0111] S501, sort the state quantization values ​​of each slave node to obtain the slave node sequence corresponding to each slave node.

[0112] To reiterate, the state quantization value of each slave node is positively correlated with its probability of becoming the new master node. That is, the larger the state quantization value of a slave node, the greater its probability of becoming the new master node; conversely, the smaller the state quantization value, the smaller its probability of becoming the new master node. Based on this, the state quantization values ​​of each slave node are sorted in descending order to obtain a sequence of slave nodes.

[0113] S502, based on the slave node sequence of each slave node, determines the candidate master node from each slave node.

[0114] The first slave node in the slave node sequence of each slave node is determined as the candidate master node, or the backup nodes in the slave node sequence are selected according to a preset ratio, and one of the selected backup nodes is randomly selected as the candidate master node.

[0115] In this embodiment, the state quantization values ​​of each slave node are sorted to obtain the slave node sequence corresponding to each slave node, so as to intuitively distinguish the state of each slave node. Then, based on this, candidate master nodes are determined from each slave node. The entire determination process is logically clear and based on reliable evidence, and is suitable for distributed cluster systems.

[0116] In an exemplary embodiment, determining a candidate master node from among the slave nodes based on the slave node sequence of each slave node includes:

[0117] Based on the slave node sequence of each slave node, standby nodes with state quantization values ​​greater than the preset state quantization threshold are selected from each slave node; the historical failure rate of each standby node is obtained from the storage table; and the standby node corresponding to the minimum historical failure rate is determined as the candidate master node.

[0118] The storage table includes the historical failure rate of each node in the distributed cluster. The historical failure rate of each node is the ratio between the number of historical failures of that node and a preset failure threshold, which can be the maximum number of historical failures of all nodes in the distributed cluster.

[0119] Based on the slave node sequence of each slave node, standby nodes with state quantization values ​​greater than the preset state quantization threshold are selected from each slave node. Based on the identifier of the standby node, the historical failure rate of each standby node is obtained from the storage table. The historical failure rates of each standby node are compared to determine the minimum historical failure rate. The standby node corresponding to the minimum historical failure rate is determined as the candidate master node.

[0120] In this embodiment, based on the slave node sequence of each slave node, standby nodes with state quantization values ​​greater than a preset state quantization threshold are selected from each slave node to ensure the reliability of the current performance of the standby nodes. Then, based on the historical failure rate of each standby node, the risk of future failure of each standby node is assessed. The candidate master nodes determined in this way have the characteristics of reliable performance and low failure probability, providing a reliable basis for the subsequent determination of new master nodes.

[0121] Before determining a new master node, the overall environment of the distributed cluster can be pre-assessed, and the master node switching environment can be further verified to ensure the smooth progress of subsequent master node selection and switching steps. In an exemplary embodiment, such as... Figure 6 As shown, before determining the new master node based on the running status indicator data of each slave node in the distributed cluster other than the current master node, the method further includes:

[0122] S601, retrieves the number of active nodes in the distributed cluster.

[0123] Active nodes are nodes that are running in the distributed cluster.

[0124] In a distributed cluster system, active nodes are the effective nodes that ensure the normal operation of the cluster. Their number and status determine the cluster's processing capacity, fault tolerance, and stability.

[0125] Optionally, each slave node in the distributed cluster sends a heartbeat packet to the current master node, and the current master node maintains a slave node status table. In this case, the slave nodes can read the active nodes in the running state from the node status table maintained by the current master node and count the number of active nodes.

[0126] S602: If the number of active nodes is less than or equal to half the total number of nodes in the distributed cluster, a cluster environment anomaly report will be generated.

[0127] Among them, the cluster environment anomaly report is used to indicate the operation and maintenance of nodes in the distributed cluster.

[0128] If the number of active nodes is less than or equal to half the total number of nodes in the distributed cluster, it indicates that the distributed cluster is in a high-risk operating state. At this time, the data consistency and cluster availability of the distributed cluster will be greatly reduced. In this case, the operation of electing a master node will not be performed. Instead, a cluster environment anomaly report will be generated to indicate that the nodes of the distributed cluster should be maintained and repaired in a timely manner to ensure the overall availability of the distributed cluster.

[0129] S603: If the number of active nodes is greater than half the total number of nodes in the distributed cluster, then a new master node is determined based on the running status indicators of each slave node in the distributed cluster, excluding the current master node.

[0130] If the number of active nodes is greater than half the total number of nodes in the distributed cluster, it indicates that the distributed cluster is in a high-availability state. At this time, the step of determining a new master node is executed. The implementation method can be found in the description of the new master node determination step in the above embodiment, and will not be repeated here.

[0131] It should be understood that, in this embodiment of the application, comparing half of the total number of nodes in the distributed cluster with the number of active nodes is merely an illustration. In actual application scenarios, one can also compare half of the total number of nodes in the distributed cluster plus 1 with the number of active nodes, or compare three-quarters of the total number of nodes in the distributed cluster with the number of active nodes, etc.

[0132] In this embodiment, when the number of active nodes in the distributed cluster is less than or equal to half the total number of nodes in the distributed cluster, a cluster environment anomaly report is generated in a timely manner to trigger cluster node operation and maintenance, thus preventing the spread of cluster failures; when the number of active nodes in the distributed cluster is greater than half the total number of nodes in the distributed cluster, a new master node is determined to ensure that the election process of the new master node is carried out in a cluster availability environment, thereby improving the reliability of the new master node.

[0133] Next, in the scenario of determining a new master node, the execution strategy for each slave node in the distributed cluster will be explained. In an exemplary embodiment, such as... Figure 7 As shown, the method also includes:

[0134] S701, when the new master node is a slave node to which it belongs, binds the new master node to the virtual network address of the distributed cluster, and broadcasts address resolution protocol messages when the new master node is connected to the network, so as to refresh the master node address cached by each upper-layer device of the distributed cluster.

[0135] The new master node, acting as its own slave node, binds its virtual network address to its physical network interface. This allows the new node to receive and process network requests from clients through this virtual address. Furthermore, when the new master node is network-connected, it broadcasts Address Resolution Protocol (ARP) messages to all upper-layer devices in the distributed cluster, instructing them to update their cached mappings between virtual network addresses and historical master nodes to the mappings between virtual network addresses and the new master node.

[0136] S702 monitors the running status of the new master node when the new master node is not a slave node to which it belongs.

[0137] If the new master node is not a slave node to which it belongs, the new master node will perform the virtual network address binding step and broadcast address resolution protocol messages. Slave nodes that are not the new master node will continue to monitor the new master node's operational status.

[0138] In this embodiment, when the new master node is a slave node to which it belongs, the upper-layer device address cache is refreshed quickly by binding a virtual network address and broadcasting messages, ensuring that network requests inside and outside the distributed cluster are seamlessly switched to the new master node and guaranteeing network continuity during the master node switching process; when the new master node is not a slave node to which it belongs, the running status of the new master node is monitored to avoid service interruption caused by failure or abnormality of the new master node.

[0139] In one exemplary embodiment, the method further includes:

[0140] When the virtual network address is switched from the current master node to the new master node, a resource synchronization instruction is sent to the corresponding business layer system in the distributed cluster; the resource synchronization instruction is used to instruct the business layer system to send the business requests sent by the client to the new master node for processing.

[0141] The business layer system serves as an intermediary between the distributed cluster and the client. It stores the mapping relationship between virtual network addresses (logical addresses) and master node addresses (physical addresses) and is responsible for forwarding the client's business requests to the master node of the distributed cluster.

[0142] When the virtual network address is switched from the current master node to the new master node, a resource synchronization instruction is sent to the corresponding business layer system in the distributed cluster to inform the business layer system that the master node has been changed and all client business requests need to be transferred to the new master node for processing.

[0143] In this embodiment of the application, when the virtual network address is switched from the current master node to the new master node, a resource synchronization instruction is sent to the corresponding business layer system in the distributed cluster to instruct the business layer system to send the business requests sent by the client to the new master node for processing, so that the client can complete the processing of the client's business requests without being aware of the change of the master node.

[0144] In one exemplary embodiment, an address switching method is provided, applied to a slave node of a distributed cluster, comprising the following steps:

[0145] (1) Sample multiple different types of operating status indicators of the current master node according to the preset sampling period.

[0146] Different types of operational status indicators include, but are not limited to: CPU utilization (e.g., exceeding 90% is abnormal), disk I / O latency (IO wait time exceeds a set threshold), network connectivity (e.g., ping gateway latency, packet loss rate), and local service response status (e.g., HTTP interface return timeout, status code error, etc.).

[0147] The sampling results of the running status indicators are recorded in the local cache, and the statistical results are periodically synchronized to a unified path so that each slave node can obtain the running status of each node in a unified manner.

[0148] (2) If the data of any type of operating status indicator of the current master node is greater than the corresponding indicator threshold, the current master node is initially abnormal, and the abnormal frequency of the current master node is further judged to see if it exceeds the preset frequency threshold. The operating status of the current master node is determined according to the judgment result.

[0149] To avoid misleading judgments due to occasional interference, methods such as sliding window averaging and accumulating the number of anomalies are used to determine trends. For example, only then can a node be identified as being in an abnormal state.

[0150] For example, determining whether the abnormal frequency of the current master node exceeds a preset frequency threshold includes: if a certain indicator exceeds the abnormal threshold in three consecutive rounds of detection; or judging the fault count threshold, such as CPU abnormality lasting ≥3 times; or abnormal detection period window, such as network jitter occurring ≥2 times within 10 seconds.

[0151] (3) If the current master node is in an abnormal state, determine whether the current master node has reached the preset switching cooldown period.

[0152] For example, after the current master node successfully switches to master, it must wait at least 600 seconds before participating in the next round of master election.

[0153] (4) Environmental secondary confirmation mechanism.

[0154] If the current master node is in an abnormal state and the switchover cooldown period has expired, the switchover will not be initiated immediately. Instead, a "secondary confirmation" process will begin. The main objective of this stage is to prevent further system crashes caused by blindly switching over when the cluster is under resource pressure or in a degraded state. The check logic can be: the number of active nodes in the cluster is no less than half + 1. If the above check fails, the cluster system will postpone the master switchover, record diagnostic information, and output an error log for administrator processing, and then perform another check and switchover in the next cycle.

[0155] (5) Candidate slave node selection and optimization logic.

[0156] Once the aforementioned conditions are met, the system officially enters the master node election phase. At this time, each slave node pulls all node status indicator data and selects a new master node based on the scoring strategy.

[0157] The scoring method can be based on a multi-index weighted method. When multiple slave nodes have similar scores, the one with the lower historical failure rate is selected as the candidate master node and registered. Then, the new master node is determined according to the registration time of multiple candidate master nodes.

[0158] (6) Main control and business avoidance strategy.

[0159] To avoid service interruptions or conflicts, the system adopts a "business avoidance + VIP sequential migration" strategy, including the following:

[0160] The new master node pre-binds the VIP: The new master node executes the virtual network address binding command and checks network connectivity; if the network is connected, it broadcasts ARP packets to refresh the address cache of upstream routers or switches; and the old master node confirms its resignation: upon detecting the master-slave status change, the old master immediately performs the unbinding operation. It should be noted that the entire process must avoid the risk of dual-master binding, ensuring that the VIP exists on only one node at any given time.

[0161] (7) Synchronization and steady-state maintenance after the master is cut off.

[0162] After the master switch is completed, the cluster system will enter a new steady-state period. During this period, the new master node will update its running status every 5-10 seconds and maintain its validity through heartbeat packets. Slave nodes will listen to the master node to determine its status. If the master node enters an abnormal state again, the above process will be repeated. After each successful master switch, the system will record the operation log and may notify the business layer system to complete resource synchronization.

[0163] In this embodiment, a fault diagnosis mechanism is used to improve the high availability of the cluster's master node, ensuring the VIP remains in a relatively stable state and significantly reducing service interruptions caused by nodes in a "falsely active" state. This offers at least the following advantages: ① A master node election exclusive mechanism based on runtime data scoring. Unlike traditional first-come-first-served or lowest-order-first-served models, this embodiment introduces a health threshold filter before nodes participate in the election and supports active withdrawal, ensuring only nodes in good condition participate in the election, improving the rationality of the election and service quality. ② A fault-triggered two-stage confirmation mechanism to avoid erroneous master switchover and service avalanche: This invention introduces a "fault threshold + environment confirmation" two-stage judgment strategy in the master node fault judgment process. Master-slave switching only occurs after a certain degree of abnormal persistence and confirmation that the cluster as a whole is in a stable state. This avoids the problem of frequent switching due to misjudgment or slight fluctuations in traditional solutions, effectively preventing service avalanche or cascading failures. ③ A layered fault-tolerant architecture that coordinates VIP high availability with distributed coordination service process high availability. A layered fault-tolerant architecture was constructed. Master node election is based on a distributed coordination service process to ensure consistency, while node health monitoring and VIP control modules achieve collaborative fault control. Even in the event of node failure or partitioning, limited autonomy and state maintenance can still be achieved among nodes, enhancing system resilience. By introducing a mechanism of "proactive health detection + anomaly diagnosis + intelligent master election," a more stable and intelligent VIP high-availability solution was built.

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

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

[0166] In one exemplary embodiment, such as Figure 8 As shown, an address switching device is provided, including: a status monitoring module 801, a timing judgment module 802, and an address switching module 803, wherein:

[0167] The status monitoring module 801 is used to monitor the running status of the current master node in the distributed cluster.

[0168] The timing judgment module 802 is used to determine whether the running time of the current master node has reached the preset switching cooldown cycle when the current master node's running state is abnormal.

[0169] The address switching module 803 is used to determine a new master node based on the running status index data of each slave node in the distributed cluster other than the current master node if the running time of the current master node reaches the switching cooldown period, and to complete the switching of the virtual network address of the distributed cluster from the current master node to the new master node.

[0170] In an exemplary embodiment, the status monitoring module 801 includes: an indicator sampling unit, a first determination unit, and a second determination unit, wherein:

[0171] The indicator sampling unit is used to collect multiple different types of operational status indicator data of the current master node according to a preset sampling period;

[0172] The first determining unit is used to determine the current master node's operating status as normal if multiple different types of operating status indicator data of the current master node are all less than or equal to the corresponding indicator threshold.

[0173] The second determining unit is used to determine that the current master node's operating status is abnormal if any type of operating status indicator data is greater than the corresponding indicator threshold and the abnormal frequency of the operating status indicator data exceeds a preset frequency threshold.

[0174] In an exemplary embodiment, the address switching module 803 includes: a data reading unit, a quantization value calculation unit, a node reporting unit, and a node determination unit, wherein:

[0175] The data reading unit is used to retrieve multiple running status indicator data of each slave node other than the current master node from the storage table of the distributed cluster; the storage table includes running status indicator data reported by each node in the distributed cluster.

[0176] The quantization value calculation unit is used to perform weighted processing on multiple operating status indicator data of each slave node according to preset indicator weights to obtain the status quantization value of each slave node; the status quantization value of each slave node represents the degree of association between each slave node and the new master node;

[0177] The node reporting unit is used to determine the candidate master node based on the status quantization value of each slave node, and report the candidate master node to the storage table;

[0178] The node determination unit is used to determine the new master node based on the reporting time of each candidate master node in the storage table.

[0179] In an exemplary embodiment, the node reporting unit includes: a node sorting subunit and a master node determination subunit, wherein:

[0180] The node sorting subunit is used to sort the state quantization values ​​of each slave node to obtain the slave node sequence corresponding to each slave node.

[0181] The master node determines the sub-unit, which is used to determine the candidate master node from each slave node based on the slave node sequence of each slave node.

[0182] In an exemplary embodiment, the master node determining subunit is further configured to: based on the slave node sequence of each slave node, select standby nodes from each slave node whose state quantization value is greater than a preset state quantization threshold; obtain the historical failure rate of each standby node from the storage table; the storage table includes the historical failure rate of each node in the distributed cluster; and determine the standby node corresponding to the minimum historical failure rate as a candidate master node.

[0183] In one exemplary embodiment, the address switching device further includes: a quantity determination module, a report generation module, and a cluster master election module, wherein:

[0184] The quantity determination module is used to obtain the number of active nodes in the distributed cluster; active nodes are nodes in the distributed cluster that are in a running state.

[0185] The report generation module generates a cluster environment anomaly report if the number of active nodes is less than or equal to half the total number of nodes in the distributed cluster. The cluster environment anomaly report is used to indicate the maintenance of the nodes in the distributed cluster.

[0186] The cluster master selection module is used to determine a new master node based on the running status indicators of each slave node in the distributed cluster, excluding the current master node, if the number of active nodes is greater than half the total number of nodes in the distributed cluster.

[0187] In one exemplary embodiment, the address switching device further includes: an address binding module and a new node monitoring module, wherein:

[0188] The address binding module is used to bind the new master node to the virtual network address of the distributed cluster when the new master node is its own slave node, and broadcast address resolution protocol messages when the new master node is connected to the network to refresh the master node address cached by each upper-layer device of the distributed cluster.

[0189] The new node monitoring module is used to monitor the running status of the new master node when it is not a slave node to which it belongs.

[0190] In an exemplary embodiment, the address switching device further includes: a resource synchronization module, configured to send a resource synchronization instruction to the corresponding business layer system in the distributed cluster when the virtual network address is switched from the current master node to the new master node; the resource synchronization instruction is used to instruct the business layer system to send the business request sent by the client to the new master node for processing.

[0191] Each module in the aforementioned address switching device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0192] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores address switching data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements an address switching method.

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

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

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

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

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

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

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

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

Claims

1. An address switching method, characterized in that, A distributed coordination service process applied to any slave node in a distributed cluster, wherein the distributed coordination service is deployed on each node of the distributed cluster; the method includes: Monitor the running status of the current master node in the distributed cluster; If the current master node is in an abnormal running state, determine whether the running time of the current master node has reached the preset switching cooldown period. If the runtime of the current master node reaches the switching cooldown period, a new master node is determined based on the running status index data of each slave node in the distributed cluster other than the current master node, and the virtual network address of the distributed cluster is switched from the current master node to the new master node.

2. The method according to claim 1, characterized in that, Monitoring the running status of the current master node in the distributed cluster includes: According to the preset sampling period, collect multiple different types of operating status indicator data of the current master node; If multiple different types of operating status indicator data of the current master node are all less than or equal to the corresponding indicator threshold, then the operating status of the current master node is determined to be normal. If any type of operating status indicator data of the current master node is greater than the corresponding indicator threshold, and the abnormal frequency of the operating status indicator data exceeds a preset frequency threshold, then the operating status of the current master node is determined to be abnormal.

3. The method according to claim 1 or 2, characterized in that, The step of determining a new master node based on the operational status indicator data of each slave node in the distributed cluster, excluding the current master node, includes: Obtain multiple operational status indicator data of each slave node other than the current master node from the storage table of the distributed cluster; the storage table includes operational status indicator data reported by each node in the distributed cluster. According to the preset index weights, the multiple operating status index data of each slave node are weighted to obtain the state quantification value of each slave node; the state quantification value of each slave node represents the degree of association between each slave node and the new master node; Candidate master nodes are determined based on the state quantization values ​​of each slave node, and the candidate master nodes are reported to the storage table; The new master node is determined based on the reporting time of each candidate master node in the storage table.

4. The method according to claim 3, characterized in that, The step of determining candidate master nodes based on the state quantization values ​​of each slave node includes: The state quantization values ​​of each slave node are sorted to obtain the slave node sequence corresponding to each slave node. Based on the slave node sequence of each slave node, the candidate master node is determined from each slave node.

5. The method according to claim 4, characterized in that, The step of determining the candidate master node from the slave nodes based on the slave node sequence of each slave node includes: Based on the slave node sequence of each slave node, standby nodes with state quantization values ​​greater than a preset state quantization threshold are selected from each slave node. The historical failure rate of each of the backup nodes is obtained from the storage table; the storage table includes the historical failure rate of each node in the distributed cluster. The standby node corresponding to the lowest historical failure rate is determined as the candidate master node.

6. The method according to claim 1 or 2, characterized in that, Before determining the new master node based on the running status indicator data of each slave node in the distributed cluster other than the current master node, the method further includes: Obtain the number of active nodes in the distributed cluster; the active nodes are the nodes in the distributed cluster that are in a running state. If the number of active nodes is less than or equal to half the total number of nodes in the distributed cluster, a cluster environment anomaly report is generated; the cluster environment anomaly report is used to indicate the operation and maintenance of the nodes in the distributed cluster. If the number of active nodes is greater than half the total number of nodes in the distributed cluster, a new master node is determined based on the running status index data of each slave node in the distributed cluster, excluding the current master node.

7. The method according to claim 1 or 2, characterized in that, The method further includes: When the new master node is a slave node to which it belongs, the new master node is bound to the virtual network address of the distributed cluster, and when the new master node is connected to the network, an address resolution protocol message is broadcast to refresh the master node address cached by each upper-layer device corresponding to the distributed cluster. If the new master node is not a slave node to which it belongs, monitor the running status of the new master node.

8. The method according to claim 1 or 2, characterized in that, The method further includes: When the virtual network address is switched from the current master node to the new master node, a resource synchronization instruction is sent to the corresponding business layer system in the distributed cluster; the resource synchronization instruction is used to instruct the business layer system to send the business request sent by the client to the new master node for processing.

9. A distributed cluster system, characterized in that, The distributed cluster system includes a master node and multiple slave nodes, and each node in the distributed cluster system is deployed with a distributed coordination service; each slave node in the distributed cluster calls the distributed coordination service process to execute the steps of the method according to any one of claims 1 to 8.

10. An address switching device, characterized in that, The device includes: The status monitoring module is used to monitor the running status of the current master node in the distributed cluster; The timing judgment module is used to determine whether the running time of the current master node has reached the preset switching cooldown cycle when the current master node's running state is abnormal. The address switching module is used to determine a new master node based on the running status index data of each slave node in the distributed cluster other than the current master node if the runtime of the current master node reaches the switching cooldown period, and to complete the switching of the virtual network address of the distributed cluster from the current master node to the new master node.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images