一种多个星节点分布式共识的处理方法和处理系统

摘要: 本申请涉及卫星星座环境下的分布式共识,具体涉及一种多个星节点分布式共识的处理方法和处理系统。背景技术:1、在地面数据中心领域,以computeexpressli...
一种多个星节点分布式共识的处理方法和处理系统

本申请涉及卫星星座环境下的分布式共识,具体涉及一种多个星节点分布式共识的处理方法和处理系统。

背景技术:

1、在地面数据中心领域,以compute express link(cxl)为代表的一致性互连技术已成为异构计算架构升级的核心支撑。cxl基于pcie物理层构建,通过cxl.io(i/o协议)、cxl.cache(缓存一致性协议)与cxl.mem(内存语义协议)三大子协议,实现了cpu、gpu、npu、fpga及内存扩展设备之间的缓存一致性互联与内存池化共享。cxl 3.0支持跨节点的全局地址空间映射、动态内存分配与硬件级缓存一致性维护,带宽可达128 gb/s(x16),延迟控制在百纳秒级,有效支撑了ai训练、高性能计算及云基础设施中的大规模异构资源统一调度。

2、然而,将地面一致性互连技术直接应用于星载环境面临根本性适配难题。星载计算场景具有以下区别于地面数据中心的本质特征:

3、链路间歇性通断:星间链路(激光或微波)受轨道几何约束呈周期性可见与不可见交替,链路窗口期与静默期交替出现,无法提供持续稳定的双向通信通道。leo星座中相邻卫星的可见窗口通常在数分钟至数十分钟量级,窗口切换期间链路质量剧烈波动。

4、拓扑时变驱动:星座拓扑并非由人工静态配置,而是受轨道力学严格驱动呈周期性演化。卫星间的相对位置、天线指向可用性、链路预算随轨道相位实时变化,导致最优的数据迁移路径与共识拓扑结构持续动态调整。

5、传统raft、paxos等共识协议基于地面数据中心持续可用的低延迟网络设计,其核心假设包括:网络分区是异常状态而非常态;节点故障与链路中断可通过固定超时机制可靠区分;领导选举与日志复制依赖持续稳定的双向通信。在星间链路环境下,这些基本假设均不成立:固定周期的心跳机制将链路不可见期间误判为领导节点失效,频繁触发无意义的领导选举与日志回滚;多数派投票机制在星间链路窗口切换期间因节点不可达而失效,导致系统可用性急剧下降;逐条确认与固定超时策略无法利用链路窗口期的有限带宽,协议开销大量挤占宝贵的星间通信资源。因此,传统raft、paxos等共识协议难以适用于星间链路环境下。

6、需要说明的是,在上述背景技术部分公开的信息仅用于加强对本申请的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现思路

1、为了对披露的实施例的一些方面有基本的理解,下面给出了简单的概括。所述概括不是泛泛评述,也不是要确定关键/重要组成元素或描绘这些实施例的保护范围,而是作为后面的详细说明的序言。

2、本公开实施例提供了一种多个星节点分布式共识的处理方法和处理系统,能够适用于星间链路受轨道几何约束呈周期性可见与不可见交替的环境下,解决选举、日志复制等超时情况下,频繁触发无意义的领导选举的问题。

3、在一些实施例中,一种多个星节点分布式共识的处理方法,至少两个星节点组成星节点组,星节点组中的星节点分为领导节点、跟随节点,所述星节点中包括处理系统,所述处理系统包括自适应心跳定时单元和投票收集引擎,所述处理方法包括,由所述自适应心跳定时单元:依据链路可见性划分链路状态,所述链路状态包括稳定窗口期、窗口转换期与窗口边界期;基于第一星节点的轨道星历信息确定第一星节点的当前链路状态;基于第一星节点的当前链路状态,以及预设的链路状态与窗口期系数的对应关系,确定第一星节点当前的窗口期系数;基于第一星节点当前的窗口期系数和超时参数基础值,得到第一星节点的目标超时参数值;

4、由所述投票收集引擎:基于目标超时参数值,在选举操作、心跳间隔和/或日志复制延时的时间达到目标超时参数值的情况下,所述第一星节点由跟随节点转为候选节点;不增加任期号并向星节点组内的其它星节点发送预投票请求信息;在没有收到超过预定数量星节点的响应信息的情况下,第一星节点退回为跟随节点;在收到超过预定数量星节点的同意第一星节点为候选节点的响应信息的情况下,增加任期号并进入选举程序。

