CN112068978B - View-change二次启动定时器的定时期限延长方法及装置 - Google Patents

View-change二次启动定时器的定时期限延长方法及装置 Download PDF

Info

Publication number
CN112068978B
CN112068978B CN202010879413.7A CN202010879413A CN112068978B CN 112068978 B CN112068978 B CN 112068978B CN 202010879413 A CN202010879413 A CN 202010879413A CN 112068978 B CN112068978 B CN 112068978B
Authority
CN
China
Prior art keywords
view
change
consensus
consensus node
start timer
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.)
Active
Application number
CN202010879413.7A
Other languages
English (en)
Other versions
CN112068978A (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.)
Hengbao Co Ltd
Original Assignee
Hengbao 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 Hengbao Co Ltd filed Critical Hengbao Co Ltd
Priority to CN202010879413.7A priority Critical patent/CN112068978B/zh
Publication of CN112068978A publication Critical patent/CN112068978A/zh
Application granted granted Critical
Publication of CN112068978B publication Critical patent/CN112068978B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • 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/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1453—Management of the data involved in backup or backup restore using de-duplication of the data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)

Abstract

本发明提供一种实用型拜占庭容错VIEW‑CHANGE二次启动定时器的定时期限延长方法，其特征在于，共识节点接收其他共识节点发送的VIEW‑CHANGE消息；提取所述其他共识节点发送的VIEW‑CHANGE消息中的PREPARED数据中的共识节点信息；对提取的所述PREPARED数据中的共识节点信息持续进行去重并统计去重后的共识节点信息数量；根据所述统计去重后的共识节点信息数量判断是否将VIEW‑CHANGE二次启动定时器的定时期限进行延长。本发明根据在VIEW‑CHANGE过程中的参数监控、参数处理，调整VIEW‑CHANGE二次启动定时器的定时期限，使得该定时期限设置更适于当前共识节点的通信环境状态以及处理数据水平，不仅能够减少VIEW‑CHANGE过程的触发频次，提高VIEW‑CHANGE过程的处理效率，而且一定程度上保证了共识系统的存活性。

Description

VIEW-CHANGE二次启动定时器的定时期限延长方法及装置
技术领域
本发明涉及通信技术领域或者计算机技术领域，尤其是一种实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法。
背景技术
在实用型拜占庭容错PBFT(Practical Byzantine Fault Tolerance)的共识过程中， VIEW-CHANGE事件是常见的系统操作，对于保证共识系统存活性(Liveness)，持续不断地进行共识操作，起到了决定性的作用。在共识过程中，如果共识节点出现错误，特别是主共识节点出现错误，或者拜占庭共识节点故意作恶，故意发送错误消息或者不发送消息，或者网络出现故障，导致消息传输不能及时准确地到达目的共识节点，此时，相应的共识节点需要发送VIEW-CHANGE消息，调整当年共识系统的主副共识节点角色和作用，重新开始正常的共识过程。
目前在实用型拜占庭容错共识过程中，完整的共识过程需要经过三个阶段，即PRE-PREPARE阶段、PREPARE阶段、以及COMMIT阶段，主共识节点或者每个副本共识节点在接收请求后，都会启动VIEW-CHANGE定时器，定时器预先设定一个定时期限，如果在预先设定的时间期限内，主共识节点或者每个副本共识节点不能完成COMMIT阶段，那么该共识节点开始向其他共识节点发送VIEW-CHANGE消息，此时启动VIEW-CHANGE 流程。因此，VIEW-CHANGE过程是在共识系统不能完成正常共识流程的情况下，设置的一种防护措施，以接收请求消息为起点，以COMMIT正常完成为结束，如果期间的各阶段工作正常完成，那么视为一个完整的共识过程，如果不能如期完成一个完整的共识流程，整个共识系统将被引导进入VIEW-CHANGE阶段。
然而，VIEW-CHANGE阶段也并非能够顺利地完成，这是由于共识系统并不是全时段正确运行的系统，与共识过程类似，在VIEW-CHANGE阶段，共识节点同样会出现错误，主共识节点出现错误的可能性极大，部分拜占庭共识节点故意作恶，故意发送错误的 VIEW-CHANGE消息或者在主共识节点未出现错误时发送VIEW-CHANGE消息，或者在 VIEW-CHANGE阶段不发送消息，或者网络出现故障，导致消息传输不能及时准确地到达目的共识节点，以上情况都会导致VIEW-CHANGE不能正常完成，破坏了整个共识系统的存活性。
基于以上情况，在遇到VIEW-CHANGE不能正常完成的时候，设置了一个二次启动的机制，也即重新启动VIEW-CHANGE过程，为了达到事件触发启动的目的，共识系统中的每个共识节点都内设了一个二次启动的定时器。当某个共识节点开始VIEW-CHANGE过程的时候，VIEW-CHANGE二次启动定时器同时开始工作，当该二次启动定时器的定时期限届满时，如果本次VIEW-CHANGE过程没有顺利完成，则该共识节点重新发送 VIEW-CHANGE消息，该消息按照主共识节点的更换原则，重新更换新的主共识节点，开始新一轮的VIEW-CHANGE过程。以上VIEW-CHANGE二次启动定时器可以多次重置，这样，当某一个VIEW-CHANG不能正常完成的时候，可以及时地进入下一个 VIEW-CHANGE过程，通过以上方式，整个共识系统能够避免无限期地停滞在某一个 VIEW-CHANGE过程内，使得整个共识系统的存活性保持正常。
在VIEW-CHANGE的过程中，经常会存在以下情况，即：各个共识节点的处理进度差距过大，而各个共识节点之间的通信能力和状况相对正常。各个共识节点的处理能力往往并不完全一致或者接近，各个共识节点承担的业务负担也不相同，在请求消息的数量比较大的情况下，各个共识节点承担的业务负担会有巨大的差距，而且，除了请求消息队列在各个共识节点中排队执行之外，各个共识节点还要完成VIEW-CHANGE消息的排队执行、 VIEW-CHANGE验证消息的排队执行、CHECK-POINT消息的排队执行、CHECK-POINT 验证消息的排队执行，以及各个数据结构存储、封包、处理、转发，以及各个共识节点之间的通信流程，都可能造成各个共识节点处理进度的不一致。
在这种情况下，由于实用型拜占庭容错的共识过程共有3f+1个共识节点，其中保证拜占庭节点的数量要少于等于f个，因此，如果网络状态保持正常通信，各个共识节点之间接收、发送消息的过程没有出现异常，那么在绝大多数情况下，各个共识节点都能够顺利向 2f个其他共识节点发送消息、或者顺利从2f个其他共识节点接收消息，从而，在各个共识节点经过一段时间的内部消息排队处理之后，整个共识过程依然能够顺利完成。
VIEW-CHANGE二次启动定时器所监控的时间期限主要是各个共识节点内部处理消息以及发送接收消息的时间，如果当发送接收消息的网络传输环境处于正常状态的时候，那么该VIEW-CHANGE二次启动定时器实际上所监控的时间期限，仅仅是各个共识节点内部处理消息的时间。在这种情况下，如果延长VIEW-CHANGE二次启动定时器的定时期限，尽量等待各个共识节点在内部处理完消息队列，通过当前正常的网络环境发送和接收消息。
然而，目前VIEW-CHANGE二次启动定时器的定时期限相对固定，虽然采用该定时器能够在一定程度上避免无限期地停滞在某一个VIEW-CHANGE过程内，但是，这种方式也会产生一些负面的影响，也即固定的定时期限只能机械地触发重新开始VIEW-CHANGE事件，这样造成频繁地重启多轮的VIEW-CHANGE过程，导致在上一轮次的VIEW-CHANGE 可能正处于正常处理流程的前提下，定时器按时中断了该轮次的可能正常的 VIEW-CHANGE过程，从而浪费了宝贵的共识节点处理时间。在极端情况下，如果 VIEW-CHANGE二次启动定时器的定时期限设置过短，导致过于频繁地中断 VIEW-CHANGE过程，从而极少能够正常完成一次完整的VIEW-CHANGE过程，使得整个共识系统的存活性难以正常保持，共识过程的效率也相对低下。
发明内容
为了解决背景技术中描述的技术问题，本发明实施例提供了一种实用型拜占庭容错 VIEW-CHANGE二次启动定时器的定时期限延长方法。根据在VIEW-CHANGE过程中的参数监控、参数处理，调整VIEW-CHANGE二次启动定时器的定时期限，使得该定时期限设置更适于当前共识节点的通信环境状态以及处理数据水平，不仅能够减少VIEW-CHANGE 过程的触发频次，提高VIEW-CHANGE过程的处理效率，而且一定程度上保证了共识系统的存活性。
本申请实施例提供了一种实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法：
共识节点接收其他共识节点发送的VIEW-CHANGE消息；
提取所述其他共识节点发送的VIEW-CHANGE消息中的PREPARED数据的共识节点信息；
将所述提取的PREPARED数据中的共识节点信息存入备份表格，对所述存入备份表格的共识节点信息进行持续去除重复的操作，形成没有重复共识节点信息的列表；
当列表中的共识节点信息数量达到满额的时候，将VIEW-CHANGE二次启动定时器的定时期限进行延长。
进一步地，对所述存入备份表格中的共识节点信息进行去除重复操作为在存入所述备份表格之前进行去除重复操作。
进一步地，对所述存入备份表格中的共识节点信息进行去除重复操作为在存入所述备份表格之后对备份表格中的共识节点信息进行去除重复操作。
进一步地，所述方法还包括对所述备份表格内的共识节点信息数量进行统计，当所述备份表格内的共识节点信息数量累积到满额的平方时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
进一步地，所述方法还包括对所述备份表格内的共识节点信息数量进行统计，当任一共识节点信息数量在所述备份表格中出现频次大于或等于满额时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
进一步地，所述方法还包括如果副本共识节点在未延长的VIEW-CHANGE二次启动定时器的定时期限内，接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器，如果 VIEW-CHANGE二次启动定时器的定时期限被延长，则如果副本共识节点在延长的定时期限内接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器。
进一步地，所述方法还包括如果下一个主共识节点在未延长的VIEW-CHANGE二次启动定时器定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则发送 NEW-VIEW，进入新的VIEW；如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果下一个主共识节点在延长的定时期限内接收到超过共识节点总数量2/3个 VIEW-CHANGE消息，则发送NEW-VIEW，进入新的VIEW。
本申请实施例还提供一种实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长装置，其特征在于，共识节点包括接收模块、提取模块、去重模块、延长定时期限模块；接收模块：接收其他共识节点发送的VIEW-CHANGE消息；提取模块：提取所述其他共识节点发送的VIEW-CHANGE消息中的PREPARED数据中的共识节点信息；去重模块：将所述提取的PREPARED数据中的共识节点信息存入备份表格，对所述存入备份表格的共识节点信息进行持续去除重复的操作，形成没有重复共识节点信息的列表；延长定时期限模块：当列表中的共识节点信息数量达到满额的时候，将VIEW-CHANGE二次启动定时器的定时期限进行延长。
进一步地，对所述存入备份表格中的共识节点信息持续进行去除重复操作为在存入所述备份表格之前进行去除重复操作。
进一步地，所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长装置，对所述存入备份表格中的共识节点信息进行去除重复操作为在存入备份表格之后对备份表格中的共识节点信息进行去除重复操作。
进一步地，对备份表格内的节点数量进行统计，当备份表格内的节点数量累积到满额的平方时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
进一步地，对备份表格内的节点数量进行统计，当任一共识节点在备份表格中出现频次大于或等于满额时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
进一步地，所述装置还包括VIEW-CHANGE二次启动定时器控制模块：当共识节点为副本共识节点时，如果在未延长的VIEW-CHANGE二次启动定时器的定时期限内，接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器，如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果在延长的定时期限内接收到NEW-VEIW时，停止 VIEW-CHANGE二次启动定时器。
进一步地，所述装置还包括VIEW-CHANGE二次启动定时器控制模块：当共识节点为下一个主共识节点时，如果在未延长的VIEW-CHANGE二次启动定时器定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则发送NEW-VIEW，进入新的VIEW；如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果在延长的定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则发送NEW-VIEW，进入新的VIEW。
根据以上技术方案，本发明采用了VIEW-CHANGE二次启动定时器的定时期限延长方法，在VIEW-CHANGE过程中，对于VIEW-CHANGE二次启动定时器的定时期限进行调整，调整的依据为在共识节点发送的VIEW-CHANGE消息中；提取PREPARED数据，以及 PREPARED数据中的共识节点信息；并对共识节点信息进行一定的操作，归纳出满足条件的共识节点信息的列表；根据列表中数据属性，对VIEW-CHANGE二次启动定时器的定时期限进行调整，根据以上技术方案，可以监控当前网络环境，及时掌握共识系统中的通信状态，合理设置VIEW-CHANGE事件的触发时机。
附图说明
附图1显示了在现有技术中实用型拜占庭容错的流程。
附图2显示了在现有技术中视图发生转换的基本流程。
附图3显示了本发明示例性的共识节点布局的示意图。
附图4显示了本发明示例性的实施例1的步骤执行流程的示意图。
附图5显示了本发明示例性的各实施例中的去除重复共识节点的示意图。
附图6显示了本发明示例性的实施例2的步骤执行流程的示意图。
附图7显示了本发明示例性的实施例3的结构图。
具体实施方式
本申请实施例提供了一种实用拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，根据在VIEW-CHANGE过程中的参数监控、参数处理，调整VIEW-CHANGE 二次启动定时器的定时期限，使得该定时期限设置更适于当前共识节点的通信环境状态以及处理数据水平，不仅能够减少VIEW-CHANGE过程的触发频次，提高VIEW-CHANGE过程的处理效率，而且一定程度上保证了共识系统的存活性。
本发明的摘要、说明书、权利要求书、附图中的术语等(如果存在)是用于区别类似的对象，而不必限定于各技术特征描述特定的顺序或先后次序。对于这样使用的技术特征，本领域技术人员应该能够理解在适当情况下可以互换，从而使得这里描述的实施例能够在本发明之外的图示或描述中按照一定顺序实施。此外，术语“包括”以及他们的任何变形，意图在于覆盖其他的实施例，而不必限于清楚地列出的那些步骤，而是可包括没有清楚地列出的或对于这些过程、方法、及其它步骤。
现有技术中的实用型拜占庭容错的共识流程主要分为三个阶段，如附图1所示，分别是PRE-PREPARE，PREPARE，以及COMMIT三个阶段，在三个阶段之前还包括请求接收、在三个阶段之后还包括执行回复。实用型拜占庭容错的共识系统主要包含了以下基本节点，包括客户端、主共识节点、副本共识节点，其中共识节点的数量至少为3f+1个，其中保证拜占庭节点的数量要少于等于f个。主共识节点和副本共识节点即为需要执行共识流程的共识节点，对于请求和消息进行复制操作；客户端，共识过程的发起方，向主共识节点发起请求，请求中包含了需要共识的交易信息，该节点有时在区块链中可以跟主共识节点是同一个节点；主共识节点，启动共识过程，从客户端收到请求后生成新区块并向各个共识节点广播；共识节点验证区块的过程，实际上是对主共识节点发送的请求进行验证，在收到请求后进行验证，然后向包括主共识节点在内的其他共识节点广播验证结果，执行共识过程。
在执行共识过程中，主共识节点和副本共识节点的组合方式形成一个VIEW，在VIEW 上对区块完成共识流程；每一次主共识节点或者共识节点的变更都会启动VIEW-CHANGE，一般通过广播的方式进行，也可以通过共识操作完成，例如当包括主共识节点在内的共识节点出现宕机、断线等问题，则会出现一个新的VIEW，新的VIEW会选出一个新的主共识节点。
附图2是现有技术中VIEW-CHANGE的流程，主要分为三个阶段，第一阶段，各副本共识节点发现主共识节点出现宕机或断线，向共识系统中其他副本共识节点广播发送 VIEW-CHANGE消息，确定下一个VIEW以及新的主共识节点，第二阶段，各副本共识节点接收其他副本共识节点广播发送的VIEW-CHANGE消息，在接收到一定数量的 VIEW-CHANGE消息之后，此时共识系统对下一轮VIEW和新的主共识节点形成了共识，各副本共识节点向新的主共识节点发送ACK消息，表示同意在新VIEW中由新的主共识节点行使权力；第三阶段，新的主共识节点在接收到一定数量的ACK消息后，向各副本共识节点广播NEW-VIEW消息，并开始重新发送PRE-PREPARE消息。
附图3显示了本发明的共识节点布局示例，301是外围设备，可以为终端、电脑、智能设备、机器通信设备等，302为客户端，同时也可以为主共识节点，303为主共识节点或者共识节点(副本共识节点)，304-306为共识节点(副本共识节点)。
实施例一
以下步骤作为示例，详解实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法的实施例一。如附图4所示，在本实施例中，各共识节点均设置了一个 VIEW-CHANGE二次启动定时器，该定时器可以是软件实现，也可以采用硬件时钟方式实现，定时器预先设置一个定时期限，该定时期限可以根据经验值进行设置，也可以在共识系统启动的时候，与VIEW-CHANGE首次启动所使用的定时器的定时期限相等，即从接收请求至COMMIT完成之间的定时期限。
步骤S401：各个共识节点304-306接收其他共识节点发送的VIEW-CHANGE消息，其中既包括有主共识节点，又有副本共识节点。
在本步骤中，VIEW-CHANGE已经启动，最常见的VIEW-CHANGE启动原因可以是COMMIT过程没有顺利完成。此外，这里的VIEW-CHANGE启动原因还可以是接收到2f+1 个不同共识节点VIEW-CHANGE。各个共识节点304-306在接收完VIEW-CHANGE消息后，将其存储在共识节点内部。
步骤S402：提取所述其他共识节点发送的VIEW-CHANGE消息中的PREPARED数据，进一步提取所述PREPARED数据中的共识节点信息。
接收的VIEW-CHANGE消息中，包含了发送VIEW-CHANGE消息的共识节点，所处理的处于PREPARED状态的请求，其中不包含发送VIEW-CHANGE消息的共识节点中已经进入COMMIT状态的请求，也即该发送VIEW-CHANGE消息的共识节点对于某个请求已经收到了2f+1(含该发送VIEW-CHANGE消息的共识节点本身)的COMMIT消息，达到了COMMIT-local状态。这些处于PREPARED的请求被打包在P集合内，并且这些处于 PREPARED的请求包含了发送PREPARE消息的共识节点信息。进一步地，提取这些 PREPARED消息中的共识节点信息。
步骤S403：将所述提取的PREPARED数据中的共识节点信息存入预先创建的备份表格中，对备份表格中的共识节点信息持续进行去除重复的操作，形成没有重复共识节点信息的列表。
参见附图5，当接收到每个VIEW-CHANGE消息时，提取该VIEW-CHANGE消息中的PREPARED消息所对应的共识节点信息，并且存入一张预先设置的列表中。存入之后对其中的共识节点信息进行去除重复操作，使得列表中的每一个共识节点信息都是唯一的。
步骤S404：当列表中的节点信息数量达到满额的时候，将VIEW-CHANGE二次启动定时器的定时期限进行延长。
满额的标准是达到3f个没有重复的共识节点信息，此时由于收集完毕了所有的共识节点信息，显示该共识节点能够直接或间接地获取所有共识节点信息，因此，整个共识系统的通信环境应该是良好的，当前需要等待的是，尚未收到VIEW-CHANGE消息的共识节点正在处理的共识过程或者消息队列，此时，为了有充足的时间等待发送VIEW-CHANGE消息的共识节点处理完毕，将VIEW-CHANGE二次启动定时器的定时期限进行延长，可以成倍延长，或者可以按照阶梯方式递进延长。
步骤S405：停止VIEW-CHANGE二次启动定时器。
本步骤主要用于各个共识节点停止VIEW-CHANGE二次启动定时器，在以下情形满足的时候，执行停止定时器的操作。
一是对于各个副本共识节点，当副本共识节点接收到NEW-VIEW消息时，此时VIEW-CHANGE过程已经完成，新的主共识节点开始接收新的请求，以及将尚处于 PRE-PREPARE阶段以及PREPARED阶段的消息重新开始PRE-PREPARE过程，即，如果副本共识节点在未延长的VIEW-CHANGE二次启动定时器的定时期限内，接收到 NEW-VEIW时，停止VIEW-CHANGE二次启动定时器，如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果副本共识节点在延长的定时期限内接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器。
二是对于下一轮次的新的主共识节点，如果下一个主共识节点在未延长的 VIEW-CHANGE二次启动定时器定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则表明VIEW-CHANGE准备工作已经全部完成，新的主共识节点将发送NEW-VIEW，进入新的VIEW，开始作为新的主共识节点主持整个共识系统的共识过程；类似地，如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果下一个主共识节点在延长的定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则表明VIEW-CHANGE准备工作已经全部完成，新的主共识节点将发送NEW-VIEW，进入新的 VIEW。
实施例二
以下步骤作为示例，详解实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法的实施例二。实施例二与实施例一在主要执行流程上基本保持一致，如附图6所示，进一步地增加了一个备份表格，主要用于更加合理地控制VIEW-CHANGE二次启动定时器。
在本实施例中，各共识节点同样均设置了一个VIEW-CHANGE二次启动定时器，该定时器可以是软件实现，也可以采用硬件时钟方式实现，定时器预先设置一个定时期限，该定时期限可以根据经验值进行设置，也可以在共识系统启动的时候，与VIEW-CHANGE首次启动所使用的定时器的定时期限相等，即从接收请求至COMMIT完成之间的定时期限。
步骤601：各个共识节点304-306接收其他共识节点发送的VIEW-CHANGE消息，其中既包括有主共识节点，又有副本共识节点。
在本步骤中，VIEW-CHANGE已经启动，最常见的VIEW-CHANGE启动原因可以是COMMIT过程没有顺利完成。此外，这里的VIEW-CHANGE启动原因还可以是接收到f+1 个不同共识节点VIEW-CHANGE。各个共识节点304-306在接收完VIEW-CHANGE消息后，将其存储在共识节点内部。
步骤S602：提取所述其他共识节点发送的VIEW-CHANGE消息中的PREPARED数据，进一步提取所述PREPARED数据中的共识节点信息。
接收的VIEW-CHANGE消息中，包含了发送VIEW-CHANGE消息的共识节点，所处理的处于PREPARED状态的请求，其中不包含发送VIEW-CHANGE消息的共识节点中已经进入COMMIT状态的请求，也即该发送VIEW-CHANGE消息的共识节点对于某个请求已经收到了2f+1(含该发送VIEW-CHANGE消息的共识节点本身)的COMMIT消息，达到了COMMIT-local状态。这些处于PREPARED的请求被打包在P集合内，并且这些处于 PREPARED的请求包含了发送PREPARE消息的共识节点信息。进一步地，提取这些 PREPARED消息中的共识节点信息。
步骤S603：将所述PREPARED数据中的共识节点信息持续进行去除重复的操作，将去重的共识节点信息存入预先创建的备份表格中，形成没有重复共识节点信息的列表。
参见附图6，当接收到每个VIEW-CHANGE消息时，提取该VIEW-CHANGE消息中的PREPARED消息所对应的共识节点信息，将所述PREPARED数据中的共识节点信息持续进行去除重复的操作，将去重的共识节点信息存入预先创建的备份表格中，形成没有重复共识节点信息的列表。与实施例一不同之处在于，实施例一是在存入每个VIEW-CHANGE消息所包含的多个PREPARED消息所对应的共识节点信息之后直接存入备份表格中，对备份表格中的共识节点信息不进行去除重复操作，这种方式实时性强，能够快速调整 VIEW-CHANGE二次启动定时器。然而，这种方式也会更加占用资源，可以采用以下替代方式，即在收到多个VIEW-CHANGE消息之后，直接进行去除重复操作，这样可以节省资源，例如可以设定为在接收到Floor(f/3)个VIEW-CHANGE消息之后进行去除重复操作， Floor()函数为向下取整函数。
此外，在实际共识过程中，经常会出现某一个共识节点的网络环境非常好，而其他某一个共识节点的网络环境非常差，此时，两者之间的网络环境差距会导致网络环境非常好的共识节点进度受到较大程度的影响，而实用型拜占庭容错可以对f个拜占庭节点进行容错，因此，在这种情况下，应当尽量避免网络环境差的共识节点延误了网络环境好的共识节点的进度，甚至可能延误了整个共识系统的进度，因此，需要采取相应的措施来改善这种情况。
在所述提取PREPARED数据中的共识节点信息前创建备份表格，并将提取的节点信息存入该备份表格，对所述备份表格内的节点信息不进行去除重复的操作。对备份表格内的节点数量进行统计，当备份表格内的节点数量累积到满额的平方时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE 流程。或者对备份表格内的节点数量进行统计，当任一共识节点在备份表格中出现频次大于或等于满额时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
步骤S604：当列表中的节点信息数量达到满额的时候，将VIEW-CHANGE二次启动定时器的定时期限进行延长。
满额的标准是达到3f个没有重复的共识节点信息，此时由于收集完毕了所有的共识节点信息，显示该共识节点能够直接或间接地获取所有共识节点信息，因此，整个共识系统的通信环境应该是良好的，当前需要等待的是，尚未收到VIEW-CHANGE消息的共识节点正在处理的共识过程或者消息队列，此时，为了有充足的时间等待发送VIEW-CHANGE消息的共识节点处理完毕，将VIEW-CHANGE二次启动定时器的定时期限进行延长，可以成倍延长，或者可以按照阶梯方式递进延长。
步骤S605：停止VIEW-CHANGE二次启动定时器。
本步骤主要用于各个共识节点停止VIEW-CHANGE二次启动定时器，在以下情形满足的时候，执行停止定时器的操作。
一是对于各个副本共识节点，当副本共识节点接收到NEW-VIEW消息时，此时VIEW-CHANGE过程已经完成，新的主共识节点开始接收新的请求，以及将尚处于 PRE-PREPARE阶段以及PREPARED阶段的消息重新开始PRE-PREPARE过程，即，如果副本共识节点在未延长的VIEW-CHANGE二次启动定时器的定时期限内，接收到 NEW-VEIW时，停止VIEW-CHANGE二次启动定时器，如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果副本共识节点在延长的定时期限内接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器。
二是对于下一轮次的新的主共识节点，如果下一个主共识节点在未延长的 VIEW-CHANGE二次启动定时器定时期限内接收到超过共识节点总数量2/3个 VIEW-CHANGE消息，则表明VIEW-CHANGE准备工作已经全部完成，新的主共识节点将发送NEW-VIEW，进入新的VIEW，开始作为新的主共识节点主持整个共识系统的共识过程；类似地，如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果下一个主共识节点在延长的定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则表明VIEW-CHANGE准备工作已经全部完成，新的主共识节点将发送NEW-VIEW，进入新的 VIEW。
实施例三
实施例三提供了一种实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长装置，其特征在于，共识节点包括接收模块、提取模块、去重模块、延长定时期限模块；接收模块：接收其他共识节点发送的VIEW-CHANGE消息；提取模块：从接收模块获取 VIEW-CHANGE消息，提取所述其他共识节点发送的VIEW-CHANGE消息中的PREPARED 数据，进一步提取所述PREPARED数据中的共识节点信息；去重模块：将所述PREPARED 数据中的共识节点信息持续进行去除重复的操作，形成没有重复共识节点信息的列表；延长定时期限模块：根据去重模块形成的所述没有重复共识节点信息的列表，当列表中的节点信息数量达到满额的时候，将VIEW-CHANGE二次启动定时器的定时期限进行延长。
为尽量避免网络环境差的共识节点延误了网络环境好的共识节点的进度，甚至可能延误了整个共识系统的进度，因此，需要采取相应的措施来改善这种情况。为此，设置一个备份表格模块：在所述PREPARED数据中的共识节点信息过程中另建一张备份表格，并将提取的节点信息存入该备份表格，对所述备份表格内的节点信息不进行去除重复的操作。对备份表格内的节点数量进行统计，当备份表格内的节点数量累积到满额的平方时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的 VIEW-CHANGE流程。对备份表格内的节点数量进行统计，当任一共识节点在备份表格中出现频次大于或等于满额时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
VIEW-CHANGE二次启动定时器控制模块：当共识节点为副本共识节点时，如果在未延长的VIEW-CHANGE二次启动定时器的定时期限内，接收到NEW-VEIW时，停止 VIEW-CHANGE二次启动定时器，如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果在延长的定时期限内接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器。当共识节点为下一个主共识节点时，如果在未延长的VIEW-CHANGE二次启动定时器定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则发送NEW-VIEW，进入新的VIEW；如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果在延长的定时期限内接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则发送NEW-VIEW，进入新的VIEW。
本发明说明书提到的各实施例仅用以说明涉及的技术方案，而非对保护范围进行限制，尽管参照各实施例对本发明的技术方案进行了详细的说明，然而本领域技术人员应当理解，对于各实施例的技术方案仍然能够进一步修改、改进，或者对其中部分或者全部技术特征进行替换；而这些修改、改进或者替换，并不使其本质脱离了本发明意图保护的范围。

Claims (10)

1.一种实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，其特征在于，
共识节点接收其他共识节点发送的VIEW-CHANGE消息；
提取所述其他共识节点发送的VIEW-CHANGE消息中的PREPARED数据的共识节点信息；
将所述提取的PREPARED数据中的共识节点信息存入备份表格，对所述存入备份表格的共识节点信息进行持续去除重复的操作，形成没有重复共识节点信息的列表；
所述PREPARED数据指的是：接收的VIEW-CHANGE消息中，包含了发送VIEW-CHANGE消息的共识节点，所处理的处于PREPARED状态的请求，其中不包含发送VIEW-CHANGE消息的共识节点中已经进入COMMIT状态的请求；当列表中的共识节点信息数量达到满额的时候，将VIEW-CHANGE二次启动定时器的定时期限进行延长；
所述当列表中的共识节点信息数量达到满额的标准是：达到3f个没有重复的共识节点信息，此时收集完毕了所有的共识节点信息，显示该共识节点能够直接或间接地获取所有共识节点信息，整个共识系统的通信环境是良好的。
2.如权利要求1所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，其特征在于，
对所述存入备份表格中的共识节点信息持续进行去除重复操作为在存入所述备份表格之前进行去除重复操作。
3.如权利要求1所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，其特征在于，对所述存入备份表格中的共识节点信息进行去除重复操作为在存入备份表格之后对备份表格中的共识节点信息进行去除重复操作。
4.如权利要求3所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，其特征在于，
对所述备份表格内的共识节点信息数量进行统计，当所述备份表格内的共识节点信息数量累积到满额的平方时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
5.如权利要求3所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，其特征在于，
对所述备份表格内的共识节点信息数量进行统计，当任一共识节点信息数量在所述备份表格中出现频次大于或等于满额时，停止VIEW-CHANGE并重置VIEW-CHANGE二次启动定时器，并再次启动下一个主共识节点的VIEW-CHANGE流程。
6.如权利要求1-5中任意一项所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，其特征在于，
如果副本共识节点在未延长的VIEW-CHANGE二次启动定时器的定时期限内，接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器；
如果VIEW-CHANGE二次启动定时器的定时期限被延长，则如果副本共识节点在延长的定时期限内接收到NEW-VEIW时，停止VIEW-CHANGE二次启动定时器。
7.如权利要求1-5中任意一项所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长方法，其特征在于，
如果在未延长的VIEW-CHANGE二次启动定时器定时期限内下一个主共识节点接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则发送NEW-VIEW，进入新的VIEW；如果在VIEW-CHANGE二次启动定时器的定时期限被延长的定时期限内下一个主共识节点接收到超过共识节点总数量2/3个VIEW-CHANGE消息，则发送NEW-VIEW，进入新的VIEW。
8.一种实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长装置，其特征在于，
共识节点包括接收模块、提取模块、去重模块、延长定时期限模块；
接收模块：接收其他共识节点发送的VIEW-CHANGE消息；
提取模块：提取所述其他共识节点发送的VIEW-CHANGE消息中的PREPARED数据中的共识节点信息；
去重模块：将所述提取的PREPARED数据中的共识节点信息存入备份表格，对所述存入备份表格的共识节点信息进行持续去除重复的操作，形成没有重复共识节点信息的列表；
所述PREPARED数据指的是：接收的VIEW-CHANGE消息中，包含了发送VIEW-CHANGE消息的共识节点，所处理的处于PREPARED状态的请求，其中不包含发送VIEW-CHANGE消息的共识节点中已经进入COMMIT状态的请求；延长定时期限模块：当列表中的共识节点信息数量达到满额的时候，将VIEW-CHANGE二次启动定时器的定时期限进行延长；
所述当列表中的共识节点信息数量达到满额的标准是：达到3f个没有重复的共识节点信息，此时收集完毕了所有的共识节点信息，显示该共识节点能够直接或间接地获取所有共识节点信息，整个共识系统的通信环境是良好的。
9.如权利要求8所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长装置，其特征在于，
对所述存入备份表格中的共识节点信息持续进行去除重复操作为在存入所述备份表格之前进行去除重复操作。
10.如权利要求8所述的实用型拜占庭容错VIEW-CHANGE二次启动定时器的定时期限延长装置，其特征在于，对所述存入备份表格中的共识节点信息进行去除重复操作为在存入备份表格之后对备份表格中的共识节点信息进行去除重复操作。
CN202010879413.7A 2020-08-27 2020-08-27 View-change二次启动定时器的定时期限延长方法及装置 Active CN112068978B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010879413.7A CN112068978B (zh) 2020-08-27 2020-08-27 View-change二次启动定时器的定时期限延长方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010879413.7A CN112068978B (zh) 2020-08-27 2020-08-27 View-change二次启动定时器的定时期限延长方法及装置

