分布式***的通信方法及装置
技术领域
本发明涉及计算机技术领域,尤其涉及一种分布式***的通信方法及装置。
背景技术
分布式存储为云计算块存储服务提供了高可用、高性能、高数据安全的保证。在分布式存储中,由于多接点通信、网络多链接、交换机丢包以及网卡硬件等,造成传输过程中请求乱序,导致存储数据被写脏。然而,目前尚未提出能够解决分布式存储***网络乱序问题的解决方案。
发明内容
本申请实施例提供一种分布式***的通信方法及装置,能够解决分布式存储***的网络乱序问题。
本申请采用如下技术方案。
一种分布式***的通信方法,包括:
主节点接收来自客户端的打开虚拟机块设备的请求;
将所述虚拟机块设备的设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成用于代表当前会话的全局版本号;
将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端,以便所述客户端利用所述全局版本号与相应的服务节点建立会话。
其中,所述将所述全局版本号与对于所述虚拟机块设备的服务节点定位信息返回给所述客户端之后,还包括:
主节点接收来自所述服务节点的会话消息,所述会话消息携带客户端提供给所述服务节点的全局版本号;
主节点将所述会话消息携带的全局版本号与本地的全局版本号比较以校验所述会话消息是否过期,在所述会话消息携带的全局版本号不小于本地的全局版本号时,向所述服务节点返回校验通过信息。
其中,所述方法还包括:所述主节点需要迁移到新的物理机时,在所述新的物理机启用为主节点之前,将所述管理者版本号递增,并持久化到本地或共享文件中,同时将递增后的所述管理者版本号同步到其他物理机。
其中,所述将所述全局版本号与对于所述虚拟机块设备的服务节点定位信息返回给所述客户端之后,还包括:
接收来自客户端的查看所述虚拟机块设备的服务节点状态的请求;
查询所述服务节点定位信息,在所述服务节点定位信息失效时,将所述设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成新的全局版本号;
将所述新的全局版本号以及新的服务节点定位信息返回给所述客户端。
一种分布式***的通信方法,包括:
客户端向主节点发送打开虚拟机块设备的请求;
客户端接收所述主节点返回的服务节点定位信息和用于代表当前会话的全局版本号,根据所述服务节点定位信息向相应的服务节点发送会话建立请求,所述会话建立请求携带所述全局版本号,以便与所述服务节点建立会话关系;
其中,所述全局版本号包括设备打开版本号和管理者版本号,所述设备打开版本号为所述主节点在收到所述打开虚拟机块设备的请求后递增的设备打开版本号。
其中,所述根据所述服务节点定位信息向相应的服务节点发送会话建立请求之后,还包括:
接收所述服务节点返回的会话建立成功的消息,将请求序列号重新从0开始递增;
向所述服务节点发送读写IO请求时,在上一次IO请求的所述请求序列号的基础上递增以得到本次IO请求的请求序列号,并在本次IO请求中携带所述全局版本号以及所述本次IO请求的请求序列号。
其中,所述根据所述服务节点定位信息向相应的服务节点发送会话建立请求之后,还包括:
接收来自所述服务节点的会话建立失败消息或IO请求失败消息,向主节点发送查看所述服务节点状态的请求到主节点;
接收所述主节点返回的新服务节点定位信息以及新的全局版本号。
一种分布式***的通信方法,包括:
服务节点接收来自客户端的会话建立请求,所述会话建立请求携带全局版本号;
服务节点向主节点发送会话消息,所述会话消息携带所述全局版本号;
服务节点在接收到所述主节点返回的校验通过信息时,向所述客户端返回会话建立成功的消息;
其中,所述全局版本号包括设备打开版本号和管理者版本号,所述设备打开版本号为所述主节点在收到所述客户端的打开虚拟机块设备的请求后递增的设备打开版本号。
其中,所述向所述客户端返回会话建立成功的消息之后,还包括:
服务节点接收来自所述客户端的IO请求,所述IO请求携带所述全局版本号以及请求序列号;
服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效;
在所述IO请求无效时,服务节点拒绝所述IO请求,向所述客户端返回IO请求失败的信息。
其中,所述方法还包括:服务节点在内存中配置总位数为n的一组窗口,所述窗口的位置相对独立,且每个窗口内存储该当前有效的请求序列号,所述当前有效的请求序列号为所述窗口处理过的最大请求序列号,n不小于相应虚拟机块设备的最大请求并发数;
所述服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效,包括:利用所述总位数为n的一组窗口对所述IO请求携带的请求序列号进行窗口校验,以检查所述IO请求是否有效。
其中,所述进行窗口校验以检查所述IO请求是否有效,包括:通过哈希算法将所述IO请求的请求序列号定位到所述一组窗口中的一个窗口;比较所述IO请求的请求序列号与所定位窗口内当前有效的请求序列号,如果所述IO请求的请求序列号小于所定位窗口内当前有效的请求序列号,则所述IO请求无效。
一种分布式***的通信方法,包括:
客户端向主节点发送打开虚拟机块设备的请求;
主节点将所述虚拟机块设备的设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成用于代表当前会话的全局版本号;
主节点将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端,以便所述客户端利用所述全局版本号与相应的服务节点建立会话。
其中,所述主节点将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端之后,还包括:
客户端根据所述服务节点定位信息向相应的服务节点发送会话建立请求,所述会话建立请求携带所述全局版本号,以便与所述服务节点建立会话关系;
服务节点接收所述会话建立请求,向主节点发送会话消息,所述会话消息携带所述全局版本号;
所述主节点将所述会话消息携带的全局版本号与本地的全局版本号比较以校验所述会话消息是否过期,在所述会话消息携带的全局版本号不小于本地的全局版本号时,向所述服务节点返回校验通过信息;
服务节点在接收到所述主节点返回的校验通过信息时,向所述客户端返回会话建立成功的消息。
其中,还包括:所述主节点需要迁移到新的物理机时,在所述新的物理机启用为主节点之前,将所述管理者版本号递增,并持久化到本地或共享文件中,同时将递增后的所述管理者版本号同步到其他物理机。
其中,还包括:客户端接收所述服务节点返回的会话建立成功的消息,将请求序列号重新从0开始递增;客户端向所述服务节点发送读写IO请求时,在上一次IO请求的所述请求序列号的基础上递增以得到本次IO请求的请求序列号,并在本次IO请求中携带所述全局版本号以及所述本次IO请求的请求序列号。
其中,还包括:服务节点接收来自所述客户端的IO请求,所述IO请求携带所述全局版本号以及请求序列号;服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效;在所述IO请求无效时,服务节点拒绝所述IO请求,向所述客户端返回IO请求失败的信息。
其中,所述方法还包括:服务节点在内存中配置总位数为n的一组窗口,所述窗口的位置相对独立,且每个窗口内存储该当前有效的请求序列号,所述当前有效的请求序列号为所述窗口处理过的最大请求序列号,n不小于相应虚拟机块设备的最大请求并发数;所述服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效,包括:利用所述总位数为n的一组窗口对所述IO请求携带的请求序列号进行窗口校验,以检查所述IO请求是否有效。
其中,还包括:客户端接收来自所述服务节点的会话建立失败消息或IO请求失败消息,向主节点发送查看所述虚拟机块设备的服务节点状态的请求;主节点接收来自客户端的查看服务节点状态的请求,查询所述服务节点定位信息,在所述服务节点定位信息失效时,将所述设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成新的全局版本号;将所述新的全局版本号以及新的服务节点定位信息返回给所述客户端。
一种分布式***的通信装置,包括:
存储有计算机程序的存储器;
处理器,配置为读取所述计算机程序以执行上述的一种分布式***的通信方法的步骤。
一种分布式***的通信装置,包括:
存储有计算机程序的存储器;
处理器,配置为读取所述计算机程序以执行上述的另一种分布式***的通信方法的步骤。
一种分布式***的通信装置,包括:
存储有计算机程序的存储器;
处理器,配置为读取所述计算机程序以执行上述的又一种分布式***的通信方法的步骤。
一种分布式***,包括:客户端、主节点以及服务节点;
所述客户端,用于向主节点发送打开虚拟机块设备的请求;
所述主节点,用于接收来自客户端的打开虚拟机块设备的请求,将所述虚拟机块设备的设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成用于代表当前会话的全局版本号,将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端,以便所述客户端利用所述全局版本号与相应的服务节点建立会话。
其中,所述客户端,还用于根据所述服务节点定位信息向相应的服务节点发送会话建立请求,所述会话建立请求携带所述全局版本号,以便与所述服务节点建立会话关系;
服务节点,用于接收来自客户端的会话建立请求,所述会话建立请求携带全局版本号;向主节点发送会话消息,所述会话消息携带所述全局版本号;在接收到所述主节点返回的校验通过信息时,向所述客户端返回会话建立成功的消息;
所述主节点,还用于将所述会话消息携带的全局版本号与本地的全局版本号比较以校验所述会话消息是否过期,在所述会话消息携带的全局版本号不小于本地的全局版本号时,向所述服务节点返回校验通过信息。
其中,所述客户端,还用于在接收到所述服务节点返回的会话建立成功的消息,将请求序列号重新从0开始递增;以及,还用于向所述服务节点发送读写IO请求时,在上一次IO请求的所述请求序列号的基础上递增以得到本次IO请求的请求序列号,并在本次IO请求中携带所述全局版本号以及所述本次IO请求的请求序列号。
其中,所述服务节点,还用于接收来自所述客户端的IO请求,所述IO请求携带所述全局版本号以及请求序列号;根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效;在所述IO请求无效时,拒绝所述IO请求,向所述客户端返回IO请求失败的信息。
其中,所述服务节点,还用于在内存中配置总位数为n的一组窗口,所述窗口的位置相对独立,且每个窗口内存储该当前有效的请求序列号,所述当前有效的请求序列号为所述窗口处理过的最大请求序列号,n不小于相应虚拟机块设备的最大请求并发数;所述服务节点,用于根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效,包括:利用所述总位数为n的一组窗口对所述IO请求携带的请求序列号进行窗口校验,以检查所述IO请求是否有效。
其中,所述客户端,还用于接收来自所述服务节点的会话建立失败消息或IO请求失败消息,向主节点发送查看所述虚拟机块设备的服务节点状态的请求;所述主节点,还用于接收来自客户端的查看服务节点状态的请求,查询所述服务节点定位信息,在所述服务节点定位信息失效时,将所述设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成新的全局版本号;将所述新的全局版本号以及新的服务节点定位信息返回给所述客户端。
其中,所述主节点,还用于需要迁移到新的物理机时,在所述新的物理机启用为主节点之前,将所述管理者版本号递增,并持久化到本地或共享文件中,同时将递增后的所述管理者版本号同步到其他物理机。
一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述的一种分布式***的通信方法的步骤。
一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述的另一种分布式***的通信方法的步骤。
一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述的又一种分布式***的通信方法的步骤。
一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述的又一种分布式***的通信方法的步骤。
本申请包括以下优点:
本发明实施例中,通过全局版本号解决网络乱序问题同时,保证分布式存储高可用、高性能。
本发明实施例中,通过每次建立新会话递增全局版本号中设备打开版本号的方式解决分布式存储***中主节点、服务节点以及客户端之间通信网络乱序的问题,同时保证分布式存储***的高可用、高性能。
本发明实施例中,主节点故障时通过递增全局版本号中的管理者版本号,解决分布式存储***中主节点故障时的网络乱序问题,同时可以保证分布式存储***中主节点的高可用、高性能。
本发明实施例中,通过全局版本号与请求序列号解决分布式存储***中IO流的通信乱序问题,同时保证分布式存储***的高可用、高性能。
当然,实施本申请的任一产品必不一定需要同时达到以上所述的所有优点。
附图说明
图1为本申请分布式***给的示例性架构示意图;
图2为本申请一种分布式***的通信方法流程示意图;
图3为本申请另一种分布式***的通信方法流程示意图;
图4为本申请再一种分布式***的通信方法流程示意图;
图5为本申请又一种分布式***的通信方法流程示意图;
图6为本申请一实例中分布式***通信过程中控制流处理的示例性流程示意图;
图7为本申请另一实例中分布式***通信过程中IO流处理的示例性流程示意图;
图8为本申请日志结构块设备的示例性结构图。
具体实施方式
下面将结合附图及实施例对本申请的技术方案进行更详细的说明。
需要说明的是,如果不冲突,本申请实施例以及实施例中的各个特征可以相互结合,均在本申请的保护范围之内。另外,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
在一个典型的配置中,客户端或服务器的计算设备可包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存(memory)。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。内存可能包括模块1,模块2,……,模块N(N为大于2的整数)。
计算机可读介质包括永久性和非永久性、可移动和非可移动存储介质。存储介质可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM),快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
本文术语解释如下:
虚拟机块设备(block device),也可称为虚拟机磁盘或块设备,是利用物理机器或其集群提供的物理磁盘资源形成的虚拟磁盘。
日志结构块设备(LSBD,log structured block device),也可称为日志结构的虚拟机磁盘,是基于日志方式构建的虚拟机块设备。
Raft是一种用来管理日志复制的一致性算法。
Paxos是一种基于消息传递的一致性算法。
如图1所示,为本申请所述分布式存储***的示例性架构。其中,该分布式存储***可以包括:客户端(Client)、主节点(Master)、服务节点(Server)。其中,客户端为发起IO的节点,负责从主节点获得各服务节点的定位(location)信息,并将读写(IO)请求送至相应的服务节点。主节点负责各服务节点的管理、虚拟机块设备的元信息(metainformation)等。服务节点可以有多个,负责IO流的持久化,提供前端IO读写服务,服务节点可以写三份或者通过Raft提供多份,保证数据安全性。实际应用中,上述分布式存储***可通过由相互耦合的多台物理机组成的集群实现,客户端、主节点以及服务节点分别可以通过一台或多台物理机来实现。比如,主节点可以由多台机器通过Paxos组提供高可用服务。
实际应用中,本申请的上述分布式存储***可以通过由多个相互耦合的物理机组成的集群实现。具体来讲,上述客户端、主节点、以及各服务节点分别可以通过集群中的一台或多台相互耦合的物理机实现。
相关技术中,TCP协议的TCP单链接内请求保序,不仅局限在单个链接上,而且在保序的同时会造成两个通信节点间性能受到限制。而对于分布式存储来说,不仅需要多机多链接提供服务,而且需要具备高性能、高可用性,这就需要单个存储设备的性能可以压满网卡的硬件极限,例如物理机挂载了两张网卡,每张是10G/b,那么单个物理机的性能最大吞吐需要能做到20G/b,把这两张网卡都压满,以使得分布式存储在保证其存储节点间通信网络顺序的同时具备高性能、高可用性。由此可知,TCP协议的单链接内请求保序并不适用于分布式存储。无法保证分布式存储的各存储内部的网络顺序。
针对上述问题,本申请提出了如下技术方案,在保证分布式存储***中各节点通信网络顺序的同时,满足其高性能的需求。
下面对本申请技术方案的实现方式进行说明。
一种分布式***的通信方法,可通过分布式***的主节点来实现,如图2所示,可以包括:
步骤201,主节点接收来自客户端的打开虚拟机块设备的请求;
步骤202,将所述虚拟机块设备的设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成用于代表当前会话的全局版本号;
步骤203,将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端,以便所述客户端利用所述全局版本号与相应的服务节点建立会话。
本申请中,全局版本号(BaseVersion)包括两部分:管理者版本号(MasterVersion)和设备打开版本号(OpenVersion)。全局版本号是由主节点产生的版本号,添加在IO流请求与控制流请求,通过一定规则可以过滤掉网络中延迟滞后的请求。一种实现方式中,全局版本号可以针对每个虚拟机块设备进行配置,换言之,可以针对不同过的虚拟机块设备设置不同的全局版本号。每个虚拟机块设备都可以具有与之对应的全局版本号。
比如,在linux***下,全局版本号可以是一个Uint64的整数,可以被拆分为高32位的管理者版本号、低32位的设备打开版本号。即,全局版本号可以表示为:|MasterVersion(Uint32)|OpenVersion(Uint32)|。
其中,管理者版本号是由主节点产生的,当主节点发生机器切换或主节点重选举时管理者版本号递增。为了避免主节点发生重启后管理者版本号丢失,主节点可以将管理者版本号持久化在本地或共享文件中。一种实现方式中,管理者版本号可以持久化在主节点的头部数据中。当主节点需要迁移到新的物理机时,新的物理机在成为主节点之前会把管理者版本号自增持久化,同时通知其他的物理机更新。这里,管理者版本号主要是为了保证主节点在发生故障时通过递增的方式升级,从而解决分布式存储***中主节点故障时的网络乱序问题,同时可以保证分布式存储***中主节点的高可用、高性能。
其中,设备打开版本号在每次虚拟机块设备被重新打开后会在内存中进行递增。由于内存速度快,持久化需要写磁盘会慢很多,因此,设备打开版本号的产生不需要进行持久化,以确保分布式存储***的高性能和高可用性。具体来讲,在虚拟机块设备打开的过程中,打开虚拟机块设备的请求由客户端发送到主节点,主节点收到该请求后对相应虚拟机块设备的设备打开版本号在内存中进行递增,由于设备打开版本号是全局版本号的低32号,此时全局版本号也会发生增长。如此,可以通过每次建立新会话递增全局版本号中设备打开版本号的方式解决分布式存储***中主节点、服务节点以及客户端之间通信网络乱序的问题,同时保证分布式存储***的高可用、高性能。
在上述图2所示的通信方法中,还可以包括:所述主节点需要迁移到新的物理机时,在所述新的物理机启用为主节点之前,将所述管理者版本号递增,并持久化到本地或共享文件中,同时将递增后的所述管理者版本号同步到其他物理机。这里,其他物理机是指除所述新的物理机之外可启用为所述主节点的物理机。
一种实现方式中,主节点是分布式***的管理者,一般由多个物理机以主备的形式组成,以具备高可用的特性。在主节点发生故障的情况下,需要选举出新的物理机作为主节点(即主节点从一台物理机切换到另一台物理机),在该新的物理机成为主节点之前,该新的物理机将管理者版本号在当前值的基础上递增,持久化在本地或者共享文件中,同时把递增后的管理者版本号同步给其他物理机,这之后该新的物理机才作为主节点进行启用。换言之,只有管理者版本号升级成功后,新的物理机才可作为主节点进行服务,以此来保证,在主节点发生主备切换的时候管理者版本号全局递增。
例如,可以使用三个物理机组成主节点,其中,只有当前选为主节点的物理机提供服务,当该物理机发生故障的时候,将从其余两个物理机中选择一个作为主节点,以此来解决单机故障问题。在此情况下,在即将成为主节点的物理机在成为主节点之前先递增管理者版本号的值,并持久化在本地或者共享文件中,同时会把递增后的管理者版本号同步给除该物理机之外的其他两台物理机,这之后,该物理机作为新的主节点进行启用,以此来保证主节点在执行主备切换时,管理者版本号的全局递增。
在上述图2所示的通信方法中,所述将所述全局版本号与对于所述虚拟机块设备的服务节点定位信息返回给所述客户端之后,还可以包括:主节点接收来自所述服务节点的会话消息,所述会话消息携带客户端提供给所述服务节点的全局版本号;主节点将所述会话消息携带的全局版本号与本地的全局版本号比较以校验所述会话消息是否过期,在所述会话消息携带的全局版本号不小于本地的全局版本号时,向所述服务节点返回校验通过信息。
实际应用中,由于服务节点需要向主节点持久化该次会话的全局版本号,可能网络中乱序的老版本请求(即对于老的全局版本号的请求)会在新版本(即新的全局版本号)成功后到达主节点,该场景下主节点需要校验请求中的全局版本号是否有效。这里需要注意的是,全局版本号在主节点的全局唯一递增,可以保证不会出现新版本回退的场景。这里,服务节点向主节点持久化该次会话的全局版本号时,可以包括:主节点将该条记录(比如,服务节点发过来的会话信息)存储在磁盘或者共享文件上。其中,该会话信息可以包括:服务节点的IP、数据文件的会话ID(session ID)、以及全局版本号。
实际应用中,新启用为主节点的物理机,在收到请求(比如,来自服务节点的会话消息)后会先校验该请求中携带的全局版本号是否大于本地的全局版本号,如果该请求中携带的全局版本号不大于本地的全局版本号则拒绝该请求,如果该请求中携带的全局版本号大于本地的全局版本号则接受该请求并进行后续处理。如此,通过比较全局版本号校验该请求是否过期,可确保主节点所处理的请求都是合法的。
这里,在主节点发生切换或者故障的场景下,管理者版本号会增长,此时已经建立的会话不会受到影响,设备打开版本号在内存中会从0开始,管理者版本号+设备打开版本号的严格递增保证下次会话建立请求的有效性,如果此时来自服务节点的老版本请求(对应旧的全局版本号)到主节点尝试进行创建或者删除操作时,由于主节点侧的全局版本号已递增,此时该老版本请求会失败。如此,通过全局版本号可排除来自服务节点的失效请求,从而解决了服务节点多机网络问题的乱序问题。
在上述图2所示的通信方法中,将所述全局版本号与对于所述虚拟机块设备的服务节点定位信息返回给所述客户端之后,还可以包括:接收来自客户端的查看所述虚拟机块设备的服务节点状态的请求;查询所述服务节点定位信息,在所述服务节点定位信息失效时,将所述设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成新的全局版本号;将所述新的全局版本号以及新的服务节点定位信息返回给所述客户端。
上述图2所示分布式***的通信方法中,主节点的数据保序主要通过全局版本号解决,在故障场景下通过升级管理者版本号解决此场景下排除网络中乱序的请求,建立会话的过程中通过管理者版本号和设备打开版本号的结合排除网络中乱序的请求,从而解决分布式存储***中各节点之间网络乱序的问题,同时避免数据不被写乱,保证分布式存储***的高可用、高性能。
比如,新会话建立之前,全局版本号是:master version 2+open version 3,新会话建立过程中全局版本号递增为:master version 3+open version 3,那么即使使用master version 2+open version 3的请求在新会话建立过程中或新会话建立完成之后发送到了主节点,主节点也会拒绝该请求,以避免这些无效的请求将数据写坏。
举例来说,服务节点a要更新会话a,但是超时,此时发生了服务节点切换,客户端与服务节点b建立了会话b,且该会话b被成功持久化,这时网络中服务节点a的请求到了主节点,持久化了这个虚拟机块设备的会话信息。这种情况数据就会被写乱。本申请的上述方案中,客户端与服务节点b建立会话b的过程中,主节点将全局版本号递增,这之后,服务节点a请求到了主节点,主节点也会拒绝该请求,从而避免数据被写乱。
另一种分布式***的通信方法,可通过分布式***的客户端实现,如图3所示,该通信方法可以包括:
步骤301,客户端向主节点发送打开虚拟机块设备的请求;
步骤302,客户端接收所述主节点返回的服务节点定位信息和用于代表当前会话的全局版本号,根据所述服务节点定位信息向相应的服务节点发送会话建立请求,所述会话建立请求携带所述全局版本号,以便与所述服务节点建立会话关系;
其中,所述全局版本号包括设备打开版本号和管理者版本号,所述设备打开版本号为所述主节点在收到所述打开虚拟机块设备的请求后递增的设备打开版本号。
实际应用中,会话建立时客户端可以将全局版本号存储在内存中。
在上述图3所示的通信方法中,根据所述服务节点定位信息向相应的服务节点发送会话建立请求之后,还可以包括:接收所述服务节点返回的会话建立成功的消息,将请求序列号重新从0开始递增;向所述服务节点发送读写IO请求时,在上一次IO请求的所述请求序列号的基础上递增以得到本次IO请求的请求序列号,并在本次IO请求中携带所述全局版本号以及所述本次IO请求的请求序列号。这样,IO流数数据的保序通过全局版本号和请求序列号同时来解决,以保证分布式存储***对IO流的处理性能比较高。
本申请中,请求序列号适用于IO请求。请求序列号可以由客户端在内存中生成,在单次会话中请求序列号严格递增。如此,在高性能的分布式存储中,通过全局版本号与请求序列号的结合,可以在会话建立起来后,没有发生故障等因素导致服务不可用的场景下,IO流处理过程中客户端不需要跟主节点通信,只与服务节点通信即可。
这里,当客户端发生Crash或者网络不通的情况下,新的客户端起来会尝试建立会话,新的会话下全局版本号会递增到新的值,此时请求序列号在内存中会从0开始,全局版本号+请求序列号依旧可以唯一表示一个会话下的一个IO请求。具体的,每次会话建立成功之后,请求序列号都会在客户端的内存中从0自增。这里的自增是指每次“+1”的递增,比如,可以表示为:RequestSeq=RequestSeq+1。
这里,在客户端发生进程重启或迁移的场景中,请求序列号会从0开始,此时通过将请求序列号与全局版本号一起使用,可以排除网络中乱序的IO请求。
本申请中,在单次会话中请求序列号严格递增是指在网络正常时单次会话下请求序列号在每次产生IO请求时自增。比如,先产生三个IO请求,那么这三个IO请求的请求序列号分别为:1、2、3,之后再有100个IO请求,那么这100个IO请求的请求序列号即为4~103。如果网络超时,IO请求的请求序列号将保持不变继续重试。如果服务节点向客户返回了明确的错误消息,请求序列号更新到最新。
这里,可以使用原子变量或者分区等方式实现请求序列号的自增,以保证单次会话中请求序列号的严格递增。
这里,请求序列号在客户端内存中维护,每次发送IO请求时通过自增操作获得当前的请求序列号,添加在请求中。具体来讲,客户端发出每个IO请求之前,由客户端产生请求序列号并填充到IO请求中,服务节点在收到该IO请求后,利用其中的请求序列号进行窗口校验以检查该IO请求是否有效,如果该IO请求有效则服务节点会继续处理该IO请求,如果该请求已失效则服务节点会将该IO请求直接丢弃。
在上述图3所示的通信方法中,所述根据所述服务节点定位信息向相应的服务节点发送会话建立请求之后,还可以包括:接收来自所述服务节点的会话建立失败消息或IO请求失败消息,向主节点发送查看所述服务节点状态的请求到主节点;接收所述主节点返回的新服务节点定位信息以及新的全局版本号。
实际应用中,当服务节点发生故障时,由于会话的失败,客户端会尝试与主节点建立新的会话,在该新会话的建立过程中设备打开版本号递增,相应的全局版本号整体递增,通过该递增之后的全局版本号可以唯一的代表该新会话,客户端完成该新会话的建立之后,发送新的IO请求(该新的IO请求使用递增之后的全局版本号,且其请求序列号重新从0开始)到新的服务节点即可恢复服务。此时,网络中飞着的IO请求(即使用递增之前全局版本号的IO请求)即被视为是无效的,为避免这些IO请求把虚拟机块设备中的数据写坏,新的服务节点通过对比全局版本号将这些IO请求拒绝掉,以避免这些无效的请求将数据写坏。
再一种分布式***的通信方法,可通过分布式***的客户端实现,如图4所示,该通信方法可以包括:
步骤401,服务节点接收来自客户端的会话建立请求,所述会话建立请求携带全局版本号;
步骤402,服务节点向主节点发送会话消息,所述会话消息携带所述全局版本号;
步骤403,服务节点在接收到所述主节点返回的校验通过信息时,向所述客户端返回会话建立成功的消息;
其中,所述全局版本号包括设备打开版本号和管理者版本号,所述设备打开版本号为所述主节点在收到所述客户端的打开虚拟机块设备的请求后递增的设备打开版本号。
实际应用中,会话建立时服务节点也会存全局版本号在内存中。
在图4所示的通信方法中,还可以包括:在接收到所述主节点返回的校验不通过信息时,向所述客户端返回会话建立失败的消息。
在图4所示的通信方法中,向所述客户端返回会话建立成功的消息之后,还可以包括:服务节点接收来自所述客户端的IO请求,所述IO请求携带所述全局版本号以及请求序列号;服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效;在所述IO请求无效时,服务节点拒绝所述IO请求,向所述客户端返回IO请求失败的信息。具体来讲,客户端发出每个IO请求之前,由客户端产生请求序列号并填充到IO请求中,服务节点在收到该IO请求后,利用IO请求中的请求序列号进行窗口校验以检查该IO请求是否有效,如果该IO请求有效则继续处理该IO请求,如果该请求已失效则直接丢弃。
在图4所示的通信方法中,还可以包括:服务节点在内存中配置总位数为n的一组窗口,所述窗口的位置相对独立,且每个窗口内存储该当前有效的请求序列号,所述当前有效的请求序列号为所述窗口处理过的最大请求序列号,n不小于相应虚拟机块设备的最大请求并发数。
实际应用中,服务节点可以维护总位数为n的一组窗口,该组窗口包括n个窗口,每个窗口的位置相对独立,且每个窗口内存储该窗口当前有效的请求序列号(即该窗口处理过的最大请求序列号)。其中,n为预先设定的固定值,可以根据最大请求并发数确定。实际应用中,该窗口存放在服务节点的内存中。上述方法中,服务节点的窗口不同于TCP的滑动窗口,由于每个窗口位置相对独立,在某个窗口位的请求出现问题时其他窗口位仍可继续使用,可避免因某个窗口位的请求出现问题而导致整个传输过程受影响。比如,第5位的窗口请求在服务节点端出现了问题,这时并不影响整个传输过程,其他窗口位置可以继续使用。这样,可以在排除掉网络过时请求的同时,较好的满足分布式存储***对高性能的需求。
这里,窗口的总位数n的大小需要大于IO请求并发数,以便满足分布式存储***对高性能的需求。实际应用中,该窗口的总位数n可以是固定值,比如,n可以固定取为1024。一种实现方式中,窗口的总位数n可以根据相应虚拟机块设备支持的最大请求并发数确定。较佳的,n的值一般是最大请求并发数的2倍以上。比如某个虚拟机块设备的最大请求并发数是100,那负责该虚拟机块设备的服务节点可以将自己的窗口总位数n设置为400。
图4所示的通信方法中,所述服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效,可以包括:利用所述总位数为n的一组窗口对所述IO请求携带的请求序列号进行窗口校验,以检查所述IO请求是否有效。具体的,所述进行窗口校验以检查所述IO请求是否有效,可以包括:通过哈希算法将所述IO请求的请求序列号定位到所述一组窗口中的一个窗口;比较所述IO请求的请求序列号与所定位窗口内当前有效的请求序列号,如果所述IO请求的请求序列号小于所定位窗口内当前有效的请求序列号,则所述IO请求无效。
一种实现方式中,服务节点处理IO请求的过程可以是:接收来自客户端的IO请求,通过哈希(hash)算法将该IO请求使用的请求序列号定位到一个窗口,比较该IO请求使用的请求序列号与该位置的窗口内当前有效的请求序列号(即该窗口处理过的最大请求序列号),如果该IO请求使用的请求序列号小于该位置的窗口内当前有效的请求序列号,则说明该IO请求已经失效,丢弃掉即可;如果该IO请求使用的请求序列号不小于该位置的窗口内当前有效的请求序列号,则说明该IO请求有效,继续处理该IO请求。
一种实现方式中,通过哈希(hash)算法将该IO请求使用的请求序列号定位到一个窗口,可以包括:通过“请求序列号%窗口总位数(即n)”计算IO请求中请求序列号对应的窗口位置。比如,窗口总位数为4(即n为4),当前IO请求的请求序列号是10,10%4=2,那么,该请求序列号对应第二位窗口,即将该请求序列号定位到第二位窗口上。
比如,服务节点的窗口可以配置为如下:|0|1|2|3|4|....|n-1|n|。n为窗口总位数,会话建立时所有位置的窗口的取值初始化为0,在会话建立完成处理过IO请求之后,该位置的窗口内存放其处理过的最大请求序列号,该窗口的取值可以表示相应窗口下处理过程的最大请求序列号,该最大请求序列号即为该窗口内当前有效的请求序列号。
比如,当前接收到的IO请求的请求序列号为10,定位到第2位窗口,第2位窗口内当前存放的有效请求序列号为8,IO请求的请求序列号为10大于第2位窗口内当前存放的有效请求序列号8,那么该IO请求有效,服务节点将继续处理该IO请求,同时将更新第2位窗口内存放的有效请求序列号为10。
一种实现方式中,对于请求序列号(RequestSeq),在服务节点端可以设置1024位的一组窗口,请求序列号通过对(即请求序列号%1024)获得窗口的位置,与窗口内当前的请求序列号进行对比,大于当前窗口的请求序列号才会被处理。由于整个IO流的过程中都是在客户端的内存与服务节点的内存进行操作,可以保证分布式存储***的各物理机具有较高的性能。上述方法中,单个窗口位的阻塞并不影响整体的性能,每个窗口位可以被高于当前请求序列号的请求抢占。在客户端对于请求超时,会进行重试,如收到序列号过期错误,会更新请求序列号到最新,重试请求。
通过图4所示分布式***的通信方法,通过全局版本号解决服务节点在控制流处理中的网络乱序问题,通过全局版本号+请求序列号解决服务节点在IO流处理中的网络乱序问题。在解决这些网络乱序问题的同时,还可以避免数据写坏,保证分布式存储***的高性能和高可用性。
举例来说,客户端在物理机a上发生断网时迁移到了物理机b上,这时物理机a上可能还存在客户端a,物理机a上的客户端可能仍在发送IO请求,其IO请求的请求序列号为当前值。但是,当前有用的是物理机b上的客户端了。在迁移之后,物理机b上的客户端在发送IO请求时将该IO请求的请求序列号在所述当前值的基础上递增,并使用该递增之后的请求序列号发出IO请求,此时,如果服务节点接收到物理机a上客户端的IO请求和物理机b上客户端的IO请求,将会仅处理物理机b上客户端发出的IO请求,而拒绝物理机a上客户端的IO请求,如此,通过全局版本号+请求序列号可以确保物理机b上客户端的IO请求成功,而物理机a上客户端的IO请求失败,从而避免物理机a上客户端的IO请求把数据写坏。
又一种分布式***的通信方法,通过分布式***实现,如图5所示,可以包括:
步骤501,客户端向主节点发送打开虚拟机块设备的请求;
步骤502,主节点将所述虚拟机块设备的设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成用于代表当前会话的全局版本号;
步骤503,主节点将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端,以便所述客户端利用所述全局版本号与相应的服务节点建立会话。
在图5所示的通信方法中,所述主节点将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端之后,还可以包括:客户端根据所述服务节点定位信息向相应的服务节点发送会话建立请求,所述会话建立请求携带所述全局版本号;服务节点接收所述会话建立请求,向主节点发送会话消息,所述会话消息携带所述全局版本号;所述主节点将所述会话消息携带的全局版本号与本地的全局版本号比较以校验所述会话消息是否过期,在所述会话消息携带的全局版本号不小于本地的全局版本号时,向所述服务节点返回校验通过信息;服务节点在接收到所述主节点返回的校验通过信息时,向所述客户端返回会话建立成功的消息。
在图5所示的通信方法中,还可以包括:所述主节点需要迁移到新的物理机时,在所述新的物理机启用为主节点之前,将所述管理者版本号递增,并持久化到本地或共享文件中,同时将递增后的所述管理者版本号同步到其他物理机。
在图5所示的通信方法中,还可以包括:客户端接收所述服务节点返回的会话建立成功的消息,将请求序列号重新从0开始递增;客户端向所述服务节点发送读写IO请求时,在上一次IO请求的所述请求序列号的基础上递增以得到本次IO请求的请求序列号,并在本次IO请求中携带所述全局版本号以及所述本次IO请求的请求序列号。
在图5所示的通信方法中,还可以包括:服务节点接收来自所述客户端的IO请求,所述IO请求携带所述全局版本号以及请求序列号;服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效;在所述IO请求无效时,服务节点拒绝所述IO请求,向所述客户端返回IO请求失败的信息。
在图5所示的通信方法中,还可以包括:服务节点在内存中配置总位数为n的一组窗口,所述窗口的位置相对独立,且每个窗口内存储该当前有效的请求序列号,所述当前有效的请求序列号为所述窗口处理过的最大请求序列号,n不小于相应虚拟机块设备的最大请求并发数;
所述服务节点根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效,包括:利用所述总位数为n的一组窗口对所述IO请求携带的请求序列号进行窗口校验,以检查所述IO请求是否有效。
在图5所示的通信方法中,还可以包括:客户端接收来自所述服务节点的会话建立失败消息或IO请求失败消息,向主节点发送查看所述虚拟机块设备的服务节点状态的请求;主节点接收来自客户端的查看服务节点状态的请求,查询所述服务节点定位信息,在所述服务节点定位信息失效时,将所述设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成新的全局版本号;将所述新的全局版本号以及新的服务节点定位信息返回给所述客户端。
图5所示分布式***的通信方法中其他技术细节可参照上文各节点侧的通信方法,不再赘述。
下面以两个实例来详细说明本申请的通信方法。
实例1
如图6所示,分布式***通信过程中控制流处理的示例性流程可以包括:
步骤601,客户端向主节点发送打开虚拟机块设备的请求,以获取该虚拟机块设备的当前全局版本号;
步骤602,主节点接收客户端发送的打开虚拟机块设备的请求,从本地或共享文件中查找到该虚拟机块设备的管理者版本号,并将该虚拟机块设备的设备打开版本号进行递增,基于该管理者版本号与递增后的设备打开版本号生成代表当前会话的全局版本号,并向客户端返回响应消息,该响应消息携带该全局版本号和对应该虚拟机块设备的服务节点定位(Location)信息;
实际应用中,主节点会管理当前虚拟机块设备的服务节点是否已经在服务状态、以及当前虚拟机块设备在哪个服务节点提供服务(比如,为虚拟机块设备服务的这些服务节点的地址)等与服务节点相关的Location信息,客户端在打开虚拟机块设备的过程中需要向主节点获取当前虚拟机块设备在哪个服务节点以及这些服务节点的当前状态(即服务节点的Location信息),根据该Location信息客户端会选择负责为当前虚拟机块设备服务且正在服务状态的服务节点,向该服务节点发送会话请求。
在此过程中,主节点会按照上面的规则生成全局版本号给客户端。实际应用中,客户端一般通过TCP网络,向主节点发送TCP网络请求(即上述打开虚拟机块设备的请求为TCP网络请求)来获取信息。
步骤603,客户端根据主节点返回的服务节点Location信息,向相应的服务节点发送会话建立请求,所述会话建立请求携带上述全局版本号,尝试与该服务节点建立长期会话关系;
步骤604,服务节点接收来自客户端的会话建立请求,获取客户端的当前全局版本号,并向主节点发送会话消息,该会话消息携带客户端的当前全局版本号,以校验全局版本号是否合理;
步骤605,主节点接收服务节点发送的会话消息,对其中携带的全局版本号进行校验,即将该会话消息中的全局版本号与本地或共享文件中的全局版本号进行比较,如果该会话消息中的全局版本号不小于本地或共享文件中的全局版本号则校验通过,向服务节点返回校验通过信息;
步骤606,服务节点接收主节点返回的校验通过信息并进行记录(比如,记录校验通过的全局版本号),校验通过后,服务节点向客户端返回会话建立成功的消息。
在上述控制流的处理流程中,全局版本号代表本次会话建立的唯一表示。
在上述控制流程的处理过程中,考虑到各个节点间的通信存在不可靠性,还可以包含如下各节点发生请求失败或者超时的场景。
如果客户端向服务节点请求会话建立失败时,服务节点状态可能已经是建立会话状态,在该场景下,客户端重新向主节点获取该服务节点的Location信息。比如,客户端可以发送请求到主节点以查看当前服务节点的状态,主节点在接收到该请求之后,查看相应的服务节点,如果该服务节点的Location信息已经失效(实际应用中,服务节点的Location信息会在一定时间内失效,比如10s中内主节点发现服务节点处于不可服务状态),主节点会返回新的服务节点地址给客户端,同时将设备打开版本号递增并将该递增之后的新全局版本号同时返回给客户端,以保证全局版本号的递增。客户端使用该新全局版本号与新的服务节点建立新会话。这样,可以通过该递增后的新全局版本号可排除掉较低版本的全局版本号的会话,确保在新会话建立时老会话即刻失效。
实例2
分布式***通过控制流处理在客户端与服务节点建立一个会话关系之后,可以执行IO流的处理。如图7所示,分布式***通信过程中IO流处理的示例性流程可以包括:
步骤701,客户端产生请求序列号并填充到IO请求,将所述IO请求发送给服务节点,该IO请求还携带代表当前会话的全局版本号;
步骤702,服务节点接收所述IO请求,利用其中的请求序列号进行窗口校验以检查该IO请求是否有效,如果该IO请求有效则服务节点会继续处理该IO请求,如果该IO请求已失效则服务节点会将该IO请求直接丢弃,向客户端返回IO请求失败的消息。
该示例性流程中,客户端产生请求序列号的过程、服务节点利用其中的请求序列号进行窗口校验的过程分别可参照上文的相关记载,不再赘述。
该示例性流程中,如果有客户端与服务节点间发生网络故障等原因,导致客户端无法和服务节点通信,该场景下,客户端会发现自己的IO请求失败,在这个过程中,客户端会发送请求到主节点以查看当前服务节点的状态,主节点在接收到该请求之后,查看相应的服务节点,如果该服务节点的Location信息已经失效(实际应用中,服务节点的Location信息会在一定时间内失效,比如10s中内主节点发现服务节点处于不可服务状态),主节点会返回新的服务节点地址给客户端,同时将设备打开版本号递增并将该递增之后的新全局版本号同时返回给客户端,以保证全局版本号的递增。客户端使用该递增后的新全局版本号与新的服务节点建立新会话,此时,通过该递增后的新全局版本号可排除掉较低版本的全局版本号的会话,确保在新会话建立时老会话即刻失效。客户端重试该IO请求时,将会在新会话下进行重试。
需要说明的是,上述各实例的执行流程仅为示例性实现方式。实际应用中,可基于应用场景的不同或应用对象的不同,调整上述流程中各步骤的具体实现方式、以及各步骤的执行顺序。
一种分布式***的通信装置,可应用于分布式***的主节点,可以包括:存储有计算机程序的存储器;处理器,配置为读取所述计算机程序以执行图2所示分布式***通信方法的步骤。
一种分布式***的通信装置,可应用于分布式***的客户端,可以包括:存储有计算机程序的存储器;处理器,配置为读取所述计算机程序以执行图3所示分布式***通信方法的步骤。
一种分布式***的通信装置,可应用于分布式***的服务节点,可以包括:存储有计算机程序的存储器;处理器,配置为读取所述计算机程序以执行图4所示分布式***通信方法的步骤。
需要说明的是,本实施例上述各通信装置的上述结构仅为其基础架构。实际应用中,该延迟加载装置还可包括其他部件,比如,总线、通信电路、输入部件、输出部件等。当然,除此之外,上述延迟加载装置还可包括其他部件。
本实施例中上述各通信装置的具体技术细节可参照上述方法部分。
一种分布式***,包括:客户端、主节点以及服务节点;
所述客户端,用于向主节点发送打开虚拟机块设备的请求;
所述主节点,用于接收来自客户端的打开虚拟机块设备的请求,将所述虚拟机块设备的设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成用于代表当前会话的全局版本号,将所述全局版本号与对应所述虚拟机块设备的服务节点定位信息返回给所述客户端,以便所述客户端利用所述全局版本号与相应的服务节点建立会话。
其中,所述客户端,还可以用于根据所述服务节点定位信息向相应的服务节点发送会话建立请求,所述会话建立请求携带所述全局版本号,以便与所述服务节点建立会话关系;服务节点,可以用于接收来自客户端的会话建立请求,所述会话建立请求携带全局版本号;向主节点发送会话消息,所述会话消息携带所述全局版本号;在接收到所述主节点返回的校验通过信息时,向所述客户端返回会话建立成功的消息;所述主节点,还可以用于将所述会话消息携带的全局版本号与本地的全局版本号比较以校验所述会话消息是否过期,在所述会话消息携带的全局版本号不小于本地的全局版本号时,向所述服务节点返回校验通过信息。
其中,所述客户端,还可以用于在接收到所述服务节点返回的会话建立成功的消息,将请求序列号重新从0开始递增;以及,还用于向所述服务节点发送读写IO请求时,在上一次IO请求的所述请求序列号的基础上递增以得到本次IO请求的请求序列号,并在本次IO请求中携带所述全局版本号以及所述本次IO请求的请求序列号。
其中,所述服务节点,还可以用于接收来自所述客户端的IO请求,所述IO请求携带所述全局版本号以及请求序列号;根据所述IO请求携带的请求序列号,进行窗口校验以检查所述IO请求是否有效;在所述IO请求无效时,拒绝所述IO请求,向所述客户端返回IO请求失败的信息。
具体的,所述服务节点,还可以用于在内存中配置总位数为n的一组窗口,所述窗口的位置相对独立,且每个窗口内存储该当前有效的请求序列号,所述当前有效的请求序列号为所述窗口处理过的最大请求序列号,n不小于相应虚拟机块设备的最大请求并发数;以及,具体可以用于利用所述总位数为n的一组窗口对所述IO请求携带的请求序列号进行窗口校验,以检查所述IO请求是否有效。
其中,所述客户端,还可以用于接收来自所述服务节点的会话建立失败消息或IO请求失败消息,向主节点发送查看所述虚拟机块设备的服务节点状态的请求;所述主节点,还可以用于接收来自客户端的查看服务节点状态的请求,查询所述服务节点定位信息,在所述服务节点定位信息失效时,将所述设备打开版本号递增,基于该递增后的设备打开版本号以及已有的管理者版本号生成新的全局版本号;将所述新的全局版本号以及新的服务节点定位信息返回给所述客户端。
其中,所述主节点,还可以用于需要迁移到新的物理机时,在所述新的物理机启用为主节点之前,将所述管理者版本号递增,并持久化到本地或共享文件中,同时将递增后的所述管理者版本号同步到其他物理机。
本实施例中上述分布式***的具体技术细节可参照上述方法部分。
一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一种分布式***的通信方法的步骤。
一种实现方式中,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述图2所示分布式***的通信方法分布式***的通信方法的步骤。该计算机可读存储介质可通过分布式***的主节点实现,该主节点可通过物理机或其集群实现。
另一种实现方式中,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述图3所示分布式***的通信方法的步骤。该计算机可读存储介质可通过分布式***的客户端实现,该客户端可通过物理机或其集群实现。
另一种实现方式中,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述图4所示分布式***的通信方法的步骤。该计算机可读存储介质可通过分布式***的服务节点实现,该服务节点通过物理机或其集群实现。
另一种实现方式中,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述图5所示分布式***的通信方法的步骤。该计算机可读存储介质可通过分布式***实现,该分布式***可物理机集群实现。
本实施例中上述计算机可读存储介质的具体技术细节可参照上述方法部分。
需要说明的是,本申请的技术方案可适用于多种类型的虚拟机块设备。尤其可适用于可切分为多个子块的虚拟机块设备。具体来讲,该虚拟机块设备可以按照逻辑区块地址(LBA,Logical Block Address)切分为多个子块(segment),每个子块存放相应逻辑区块地址区间的数据块;每个子块包括多个数据文件,每个子块中的数据块会被分配到这些数据文件以进行保存。举例来说,该虚拟机块设备可以为如图8所示的日志结构块设备,该日志结构块设备包括N+1(N为不小于1的整数)个子块,每个子块包括X(X为不小于1的整数)个相对应的索引文件(Index file)及数据文件(Data file),索引文件和数据文件分别可以是扁平化的日志文件(flat log file),索引文件用于存储因子块数据修改而产生的元数据(metadata),数据文件用于存储因子块数据修改而产生的数据(data)。除此之外,该虚拟机块设备还可以为其他类型。
实际应用中,本申请的技术方案不受语言限制,为了保证性能建议采用C、C++语言实现,在高性能的网络、服务器、磁盘物理环境中更能发挥优势。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件(例如处理器)完成,所述程序可以存储于计算机可读存储介质中,如只读存储器、磁盘或光盘等。可选地,上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地,上述实施例中的各模块/单元可以采用硬件的形式实现,例如通过集成电路来实现其相应功能,也可以采用软件功能模块的形式实现,例如通过处理器执行存储于存储器中的程序/指令来实现其相应功能。本申请不限制于任何特定形式的硬件和软件的结合。
以上显示和描述了本申请的基本原理和主要特征和本申请的优点。本申请不受上述实施例的限制,上述实施例和说明书中描述的只是说明本申请的原理,在不脱离本申请精神和范围的前提下,本申请还会有各种变化和改进,这些变化和改进都落入要求保护的本申请范围内。