A zero-downtime consistency protocol switching method

Abstract

The application designs a zero downtime consistency protocol switching method, belongs to the technical field of distributed system consensus, and is implemented by a consistency protocol scheduling layer and multiple consistency protocols; a unique command sequence number McpSeqNo and a consistency protocol label McpProcessedBy are added for each client request and used in the consistency protocol scheduling layer; the sequence number McpSeqNo is incremental in the consistency protocol scheduling layer, and when a state machine executes a command, the latest, that is, the largest sequence number of each client that has been executed is tracked and saved; when the state machine starts to execute a command in a log, the consistency protocol scheduling layer compares the sequence number to check whether it is the next command to be executed, and if yes, the command is directly executed, otherwise, the command is ignored and the result of the last execution of the command is returned; thus, different consistency protocols can be dynamically selected for dynamic changing workloads, so that the protocol transition period is fault-tolerant.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of distributed system consensus, and particularly relates to a zero-downtime consensus protocol switching method. BACKGROUND

[0002] With the rapid development of related technologies such as artificial intelligence, Internet of Things, 5G, and the accelerated promotion of digital economy in the world, data resources have become the key force of global competition. At present, the global data volume is still in the stage of rapid growth. According to the statistics and forecasts of authoritative agencies, the global data volume has reached 47 ZB in 2020, and it is predicted that the data volume will reach 2412 ZB in 2035. The traditional centralized storage system cannot efficiently and reliably store these huge amounts of data, and more and more companies use distributed storage systems.

[0003] The distributed storage system uses multiple independent devices to store data in a scattered manner. Such a storage system can use multiple devices to share the storage load, and through the connection of computer networks, the scattered storage units are unified logically. However, distributed storage may cause problems such as data loss and unrecoverability. When data is accessed and read by multiple users, inconsistencies may occur between the copies, which will directly affect the consistency and accuracy of the system. Therefore, data consistency is a major challenge in distributed systems.

[0004] In order to solve the problem of distributed consistency, researchers have proposed a variety of classic consensus protocol algorithms. However, each existing consistency protocol design is optimized and improved for a specific configuration, so although these protocols perform well in their optimized design scenarios, no protocol can consistently maintain good performance in different scenarios, so careful selection of the appropriate protocol is required according to different workloads to enable the system to have better performance.

[0005] The existing most naive protocol switching solution is the "stop-redirect" simple and direct switching scheme. When the workload changes, a stop request is sent to all nodes in the cluster, and when all node instances are executed to place the system in a static state, the initialization of another consistency protocol is notified.

[0006] However, this method mainly has two problems: on the one hand, the transition during protocol switching is not fault-tolerant, which may cause the system to crash during switching; on the other hand, if there are new submission commands after the node confirms the stop request, they will not be processed, and the system will suffer from downtime.

[0007] In this context, providing an appropriate switching solution is a key step to improve system performance. SUMMARY

[0008] In view of the deficiencies of the prior art, the application designs a zero-downtime consistency protocol switching method.

[0009] A zero-downtime consistency protocol switching method, which is specifically implemented by a consistency protocol scheduling layer and a plurality of consistency protocols, adds a unique command sequence number McpSeqNo and a consistency protocol tag McpProcessedBy for each client request, and uses the sequence number McpSeqNo in the consistency protocol scheduling layer; the sequence number McpSeqNo is incremental in the consistency protocol scheduling layer, and when the state machine executes a command, the state machine tracks and saves the latest, i.e., the largest sequence number of each client that has been executed; when the state machine starts to execute a command in a log, the consistency protocol scheduling layer compares the sequence number to check whether it is the next command to be executed, and if so, directly executes the command, otherwise, ignores the command and returns the result of the last execution of the command.

[0010] The consistency protocol scheduling layer abstracts the instantiation process of the replicated state machine into a general layer by running the Paxos protocol, and updates the state of the replicated state machine through the higher abstraction layer.

[0011] The consistency protocol is given a set of consistency protocols {P1, P 2... P n} at the beginning, and the consistency protocol scheduling layer is responsible for switching from one consistency protocol to another; by setting the running protocol instance to another protocol instance, the execution of the update state machine completes the protocol switching.

[0012] The protocol switching configures a general state machine by combining different consistency protocol instances, abstracts the switching adaptation function to the consistency protocol scheduling layer, regards multiple consistency protocols as black boxes, and more modularly uses these different consistency protocols; a plurality of consistency protocols are integrated at the initialization; the method for consistency protocol switching is specifically as follows:

[0013] First, the consistency protocol is initialized to run synchronously at the node initialization, and the server registers the message packet of each phase in the protocol execution process for each consistency protocol, forwards the message packet to each consistency protocol, and makes a certain consistency protocol intercept the message packet required by the consistency protocol; no matter which consistency protocol message packet request arrives, the server will not stop processing the client request during the protocol switching.

[0014] The life cycle of a consensus protocol instance is called a Period. When a switch is performed, a new consensus protocol instance is started and the next Period begins. The life cycle of a Period is strictly bound to the consensus protocol instance. Since Repass-Switch synchronously initializes the consensus protocol at startup, when a new Period is started in one node, all other nodes will start the new Period synchronously, and these nodes are also the participants of the consensus protocol instance after the switch;

[0015] A new Period is started every time a switch is performed. Therefore, after that, the ordering of new request commands occurs in the new Period. During the switch, both consensus protocol instances are ordering the commands submitted by the client. That is, the instance in the previous Period is ordering the commands that are not decided at the beginning of the switch, and the instance in the new Period is ordering the commands that are started after the transition of the switch. In this way, the consensus protocol scheduling layer not only ensures that commands are sequentially scheduled and executed according to different Periods, but also ensures the order of the running consensus protocol instances in the same Period, and realizes the continuity of processing commands.

[0016] When the client issues the first request command, the consensus protocol scheduling layer adds a command sequence number McpSeqNo to it, and adds the consensus protocol tag McpProcessedBy used by the command. At this time, the client does not know which server is the leader, and it will send the command to any node. If the node is not the leader, the request command is forwarded to the leader node. The instance of the currently running consensus protocol Consensus1 starts to process the client request. When the workload changes, the client issues a new request command. The consensus protocol scheduling layer receives the command and switches to the new consensus protocol Consensus2 according to the consensus protocol tag for processing. According to the properties of the consensus protocol, after receiving the confirmation message from the majority of nodes, all correct nodes will create and initialize the instance of the new consensus protocol to be switched to, that is, the new Period2 starts and calls the instance of Consensus2. When other nodes are ready to switch, after receiving the confirmation message from the node, all correct nodes will create and initialize the instance of the new consensus protocol to be switched to. At the same time, the consensus protocol scheduling layer checks whether it is the next command to be executed in the sequence by comparing the command sequence number McpSeqNo. If it is, it updates the state machine state and starts processing the request command. In this way, the consensus protocol is coordinated to switch dynamically and fault-tolerantly without downtime, and the protocol switching delay is minimized.

[0017] For a state machine command, its execution process includes the following:

[0018] The command sequence number cached by the protocol scheduling layer checks whether the command is the next command to be executed, and if so, the command is put into the execution buffer directly; the sequence number cached by the protocol scheduling layer is updated, and the state machine executes the command; for each command in the execution buffer, it is determined whether it is the next command to be executed, if so, the sequence number cached by the protocol scheduling layer is updated and the state machine executes the command, and the command is removed from the buffer, and if it is not the next command to be executed, the loop is exited directly;

[0019] The execution command buffer needs to meet the following properties:

[0020] (1) The commands in the buffer need to be guaranteed to be locally ordered;

[0021] (2) After a command is removed from the buffer, the next command in the buffer needs to be the command with the smallest sequence number among all the commands in the buffer;

[0022] (3) When a new command is written into the buffer due to the inability to execute, the next command in the buffer after writing needs to be the command with the smallest sequence number among all the commands in the buffer.

[0023] The present application has the beneficial technical effects:

[0024] Compared with the existing "stop-redirection" scheme, the consistency protocol switching method proposed in the present application can switch the protocol during running, and can minimize the user's perceived delay. Specifically, the following beneficial effects are included:

[0025] (1) Reduce the user's perceived delay; the consistency protocol switching method proposed in the present application only receives change commands during protocol switching, and is not affected by node requests. At the same time, the consistency protocol scheduling layer ensures its availability by running the Paxos protocol. This coordination between consistency protocols by the consistency protocol scheduling layer can smoothly transition without stopping during the transition, minimizing protocol switching delay.

[0026] (2) Fault tolerance; the "stop-redirection" scheme rejects any new command submitted to the system during the transition, and cannot tolerate faults. The consistency protocol switching method proposed in the present application can switch the consensus protocol during running, so that different consistency protocols can be dynamically selected for dynamic changing workloads, and zero downtime is guaranteed during the transition. The protocol transition period is fault-tolerant. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1 The flow chart of the zero-downtime consistency protocol switching method according to an embodiment of the present application;

[0028] Figure 2 The consistency protocol interface class diagram provided in the embodiment of the application;

[0029] Figure 3 The state machine interface class diagram provided in the embodiment of the application. DETAILED DESCRIPTION

[0030] The application will be further described below in combination with the drawings and embodiments.

[0031] A zero-downtime consistency protocol switching method, which is specifically implemented by a consistency protocol scheduling layer and a plurality of consistency protocols, adds a unique command sequence number McpSeqNo and a consistency protocol tag McpProcessedBy for each client request, and uses the sequence number McpSeqNo in the consistency protocol scheduling layer; the sequence number McpSeqNo is incremental in the consistency protocol scheduling layer, and when a state machine executes a command, the state machine tracks and saves the latest, i.e., the largest sequence number of each client that has been executed; when the state machine starts to execute a command in a log, the consistency protocol scheduling layer compares the sequence number to check whether it is the next command to be executed, and if so, directly executes the command, otherwise, ignores the command and returns the result of the last execution of the command.

[0032] The consistency protocol scheduling layer abstracts the instantiation process of the replicated state machine into a general layer by running the Paxos protocol, and executes the state update of the replicated state machine through the higher abstraction layer.