Publications (2)

Publication Number Publication Date
CN112068978A CN112068978A (zh) 2020-12-11
CN112068978B true CN112068978B (zh) 2022-06-10

Family

ID=73660731

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010879413.7A Active CN112068978B (zh) 2020-08-27 2020-08-27 View-change二次启动定时器的定时期限延长方法及装置

Country Status (1)

Country Link
CN (1) CN112068978B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112929354B (zh) * 2021-01-28 2022-04-08 恒宝股份有限公司 一种实用型拜占庭容错抗攻击死锁的方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106651346A (zh) * 2016-11-28 2017-05-10 上海凯岸信息科技有限公司 基于区块链的征信数据共享与交易系统
CN107579848A (zh) * 2017-08-30 2018-01-12 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
CN110445619A (zh) * 2017-03-30 2019-11-12 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
CN110443616A (zh) * 2019-06-28 2019-11-12 筑客网络技术（上海）有限公司 基于随机门限签名机制的拜占庭容错共识方法
CN111522876A (zh) * 2020-04-07 2020-08-11 金蝶软件（中国）有限公司 区块链共识方法、装置和计算机设备、及区块链节点

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106445711B (zh) * 2016-08-28 2019-04-30 杭州云象网络技术有限公司 一种应用于区块链的拜占庭容错共识方法
CN108667614B (zh) * 2018-04-19 2021-02-02 上海分布信息科技有限公司 一种拜占庭容错方法及其实现系统
BR112019008172B1 (pt) * 2018-11-07 2022-01-25 Advanced New Technologies Co., Ltd Método implementado por computador para facilitar um processo de consenso em uma rede de protocolo de confiança baseada na tolerância a falhas bizantinas práticas, meio de armazenamento não transitório legível por computador e sistema
CN109600323B (zh) * 2018-11-12 2021-10-01 中山大学 一种拜占庭共识机制
AU2018348336B2 (en) * 2018-12-13 2020-07-23 Advanced New Technologies Co., Ltd. Performing a change of primary node in a distributed system
CN111338857A (zh) * 2020-02-11 2020-06-26 安徽理工大学 一种拜占庭容错共识协议
CN111586168B (zh) * 2020-05-06 2022-04-08 恒宝股份有限公司 水线高度的更改设置方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106651346A (zh) * 2016-11-28 2017-05-10 上海凯岸信息科技有限公司 基于区块链的征信数据共享与交易系统
CN110445619A (zh) * 2017-03-30 2019-11-12 腾讯科技（深圳）有限公司 区块链系统、消息处理方法及存储介质
CN107579848A (zh) * 2017-08-30 2018-01-12 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
CN110443616A (zh) * 2019-06-28 2019-11-12 筑客网络技术（上海）有限公司 基于随机门限签名机制的拜占庭容错共识方法
CN111522876A (zh) * 2020-04-07 2020-08-11 金蝶软件（中国）有限公司 区块链共识方法、装置和计算机设备、及区块链节点

