A data distribution service communication framework supporting pluggable distributed consensus algorithm

Abstract

The application discloses a data distribution service communication framework supporting pluggable distributed consensus algorithm, which comprises a distributed consensus algorithm module, a collection decision module, a data distribution service middleware and a data distribution service interface module. The consensus algorithm module is responsible for the consistency and availability guarantee of resolutions in a distributed system; the collection decision module is responsible for collecting distributed node information and intelligently adjusting a better consensus algorithm; and the data distribution service interface module is responsible for the interaction between the data distribution service middleware and the distributed consensus algorithm module. Through application of modern computer technology, the application proposes a framework flexibly integrating the data distribution service communication middleware and the distributed consensus algorithm, and intelligently adjusts the consensus algorithm of the consensus algorithm module according to the condition of the distributed system. Based on the application, a high-reliability distributed system capable of solving single-point fault, realizing remote backup and load balancing can be easily built on the data distribution service.

Description

Technical Field

[0001] This invention belongs to the field of computer science and technology, specifically relating to a data distribution service communication framework that combines data distribution service middleware with different distributed consensus algorithms, can obtain and analyze system performance through a distributed system collector, and then complete adaptive selection and updating of distributed consensus algorithms according to the selection algorithm. Background Technology

[0002] Data Distribution Service (DDS) is a middleware standard for distributing data in real-time systems. It supports the collaborative work of distributed applications by distributing data between applications, making real-time communication between distributed systems more reliable and efficient. DDS has the following characteristics: 1) Reliability: DDS ensures reliable message delivery by providing QoS (Quality of Service). These QoS parameters control message delivery speed, delivery order, retries, and error handling. 2) Real-time Performance: DDS supports data transmission in real-time systems, ensuring the timeliness and reliability of data transmission. 3) Scalability: DDS supports the deployment of large-scale systems, easily adding new devices and applications to the distributed system. 4) Interoperability: DDS is an open standard that supports multiple programming languages ​​and hardware platforms, enabling interoperability between different applications and devices. DDS is widely used in many real-time system fields, such as industrial automation, medical devices, aerospace, military, and communications. While DDS performs well in many aspects, it cannot handle scenarios with high availability requirements, such as scenarios where service must remain available even with single-node failures. For example, when a data distribution service node receives data, immediately processes it, and returns the result to the requester, if that node crashes at this point, the entire system becomes unavailable. A simple data distribution service protocol can only guarantee data persistence through QoS, but it cannot guarantee the availability of the distributed system.

[0003] Currently, there are many third-party libraries that implement data distribution service protocols, such as FAST-DDS. However, these libraries only address the implementation of the data distribution service protocol and cannot solve the problem of single-node crashes in distributed scenarios. Therefore, in many scenarios that require solving such problems, developers need to write their own distributed consensus algorithm on top of it to ensure system availability. Implementing a distributed consensus algorithm is a very complicated task, and different distributed consensus algorithms have different characteristics. To help users reduce development workload, this invention integrates various distributed consensus algorithms on top of the data distribution service. It can automatically select different distributed consensus algorithms according to different scenario characteristics, allowing users to use it out of the box even without knowing the algorithm details. Summary of the Invention

[0004] The purpose of this invention is to provide a framework for a data distribution service that supports pluggable distributed consensus algorithms and can intelligently select algorithms based on collector data. Because the data distribution service middleware only handles information transmission at the transport layer, implementing a highly reliable system capable of resolving single points of failure, achieving off-site backup, and load balancing on the data distribution service often requires writing an independent distributed consensus algorithm on top of it. Therefore, to reduce development effort, this invention provides interfaces for easily injecting different algorithm implementations to support the integration of more distributed algorithms, and injects open-source consensus algorithm implementations into these interfaces. Regarding consensus algorithm selection, an intelligent selection method is provided. This method analyzes the efficiency and availability of the current system through distributed node traffic and log synchronization collectors, and then automatically changes the system's consensus algorithm, achieving adaptive consensus algorithm selection.

[0005] The specific technical solution for achieving the objective of this invention is as follows:

