Real-time consistency method for swarm robots under unreliable network conditions

Abstract

The application relates to the technical field of distributed cluster, and discloses a real-time consistency method for a cluster robot under unreliable network conditions, which comprises the following steps: designing a Learner state node, sending a data request to a contactable Follower node, and adapting to a non-complete network topology structure; optimizing a log organization structure, uniquely identifying the log through a time stamp and a Leader node ID; designing two levels of node priority, dynamically updating the first priority according to the node log size and the new and old degree of the recent log time stamp, and globally uniquely configuring the second priority when the cluster starts; designing a partition merging process, and designing the merging process between partitions and the log synchronization process between partitions; and solving the problem of the cluster external service during partition merging through a joint Leader consensus method. Compared with the prior art, the application mainly aims at and solves the problems of master selection and data consistency in the cluster partition under the conditions of network partition and flash interruption.

Description

Technical Field

[0001] This invention relates to the field of distributed cluster technology, specifically a real-time consistency method for cluster robots under unreliable network conditions. Background Technology

[0002] In a distributed cluster system, each node in the cluster interacts with data information through the cluster network to achieve data synchronization and collaborative control. To ensure data and state consistency among all nodes in the cluster, reasonable election rules are typically set to ensure that there is one and only one Leader node in the cluster at any given time, which manages the cluster uniformly. Currently, mainstream distributed consensus algorithms, including Raft and Paxos, use voting during the election process, which can lead to issues such as vote splitting and is difficult to handle network partitions. Specifically, when a network partition occurs, if the number of nodes in the partition is less than half the cluster size, the nodes in the partition will be unable to elect a Leader, rendering the partition unusable. The voting-based election process also suffers from vote splitting, resulting in low election efficiency. While algorithms that pre-set priorities, such as the Bully algorithm, can solve the election problem under network partitions, the priorities set before the cluster runs cannot reflect the log load of the nodes during runtime, thus the election cannot guarantee that the elected Leader has the latest logs and state.

[0003] Meanwhile, in unreliable networks where communication topologies frequently fluctuate, there is a lack of consensus methods to ensure that the cluster can continue to provide services normally during network merging. Currently, there is still a lack of consensus algorithms that can adapt to situations where connectivity is not fully realized. Summary of the Invention

[0004] To address the aforementioned problems, this invention provides a real-time consistency algorithm for cluster robots under unreliable network conditions. This algorithm ensures that when the network experiences partitioning or intermittent outages, the cluster can still elect a leader within the partition and maintain data consistency within the partition. Furthermore, after the network failure is recovered, the cluster partitions are merged and the partition logs are synchronized.

[0005] To achieve the above objectives, a real-time consistency method for clustered robots under unreliable network conditions is provided, as detailed below:

[0006] S1. Divide the status of all nodes in the cluster into Leader, Follower, Candidate, and Learner; the node status changes dynamically to adapt to the network topology and the log update status of each node;

[0007] S2. The Leader node maintains its management of the cluster by periodically sending heartbeat packets to the other nodes; Follower nodes respond to the heartbeat packets from the Leader to accept the Leader's management, and at the same time synchronize the data from the Leader to the Learner nodes; the Candidate state is the intermediate process of electing a Leader node; the Learner state is the state that can only receive data forwarded by the Follower.

[0008] S3. Set two priority levels. The first priority is dynamically updated based on the number of logs and their age during cluster operation. The second priority is configured in advance when the cluster starts up, is globally unique, and does not change. During the cluster leader election process, the two priorities will be compared in turn, and the node with the highest priority in both levels will be elected as the cluster leader.

[0009] S4. When network fluctuations in the cluster cause network partitions, nodes in the partition that are missing a Leader will experience heartbeat timeouts and enter the election phase. The election phase ensures that a unique Leader node is generated in the partition.

[0010] S5. When the cluster network topology changes and a non-fully connected network topology state occurs, nodes that cannot communicate directly with the Leader node switch to the Learner state and complete data synchronization by sending data requests to the Follower nodes.

[0011] S6. The Leader node dynamically maintains the Peers table for all nodes it manages. When a node it manages fails to respond after three rounds of heartbeats, it removes the node from the Peers table.

[0012] S7. The Leader manages the logs of members in the Peers table. The Leader uses a heartbeat mechanism to synchronize the logs to be synchronized to the members in the Peers table it manages, so as to achieve real-time data and status consistency of the cluster nodes.

