WO2020024615A1 - 一种共识流程恢复方法及相关节点 - Google Patents

一种共识流程恢复方法及相关节点 Download PDF

Info

Publication number
WO2020024615A1
WO2020024615A1 PCT/CN2019/081998 CN2019081998W WO2020024615A1 WO 2020024615 A1 WO2020024615 A1 WO 2020024615A1 CN 2019081998 W CN2019081998 W CN 2019081998W WO 2020024615 A1 WO2020024615 A1 WO 2020024615A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
instance
master
nodes
slave
Prior art date
Application number
PCT/CN2019/081998
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 EP19845036.3A priority Critical patent/EP3675416B1/en
Publication of WO2020024615A1 publication Critical patent/WO2020024615A1/zh
Priority to US16/847,171 priority patent/US11200123B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1051—Group master selection mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures

Definitions

  • the invention relates to the field of big data technology, in particular to a method for recovering a consensus process and related nodes.
  • Blockchain is a type of chain data structure that combines data blocks in a sequential manner, and it is a tamper-proof and non-forgeable distributed ledger guaranteed by cryptography.
  • Existing clusters of nodes that implement the blockchain solution use the practical Byzantine fault tolerance (PBFT) algorithm for consensus when solving the problem of negotiation between nodes and how to generate new blocks.
  • PBFT Byzantine fault tolerance
  • the consensus efficiency is provided by the blockchain.
  • the node cluster includes a primary node, and the nodes other than the primary node are slave nodes.
  • the master node assumes more tasks in the consensus process, for example, receiving a client (client) sends Data processing request, and then send the key information in the request to all other nodes in the node cluster, so that the nodes in the node cluster can agree on the data.
  • client client
  • the nodes in the node cluster will re-elect a new master node.
  • a competition-based election method is usually used. During the competition, various nodes will exchange a lot of information.
  • this process will continue for a certain period of time; if there is data that needs consensus during this period, it will need to wait until the new master node is generated before it will be executed. That is to say, the consensus process may be interrupted due to the failure of the master node, and how to quickly recover after the consensus process is interrupted is a technical problem that needs to be solved by those skilled in the art.
  • the embodiment of the invention discloses a method for recovering a consensus process and related nodes, which can solve the problem that the recovery speed of the consensus process is slow after the master node fails in the consistency process.
  • an embodiment of the present application provides a cluster system.
  • the cluster system includes multiple nodes, and the multiple nodes collectively run multiple instances, and each of the multiple instances is controlled by the multiple nodes.
  • Nodes operate together, and there is one master instance and one or more slave instances in the multiple instances; for each instance, one node in the multiple nodes exists as the master node corresponding to each instance;
  • the multiple master nodes corresponding to the multiple instances are different nodes.
  • the first node sends a service request to each second node; the first node is a master node corresponding to one of the multiple instances, and the second The node is a slave node corresponding to the one instance; the first node receives the first verification information returned by the second node, the first verification information includes a signature of the second node, and the first verification The information indicates that the second node passes verification of the service request. If the amount of the first verification information received by the first node exceeds a second preset threshold, the first node executes the service request. The first node sends first confirmation information to each of the second nodes, and the first confirmation information includes all the first verification information received by the service request and the first node. The second node's signature; the first confirmation information is used to cause the second node to execute the service request.
  • the multiple nodes are configured to determine a target instance from the one or more slave instances, and the throughput of the target instance is greater than the throughput of the master instance High; the multiple nodes are used to reach consensus among the multiple nodes, so that the target instance replaces the master instance to become a new master instance. That is to say, when the master instance in these multiple instances cannot run normally due to the failure of the master node, the multiple nodes are not required to re-elect the master node, but directly from an already existing The target instance is determined in the instance, and the target instance is replaced with a new master instance, which improves the efficiency of fault recovery.
  • an embodiment of the present application provides a method for restoring a consensus process, which is characterized in that the method is applied to a node cluster, where the node cluster includes multiple nodes, and the multiple nodes collectively run multiple instances, where the multiple Each of the instances is jointly run by the multiple nodes, and there is one master instance and one or more slave instances in the multiple instances; for each instance, one node in the multiple nodes exists as the The master node of the instance, and the remaining nodes as slave nodes of the instance; the multiple master nodes corresponding to the multiple instances are different nodes, and the method includes: one or more of the multiple nodes are slaves The one or more slave instances determine a target instance, and the throughput of the target instance is higher than the throughput of the master instance; the first node and each second node reach a consensus to replace the target instance with the target instance.
  • the master instance becomes a new master instance
  • the second node is a slave node running the target instance
  • the first node is a master node running the
  • the node cluster runs a master instance and one or more slave instances together.
  • the node cluster directly selects a new master from the one or more slave instances. Instance, rather than the node cluster re-doing a lot of information interaction to establish a new master instance. Therefore, when the original master instance fails to work normally, the new master instance can immediately take over the original master instance to execute the consensus process, so that the consensus process can be quickly restored after the interruption.
  • the method further includes: one or more of the plurality of nodes detecting a throughput of each of the plurality of instances; the first A node determines the target instance from the one or more slave instances according to the throughput of the each instance.
  • each instance is used to process a service request, and the method further includes: the first node sends the second node to each of the second nodes A service request; the first node receives first verification information returned by the second node, the first verification information includes a signature of the second node, and the first verification information indicates that the second node The service request verification is passed; if the amount of the first verification information received by the first node exceeds a second preset threshold, the first node executes the service request; the first node sends a request to each Sending, by the second node, first confirmation information, where the first confirmation information includes the service request and a signature of the second node among all the first verification information received by the first node; The first confirmation information is used to cause the second node to execute the service request.
  • the second node of the target instance does not need to confirm back and forth with other slave nodes of the target instance, and each slave node of the target instance only needs to send the signature of each slave node through the first node.
  • the first confirmation information can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • the first node and each second node reach a consensus to replace the target instance with the master instance to become a new master instance, including: the first The node sends a replacement request to each of the second nodes, where the replacement request is used to request that the target instance be replaced with the master instance to become a new master instance; the first node receives the first node returned by the second node.
  • Second verification information where the second verification information includes a signature of the second node, and the second verification information indicates that the second node passes verification of the replacement request; The amount of the second verification information exceeds a third preset threshold, the first node replaces the target instance with the master instance to become a new master instance; the first node sends a first to each of the second nodes.
  • Second confirmation information the second confirmation information including the signature of the second node among all the second verification information received by the first node; the second confirmation information is used to indicate each A second node in said replacement request, replacing the main examples of the target instance becomes the new primary instance.
  • the second node of the target instance does not need to confirm back and forth with other slave nodes of the target instance, and each slave node of the target instance only needs to carry the signature of each slave node through the first node
  • the second confirmation information can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • a part of the plurality of slave nodes of any one of the multiple instances is a standby master node of any one of the instances, and the any one The standby master node of the instance is used to replace the master node of any one instance as a new master node of any one instance. It can be understood that equipping each master node with a standby master node can select a new master node from the equipped standby master nodes more quickly when the master node is replaced, instead of a blind slave node, which is large. The election of a new master node within the scope not only improves the election efficiency of the master node, but also reduces the communication between the nodes.
  • a part of the plurality of slave nodes of any one of the multiple instances is a standby master node of any one of the instances, and the any one There is a priority order between the standby master nodes of the instance; the standby master node of the any instance is used to replace the master node of the any instance as a new master node of the any instance, specifically:
  • the standby master node with the highest priority among the standby master nodes of any one instance is used to replace the master node of any one instance as a new master node of any one instance. It can be understood that the priority can further limit the order in the election of a new master node, and avoid the problem of high communication pressure caused by blind election.
  • N is an integer greater than or equal to 3.
  • an embodiment provides a consensus method, the method includes: a first node sends the service request to each second node; the first node is a master node running an instance, and the second node The node is a slave node running the one instance; the first node receives first verification information returned by the second node, the first verification information includes a signature of the second node, and the first verification The information indicates that the second node passes verification of the service request. If the amount of the first verification information received by the first node exceeds a second preset threshold, the first node executes the service request. The first node sends first confirmation information to each of the second nodes, and the first confirmation information includes all the first verification information received by the service request and the first node. The second node's signature; the first confirmation information is used to cause the second node to execute the service request.
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • an embodiment of the present application provides a consensus method.
  • the method includes: a second node receives the service request sent by a first node; the first node is a master node running an instance, and the second node The node is a slave node running the one instance; the second node verifies the first to-be-verified information to generate first verification information, and the first verification information includes a signature of the second node, so The first verification information indicates that the second node passes verification of the service request; the second node sends the first verification information to the first node so that the first node receives the first verification information When a quantity of verification information exceeds a second preset threshold, the service request is executed and a first confirmation message is sent to the second node, and the first confirmation message includes each of the first verifications received by the first node A signature from the second node in the information; if the first confirmation message sent by the first node is received, the second node executes the service according to the first to-be-checked information begging
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • an embodiment of the present application provides a node.
  • the node includes a sending unit, a receiving unit, and an execution unit.
  • the sending unit is configured to send the service request to each second node.
  • the node is configured to run one The master node of the instance, the second node is a slave node running the one instance;
  • the receiving unit is configured to receive the first verification information returned by the second node, and the first verification information includes the second verification information A signature of a node, the first verification information indicates that the second node has verified the service request, and an execution unit is configured to receive the first verification information in the receiving unit in an amount exceeding a second preset A threshold to execute the service request;
  • the sending unit is configured to send first confirmation information to each of the second nodes, where the first confirmation information includes the service request and all information received by the node The signature of the second node in the first verification information; and the first confirmation information is used to cause the second node to execute the service request.
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • an embodiment of the present application provides a node.
  • the node includes a receiving unit, a verification unit, a sending unit, and an execution unit.
  • the receiving unit is configured to receive the service request sent by the first node.
  • the first node is a master node running an instance, and the node is a slave node running the one instance;
  • a verification unit is configured to verify the first to-be-checked information to generate first verification information, and the first A verification information includes a signature of the node, the first verification information indicates that the node has passed verification of the service request, and
  • a sending unit is configured to send the first verification information to the first node so that the The first node executes the service request and sends a first confirmation message to the node when the amount of the first verification information received exceeds a second preset threshold, the first confirmation message including the first node receiving A signature from the node in each of the first verification information; an execution unit, configured to, when receiving the first confirmation message sent by the first node, According to
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • an embodiment of the present application provides a node, where the node includes a processor and a memory, where the memory is used to store program instructions, and when the processor calls the program instructions, implement the described in the third aspect method.
  • an embodiment of the present application provides a node, where the node includes a processor and a memory, where the memory is used to store program instructions, and when the processor calls the program instructions, implement the described in the fourth aspect method.
  • an embodiment of the present application provides a computer-readable storage medium.
  • the computer-readable storage medium stores instructions, and when the computer-readable storage medium runs on a processor, the method described in the third aspect is implemented.
  • an embodiment of the present application provides a computer-readable storage medium, where the computer-readable storage medium stores instructions, and when the computer-readable storage medium runs on a processor, implements the method described in the fourth aspect.
  • a node cluster runs multiple instances together.
  • a new master instance is directly selected from the multiple instances, instead of the node cluster re-doing a lot of information. Interact to re-create a new master instance. Therefore, when the original master instance fails to work normally, the new master instance can immediately replace the original master instance for consistency processing, which can avoid the problem of a long delay in consistency processing caused by the replacement of the instance.
  • FIG. 1 is a schematic structural diagram of a node cluster according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a node according to an embodiment of the present invention.
  • FIG. 3 is a schematic flowchart of a data consensus method according to an embodiment of the present invention.
  • FIG. 4 is a schematic flowchart of a method for recovering a consensus process according to an embodiment of the present invention
  • FIG. 5 is a schematic diagram of a scenario throughput according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a scenario of a consensus process according to an embodiment of the present invention.
  • FIG. 7 is a schematic diagram of a scenario for selecting a master node according to an embodiment of the present invention.
  • FIG. 8 is a schematic diagram of a scenario for selecting a master node according to an embodiment of the present invention.
  • FIG. 9 is a schematic flowchart of a data consensus method according to an embodiment of the present invention.
  • FIG. 10 is a schematic structural diagram of a node according to an embodiment of the present invention.
  • FIG. 11 is a schematic structural diagram of a node according to an embodiment of the present invention.
  • FIG. 12 is a schematic structural diagram of a node according to an embodiment of the present invention.
  • FIG. 13 is a schematic structural diagram of a node according to an embodiment of the present invention.
  • nodes in a node cluster jointly run an instance, and transactions are processed consistently through the one instance. Once the one instance fails and cannot run normally, each node in the node cluster needs to renegotiate, thereby Election of a new instance for consistency processing, the process of re-election of consistent instances takes a long time, during which the task of consistency processing is equivalent to suspension, the embodiment of the present application can avoid consistency caused by re-election of consistent instances.
  • the problem of processing suspension is described below with reference to the accompanying drawings in the embodiments of the present invention.
  • FIG. 1 is a schematic structural diagram of a node cluster 10 according to an embodiment of the present invention.
  • the node cluster 10 includes multiple nodes 101, and the node cluster 10 runs multiple instances 102.
  • Each instance 102 is jointly run by a cluster of nodes.
  • each node 101 in the node cluster 10 can be divided into several logical nodes, each logical node can serve as a running node of an instance, and several logical nodes on a node 101 can serve as running of different instances, respectively.
  • Node any two logical nodes on a node cannot serve as running nodes of an instance at the same time; for any one instance, each of the multiple nodes that does not fail must provide a logical node as the instance's Run the node.
  • the node cluster includes one master node and one or more slave nodes running each instance. Specifically, any one instance requires multiple logical nodes to run together, and there must be a master node and one or more slave nodes in the multiple logical nodes, that is, multiple nodes in the node cluster need to have one
  • the node (logical node) serves as the master node of this instance, and the remaining nodes (logical nodes) serve as slave nodes of this instance.
  • any node in the node cluster serves as the master node of an instance at most.
  • the multiple instances include a master instance and one or more slave instances, and each of the multiple instances is used to execute a business request (for example, generating a block based on transaction information).
  • the master instance of is also used to place the result of the execution of the business request (for example, if the block is generated, the generated block is placed), where the placement refers to storage on disk, usually refers to permanent storage or Long-term storage, not short-term storage like cache.
  • the slave instance will not compass the result after executing the business request. For example, the slave instance may only cache the generated blocks, or it will not be stored at all after generating the blocks.
  • FIG. 2 is a schematic structural diagram of a node 101 according to an embodiment of the present application.
  • the node 101 may be any node in the node cluster 10.
  • the node 101 includes a node management module 1012 and a consensus instance IO management.
  • Node management module 1012 responsible for node management, including node startup, decision and execution of active and standby instance switching.
  • Consensus instance IO management module 1013 used to perform input / output (IO) monitoring on each running instance to obtain the throughput of each instance.
  • Consensus instance information management module 1014 used to maintain the information of each instance on the node, including the role (master node or slave node), access address, port information, etc. that the current node plays in each instance.
  • Configuration module 1015 responsible for reading and loading initial parameters required by the node during operation.
  • the consensus instance module includes a consistency unit, a message management unit, a service execution unit, and a data encryption authentication unit.
  • the consistency unit is used for instance consensus
  • the message management unit is used to receive and send messages of the instance, and the final message may also pass through the above communication module
  • the business execution unit is used to execute the business according to the business request (for example, package transactions and create Block)
  • the data encryption and authentication unit is used to verify the legality of messages and data, and to encrypt and decrypt messages and data.
  • Ledger management module 1017 used to maintain the blockchain information on the nodes.
  • FIG. 3 illustrates the general execution process of the above modules, as follows: 1, consensus instance information management module 1014 according to the node start instruction (node start); 2, consensus instance information management module 1014 obtains configuration information from configuration module 1015; 3, The configuration module 1015 obtains and generates configuration information from the outside, and returns it to the consensus instance information management module 1014; 4, the consensus instance information management module 1014 loads the configuration information for startup, and returns the startup result to the node management module (the startup result may be (Feedback to the user who triggered the node start); 5 The node management module obtains the throughput of each instance from the IO management module; 6 The node management module notifies the consensus instance information management module to switch from the instance to the master instance according to the throughput of each instance .
  • each module and unit in FIG. 2 is a functional module divided according to functions.
  • some of the functional blocks can be subdivided into more small functional modules, and some functional modules may also be combined into a function. Modules, but no matter whether these functional modules are subdivided or combined, they will not have a substantial impact on the implementation of the method and process of this application for the node 10.
  • each function module corresponds to its own program code (or program instructions). When the corresponding program code of these function modules runs on the processor, the function module executes the corresponding process to achieve the corresponding function.
  • FIG. 4 is a schematic flowchart of a consensus process recovery method according to an embodiment of the present invention.
  • the method may be implemented based on the node cluster shown in FIG. 1, or may be implemented based on other architectures.
  • the method includes: Not limited to the following steps:
  • the instance switching process is as follows:
  • Step S401 each node in the node cluster detects the throughput of each of the multiple instances.
  • the multiple instances in the embodiment of the present application include a master instance and one or more slave instances, and each node in the node cluster can identify which master instance is a slave instance, and each instance will be real-time In accordance with the business request (for example, generating a block based on the transaction information).
  • the business request for example, generating a block based on the transaction information.
  • some instances perform business efficiently based on business requests, and some instances perform business inefficiently based on business requests.
  • the efficiency of each instance's execution of business can be determined by the throughput of each instance per unit time (or "throughput" ") To determine that the more efficient the instance, the higher the throughput per unit time.
  • each instance is jointly participated by all nodes in the node cluster (except the node that has failed), which means that each node in the node cluster (except the node that has failed) participates in this at the same time. Since each instance is running, each node in the node cluster can obtain the throughput of each of the multiple instances.
  • Step S402 A node in the node cluster determines a target instance according to the throughput of each instance detected by itself.
  • the target instance is a slave instance in which the throughput of the one or more slave instances is higher than the throughput of the master instance before replacement, for example, the throughput of the master instance before the replacement is higher than the first preset threshold.
  • the first preset threshold value is a preset value for reference comparison, which can be a parameter representing the size of the throughput, a set ratio, a function expression, and so on. If there are multiple slave instances whose throughput is higher than the first preset threshold than the master instance before replacement, then the target instance can be any one of them, or the one with the highest throughput, or meet a preset filter Condition one.
  • Figure 5 illustrates the throughput of several instances, which illustrates the throughput T2 of the master instance, the throughput T1 of the slave instance 1, and the throughput T3 of the slave instance 2.
  • the throughput of the master instance T2 is higher than the first preset threshold, so the slave instance 1 is the target instance.
  • each node in the node cluster individually determines a target instance and sends a first request message to the master node of the target instance determined by itself, requesting to replace the target instance determined by itself as the master instance,
  • the first request message may be a signed Propose message ⁇ propose, sign_0,>, where promise is used to request that the target instance be replaced with a new master instance, and sign_0 is the signature of the pose of the node that sent the pose message.
  • there may be different target instances determined by some nodes so these nodes will each send a first request message to the master node of the different target instance. Accordingly, each master node receives the first request message sent to itself.
  • the preset threshold is a preset value for reference comparison, and only one master node among the master nodes receiving the first request message receives The number of first request messages will be greater than the preset threshold.
  • the preset threshold is equal to 2f + 1, where f is the number of nodes in the node cluster that may be faulty or unreliable.
  • f is less than or equal to N is the total number of nodes in the above node cluster.
  • f may also be calculated or derived by other methods.
  • the master node of a target instance determines that the number of first request messages it receives reaches the preset threshold, the master node of the target instance can be called the first node, and the slave node of the target instance can be called the second node. Afterwards, the first node needs to reach consensus with each second node to replace the determined target instance with a new master instance. The process of reaching consensus between the first node and each second node will be described in step S403.
  • a node is pre-configured (or elected) in the node cluster to determine the target instance, and the node sends a first request message to the master node of the determined target instance after determining the target instance.
  • the master node of the target instance is the first node
  • the slave node of the target instance is called the second node.
  • the first node needs to reach a consensus with each second node to The target instance is replaced with a new master instance, and the process of reaching a consensus between the first node and each second node will be described in step S403.
  • a node in the node cluster determines the target instance, if it is the master node of the identified target instance, the master node of the target instance can be called the first node and the target instance.
  • the slave node is the second node, and the first node needs to reach consensus with each second node to replace the target instance with a new master instance.
  • the process of reaching consensus between the first node and each second node will be in step S403. Description.
  • Step S403 The first node and each second node reach a consensus to replace the target instance in the multiple instances of the node cluster operation with a new master instance.
  • the first node learns that the target instance needs to be replaced with a new master instance, it negotiates with each second node in the node cluster.
  • the purpose of the negotiation is to transfer the The target instance is replaced with a new master instance.
  • An optional process for negotiation is as follows:
  • the first node sends a replacement request to each second node, and the replacement request is used to instruct to replace the target slave instance with a new master instance.
  • the replacement request may be a signed Candidate message ⁇ candidate, sign_1>, where candidate is used to indicate that the target slave instance is replaced with a new master instance, and sign_1 is the signature of the first node on the candidate.
  • Step 2 The second node receives the replacement request sent by the first node and verifies the replacement request.
  • the process of verifying the replacement request includes verification of the throughput of the target instance, specifically Since the second node also participates in the operation of each instance, the second node can also learn the throughput of each instance; the second node will determine whether the throughput of the target instance to which the first node is to be switched is true through the replacement request The throughput of the master instance before switching is higher than the first preset threshold. If it is really higher than the first preset threshold, the verification of the throughput of the target instance passes, otherwise it fails.
  • the process of verifying the replacement request further includes verifying the signature in the replacement request, wherein the verification of the signature can achieve at least two purposes: 1. whether the replacement request came from the first node; 2. Whether the replacement request has been tampered with during the sending process. If the replacement request is sent by the first node and has not been modified since it was sent, the verification of the signature in the replacement request passes.
  • the second node if the verification of the replacement request passes, the second node generates second verification information, and then sends the second verification information to the first node.
  • the second verification information may be a signed agreement message ⁇ agree, sign>, where agree is used to indicate that the replacement request is verified, and sign is a second node's signature on the agree.
  • step 3 the first node receives the second verification information for the replacement request sent by the second node; if the number of the received second verification information reaches a third preset threshold, the A node and each second node reach a consensus on replacing the target instance with a new master instance, so the first node replaces the target instance with a new master instance; and the first node forwards to each of the second nodes
  • the node sends a second confirmation message to instruct each second node to replace the target instance with a new master instance, and the second confirmation message may be a signed commit message ⁇ commit, sign_0, sign_1, ... sign_2f> Wherein, commit is used to indicate the content required for the second confirmation information, and sign_0, sign_1, ...
  • the third preset threshold value is a preset value used for reference comparison, which may be a parameter that characterizes the size of the throughput, a set ratio, a function expression, and so on.
  • the third preset threshold is equal to 2f, and f is the number of nodes that may be faulty or untrustworthy in the node cluster. For example, f is less than or equal to N is the total number of nodes in the above node cluster. Of course, f may also be calculated or derived by other methods.
  • the second node receives the second confirmation information sent by the first node, and the second node can obtain each signature in the second confirmation information, and according to each signature, it can be learned that the first node sends the first confirmation message to the first node.
  • the number of nodes of the second verification information exceeds the third preset threshold, that is, the number of nodes that agree to switch the target instance to the master instance exceeds the third preset threshold, so the second node replaces the target instance with a new master instance.
  • the instance consensus process for the transaction information includes four stages: preprocessing Apend, confirming, executing Commit, and completing Committed, as shown in Figure 6, the detailed process is as follows:
  • the first node sends a service request to each second node, and the service request is used to request the second node to perform a service.
  • the service may be transaction information reqinfo, and executing the transaction information may specifically generate a block based on the transaction.
  • the service request ⁇ reqinfo, req_order, sign_0> includes the transaction information reqinfo, a signature sign_0 of the first node to the transaction information reqinfo, and a sequence number req_order assigned to the transaction information.
  • the second node receives the service request ⁇ reqinfo, req_order, sign_0> sent by the first node, the second node verifies the service request, and if the signature sign_0 in the service request passes verification, And it is determined that the sequence number req_order is not used and the sequence number is the latest (for example, req_order is greater than any recorded sequence number), then the second node recognizes the reqinfo message in the service request, that is, the service request is verified to pass.
  • the second node signs the service request to obtain the first verification information ⁇ reqinfo, req_order, sign_0, sign_1>, where sign_1 is the second node's signature on the service request ⁇ reqinfo, req_order, sign_0>.
  • Each second node then sends the first verification information ⁇ reqinfo, req_order, sign_0, sign_1> to the first node.
  • the first node receives the first verification information ⁇ reqinfo, req_order, sign_0, sign_1> sent by the second node, and if the number of the received first verification information exceeds a second preset threshold, Then, the first node executes a service, for example, generates a first block of the transaction information (including writing transaction information reqinfo and a corresponding sequence number req_order to a block message queue).
  • the first node also sends a first confirmation message ⁇ reqinfo, req_order, sign_0, sign_1, sign_2, sign_3, sign_4, ..., sign_N-1, sign_N> to the second nodes, so that the second node
  • the service request also executes a service; where sign_1, sign_2, sign_3, sign_4, ..., sign_N-1, sign_N are the signatures of different nodes to the service request ⁇ reqinfo, req_order, sign_0> (N is a positive integer), They are carried in the first verification information sent by the corresponding node to the first node, respectively.
  • the signature of each node for ⁇ reqinfo, req_order, sign_0> is used to indicate that the node has passed the verification of ⁇ reqinfo, req_order, sign_0>.
  • the second preset threshold is a preset value for reference comparison, which may be a parameter that characterizes the size of the throughput, a set ratio, a function expression, and so on.
  • the second preset threshold is equal to 2f, and f is the number of nodes that may be faulty or untrustworthy in the node cluster.
  • f is less than or equal to N is the total number of nodes in the above node cluster.
  • f may also be calculated or derived by other methods.
  • the second node if the second node receives the first confirmation message sent by the first node, it will determine how many nodes have paired the first to-be-checked message according to the signature of each node included in the first confirmation message. ⁇ reqinfo, req_order, sign_0> The verification is passed. If the number of nodes that pass the verification exceeds a second preset threshold, the second node executes the service according to the service request, for example, generates the first block of the transaction information. (Including writing transaction information reqinfo and its corresponding serial number req_order to the block message queue). Optionally, if the service is transaction information, the first node and the second node may also send the first blocks generated by them to the device (or client) requesting consistent processing of the transaction information.
  • the second node of the target instance does not need to confirm back and forth with other slave nodes of the target instance, and each slave node of the target instance only needs to send the signature of each slave node through the first node.
  • the first confirmation information can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • the above transaction information may refer to information of a single transaction or information of multiple transactions.
  • the information of the multiple transactions may be sent by other devices to the first device.
  • each node in the node cluster broadcasts the transaction information received by itself to other nodes in the node cluster; for another example, a device outside the node cluster sends multiple transactions to the first node.
  • the first node assigns a total serial number to the multiple transactions, and performs consensus on the multiple transactions as a unit (that is, in the prior art, a consensus consensus process is performed once for each transaction. (Here is a consensus process for multiple transactions).
  • each second node traverses and verifies each of the multiple transactions. If a transaction has already completed the validity check locally before receiving the business request, it is no longer necessary Verify the legitimacy, otherwise you need to verify the legitimacy of a certain transaction; if each of the multiple transactions is verified, and the overall serial number of the multiple transactions is given to other multiple transactions previously received If the overall serial number is larger, the verification of the transaction information is passed. It is understandable that when multiple transactions perform a consensus consensus process together, the number of communications can be greatly reduced. Assuming that there are k transactions that need to be consensus on n nodes, if consensus is made for each transaction separately, k transactions The communication complexity is O (kn). If k transactions are consensused together, the communication complexity of k transactions can be expressed as O (n).
  • the master node election process is as follows:
  • a part of the multiple slave nodes of any one of the multiple instances is a standby master node of the any instance, and the standby master node of the any instance
  • the node is used to replace the master node of any one instance as a new master node of any one instance; optionally, there is no duplication between the standby master nodes of any two instances. For example, when configuring the above multiple instances, sort the nodes in the node cluster, for example, sort based on parameters such as hardware performance, IP address, and device name.
  • the first L nodes in the sorting can be taken, and each of these L nodes is used as the master node of an instance; then from the node cluster except the L nodes Among the nodes, the standby master node of each instance is selected, and the standby master node of each instance is not repeated.
  • the node of the standby master node of the first instance is equal to 1 + iL
  • the standby of the second instance The number of the master node is equal to 2 + iL
  • the node of the standby master node of the Lth instance is equal to the node of L + iL, where i is a positive integer greater than or equal to 1, and the specific values of i can be defined in advance.
  • the ordering of these L instances is not limited. Of course, other methods can be used to ensure that the standby master node of each instance is not duplicated, and other methods are not used as examples here.
  • the standby master node of any one of the instances there is a priority order between the standby master nodes of any one of the instances, and the specific parameters based on which to determine the priority of each standby master node are not limited here.
  • the standby master that is ranked higher in the list is optional. The higher the priority of the node; under this premise, the standby master node of the any instance is used to change to the new master node of the any instance when the master node of the any instance needs to be replaced, specifically: : According to the priority order, the standby master node with the highest priority among the standby master nodes of any one instance is used to replace the master node of any one instance as a new master node of any one instance. For example, as shown in FIG.
  • the multiple instances include a master instance, slave instance 1 and slave instance 2, where the master node of the master instance is node 1 and the standby master node is node 3 and node 0 (and The priority of node 3 is higher than the priority of node 0); the master node of slave instance 1 is node 2, the standby master node is node 5, the master node of slave 2 is node 4, and the standby master node is node 6. Then, when node 1 as the current master node of the master instance fails, node 3 is selected as the new master node of the master instance.
  • node 0 is selected as the new master node of the master instance; as the slave instance 1
  • node 5 is selected as the new master node of slave instance 1.
  • node 6 is selected as the new master node of slave 2 Master node;
  • Figure 8 shows the corresponding scenario.
  • Each node in a node cluster sends election information to the priority according to the priority order of the standby master node of the certain instance.
  • the highest standby master node instructs the standby master node with the highest priority to switch to a new master node.
  • the standby master node with the highest priority of this instance receives a preset amount of vote information, it broadcasts an election confirmation ( vote_commit) information to indicate that the new current master node of this instance is its standby master node with the highest priority.
  • each node in the node cluster updates its configuration information according to the vote_commit information, so as to configure the standby master node with the highest priority as the new master node of the certain instance.
  • the preset number is equal to
  • a node cluster runs multiple instances together.
  • a new master instance is directly selected from the multiple instances, instead of re-doing a large number of nodes in the cluster. Information to re-create a new master instance. Therefore, when the original master instance fails to work normally, the new master instance can immediately replace the original master instance for consistency processing, which can avoid the problem of a long delay in consistency processing caused by the replacement of the instance.
  • FIG. 9 is a data consensus method provided by an embodiment of the present invention.
  • the method may be implemented based on the node cluster shown in FIG. 1, or may be implemented based on other architectures, for example, running in a architecture There are multiple nodes in the architecture, and the multiple nodes run one instance; for another example, running in a architecture, there are multiple nodes in the architecture, the multiple nodes run multiple instances together, and so on. Regardless of whether the multiple nodes run one instance or multiple instances, the primary node (primary node) of one of the running instances can be called the first node, and the slave node (backup node) of the certain instance is called The second node refers to the certain instance as the target instance for the convenience of subsequent description.
  • the method includes but is not limited to the following steps:
  • Step S901 The first node sends a service request to each second node, where the service request is used to request the second node to perform a service.
  • the service may be transaction information reqinfo, and executing the transaction information may specifically generate a block based on the transaction.
  • the service request ⁇ reqinfo, req_order, sign_0> includes the transaction information reqinfo, a signature sign_0 of the first node to the transaction information reqinfo, and a sequence number req_order assigned to the transaction information.
  • Step S901 is equivalent to the pre-processing Apend phase in the consistency process shown in FIG. 6.
  • Step S902 the second node receives a service request ⁇ reqinfo, req_order, sign_0> sent by the first node, the second node verifies the service request, and if the signature sign_0 in the service request passes verification, and It is determined that the sequence number req_order is not used and the sequence number is the latest (for example, req_order is greater than any recorded sequence number), then the second node recognizes the reqinfo message in the service request, that is, the service request is verified to pass.
  • the second node signs the service request to obtain the first verification information ⁇ reqinfo, req_order, sign_0, sign_1>, where sign_1 is the second node's signature on the service request ⁇ reqinfo, req_order, sign_0>.
  • Each second node then sends the first verification information ⁇ reqinfo, req_order, sign_0, sign_1> to the first node.
  • step S902 corresponds to the confirmation phase in the consistency process shown in FIG. 6.
  • Step S903 The first node receives the first verification information ⁇ reqinfo, req_order, sign_0, sign_1> sent by the second node. If the number of the received first verification information exceeds a second preset threshold, then The first node executes a service, for example, generates a first block of the transaction information (including writing transaction information reqinfo and a corresponding sequence number req_order to a block message queue).
  • the first node also sends a first confirmation message ⁇ reqinfo, req_order, sign_0, sign_1, sign_2, sign_3, sign_4, ..., sign_N-1, sign_N> to the second nodes, so that the second node
  • the service request also executes a service; where sign_1, sign_2, sign_3, sign_4, ..., sign_N-1, sign_N are the signatures of different nodes to the service request ⁇ reqinfo, req_order, sign_0> (N is a positive integer), They are carried in the first verification information sent by the corresponding node to the first node, respectively.
  • the signature of each node for ⁇ reqinfo, req_order, sign_0> is used to indicate that the node has passed the verification of ⁇ reqinfo, req_order, sign_0>.
  • the second preset threshold is a preset value for reference comparison, which may be a parameter that characterizes the size of the throughput, a set ratio, a function expression, and so on.
  • the second preset threshold is equal to 2f, and f is the number of nodes that may be faulty or untrustworthy in the node cluster. For example, f is less than or equal to N is the total number of nodes in the above node cluster, and f may also be calculated or derived by other methods.
  • step S903 is equivalent to the execution of the Commit stage in the consistency process shown in FIG. 6.
  • Step S904 if the second node receives the first confirmation message sent by the first node, it is judged how many nodes pair the first to-be-checked message according to the signature of each node included in the first confirmation message ⁇ reqinfo, req_order, sign_0> The verification is passed. If the number of nodes that pass the verification exceeds a second preset threshold, the second node executes a service according to the service request, for example, generates a first block of the transaction information ( Including writing transaction information reqinfo and its corresponding sequence number req_order to the block message queue). Optionally, if the service is transaction information, the first node and the second node may also send the first blocks generated by them to the device (or client) requesting consistent processing of the transaction information.
  • Step S904 is equivalent to the completion of the Committed phase in the consistency process shown in FIG. 6.
  • the second node of the target instance does not need to confirm back and forth with other slave nodes of the target instance, and each slave node of the target instance only needs to send the signature of each slave node through the first node.
  • the first confirmation information can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • the above transaction information may refer to information of a single transaction or information of multiple transactions.
  • the information of the multiple transactions may be sent by other devices to the first device.
  • each node in the node cluster broadcasts the transaction information received by itself to other nodes in the node cluster; for another example, a device outside the node cluster sends multiple transactions to the first node.
  • the first node assigns a total serial number to the multiple transactions, and performs consensus on the multiple transactions as a unit (that is, in the prior art, a consensus consensus process is performed once for each transaction. (Here is a consensus process for multiple transactions).
  • each second node traverses and verifies each of the multiple transactions. If a transaction has already completed the validity check locally before receiving the business request, it is no longer necessary Verify the legitimacy, otherwise you need to verify the legitimacy of a certain transaction; if each of the multiple transactions is verified, and the overall serial number of the multiple transactions is given to other multiple transactions previously received If the overall serial number is larger, the verification of the transaction information is passed. It is understandable that when multiple transactions perform a consensus consensus process together, the number of communications can be greatly reduced. Assuming that there are k transactions that need to be consensus on n nodes, if consensus is made for each transaction separately, k transactions The communication complexity is O (kn). If k transactions are consensused together, the communication complexity of k transactions can be expressed as O (n).
  • FIG. 10 is a schematic structural diagram of a node 100 according to an embodiment of the present invention.
  • the node 100 includes a sending unit 1001, a receiving unit 1002, and an executing unit 1003. A detailed description of each unit is as follows.
  • the sending unit 1001 is configured to send the service request to each second node; the node is a master node running an instance, and the second node is a slave node running the one instance;
  • the receiving unit 1002 is configured to receive first verification information returned by the second node, where the first verification information includes a signature of the second node, and the first verification information indicates that the second node is responsible for the service. Request verification passed;
  • the execution unit 1003 is configured to execute the service request when the quantity of the first verification information received by the receiving unit exceeds a second preset threshold
  • the sending unit 1001 is configured to send first confirmation information to each of the second nodes, where the first confirmation information includes the service request and all of the first verification information received by the node.
  • the second node's signature; the first confirmation information is used to cause the second node to execute the service request.
  • each unit may also correspond to the corresponding description of the method embodiment shown in FIG. 9.
  • the node shown in FIG. 10 is the first node in the method embodiment shown in FIG. 9.
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • FIG. 11 is a schematic structural diagram of a node 110 according to an embodiment of the present invention.
  • the node 110 includes a receiving unit 1101, a verifying unit 1102, a sending unit 1103, and an executing unit 1104. A detailed description of each unit is as follows. .
  • the receiving unit 1101 is configured to receive the service request sent by the first node; the first node is a master node running an instance, and the node is a slave node running the one instance;
  • the verification unit 1102 is configured to verify the first to-be-verified information to generate first verification information, where the first verification information includes a signature of the node, and the first verification information indicates that the node is responsible for the service. Request verification passed;
  • the sending unit 1103 is configured to send the first verification information to the first node, so that the first node executes the service request and sends a request to the first node when the quantity of the first verification information received exceeds a second preset threshold. Sending, by the node, a first confirmation message, where the first confirmation message includes a signature from the node in each of the first verification information received by the first node;
  • the execution unit 1104 is configured to execute the service request according to the first to-be-checked information when the first confirmation message sent by the first node is received.
  • each unit may also correspond to the corresponding description of the method embodiment shown in FIG. 9.
  • the node shown in FIG. 11 is the second node in the method embodiment shown in FIG. 9.
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • FIG. 12 is a node 120 according to an embodiment of the present invention.
  • the node 120 includes a processor 1201, a memory 1202, and a communication interface 1203.
  • the processor 1201, the memory 1202, and the communication interface 1203 are connected to each other through a bus. .
  • the memory 1202 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or A portable read-only memory (CD-ROM).
  • RAM random access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • CD-ROM portable read-only memory
  • the memory 1202 is used for related instructions and data.
  • the communication interface 1203 is used to receive and send data.
  • the processor 1201 may be one or more central processing units (CPUs).
  • CPUs central processing units
  • the CPU may be a single-core CPU or a multi-core CPU.
  • the processor 1201 in the node 120 is configured to read the program code stored in the memory 1202 and perform the following operations:
  • the node 120 is a master node running an instance, and the second node is a slave node running the one instance;
  • first confirmation information includes the service request and all of the first verification information received by the node 120 A signature of a second node; the first confirmation information is used to cause the second node to execute the service request.
  • each unit may also correspond to the corresponding description of the method embodiment shown in FIG. 9.
  • the node shown in FIG. 12 is the first node in the method embodiment shown in FIG. 9.
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • FIG. 13 is a node 130 according to an embodiment of the present invention.
  • the node 130 includes a processor 1301, a memory 1302, and a communication interface 1303.
  • the processor 1301, the memory 1302, and the communication interface 1303 are connected to each other through a bus. .
  • the memory 1302 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or A portable read-only memory (CD-ROM).
  • RAM random access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • CD-ROM portable read-only memory
  • the memory 1302 is used for related instructions and data.
  • the communication interface 1303 is used to receive and send data.
  • the processor 1301 may be one or more central processing units (CPUs).
  • CPUs central processing units
  • the CPU may be a single-core CPU or a multi-core CPU.
  • the processor 1301 in the node 130 is configured to read the program code stored in the memory 1302 and perform the following operations:
  • the first node is a master node running an instance
  • the node 130 is a slave node running the one instance
  • Verifying the first to-be-verified information to generate first verification information where the first verification information includes a signature of the node 130, and the first verification information indicates that the node 130 passes verification of the service request ;
  • the service request is executed according to the first to-be-checked information.
  • each unit may also correspond to the corresponding description of the method embodiment shown in FIG. 9.
  • the node shown in FIG. 13 is the second node in the method embodiment shown in FIG. 9.
  • the second node of the one instance does not need to confirm back and forth with other slave nodes of the one instance, and each slave node of the one instance only needs to carry each slave node sent by the first node.
  • the first confirmation information signed by the node can determine whether the slave nodes other than themselves agree to execute the service request. Since mutual confirmation between the slave nodes is omitted, the communication complexity is greatly reduced.
  • An embodiment of the present invention further provides a chip system.
  • the chip system includes at least one processor, a memory, and an interface circuit.
  • the memory, the transceiver, and the at least one processor are interconnected through a line.
  • the at least one memory Instructions are stored therein; when the instructions are executed by the processor, the method flow shown in FIG. 4 is implemented.
  • An embodiment of the present invention further provides a computer-readable storage medium, where the computer-readable storage medium stores instructions, and when the computer-readable storage medium runs on a processor, the method flow shown in FIG. 4 is implemented.
  • An embodiment of the present invention further provides a computer program product.
  • the computer program product runs on a processor, the method flow shown in FIG. 4 is implemented.
  • the processes may be completed by a computer program instructing related hardware.
  • the program may be stored in a computer-readable storage medium.
  • When the program is executed, Can include the processes of the method embodiments described above.
  • the foregoing storage media include: ROM or random storage memory RAM, magnetic disks, or optical discs, which can store various program code media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Quality & Reliability (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例提供一种共识流程恢复方法及相关节点，该方法应用于节点集群，节点集群包含多个节点，多个节点共同运行多个实例，针对每个实例，多个节点中存在一个节点作为该实例的主节点，其余的节点作为该实例的从节点；多个实例对应的多个主节点分别为不同的节点，该方法包括：多个节点中的一个或多个节点从一个或多个从实例中确定目标实例，目标实例的吞吐量比主实例的吞吐量高；第一节点与各个第二节点达成共识，以将目标实例替换主实例成为新的主实例，第二节点为运行目标实例的从节点，第一节点为运行目标实例的主节点。采用本申请实施例方法，能够解决一致性处理流程中的主节点故障后共识流程恢复速度较慢的问题。

Description

一种共识流程恢复方法及相关节点 技术领域
本发明涉及大数据技术领域，尤其涉及一种共识流程恢复方法及相关节点。
背景技术
区块链是一种将数据区块以顺序相连的方式组合成的一种链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。现有执行区块链方案的节点集群在解决节点之间协商、决策如何生成新区块的问题时，使用实用拜占庭容错(practical byzantine fault tolerance，PBFT)算法进行共识，共识效率是区块链对外提供服务的核心能力。PBFT算法的核心理论是n>＝3f+1，其中，n是节点集群中的节点总数，f是允许出现故障的节点的最大数。即当出现拜占庭容错(如发送恶意错误信息)的节点不超过f个时，这节点集群中的没有出现拜占庭容错的其他节点最终都可以的得到正确的共识结果，也即是说，每个没有出现拜占庭容错的节点在收到2f+1条正确的消息后即可得出正确的共识结果。
该节点集群中包括一个主节点(primarynode)，除该主节点之外的节点为从节点(backup node)，主节点在共识过程中承担了更多的任务，例如，接收客户端(client)发送的数据处理请求，然后将该请求中的关键信息发送给节点集群中其他所有节点，以使节点集群中的节点对该数据进行共识。一旦该主节点出现故障，该节点集群中的节点就会重新选举出一个新的主节点，在选举的过程中通常采用基于竞争的选举方式，竞争过程中各个节点之间会进行大量的信息交互(因为节点集群中节点数量往往比较庞大)，这个过程会持续一定的时间；如果在此期间有数据需要共识则需要等到新的主节点产生之后才会执行。也即是说，共识流程可能会因为主节点故障而出现中断，共识流程中断之后如何快速恢复是本领域的技术人员需要解决的技术问题。
发明内容
本发明实施例公开了一种共识流程恢复方法及相关节点，能够解决一致性处理流程中的主节点故障后共识流程恢复速度较慢的问题。
第一方面，本申请实施例提供一种集群系统，所述集群系统中包含多个节点，所述多个节点共同运行多个实例，其中所述多个实例中的每个实例由所述多个节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；针对每个实例，所述多个节点中存在一个节点作为所述每个实例对应的主节点；所述多个实例对应的多个主节点分别为不同的节点。
在上述集群系统中，多个节点共同运行着多个实例，且其中各个实例对应的主节点各不相同，因此当其中一个实例的主节点出现问题并不意味着其他的实例的主节点也出现问题，因此避免了集群系统因为其中一个实例故障而导致无法正常运行的问题。
在第一方面的第一种可能的实现方式中：第一节点向每一个第二节点发送业务请求；所述第一节点为所述多个实例中一个实例对应的主节点，所述第二节点为所述一个实例对应的从节点；所述第一节点接收所述第二节点返回的第一验证信息，所述第一验证信息中 包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；若所述第一节点接收到的所述第一验证信息的数量超过第二预设阈值，所述第一节点执行所述业务请求；所述第一节点向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所述第一节点接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
可以看出，在一致性处理过程中，各个第二节点之间不需要进行来回确认，只需通过第一节点发送的携带各个第二节点签名的第一确认信息，即可确定除自身以外的其他第二节点是否同意执行所述业务请求，由于省掉了各个第二节点之间的相互确认，因此大大降低了通信复杂度。
在第一方面的第一种可能的实现方式中：所述多个节点用于从所述一个或多个从实例中确定目标实例，所述目标实例的吞吐量比所述主实例的吞吐量高；所述多个节点用于在所述多个节点之间达成共识，以使得所述目标实例替换所述主实例成为新的主实例。也即是说，因此当这多个实例中的主实例因主节点故障而不能正常运行时，不需要该多个节点重新选举主节点，而是直接根据各实例吞吐量大小从一个已经存在的实例中确定目标实例，并将目标实例替换为新的主实例，提高了故障恢复效率。
第二方面，本申请实施例提供一种共识流程恢复方法，其特征在于，应用于节点集群，所述节点集群包含多个节点，所述多个节点共同运行多个实例，其中所述多个实例中的每个实例由所述多个节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；针对每个实例，所述多个节点中存在一个节点作为该实例的主节点，其余的节点作为该实例的从节点；所述多个实例对应的多个主节点分别为不同的节点，所述方法包括：所述多个节点中的一个或多个节点从所述一个或多个从实例中确定目标实例，所述目标实例的吞吐量比所述主实例的吞吐量高；第一节点与各个第二节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，所述第二节点为运行所述目标实例的从节点，所述第一节点为运行所述目标实例的主节点。
可以看出，节点集群共同运行了一个主实例和一个或多个从实例，当主实例吞吐量较小而无法正常工作时，该节点集群直接从该一个或多个从实例中选择一个新的主实例，而不是该节点集群重新进行大量的信息交互来建立一个新的主实例。因此当原先的主实例无法正常工作时，新的主实例能够立即接替原先的主实例执行共识流程，使得共识流程中断之后能够快速恢复。
在第二方面的第一种可能的实现方式中，所述方法还包括：所述多个节点中的一个或多个节点检测所述多个实例中每个实例的吞吐量；所述第一节点根据所述每个实例的吞吐量从所述一个或多个从实例中确定所述目标实例。
在第二方面的第二种可能的实现方式中，所述每个实例均用于对业务请求进行处理，所述方法还包括：所述第一节点向每一个所述第二节点发送所述业务请求；所述第一节点接收所述第二节点返回的第一验证信息，所述第一验证信息中包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；若所述第一节点接收到的所述第一验证信息的数量超过第二预设阈值，所述第一节点执行所述业务请求；所述第一节点向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所 述第一节点接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
可以看出，在一致性处理过程中，目标实例的第二节点不需要与目标实例的其他从节点进行来回确认，目标实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
在第二方面的第三种可能的实现方式中，所述第一节点与各个第二节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，包括：所述第一节点向每一个所述第二节点发送替换请求，所述替换请求用于请求将所述目标实例替换所述主实例成为新的主实例；所述第一节点接收所述第二节点返回的第二验证信息，所述第二验证信息中包括所述第二节点的签名，所述第二验证信息表示所述第二节点对所述替换请求验证通过；若所述第一节点接收到的所述第二验证信息的数量超过第三预设阈值，所述第一节点将所述目标实例替换所述主实例成为新的主实例；所述第一节点向每一个所述第二节点发送第二确认信息，所述第二确认信息包括所述第一节点接收到的所有的所述第二验证信息中的所述第二节点的签名；所述第二确认信息用于指示每一个所述第二节点执行所述替换请求，将所述目标实例替换所述主实例成为新的主实例。
可以看出，在切换主实例的过程中，目标实例的第二节点不需要与目标实例的其他从节点进行来回确认，目标实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第二确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
在第二方面的第四种可能的实现方式中，所述多个实例中任一实例的所述多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。可以理解的是，为每个主节点配备备用主节点，能够在进行主节点更换时更快得从配备的备用主节点中选择出新的主节点，而不是盲目的从节点集群这样要大的范围内去选举新的主节点，不仅提高了主节点的选举效率，还减少了节点之间的通信。
在第二方面的第五种可能的实现方式中，所述多个实例中任意两个实例的备用主节点之间不重复。能够避免更换新的主节点时出现冲突。
在第二方面的第六种可能的实现方式中，所述多个实例中任一实例的所述多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的各个备用主节点之间存在优先级顺序；所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点，具体为：
按照所述优先级顺序，所述任一个实例的各个备用主节点中优先级最高的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。可以理解的是，通过优先级可以进一步限定选举新的主节点时的秩序，避免盲目选举而导致通信压力较大的问题。
在第二方面的第七种可能的实现方式中，所述多个实例中实例的数量L与所述节点集群中的节点数量N之间存在如下关系：
Figure PCTCN2019081998-appb-000001
N为大于或等于3的整数。
这样设置的考虑如下：拜占庭容错机制在设计之初就有一个前提，即所有参与共识的N个节点中，最多允许f个节点不可靠(例如，对交易信息做篡改、或者对交易信息做一些不符合规则的处理)，其中，N≥3f+1。而本发明的全部L个实例中，至少得有一个实例是有效的，不然共识的结果就没有意义。而可能出现的无效的实例的数量为f个，即上面f个不可靠的节点各自担任一个实例的主节点(primary节点)，因此，只要L≥f+1，就可以保证至少存在一个有效的实例。根据以上示意的N与f之间的关系，以及f与L的关系，就可以得出上述实例的数量L与节点数量N之间的关系。
第三方面，本身实施例提供一种共识方法，所述方法包括：第一节点向每一个第二节点发送所述业务请求；所述第一节点为运行一个实例的主节点，所述第二节点为运行所述一个实例的从节点；所述第一节点接收所述第二节点返回的第一验证信息，所述第一验证信息中包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；若所述第一节点接收到的所述第一验证信息的数量超过第二预设阈值，所述第一节点执行所述业务请求；所述第一节点向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所述第一节点接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
第四方面，本申请实施例提供一种共识方法，所述方法包括：第二节点接收第一节点发送的所述业务请求；所述第一节点为运行一个实例的主节点，所述第二节点为运行所述一个实例的从节点；所述第二节点对所述第一待校验信息进行验证以生成第一验证信息，所述第一验证信息包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；所述第二节点向所述第一节点发送所述第一验证信息，以便所述第一节点在接收到所述第一验证信息的数量超过第二预设阈值时执行所述业务请求和向所述第二节点发送第一确认消息，所述第一确认消息包括所述第一节点接收的各个所述第一验证信息中的来自所述第二节点的签名；若接收到所述第一节点发送的所述第一确认消息，则所述第二节点根据所述第一待校验信息执行所述业务请求。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
第五方面，本申请实施例提供一种节点，该节点包括发送单元、接收单元和执行单元，其中：发送单元，用于向每一个第二节点发送所述业务请求；所述节点为运行一个实例的主节点，所述第二节点为运行所述一个实例的从节点；接收单元，用于接收所述第二节点 返回的第一验证信息，所述第一验证信息中包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；执行单元，用于在所述接收单元接收到的所述第一验证信息的数量超过第二预设阈值，执行所述业务请求；所述发送单元，用于向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所述节点接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
第六方面，本申请实施例提供一种节点，该节点包括接收单元、验证单元、发送单元和执行单元，其中：接收单元，用于接收所述第一节点发送的所述业务请求；所述第一节点为运行一个实例的主节点，所述节点为运行所述一个实例的从节点；验证单元，用于对所述第一待校验信息进行验证以生成第一验证信息，所述第一验证信息包括所述节点的签名，所述第一验证信息表示所述节点对所述业务请求验证通过；发送单元，用于向所述第一节点发送所述第一验证信息，以便所述第一节点在接收到所述第一验证信息的数量超过第二预设阈值时执行所述业务请求和向所述节点发送第一确认消息，所述第一确认消息包括所述第一节点接收的各个所述第一验证信息中的来自所述节点的签名；执行单元，用于在接收到所述第一节点发送的所述第一确认消息时，根据所述第一待校验信息执行所述业务请求。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
第七方面，本申请实施例提供一种节点，所述节点包括处理器和存储器，所述存储器用于存储程序指令，当所述处理器调用所述程序指令时，实现第三方面所描述的方法。
第八方面，本申请实施例提供一种节点，所述节点包括处理器和存储器，所述存储器用于存储程序指令，当所述处理器调用所述程序指令时，实现第四方面所描述的方法。
第九方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在处理器上运行时，实现第三方面所描述的方法。
第十方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在处理器上运行时，实现第四方面所描述的方法。
通过实施本申请实施例，节点集群共同运行了多个实例，当其中的主实例无法正常工作时，直接从该多个实例中选择一个新的主实例，而不是该节点集群重新进行大量的信息交互来重新建立一个新的主实例。因此当原先的主实例无法正常工作时，新的主实例能够立即接替原先的主实例进行一致性处理，能够避免因更换实例而导致一致性处理延的时较长的问题。
附图说明
以下对本发明实施例用到的附图进行介绍。
图1是本发明实施例提供的一种节点集群的结构示意图；
图2是本发明实施例提供的一种节点的结构示意图；
图3是本发明实施例提供的一种数据共识方法的流程示意图；
图4是本发明实施例提供的一种共识流程恢复方法的流程示意图；
图5是本发明实施例提供的一种策略吞吐量的场景示意图；
图6是本发明实施例提供的一种共识过程的场景示意图；
图7是本发明实施例提供的一种选举主节点的场景示意图；
图8是本发明实施例提供的一种选举主节点的场景示意图；
图9是本发明实施例提供的一种数据共识方法的流程示意图；
图10是本发明实施例提供的一种节点的结构示意图；
图11是本发明实施例提供的一种节点的结构示意图；
图12是本发明实施例提供的一种节点的结构示意图；
图13是本发明实施例提供的一种节点的结构示意图。
具体实施方式
现有技术中，节点集群中的节点共同运行一个实例，通过该一个实例对交易进行一致性处理，一旦该一个实例出现故障无法正常运行，那么该节点集群中的各个节点需要重新进行协商，从而选举出新的实例进行一致性处理，重新选举一致性实例的过程耗时较长，在此期间一致性处理的任务相当于暂停，本申请实施例能够避免因重新选举一致性实例而导致一致性处理流程暂停的问题，下面结合本发明实施例中的附图对本发明实施例进行描述。
请参见图1，图1是本发明实施例提供的一种节点集群10的结构示意图，该节点集群10包括多个节点101，该节点集群10运行着多个实例102。
每个实例102均由节点集群共同运行。具体来说，节点集群10中的每个节点101均可以划分出若干个逻辑节点，每个逻辑节点可以充当一个实例的运行节点，一个节点101上的若干个逻辑节点可以分别充当不同实例的运行节点，一个节点上的任意两个逻辑节点不能同时充当一个实例的运行节点；对于任意一个实例来说，该多个节点中每个未出现故障的节点均需各自提供一个逻辑节点作为这个实例的运行节点。
所述节点集群包含运行所述每个实例的一个主节点和一个或者多个从节点。具体来说，任意一个实例都需要多个逻辑节点来共同运行，并且这多个逻辑节点中要有一个主节点和一个或者多个从节点，即该节点集群中包含的多个节点需要有一个节点(的逻辑节点)作为这个实例的主节点，其余节点(的逻辑节点)作为这个实例的从节点。并且，节点集群中的任意一个节点最多作为一个实例的主节点。
另外，所述多个实例包括一个主实例和一个或者多个从实例，所述多个实例中每个实 例用于执行业务请求(例如，根据交易信息生成区块)，所述多个实例中的主实例还用于将执行业务请求的后的结果落盘(例如，若生成了区块则将生成的区块落盘)，其中，落盘是指存储在磁盘中，通常指永久存储或者较长时间的存储，而不是缓存那样短时间存储。另外，从实例不会将执行业务请求后的结果罗盘，例如，从实例可能只是将生成的区块进行缓存，或者生成区块之后完全不作存储。
请参见图2，图2是本申请实施例提供的一种节点101的结构示意图，该节点101可以为该节点集群10中的任意一个节点；该节点101包括节点管理模块1012、共识实例IO管理模块1013、共识实例信息管理模块1014、配置模块1015、共识实例模块1016和账本管理模块1017，下面对各个模块及单元进行介绍：
节点管理模块1012：负责节点管理，包括节点启动、主备实例切换的决策与执行。
共识实例IO管理模块1013：用于对运行的各个实例进行输入/输出(Input/Output，IO)监控，以获得各个实例的吞吐量情况。
共识实例信息管理模块1014：用于维护节点上各个实例的信息，包括当前节点在各个实例中充当的角色(主节点还是从节点)、访问地址、端口信息等。
配置模块1015：负责读取、加载节点运行时所需的初始参数。
共识实例模块1016：共识实例模块包括一致性单元、消息管理单元、业务执行单元和数据加密认证单元。其中，一致性单元用于实例进行共识；消息管理单元用于接收和发送实例的消息，最终消息可能还会经过上述通信模块；业务执行单元用于根据业务请求执行业务(例如，打包交易并创建区块)；数据加密认证单元用于校验消息和数据的合法性，并对消息和数据进行加解密。
账本管理模块1017：用于维护节点上的区块链信息。
如图3示意了以上模块的大致执行流程，具体如下：①、共识实例信息管理模块1014根据节点启动指令(node start)；②、共识实例信息管理模块1014向配置模块1015获取配置信息；③、配置模块1015从外部获取并生成配置信息，并返回给共识实例信息管理模块1014；④、共识实例信息管理模块1014加载配置信息进行启动，并将启动结果返回给节点管理模块(还可能将启动结果反馈给触发node start的用户)；⑤、节点管理模块从IO管理模块获取各个实例的吞吐率；⑥、节点管理模块根据各实例的吞吐率通知共识实例信息管理模块进行从实例到主实例的切换。
可以理解的是，图2中各个模块和单元是根据功能划分出的功能模块，在具体实现时其中部分功能块可以被细分为更多细小的功能模块，部分功能模块也可能组合成一个功能模块，但无论这些功能模块是进行了细分还是组合，都不会对该节点10实施本申请的方法流程产生实质影响。通常，每个功能模块都对应有各自的程序代码(或者说程序指令)，这些功能模块各自对应的程序代码在处理器上运行时，使得功能模块执行相应的流程从而实现相应功能。
请参见图4，图4是本发明实施例提供的一种共识流程恢复方法的流程示意图，该方法可以基于图1所示的节点集群来实现，也可以基于其他架构来实现，该方法包括但不限于如下步骤：
实例切换流程如下：
步骤S401：节点集群中每个节点检测所述多个实例中每个实例的吞吐量。
具体地，本申请实施例中多个实例包括一个主实例和一个或者多个从实例，且该节点集群中的每个节点可以识别哪个为主实例哪些为从实例，其中，每个实例都会实时地根据业务请求执行业务(例如，基于交易信息生成区块)。在实际操作中，有些实例根据业务请求执行业务的效率高，有些实例根据业务请求执行业务的效率低，各个实例执行业务的效率高低可以通过单位时间内各个实例的吞吐量(或者说“吞吐量”)来确定，效率越高的实例在单位时间内的吞吐量也越高。前面提到，每个实例都由该节点集群中的所有节点(出现故障的节点除外)共同参与，也就是说该节点集群中的每个节点(出现故障的节点除外)上同时参与了这多个实例的运行，因此该节点集群中每个节点可以获取到该多个实例中每个实例的吞吐量。
步骤S402：节点集群中的节点根据自己检测的所述每个实例的吞吐量确定目标实例。
具体地，该目标实例为该一个或者多个从实例中吞吐量比替换前的主实例的吞吐量高的从实例，例如，比替换前的主实例的吞吐量高于第一预设阈值的从实例。该第一预设阈值为预先设置的用于参考对比的数值，其可以具体为表征吞吐量大小的参数，也可以为一个设定的比例，还可以为一个函数表达式，等等。假若比替换前的主实例的吞吐量高于第一预设阈值的从实例有多个，那么该目标实例可以具体为其中任意一个，或者吞吐量最高的一个，或者满足预设的某个筛选条件的一个。举例来说，图5示意了几个实例的吞吐量，其中示意了主实例的吞吐量T2，从实例1的吞吐量T1，从实例2的吞吐量T3，由于从实例1的吞吐量T1比主实例T2的吞吐量高于第一预设阈值，因此从实例1为目标实例。
第一种可选方案中，节点集群中每个节点各自确定出目标实例并向自己确定出的目标实例的主节点发送第一请求消息，以请求将自己确定出的目标实例替换为主实例，例如，该第一请求消息可以为带签名的Propose消息<propose，sign_0,>，其中，propose用于请求将目标实例替换为新的主实例，sign_0为发送该propose消息的节点对propose的签名。可选的，可能存在一些节点确定出的目标实例不同，因此这一些节点会各自向不同目标实例的主节点发送第一请求消息，相应地，每个主节点接收发送给自己的第一请求消息，并确定第一请求消息的数量是否达到预设阈值，此处的预设阈值为预先设置的用于参考对比的值，接收到第一请求消息的各个主节点中只有一个主节点接收到的第一请求消息的数量会大于该预设阈值，可选的，该预设阈值等于2f+1，其中，f为节点集群中可能出错或者不可信的节点的数量，例如，f小于或者等于
Figure PCTCN2019081998-appb-000002
N为上述节点集群中的节点的总数量，当然，f还可能通过其他方式计算或者推导。
若一个目标实例的主节点确定自己接收到的第一请求消息的数量达到该预设阈值，可以称该一个目标实例的主节点为第一节点，称该一个目标实例的从节点为第二节点，后续该第一节点需要与各个第二节点达成共识，以将确定出的目标实例替换为新的主实例，该第一节点与各个第二节点达成共识的过程将在骤S403中描述。
第二种可选方案中，该节点集群中预先配置(或选举)一个节点来确定目标实例，该一个节点确定目标实例之后向确定出的目标实例的主节点发送第一请求消息，可以称该目标实例的主节点为第一节点，称该目标实例的从节点为第二节点，该第一节点接收到该第一请求消息之后，该第一节点需要与各个第二节点达成共识，以将该目标实例替换为新的 主实例，该第一节点与各个第二节点达成共识的过程将在骤S403中描述。
第三种可选的方案中，该节点集群中某一个节点确定目标实例之后，若自己就是确定出的目标实例的主节点，可以称该目标实例的主节点为第一节点，称该目标实例的从节点为第二节点，该第一节点需要与各个第二节点达成共识，以将该目标实例替换为新的主实例，该第一节点与各个第二节点达成共识的过程将在骤S403中描述。
步骤S403：第一节点与各个第二节点达成共识，以将所述节点集群运行的多个实例中的目标实例替换为新的主实例。
具体地，第一节点获知需要将所述目标实例替换为新的主实例后，即与节点集群中的各个第二节点进行协商，协商的目的是将所述节点集群运行的多个实例中的目标实例替换为新的主实例，协商的一种可选流程如下：
第1步，第一节点向各个第二节点发送替换请求，所述替换请求用于指示将所述目标从实例替换为新的主实例。该替换请求可以为带签名的Candidate消息<candidate，sign_1>，其中，candidate用于指示将所述目标从实例替换为新的主实例，sign_1为该第一节点对candidate的签名。
第2步，第二节点接收第一节点发送的替换请求，对所述替换请求进行验证，可选的，对所述替换请求进行验证的过程包括对目标实例的吞吐量的验证，具体来说，由于第二节点也参与了各个实例的运行，因此第二节点也可以获知各个实例的吞吐量；该第二节点会判断第一节点通过替换请求指示要切换到的目标实例的吞吐量是否真的比切换之前的主实例的吞吐量高于第一预设阈值，若真的高于第一预设阈值则对目标实例的吞吐量的验证通过，否则不通过。另外，对所述替换请求进行验证的过程还包括对该替换请求中的签名的验证，其中，签名的验证至少可以达到两个目的：1、该替换请求是否为第一节点出来的，2、该替换请求在发送过程中是否有被篡改过，如果替换请求是由第一节点发出来且发出来之后未被修改过，则对替换请求中的签名的验证通过。
综上，若对所述替换请求验证通过则第二节点生成第二验证信息，然后向所述第一节点发送所述第二验证信息。该第二验证信息可以为带签名的agree消息<agree，sign>，其中，agree用于表示对替换请求验证通过，sign为第二节点对该agree的签名。
第3步，所述第一节点接收所述第二节点发送的对所述替换请求的第二验证信息；若接收到的所述第二验证信息的数量达到第三预设阈值，则认为第一节点与各个第二节点对将目标实例替换为新的主实例达成共识，因此所述第一节点将所述目标实例替换为新的主实例；并且所述第一节点向所述各个第二节点发送第二确认信息，以指示所述各个第二节点将所述目标实例替换为新的主实例，该第二确认信息可以为带签名的commit消息<commit，sign_0,sign_1,……sign_2f>，其中，commit用于指示该第二确认信息所需指示的内容，sign_0,sign_1,……sign_2f依次为各个向第一节点发送了第二验证信息的第二节点的签名。另外，该第三预设阈值为预先设置的用于参考对比的值，其可以具体为表征吞吐量大小的参数，也可以为一个设定的比例，还可以为一个函数表达式，等等。可选的，该第三预设阈值等于2f，f为节点集群中可能出错或者不可信的节点的数量，例如，f小于或者等于
Figure PCTCN2019081998-appb-000003
N为上述节点集群中的节点的总数量，当然，f还可能通过其他方式计算或者推导。
第4步，所述第二节点接收所述第一节点发送的第二确认信息，该第二节点可以获取该第二确认信息中的各个签名，根据各个签名可以获知向第一节点发送了第二验证信息的节点数量超过第三预设阈值，即同意将目标实例切换为主实例的节点数量超过第三预设阈值，因此第二节点将所述目标实例替换为新的主实例。
在上述第三种可选方案的前提下，可能存在多个节点本身就是自己确定出的目标实例的主节点，因此可能出现多个第一节点各自与相应的第二节点达成共识，但是根据共识的机制，最终只会有一个第一节点与相应的第二节点达成共识。也即是说，最终只会选择出一个目标实例来替换原来的主实例成为新的主实例。另外，本申请实施例中的“达成共识”为是指一些节点通过协商来确定执行一项操作，“达成共识”属于本领域的专业术语，此处不再做过多描述。
一致性共识流程如下：
在一种可选的方案中，实例对交易信息进行一致性共识流程包含预处理Apend、确认Confirm、执行Commit、完成Commited四个阶段，如图6所示，详细流程如下：
预处理Apend阶段：第一节点向各个第二节点发送业务请求，该业务请求用于请求第二节点执行业务。举例来说，该业务可以为交易信息reqinfo，执行交易信息可以具体为根据交易生成区块。可选的，所述业务请求<reqinfo,req_order，sign_0>包括所述交易信息reqinfo、第一节点对所述交易信息reqinfo的签名sign_0和为所述交易信息分配的序号req_order。
确认Confirm阶段：所述第二节点接收第一节点发送的业务请求<reqinfo,req_order，sign_0>，所述第二节点对所述业务请求进行验证，如果对该业务请求中的签名sign_0验证通过、并且确定序号req_order未被使用且序号最新(例如，req_order大于任意已记录的序号)，那么第二节点认可该业务请求中的reqinfo消息，即对业务请求验证通过。随后，该第二节点对业务请求进行签名得到第一验证信息<reqinfo,req_order，sign_0，sign_1>，其中，sign_1为第二节点对业务请求<reqinfo,req_order，sign_0>的签名。然后各个第二节点向所述第一节点发送所述第一验证信息<reqinfo,req_order，sign_0，sign_1>。
执行Commit阶段：所述第一节点接收所述第二节点发送的第一验证信息<reqinfo,req_order，sign_0，sign_1>，若接收到的所述第一验证信息的数量超过第二预设阈值，则所述第一节点执行业务，例如，生成所述交易信息的第一区块(包括将交易信息reqinfo和其对应的序列号req_order写入区块消息队列)。另外，该第一节点还向所述各个第二节点发送第一确认消息<reqinfo,req_order，sign_0，sign_1，sign_2，sign_3，sign_4，……，sign_N-1，sign_N>，以使第二节点根据所述业务请求也执行业务；其中，sign_1，sign_2，sign_3，sign_4，……，sign_N-1，sign_N分别为不同的节点对业务请求<reqinfo,req_order，sign_0>的签名(N为正整数)，分别携带在相应的节点发送给第一节点的第一验证信息中。每个节点对<reqinfo,req_order，sign_0>的签名用于表明该节点对<reqinfo,req_order，sign_0>验证通过。另外，该第二预设阈值为预先设置的用于参考对比的值，其可以具体为表征吞吐量大小的参数，也可以为一个设定的比例，还可以为一个函数表达式，等等。可选的，该第二预设阈值等于2f，f为节点集群中可能出错或者不可信的节点的数量，例如，f小于或者等于
Figure PCTCN2019081998-appb-000004
N为上述节点集群中的节点的总数量，当然，f还可能通过 其他方式计算或者推导。
完成Commited阶段：若第二节点接收到所述第一节点发送的所述第一确认消息，则根据第一确认消息包含的各个节点的签名判断有多少个节点对对上述第一待校验消息<reqinfo,req_order，sign_0>验证通过了，如果验证通过的节点数量超过第二预设阈值，则所述第二节点根据所述业务请求执行业务，例如，生成所述交易信息的第一区块(包括将交易信息reqinfo和其对应的序列号req_order写入区块消息队列)。可选的，假若该业务为交易信息，该第一节点和该第二节点还可以将各自产生的第一区块发送给请求对所述交易信息进行一致性处理的设备(或客户端)。
可以看出，在一致性处理过程中，目标实例的第二节点不需要与目标实例的其他从节点进行来回确认，目标实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
需要说明的是，上述交易信息可以指单笔交易的信息也可以指多笔交易的信息，当交易信息指的是多笔交易的信息时，该多笔交易的信息可以为其他设备发送给第一节点的，例如，节点集群中的各个节点将自己收到的交易信息广播给节点集群中的其他节点；再如，该节点集群以外的设备向该第一节点发送了多笔交易的信息。在进行一致性共识过程中，该第一节点赋予该多笔交易一个总的序列号，并以该多笔交易为单位进行共识(即现有技术是每笔交易要执行一次一致性共识流程，而这里是多笔交易一起执行一次一致性共识流程)。可选的，各个第二节点在接收到业务请求后，遍历校验该多个笔交易中每笔交易，如果某笔交易在接收到该业务请求之前已经在本地完成合法性校验则无需再校验合法性，否则需要对该某笔交易的合法性进行校验；若该多笔交易中每笔交易均验证通过，并且赋予该多笔交易的整体序列号此前收到的其他多笔交易的整体序列号要大，则对交易信息的验证通过。可以理解的是，当多笔交易一起进行一致性共识流程时，能够大量减少通信次数，假设有k笔交易需要在n个节点上进行共识，如果为每笔交易单独进行共识，则k笔交易的通信复杂度为O(kn)，如果k笔交易一起进行共识，则k笔交易的通信复杂度可以表示为O(n)。
主节点选举流程如下：
在又一种可选的方案中，所述多个实例中任一实例的所述多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点；可选的，任意两个实例的备用主节点之间不重复。举例来说，在配置上述多个实例的时候就对节点集群中的节点进行排序，例如，根据硬件性能强弱、IP地址、设备名称等参数进行排序。假若该多个实例中实例的数量为L，那么可以取排序中前L个节点，这L个节点中每个节点各作为一个实例的主节点；然后从节点集群中除这L个节点外的节点中选择各个实例的备用主节点，各个实例的备用主节点不重复，例如，该多个实例中，第1个实例的备用主节点的序号等于1+iL的节点，第2个实例的备用主节点的序号等于2+iL的节点，……，第L个实例的备用主节点的序号等于L+iL的节点，其中，i取大于等于1的正整数，i具体取哪些值可以预先定义好，以便控制每个实例的备用主节点的数量，这L个实例的排序不作限定。当然，还可以通过其他方式 保证各个实例的备用主节点不重复，其他方式此处不一一举例。
可选的，所述任意一个实例的各个备用主节点之间存在优先级顺序，具体基于哪些参数来确定各个备用主节点的优先级此处不作限定，可选的，排序越靠前的备用主节点的优先级越高；在这个前提下，所述任意一个实例的备用主节点用于在所述任意一个实例的主节点需要更换时变更为所述任意一个实例的新的主节点，具体为：按照所述优先级顺序，所述任一个实例的各个备用主节点中优先级最高的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。举例来说，如图7所示，该多个实例中包括主实例，从实例1和从实例2，其中，主实例的主节点为节点1，备用主节点依次为节点3和节点0(且节点3的优先级高于节点0的优先级)；从实例1的主节点为节点2，备用主节点为节点5，从实例2的主节点为节点4，备用主节点为节点6。那么，作为主实例当前主节点的节点1出现故障时，则选择节点3作为该主实例的新主节点，若节点3也故障，则选择节点0作为该主实例的新主节点；作为从实例1当前主节点的节点2出现故障时，则选择节点5作为该从实例1的新主节点；作为从实例2当前主节点的节点4出现故障时，则选择节点6作为该从实例2的新主节点；图8为对应的场景示意图。
下面以某个实例为例讲述一种可选的选举主节点的流程：1、节点集群中各个节点根据该某个实例的备用主节点的优先级顺序，发送选举(vote)信息给其中优先级最高的备用主节点，以指示该优先级最高的备用主节点切换为新的主节点，该某个实例的优先级最高的备用主节点接收到预设数量的vote信息后，则广播选举确认(vote_commit)信息，以指示该某个实例新当前的主节点为其优先级最高的备用主节点。然后节点集群中各个节点根据该vote_commit信息更新自己的配置信息，以将该优先级最高的备用主节点配置为该某个实例的新的主节点。可选的，该预设数量等于
Figure PCTCN2019081998-appb-000005
在一种可选的方案中，所述多个实例中实例的数量L与所述节点集群中的节点数量N之间存在如下关系：
Figure PCTCN2019081998-appb-000006
这样设置的考虑如下：拜占庭容错机制在设计之初就有一个前提，即所有参与共识的N个节点中，最多允许f个节点不可靠(例如，对交易信息做篡改、或者对交易信息做一些不符合规则的处理)，其中，N≥3f+1。而本发明的全部L个实例中，至少得有一个实例是有效的，不然共识的结果就没有意义。而可能出现的无效的实例的数量为f个，即上面f个不可靠的节点各自担任一个实例的主节点(primary节点)，因此，只要L≥f+1，就可以保证至少存在一个有效的实例。根据以上示意的N与f之间的关系，以及f与L的关系，就可以得出上述实例的数量L与节点数量N之间的关系。
在图4所描述的方法中，节点集群共同运行了多个实例，当其中的主实例无法正常工作时，直接从该多个实例中选择一个新的主实例，而不是该节点集群重新进行大量的信息交互来重新建立一个新的主实例。因此当原先的主实例无法正常工作时，新的主实例能够立即接替原先的主实例进行一致性处理，能够避免因更换实例而导致一致性处理延的时较长的问题。
请参见图9，图9是本发明实施例提供的一种数据共识方法，该方法可以基于图1所 示的节点集群来实现，也可以基于其他架构来实现，例如，运行在一种架构中，该架构中存在多个节点，该多个节点运行一个实例；再如，运行在一种架构中，该架构中存在多个节点，该多个节点共同运行多个实例，等等。无论该多个节点运行一个实例还是运行多个实例，可以称其运行的实例中的某一实例的主节点(primary node)为第一节点，称该某一实例的从节点(backup node)为第二节点，称该某一实例为目标实例，以方便后续描述。该方法包括但不限于如下步骤：
步骤S901：所述第一节点向各个第二节点发送业务请求，该业务请求用于请求第二节点执行业务。举例来说，该业务可以为交易信息reqinfo，执行交易信息可以具体为根据交易生成区块。可选的，所述业务请求<reqinfo,req_order，sign_0>包括所述交易信息reqinfo、第一节点对所述交易信息reqinfo的签名sign_0和为所述交易信息分配的序号req_order。
其中，步骤S901相当于图6所示的一致性流程中的预处理Apend阶段。
步骤S902：所述第二节点接收第一节点发送的业务请求<reqinfo,req_order，sign_0>，所述第二节点对所述业务请求进行验证，如果对该业务请求中的签名sign_0验证通过、并且确定序号req_order未被使用且序号最新(例如，req_order大于任意已记录的序号)，那么第二节点认可该业务请求中的reqinfo消息，即对业务请求验证通过。随后，该第二节点对业务请求进行签名得到第一验证信息<reqinfo,req_order，sign_0，sign_1>，其中，sign_1为第二节点对业务请求<reqinfo,req_order，sign_0>的签名。然后各个第二节点向所述第一节点发送所述第一验证信息<reqinfo,req_order，sign_0，sign_1>。
其中，步骤S902相当于图6所示的一致性流程中的确认Confirm阶段。
步骤S903：所述第一节点接收所述第二节点发送的第一验证信息<reqinfo,req_order，sign_0，sign_1>，若接收到的所述第一验证信息的数量超过第二预设阈值，则所述第一节点执行业务，例如，生成所述交易信息的第一区块(包括将交易信息reqinfo和其对应的序列号req_order写入区块消息队列)。另外，该第一节点还向所述各个第二节点发送第一确认消息<reqinfo,req_order，sign_0，sign_1，sign_2，sign_3，sign_4，……，sign_N-1，sign_N>，以使第二节点根据所述业务请求也执行业务；其中，sign_1，sign_2，sign_3，sign_4，……，sign_N-1，sign_N分别为不同的节点对业务请求<reqinfo,req_order，sign_0>的签名(N为正整数)，分别携带在相应的节点发送给第一节点的第一验证信息中。每个节点对<reqinfo,req_order，sign_0>的签名用于表明该节点对<reqinfo,req_order，sign_0>验证通过。另外，该第二预设阈值为预先设置的用于参考对比的值，其可以具体为表征吞吐量大小的参数，也可以为一个设定的比例，还可以为一个函数表达式，等等。可选的，该第二预设阈值等于2f，f为节点集群中可能出错或者不可信的节点的数量，例如，f小于或者等于
Figure PCTCN2019081998-appb-000007
N为上述节点集群中的节点的总数量，f还可能通过其他方式计算或者推导。
其中，步骤S903相当于图6所示的一致性流程中的执行Commit阶段。
步骤S904：若第二节点接收到所述第一节点发送的所述第一确认消息，则根据第一确认消息包含的各个节点的签名判断有多少个节点对对上述第一待校验消息<reqinfo,req_order，sign_0>验证通过了，如果验证通过的节点数量超过第二预设阈值，则所述第二节点根据所述业务请求执行业务，例如，生成所述交易信息的第一区块(包括将 交易信息reqinfo和其对应的序列号req_order写入区块消息队列)。可选的，假若该业务为交易信息，该第一节点和该第二节点还可以将各自产生的第一区块发送给请求对所述交易信息进行一致性处理的设备(或客户端)。
其中，步骤S904相当于图6所示的一致性流程中的完成Commited阶段。
可以看出，在一致性处理过程中，目标实例的第二节点不需要与目标实例的其他从节点进行来回确认，目标实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
需要说明的是，上述交易信息可以指单笔交易的信息也可以指多笔交易的信息，当交易信息指的是多笔交易的信息时，该多笔交易的信息可以为其他设备发送给第一节点的，例如，节点集群中的各个节点将自己收到的交易信息广播给节点集群中的其他节点；再如，该节点集群以外的设备向该第一节点发送了多笔交易的信息。在进行一致性共识过程中，该第一节点赋予该多笔交易一个总的序列号，并以该多笔交易为单位进行共识(即现有技术是每笔交易要执行一次一致性共识流程，而这里是多笔交易一起执行一次一致性共识流程)。可选的，各个第二节点在接收到业务请求后，遍历校验该多个笔交易中每笔交易，如果某笔交易在接收到该业务请求之前已经在本地完成合法性校验则无需再校验合法性，否则需要对该某笔交易的合法性进行校验；若该多笔交易中每笔交易均验证通过，并且赋予该多笔交易的整体序列号此前收到的其他多笔交易的整体序列号要大，则对交易信息的验证通过。可以理解的是，当多笔交易一起进行一致性共识流程时，能够大量减少通信次数，假设有k笔交易需要在n个节点上进行共识，如果为每笔交易单独进行共识，则k笔交易的通信复杂度为O(kn)，如果k笔交易一起进行共识，则k笔交易的通信复杂度可以表示为O(n)。
上述详细阐述了本发明实施例的方法，下面提供了本发明实施例的装置。
请参见图10，图10是本发明实施例提供的一种节点100的结构示意图，该节点100包括发送单元1001、接收单元1002和执行单元1003，其中，各个单元的详细描述如下。
发送单元1001用于向每一个第二节点发送所述业务请求；所述节点为运行一个实例的主节点，所述第二节点为运行所述一个实例的从节点；
接收单元1002用于接收所述第二节点返回的第一验证信息，所述第一验证信息中包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；
执行单元1003用于在所述接收单元接收到的所述第一验证信息的数量超过第二预设阈值，执行所述业务请求；
所述发送单元1001用于向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所述节点接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
需要说明的是，各个单元的实现还可以对应参照图9所示的方法实施例的相应描述。图10所示的节点为图9所示方法实施例中的第一节点。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他 从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
请参见图11，图11是本发明实施例提供的一种节点110的结构示意图，该节点110包括接收单元1101、验证单元1102、发送单元1103和执行单元1104，其中，各个单元的详细描述如下。
接收单元1101用于接收所述第一节点发送的所述业务请求；所述第一节点为运行一个实例的主节点，所述节点为运行所述一个实例的从节点；
验证单元1102用于对所述第一待校验信息进行验证以生成第一验证信息，所述第一验证信息包括所述节点的签名，所述第一验证信息表示所述节点对所述业务请求验证通过；
发送单元1103用于向所述第一节点发送所述第一验证信息，以便所述第一节点在接收到所述第一验证信息的数量超过第二预设阈值时执行所述业务请求和向所述节点发送第一确认消息，所述第一确认消息包括所述第一节点接收的各个所述第一验证信息中的来自所述节点的签名；
执行单元1104用于在接收到所述第一节点发送的所述第一确认消息时，根据所述第一待校验信息执行所述业务请求。
需要说明的是，各个单元的实现还可以对应参照图9所示的方法实施例的相应描述。图11所示的节点为图9所示方法实施例中的第二节点。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
请参见图12，图12是本发明实施例提供的一种节点120，该节点120包括处理器1201、存储器1202和通信接口1203，所述处理器1201、存储器1202和通信接口1203通过总线相互连接。
存储器1202包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable read only memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)，该存储器1202用于相关指令及数据。通信接口1203用于接收和发送数据。
处理器1201可以是一个或多个中央处理器(central processing unit，CPU)，在处理器1201是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。
节点120中的处理器1201用于读取所述存储器1202中存储的程序代码，执行以下操作：
通过所述通信接口1202向每一个第二节点发送所述业务请求；所述节点120为运行一个实例的主节点，所述第二节点为运行所述一个实例的从节点；
通过所述通信接口1202接收所述第二节点返回的第一验证信息，所述第一验证信息中 包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；
若所述通信接口1202接收到的所述第一验证信息的数量超过第二预设阈值，执行所述业务请求；
通过所述通信接口向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所述节点120接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
需要说明的是，各个单元的实现还可以对应参照图9所示的方法实施例的相应描述。图12所示的节点为图9所示方法实施例中的第一节点。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
请参见图13，图13是本发明实施例提供的一种节点130，该节点130包括处理器1301、存储器1302和通信接口1303，所述处理器1301、存储器1302和通信接口1303通过总线相互连接。
存储器1302包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable read only memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)，该存储器1302用于相关指令及数据。通信接口1303用于接收和发送数据。
处理器1301可以是一个或多个中央处理器(central processing unit，CPU)，在处理器1301是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。
节点130中的处理器1301用于读取所述存储器1302中存储的程序代码，执行以下操作：
通过所述通信接口1303接收第一节点发送的所述业务请求；所述第一节点为运行一个实例的主节点，所述节点130为运行所述一个实例的从节点；
对所述第一待校验信息进行验证以生成第一验证信息，所述第一验证信息包括所述节点130的签名，所述第一验证信息表示所述节点130对所述业务请求验证通过；
通过所述通信接口1303向所述第一节点发送所述第一验证信息，以便所述第一节点在接收到所述第一验证信息的数量超过第二预设阈值时执行所述业务请求和向所述节点130发送第一确认消息，所述第一确认消息包括所述第一节点接收的各个所述第一验证信息中的来自所述节点130的签名；
若通过所述通信接口1303接收到所述第一节点发送的所述第一确认消息，则根据所述第一待校验信息执行所述业务请求。
需要说明的是，各个单元的实现还可以对应参照图9所示的方法实施例的相应描述。图13所示的节点为图9所示方法实施例中的第二节点。
可以看出，在一致性处理过程中，该一个实例的第二节点不需要与该一个实例的其他从节点进行来回确认，该一个实例的各个从节点只需通过第一节点发送的携带各个从节点 签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
本发明实施例还提供一种芯片系统，所述芯片系统包括至少一个处理器，存储器和接口电路，所述存储器、所述收发器和所述至少一个处理器通过线路互联，所述至少一个存储器中存储有指令；所述指令被所述处理器执行时，实现图4所示的方法流程。
本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在处理器上运行时，实现图4所示的方法流程。
本发明实施例还提供一种计算机程序产品，当所述计算机程序产品在处理器上运行时，实现图4所示的方法流程。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

Claims (30)

  1. 一种共识方法，其特征在于，所述方法包括：
    第一节点向M个从节点发送业务请求；所述第一节点为运行一个实例的主节点，所述M个从节点为运行所述实例的从节点，M为正整数；
    所述第一节点接收N个从节点返回的第一验证信息，所述第一验证信息包括生成所述第一验证信息的从节点的签名，所述第一验证信息表示生成所述第一验证信息的从节点对所述业务请求验证通过，N为小于等于M的正整数；
    若所述第一节点接收到的所述第一验证信息的数量N超过第二预设阈值，所述第一节点执行所述业务请求；
    所述第一节点向所述M个从节点发送第一确认信息，所述第一确认信息包括所述N个从节点返回的第一验证信息中所包括的所述N个从节点的签名；所述第一确认信息用于使得所述M个从节点执行所述业务请求。
  2. 根据权利要求1所述的方法，其特征在于，节点集群包括所述第一节点和所述M个从节点，所述第一节点和所述M个从节点上共同运行多个实例，其中所述多个实例中的每个实例由所述第一节点和所述M个从节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；所述第一节点为运行所述多个实例中的目标实例的主节点，所述M个从节点为运行所述目标实例的从节点，所述方法还包括：
    所述第一节点与所述M个从节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，所述目标实例的吞吐量比所述主实例的吞吐量高。
  3. 根据权利要求1或2所述的方法，其特征在于，运行所述多个实例中任一实例的多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  4. 根据权利要求3所述的方法，其特征在于，所述多个实例中任意两个实例的备用主节点之间不重复。
  5. 根据权利要求3或4所述的方法，其特征在于，所述任一个实例的各个备用主节点之间存在不同的优先级；所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点，具体为：
    按照所述优先级，所述任一个实例的各个备用主节点中优先级最高的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  6. 根据权利要求2-5任一项所述的方法，其特征在于，所述多个实例中实例的数量L与所述节点集群中的节点数量K之间存在如下关系：
    Figure PCTCN2019081998-appb-100001
    K＝M+1，K为大于或等于3的整数。
  7. 一种共识方法，其特征在于，所述方法包括：
    第二节点接收第一节点发送的业务请求；所述第一节点为运行一个实例的主节点，所述第二节点为运行所述一个实例的M个从节点之一，M为正整数；
    所述第二节点对所述业务请求进行验证以生成第一验证信息，所述第一验证信息包括生成所述第一验证信息的从节点的签名，所述第一验证信息表示生成所述第一验证信息的从节点对所述业务请求验证通过；
    所述第二节点向所述第一节点发送所述第一验证信息；
    所述第二节点接收所述第一节点发送的第一确认消息，并根据所述业务请求执行所述业务请求，所述第一确认消息包括N个从节点各自的签名，所述N个从节点各自的签名为所述第一节点接收到N个从节点所发送的N个第一验证消息中所包括的，所述第一确认消息表示所述第一节点接收到所述第一验证信息的数量N超过第二预设阈值，N为小于等于M的正整数。
  8. 根据权利要求7所述的方法，其特征在于，节点集群包括所述第一节点和所述M个从节点，所述第一节点和所述M个从节点上共同运行多个实例，其中所述多个实例中的每个实例由所述第一节点和所述M个从节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；所述第一节点为运行所述多个实例中的目标实例的主节点，所述第二节点为运行所述目标实例的所述M个从节点之一，所述方法还包括：
    所述第二节点与所述第一节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，所述目标实例的吞吐量比所述主实例的吞吐量高。
  9. 根据权利要求7或8所述的方法，其特征在于，运行所述多个实例中任一实例的多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  10. 根据权利要求9所述的方法，其特征在于，所述多个实例中任意两个实例的备用主节点之间不重复。
  11. 根据权利要求9或10所述的方法，其特征在于，所述任一个实例的各个备用主节点之间存在不同的优先级；所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点，具体为：
    按照所述优先级，所述任一个实例的各个备用主节点中优先级最高的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  12. 根据权利要求8-11任一项所述的方法，其特征在于，所述多个实例中实例的数量L与所述节点集群中的节点数量K之间存在如下关系：
    Figure PCTCN2019081998-appb-100002
    K＝M+1，K为大于或等于3的整数。
  13. 一种节点，其特征在于，包括：
    发送单元，用于向M个从节点发送所述业务请求；所述节点为运行一个实例的主节点，所述M个从节点为运行所述一个实例的从节点，M为正整数；
    接收单元，用于接收N个从节点返回的第一验证信息，所述第一验证信息包括生成所述第一验证信息的从节点的签名，所述第一验证信息表示生成所述第一验证信息的从节点对所述业务请求验证通过，N为小于等于M的正整数；
    执行单元，用于在所述接收单元接收到的所述第一验证信息的数量N超过第二预设阈 值，执行所述业务请求；
    所述发送单元，用于向所述M个从节点发送第一确认信息，所述第一确认信息包括所述N个从节点返回的第一验证信息中所包括的所述N个从节点的签名；所述第一确认信息用于使得所述M个从节点执行所述业务请求。
  14. 根据权利要求13所述的节点，其特征在于，节点集群包括所述节点和所述M个从节点，所述节点和所述M个从节点上共同运行多个实例，其中所述多个实例中的每个实例由所述节点和所述M个从节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；所述节点为运行所述多个实例中的目标实例的主节点，所述M个从节点为运行所述目标实例的从节点，所述节点还用于：
    与所述M个从节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，所述目标实例的吞吐量比所述主实例的吞吐量高。
  15. 根据权利要求13或14所述的节点，其特征在于，运行所述多个实例中任一实例的多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  16. 根据权利要求15所述的节点，其特征在于，所述多个实例中任意两个实例的备用主节点之间不重复。
  17. 根据权利要求15或16所述的节点，其特征在于，所述任一个实例的各个备用主节点之间存在不同的优先级；所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点，具体为：
    按照所述优先级，所述任一个实例的各个备用主节点中优先级最高的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  18. 根据权利要求14-17任一项所述的节点，其特征在于，所述多个实例中实例的数量L与所述节点集群中的节点数量K之间存在如下关系：
    Figure PCTCN2019081998-appb-100003
    K＝M+1，K为大于或等于3的整数。
  19. 一种节点，其特征在于，包括：
    接收单元，用于接收第一节点发送的业务请求；所述第一节点为运行一个实例的主节点，所述节点为运行所述一个实例的M个从节点之一，M为正整数；还用于接收所述第一节点发送的第一确认消息，所述第一确认消息包括N个从节点各自的签名，所述N个从节点各自的签名为所述第一节点接收到N个从节点所发送的N个第一验证消息中所包括的，所述第一确认消息表示所述第一节点接收到所述第一验证信息的数量N超过第二预设阈值，N为小于等于M的正整数；
    验证单元，用于对所述第一待校验信息进行验证以生成第一验证信息，所述第一验证信息包括生成所述第一验证信息的从节点的签名，所述第一验证信息表示生成所述第一验证信息的从节点对所述业务请求验证通过；
    发送单元，用于向所述第一节点发送所述第一验证信息；
    执行单元，用于在接收到所述第一节点发送的所述第一确认消息时，根据所述业务请 求执行所述业务请求。
  20. 根据权利要求19所述的节点，其特征在于，节点集群包括所述第一节点和M个所述节点，所述第一节点和M个所述节点上共同运行多个实例，其中所述多个实例中的每个实例由所述第一节点和M个所述节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；所述第一节点为运行所述多个实例中的目标实例的主节点，所述节点为运行所述目标实例的M个从节点之一，所述节点还用于：
    与所述第一节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，所述目标实例的吞吐量比所述主实例的吞吐量高。
  21. 根据权利要求19或20所述的节点，其特征在于，运行所述多个实例中任一实例的多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  22. 根据权利要求21所述的节点，其特征在于，所述多个实例中任意两个实例的备用主节点之间不重复。
  23. 根据权利要求21或22所述的节点，其特征在于，所述任一个实例的各个备用主节点之间存在不同的优先级；所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点，具体为：
    按照所述优先级，所述任一个实例的各个备用主节点中优先级最高的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。
  24. 根据权利要求20-23任一项所述的节点，其特征在于，所述多个实例中实例的数量L与所述节点集群中的节点数量K之间存在如下关系：
    Figure PCTCN2019081998-appb-100004
    K＝M+1，K为大于或等于3的整数。
  25. 一种集群系统，其特征在于，所述集群系统中包含第一节点和M个从节点，所述第一节点为运行一个实例的主节点，所述M个从节点为运行所述实例的从节点，M为正整数，所述第一节点用于：
    向所述M个从节点发送业务请求；
    接收N个从节点返回的第一验证信息，所述第一验证信息包括生成所述第一验证信息的从节点的签名，所述第一验证信息表示生成所述第一验证信息的从节点对所述业务请求验证通过，N为小于等于M的正整数；
    若接收到的所述第一验证信息的数量N超过第二预设阈值，执行所述业务请求；
    向所述M个从节点发送第一确认信息，所述第一确认信息包括所述N个从节点返回的第一验证信息中所包括的所述N个从节点的签名；所述第一确认信息用于使得所述M个从节点执行所述业务请求；
    所述M个从节点用于：
    接收所述第一节点发送的所述业务请求；
    对所述业务请求进行验证以生成所述第一验证信息；
    向所述第一节点发送所述第一验证信息；
    接收所述第一节点发送的所述第一确认消息，并根据所述业务请求执行所述业务请求。
  26. 根据权利要求25所述的集群系统，其特征在于，所述第一节点和所述M个从节点上共同运行多个实例，其中所述多个实例中的每个实例由所述第一节点和所述M个从节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；所述第一节点为运行所述多个实例中的目标实例的主节点，所述第二节点为运行所述目标实例的所述M个从节点之一，所述第一节点还用于与所述M个从节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，所述目标实例的吞吐量比所述主实例的吞吐量高。
  27. 一种节点，其特征在于，所述节点包括处理器和存储器，所述存储器用于存储程序指令，当所述处理器调用所述程序指令时，实现权利要求1-6任一项所述的方法。
  28. 一种节点，其特征在于，所述节点包括处理器和存储器，所述存储器用于存储程序指令，当所述处理器调用所述程序指令时，实现权利要求7-12任一项所述的方法。
  29. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在处理器上运行时，实现权利要求1-6任一项所述的方法。
  30. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在处理器上运行时，实现权利要求7-12任一项所述的方法。
PCT/CN2019/081998 2018-07-30 2019-04-10 一种共识流程恢复方法及相关节点 WO2020024615A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19845036.3A EP3675416B1 (en) 2018-07-30 2019-04-10 Consensus process recovery method and related nodes
US16/847,171 US11200123B2 (en) 2018-07-30 2020-04-13 Consensus process recovery method and related node

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810859769.7 2018-07-30
CN201810859769.7A CN110784331B (zh) 2018-07-30 2018-07-30 一种共识流程恢复方法及相关节点

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/847,171 Continuation US11200123B2 (en) 2018-07-30 2020-04-13 Consensus process recovery method and related node

Publications (1)

Publication Number Publication Date
WO2020024615A1 true WO2020024615A1 (zh) 2020-02-06

Family

ID=69231371

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/081998 WO2020024615A1 (zh) 2018-07-30 2019-04-10 一种共识流程恢复方法及相关节点

Country Status (4)

Country Link
US (1) US11200123B2 (zh)
EP (1) EP3675416B1 (zh)
CN (1) CN110784331B (zh)
WO (1) WO2020024615A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114024974A (zh) * 2021-10-28 2022-02-08 上海应用技术大学 用于化工厂易燃气体监测系统的pbft算法改进方法

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11496558B2 (en) * 2020-01-29 2022-11-08 Hewlett Packard Enterprise Development Lp Peer-to-peer blockchain fabric management mechanism
CN113079081B (zh) * 2020-09-25 2022-08-02 支付宝(杭州)信息技术有限公司 消息传输方法及装置
CN112398692B (zh) * 2020-11-16 2022-07-19 网易（杭州）网络有限公司 共识流程处理方法、装置和电子设备
CN112636929B (zh) * 2020-12-29 2023-01-17 北京百度网讯科技有限公司 群组业务实现方法、装置、设备和存储介质
US11343313B1 (en) * 2021-01-28 2022-05-24 International Business Machines Corporation Fault tolerant periodic leader rotation for blockchain
EP4420300A1 (en) * 2021-10-18 2024-08-28 Sophos Limited Network appliances for secure enterprise resources
US20240303109A1 (en) * 2023-03-07 2024-09-12 Paypal, Inc. Reducing Processing Bandwidth of Networked Services by Consolidating Service Tasks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106789095A (zh) * 2017-03-30 2017-05-31 腾讯科技（深圳）有限公司 分布式系统及消息处理方法
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping
CN107819749A (zh) * 2017-10-26 2018-03-20 平安科技（深圳）有限公司 基于以太坊的区块链系统和交易数据处理方法
CN108108967A (zh) * 2017-12-29 2018-06-01 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9621412B2 (en) * 2012-12-27 2017-04-11 Telecom Italia S.P.A. Method for guaranteeing service continuity in a telecommunication network and system thereof
CN106161495A (zh) * 2015-03-25 2016-11-23 中兴通讯股份有限公司 一种主节点选举方法、装置及存储系统
US9632892B1 (en) * 2015-03-30 2017-04-25 EMC IP Holding Company LLC NFS cluster failover
CN107579848B (zh) * 2017-08-30 2020-08-25 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
GB201715073D0 (en) * 2017-09-19 2017-11-01 Memoscale As Data security
CN108134706B (zh) * 2018-01-02 2020-08-18 中国工商银行股份有限公司 区块链多活高可用系统、计算机设备以及方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping
CN106789095A (zh) * 2017-03-30 2017-05-31 腾讯科技（深圳）有限公司 分布式系统及消息处理方法
CN107819749A (zh) * 2017-10-26 2018-03-20 平安科技（深圳）有限公司 基于以太坊的区块链系统和交易数据处理方法
CN108108967A (zh) * 2017-12-29 2018-06-01 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法

Non-Patent Citations (1)

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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114024974A (zh) * 2021-10-28 2022-02-08 上海应用技术大学 用于化工厂易燃气体监测系统的pbft算法改进方法
CN114024974B (zh) * 2021-10-28 2024-03-29 上海应用技术大学 用于化工厂易燃气体监测系统的pbft算法改进方法

Also Published As

Publication number Publication date
US20200241981A1 (en) 2020-07-30
CN110784331B (zh) 2022-05-13
EP3675416B1 (en) 2023-06-21
US11200123B2 (en) 2021-12-14
CN110784331A (zh) 2020-02-11
EP3675416A4 (en) 2021-08-25
EP3675416A1 (en) 2020-07-01

Similar Documents

Publication Publication Date Title
WO2020024615A1 (zh) 一种共识流程恢复方法及相关节点
WO2021109719A1 (zh) 事务处理方法、装置、设备及计算机存储介质
WO2020253596A1 (zh) 一种Redis集群的高可用方法及装置
US9641627B2 (en) Techniques for remapping sessions for a multi-threaded application
EP4083786A1 (en) Cloud operating system management method and apparatus, server, management system, and medium
CN110807064B (zh) Rac分布式数据库集群系统中的数据恢复装置
CN111614468B (zh) 一种区块链共识方法及系统
US20200042410A1 (en) Role designation in a high availability node
US8442958B2 (en) Server change management
CN111314125A (zh) 用于容错通信的系统和方法
WO2016058307A1 (zh) 资源的故障处理方法及装置
CN103019889A (zh) 分布式文件系统及其故障处理方法
CN104158707A (zh) 一种检测并处理集群脑裂的方法和装置
WO2020232859A1 (zh) 分布式存储系统、数据写入方法、装置和存储介质
CN102938705A (zh) 一种高可用多机备份路由表管理与切换方法
WO2017215430A1 (zh) 一种集群内的节点管理方法及节点设备
CN108063813A (zh) 一种集群环境下密码服务网络并行化的方法与系统
WO2021139174A1 (zh) 一种faas分布式计算方法和装置
CN106790563A (zh) 分布式存储系统和方法
Tsai et al. Lessons learned from developing permissioned blockchains
US20210218827A1 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
CN111813606A (zh) 一种双节点虚拟机容错的方法、系统、设备及介质
CN106407264A (zh) 一种高可用性和强一致性的数据库集群系统及其命令处理方法
KR20200118798A (ko) 전자 디바이스들, 시스템들 및 방법들
CN115755570A (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: 19845036

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019845036

Country of ref document: EP

Effective date: 20200327

NENP Non-entry into the national phase

Ref country code: DE