[0006] A data distribution service communication framework supporting pluggable distributed consensus algorithms is provided for building distributed systems. It includes a distributed consensus algorithm module, a data collection and decision-making module, a data distribution service interface module, and a data distribution service middleware. The distributed consensus algorithm module is responsible for ensuring the consistency and availability of decisions in the distributed system. The data collection and decision-making module is responsible for collecting information from distributed nodes and intelligently adjusting the consensus algorithm to address issues of low efficiency or availability in the distributed system. The data distribution service interface module is responsible for facilitating interaction between the data distribution service middleware and the distributed consensus algorithm module. The data distribution service middleware is responsible for message transmission at the transport layer of the distributed system.

[0007] In the distributed system, nodes are abstracted into a class whose members include a client list, persistent objects, the index of the current node, the state of the current node, the current term number, the election target, a log list, committed log positions, applied log positions, a list of log positions that each server is about to send, a list of the highest matching log positions that each server has received, the last heartbeat time, an application log pipeline, an election pipeline, and a log synchronization pipeline.

[0008] The distributed consensus algorithm module comprises four units: a leader election unit, a log synchronization unit, a consensus algorithm switching unit, and a collector client unit.

[0009] The leader election unit: Nodes in the distributed system are in one of three states at any given time: follower, candidate, or leader. A node starts in the follower state. If it does not receive any information from the leader node (i.e., the node in the leader state) within the election timeout period, it becomes a candidate. A candidate sends voting requests to other nodes; if it receives more than half of the votes, it becomes the leader node. After becoming the leader node, it periodically sends heartbeat messages to other nodes to prevent other follower nodes from becoming candidates. The leader election unit, through its leader election mechanism, ensures that even if the leader node crashes, a new leader node can still be elected, and communication with the distributed system clients can continue, guaranteeing the availability of the distributed system.

[0010] Log synchronization unit: When a distributed system client sends a command to the leader node, or periodically sends a heartbeat, the leader node sends the latest log information to other nodes based on the log synchronization progress messages recorded locally. If a success message is received, the leader node updates its local log progress data. Only when a log entry is synchronized by more than half of the nodes will the leader node commit the log entry, execute the command within the log entry, and return the result to the distributed system client. The log synchronization unit ensures the consistency of the distributed system.

[0011] Consensus Algorithm Switching Unit: The leader election unit and log synchronization unit are each treated as methods of an interface class. Any distributed consensus algorithm can implement these two interfaces to become a distributed consensus algorithm implementation class. The consensus algorithm switching unit is a function within the distributed consensus algorithm module. It takes the name of the consensus algorithm to be switched as input, and can use the template pattern to obtain the corresponding consensus algorithm class object, and then replace the consensus algorithm object currently in use in the module.

[0012] Collector client unit: This is a client that uses shared memory for inter-process communication. It is responsible for periodically obtaining distributed system traffic data and distributed system leader update frequency data from all nodes, and then sending them to the collector server in the collection decision module.

[0013] By implementing the leader election unit and log synchronization unit, different distributed consensus algorithms can be connected to the distributed consensus algorithm module, realizing the pluggability of different distributed consensus algorithms; and the switching of different consensus algorithms can be completed by calling the consensus algorithm switching unit.

[0014] The data distribution service interface module encapsulates the API provided by the data distribution service, using the proxy pattern to implement an abstract class through inheritance by the data read listener. It provides a method to register two functions: "Synchronous Send Command" and "Data Processing." The "Synchronous Send Command" function is responsible for sending information from the distributed leader node to other nodes, synchronously waiting until successful submission. The "Data Processing" function is responsible for processing the received messages after submission. Both functions are stored as member objects of the abstract class. The "Data Validation" method of the data read listener is overridden, internally calling "Synchronous Send Command" first to complete log synchronization, and then calling "Data Processing" to process the received messages. The data distribution service interface module enables interaction between the data distribution service middleware module and the distributed consensus algorithm module. The collection decision module includes a collector server unit and an intelligent distributed consensus algorithm selection unit. This module executes only on the leader node, responsible for collecting and analyzing distributed node data, and completing the online selection and update of the consensus algorithm within the distributed consensus algorithm module based on the efficiency and availability of the distributed system. The collector server unit is a server using shared memory for inter-process communication, periodically acquiring distributed node performance data sent from the collector client in the distributed consensus algorithm module. The intelligent distributed consensus algorithm selection unit is responsible for analyzing the data collected by the collector server unit; it analyzes the efficiency of the current distributed system using the distributed system traffic frequency and latency data, and then selects the consensus algorithm with high efficiency or reliability using the consensus algorithm selection algorithm; whenever switching algorithms, the leader node first calls the switching function in its own consensus algorithm switching unit, and then sends an RPC request to other nodes to switch consensus algorithms.

