CN114039978B - 一种去中心化的PoW算力集群部署方法 - Google Patents

Abstract

本发明公开了一种去中心化的PoW算力集群部署方法，包括实现DRCCP通讯协议部署的DRCCP通讯流程，该通讯流程包括集群初始化、建立通讯、请求同步、责任声明、故障迁移、请求转发和集群停机。与现有技术相比，本发明使集群内的各计算节点可以自主协调数据同步，并自动进行故障迁移，有效减少了节点数量，在实现容错性能的前提下降低了部署成本；同时，通过服务发现形式自主扩容，在横向扩容上能实现更加灵活的效果。

Description

一种去中心化的PoW算力集群部署方法

技术领域

本发明涉及分布式网络和共识机制领域，特别是涉及一种PoW算力集群设计方案。

背景技术

随着深度学习模型的大型化发展，为满足深度学习的高算力需求，分布式技术方案逐渐成为研究热点。在面对深度学习庞大资源池时，能将任务拆分成多个子任务，有效解决传统并行计算中耗时长的问题，实现高速度、高效率的计算效果。在分布式技术方案中，对于算力和处理能力是实现集群方案部署的核心。

分布式技术方案通常采用主/从和多主架构。在实现有效集群调度的前提下，一方面提高服务的容错性，即当一个节点崩溃时还存在多个节点可以运行，另一方面提高服务的响应速度，即多个节点提供服务，从而有效缓解响应延迟带来的问题，提高系统的承受能力。集群调度模式主要有负载均衡模式、主/从分离模式以及选举模式等。但这些模式都额外需要至少一个主节点（Master/Leader）用于监控集群状态，是一种中心化的算力集群方案。其中主节点（Master/Leader）是调度机制中最关键的环节，承担着集群监控和从节点（Slave）分发等重要职能。在主节点（Master/Leader）节点下线的情况下，集群中的从节点（Slave）将被迫重新选举新的主节点（Master/Leader），此时集群将出现真空期，不利于集群的顺利工作。随着分级数的增加，中心化模式需要增设额外节点，从而导致主节点（Master/Leader）数量也会随着增加，这样不仅浪费了部分节点的处理性能，还需额外对主节点（Master/Leader）进行分配。比如，在选举模式中，全部节点事实上均处于暂停状态，极大程度上延长了节点的等待时间，浪费空闲节点的性能，降低了整体的运行效率，使得部署复杂低效。

发明内容

本发明旨在提出了一种去中心化的PoW算力集群部署方法，采用分布式网络设计了一种DRCCP通讯协议和实现DRCCP通讯协议部署的通讯流程。

本发明利用以下技术方案实现：

一种去中心化的PoW算力集群部署方法，该方法包括实现DRCCP通讯协议部署的通讯流程，其中，所述字段UID，用于记录消息时间戳，以保证在运行期间不重复；所述字段TYPE，用于记录消息类型，以描述消息的发送目的和接受者的行为，其取值至少为HEART请求、ALIVE请求、SYNC请求、RECOVER请求、FAIL请求以及MEET-PING-PONG请求；所述字段DATA，用于记录传输数据；该通讯流程具体包括以下步骤：

步骤1：集群初始化，确定DRCCP通讯协议的报文格式以及具体字段格式，以去中心化为标准构建集自主协调数据同步、自动故障迁移、分布式一致性为一体的分布式DRCCP通讯协议；

步骤2：建立通讯，通过MEET-PING-PONG在主机和集群间建立通讯；

步骤3：请求同步，节点向其他节点发送同步请求；

步骤4：责任声明，节点对提案进行责任声明；

步骤5：故障迁移，通过设计的PoW共识算法实现节点故障迁移；所述PoW共识算法，实现了将故障迁移分为集群侧和节点侧，当节点发送的HEART请求未得到回复时，开启一个FAIL提案，强制发送心跳HEART监测请求，随后，按照回复统计支持票数，若支持票数过半，判定节点下线，使用空闲节点或重复连接继续运作；

步骤6：请求转发，利用节点转移非负责的hash值；

步骤7：集群停机，接受STOP消息，停止集群工作。

与现有技术相比，本发明使集群内的各计算节点可以自主协调数据同步，并自动进行故障迁移，有效减少了节点数量，在实现容错性能的前提下降低了部署成本；同时，通过服务发现形式自主扩容，在横向扩容上能实现更加灵活的效果。

附图说明

图1为本发明的一种去中心化的PoW算力集群部署方法整体方案示意图；

图2为本发明的通讯流程整体流程示意图；

图3为本发明的建立通讯流程图；

图4为本发明的请求同步流程图；

图5为本发明的责任声明流程图；