[0013] S8. When merging cluster partitions, the Leader nodes of both partitions complete the merging of the partitions through a four-stage partition merging process. During the partition merging process, the consensus method of the joint Leader provides cluster services to the outside world, ensuring the availability of the cluster during partition merging.

[0014] Furthermore, step S3 is as follows: The first priority mapping function f(x1,x2) for nodes is set as follows:

[0015]

[0016] Where x1 is the number of log entries committed by the node, and x2 is the difference between the current time and the average timestamp of the committed log entries; Tp The time threshold is α, β are weighting coefficients; T now This is the current millisecond-level timestamp sequence; the node's second priority is pre-configured and ensures global uniqueness within the cluster.

[0017] Furthermore, step S4 is detailed as follows:

[0018] S4.1: Nodes monitor their communication with the Leader node by setting an election timeout timer. When the election timer expires and no heartbeat message is received from the Leader node in the partition, the node enters the election phase.

[0019] S4.2: The election timeout timer is set according to the two-level priority of the nodes. The election timeout mapping function is as follows:

[0020] Election timeout =k1·(basetime+P1·T1+P2·T2)

[0021] Where basetime is the base timeout duration, P1 and P2 are the first and second priorities respectively, T1 and T2 are the first and second rated time parameters, and k1 is the time coefficient;

[0022] S4.3: Nodes entering the election phase switch their state to Candidate and broadcast an election request to the cluster members, carrying their current two-level priorities calculated according to the priority mapping function mentioned above; the other nodes that receive the election request decide on the content of their reply message based on their own state and their own two-level priorities.

[0023] S4.4: If the current state of the election responder is Leader or the election responder is currently communicating with other Leader nodes, it replies with a STOP message to terminate the election process of the election initiator, and carries its own Leader information; if the election responder is not currently communicating with any Leader, it calculates its own two-level priority according to the priority mapping function, and compares the priority of the election initiator with its own. If the two-level priority of the election initiator is higher than that of the election responder, the election responder resets the election timer; otherwise, the election responder replies with a STOP message to terminate the election process of the election initiator, and carries the priority information of the election responder.

[0024] S4.5: After broadcasting the election request, the election initiator waits for a preset election waiting time. If it receives a STOP message from any node during this period, it exits the election phase. If the preset election waiting time is reached and no STOP message is received, the election initiator changes its state to Leader, and the election phase ends, with the election initiator being elected Leader.

[0025] Furthermore, step S5 is as follows: When a node cannot communicate directly with the Leader node, it switches to the Learner state and pairs with a Follower node. The Learner node periodically sends data requests to the paired Follower node to complete the replication and synchronization of the Learner node logs.

[0026] Furthermore, step S6 is as follows: The Leader maintains the control of the cluster by sending heartbeat messages periodically, and records the heartbeat response status of the other nodes in the cluster it manages through the Peers table. When a managed node fails to respond after three rounds of heartbeats, the node is removed from the Peers table.

[0027] Furthermore, step S7 is detailed as follows:

[0028] S7.1: The structure of node logs in the cluster includes a log index and a log data content. A unique log index identifier is formed by a local trusted millisecond-level timestamp and the LeaderID that submitted the log. The log data content contains the client data that needs to be synchronized.

[0029] S7.2: According to the election process in step S4, the elected Leader node is guaranteed to have the highest two-level priority, that is, the Leader has the most up-to-date logs and status; at the same time, the Peers members managed by the Leader node carry all their own log index information in the heartbeat reply. The Leader node checks the log missing status of the member nodes in the Peers table by parsing the log index content in the heartbeat reply message, and integrates the missing log content into a log packet and carries it into the next round of heartbeat data packet to send to the Peers members;

[0030] S7.3: The managed node that receives a heartbeat data packet carrying a log packet will parse the log packet from the Leader and update it to its own log directory, thereby realizing the updating and synchronization of cluster data and status.

[0031] Furthermore, step S8 is as follows: During the partition merge condition triggering phase, when Leader2 node receives the heartbeat signal from Leader1 node, it triggers partition merge;

[0032] S8.1: In the partition merge log preparation phase, Leader1 node, based on the received log index, backtracks to the most recent identical log entry in its local logs and configures the maximum log backtracking time window to ensure the timeliness of the backtracked logs; Leader1 node packages the local logs after the most recent identical log into a log packet and sends it to Leader2 node; similarly, Leader1 node sends its local log index to Leader2 node, and Leader2 node backtracks to the most recent identical log entry in its local logs, packages it into a log packet, and sends it to Leader1 node;