[0015] The data distribution service middleware is a middleware used to distribute data in real-time systems; it supports the collaborative work of distributed applications by distributing data between nodes, making real-time communication between distributed systems more reliable and efficient.

[0016] The beneficial effects of this invention are as follows: By integrating a data distribution service middleware with a distributed consensus algorithm, this invention makes it easier for developers to build a reliable, consistency-compliant distributed system based on a data distribution service. The distributed consensus algorithm module in this invention provides a universal interface, facilitating easy integration with other consensus algorithms. In previous distributed systems, distributed consensus algorithms were almost always fixed, and different consensus algorithms exhibited varying performance and availability characteristics. The data collection and decision-making module in this invention, through a consensus algorithm switching algorithm, analyzes the distributed node data collected by the collector and selects the consensus algorithm that best addresses the current bottleneck. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the framework of the present invention;

[0018] Figure 2 This is a diagram illustrating the node state changes in the distributed consensus algorithm module.

[0019] Figure 3 This is a diagram illustrating the switching of the consensus algorithm in the data collection and decision-making module. Implementation

[0020] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. See also... Figure 1 This invention discloses a data distribution service communication framework supporting a pluggable distributed consensus algorithm. It includes a distributed consensus algorithm module, a data collection and decision-making module, a data distribution service interface module, and a data distribution service middleware. The distributed consensus algorithm module is responsible for ensuring the consistency and availability of decisions in the distributed system. The data collection and decision-making module is responsible for collecting information from distributed nodes and intelligently adjusting to a better consensus algorithm. The data distribution service interface module is responsible for connecting the data distribution service middleware and the distributed consensus algorithm module. The data distribution service middleware is responsible for message transmission at the transport layer. This invention includes:

[0021] 1) The distributed consensus algorithm module based on the data distribution service includes four basic units: leader election, log synchronization, consensus algorithm switching, and collector client. Different consensus algorithms can be integrated by implementing the first two basic units, enabling plug-and-play functionality for different distributed consensus algorithms. The distributed consensus algorithm ensures consistency of resolutions by electing a single leader and passing resolutions through majority voting, i.e., log synchronization. If a single node in the distributed system fails, the consensus algorithm can re-elect a new leader, thus solving the single point of failure problem and ensuring system availability.

[0022] 2) Data distribution service interface module, which contains a set of interfaces that can easily apply different consensus algorithms to the data distribution service middleware. It is responsible for connecting the distributed consensus algorithm module and the data distribution service middleware module. This module is based on the Fast-DDS API, adopts the adapter pattern, and designs an abstract class. Users only need to inject the message synchronization function of the distributed consensus algorithm as a parameter into the class.

[0023] 3) A data collection and decision-making module, including a collector server and an intelligent distributed consensus algorithm selection unit, analyzes the efficiency and availability of the current system by collecting distributed node traffic and distributed node leader update frequency data. It then automatically changes the system's distributed consensus algorithm, completing adaptive consensus algorithm selection and updates. The collector server obtains data on the frequency and latency of distributed system requests to analyze the efficiency of distributed nodes; it also obtains data on the distributed system leader update frequency to analyze system availability. The distributed consensus algorithm selection algorithm analyzes the performance of the current distributed system's efficiency and availability based on the data obtained by the collector, then intelligently weighs and selects a better distributed consensus algorithm. Finally, it calls the consensus algorithm switching function of the distributed consensus algorithm module to complete the online selection and update of the distributed consensus algorithm.

[0024] 4) Data distribution service middleware is a type of middleware used to distribute data in real-time systems. It supports the collaborative work of distributed applications by distributing data between nodes, making real-time communication between distributed systems more reliable and efficient.

[0025] The four units—leader election, log synchronization, consensus algorithm switching, and collector client—are specifically as follows:

[0026] The leader election unit is designed by first creating a structure representing the distributed node. Members include: a list of other node clients (primarily used to send RPC messages to other nodes); a persistent object to persist node information in memory to disk; the node's index (its index within the distributed node group); the node's state (e.g., follower, candidate, leader); the current term number (the global term number recorded by the current node); the election object (which node the current node voted for); a log list storing log information not yet persisted to the database; the committed log position (the index of the last log position committed by the current node); the applied log position (the index of the last log position applied by the current node); a list of log positions to be sent by each server (the index of the first log entry sent to each node during log synchronization); and a list of the highest-matching log positions received by each server (the index of the last log entry whose progress matches the log progress of other nodes).

[0027] Leader election handles the sending and processing of decisions by electing a leader. If a node hasn't received a heartbeat from the "real" leader after a certain random time, it changes from a follower state to a candidate state. At this point, it sends a vote request to other nodes. The request includes four pieces of information about the current node: its current term, its node identifier, the position of the last log entry in its log list, and its corresponding term. When other nodes receive the request, they judge whether the following conditions are met: the requester's term is less than the voter's term; it has already voted for another candidate; the requester's term in its last log entry is less than or equal to the voter's term; or, if the terms are the same, the requester's last log entry position index is less than the voter's. If any of these four conditions are met, the requester will not vote. After sending election requests to all other nodes in parallel, the requester synchronously waits for the results. If it receives votes, it increments its vote count by 1. When it receives more than half of the votes, it changes its state to leader. If the term in the response is greater than the current node's term, it reverts to follower state.

[0028] The log synchronization unit is primarily responsible for synchronizing the local resolution logs with other distributed nodes. After being elected as the leader, it periodically sends heartbeats to other nodes for log synchronization. Each heartbeat packet contains the log information to be transmitted to other nodes, with the log index ranging from the next log index stored locally on the receiving node to the index of the latest log already received locally. The receiving node also needs to send its next log index and term, as well as the leader's latest commit index, to the receiving node. When a receiving node receives a log synchronization request from the leader node and returns success, the leader first updates the corresponding node's local matching index and next log index to the leader's latest log information. It also increments the successful synchronization count. When the number of successfully synchronized nodes reaches half of the total nodes, the leader node commits the logs and updates the commit index to the latest log information. If the log synchronization request response detects that any node's term is longer than the current term, the leader node becomes a follower node and stops log synchronization. If more than half of the log synchronization requests time out, the leader node reverts to a follower node.

[0029] The consensus algorithm switching unit treats leader election and log synchronization as methods in an interface class. Any distributed consensus algorithm can implement these two interfaces to become a distributed consensus algorithm implementation class. The consensus algorithm switching unit is a function within the distributed consensus algorithm module. It takes the name of the consensus algorithm to be switched to as input, generates a new corresponding consensus algorithm object, and then replaces the consensus algorithm object currently in use within the module.

[0030] Collector Client Unit: This is a client that uses shared memory for inter-process communication. It is responsible for periodically obtaining distributed system traffic data and distributed system leader update frequency data from the distributed consensus nodes, and then sending them to the collector server in the collection decision module.

[0031] The data distribution service interface module based on Fast-DDS is as follows:

[0032] 1) Utilize the service center provided by the data distribution service to dynamically obtain information about the leader node and forward all external requests to the leader node. 2) Encapsulate the API provided by the data distribution service, using the proxy pattern to implement an abstract class that the data read listener inherits from. This class provides a method to register two functions: "Synchronous Send Command" and "Data Processing." The "Synchronous Send Command" function is responsible for sending information from the distributed leader node to other nodes, synchronously waiting until successful commit. The "Data Processing" function is responsible for processing the received messages after commit. Both functions are stored as member objects of the abstract class. The "Data Validation" method of the data read listener is then overridden. Internally, it first calls "Synchronous Send Command" to complete log synchronization, and then calls "Data Processing" to process the received messages. The data distribution service interface module implements the interaction between the data distribution service middleware module and the distributed consensus algorithm module. The collection and decision module specifically includes: 1) A collector server, which uses shared memory for inter-process communication and periodically acquires distributed node data sent from the collector client in the distributed consensus algorithm module. 2) An intelligent distributed consensus algorithm selection unit, which analyzes the data collected by the collector server. The efficiency of the distributed system is analyzed using system traffic frequency and latency data. High latency indicates inefficiency due to contention, necessitating the adoption of the more efficient Raft algorithm. Availability is assessed based on node state changes from the collector. Frequent leader node changes indicate low availability, requiring the adoption of the more available Paxos algorithm. If all data is relatively balanced, the Epaxos algorithm, balancing efficiency and availability, is used. The consensus algorithm transition is not abrupt; instead of immediately switching from Paxos to Raft if latency falls below a threshold, a circuit breaker-like mechanism is employed. The system first switches to Epaxos, then analyzes performance metrics over a period. If requests exceeding the threshold still exceed a certain proportion, it switches back to Raft. The collection and decision-making module operates only when a node is in the leader state. When switching consensus algorithms, the leader node first calls its own consensus algorithm switching unit, then uses RPC to call the consensus algorithm switching units of other nodes. Example