图6为本发明的故障迁移流程图，（6a）集群侧，（6b）节点侧。

具体实施方式

以下结合附图和具体实施例对本发明的技术方案进行详细说明。

如图1所示，为本发明的一种去中心化的PoW算力集群部署方法整体方案示意图。本发明整体方案分为DRCCP通讯协议和实现DRCCP通讯协议部署的DRCCP通讯流程两个部分。其中，所述DRCCP协议作为以去中心化为标准构建了一种集自主协调数据同步、自动故障迁移、分布式一致性为一体的分布式通讯协议，实现了集群的实时同步和故障迁移。所述DRCCP通讯流程包括建立通讯、请求同步、责任声明、故障迁移和请求转发，实现节点自动请求同步和故障迁移。部署DRCCP通讯协议的DRCCP通讯流程基于PoW共识算法来实现。所述PoW共识算法，实现了将故障迁移分为集群侧和节点侧，当节点发送的HEART请求未得到回复时，开启一个FAIL提案，强制发送心跳HEART监测请求。随后，按照回复统计支持票数，若支持票数过半，判定节点下线，使用空闲节点或重复连接继续运作。

一、DRCCP通讯协议

所述DRCCP通讯协议的报文格式包括三个字段：UID、TYPE和DATA。分别对这三个字段进行说明如下：

（一）字段UID

记录每一条消息的时间戳，以保证在运行期间不重复。字段UID在操作次数递增的情况下不会减少，这使得具有序关系的两个操作在任何情况下均保持原本的序关系，且可保证已发生的事件不会被回退。节点利用字段UID报文格式，通过追加消息的方式认可该消息，维护日志的一致性，有助于实现PoW共识。该字段UID是80位的10进制数字。

（二）字段TYPE

记录每一条消息的类型，用于区分消息的发送目的和接受者的行为，其取值有HEART、ALIVE、SYNC、RECOVER、FAIL、MEET-PING-PONG等等。对于不同类型的消息类型，UID编号也会做出相应的变化。

（三）字段DATA

记录实际传输的数据。对于不同类型的消息，数据存在不同的格式。

二、DRCCP通讯流程，实现了对各部分设计了通讯流程和对应的日志记录规则，也为主机对于不同类型消息的回复制定了规则。如图2所示，为基于DRCCP通讯协议的通讯流程示意图，包括以下步骤：

步骤1：集群初始化，确定通讯协议的报文格式以及具体字段格式；

步骤2：建立通讯，通过MEET-PING-PONG在主机和集群间建立通讯；

步骤3：请求同步，节点向其他节点发送RECOVER 以请求同步；

步骤4：责任声明，节点通过DECLARE对提案进行责任声明；

步骤5：故障迁移，通过设计的共识算法实现节点故障迁移；

步骤6：请求转发，节点可以转移非负责的hash值；

步骤7：集群停机，接受STOP消息，停止集群工作。

上述DRCCP通讯流程的具体处理如下：

步骤1、集群初始化，确定通讯协议的报文格式以及具体字段格式：人工手动指定一台主机作为初始节点，点亮该节点的BOOT标记位，被点亮BOOT标记位的主机无需进行PONG认证即可自动加入集群，将一条PONG消息作为创始日志头进行记录，并强制执行一次SYNC同步，运行过程中，当BOOT标记位收到另一节点的加入的信息时，原BOOT标记位熄灭；

步骤2、建立通讯，通过MEET-PING-PONG在主机和集群间建立通讯：日志记录采用PONG消息同步至集群消息队列的规则，当主机向任意一个集群中的结点发送MEET消息时，若收到消息的节点同意加入集群，则向主机回复PING。主机收到节点消息后，向该节点回复PONG消息进行确认。介绍节点收到PONG消息后将自动更新集群节点列表，并向集群发送SYNC消息声明新节点信息；

如图3所示，为建立通讯流程。主机向任意一个集群中的结点发送MEET消息，任意节点收到后如同意加入集群则回复PING。如多个结点回复，则仅接受最先到达的节点请求并回复PONG消息确认。当发送PONG消息后，超过2倍等待时间无异常，自动视为主机加入集群。介绍节点收到PONG消息后，更新集群节点列表，并向集群发送SYNC消息声明新节点。其中，日志记录规则为PONG消息同步至集群消息队列。

步骤3、请求同步，节点向其他节点发送RECOVER 以请求同步：待同步节点如需要同步，可向全体节点发送RECOVER消息请求同步，其他节点收到后回复SYNC消息，此消息包含全体增量消息，待同步节点收到SYNC消息后，根据消息的UID进行筛选和增量更新；