[0033] S8.2: During the partition merge log synchronization phase, after the Leader node of each partition receives the log packet from the other partition, it broadcasts the log packet to all Follower nodes within its managed partition. After receiving the log packet from the Leader node, the Follower node paired with the Leader node forwards the log packet to the paired Learner node. After receiving the log packet from the other partition, all nodes within the partition reorganize the logs they manage locally according to the log index order rules.

[0034] S8.3: During the partition merge status update phase, the Leader2 node broadcasts a status update message to all Follower nodes within its own partition and becomes a Follower node of the Leader1 partition. The Follower and Learner nodes of the Leader2 partition are initialized to Follower state, waiting for heartbeat messages from other Leader nodes and joining the new partition. At this point, the Leader2 partition is disbanded, and the partition merge is complete.

[0035] During partition merging, partition Leader1 and Leader2 temporarily form a joint Leader to provide services to external clients. When any Leader receives a data request from a client, it sends the data to be synchronized to the other Leader. A piece of data can only be successfully committed after both Leaders reach a consensus.

[0036] The beneficial effects of this invention are as follows:

[0037] By setting a two-level priority system, the cluster can effectively elect a unique leader within each network partition after a network partition occurs, improving the election success rate and efficiency. It also ensures that the elected leader node has the latest logs and status within the network partition. The addition of Learner state nodes adapts to incompletely connected network topologies, increasing the cluster's adaptability and robustness to unreliable network conditions. The consensus mechanism using a joint leader ensures cluster availability during the network partition merging process. Attached Figure Description

[0038] Figure 1 This is a schematic diagram illustrating the external service provided by the present invention in an unreliable network environment.

[0039] Figure 2 This is a flowchart of the election stage of the present invention.

[0040] Figure 3 This is a schematic diagram of log synchronization using the joint Leader consensus method during the partition merging phase of this invention. Detailed Implementation

[0041] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0042] To address the distributed consistency problem of clusters in unreliable network environments, this invention provides a real-time consistency algorithm for cluster robots under unreliable network conditions. This algorithm ensures that when the network experiences partitioning or intermittent outages, the cluster can guarantee leader election and data consistency within each partition. Furthermore, after the network failure is recovered, the cluster partitions are merged and the partition logs are synchronized.

[0043] S1. Divide the status of all nodes in the cluster into Leader, Follower, Candidate, and Learner; the node status changes dynamically to adapt to the network topology and the log update status of each node;

[0044] S2. The Leader node maintains its management of the cluster by periodically sending heartbeat packets to the other nodes; Follower nodes respond to the heartbeat packets from the Leader to accept the Leader's management, and at the same time synchronize the data from the Leader to the Learner nodes; the Candidate state is the intermediate process of electing a Leader node; the Learner state is the state that can only receive data forwarded by the Follower.

[0045] S3. Set two priority levels. The first priority is dynamically updated based on the number of logs and their age during cluster operation. The second priority is configured in advance when the cluster starts up, is globally unique, and does not change. During the cluster leader election process, the two priorities will be compared in turn, and the node with the highest priority in both levels will be elected as the cluster leader.

[0046] S4. When network fluctuations in the cluster cause network partitions, nodes in the partition that are missing a Leader will experience heartbeat timeouts and enter the election phase. The election phase ensures that a unique Leader node is generated in the partition.

[0047] S5. When the cluster network topology changes and a non-fully connected network topology state occurs, nodes that cannot communicate directly with the Leader node switch to the Learner state and complete data synchronization by sending data requests to the Follower nodes.

[0048] S6. The Leader node dynamically maintains the Peers table for all nodes it manages. When a node it manages fails to respond after three rounds of heartbeats, it removes the node from the Peers table.

[0049] S7. The Leader manages the logs of members in the Peers table. The Leader uses a heartbeat mechanism to synchronize the logs to be synchronized to the members in the Peers table it manages, so as to achieve real-time data and status consistency of the cluster nodes.

[0050] S8. When the network failure is recovered and the cluster partitions are merged, the Leader nodes of both partitions complete the merging of the partitions through a four-stage partition merging process. During partition merging, services are provided to the outside world through the consensus method of the joint Leader to ensure the availability of the cluster during partition merging.