[0033] Node construction unit design:

[0034] Construct a distributed node structure whose members include a client list, persistent objects, the index of the current node, the state of the current node, the current term number, election targets, a log list, committed log positions, applied log positions, a list of log positions that each server is about to send, a list of the highest matching log positions that each server has received, the last heartbeat time, an application log pipeline, an election pipeline, and a log synchronization pipeline.

[0035] State change unit design:

[0036] Each distributed node has three states: follower, candidate, and leader. Changes between them are as follows: Figure 2 As shown.

[0037] State changes occur in many places. For convenience, state changes are extracted into a method. This method first determines whether the election timeout timer needs to be reset. If so, it sends a signal to the election goroutine through the election pipeline. Then, it performs different actions based on the desired state value: When the state becomes "flower," it resets supporters to -1, clears the log position list to be sent by each server and the list of the highest matching log positions received by each server, and then sends a message to the election pipeline. When the state becomes "candidate," it increments the current term count, sets itself as a supporter, and calls the request vote method to initiate the election request. When the state becomes "leader," it synchronizes its latest local messages to the list recording other nodes, and also sends a message to the log synchronization pipeline to begin log synchronization.

[0038] Each non-leader node has a timer. If the timer expires (150ms~200ms), it will call the state change method. This method passes the target state to be changed and whether to reset the election timeout timer as parameters; or when a reset timer message is received, it will restart the timer.

[0039] Leadership election unit design:

[0040] The leader election module mainly consists of two parts: one is the process of a candidate initiating a voting request to other nodes and then processing the result; the other is the process of other nodes processing the vote after receiving the request.

[0041] Part 1: Once a node becomes a candidate, it immediately initiates a voting request. This request includes the candidate's current term, its own node number, and the index and term number of the latest log stored locally. Then, a coroutine is started to send the request in parallel. If more than half of the nodes agree, the node becomes the leader; otherwise, it remains in that position until a timeout triggers a timer for the next term. If an updated log is received in the response message, indicating that a new leader has been appointed, the election fails, the node updates its own log to match the leader, and then becomes a follower again. Because concurrency is involved, locks are used to manage data hazards.

[0042] Part Two: When other nodes receive a request from a candidate, they first place the current node's term count in the returned structure so the candidate can check if its term is lagging. If the candidate's term count in the request is less than the current node's term count, the vote is rejected; if the term count in the request is greater than the current node's term count, the current node's term count is immediately updated to the candidate's term count, and its state is changed to "flower"; if the candidate's term count is greater than or equal to the current node's term count, the node first checks if it has voting rights. A node only has voting rights if it hasn't voted for any other node or has already voted for a candidate. Besides voting rights, the candidate's log progress must also catch up with the current node's log progress. Catching up is defined as: the term count of the requester candidate's last log entry is greater than or equal to the term count of the last entry in the current node's local log, and the index position of the candidate's last log entry must be greater than or equal to the index position of the current node's last log entry. When a node acquires voting rights and the candidate's log progress catches up with the current node, the current node will agree to vote for the candidate and send a message to the election pipeline to inform the election timer to start the next cycle. This prevents the current node from agreeing to vote only after the timer expires and then immediately becoming the candidate again to request votes.

[0043] All state changes in the above two parts adopt the methods specifically implemented in the state change module of the second part.

[0044] Create a Subscriber proxy class responsible for callbacks of messages received from the data distribution service. First, an `init` function is needed to initialize Fast-DDS related objects. Create a domain participant and register the data type by calling the `register_type()` method. Next, create the subscriber's QoS (Quality of Service), which can be set to `SUBSCRIB-ER_QOS_DEFAULT`. Then, use the created domain participant to create subscribers, followed by creating `TopicQos` and `Topic`. After creation, use these as parameters to create readers from the subscribers. The reader also needs a listener that inherits from `DataReaderListener` as a parameter. The listener handles message callbacks by overriding the `on_data_available` method, allowing it to parse data using a custom IDL after receiving messages from other nodes.

[0045] To ensure that decision-makers in a distributed system, upon receiving decision information, forward it to other nodes for log synchronization, and then perform post-processing after synchronization is complete, the methods for sending decision information and post-processing messages upon receipt need to be defined as function objects in a Subscriber proxy class. Then, in the listener's callback method, this function object is first called to synchronize and wait for more than half of the nodes to reach consensus before using the information as a parameter for post-processing in the application layer's business logic.

[0046] With this proxy class, developers can easily integrate other distributed consensus algorithms. If a new distributed consensus algorithm is introduced, the only modification required is to place the consensus algorithm's decision synchronization method as a function object within the Subscriber proxy class. The post-processing logic performed by the upper layer after receiving the information can remain unchanged.

[0047] Different distributed consensus algorithms have different performance characteristics: Paxos allows each replica to propose, resulting in high availability, but its efficiency is low due to contention and conflicts; Raft elects a leader to avoid conflicts, improving efficiency, but it also introduces a leader bottleneck, reducing availability; while Epaxos strikes a balance between the two, maintaining a moderate level of efficiency and availability. Therefore, this invention, in addition to supporting manual selection of consensus algorithms, also provides a function for adaptively selecting and updating consensus algorithms based on specific scenarios.

[0048] To identify scenario information and analyze the current performance of the distributed system, a collector is needed to gather information on traffic latency and node changes from within the distributed system. This information can only be collected by the collector client within the consensus algorithm and then sent to the collector server for further processing. Therefore, to implement the collector, a library for inter-process communication (IPC) is first developed. This library can utilize TCP or shared memory for client-server interaction. If the client and server are on the same device, shared memory is used because it avoids the TCP kernel protocol stack, resulting in faster performance. Specifically, the ZeroMQ IPC library is used for communication. If TCP communication is used, the server-side implementation uses the Proactor asynchronous network model. Its underlying epoll system call can efficiently monitor a large number of file descriptors in Linux, handling higher concurrency scenarios.

[0049] The initial distributed consensus algorithm for the distributed system is set to Epaxos (this node is referred to as the Epaxos state) because this algorithm has relatively balanced performance. After obtaining the request latency q of the collector and the leader node state change frequency s, a sliding window algorithm is used to calculate the average of the first k sampled data in real time. Once the sliding average of q is detected to be higher than the set threshold qt at some point, it indicates that the distributed system is inefficient, possibly due to data conflicts and lock contention during multi-node decision-making. At this time, it enters a semi-mutation state, because it may be caused by internal system performance fluctuations. Then, it will continue to monitor for a period of time t. If the proportion of the average sliding latency q exceeding the threshold qt during this period exceeds m, it will enter the Raft state; otherwise, it will revert to the Epaxos state. When the node is in the Raft state, it continues to collect and analyze data. If the sliding average of q is detected to be lower than the set threshold qt at some point, it enters a semi-mutation state. Then, it will continue to monitor for a period of time t. If the proportion of the average sliding latency q exceeding the threshold qt during this period is lower than m, it will enter the Epaxos state; otherwise, it will remain in the Raft state. Similarly, the leader node state change frequency *s*, like the request latency *q*, dynamically switches between semi-mutation and Paxos states. The node state change diagram is shown below. Figure 3 As shown.

Claims

