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

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

Info

Publication number
CN110784331A
CN110784331A CN201810859769.7A CN201810859769A CN110784331A CN 110784331 A CN110784331 A CN 110784331A CN 201810859769 A CN201810859769 A CN 201810859769A CN 110784331 A CN110784331 A CN 110784331A
Authority
CN
China
Prior art keywords
node
instance
nodes
service request
verification information
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN201810859769.7A
Other languages
English (en)
Other versions
CN110784331B (zh
Inventor
丁健
刘勋
曹朝
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201810859769.7A priority Critical patent/CN110784331B/zh
Priority to PCT/CN2019/081998 priority patent/WO2020024615A1/zh
Priority to EP19845036.3A priority patent/EP3675416B1/en
Publication of CN110784331A publication Critical patent/CN110784331A/zh
Priority to US16/847,171 priority patent/US11200123B2/en
Application granted granted Critical
Publication of CN110784331B publication Critical patent/CN110784331B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • 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
    • 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/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

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

一种共识流程恢复方法及相关节点
技术领域
本发明涉及大数据技术领域，尤其涉及一种共识流程恢复方法及相关节点。
背景技术
区块链是一种将数据区块以顺序相连的方式组合成的一种链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。现有执行区块链方案的节点集群在解决节点之间协商、决策如何生成新区块的问题时，使用实用拜占庭容错(practicalbyzantine fault tolerance，PBFT)算法进行共识，共识效率是区块链对外提供服务的核心能力。PBFT算法的核心理论是n>＝3f+1，其中，n是节点集群中的节点总数，f是允许出现故障的节点的最大数。即当出现拜占庭容错(如发送恶意错误信息)的节点不超过f个时，这节点集群中的没有出现拜占庭容错的其他节点最终都可以的得到正确的共识结果，也即是说，每个没有出现拜占庭容错的节点在收到2f+1条正确的消息后即可得出正确的共识结果。
该节点集群中包括一个主节点(primarynode)，除该主节点之外的节点为从节点(backup node)，主节点在共识过程中承担了更多的任务，例如，接收客户端(client)发送的数据处理请求，然后将该请求中的关键信息发送给节点集群中其他所有节点，以使节点集群中的节点对该数据进行共识。一旦该主节点出现故障，该节点集群中的节点就会重新选举出一个新的主节点，在选举的过程中通常采用基于竞争的选举方式，竞争过程中各个节点之间会进行大量的信息交互(因为节点集群中节点数量往往比较庞大)，这个过程会持续一定的时间；如果在此期间有数据需要共识则需要等到新的主节点产生之后才会执行。也即是说，共识流程可能会因为主节点故障而出现中断，共识流程中断之后如何快速恢复是本领域的技术人员需要解决的技术问题。
发明内容
本发明实施例公开了一种共识流程恢复方法及相关节点，能够解决一致性处理流程中的主节点故障后共识流程恢复速度较慢的问题。
第一方面，本申请实施例提供一种集群系统，所述集群系统中包含多个节点，所述多个节点共同运行多个实例，其中所述多个实例中的每个实例由所述多个节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；针对每个实例，所述多个节点中存在一个节点作为所述每个实例对应的主节点；所述多个实例对应的多个主节点分别为不同的节点。
在上述集群系统中，多个节点共同运行着多个实例，且其中各个实例对应的主节点各不相同，因此当其中一个实例的主节点出现问题并不意味着其他的实例的主节点也出现问题，因此避免了集群系统因为其中一个实例故障而导致无法正常运行的问题。
在第一方面的第一种可能的实现方式中：第一节点向每一个第二节点发送业务请求；所述第一节点为所述多个实例中一个实例对应的主节点，所述第二节点为所述一个实例对应的从节点；所述第一节点接收所述第二节点返回的第一验证信息，所述第一验证信息中包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；若所述第一节点接收到的所述第一验证信息的数量超过第二预设阈值，所述第一节点执行所述业务请求；所述第一节点向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所述第一节点接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
可以看出，在一致性处理过程中，各个第二节点之间不需要进行来回确认，只需通过第一节点发送的携带各个第二节点签名的第一确认信息，即可确定除自身以外的其他第二节点是否同意执行所述业务请求，由于省掉了各个第二节点之间的相互确认，因此大大降低了通信复杂度。
在第一方面的第一种可能的实现方式中：所述多个节点用于从所述一个或多个从实例中确定目标实例，所述目标实例的吞吐量比所述主实例的吞吐量高；所述多个节点用于在所述多个节点之间达成共识，以使得所述目标实例替换所述主实例成为新的主实例。也即是说，因此当这多个实例中的主实例因主节点故障而不能正常运行时，不需要该多个节点重新选举主节点，而是直接根据各实例吞吐量大小从一个已经存在的实例中确定目标实例，并将目标实例替换为新的主实例，提高了故障恢复效率。
第二方面，本申请实施例提供一种共识流程恢复方法，其特征在于，应用于节点集群，所述节点集群包含多个节点，所述多个节点共同运行多个实例，其中所述多个实例中的每个实例由所述多个节点共同运行，并且所述多个实例中存在一个主实例和一个或多个从实例；针对每个实例，所述多个节点中存在一个节点作为该实例的主节点，其余的节点作为该实例的从节点；所述多个实例对应的多个主节点分别为不同的节点，所述方法包括：所述多个节点中的一个或多个节点从所述一个或多个从实例中确定目标实例，所述目标实例的吞吐量比所述主实例的吞吐量高；第一节点与各个第二节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，所述第二节点为运行所述目标实例的从节点，所述第一节点为运行所述目标实例的主节点。
可以看出，节点集群共同运行了一个主实例和一个或多个从实例，当主实例吞吐量较小而无法正常工作时，该节点集群直接从该一个或多个从实例中选择一个新的主实例，而不是该节点集群重新进行大量的信息交互来建立一个新的主实例。因此当原先的主实例无法正常工作时，新的主实例能够立即接替原先的主实例执行共识流程，使得共识流程中断之后能够快速恢复。
在第二方面的第一种可能的实现方式中，所述方法还包括：所述多个节点中的一个或多个节点检测所述多个实例中每个实例的吞吐量；所述第一节点根据所述每个实例的吞吐量从所述一个或多个从实例中确定所述目标实例。
在第二方面的第二种可能的实现方式中，所述每个实例均用于对业务请求进行处理，所述方法还包括：所述第一节点向每一个所述第二节点发送所述业务请求；所述第一节点接收所述第二节点返回的第一验证信息，所述第一验证信息中包括所述第二节点的签名，所述第一验证信息表示所述第二节点对所述业务请求验证通过；若所述第一节点接收到的所述第一验证信息的数量超过第二预设阈值，所述第一节点执行所述业务请求；所述第一节点向每一个所述第二节点发送第一确认信息，所述第一确认信息包括所述业务请求和所述第一节点接收到的所有的所述第一验证信息中的所述第二节点的签名；所述第一确认信息用于使得所述第二节点执行所述业务请求。
可以看出，在一致性处理过程中，目标实例的第二节点不需要与目标实例的其他从节点进行来回确认，目标实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第一确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
在第二方面的第三种可能的实现方式中，所述第一节点与各个第二节点达成共识，以将所述目标实例替换所述主实例成为新的主实例，包括：所述第一节点向每一个所述第二节点发送替换请求，所述替换请求用于请求将所述目标实例替换所述主实例成为新的主实例；所述第一节点接收所述第二节点返回的第二验证信息，所述第二验证信息中包括所述第二节点的签名，所述第二验证信息表示所述第二节点对所述替换请求验证通过；若所述第一节点接收到的所述第二验证信息的数量超过第三预设阈值，所述第一节点将所述目标实例替换所述主实例成为新的主实例；所述第一节点向每一个所述第二节点发送第二确认信息，所述第二确认信息包括所述第一节点接收到的所有的所述第二验证信息中的所述第二节点的签名；所述第二确认信息用于指示每一个所述第二节点执行所述替换请求，将所述目标实例替换所述主实例成为新的主实例。
可以看出，在切换主实例的过程中，目标实例的第二节点不需要与目标实例的其他从节点进行来回确认，目标实例的各个从节点只需通过第一节点发送的携带各个从节点签名的第二确认信息，即可确定除自身以外的从节点是否同意执行所述业务请求，由于省掉了各个从节点之间的相互确认，大大降低了通信复杂度。
在第二方面的第四种可能的实现方式中，所述多个实例中任一实例的所述多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。可以理解的是，为每个主节点配备备用主节点，能够在进行主节点更换时更快得从配备的备用主节点中选择出新的主节点，而不是盲目的从节点集群这样要大的范围内去选举新的主节点，不仅提高了主节点的选举效率，还减少了节点之间的通信。
在第二方面的第五种可能的实现方式中，所述多个实例中任意两个实例的备用主节点之间不重复。能够避免更换新的主节点时出现冲突。
在第二方面的第六种可能的实现方式中，所述多个实例中任一实例的所述多个从节点中的部分从节点为所述任一实例的备用主节点，所述任一个实例的各个备用主节点之间存在优先级顺序；所述任一个实例的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点，具体为：
按照所述优先级顺序，所述任一个实例的各个备用主节点中优先级最高的备用主节点用于代替所述任一个实例的主节点成为所述任一个实例的新的主节点。可以理解的是，通过优先级可以进一步限定选举新的主节点时的秩序，避免盲目选举而导致通信压力较大的问题。
在第二方面的第七种可能的实现方式中，所述多个实例中实例的数量L与所述节点集群中的节点数量N之间存在如下关系：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 BDA0001748094030000081
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 BDA0001748094030000091
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 BDA0001748094030000101
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 BDA0001748094030000112
在一种可选的方案中，所述多个实例中实例的数量L与所述节点集群中的节点数量N之间存在如下关系：
Figure BDA0001748094030000111
N≥3。
这样设置的考虑如下：拜占庭容错机制在设计之初就有一个前提，即所有参与共识的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 BDA0001748094030000121
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 programmableread 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 programmableread 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 (19)

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

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201810859769.7A CN110784331B (zh) 2018-07-30 2018-07-30 一种共识流程恢复方法及相关节点
PCT/CN2019/081998 WO2020024615A1 (zh) 2018-07-30 2019-04-10 一种共识流程恢复方法及相关节点
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 (1)

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

Publications (2)

Publication Number Publication Date
CN110784331A true CN110784331A (zh) 2020-02-11
CN110784331B CN110784331B (zh) 2022-05-13

Family

ID=69231371

Family Applications (1)

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

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
CN112398692A (zh) * 2020-11-16 2021-02-23 网易（杭州）网络有限公司 共识流程处理方法、装置和电子设备

Families Citing this family (4)

* 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
CN111934990B (zh) * 2020-09-25 2021-02-09 支付宝(杭州)信息技术有限公司 消息传输方法及装置
US11343313B1 (en) * 2021-01-28 2022-05-24 International Business Machines Corporation Fault tolerant periodic leader rotation for blockchain
CN114024974B (zh) * 2021-10-28 2024-03-29 上海应用技术大学 用于化工厂易燃气体监测系统的pbft算法改进方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106161495A (zh) * 2015-03-25 2016-11-23 中兴通讯股份有限公司 一种主节点选举方法、装置及存储系统
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
CN107579848A (zh) * 2017-08-30 2018-01-12 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
CN108134706A (zh) * 2018-01-02 2018-06-08 中国工商银行股份有限公司 区块链多活高可用系统、计算机设备以及方法

Family Cites Families (5)

* 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
US9632892B1 (en) * 2015-03-30 2017-04-25 EMC IP Holding Company LLC NFS cluster failover
GB201715073D0 (en) * 2017-09-19 2017-11-01 Memoscale As Data security
CN107819749A (zh) * 2017-10-26 2018-03-20 平安科技（深圳）有限公司 基于以太坊的区块链系统和交易数据处理方法
CN108108967B (zh) * 2017-12-29 2020-10-16 山大地纬软件股份有限公司 面向复杂数字资产的多阶段pbft共识系统及方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106161495A (zh) * 2015-03-25 2016-11-23 中兴通讯股份有限公司 一种主节点选举方法、装置及存储系统
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 腾讯科技（深圳）有限公司 分布式系统及消息处理方法
CN107579848A (zh) * 2017-08-30 2018-01-12 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
CN108134706A (zh) * 2018-01-02 2018-06-08 中国工商银行股份有限公司 区块链多活高可用系统、计算机设备以及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
X P. AUBLIN等: "RBFT: Redundant Byzantine Fault Tolerance", 《IEEE，2013 IEEE 33RD INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS, PHILADELPHIA, PA, USA, 2013》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112398692A (zh) * 2020-11-16 2021-02-23 网易（杭州）网络有限公司 共识流程处理方法、装置和电子设备
CN112398692B (zh) * 2020-11-16 2022-07-19 网易（杭州）网络有限公司 共识流程处理方法、装置和电子设备

Also Published As

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

Similar Documents

Publication Publication Date Title
CN110784331B (zh) 一种共识流程恢复方法及相关节点
US10721326B2 (en) Method, apparatus, and electronic device for processing consensus requests in a blockchain consensus network
US20180285217A1 (en) Failover response using a known good state from a distributed ledger
US20180308091A1 (en) Fairness preserving byzantine agreements
CN102346460B (zh) 一种基于事务的服务控制系统及其控制方法
US7249280B2 (en) Cheap paxos
CN110431533B (zh) 故障恢复的方法、设备和系统
CN106911648B (zh) 一种环境隔离方法及设备
CN110807064B (zh) Rac分布式数据库集群系统中的数据恢复装置
CN110224871A (zh) 一种Redis集群的高可用方法及装置
CN111314125A (zh) 用于容错通信的系统和方法
CN113127270B (zh) 一种基于云计算的3取2安全计算机平台
JP6431197B2 (ja) スナップショット処理方法および関係付けられたデバイス
CN110413687B (zh) 基于节点互证校验的分布式事务故障处理方法及相关设备
CN111240806B (zh) 一种分布式容器镜像构建调度方法
CN103678031A (zh) 二乘二取二冗余系统及方法
CN112948063A (zh) 云平台的创建方法、装置、云平台以及云平台实现系统
CN113489691A (zh) 网络访问方法、装置、计算机可读介质及电子设备
CN114554593A (zh) 数据处理方法及装置
CN113901047A (zh) 一种基于内存数据库的简便集群主从选举方法
KR20210097560A (ko) 블록체인 트랜잭션 처리 방법
CN115755570A (zh) 多冗余度异构调度裁决器的调度裁决方法及装置
CN116232893A (zh) 分布式系统的共识方法、装置、电子设备及存储介质
CN113630445B (zh) 一种基于区块链网络的数据存储方法及装置
CN112953897B (zh) 一种基于云计算设备的列控系统边缘安全节点的实现方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant