WO2018120174A1 - 故障恢复的方法、设备和系统 - Google Patents

故障恢复的方法、设备和系统 Download PDF

Info

Publication number
WO2018120174A1
WO2018120174A1 PCT/CN2016/113848 CN2016113848W WO2018120174A1 WO 2018120174 A1 WO2018120174 A1 WO 2018120174A1 CN 2016113848 W CN2016113848 W CN 2016113848W WO 2018120174 A1 WO2018120174 A1 WO 2018120174A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
log
leader
latest
log entry
Prior art date
Application number
PCT/CN2016/113848
Other languages
English (en)
French (fr)
Inventor
侯杰
宋跃忠
林程勇
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2016/113848 priority Critical patent/WO2018120174A1/zh
Priority to EP16925925.6A priority patent/EP3553669A4/en
Priority to CN201680091858.0A priority patent/CN110431533B/zh
Publication of WO2018120174A1 publication Critical patent/WO2018120174A1/zh
Priority to US16/456,679 priority patent/US11102084B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/30—Decision processes by autonomous network management units using voting and bidding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • G06F11/1425—Reconfiguring to eliminate the error by reconfiguration of node membership
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements

Definitions

  • FIG. 7 is a schematic diagram of a system in an embodiment of the present invention.
  • Last log index (English: lastLogIndex) variable: used to identify the index of the last log stored on a node in the Raft cluster.
  • the log is stored in an array, and the index describes the storage order of the log.
  • each state variable described above is separately maintained on each node in the Raft cluster, that is, each node generates and maintains each state variable itself, and these state variables are unique on each node.
  • the node obtains votes from more than half of the servers in the Raft cluster, it is converted to Leader by Candidate and begins to broadcast the heartbeat;
  • the logs processed by each node in the Raft cluster can be stored on a non-volatile storage medium, for example, a storage medium such as a disk or a hard disk that is not lost after power-off; or can be stored on a volatile storage medium, for example, A storage medium in which data is lost after power failure.
  • these nodes do not store the log data on a non-volatile medium such as a disk, but instead choose to store the log data on a volatile storage medium, and the log data is read and written in the memory. The reading and writing speed is faster.
  • the Raft cluster includes at least three nodes.
  • the number of nodes with the latest logs included in the distributed cluster system affects one of the nodes with the latest logs, and restarts a node with no latest logs to become the leader leader, it may Causes the latest log to be lost.
  • the number of nodes with the latest logs can be M
  • M is
  • N is the number of nodes in the Raft cluster
  • N is an odd number greater than or equal to 3.
  • Node2 When Node2 receives the request voting message sent by Node3, it compares lastLogIndex and lastLogTerm on two nodes of Node2 and Node3. If Node2's lastLogTerm is more Large, or, Node2 and Node3 have the same lastLogTerm but Node2's lastLogIndex is larger. If it is determined that Node2's own saved log is more complete, the voting request is rejected. Similarly, when Node1 receives the request voting message sent by Node3, it compares lastLogIndex and lastLogTerm on Node1 and Node3.
  • the solution provided by the embodiment of the present invention includes a 301 part, a 302 part, a 303 part, and a 304 part, where the 301 part and the 304 part are executed on the first node, and the 303 part and the 304 part are executed on the second node, respectively Description.
  • the voting state is set to be unable to vote, and the voting state is used to indicate whether the first node can vote in the process of electing the leader in the distributed cluster system.
  • the method for determining the reason why the log of the first node is empty may be implemented by saving the second identification information in the non-volatile storage medium of the first node.
  • the second identifier information is used to indicate whether the first node has received the first log from other nodes or user equipments in the distributed cluster system. For example, when the Raft cluster is initially started, the log of the first node is empty (the log has never been received before), and the second identifier information is 0, which represents false (English: False), and is used to indicate the first A node has not received the first log from other nodes or client devices in the distributed cluster system.
  • the client device is a client (English: Client) node outside the Raft cluster, and may be a network forwarding device, such as a router or a switch, or an application server or the like.
  • the second identifier is set to be 1 when the Raft cluster is running. , representing true (English: True), is used to indicate that the first node has received the first log from other nodes or user equipments in the distributed cluster system.
  • the first node fails to restart, if the first node confirms that the second identification information is 1 (ie, Ture), and the log stored in the memory of the first node is empty, determining the first A node lost its log due to a failed reboot.
  • the first node After the first node fails to restart, if the first node confirms that the second identifier information is 0 (ie, False), and the log stored in the memory of the first node is empty, determining the first The initial boot log of a node is empty. That is, because the nodes in the cluster are started for the first time when the Raft cluster is initially started, the memory log is empty.
  • the embodiment of the present invention provides a more A simple and specific way of configuring the second identification information.
  • the voting state of the first node after the fault is restarted to be unable to vote it is ensured that the third node that has no latest log before the fault cannot be selected as the Leader in the Leader election of the Raft cluster, and The second node with the latest log before the fault can be elected as the new leader, so that the latest log before the fault can be released (or synchronized) to other nodes in the Raft cluster, which is the latest log before the fault in Raft.
  • the cluster will not be lost, which improves the security of the Raft cluster.
  • Node2 initiates a voting request, you can get 1 vote for yourself and 1 ticket for Node3 (the principle of Node3 vote for yes. For details, please refer to the description of the technical problem shown in Figure 2a above). Tickets, more than half (1.5 votes), were elected as Leader. The latest log a is synchronized to Node1 and Node3 so that the latest log a is not lost when Node1 fails to restart.
  • Node2 initiates a voting request, you can get 1 vote for yourself and 1 vote for Node3 (because Node2 has the latest log a, the lastLogIndex of Node2 is greater than the lastLogIndex of Node3, and Node3 will give Node2 Vote in favor.
  • the latest log a is synchronized to Node1 and Node3 so that the latest log a is not lost when Node1 fails to restart.
  • the second node is a leader. Specifically, after the first node fails to restart, the second node obtains more than half of the pro-voting in the distributed cluster system to become the new leader, and the more than half of the pro-voting includes the second node. The own vote in favor and the vote of the third node in favor, the second node cannot obtain the vote of the first node in favor.
  • the third node without the latest log before the fault cannot be elected as the leader, thereby ensuring that the first log of the latest log before the fault is secured
  • the two nodes can be successfully elected as Leader.
  • the second node is a leader including the following three cases, which are illustrated as follows.
  • the Node 2 as the Follower becomes a new leader by election.
  • Node1 fails, Node2 and Node3 cannot receive the heartbeat sent by Node1 as the leader.
  • the election timer expires, causing a new round of Leader election, and Node2 becomes the new Leader.
  • the new leader elected by the Raft cluster system after the Node1 failure restarts sends the copy log entry message to the Node1, so that the Node1 restores the voting right. Therefore, in the case that the Raft cluster system performs a new round of Leader election when the Node1 fails to restart, the system can still work normally, further improving the security of the system.
  • the Raft cluster does not perform a new round of Leader elections.
  • the leader ie, the leader of the distributed cluster system before the first node fails to restart
  • the leader at this time can also be regarded as the old leader before the first node fails to restart.
  • the old leader sends the replication log entry message described below to the Node1, so that the Node1 restores the voting right, and ensures that when the Node1 fails to restart, the Raft cluster system does not have a new round of Leader election, the system still It works well and improves the security of the system.
  • the copy log entry message (English: ReplicatedLogEntry) includes a log entry, and the second node as the leader updates all of its own log entries to the first node synchronously.
  • the number of the copy log entry messages may be equal to the number of the log entries or may be smaller than the number of the log entries.
  • the number of log entries is M
  • the number of the copy log entry messages is N
  • N is less than or equal to M
  • N and M are positive integers greater than or equal to 1.
  • N indicates that one log entry is included in each of the copy log entry messages.
  • each of the duplicate log entry messages includes multiple log entries (ie, a set of log entries) or one log entry.
  • the log entry includes the latest log a, and then Node1 receives and saves the latest log a synchronized by Node2, which is the latest log a is not lost after the Node1 fails to restart.
  • the timing at which the first node sets the voting status of the first node to be voteable may include the following cases.
  • the Nth replication log entry message includes the latest log before the failure
  • the first node receives the Xth replication log entry message sent by the second node (X is greater than A positive integer equal to 1 and less than N) sets the voting status to vote and restores the voting rights in the Leader election. That is, the first node has not been synchronized to the fault before The latest log is restored to the right to vote.
  • the second node fails, the latest log before the failure will be lost, and since the first section already has the right to vote, in the new round of the election, the vote will be voted for the other.
  • the node for example, is voted for the third node, so that the third node becomes a new leader, and the Raft cluster continues to run, but does not recognize that the log has been lost, thus posing a security risk.
  • the second node is not faulty, and after the right to vote is resumed, the latest log before the fault is continuously synchronized to the first node, the latest log before the fault is not lost, and the second log will not occur.
  • the Nth replication log entry message includes the latest log before the failure
  • the first node receives the Xth replication log entry message sent by the second node (X is equal to The positive integer of N) sets the voting status to vote, and restores the voting rights in the Leader election. That is, when the first node synchronizes to the latest log before the failure, the right to vote is restored. At this time, if the second node fails, the latest log before the failure will not be lost, and no security risks will occur.
  • the present invention adds first identifier information to the copy log entry message, where the first identifier information is used to indicate whether the log entry carried in the copy log entry message includes the second node becomes The last log before the new leader.
  • the copy log entry message is used to indicate that the first node saves the log entry and does not The voting status of the first node is changed, that is, the voting rights of the first node are not restored.
  • the first identifier information indicates that the log entry does not include the last log before the second node becomes the leader, so that the duplicate log entry message is synchronized with the latest log before the fault (that is, the old log before the fault) ), still operate normally.
  • the copy log entry message is used to indicate that the first node is to use the date
  • the entry is saved and the voting status of the first node is set to be voted.
  • the last log before the second node becomes the leader may be the latest log before the fault, or may be a new log newly received after the fault, which is illustrated by the following examples.
  • the last log before the second node becomes the leader is the latest log before the fault.
  • the Node2 sends a ReplicatedLogEntry message Y to the Node1, and the ReplicatedLogEntry message Y includes the The latest log a and the first identification information a, the first identification information a indicates that the latest log a is the last log before the Node 2 becomes the leader.
  • the Node1 After receiving the ReplicatedLogEntry message Y, the Node1 confirms that the Node1 receives the latest log a according to the first identification information a, saves the latest log a, and sets the voting state of Node1 to vote, and restores the voting right of Node1.
  • the last log before the second node becomes the leader is a new log newly received after the fault.
  • Node2 acts as a leader, and when Node1 fails to restart, it receives a log b sent by the user equipment. Then the Raft cluster initiates a new round of Leader election. After Node1 fails to restart, Node2 continues to elect a new round of the leader, and log b is the last log before Node2 becomes the elected new leader.
  • the Node2 sends a ReplicatedLogEntry message Y to the Node1, the ReplicatedLogEntry message Y includes the latest log a and the first identification information a, and the first identification information a indicates that the latest log a is not the last log before the Node2 becomes the Leader. .
  • Node1 After receiving the ReplicatedLogEntry message Y, Node1 saves the latest log a, and does not set the voting status of Node1 to vote, and does not restore the voting rights of Node1.
  • the Node2 continues to send a ReplicatedLogEntry message Z to the Node1, the ReplicatedLogEntry message Z includes the log b and the first identification information b, and the first identification information b indicates that the log b is the last log before the Node2 becomes the Leader.
  • Node1 After receiving the ReplicatedLogEntry message Z, Node1 saves the log b and sets the voting status of Node1 to vote, and restores the voting rights of Node1. It should be noted that the log b only As an example, when the Node1 fails to be restarted, multiple new logs other than the log b, such as the log c and the log d, can be received, which is not limited herein. In this case, the principle is the same as above, and will not be described here.
  • Node1 will not be able to resume voting after receiving the latest log a.
  • Node1 does not receive the latest log a, the right to vote cannot be restored.
  • the Node3 node cannot be elected as the Leader (because the Node1 and Node2 are not allowed to vote), so that the Raft cluster cannot select the Leader, and the log will be lost and the fault will be reported. Notify the administrator to solve the problem as soon as possible, avoiding the insecure potential caused by the Raft cluster log has been lost and continues to run.
  • the first node By adding the first identification information to the replication log entry message, the first node is restored to the right to vote after ensuring that the latest log before the failure is received, thereby preventing the Raft cluster from recognizing that the Raft cluster cannot recognize The log is lost and continues to run, causing security problems.
  • FIG. 5a shows a possible structural diagram of the first network device involved in the above embodiment.
  • the first network device 500A is used as the first node, and is applied in a distributed cluster system.
  • the number of nodes including the latest log included in the distributed cluster system affects one of the nodes having the latest log. After the restart, the election does not have the latest log.
  • the node becomes the leader leader
  • the distributed cluster system includes at least the first node, the second node, and the third node, wherein the first node and the second node have the latest log before the failure.
  • the third node does not have the latest log before the fault
  • the first network device 500A includes:
  • the processing unit 504A is configured to set a voting state to be unable to vote after the first node fails to restart, and the voting state is used to indicate whether the first node can elect a leader in the distributed cluster system. Vote.
  • the receiving unit 502A is configured to receive a replication log entry message from the second node, where the second node is a Leader.
  • the processing unit 504A is further configured to set a voting state of the first node to be voteable according to the copy log entry message.
  • the second node is a new leader elected by the distributed cluster system after the first node fails to restart.
  • the copy log entry message includes a log entry and first identifier information, where the first identifier information is used to indicate whether the log entry includes the last log before the second node becomes the new leader.
  • the processing unit 504A confirms, according to the first identifier information, that the log entry includes the last log before the second node becomes the new leader, saves the log entry, and stores the first node.
  • the voting status is set to vote.
  • the first network device 500A also includes a volatile storage unit for storing the log entries.
  • the processing unit 504A is further configured to: according to the first identifier information, confirm that the log entry does not include the last log before the second node becomes a leader, save the log entry, and retain the first log The voting status of a node is not voting.
  • the processing unit 504A determines that the log of the first node is empty because the fault restart causes the log to be lost, and the voting state is set to be unable to vote.
  • the first node further includes a non-volatile storage unit, where the second identifier information is saved in the non-volatile storage unit, where the second identifier information is used to indicate whether the first node is The first log was received from other nodes or client devices in the distributed cluster system.
  • the processing unit 504A is configured to confirm that the second identifier information indicates that the first node has received the first log, and the current log of the first node is empty.
  • the processing unit 504A is configured to determine that the first node has lost a log due to a faulty restart.
  • the first network device 500A of the embodiment of the present invention may implement various implementation functions and steps in the first node in the foregoing embodiment corresponding to FIG. 2a to FIG. 4b. For brevity, details are not described herein again.
  • FIG. 5b shows still another possible structure of the first network device involved in the above embodiment.
  • the first network device 500B includes a receiver 510B, a processor 520B, a transmitter 530B, a random access memory 540B, a read only memory 550B, and a bus 560B.
  • the processor 520B is coupled to the receiver 510B, the transmitter 530B, the random access memory 540B, and the read only memory 550B via the bus 560B.
  • the booting is performed by the bootloader booting system in the basic input/output system or the embedded system in the read-only memory 550B, and the first network device 500B is booted into the normal running state.
  • the application and operating system are run in the random access memory 540B such that:
  • Receiver 510B receives a duplicate log entry message from the second node, the second node being a Leader.
  • the sender 630B is configured to send a replication log entry message to the first node, where the replication log entry message is used to indicate that the first node can vote in a leader election.
  • the second network device 600B in the embodiment of the present invention may correspond to the second node in the embodiment corresponding to the foregoing FIG. 2a to FIG. 4b, and the processor 620B, the transmitter 630B, and the like in the second network device 600B may be implemented.
  • the processor 620B is configured to perform all operations of the processing unit 604A of the second network device of FIG. 6a
  • the transmitter 630B is configured to perform all operations of the transmitting unit 606A of the second network device of FIG. 6a.
  • the read only memory 650B is used to perform all of the operations of the nonvolatile memory unit of Figure 6a. For the sake of brevity, it will not be repeated here.
  • FIG. 7 is a schematic diagram of a system for fault recovery according to an embodiment of the present invention.
  • system 700 includes a first network device 710 and a second network device 720.
  • the first network device 710 is any of the first network devices described above with reference to Figures 5a, 5b
  • the second network device 720 is any of the second network devices described above with reference to Figures 6a, 6b.
  • each device in the system refer to the related chapters in Figure 5a-5b and Figure 6a-6b above, and details are not described here.
  • the size of the sequence numbers of the above processes does not mean the order of execution, and the order of execution of each process should be determined by its function and internal logic, and should not be taken to the embodiments of the present invention.
  • the implementation process constitutes any limitation.
  • the disclosed systems, devices, and methods may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division, and the actual implementation may have another
  • the manner of division, such as multiple units or components, may be combined or integrated into another system, or some features may be omitted or not performed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the functions may be stored in a computer readable storage medium if implemented in the form of a software functional unit and sold or used as a standalone product.
  • the technical solution of the present invention which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including
  • the instructions are used to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