1. A distributed system, built upon a data distribution service communication framework supporting pluggable distributed consensus algorithms, characterized in that: The communication framework includes a distributed consensus algorithm module, a data acquisition and decision-making module, a data distribution service interface module, and a data distribution service middleware. The distributed consensus algorithm module is responsible for ensuring the consistency and availability of decisions in the distributed system. The data acquisition and decision-making module is responsible for collecting information from distributed nodes and intelligently adjusting the consensus algorithm to solve the problems of low efficiency or availability in the distributed system. The data distribution service interface module is responsible for connecting the data distribution service middleware and the distributed consensus algorithm module. The data distribution service middleware is responsible for message transmission at the transport layer of the distributed system. The distributed consensus algorithm module comprises four units: a leader election unit, a log synchronization unit, a consensus algorithm switching unit, and a collector client unit. The leader election unit: Nodes in the distributed system are in one of three states at any given time: follower, candidate, or leader. A node starts in the follower state. If it does not receive any information from the leader node (i.e., the node in the leader state) within the election timeout period, it becomes a candidate. A candidate sends voting requests to other nodes; if it receives more than half of the votes, it becomes the leader node. After becoming the leader node, it periodically sends heartbeat messages to other nodes to prevent other follower nodes from becoming candidates. The leader election unit, through its leader election mechanism, ensures that even if the leader node crashes, a new leader node can still be elected, and communication with the distributed system clients can continue, guaranteeing the availability of the distributed system. Log synchronization unit: When a distributed system client sends a command to the leader node, or periodically sends a heartbeat, the leader node sends the latest log information to other nodes based on the log synchronization progress messages recorded locally. If a success message is received, the leader node updates its local log progress data. Only when a log entry is synchronized by more than half of the nodes will the leader node commit the log entry, execute the command within the log entry, and return the result to the distributed system client. The log synchronization unit ensures the consistency of the distributed system. Consensus Algorithm Switching Unit: The leader election unit and log synchronization unit are each treated as methods of an interface class. Any distributed consensus algorithm can implement these two interfaces to become a distributed consensus algorithm implementation class. The consensus algorithm switching unit is a function within the distributed consensus algorithm module. It takes the name of the consensus algorithm to be switched as input, and can use the template pattern to obtain the corresponding consensus algorithm class object, and then replace the consensus algorithm object currently in use in the module. Collector client unit: This is a client that uses shared memory for inter-process communication. It is responsible for periodically obtaining distributed system traffic data and distributed system leader update frequency data from all nodes, and then sending them to the collector server in the collection decision module. By implementing the leader election unit and log synchronization unit, different distributed consensus algorithms can be connected to the distributed consensus algorithm module, realizing the pluggability of different distributed consensus algorithms; and the switching of different consensus algorithms can be completed by calling the consensus algorithm switching unit. The data distribution service interface module encapsulates the API provided by the data distribution service, using the proxy pattern to implement an abstract class through inheritance by the data read listener. It provides a method to register two functions: "Synchronous Send Command" and "Data Processing." The "Synchronous Send Command" function is responsible for sending information from the distributed leader node to other nodes, synchronously waiting until successful submission. The "Data Processing" function is responsible for processing the received messages after submission. Both functions are stored as member objects of the abstract class. The "Data Validation" method of the data read listener is overridden, internally calling "Synchronous Send Command" first to complete log synchronization, and then calling "Data Processing" to process the received messages. The data distribution service interface module enables interaction between the data distribution service middleware module and the distributed consensus algorithm module. The collection decision module includes a collector server unit and an intelligent distributed consensus algorithm selection unit. This module executes only on the leader node, responsible for collecting and analyzing distributed node data, and completing the online selection and update of the consensus algorithm within the distributed consensus algorithm module based on the efficiency and availability of the distributed system. The collector server unit is a server using shared memory for inter-process communication, periodically acquiring distributed node performance data sent from the collector client in the distributed consensus algorithm module. The intelligent distributed consensus algorithm selection unit is responsible for analyzing the data collected by the collector server unit; it analyzes the efficiency of the current distributed system using the distributed system traffic frequency and latency data, and then selects the consensus algorithm with high efficiency or reliability using the consensus algorithm selection algorithm; whenever switching algorithms, the leader node first calls the switching function in its own consensus algorithm switching unit, and then sends an RPC request to other nodes to switch consensus algorithms. The data distribution service middleware is a middleware used to distribute data in real-time systems; it supports the collaborative work of distributed applications by distributing data between nodes, making real-time communication between distributed systems more reliable and efficient.

Images