[0051] Step S3 is as follows: The first priority mapping function f(x1,x2) for nodes is set as follows:

[0052]

[0053] Where x1 is the number of log entries committed by the node, x2 is the difference between the current time and the average timestamp of the committed log entries; T p The time threshold is α, β are weighting coefficients; T now This is the current millisecond-level timestamp sequence; the node's second priority is pre-configured and ensures global uniqueness within the cluster.

[0054] Step S4 is as follows: Nodes monitor their communication with the Leader node by setting an election timeout timer. When the election timer expires without receiving a heartbeat message from the Leader node within the partition, the node enters the election phase. The election timeout timer is set according to the node's two-level priority, and the election timeout mapping function is as follows:

[0055] Election timeout =k1·(basetime+P1·T1+P2·T2)

[0056] Where basetime is the base timeout duration, P1 and P2 are the first and second priorities respectively, T1 and T2 are the first and second rated time parameters, and k1 is the time coefficient;

[0057] Nodes entering the election phase switch their state to Candidate and broadcast an election request to the cluster members, including their current two-level priorities calculated using the priority mapping function described above. The remaining nodes receiving the election request determine their response content based on their own state and priority levels.

[0058] If the current state of the election responder is Leader or the election responder is currently communicating with other Leader nodes, it replies with a STOP message to terminate the election process of the election initiator, and carries its own Leader information; if the election responder is not currently communicating with any Leader, it calculates its own two-level priority according to the priority mapping function, and compares the priority of the election initiator with its own. If the two-level priority of the election initiator is higher than that of the election responder, the election responder resets the election timer; otherwise, the election responder replies with a STOP message to terminate the election process of the election initiator, and carries the priority information of the election responder.

[0059] After broadcasting the election request, the election initiator waits for a preset election waiting time. If it receives a STOP message from any node during this period, it exits the election phase. If the preset election waiting time is reached and no STOP message is received, the election initiator changes its state to Leader, and the election phase ends, with the election initiator being elected Leader.

[0060] Step S5 is as follows: When a node cannot communicate directly with the Leader node, it switches to the Learner state and pairs with a Follower node. The Learner node periodically sends data requests to the paired Follower node to complete the replication and synchronization of the Learner node logs.

[0061] Step S6 is as follows: The Leader maintains the control of the cluster by sending heartbeat messages periodically, and records the heartbeat response status of the other nodes in the cluster it manages through the Peers table. When a managed node fails to respond after three rounds of heartbeats, the node is removed from the Peers table.

[0062] Step S7 is as follows: The structure of the node log in the cluster includes a log index and a log data content. A unique log index identifier is formed by a local trusted millisecond-level timestamp and the LeaderID that submitted the log. The log data content contains the client data that needs to be synchronized.

[0063] According to the election process in step S4, it is ensured that the elected Leader node has the highest two-level priority, that is, the Leader has relatively the latest logs and status; at the same time, the Peers members managed by the Leader node carry all their own log index information in the heartbeat reply. The Leader node checks the log missing situation of the member nodes in its managed Peers table by parsing the log index content in the heartbeat reply message, integrates the missing log content into a log package and carries it into the next round of heartbeat data packets and sends it to the Peers members; the managed nodes that receive the log package carried in the heartbeat data packet parse the log package from the Leader and update it to their own log directory, realizing the synchronization of the cluster data and status.

[0064] Step S8 is specifically as follows: In the partition merge condition trigger stage, when the Leader2 node receives the heartbeat signal from Leader1 (priority Leader2 < Leader1), the partition merge is triggered;

[0065] In the partition merge log preparation stage, the Leader1 node traces back to the nearest same log entry in the local log according to the received log index, and configures the maximum log backtracking time window to ensure the timeliness of the backtracked logs. Leader1 packs the local logs after the nearest same log into a log package (mergePack) and sends it to Leader2; similarly, Leader1 sends the local log index to Leader2, and Leader2 traces back to the nearest same log entry in the local log and packs it into a log package and sends it to Leader1;

[0066] In the partition merge log synchronization stage, after the Leader nodes of both partitions receive the log packages from the other partition, they broadcast the log packages to all Follower nodes within their respective jurisdictions. After the Follower nodes paired with the Leaner nodes receive the log packages from the Leader, they forward the log packages to the paired Learner nodes; all nodes within the partition (Leader, Follower, Learner) reorganize the locally managed logs according to the sequence rule of the log index after receiving the log packages from the other partition;