如图4所示，为请求同步流程图。待同步节点向全体节点发送RECOVER消息请求同步，其他节点收到后回复SYNC消息，包含全部的增量消息。任何情况下，节点收到SYNC消息后，首先检查UID首尾，若满足起始UID=当前UID+1，则选取满足条件的SYNC消息中尾UID最大的一个值进行增量更新。

步骤4、责任声明，节点通过DECLARE对提案进行责任声明：日志记录采用仅记录一次DECLARE+CMT消息，若DECLARE被全部驳回则不同步的规则，当节点准备负责新的hash映射值时，会向集群发送DECLARE消息，用于声明新负责节点（开启一个提案），根据其他节点拒绝和接受的情况，决定该提案是否被集群认可；

如图5所示，为责任声明流程图。当节点准备负责新的hash映射值时，需要向集群发送DECLARE消息，声明新负责的节点，即开启一个提案。其他节点收到DECLARE消息后，若映射值出现冲突，则回复REJECT消息进行拒绝。任何一个提案在规定时间内未受到REJECT消息的映射值则视为被集群认可。该节点重新发送DECLARE消息，并点亮CMT标记位通知提案生效。

任何节点，在任何状态下收到DECLARE+CMT消息，则强制进行一次同步。日志记录规则为仅记录一次DECLARE+CMT消息，若DECLARE中的全部映射值被全部驳回，则不同步。

步骤5、故障迁移，通过设计的共识算法实现节点故障迁移：日志记录采用仅记录一次FAIL+CMT消息的规则，在该步骤中，设计了一种新的共识算法，将故障迁移分为集群侧和节点侧，当节点发送的HEART请求未得到回复时，开启一个FAIL提案，强制进行HEART请求监测，随后，按照回复统计支持票数，若支持票数过半，判定节点下线，使用空闲节点或重复连接继续运作；

如图6所示，故障迁移流程图。将故障迁移流程分为（6a）集群侧和（6b）节点侧两个方面。

就集群侧而言，当节点向某一节点发送的HEART心跳请求未得到回复时，主观判定另一侧结点下线，开启一个FAIL提案，向集群发送一个FAIL消息，其他节点收到FAIL消息时，强制进行一次HEART请求检测。若HEART-ALIVE请求失败，则使用同UID的FAIL消息同意该提案。对于同一个FAIL提案，每个节点仅有一票。在收到提案的CMT消息之前，节点不再对该提案投票。一定时间内空闲节点收到的支持票数超过半数时，判定节点客观下线，空闲节点重复请求同步和责任声明过程，接替下线节点，发送FAIL+CMT消息确认提案生效。日志记录规则为仅记录一次FAIL+CMT消息。

就节点侧而言，任何一个节点发送HEART请求未回复时，则开启一个Local FAIL提案，强制向其他节点发送一次HEART请求，每一个ALIVE回复视为一张支持票。若规定时间内未获得超过半数的集群节点支持，则判定本地下线，连接状态重置。若仍需继续连接，则需要重复建立通讯、请求同步、责任声明等过程恢复连接。

步骤6、请求转发，节点可以转移非负责的hash值：当节点接收到的请求不是负责的hash值时，向负责节点发送MOVE消息进行请求转发，任何节点接收到MOVE消息后，会代替原有节点进行客户端通信，原有节点不再处理任何该请求的后续内容；

步骤7、集群停机，接受STOP消息，停止集群工作：日志记录采用记录一次STOP消息的规则，STOP消息用于停止集群工作，当接收到STOP消息时，节点会进行资源回收，断开连接，并重置连接状态，清空日志。

DRCCP通讯流程得益于Master/Leader节点的去除，极大地减少了多余和空闲节点数目，缩短了计算时间，降低了部署成本，在横向扩容上扩大了资源池的容量，提高了计算的速度和算力的利用效率，提升了系统的容错性能和可用性能，促进了集群部署的实时化和高效化发展。

DRCCP通讯流程在没有Master/Leader节点的情况下进行正常工作，提高算力调度的效率。

如表1所示，为消息类型和数据格式。

表1

如表2所示，为 UID编号规则表格。UID记录消息传达的时间戳，对于不同类型的消息设计了不同的UID编号规则。

表2

如表3所示，为主机消息处理规则。主机在未加入集群时，仅接受PING消息，仅发送MEET消息，主机在加入集群后的消息处理规则。

表3

本发明突破性地设计了一种DRCCP通讯协议（Distributed Redis-like ClusterCommunication Protocol，分布式类Redis集群通信协议），并设计了一种共识算法，利用日志作为PoW工作量证明，去除了Mater/Leader节点，维护了操作的一致性，使集群内的各计算节点可以自主协调数据同步，并自动进行故障迁移。