5、在一些实施例中,一种多个星节点分布式共识的处理系统,至少两个星节点组成星节点组,星节点组中的星节点分为领导节点、跟随节点,所述处理系统布置于星节点,所述处理系统包括自适应心跳定时单元和投票收集引擎;所述自适应心跳定时单元配置为:依据链路可见性划分链路状态,所述链路状态包括稳定窗口期、窗口转换期与窗口边界期;基于第一星节点的轨道星历信息确定第一星节点的当前链路状态;基于第一星节点的当前链路状态,以及预设的链路状态与窗口期系数的对应关系,确定第一星节点当前的窗口期系数;基于第一星节点当前的窗口期系数和超时参数基础值,得到第一星节点的目标超时参数值;

6、所述投票收集引擎配置为:基于目标超时参数值,在选举操作、心跳间隔和/或日志复制延时的时间达到目标超时参数值的情况下,所述第一星节点由跟随节点转为候选节点;不增加任期号并向星节点组内的其它星节点发送预投票请求信息;在没有收到超过预定数量星节点的响应信息的情况下,第一星节点退回为跟随节点;在收到超过预定数量星节点的同意第一星节点为候选节点的响应信息的情况下,增加任期号并进入选举程序。

7、本公开实施例提供的多个星节点分布式共识的处理系统和处理方法,根据第一星节点的轨道星历信息,来区分第一星节点所处的不同链路状态;不同链路状态分别对应不同的窗口期系数,这样不同的链路状态就能够分别对应不同的目标超时参数值;投票收集引擎根据获取的目标超时参数值,来判断选举操作、心跳间隔和/或日志复制延时的时间是否达到目标超时参数值,在链路间歇性通断、星节点拓扑变化、星节点故障等情况下,如果达到目标超时时间就会先进入预投票过程,即发送预投票请求,根据第一星节点与其他星节点的连通情况,以及其他星节点对第一星节点的审核情况,决定第一星节点是否收到响应信息,在第一星节点与超过预定数量星节点隔离、第一星节点审核不通过的情况下,没有收到响应信息,这样能够减少触发无意义选举,减少链路间歇性通断中链路短暂抖动对星节点组稳定性的影响。

8、以上的总体描述和下文中的描述仅是示例性和解释性的,不用于限制本申请。

1.一种多个星节点分布式共识的处理方法,其特征在于,至少两个星节点组成星节点组,星节点组中的星节点分为领导节点、跟随节点,所述星节点中包括处理系统,处理系统包括自适应心跳定时单元和投票收集引擎,所述处理方法包括:

2.根据权利要求1所述的处理方法,其特征在于,所述预投票请求信息包括第一星节点的任期号和权重信息,由第二星节点的投票收集引擎:基于收到的预投票请求信息,比较第一星节点的任期号和第二星节点的任期号;在第一星节点的任期号大于或等于第二星节点的任期号,且第一星节点的权重值大于或等于第一阈值的情况下,向第一星节点发送同意第一星节点为候选节点的响应信息;在第一星节点的任期号小于第二星节点的任期号,和/或第一星节点的权重值小于第一阈值的情况下,不向第一星节点发送响应信息。

3.根据权利要求1所述的处理方法,其特征在于,所述处理方法还包括,由所述自适应心跳定时单元:

4.根据权利要求1所述的处理方法,其特征在于,由所述投票收集引擎计算各个星节点权重参数值,包括:

5.根据权利要求4所述的处理方法,其特征在于,轨道星历参数、健康状态参数、日志状态参数和能源状态参数附带时间戳和星节点来源标识;

6.根据权利要求4所述的处理方法,其特征在于,所述处理方法还包括,由所述自适应心跳定时单元:

7.根据权利要求4所述的处理方法,其特征在于,所述处理方法还包括,由所述投票收集引擎:获取各个星节点的轨道星历信息、星节点组成员变更信息、各个星节点的故障信息;在各个星节点的周期结束、星节点组成员变更、各个星节点发生故障时触发计算星节点的权重参数值;在计算得到新的权重参数值后,与星节点组内的其它星节点交换权重向量,所述权重向量为各个星节点的权重参数值;在第一星节点所计算的各个星节点的权重参数值与星节点组内的其它星节点发送的权重向量的权重参数值对应一致的情况下,更新第一星节点的权重参数值。

8.根据权利要求4所述的处理方法,其特征在于,在第一星节点为领导节点的情况下,由所述投票收集引擎:

9.根据权利要求6所述的处理方法,其特征在于,所述领导权转移流程包括:第一星节点停止接收新请求,继续完成正在处理的事项进程;第一星节点将未提交的日志全部复制至第二星节点,并将超时信息发送至第二星节点;第二星节点在接收到超时信息的情况下,发起选举。

10.一种多个星节点分布式共识的处理系统,其特征在于,至少两个星节点组成星节点组,星节点组中的星节点分为领导节点、跟随节点,所述处理系统布置于星节点,处理系统包括自适应心跳定时单元和投票收集引擎;