[0067] In the partition merge status update stage, the Leader2 node broadcasts a status update message to all Follower nodes within its own partition and becomes a Follower node in the Leader1 partition. The Follower and Learner nodes in the Leader2 partition are initialized to the Follower state, waiting for the heartbeat messages from other Leader nodes and joining the new partition.至此,Leader2分区解散,分区合并结束;

[0068] During partition merging, partition Leader1 and Leader2 temporarily form a joint Leader to provide services to external clients. When any Leader receives a data request from a client, it sends the data to be synchronized to the other Leader. A piece of data can only be successfully committed after both Leaders reach a consensus.

[0069] The real-time consistency method for cluster robots under unreliable network conditions of the present invention dynamically adjusts the first priority of nodes based on the number and age of node logs to influence the results of the next round of cluster election. This ensures that the cluster can successfully elect the highest priority node in the partition as the partition leader when a network partition or other network failure occurs, thereby improving the availability of the cluster after a network partition. The addition of the Learner state better adapts to network conditions that are not fully connected.

Claims

1. A real-time consistency method for clustered robots under unreliable network conditions, the method is as follows: S1. Divide the status of all nodes in the cluster into Leader, Follower, Candidate, and Learner; The node status changes dynamically to adapt to the network topology and the log updates of each node. S2. The Leader state node maintains cluster management by periodically sending heartbeat data packets to the other nodes; Follower nodes respond to heartbeats from the Leader to accept the Leader's management and simultaneously synchronize data from the Leader to the Learner nodes; the Candidate state represents the intermediate process of electing a Leader node; the Learner state represents a node that can only receive data forwarded by the Follower. S3. Set two priority levels. The first priority is dynamically updated based on the number of logs and their age during cluster operation. The second priority is configured in advance when the cluster starts, is globally unique, and does not change. During the cluster leader election process, the two priorities will be compared in turn, and the node with the highest priority in both levels will be elected as the cluster leader. S4. When network fluctuations in the cluster cause network partitions, nodes in the partition that are missing a Leader will experience heartbeat timeouts and enter the election phase. The election phase ensures that a unique Leader node is generated in the partition. S5. When the cluster network topology changes and a non-fully connected network topology state occurs, nodes that cannot communicate directly with the Leader node switch to the Learner state and complete data synchronization by sending data requests to the Follower nodes. S6. The Leader node dynamically maintains the Peers table for all nodes it manages. When a node it manages fails to respond after three rounds of heartbeats, it removes the node from the Peers table. S7. The Leader manages the logs of members in the Peers table. The Leader uses a heartbeat mechanism to synchronize the logs to be synchronized to the members in the Peers table it manages, so as to achieve real-time data and status consistency of the cluster nodes. S8. When merging cluster partitions, the leader nodes of both partitions go through a four-stage partition merge process. The partitions of both parties are merged. During the partition merging process, the cluster service is provided to the outside world through the consensus method of the joint leader to ensure the availability of the cluster during the partition merging.

2. The real-time consistency method for clustered robots under unreliable network conditions as described in claim 1, characterized in that, Step S3 is as follows: The first priority mapping function f(x1,x2) for nodes is set as follows: Where x1 is the number of log entries committed by the node, and x2 is the difference between the current time and the average timestamp of the committed log entries; T p The time threshold is α, β are weighting coefficients; T now This is the current millisecond-level timestamp sequence; the node's second priority is pre-configured and ensures global uniqueness within the cluster.