Claims (4)

1.一种去中心化的PoW算力集群部署方法，其特征在于，该方法包括实现DRCCP通讯协议部署的通讯流程，所述DRCCP通讯协议的报文格式包括字段UID、字段TYPE和字段DATA三个字段，其中，所述字段UID，用于记录消息时间戳，以保证在运行期间不重复；所述字段TYPE，用于记录消息类型，以描述消息的发送目的和接受者的行为，其取值至少为HEART请求、ALIVE请求、SYNC请求、RECOVER请求、FAIL请求以及MEET-PING-PONG请求；所述字段DATA，用于记录传输数据；该通讯流程具体包括以下步骤：

步骤1：集群初始化，确定DRCCP通讯协议的报文格式以及具体字段格式，以去中心化为标准构建集自主协调数据同步、自动故障迁移、分布式一致性为一体的分布式DRCCP通讯协议；

步骤2：建立通讯，通过MEET-PING-PONG在主机和集群间建立通讯；

步骤3：请求同步，节点向其他节点发送同步请求；

步骤4：责任声明，节点对提案进行责任声明；

当节点准备负责新的hash映射值时，向集群发送DECLARE消息，声明新负责的节点，即开启一个提案，其他节点收到DECLARE消息后，若映射值出现冲突，则回复REJECT消息进行拒绝，任何一个提案在规定时间内未受到REJECT消息的映射值则视为被集群认可，该节点重新发送DECLARE消息，并点亮CMT标记位通知提案生效；

任何节点，在任何状态下收到DECLARE+CMT消息，则强制进行一次同步，日志记录规则为仅记录一次DECLARE+CMT消息，若DECLARE中的全部映射值被全部驳回，则不同步；

步骤5：故障迁移，通过设计的PoW共识算法实现节点故障迁移；所述PoW共识算法，实现了将故障迁移分为集群侧和节点侧，当节点发送的HEART请求未得到回复时，开启一个FAIL提案，强制发送心跳HEART监测请求，随后，按照回复统计支持票数，若支持票数过半，判定节点下线，使用空闲节点或重复连接继续运作；

就集群侧而言，当节点向某一节点发送的HEART心跳请求未得到回复时，主观判定另一侧结点下线，开启一个FAIL提案，向集群发送一个FAIL消息，其他节点收到FAIL消息时，强制进行一次HEART请求检测，若HEART-ALIVE请求失败，则使用同UID的FAIL消息同意该提案，对于同一个FAIL提案，每个节点仅有一票，在收到提案的CMT消息之前，节点不再对该提案投票，一定时间内空闲节点收到的支持票数超过半数时，判定节点客观下线，空闲节点重复请求同步和责任声明过程，接替下线节点，发送FAIL+CMT消息确认提案生效；

就节点侧而言，任何一个节点发送HEART请求未回复时，则开启一个Local FAIL提案，强制向其他节点发送一次HEART请求，每一个ALIVE回复视为一张支持票，若规定时间内未获得超过半数的集群节点支持，则判定本地下线，连接状态重置，若仍需继续连接，则重复建立通讯、请求同步和责任声明，恢复连接；日志记录规则为仅记录一次FAIL+CMT消息；

步骤6：请求转发，利用节点转移非负责的hash值；

步骤7：集群停机，接受STOP消息，停止集群工作。

2.如权利要求1所述的一种去中心化的PoW算力集群部署方法，其特征在于，所述步骤2还具体包括以下步骤：

主机向任意一个集群中的结点发送MEET消息，任意节点收到后如同意加入集群则回复PING，如多个结点回复，则仅接受最先到达的节点请求并回复PING消息确认，当发送PONG消息后，超过2倍等待时间无异常，自动视为主机加入集群，介绍节点收到PONG消息后，更新集群节点列表，并向集群发送SYNC消息声明新节点，其中，日志记录规则为PONG消息同步至集群消息队列。

3.如权利要求1所述的一种去中心化的PoW算力集群部署方法，其特征在于，所述步骤3还具体包括以下步骤：

待同步节点向全体节点发送RECOVER消息请求同步，其他节点收到后回复SYNC消息，包含全部的增量消息，任何情况下，节点收到SYNC消息后，首先检查UID首尾，若满足起始UID=当前UID+1，则选取满足条件的SYNC消息中尾UID最大的一个值进行增量更新。

4.如权利要求1所述的一种去中心化的PoW算力集群部署方法，其特征在于，所述字段UID在操作次数递增的情况下，使得具有序关系的两个操作在任何情况下均保持原本的序关系，且保证已发生的事件不被回退；

利用字段UID报文格式，节点通过追加消息的方式认可该消息，维护日志的一致性。

Images