[0033] The consistency protocol, at the initial stage, gives a set of consistency protocols {P1, P 2... P n The consistency protocol scheduling layer is responsible for switching from one consistency protocol to another; by setting the running protocol instance to another protocol instance, the execution of the state update completes the protocol switching.

[0034] This method of adding a client request sequence number ensures that the request command can be correctly sorted and sequentially executed, and as long as the client does not crash, the entire system exhibits "execution and only once" to the outside. The command issued by a client will be executed only once even if it is retried. At the same time, the consistency protocol scheduling layer adds a consistency protocol tag McpProcessedBy to the client command, which indicates the switching information, i.e., the next consistency protocol to be used.

[0035] The embodiment of the application is defined and described as follows:

[0036] Assume a general distributed system service model, there are n nodes {s1, s2, …, sn}, the nodes are communicated by asynchronous communication mode, that is, the loss, delay and repetition of messages are allowed. The nodes may fail due to crashes, but no malicious behavior occurs, that is, non-Berlin mode, so the system must strictly ensure that most of the nodes are correct, that is, at least n / 2+1 nodes are correct in the n node system. In addition, the arbitration size of most protocols is also n / 2+1, but in Fast Paxos and EPaxos, two consistency, in order to make a quick decision in two communication processes, the basic arbitration size cannot meet its correctness, at least 3 / 4n nodes are required to ensure correctness.

[0037] In addition, any node can send messages to other nodes, and can also receive messages from other nodes. The system ensures that if a client request is not sent, at least more than half of the replica nodes can receive it, and eventually determine in the consistent instance i, and the order of the request command on each replica is exactly the same, that is, each replica will process the message in the totally ordered sequence.

[0038] The present application selects the following six consistency protocols as examples for optimization of the above different categories, specifically:

[0039] (1) Fast Paxos: This protocol aims to further reduce the cost of reaching consensus by running a Propose phase message for all Fast Paxos instances in state machine replication. This allows the client to send commands directly to all replicas and immediately send Accept phase messages to the leader, which reduces the number of message transmissions and allows conflict-free commands to be submitted directly, thereby reducing end-to-end latency. However, Fast Paxos requires at least one communication step to resolve conflicts, and in a high-concurrency scenario, the probability of conflict is very high, and the cost of conflict resolution is also very large.

[0040] (2) Flexible Paxos (FPaxos): This protocol believes that in the first and second stages, the majority quorum is unnecessary. Instead, Flexible Paxos shows that as long as all groups in stage 1 intersect with all groups in stage 2, the Paxos property remains unchanged. This makes it possible to deploy a Paxos protocol with a smaller arbitration size in the second stage, thereby providing better performance at the expense of reducing fault tolerance.

[0041] (3) Multi-Paxos: This protocol is a basic single-leader protocol, and all requests are forwarded to the leader for processing.

[0042] (4) Mencius: In order to prevent the leader node from becoming a performance bottleneck of the distributed system, the Mencius algorithm takes turns to make each node become a leader to be responsible for the execution of instructions, which balances the access load of data replicas. However, once any replica in the Mencius algorithm cannot be accessed, other replicas cannot provide access services before the system detects the failed replica, and the availability is poor.

[0043] (5) M2Paxos: It is a multi-leader consensus protocol, which embeds the command ownership acquisition phase into the protocol process to ensure that the node with ownership of a group of commands can make decisions on those commands independently, avoiding conflicts.

[0044] (6) Egalitarian Paxos (EPaxos): It is a leaderless consensus algorithm that completely decentralizes conflict resolution and command submission, has higher throughput, and provides better scalability and availability.

[0045] The client sends a command request sequence Seq, the consistency protocol scheduling layer executes the command in sequence, updates the state machine state, and switches if all state machine sequences are consistent.

[0046] The execution process of the protocol switching of the embodiment of the application is as follows:

[0047] Suppose that the system is a cluster composed of three nodes P0, P1 and P2, and two request commands sent by the client need to be processed by two different consistency protocols to make the system optimal, so protocol switching is needed. The specific process is as follows:

[0048] As shown in the accompanying Figure 1 , first, the two consistency protocols are also initialized and run synchronously at the node initialization time, and the server registers the message packet of each phase in the protocol execution process for each consistency protocol, and forwards the message packet to each consistency protocol, so that a certain consistency protocol will intercept the message packet it needs. No matter which consistency protocol message packet request arrives, the server will not stop processing the client's request when switching protocols, so the problem of different synchronization between different replicas due to different initialization times is also solved.

[0049] The life cycle of a working instance of a consensus protocol is called a Period. Whenever a switch is performed, a new instance of a consensus protocol is started and begins the next Period. The life cycle of a Period is strictly bound to the instance of a consensus protocol. From left to right, the first vertical line indicates the start of the initialization of a consensus protocol, the second vertical line indicates the start of Period 1, and the second vertical line indicates the start of Period 2. Since Repass-Switch synchronously initializes a consensus protocol at startup, whenever a new Period is started in one node, almost all other nodes in the system will start the new Period at the same time, and these nodes are also participants of the instance of a consensus protocol after the switch.

[0050] When the first request command is issued by a client, the consensus protocol scheduling layer adds a command sequence number McpSeqNo to it and adds a consensus protocol tag McpProcessedBy used by the command. At this time, the client does not know which server is the leader, and it sends the command to any node. If the node is not the leader, the request command is forwarded to the leader node. In this way, the instance of the consensus protocol Consensus 1 used in the command is started to begin processing the client request. When the workload changes, the client issues a new request command, and the consensus protocol scheduling layer receives the command and starts using a new consensus protocol Consensus 2 according to the consensus protocol tag. According to the properties of the consensus protocol, after receiving the confirmation message from a majority of nodes, all correct nodes will create and initialize a new instance of the consensus protocol to be switched to, that is, the new Period 2 starts and calls the instance of Consensus 2. When P0 notifies other nodes to prepare for switching, the node redirects the second command request of the client to the newly created instance of the consensus protocol, and at the same time, the consensus protocol scheduling layer checks whether it is the next command to be executed in the sequence by comparing the command sequence number McpSeqNo, and if so, it updates the state machine state and begins processing the request command.

[0051] A new Period is started every time a switch is performed, so after this, the ordering of new request commands occurs in the new Period, which means that at any time during the switch, two instances of a consensus protocol are ordering commands submitted by clients. That is, the instance in the previous Period orders commands that are undecided at the start of the switch, and the instance in the new Period orders commands that start from the transition of the switch. In this way, the consensus protocol scheduling layer not only ensures that commands are sequentially scheduled and executed according to different Periods, but also ensures the order of the running instances of a consensus protocol in the same Period, achieving the continuity of processing commands.

[0052] The application features that any consensus protocol can be added to the framework at the beginning, and the commands can be executed in order during switching by the consensus protocol scheduling layer.

[0053] As shown in the accompanying Figure 2 Each consensus protocol needs to implement the CP (Consensus Protocol) interface, which is used to propose a proposal and write the return value back to the provided channel. The method returns immediately and does not block.

[0054] The application initially registers the message package of each stage in the protocol execution process for each consensus protocol, i.e., the GobRegister() function on the left side in Table 1. Gob is a format for serializing and deserializing program data in binary form in the Go language, which is used for communication between services.

[0055] Each consensus protocol is also synchronized and initialized at the beginning, so that no matter which consensus protocol message package requests, the corresponding consensus protocol can intercept the required message package, so that the protocol can process the request when switching. According to the execution process of the Paxos protocol, which includes three stages of Prepare, Accept, and Learn, the message package is divided into seven types of Prepare{}, Promise{}, Accept{}, Accepted{}, LearnRequest{}, LearnResponse{}, and ExecuteResult{}. Table 1 takes Multi-Paxos as an example to introduce the structure of the seven message packages, and the message package implementation of the remaining five consensus protocols is similar to the above. They are used by Proposer, Acceptor, and Learner in the subsequent decision-making process.

[0056] Table 1 Protocol message package structure body

[0057]

[0058]

[0059] As known from the above, the request command of the client is a set of inputs of the state machine, so as shown in the accompanying Figure 3 It needs to implement a method that can execute Command, which is used to execute the command when the consensus protocol learns the result, to change the state machine state.

[0060] The command structure executed by the state machine is introduced in Table 2 below, wherein Key, Value, Operation, and Id are basic fields, and the three fields of McpSeqNo, McpProcessedBy, and ProposerId are assigned and used by the consistency protocol scheduling layer and each protocol internally.

[0061]

[0062] The protocol switching algorithm is the core algorithm, i.e., the algorithm for implementing protocol zero-downtime switching by the consistency protocol scheduling layer. Before introducing the protocol switching algorithm, the following global variables maintained by the consistency protocol scheduling layer are introduced: currCP is the consistency protocol currently in use, currCPLock is the read-write lock of the consistency protocol, seqNo is the self-incrementing sequence number, seqNoLock is the read-write lock of the sequence number, and pendingCommands is the pending command buffer.

[0063]

[0064]

[0065] The algorithm introduces the process of starting and coordinating the consistency protocol switching. When the server receives a request issued by a client, the protocol scheduling layer guarantees the sequential execution of the command by adding a sequence number to the command, then encapsulates the client request as a message packet of the corresponding protocol according to the consistency protocol determined by the current system state, and calls the Propose() method of the corresponding protocol to process the request.

[0066] By calling the corresponding consistency protocol, the consistent value of the client request learned by the protocol after being scheduled by each node can be obtained, which is encapsulated as a state machine command entity, and the ProxyExecute() method is called by the protocol scheduling layer to proxy execute the state machine command. After the state machine command is executed, the request is sent back to the client by the protocol internally through the client address in the protocol message packet.

[0067] For a state machine command, the execution process includes the following stages:

[0068] According to the command sequence number cached by the protocol scheduling layer, it is checked whether the command is the next command to be executed. If yes, the protocol scheduling layer cached sequence number is updated, and the state machine executes the command. If not, the command is directly put into the pending buffer. For each command in the pending buffer, it is determined whether it is the next command to be executed. If yes, the protocol scheduling layer cached sequence number is updated, and the state machine executes the command, and the command is removed from the buffer. If it is not the next command to be executed, the loop is directly exited.

[0069] For the to-be-executed command buffer, the following properties need to be met:

[0070] (1) The commands of the buffer need to be guaranteed to be locally ordered;

[0071] (2) When a command is taken from the buffer, the next command in the buffer needs to be the command with the smallest sequence number among all the commands in the buffer;

[0072] (3) When a new command is written into the buffer due to the inability to execute, the next command in the buffer after writing needs to be the command with the smallest sequence number among all the commands in the buffer. Through the above properties, it can be guaranteed that after processing the new command or the command of the buffer, the first command of the buffer can be directly determined whether it is executable, if it is executable, it enters the buffer processing stage until all the commands of the buffer are executed, or the buffer is not empty but has no executable command; if it is not executable, it directly waits for a new command. The present application manages the to-be-executed commands in the buffer by maintaining a small top heap data structure, and guarantees that the above properties are established. When a new command needs to be put into the buffer due to the inability to execute, it is completed by calling the Push() method of the small top heap; when a command is executed and starts to process the buffer, since the top element of the heap is the first command of the buffer (i.e., the command with the smallest sequence number among all the commands in the buffer), if the command is executable, it is popped out by calling the Pop() method of the small top heap, and the property of the small top heap guarantees that the first command in the buffer is still the command with the smallest sequence number, and the above property still holds, and the algorithm can execute normally and will not fall into a deadlock.

[0073] In summary, the present application proposes a zero-downtime consistency protocol switching method Repass-Switch for the switching problem in protocol dynamic adaptation, which can switch from one consistency protocol suitable for a scene to another consistency protocol suitable for another scene when facing dynamically changing workloads, realizes zero-downtime switching transition of the protocol, and can minimize the protocol switching delay. The method configures a general state machine by combining different consistency protocol instances, and abstracts the switching function to the consistency protocol scheduling layer for implementation. The method does not change the consistency protocol itself, so various consistency protocols can be integrated at the beginning, and switching between these consistency protocols can be coordinated in a dynamic fault-tolerant manner. The present application can enable the protocol to switch at runtime with zero downtime, and can minimize the switching delay.

Claims

1. A zero-downtime consensus protocol switching method, characterized in that, Specifically, it is implemented in two parts: a consensus protocol scheduling layer and multiple consensus protocols; The switching method adds a unique command sequence number McpSeqNo and a consensus protocol tag McpProcessedBy to each client request, which are used in the consensus protocol scheduling layer. The sequence number McpSeqNo is incremented in the consensus protocol scheduling layer. When the state machine executes a command, it tracks and saves the most recent, i.e., the largest, sequence number that has been executed for each client. When the state machine starts executing a command in the log, the consensus protocol scheduling layer compares its sequence number to see if it is the next command to be executed. If it is, it is executed directly; otherwise, the command is ignored, and the result of the last execution of the command is returned. The consensus protocol is initially given a set of consensus protocols {P1, P2}. 2 ... P n The consensus protocol scheduling layer is responsible for switching from one consensus protocol to another; it enables the execution update state machine to complete the protocol switch by setting a change from the running protocol instance to another protocol instance. The lifecycle of a consensus protocol instance is called a Period. Whenever a switch is performed, a new consensus protocol instance will enter the working state and start a new Period. All other nodes will start their new Periods synchronously. These nodes are also participants in the consensus protocol instance after the switch. The ordering of new request commands occurs within the new Period. At any point during the switchover, both consensus protocol instances are ordering commands submitted by clients; that is, the instance in the previous Period orders commands that were not decided at the start of the switchover, while the instance in the new Period orders commands that began during the switchover transition.

2. The zero-downtime consensus protocol switching method according to claim 1, characterized in that, The consensus protocol scheduling layer abstracts the instantiation process of the replicated state machine into a general layer by running the Paxos protocol, and performs the update of the replicated state machine's state through this higher abstraction layer.

3. The zero-downtime consensus protocol switching method according to claim 1, characterized in that, Protocol switching configures a general state machine by combining different consensus protocol instances, abstracts the switching adaptation function to the consensus protocol scheduling layer, treats multiple consensus protocols as a black box, uses these different consensus protocols in a more modular way, and integrates many consensus protocols during initialization.

4. The zero-downtime consensus protocol switching method according to claim 1, characterized in that, The specific method for switching consensus protocols is as follows: First, the consensus protocol is initialized and run synchronously when the node is initialized. The server registers message packets for each stage of the protocol execution process for each consensus protocol and forwards the message packets to each consensus protocol, so that a certain consensus protocol can intercept the message packets it needs. No matter which consensus protocol's message packet request arrives, the server will not stop processing the client's request when switching protocols. When a client issues its first request command, the consensus protocol scheduling layer adds a command sequence number McpSeqNo and a consensus protocol tag McpProcessedBy to it. At this point, the client does not know which server is the leader and will send the command to any node. If the node is not the leader, the request command is forwarded to the leader node. The currently running consensus protocol instance Consensus1 then begins to process the client request. When the workload changes and the client issues a new request command, the consensus protocol scheduling layer receives this command and switches to the new consensus protocol Consensus2 for processing based on the consensus protocol tag. According to the properties of the consensus protocol, after receiving confirmation messages from a majority of nodes, all correct nodes will create and initialize an instance of the new consensus protocol to which they are to switch, that is, the new Period2 starts and calls the Consensus2 instance. When other nodes are ready to switch, after receiving confirmation messages from the nodes, all correct nodes will create and initialize instances of the new consensus protocol to which they are switching. At the same time, the consensus protocol scheduling layer checks whether it is the next command to be executed in the sequence by comparing the command sequence number McpSeqNo. If it is, it will update the state machine state and start processing the request command. This enables the consensus protocols to coordinate and switch without downtime in a dynamic and fault-tolerant manner, minimizing the protocol switching latency. The execution process of a state machine command includes the following: Check if the command is the next command to be executed based on the command sequence number cached in the protocol scheduling layer. If it is, proceed; otherwise, directly put the command into the execution buffer. Update the sequence number cached in the protocol scheduling layer, and execute the command in the state machine. For each command in the execution buffer, determine if it is the next command to be executed. If it is, update the sequence number cached in the protocol scheduling layer and execute the command in the state machine, and remove the command from the buffer. If it is not the next command to be executed, exit the loop directly.

5. The zero-downtime consensus protocol switching method according to claim 4, characterized in that, The lifecycle of the Period is strictly bound to the instance of the consensus protocol.

6. The zero-downtime consensus protocol switching method according to claim 4, characterized in that, The buffer for commands to be executed must satisfy the following properties: (1) The commands in the buffer need to be locally ordered; (2) When a command is taken from the buffer, it is necessary to ensure that the next command in the buffer is the command with the smallest sequence number among all commands in the buffer; (3) When a new command is written to the buffer because it cannot be executed, it is necessary to ensure that the next command in the buffer after the command is written is the command with the smallest sequence number among all commands in the buffer.

Images