3. The real-time consistency method for swarm robots under unreliable network conditions as described in claim 1, characterized in that, Step S4 is as follows: S4.1: Nodes monitor their communication with the Leader node by setting an election timeout timer. When the election timer expires and no heartbeat message is received from the Leader node in the partition, the node enters the election phase. S4.2: The election timeout timer is set according to the two-level priority of the nodes. The election timeout mapping function is as follows: Election timeout =k1·(basetime+P1·T1+P2·T2) Where basetime is the base timeout duration, P1 and P2 are the first and second priorities respectively, T1 and T2 are the first and second rated time parameters, and k1 is the time coefficient; S4.3: Nodes entering the election phase switch their state to Candidate and broadcast an election request to the cluster members, carrying their current two-level priorities calculated according to the priority mapping function mentioned above; the other nodes that receive the election request decide on the content of their reply message based on their own state and their own two-level priorities. S4.4: If the current state of the election responder is Leader or the election responder is currently communicating with other Leader nodes, it replies with a STOP message to terminate the election process of the election initiator, and carries its own Leader information; if the election responder is not currently communicating with any Leader, it calculates its own two-level priority according to the priority mapping function, and compares the priority of the election initiator with its own. If the two-level priority of the election initiator is higher than that of the election responder, the election responder resets the election timer; otherwise, the election responder replies with a STOP message to terminate the election process of the election initiator, and carries the priority information of the election responder. S4.5: After broadcasting the election request, the election initiator waits for a preset election waiting time. If it receives a STOP message from any node during this period, it exits the election phase. If the preset election waiting time is reached and no STOP message is received, the election initiator changes its state to Leader, and the election phase ends, with the election initiator being elected Leader.

4. The real-time consistency method for swarm robots under unreliable network conditions as described in claim 1, characterized in that, Step S5 is as follows: When a node cannot communicate directly with the Leader node, it switches to the Learner state and pairs with a Follower node. The Learner node periodically sends data requests to the paired Follower node to complete the replication and synchronization of the Learner node logs.

5. The real-time consistency method for swarm robots under unreliable network conditions as described in claim 1, characterized in that, Step S6 is as follows: The Leader maintains the control of the cluster by sending heartbeat messages periodically, and records the heartbeat response status of the other nodes in the cluster it manages through the Peers table. When a managed node fails to respond after three rounds of heartbeats, the node is removed from the Peers table.

6. The real-time consistency method for swarm robots under unreliable network conditions as described in claim 1, characterized in that, Step S7 is as follows: S7.1: The structure of node logs in the cluster includes a log index and a log data content. A unique log index identifier is formed by a local trusted millisecond-level timestamp and the LeaderID that submitted the log. The log data content contains the client data that needs to be synchronized. S7.2: According to the election process in step S4, the elected Leader node is guaranteed to have the highest two-level priority, that is, the Leader has the most up-to-date logs and status; at the same time, the Peers members managed by the Leader node carry all their own log index information in the heartbeat reply. The Leader node checks the log missing status of the member nodes in the Peers table by parsing the log index content in the heartbeat reply message, and integrates the missing log content into a log packet and carries it into the next round of heartbeat data packet to send to the Peers members; S7.3: The managed node that receives a log packet in the heartbeat data packet will parse the log packet from the Leader and update it in its own log directory, thereby realizing the updating and synchronization of cluster data and status.

7. The real-time consistency method for swarm robots under unreliable network conditions as described in claim 1, characterized in that, Step S8 is as follows: During the partition merge condition triggering phase, when Leader2 node receives the heartbeat signal from Leader1 node, it triggers partition merge; S8.1: In the partition merge log preparation phase, Leader1 node, based on the received log index, backtracks to the most recent identical log entry in its local logs and configures the maximum log backtracking time window to ensure the timeliness of the backtracked logs; Leader1 node packages the local logs after the most recent identical log into a log packet and sends it to Leader2 node; similarly, Leader1 node sends its local log index to Leader2 node, and Leader2 node backtracks to the most recent identical log entry in its local logs, packages it into a log packet, and sends it to Leader1 node; S8.2: During the partition merge log synchronization phase, after the Leader node of each partition receives the log packet from the other partition, it broadcasts the log packet to all Follower nodes within its managed partition. After receiving the log packet from the Leader node, the Follower node paired with the Leader node forwards the log packet to the paired Learner node. After receiving the log packets from the other partition, all nodes within the partition reorganize their locally managed logs according to the log index order rules. S8.3: During the partition merge status update phase, the Leader2 node broadcasts a status update message to all Follower nodes within its own partition and becomes a Follower node of the Leader1 partition. The Follower and Learner nodes of the Leader2 partition are initialized to Follower state, waiting for heartbeat messages from other Leader nodes and joining the new partition. At this point, the Leader2 partition is disbanded, and the partition merge is complete. During partition merging, partition Leader1 and Leader2 temporarily form a joint Leader to provide services to external clients. When any Leader receives a data request from a client, it sends the data to be synchronized to the other Leader. A piece of data can only be successfully committed after both Leaders reach a consensus.

Images