Abstract

一种故障恢复的方法，应用在分布式集群系统，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中第一节点和第二节点拥有所述故障前的最新日志，第三节点没有所述最新日志，该方法包括：第一节点故障重启后，投票状态设置为不能投票，投票状态用于指示第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票；第一节点接收来自第二节点的复制日志条目消息，将第一节点的投票状态设置为可以投票，第二节点为Leader。该方法有助于提高分布式集群系统的安全性。

Description

故障恢复的方法、设备和系统 技术领域
本发明实施例涉及通信领域，尤其涉及一种故障恢复的方法、设备和系统。
背景技术
分布式系统是一种组件位于联网计算机上，组件间通过传递消息来通信和协调他们动作的系统模型。组件彼此交互以便实现共同的目标。组件的并发性是分布式系统的显着特征之一。强一致性是在并发编程(例如，在分布式共享存储器，分布式事务)领域中使用的一致性模型之一。强一致性要求：所有并行进程(或节点、处理器等)以相同的顺序看到所有访问。木筏(英文：Raft)算法是一种用来保证强一致性的典型算法，该算法应用在开放日光平台(英文：OpenDaylight platform，ODL)、开放网络操作系统(英文：Open Network Operating System，ONOS)等业界主流分布式控制器系统中。
Raft将一致性问题分为Leader选举、日志复制和安全性保证三个子问题。Raft将来自客户端的操作指令转化为日志，先存储(用于后续系统故障后恢复时的依据)，然后根据日志进行一致性同步，然后同步成功后，服务器标记该日志为提交状态(该提交状态指示该日志在该系统中已经具有了一致性。该系统中的大于一半的服务器已经保存了该日志，就能够保证一致性)，并执行操作指令。日志被标记为提交状态的顺序即为指令被执行的顺序。Raft算法过程保证Raft集群中所有服务器的日志被提交的顺序保持一致。
然而，在包括至少三个节点的分布式系统中，当所述分布式系统包括的 拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader时，可能会造成所述最新的日志丢失的问题，降低了所述分布式系统的安全性。
发明内容
本发明实施例提供的故障恢复的方法、设备和系统，解决了当所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader时，可能会造成所述最新的日志丢失的问题。
为了解决上述问题，本发明实施例第一方面提供了一种故障恢复的方法，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，所述方法包括：所述第一节点故障重启后，投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票；所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票，所述第二节点为Leader。
通过将故障重启后的所述第一节点的投票状态设置为不能投票，保证了该故障前没有最新日志的所述第三节点在Raft集群的Leader选举中不能被选为Leader，而该故障前拥有最新日志的所述第二节点能够当选为新的Leader，从而能够将该故障前的最新日志发布(或同步)到Raft集群中的其它节点，是该故障前的最新日志在Raft集群中不会丢失，提升了Raft集群的安全性。
在第一方面的第一种可能的实现方式中，所述第二节点为所述第一节点故障重启前的所述分布式集群系统的leader。
通过所述第一节点故障重启前的所述分布式集群系统的leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统没有新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
在第一方面的第二种可能的实现方式中，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。
通过所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统进行新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票包括：所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；所述第一节点根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
通过在所述复制日志条目消息中增加第一标识信息，使得所述第一节点在确保收到了所述故障前的最新日志后，才被恢复投票的权利，从而避免了Raft集群不能识别出已经丢失了日志，依然继续运行，造成了不安全隐患的问题。
结合第一方面的第二种或第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述方法还包括：所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述 第二节点成为所述新的Leader前的最后一条日志；所述第一节点根据所述第一标识信息确认所述日志条目不包括所述第二节点成为Leader前的最后一条日志，将所述日志条目保存并保留所述第一节点的投票状态为不能投票。
通过第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志，使所述复制日志条目消息在同步的不是该故障前的最新日志(即该故障前的老日志)时，仍然能正常操作。
结合第一方面或第一方面的第一种至第四种任一可能的实现方式，在第一方面的第五种可能的实现方式中，所述第一节点故障重启后，投票状态设置为不能投票包括：所述第一节点启动后，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
通过在确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，才将投票状态设置为不能投票，保证了在系统初始情况下，不会将所述第一节点的投票状态设置为不能投票，从而避免了错误。
结合第一方面的第五种可能的实现方式，在第一方面的第六种可能的实现方式中，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志包括：所述第一节点在非易失性存储介质中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；所述第一节点启动时，所述第一节点确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述第一节点确定所述第一节点因为故障重启导致丢失了日志。
通过在非易失性存储介质中保存第二标识信息，本发明实施例提供了一种更简单、安全的方法保证正确的识别和设置投票状态，避免因错误识别造成的系统不能正常工作。
结合第一方面的第六种可能的实现方式，在第一方面的第七种可能的实现方式中，所述方法还包括：所述第二标识信息的初始值设置为假False， 用于指示所述第一节点初次启动，还未从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；当所述第一节点从所述分布式集群系统中的其它节点或者用户端设备接收到第一条日志后，将所述第二标识信息设置为真True，用于指示所述第一节点曾经接收过所述第一条日志。
通过将第二标识信息设置为False或True，本发明实施例提供了一种更简洁、具体的配置该第二标识信息的方式。
本发明实施例第二方面提供了一种故障恢复的方法，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，所述方法包括：所述第一节点故障重启后，所述第二节点为Leader；所述第二节点向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
通过将故障重启后的所述第一节点的投票状态设置为不能投票，保证了该故障前没有最新日志的所述第三节点在Raft集群的Leader选举中不能被选为Leader，而该故障前拥有最新日志的所述第二节点能够当选为新的Leader，从而能够将该故障前的最新日志发布(或同步)到Raft集群中的其它节点，是该故障前的最新日志在Raft集群中不会丢失，提升了Raft集群的安全性。在第二方面的第一种可能的实现方式中，所述第二节点为所述第一节点故障重启前的所述分布式集群系统的leader。
通过所述第一节点故障重启前的所述分布式集群系统的leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统没有新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
在第二方面的第二种可能的实现方式中，所述第二节点为所述第一节 点故障重启后的所述分布式集群系统选举出的新的Leader。
通过所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader向所述第一节点发送所述复制日志条目消息，使所述第一节点恢复了投票权利，保证了在所述第一节点故障重启时，所述分布式集群系统进行新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
结合第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票包括：所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；当所述第一标识信息指示所述日志条目包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
通过在所述复制日志条目消息中增加第一标识信息，使得所述第一节点在确保收到了所述故障前的最新日志后，才被恢复投票的权利，从而避免了Raft集群不能识别出已经丢失了日志，依然继续运行，造成了不安全隐患的问题。
结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，所述方法还包括：当所述第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态。
通过第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志，使所述复制日志条目消息在同步的不是该故障前的最新日志(即该故障前的老日志)时，仍然能正常操作。
结合第二方面的第一种至第四种任一可能的实现方式，在第二方面的第五种可能的实现方式中，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader包括：所述第一节点故障重启后，所述第二节点获得所述分布式集群系统中超过半数的赞成投票成为所述新的Leader，所述超过半数的赞成投票包括所述第二节点自己的赞成投票和所述第三节点的赞成投票，所述第二节点不能获得所述第一节点的赞成投票。
通过设置所述第一节点不能参与leader选举中的投票，使没有所述故障前的最新日志的所述第三节点不能当选为Leader，从而保证了拥有所述故障前的最新日志的所述第二节点能顺利当选Leader。
结合第二方面或第二方面的第一种至第五种任一可能的实现方式，在第二方面的第六种可能的实现方式中，还包括：所述第二节点在非易失性存储介质中保存第二标识信息，所述第二标识信息用于指示所述第二节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；所述第二标识信息的初始值设置为假False，用于指示所述第二节点初次启动，还未从所述分布式集群系统中的其它节点或者用户端设备接收过所述第一条日志；当所述第二节点从所述分布式集群系统中的其它节点或者用户端设备接收到第一条日志后，将所述第二标识信息设置为真True，用于指示所述第二节点曾经接收过所述第一条日志。
通过在非易失性存储介质中保存第二标识信息，本发明实施例提供了一种更简单、安全的方法保证正确的识别和设置投票状态，避免因错误识别造成的系统不能正常工作。
第三方面，本发明提供一种第一网络设备，用作第一节点，所述第一网络设备用于执行第一方面或第一方面的任意可能的实现方式中的方法。具体地，所述第一网络设备包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的模块。
第四方面，本发明提供一种第一网络设备，用作第一节点，所述第一 网络设备包括：处理器、发送器、随机存取存储器、只读存储器以及总线。其中，处理器通过总线分别耦接发送器、随机存取存储器以及只读存储器。其中，当需要运行终端设备时，通过固化在只读存储器中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导终端设备进入正常运行状态。在第一网络设备进入正常运行状态后，在随机存取存储器中运行应用程序和操作系统，使得该处理器执行第一方面或第一方面的任意可能的实现方式中的方法。
第五方面，本发明提供一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
第六方面，本发明提供一种第二网络设备，用作第二节点，所述第二网络设备用于执行第二方面或第二方面的任意可能的实现方式中的方法。具体地，所述第二网络设备包括用于执行第二方面或第二方面的任意可能的实现方式中的方法的模块。
第七方面，本发明提供一种第二网络设备，用作第二节点，所述第二网络设备包括：处理器、发送器、随机存取存储器、只读存储器以及总线。其中，处理器通过总线分别耦接发送器、随机存取存储器以及只读存储器。其中，当需要运行终端设备时，通过固化在只读存储器中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导终端设备进入正常运行状态。在第二网络设备进入正常运行状态后，在随机存取存储器中运行应用程序和操作系统，使得该处理器执行第二方面或第二方面的任意可能的实现方式中的方法。
第八方面，本发明提供一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第二方面或第二方面的任意可能的实现方式中的方法的指令。
第九方面，提供一种系统，所述系统包括第三方面至第五方面任一的第一 网络设备和第六方面至第八方面任一的第二网络设备。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。显而易见地，下面附图中反映的仅仅是本发明的一部分实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得本发明的其他实施方式。而所有这些实施例或实施方式都在本发明的保护范围之内。
图1是本发明实施例的一种分布式系统示意图；
图2a是本发明实施例中另一种分布式系统及产生问题的示意图；
图2b是本发明实施例中又一种分布式系统及产生问题的示意图；
图3是本发明实施例中一种故障恢复的方法流程交互示意图；
图4a是本发明实施例中的分布式系统及解决问题后的示意图；
图4b是本发明实施例中的分布式系统及解决问题后的示意图；
图5a是本发明实施例中的一种第一网络设备的结构示意图；
图5b是本发明实施例中的另一种第一网络设备的结构示意图；
图6a是本发明实施例中的一种第二网络设备的结构示意图；
图6b是本发明实施例中的另一种第二网络设备的结构示意图；
图7是本发明实施例中的一种系统示意图；
具体实施方式
下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有付出创造性劳 动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例描述的网络架构以及业务场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。
分布式系统是一种组件位于联网计算机上，组件间通过传递消息来通信和协调他们动作的系统模型。组件彼此交互以便实现共同的目标。分布式系统的三个显着特征是：组件的并发性，缺少全局时钟，以及组件的独立故障。分布式系统包括但不限于面向服务的架构系统、大规模多玩家在线游戏以及对等应用程序等。
强一致性是在并发编程(例如，在分布式共享存储器，分布式事务)领域中使用的一致性模型之一。强一致性要求：所有并行进程(或节点、处理器等)以相同的顺序看到所有访问。Raft算法是一种用来保证强一致性的典型算法，该算法应用在分布式系统中，例如，开放日光平台(英文：OpenDaylight platform，ODL)、开放网络操作系统(英文：Open Network Operating System，ONOS)等业界主流分布式控制器系统中。
Raft将一致性问题分为领导者(英文：Leader)选举、日志复制和安全性保证三个子问题。Raft将来自客户端的操作指令转化为日志，先存储(用于后续系统故障后恢复时的依据)，然后根据日志进行一致性同步。同步成功后，服务器标记该日志为提交状态(该提交状态指示该日志在该系统中已经具有了一致性。该系统中的大于一半的服务器已经保存了该日志，就能够保证一致性)，并执行操作指令。日志被标记为提交状态的顺序即为指令被执行的顺序。Raft算法过程保证Raft集群中所有服务器的日志被提交顺序保持一致。
下面简单描述Raft算法中的基本术语和概念定义。
Raft算法将分布式集群系统中的节点(例如，服务器)分为Leader、跟随者(英文：follower)和候选者(英文：Candidate)三种角色。Leader负责处理用户(英文：client)请求和按序将日志复制到follower。Follower被动响应请求，根据不同请求类型和内容作出动作。Candidate为由Follower向Leader转化过程中的中间状态的角色。其中，Leader通过日志复制逻辑保证所有follower日志提交顺序都与自己日志提交顺序一致。
Raft算法将分布式集群系统中每个节点(如，服务器)的时间被切分为一个个任期(英文：Term)。每个Term包括Leader选举时间和在某个Leader下的正常操作时间。每个Term最多一个Leader。有些Term不存在Leader，此时，为选举失败的情况。
基于Raft算法的分布式集群系统(下文简称为Raft集群)一开始启动时，该系统中所有的节点均以Follower身份启动，并启动选举定时器。如果Follower选举定时器超时，则认为当前系统中不存在一个服务器作为Leader，需要发起新一轮选举。当选举出一个节点作为leader后，该作为Leader的服务器必须广播心跳，以触发其它作为Follower的服务器的选举定时器重新开始计时。这是Raft算法的心跳和超时机制。
Raft集群中各节点相关的部分状态变量包括：
当前任期(英文：currentTerm)变量：用于标识节点当前所在的Term；
投票目标(英文：votedFor)变量：Leader选举过程，Raft集群中的节点用votedFor变量来标记在当前Term中，该节点选择集群中的哪个节点为Leader。
最后日志索引(英文：lastLogIndex)变量：用于标识Raft集群中某个节点上存储的最后一条日志的索引，日志存储在数组中，索引描述了日志的存储顺序。
最后日志任期(英文：lastLogTerm)变量：用于标识Raft集群中某个节点上存储最后一条日志时，该节点所在的Term。
需要说明的是，以上描述的每个状态变量在Raft集群中的每个节点上分别维护，即每个节点分别自己生成并维护所述各个状态变量，这些状态变量在每个节点上唯一。
接下来简单描述Raft集群中Leader选举的过程。
Follower的选举定时器超时后，需要发起新一轮选举。Follower自增currentTerm变量后由Follower转为Candidate，设置votedFor变量为自身，并向Raft集群中的其它所有的节点发送请求投票消息，重复至满足以下任意条件：
a.如果该节点获得Raft集群中超过半数服务器的投票，则由Candidate转化为Leader并开始广播心跳；
b.如果该节点接收到合法Leader的日志复制请求(日志复制请求也作为心跳消息)，则说明新的Leader已经产生，自己转化为Follower；
c.如果选举超时(本周期没有选举成功)，则自增currentTerm后开始新一轮的选举。
此外，Raft集群中每个节点处理的日志可以保存在非易失性存储介质上，例如，磁盘、硬盘等掉电后数据不丢失的存储介质；也可以保存在易失性存储介质上，例如内存等掉电后数据丢失的存储介质。为了提高数据处理的效率，这些节点不是将日志数据存储在磁盘等非易失性介质上，而是会选择将日志数据存储在易失性存储介质上，日志数据的读写均在内存中完成，读写速度较快。
Raft集群包括至少三个节点，当所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没 有最新日志的节点成为领导者Leader时，可能会造成所述最新的日志丢失的问题。例如，拥有最新日志的节点数量可以为M，M为
Figure PCTCN2016113848-appb-000001
取下限整数N为Raft集群中节点的个数,N为大于等于3的奇数。例如，如图1所示，Raft集群有3个节点(N＝3)分别是第一节点(英文：Node1)、第二节点(英文：Node2)和第三节点(英文：Node3)。此时，
Figure PCTCN2016113848-appb-000002
需要对2.5直接去掉小数位取整得到2(即取下限整数)，即有两个节点(如Node1和Node2)分别拥有最新的日志a，而其它节点(如Node3)还未同步到所述最新的日志a。在日志存储在易失性存储介质的场景中，此时如果Node1或Node2中的一个节点故障重启后，最新日志a将丢失。在重新进行Leader选举的过程中，没有存储最新日志a的Node3有可能通过选举成为新的Leader，新的Leader(Node3)向Node1和Node2等其它节点同步自己的日志，因为Node3上没有存储最新日志a，就不会把最新日志a同步到其它节点，这样就会造成最新的日志a丢失、Raft集群不安全的问题。
基于此场景，下面分别从上述故障重启的节点作为Leader角色或Follower角色两种情况来分别阐述问题。
如图2a所示，当Node1作为Leader，发生了故障，重启后，包括最新日志a的所有日志丢失。此时Node3开始申请要成为Leader，Node3向Node1和Node2分别发送请求投票消息，该请求投票消息携带Node3的本地日志信息，该本地日志信息包括lastLogIndex(例如，为正整数N)和lastLogTerm(例如，为正整数M)。因为Node2和Node1上已经分别保存了最新日志a，而Node3还未来得及同步到最新日志a，所以Node2和Node1上的LastLogIndex(例如，为N+1)一定大于Node3的LastLogIndex(为N)。当Node2收到Node3发来的该请求投票消息时，比较Node2和Node3两个节点上的lastLogIndex和lastLogTerm。如果Node2的lastLogTerm更 大，或者，Node2和Node3的lastLogTerm相同但Node2的lastLogIndex更大，则确定Node2自己保存的日志更完整，则拒绝该次投票请求。同理，当Node1收到Node3发来的该请求投票消息时，比较Node1和Node3两个节点上的lastLogIndex和lastLogTerm。因为Node1重启后所有的日志等相关信息已经丢失(日志信息为空)，所以Node3的lastLogIndex更大或者lastLogTerm更大，就会确定Node3保存的日志更完整，则会接受该次投票请求，赞成N3成为Leader。因为Raft集群只有3个节点，此时Node3分别获得了自己和Node1的2票赞成票，大于一半(1.5票)，所以当选为新的Leader，新的Leader会向Node1和Node2同步自己的日志信息，而Node3上并没有存储最新日志a，所以，整个Raft集群中将会丢失最新日志a，造成了Raft集群不安全的问题。
如图2b所示，当Node1作为Follower，发生了故障，包括最新日志a的所有日志丢失。重启后，Raft集群正好处于Leader选举的过程中，若Node3向Node1和Node2分别发送请求投票消息，该请求投票消息携带Node3的本地日志信息，该本地日志信息包括lastLogIndex(例如，为正整数N)和lastLogTerm(例如，为正整数M，M＝currentTerm+1)。因为Node1重启后所有的日志等相关信息已经丢失(日志信息为空)，所以Node3的lastLogIndex更大或者lastLogTerm更大，就会确定Node3保存的日志更完整，则Node1会接受该次投票请求，赞成N3成为Leader。Node3还会自己给自己投一票赞成票。因为Raft集群只有3个节点，此时Node3分别获得了自己和Node1的2票赞成票，大于一半(1.5票)，所以当选为新的Leader，新的Leader会向Node1和Node2同步自己的日志信息，而Node3上并没有存储最新日志a，所以，整个Raft集群中将会丢失最新日志a，造成了Raft集群不安全的问题。需要说明的是，因为Node3的lastLogTerm(为currentTerm+1)大于Node2的lastLogTerm(为currentTerm)，所以Node2接受Node3成为新的Leader，Node2变为Follower 状态。
还需要说明的是，本发明实施例中所述的分布式系统与分布式集群系统是同一个意思，可以互相使用。
上面描述了本发明涉及的两种可能的应用场景，下面将基于此对本发明实施例进一步详细说明。
图3为本发明实施例提供的一种故障恢复的方法流程示意图。该方法应用于图1所示的基于Raft算法的分布式集群系统中。所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志。具体地，可以应用在图2a和2b所示的两种场景中。需要说明的是，图1、图2a和图2b仅以Raft集群的节点数为3个举例说明，实际应用场景中，节点数可以为大于等于3个，原理与此相同，为了简洁，不再赘述。
本发明实施例提供的方案包括301部分、302部分、303部分和304部分，301部分和304部分在所述第一节点上执行，303部分和304部分在所述第二节点上执行，下面分别说明。
在301部分，所述第一节点故障重启后，投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票。
可选地，设置投票状态为不能投票的判断条件可以是在所述第一节点启动后，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，就将投票状态设置为不能投票。此外，如果确定所述第一节点的日志为空的原因为所述第一节点首次启动，就将投票状态设置为能投票。
通过在确定所述第一节点的日志为空的原因为故障重启导致丢失了日 志，才将投票状态设置为不能投票，保证了在系统初始情况下，不会将所述第一节点的投票状态设置为不能投票，从而造成错误
进一步，可选地，确定所述第一节点的日志为空的原因的方法可以通过在所述第一节点的非易失性存储介质中保存第二标识信息来实现。
通过在非易失性存储介质中保存第二标识信息，本发明实施例提供了一种更简单、安全的方法保证正确的识别和设置投票状态，避免因错误识别造成的系统不能正常工作。
所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。例如，在Raft集群初始启动时，所述第一节点的日志为空(之前从未接收过日志)，所述第二标识信息为0，代表假(英文：False)，用于指示所述第一节点曾经没有从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。该用户端设备为该Raft集群外的客户端(英文：Client)节点，可以是网络转发设备，如路由器、交换机；也可以是应用服务器等设备。当Raft集群运行过程中，所述第一节点从所述分布式集群系统中的其它节点(例如，第二节点)或者用户端设备接收到第一条日志，则设置该第二标识信息为1，代表真(英文：True)，用于指示所述第一节点曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。
当所述第一节点故障重启后，如果所述第一节点确认所述第二标识信息为1(即Ture)，并且所述第一节点的内存中存储的日志为空，则确定所述第一节点因为故障重启导致丢失了日志。
当所述第一节点故障重启后，如果所述第一节点确认所述第二标识信息为0(即False)，并且所述第一节点的内存中存储的日志为空，则确定所述第一节点为初始启动日志为空，即因为Raft集群初始启动时，集群中各节点首次启动，所以内存的日志为空。
通过将第二标识信息设置为False或True，本发明实施例提供了一种更 简洁、具体的配置该第二标识信息的方式。
综上，通过将故障重启后的所述第一节点的投票状态设置为不能投票，保证了该故障前没有最新日志的所述第三节点在Raft集群的Leader选举中不能被选为Leader，而该故障前拥有最新日志的所述第二节点能够当选为新的Leader，从而能够将该故障前的最新日志发布(或同步)到Raft集群中的其它节点，是该故障前的最新日志在Raft集群中不会丢失，提升了Raft集群的安全性。以下举例说明。
相对于图2a展示的技术问题，结合图4a所示，作为Leader的Node1故障重启后，确定因为故障重启导致日志为空，所以不能参与Leader选举过程中的投票。此时如果Node3发起投票请求，Node3就不能获得Node1的赞成投票，也不能获得Node2的赞成投票(具体请参考上述图2a所示的技术问题的描述部分)，只能获得自己投给自己的1票赞成投票，1票小于Raft集群的一半投票(1.5票)，因此不能当选为Leader。如果Node2发起投票请求，则可以获得自己投给自己的1票和Node3投给自己的1票(Node3投赞成票的原理，具体请参考上述图2a所示的技术问题的描述部分)，共2票，大于一半(1.5票)，因此当选为Leader。并将最新日志a同步给Node1和Node3，从而使最新日志a在Node1故障重启时不丢失。
相对于图2b展示的技术问题，结合图4b所示，作为Follower的Node1故障重启后，确定因为故障重启导致日志为空，所以不能参与Leader选举过程中的投票。重启后，Raft集群正好处于Leader选举的过程中，此时如果Node3发起投票请求，Node3就不能获得Node1的赞成投票，也不能获得Node2的赞成投票(具体请参考上述图2b所示的技术问题的描述部分)，只能获得自己投给自己的1票赞成投票，1票小于Raft集群的一半投票(1.5票)，因此不能当选为Leader。如果Node2发起投票请求，则可以获得自己投给自己的1票和Node3投给自己的1票(因为Node2拥有最新日志a，所以Node2的lastLogIndex大于Node3的lastLogIndex，Node3会给Node2 投赞成票。具体原理请参考上述图2a或2b所示的技术问题的描述部分)，共2票，大于一半(1.5票)，因此当选为Leader。并将最新日志a同步给Node1和Node3，从而使最新日志a在Node1故障重启时不丢失。
在302部分，所述第一节点故障重启后，所述第二节点为Leader。具体地，所述第一节点故障重启后，所述第二节点获得所述分布式集群系统中超过半数的赞成投票成为所述新的Leader，所述超过半数的赞成投票包括所述第二节点自己的赞成投票和所述第三节点的赞成投票，所述第二节点不能获得所述第一节点的赞成投票。
通过设置所述第一节点不能参与leader选举中的投票，使没有所述故障前的最新日志的所述第三节点不能当选为Leader，从而保证了拥有所述故障前的最新日志的所述第二节点能顺利当选Leader。
进一步，所述第二节点为Leader包括以下三种情况，举例说明如下。
第一种情况，如图2a所示的场景中，作为Leader的Node1故障重启后，作为Follower的Node2通过选举成为新的Leader。例如，Node1故障，Node2和Node3收不到作为Leader的Node1发来的心跳，选举定时器超时，引起新一轮的Leader选举，Node2成为新的Leader。
第二种情况，如图2b所示的场景中，作为Follower的Node1故障重启时，Raft集群正在进行新一轮(即新一个任期，相应的变量currentTerm+1)的Leader选举，作为Leader的Node2通过新一轮选举成为新的Leader。
在上面两种情况中，通过Node1故障重启后的所述Raft集群系统选举出的新的Leader向Node1发送所述复制日志条目消息，使Node1恢复了投票权利。从而保证了在Node1故障重启时，所述Raft集群系统进行新一轮Leader选举的情况下，所述系统仍能正常工作，进一步提升了系统的安全性。
第三种情况，如图2b所示的场景中，作为Follower的Node1故障重启时，Raft集群没有进行新一轮的Leader选举，作为Leader的Node2继续作为 Leader(即为所述第一节点故障重启前的所述分布式集群系统的leader)行使职责。此时的Leader也可以看作是所述第一节点故障重启前的老Leader。通过该老Leader向所述Node1发送下文会描述的复制日志条目消息，使所述Node1恢复了投票权利，保证了在Node1故障重启时，Raft集群系统没有新一轮Leader选举的情况下，系统仍能正常工作，提升了系统的安全性。
在303部分，所述第二节点向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
在304部分，所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票，所述第二节点为Leader。
为了简洁，303和304部分结合起来描述。所述复制日志条目消息(英文：ReplicatedLogEntry)包括日志条目，作为Leader的第二节点将自己的所有日志条目同步更新到所述第一节点上。其中所述复制日志条目消息的数量可以等于所述日志条目的数量，也可以小于所述日志条目的数量。例如，所述日志条目的数量为M，所述复制日志条目消息的数量为N，N小于等于M，N和M为大于等于1的正整数。当N等于M时，说明每条所述复制日志条目消息中包括一条日志条目。当N小于M时，说明每条所述复制日志条目消息中包括多条日志条目(即一组日志条目)或一条日志条目。如图4a或4b所示，所述日志条目中包括最新日志a，则Node1就会收到并保存Node2同步过来的最新日志a，是最新日志a在Node1故障重启后不丢失。
所述第一节点将所述第一节点的投票状态设置为可以投票的时机可以包括以下几种情况。
第一种情况，假设第N条复制日志条目消息中包括所述故障前的最新日志，当所述第一节点接收到所述第二节点发来的第X条复制日志条目消息(X为大于等于1且小于N的正整数)，就将投票状态设置为可以投票，恢复了Leader选举中的投票权利。也就是，所述第一节点还没有同步到所述故障前 的最新日志，就被恢复了投票的权利。此时如果第二节点故障，则所述故障前的最新日志会丢失，并且由于所述第一节已经具有了投票的权利，在新一轮Leader选举的过程中，会将赞成票投给其它节点，例如，投给所述第三节点，从而使所述第三节点成为新的Leader，Raft集群会继续运行，却不能识别出已经丢失了日志，因而造成了安全隐患。当然，如果第二节点没有故障，并在恢复了投票的权利后，继续将所述故障前的最新日志同步到所述第一节点上，则不会丢失该故障前的最新日志，不会发生安全隐患。
第二种情况，假设第N条复制日志条目消息中包括所述故障前的最新日志，当所述第一节点接收到所述第二节点发来的第X条复制日志条目消息(X为等于N的正整数)，就将投票状态设置为可以投票，恢复了Leader选举中的投票权利。也就是，所述第一节点同步到所述故障前的最新日志时，被恢复了投票的权利。此时如果第二节点故障，也不会造成所述故障前的最新日志会丢失，不会发生安全隐患。
由此可知，通过上述接收到复制日志条目消息恢复故障重启节点的投票权利的方法，在上述第二种情况下依然存在安全上的隐患。
为此，本发明在所述复制日志条目消息中增加第一标识信息，所述第一标识信息用于指示所述复制日志条目消息中携带的所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志。
当所述第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态，即不恢复所述第一节点的投票权利。通过第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志，使所述复制日志条目消息在同步的不是该故障前的最新日志(即该故障前的老日志)时，仍然能正常操作。
当所述第一标识信息指示所述日志条目包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日 志条目保存并将所述第一节点的投票状态设置为可以投票。
所述第二节点成为Leader前的最后一条日志可以是所述故障前的最新日志，也可以是所述故障后新接收到的一条新日志，以下分别举例说明。
首先举例说明所述第二节点成为Leader前的最后一条日志是所述故障前的最新日志。例如，如图4a或4b所示，在Node1故障重启后，如果Node2成为选举出的新Leader前的最后一条日志是最新日志a，则Node2向Node1发送ReplicatedLogEntry消息Y，该ReplicatedLogEntry消息Y包括所述最新日志a和所述第一标识信息a，所述第一标识信息a指示所述最新日志a为Node2成为Leader前的最后一条日志。Node1收到该ReplicatedLogEntry消息Y后，根据所述第一标识信息a，确认Node1收到了最新日志a，则保存最新日志a，并将Node1的投票状态设置为可以投票，恢复Node1的投票权利。
其次举例说明所述第二节点成为Leader前的最后一条日志是所述故障后新接收到的一条新日志。例如，如图4b所示，Node2作为Leader，在Node1故障重启时，又接收到用户端设备发来的一条日志b。然后Raft集群发起新一轮Leader选举，在Node1故障重启后，Node2又继续选举成新一轮的Leader，则日志b是Node2成为选举出的新Leader前的最后一条日志。则Node2向Node1发送ReplicatedLogEntry消息Y，该ReplicatedLogEntry消息Y包括所述最新日志a和所述第一标识信息a，所述第一标识信息a指示所述最新日志a不是Node2成为Leader前的最后一条日志。Node1收到该ReplicatedLogEntry消息Y后，保存最新日志a，并且不将Node1的投票状态设置为可以投票，不恢复Node1的投票权利。Node2继续向Node1发送ReplicatedLogEntry消息Z，该ReplicatedLogEntry消息Z包括所述日志b和所述第一标识信息b，所述第一标识信息b指示所述日志b是Node2成为Leader前的最后一条日志。Node1收到该ReplicatedLogEntry消息Z后，保存日志b，并且将Node1的投票状态设置为可以投票，恢复Node1的投票权利。需要说明的是，日志b仅 仅是一个举例，在上述Node1故障重启时，还可以再接收到除日志b以外的多条新日志，如日志c、日志d等，此处不做限定。此种情况时原理与上述相同，此处不再赘述。
这样就保证了Node1在收到了最新日志a后，才能恢复投票的权利。当Node1没有收到最新日志a时，不能恢复投票的权利。此时当Node2也故障重启时，Node3节点就不能被选举为Leader(因为得不到Node1和Node2的赞成投票)，这样Raft集群就无法选举出Leader，就会识别出日志丢失，进行故障上报，通知管理员尽快解决，避免了Raft集群日志已经丢失还在继续运行引起的不安全隐患。
通过在所述复制日志条目消息中增加第一标识信息，使得所述第一节点在确保收到了所述故障前的最新日志后，才被恢复投票的权利，从而避免了Raft集群不能识别出已经丢失了日志，依然继续运行，造成了安全隐患的问题。
图5a示出了上述实施例中所涉及的第一网络设备的一种可能的结构示意图。第一网络设备500A用作第一节点，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括所述第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第一网络设备500A包括：
处理单元504A，用于在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票。
接收单元502A，用于接收来自所述第二节点的复制日志条目消息，所述第二节点为Leader。
所述处理单元504A还用于根据所述复制日志条目消息，将所述第一节点的投票状态设置为可以投票。
可选地，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志。所述处理单元504A根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存，并将所述第一节点的投票状态设置为可以投票。
所述第一网络设备500A还包括易失性存储单元，所述易失性存储单元用于存储所述日志条目。
可选地，所述处理单元504A还用于根据所述第一标识信息确认所述日志条目不包括所述第二节点成为Leader前的最后一条日志，将所述日志条目保存并保留所述第一节点的投票状态为不能投票。
可选地，所述第一节点启动后，所述处理单元504A确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
进一步，可选地，所述第一节点还包括非易失性存储单元，所述非易失性存储单元中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。所述第一节点启动时，所述处理单元504A用于确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述处理单元504A用于确定所述第一节点因为故障重启导致丢失了日志。
本发明实施例的第一网络设备500A可以实施上述图2a至图4b所对应的实施例中的第一节点中的各种实施功能和的步骤，为了简洁，在此不再赘述。
图5b示出了上述实施例中所涉及的第一网络设备的再一种可能的结构 示意图。第一网络设备500B包括：接收器510B、处理器520B、发送器530B、随机存取存储器540B、只读存储器550B以及总线560B。其中，处理器520B通过总线560B分别耦接接收器510B、发送器530B、随机存取存储器540B以及只读存储器550B。其中，当需要运行第一网络设备500B时，通过固化在只读存储器550B中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导第一网络设备500B进入正常运行状态。在第一网络设备500B进入正常运行状态后，在随机存取存储器540B中运行应用程序和操作系统，使得：
处理器520B在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票。
接收器510B接收来自所述第二节点的复制日志条目消息，所述第二节点为Leader。
处理器520B还根据所述复制日志条目消息，将所述第一节点的投票状态设置为可以投票。
本发明实施例的第一网络设备500B可对应于上述图2a至图4b所对应的实施例中的第一节点，并且，该第一网络设备500B中的处理器520B、接收器510B等可以实现图2a至图4b所对应的实施例中的第一节点所具有的功能和/或所实施的各种步骤和方法。所述处理器520B用于执行图5a所述第一网络设备的处理单元504A的所有操作，所述接收器510B用于执行图5a所述第一网络设备的接收单元502A的所有操作。所述随机存取存储器540B用于执行图5a所述易失性存储单元的所有操作。所述只读存储器550B用于执行图5a所述非易失性存储单元的所有操作。为了简洁，在此不再赘述。
需要说明的是，本实施例也可以基于通用的物理服务器结合网络功能虚拟化(英文：Network Function Virtualization，NFV)技术实现的虚拟第一网络设备，所述虚拟第一网络设备可以是运行有用于故障恢复功能的程序的虚 拟机(英文：Virtual Machine，VM)，所述虚拟机部署在硬件设备上(例如，物理服务器)。虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。
图6a示出了上述实施例中所涉及的第二网络设备的一种可能的结构示意图。第二网络设备600A用作第二节点，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、所述第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第二网络设备600A包括：
处理单元604A，用于在所述第一节点故障重启后确认所述第二节点为Leader。
发送单元606A，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
可选地，所述处理单元604A用于确认所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志。所述第一标识信息的定义和描述与图2a至图4b所述的方法实施例中的描述一致，为了简洁，此处不再赘述。
可选地，所述第二网络设备600A还包括非易失性存储单元，所述非易失性存储单元中保存第二标识信息，所述第二标识信息用于指示所述第二节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志。所述第二节点启动时，所述处理单元604A用于确认所述第二标识信息指示所述第二节点曾经接收过所述第一条日志，并且所述第二节点当前 的日志为空，所述处理单元604A用于确定所述第二节点因为故障重启导致丢失了日志。
本发明实施例的第二网络设备600A可以实施上述图2a至图4b所对应的实施例中的第二节点中的各种实施功能和的步骤，为了简洁，在此不再赘述。
图6b示出了上述实施例中所涉及的第二网络设备的又一种可能的结构示意图。第二网络设备600B包括：接收器610B、处理器620B、发送器630B、随机存取存储器640B、只读存储器650B以及总线660B。其中，处理器620B通过总线660B分别耦接接收器610B、发送器630B、随机存取存储器640B以及只读存储器650B。其中，当需要运行第二网络设备600B时，通过固化在只读存储器650B中的基本输入输出系统或者嵌入式系统中的bootloader引导系统进行启动，引导第二网络设备600B进入正常运行状态。在第二网络设备600B进入正常运行状态后，在随机存取存储器640B中运行应用程序和操作系统，使得：
处理器620B，用于在所述第一节点故障重启后确认所述第二节点为Leader。
发送器630B，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
本发明实施例的第二网络设备600B可对应于上述图2a至图4b所对应的实施例中的第二节点，并且，该第二网络设备600B中的处理器620B、发送器630B等可以实现图2a至图4b所对应的实施例中的第二节点所具有的功能和/或所实施的各种步骤和方法。所述处理器620B用于执行图6a所述第二网络设备的处理单元604A的所有操作，所述发送器630B用于执行图6a所述第二网络设备的发送单元606A的所有操作。所述只读存储器650B用于执行图6a所述非易失性存储单元的所有操作。为了简洁，在此不再赘述。
还要说明的是，本发明实施例中的第一网络设备或第二网络设备可以 为多种具有计算和存储能力的设备，例如，服务器、主机、PC(personal computer，个人计算机)等计算机设备；又如，网络设备也可以为SDN(Software Defined Network，软件定义网络)控制器。
图7是本发明实施例提供的一种故障恢复的系统示意图。如图7所示，系统700包括第一网络设备710和第二网络设备720。第一网络设备710为上述图5a、5b所述的任一第一网络设备，第二网络设备720为上述图6a、6b所述的任一第二网络设备。有关系统中各设备的详细描述，请参见上述图5a-5b和图6a-6b等相关章节，此处不再赘述。
应理解，本领域技术人员在阅读本申请文件的基础上，可以针对本申请实施例中所描述的可选的特征、步骤或方法进行不需要付出创造性的组合，都属于本申请公开的实施例，只是由于描述或行文的简单没有重复赘述不同组合。
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另 外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (23)

  1. 一种故障恢复的方法，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述方法包括：
    所述第一节点故障重启后，投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票；
    所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票，所述第二节点为Leader。
  2. 根据权利要求1所述的方法，其特征在于，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。
  3. 根据权利要求2所述的方法，其特征在于，所述第一节点接收来自所述第二节点的复制日志条目消息，将所述第一节点的投票状态设置为可以投票包括：
    所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；
    所述第一节点根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
  4. 根据权利要求3所述的方法，其特征在于，所述方法还包括：
    所述第一节点根据所述第一标识信息确认所述日志条目不包括所述第二节点成为Leader前的最后一条日志，将所述日志条目保存并保留所述第一节 点的投票状态为不能投票。
  5. 根据权利要求1或4所述的方法，其特征在于，所述第一节点故障重启后，投票状态设置为不能投票包括：
    所述第一节点启动后，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
  6. 根据权利要求5所述的方法，其特征在于，确定所述第一节点的日志为空的原因为故障重启导致丢失了日志包括：
    所述第一节点在非易失性存储介质中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；
    所述第一节点启动时，所述第一节点确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述第一节点确定所述第一节点因为故障重启导致丢失了日志。
  7. 一种故障恢复的方法，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述方法包括：
    所述第一节点故障重启后，所述第二节点为Leader；
    所述第二节点向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
  8. 根据权利要求7所述的方法，其特征在于，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。
  9. 根据权利要求8所述的方法，其特征在于，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票包括：
    所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；
    当所述第一标识信息指示所述日志条目包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
  10. 根据权利要求9所述的方法，其特征在于，所述方法还包括：
    当所述第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态。
  11. 一种第一网络设备，用作第一节点，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括所述第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第一节点包括：
    处理单元，用于在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票；
    接收单元，用于接收来自所述第二节点的复制日志条目消息，所述第二节点为Leader；
    所述处理单元还用于根据所述复制日志条目消息，将所述第一节点的投票状态设置为可以投票。
  12. 根据权利要求11所述的第一节点，其特征在于，所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。
  13. 根据权利要求12所述的第一节点，其特征在于，所述处理单元还用 于根据所述复制日志条目消息，将所述第一节点的投票状态设置为可以投票包括：
    所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；
    所述处理单元根据所述第一标识信息确认所述日志条目包括所述第二节点成为所述新的Leader前的最后一条日志，将所述日志条目保存，并将所述第一节点的投票状态设置为可以投票；
    所述第一节点还包括易失性存储单元，所述易失性存储单元用于存储所述日志条目。
  14. 根据权利要求13所述的第一节点，其特征在于，所述处理单元还用于根据所述第一标识信息确认所述日志条目不包括所述第二节点成为Leader前的最后一条日志，将所述日志条目保存并保留所述第一节点的投票状态为不能投票。
  15. 根据权利要求11或14所述的第一节点，其特征在于，处理单元用于在所述第一节点故障重启后，将投票状态设置为不能投票包括：
    所述第一节点启动后，所述处理单元确定所述第一节点的日志为空的原因为故障重启导致丢失了日志，将投票状态设置为不能投票。
  16. 根据权利要求15所述的第一节点，其特征在于，所述处理单元确定所述第一节点的日志为空的原因为故障重启导致丢失了日志包括：
    所述第一节点还包括非易失性存储单元，所述非易失性存储单元中保存第二标识信息，所述第二标识信息用于指示所述第一节点是否曾经从所述分布式集群系统中的其它节点或者用户端设备接收过第一条日志；
    所述第一节点启动时，所述处理单元用于确认所述第二标识信息指示所述第一节点曾经接收过所述第一条日志，并且所述第一节点当前的日志为空，所述处理单元用于确定所述第一节点因为故障重启导致丢失了日志。
  17. 一种第二网络设备，用作第二节点，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、所述第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第二节点包括：
    处理单元，用于在所述第一节点故障重启后确认所述第二节点为Leader；
    发送单元，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
  18. 根据权利要求17所述的第二节点，其特征在于，所述处理单元用于在所述第一节点故障重启后确认所述第二节点为Leader包括：
    所述处理单元用于确认所述第二节点为所述第一节点故障重启后的所述分布式集群系统选举出的新的Leader。
  19. 根据权利要求18所述的第二节点，其特征在于，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票包括：
    所述复制日志条目消息包括日志条目和第一标识信息，所述第一标识信息用于指示所述日志条目是否包括所述第二节点成为所述新的Leader前的最后一条日志；
    当所述第一标识信息指示所述日志条目包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并将所述第一节点的投票状态设置为可以投票。
  20. 根据权利要求19所述的第二节点，其特征在于，所述方法还包括：
    当所述第一标识信息指示所述日志条目不包括所述第二节点成为Leader前的最后一条日志时，所述复制日志条目消息用于指示所述第一节点将所述日志条目保存并且不更改所述第一节点的投票状态。
  21. 一种第一网络设备，用作第一节点，应用在分布式集群系统中，所 述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括所述第一节点、第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第一节点包括：
    处理器，用于在所述第一节点故障重启后，将投票状态设置为不能投票，所述投票状态用于指示所述第一节点是否可以在所述分布式集群系统选举Leader的过程中进行投票；
    接收器，用于接收来自所述第二节点的复制日志条目消息，所述第二节点为Leader；
    所述处理器还用于根据所述复制日志条目消息，将所述第一节点的投票状态设置为可以投票。
  22. 一种第二网络设备，用作第二节点，应用在分布式集群系统中，所述分布式集群系统包括的拥有最新日志的节点数量会影响其中一个拥有最新日志的节点故障重启后选举一个没有最新日志的节点成为领导者Leader，所述分布式集群系统至少包括第一节点、所述第二节点和第三节点，其中所述第一节点和所述第二节点拥有所述故障前的最新日志，所述第三节点没有所述故障前的最新日志，其特征在于，所述第二节点包括：
    处理器，用于在所述第一节点故障重启后确认所述第二节点为Leader；
    发送器，用于向所述第一节点发送复制日志条目消息，所述复制日志条目消息用于指示所述第一节点在Leader选举中可以投票。
  23. 一种故障恢复的系统，其特征在于，所述系统包括如权利要求11至16任一所述的第一网络设备和如权利要求17至20任一所述的第二网络设备；或者所述系统包括如权利要求21所述的第一网络设备和如权利要求22所述的第二网络设备。