Also Published As

Publication number Publication date
CN112068978A (zh) 2020-12-11

Similar Documents

Publication Publication Date Title
US10833919B2 (en) Node device operation method, work status switching apparatus, node device, and medium
CN108600353B (zh) 一种区块链节点的并行块同步方法
CN107995127B (zh) 一种过载保护方法及装置
CN111130879B (zh) 一种基于pbft算法的集群异常恢复方法
CN103580915B (zh) 集群系统中确定主控节点的方法及装置
EP4061052A1 (en) Information reporting method, information receiving method, terminal and network device
CN112506702B (zh) 数据中心容灾方法、装置、设备及存储介质
WO2018010501A1 (zh) 全局事务标识gtid的同步方法、装置及系统、存储介质
CN111901422A (zh) 一种集群中节点的管理方法、系统及装置
CN107231435B (zh) 数据同步监控方法及系统
CN115002013B (zh) 运行状态的确定方法、装置、存储介质及电子装置
CN112068978B (zh) View-change二次启动定时器的定时期限延长方法及装置
CN111752488B (zh) 存储集群的管理方法、装置、管理节点及存储介质
CN110674096A (zh) 节点故障排查方法、装置、设备及计算机可读存储介质
CN112003947A (zh) 一种防止客户端向服务器重复请求的系统和验证方法
CN104821889B (zh) 一种备份报文的处理方法和设备
CN105354110A (zh) 云服务器数据备份方法及装置
CN111880947A (zh) 一种数据传输方法及装置
CN110597672A (zh) 一种atca交换系统的主备倒换的方法及装置
CN116010174A (zh) 切换服务器的方法及装置、存储介质、电子装置
CN113055203A (zh) Sdn控制平面的异常恢复方法及装置
CN112367386B (zh) 基于Ignite的自动化运维方法、装置及计算机设备
EP2988476A1 (en) Method and apparatus for processing operation on endpoint peripheral
CN111124737A (zh) 一种云平台作业冲突的判断方法及电子设备
CN115348252B (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