PCT/CN2016/113848 2016-12-30 2016-12-30 故障恢复的方法、设备和系统 WO2018120174A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/CN2016/113848 WO2018120174A1 (zh) 2016-12-30 2016-12-30 故障恢复的方法、设备和系统
EP16925925.6A EP3553669A4 (en) 2016-12-30 2016-12-30 INCIDENT RECOVERY METHOD AND DEVICE, AND SYSTEM
CN201680091858.0A CN110431533B (zh) 2016-12-30 2016-12-30 故障恢复的方法、设备和系统
US16/456,679 US11102084B2 (en) 2016-12-30 2019-06-28 Fault rectification method, device, and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2016/113848 WO2018120174A1 (zh) 2016-12-30 2016-12-30 故障恢复的方法、设备和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/456,679 Continuation US11102084B2 (en) 2016-12-30 2019-06-28 Fault rectification method, device, and system

Publications (1)

Publication Number Publication Date
WO2018120174A1 true WO2018120174A1 (zh) 2018-07-05

Family

ID=62706721

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/113848 WO2018120174A1 (zh) 2016-12-30 2016-12-30 故障恢复的方法、设备和系统

Country Status (4)

Country Link
US (1) US11102084B2 (zh)
EP (1) EP3553669A4 (zh)
CN (1) CN110431533B (zh)
WO (1) WO2018120174A1 (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10595363B2 (en) * 2018-05-11 2020-03-17 At&T Intellectual Property I, L.P. Autonomous topology management for wireless radio user equipment
CN112865995B (zh) * 2019-11-27 2022-10-14 上海哔哩哔哩科技有限公司 分布式主从系统
CN111538763B (zh) * 2020-04-24 2023-08-15 咪咕文化科技有限公司 一种确定集群中主节点的方法、电子设备和存储介质
CN114299655B (zh) * 2020-09-23 2023-09-05 成都中科信息技术有限公司 一种电子投票系统及其工作方法
CN112601216B (zh) * 2020-12-10 2022-06-21 苏州浪潮智能科技有限公司 一种基于Zigbee的可信平台告警方法与系统
CN113014634B (zh) * 2021-02-20 2023-01-31 成都新希望金融信息有限公司 集群选举处理方法、装置、设备及存储介质
US11645014B1 (en) * 2021-10-26 2023-05-09 Hewlett Packard Enterprise Development Lp Disaggregated storage with multiple cluster levels
CN114189421B (zh) * 2022-02-17 2022-05-31 江西农业大学 一种领导者节点选举方法、系统、存储介质及设备
CN114518973A (zh) * 2022-02-18 2022-05-20 成都西南信息控制研究院有限公司 分布式集群节点宕机重启恢复方法
CN114448996B (zh) * 2022-03-08 2022-11-11 南京大学 基于计算存储分离框架下的冗余存储资源的共识方法和系统
CN114406409B (zh) * 2022-03-30 2022-07-12 中国船级社 一种焊接机故障状态的确定方法、装置及设备
CN115794478B (zh) * 2023-02-06 2023-06-23 天翼云科技有限公司 系统配置方法、装置、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050132154A1 (en) * 2003-10-03 2005-06-16 International Business Machines Corporation Reliable leader election in storage area network
US7558883B1 (en) * 2002-06-28 2009-07-07 Microsoft Corporation Fast transaction commit
CN103152434A (zh) * 2013-03-27 2013-06-12 江苏辰云信息科技有限公司 一种分布式云系统中的领导节点更替方法
CN105512266A (zh) * 2015-12-03 2016-04-20 曙光信息产业(北京)有限公司 一种实现分布式数据库操作一致性的方法及装置
CN105511987A (zh) * 2015-12-08 2016-04-20 上海爱数信息技术股份有限公司 一种强一致性且高可用的分布式任务管理系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9507843B1 (en) * 2013-09-20 2016-11-29 Amazon Technologies, Inc. Efficient replication of distributed storage changes for read-only nodes of a distributed database
CN103763155A (zh) * 2014-01-24 2014-04-30 国家电网公司 分布式云存储系统多服务心跳监测方法
CN103793517B (zh) * 2014-02-12 2017-07-28 浪潮电子信息产业股份有限公司 一种基于监控机制的文件系统日志转储动态增容方法
US9047246B1 (en) * 2014-07-31 2015-06-02 Splunk Inc. High availability scheduler
CN104994168B (zh) * 2015-07-14 2018-05-01 苏州科达科技股份有限公司 分布式存储方法及分布式存储系统
US10503427B2 (en) * 2017-03-10 2019-12-10 Pure Storage, Inc. Synchronously replicating datasets and other managed objects to cloud-based storage systems

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7558883B1 (en) * 2002-06-28 2009-07-07 Microsoft Corporation Fast transaction commit
US20050132154A1 (en) * 2003-10-03 2005-06-16 International Business Machines Corporation Reliable leader election in storage area network
CN103152434A (zh) * 2013-03-27 2013-06-12 江苏辰云信息科技有限公司 一种分布式云系统中的领导节点更替方法
CN105512266A (zh) * 2015-12-03 2016-04-20 曙光信息产业(北京)有限公司 一种实现分布式数据库操作一致性的方法及装置
CN105511987A (zh) * 2015-12-08 2016-04-20 上海爱数信息技术股份有限公司 一种强一致性且高可用的分布式任务管理系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3553669A4 *

Also Published As

Publication number Publication date
CN110431533B (zh) 2021-09-14
CN110431533A (zh) 2019-11-08
US11102084B2 (en) 2021-08-24
US20190386893A1 (en) 2019-12-19
EP3553669A1 (en) 2019-10-16
EP3553669A4 (en) 2019-10-16

Similar Documents

Publication Publication Date Title
WO2018120174A1 (zh) 故障恢复的方法、设备和系统
EP3701666B1 (en) System and method for deleting node in blockchain network
CN111480157B (zh) 用于在区块链网络中添加节点的系统和方法
US11163479B2 (en) Replicated state cluster with standby node state assessment during leadership transition
EP4083786A1 (en) Cloud operating system management method and apparatus, server, management system, and medium
US11966818B2 (en) System and method for self-healing in decentralized model building for machine learning using blockchain
US20090144720A1 (en) Cluster software upgrades
US20070214355A1 (en) Leaderless Byzantine consensus
US20180004777A1 (en) Data distribution across nodes of a distributed database base system
CN106354563B (zh) 用于3d重建的分布式计算系统以及3d重建方法
US9760529B1 (en) Distributed state manager bootstrapping
CN113656147B (zh) 一种集群部署方法、装置、设备及存储介质
Mu et al. When paxos meets erasure code: Reduce network and storage cost in state machine replication
US7103639B2 (en) Method and apparatus for processing unit synchronization for scalable parallel processing
WO2023065788A1 (zh) 升级区块链系统的方法、装置及终端设备
US11392423B2 (en) Method for running a quorum-based system by dynamically managing the quorum
US20240111747A1 (en) Optimizing the operation of a microservice cluster
CN100442248C (zh) 用于避免竞争的计算机系统同步单元
EP4191429A1 (en) Techniques to achieve cache coherency across distributed storage clusters
US11288004B1 (en) Consensus-based authority selection in replicated network-accessible block storage devices
CN113568710B (zh) 一种虚拟机高可用实现方法、装置和设备
US20240135257A1 (en) System and method for self-healing in decentralized model building for machine learning using blockchain
CN117215833A (zh) 分布式数据备份方法、系统、设备及存储介质
CN115292101A (zh) 一种元数据异常状态恢复方法、装置、设备、存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16925925

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2016925925

Country of ref document: EP

Effective date: 20190708