故障应用副本处理方法、装置、计算机设备和存储介质
技术领域
本申请涉及计算机技术领域,特别是涉及一种故障应用副本处理方法、装置、计算机设备和存储介质。
背景技术
随着计算机技术的发展,出现了分布式系统,分布式系统是建立在网络之上的软件系统,分布式系统具有高度的内聚性和透明性。一般情况下,具有高可用要求的软件系统为提升系统的可用性会部署多个应用副本(应用副本为同样应用程序部署在不同的主机上)组成集群,表现为一个整体对外提供服务。当集群中的应用副本故障时,其他应用副本继续对外提供服务,以保证系统的高可用性。当应用副本故障时,目前常用的主要有两种处理方法,第一种是应用副本故障时表现为永久性故障,经过修复后无法重新加入到原来的集群中。第二种是故障应用副本在经过修复之后,能够再次加入到原来的集群中。
从实现的角度看,第二种方法首先从正常的应用副本中同步所有历史消息,在处理完所有的历史之后,再尝试加入到集群中,接收新消息。然而,目前的故障应用副本重加入集群的方法,故障应用副本为了追赶上正常的应用副本,需要花费较长的时间,从而导致了分布式系统的可用性降低。
发明内容
基于此,有必要针对上述技术问题,提供一种能够缩短故障应用副本重加入集群时间,提升分布式系统高可用性的故障应用副本处理方法、装置、计算机设备和存储介质。
一种故障应用副本处理方法,所述方法包括:
启用经过故障修复后的备应用副本,并确定所述备应用副本所在集群中当前正常运行的主应用副本;
确定在启用经过故障修复后的备应用副本时,所述主应用副本当前正在进行业务处理的第一消息;
获取接收时间在所述第一消息之后的第二消息,并查找接收时间在所述第一消息之前的历史消息;
根据所述历史消息对应的接收时间,依次对所述历史消息进行业务处理;
当所述历史消息处理完成后,根据所述第二消息的接收时间,依次对所述第二消息进行业务处理以使得本地的备应用副本重加入所述集群。
一种故障应用副本处理装置,所述装置包括:
启用模块,用于启用经过故障修复后的备应用副本,并确定所述备应用副本所在集群中当前正常运行的主应用副本;
确定模块,用于确定在启用经过故障修复后的备应用副本时,所述主应用副本当前正在进行业务处理的第一消息;
获取模块,用于获取接收时间在所述第一消息之后的第二消息,并查找接收时间在所述第一消息之前的历史消息;
处理模块,用于根据所述历史消息对应的接收时间,依次对所述历史消息进行业务处理;
处理模块还用于当所述历史消息处理完成后,根据所述第二消息的接收时间,依次对所述第二消息进行业务处理以使得本地的备应用副本重加入所述集群。
一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现以下步骤:
启用经过故障修复后的备应用副本,并确定所述备应用副本所在集群中当前正常运行的主应用副本;
确定在启用经过故障修复后的备应用副本时,所述主应用副本当前正在进行业务处理的第一消息;
获取接收时间在所述第一消息之后的第二消息,并查找接收时间在所述第一消息之前的历史消息;
根据所述历史消息对应的接收时间,依次对所述历史消息进行业务处理;
当所述历史消息处理完成后,根据所述第二消息的接收时间,依次对所述第二消息进行业务处理以使得本地的备应用副本重加入所述集群。
一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现以下步骤:
启用经过故障修复后的备应用副本,并确定所述备应用副本所在集群中当前正常运行的主应用副本;
确定在启用经过故障修复后的备应用副本时,所述主应用副本当前正在进行业务处理的第一消息;
获取接收时间在所述第一消息之后的第二消息,并查找接收时间在所述第一消息之前的历史消息;
根据所述历史消息对应的接收时间,依次对所述历史消息进行业务处理;
当所述历史消息处理完成后,根据所述第二消息的接收时间,依次对所述第二消息进行业务处理以使得本地的备应用副本重加入所述集群。
上述故障应用副本处理方法、装置、计算机设备和存储介质,将集群中的应用副本分为主应用副本和备应用副本,主应用副本负责对外提供服务,备应用副本作为备用应用副本。当应用副本发生故障时,首先对故障的应用副本进行修复作为备应用副本,进而确定主应用副本当前正在进行业务处理的第一消息,使得将本地与当前主应用副本的消息对齐,并从对齐处开始获取接收时间在第一消息之后第二消息,即新消息,同时获取接收时间在第一消息之前的历史消息,使得新消息的获取和历史消息的获取并行进行。依次处理获取到的历史消息和接收到的新消息,在历史消息处理完后再继续处理新消息,当缓存的新消息处理完之后,故障的应用副本则完成了重加入集群的过程。这样,故障应用副本和当前的主应用副本只需要进行一次消息对齐,使得网络延迟减少,且新消息的获取和历史消息的获取并行进行,缩短了故障应用副本的恢复时长,保证了故障应用副本重加入集群的及时性,进而提升了分布式系统的可用性。
附图说明
图1为一个实施例中故障应用副本处理方法的应用场景图;
图2为一个实施例中故障应用副本处理方法的流程示意图;
图3为一个实施例中故障应用副本处理方法的时序图;
图4为一个实施例中获取接收时间在第一消息之后的第二消息的步骤的流程示意图;
图5为一个实施例中故障应用副本处理装置的结构框图;
图6为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请提供的故障应用副本处理方法,可以应用于如图1所示的应用环境中。该应用环境包括一个主应用副本102和至少一个的备应用副本104,备应用副本104包括经过故障修复后的备应用副本,其中,主应用副本102通过网络与备应用副本104通过网络进行通信。其中,副本102和备应用副本104可以是相同的应用程序部署在不同的主机上。主应用副本102和备应用副本104可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。主应用副本102和备应用副本104还可以是服务器,服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
启用经过故障修复后的备应用副本104,备应用副本104确定备应用副本所在集群中当前正常运行的主应用副本102。备应用副本104确定在启用经过故障修复后的备应用副本104时,主应用副本102当前正在进行业务处理的第一消息。备应用副本104获取接收时间在第一消息之后的第二消息,并查找接收时间在第一消息之前的历史消息。备应用副本104根据历史消息对应的接收时间,依次对历史消息进行业务处理。当历史消息处理完成后,备应用副本104根据第二消息的接收时间,依次对第二消息进行业务处理以使得本地的备应用副本104重加入集群。
在一个实施例中,如图2所示,提供了一种故障应用副本处理方法,以该方法应用于图1中经过故障修复后的备应用副本104为例进行说明,包括以下步骤:
S202,启用经过故障修复后的备应用副本,并确定备应用副本所在集群中当前正常运行的主应用副本。
其中,应用副本是部署在不同主机上的相同的应用程序。具体地,分布式软件系统为提升系统的高可用性,通常会部署多个应用副本组成集群,作为一个整体对外提供服务。当集群中的应用副本发生故障时,其他副本继续对外提供服务,以保证系统的高可用性。应用副本通常有角色划分,当前对外提供服务的应用副本称为主应用副本,其他不对外提供服务的应用副本称为备应用副本。通常集群中可包括一个主应用副本和至少一个备应用副本。当应用副本副本故障时,及时对故障的应用副本进行修复,当故障的应用副本修复后,启用经过故障修复后的备应用副本,并根据故障的应用副本是主应用副本还是备应用副本,确定备应用副本所在集群中当前正常运行的主应用副本。
在一个实施例中,当主应用副本发生故障后,集群中的其中一个备应用副本可提升为主应用副本,继续对外提供服务,故障的原应用副本的角色自动变为备应用副本。当备应用副本发生故障时,仍然由原来的主应用副本对外提供服务。
在一个实施例中,当应用副本故障后,首先应该确认故障的类型,进而根据故障的类型进行相应的故障恢复。如果是应用副本对应的硬件设备导致的故障,则需要更换硬件设备。如果是应用父辈对应的软件故障,则需要进行软件修复。
S204,确定在启用经过故障修复后的备应用副本时,主应用副本当前正在进行业务处理的第一消息。
其中,业务处理是主应用副本在获取到对外服务的消息时,对获取到的消息按照对应的业务逻辑进行处理的过程。第一消息是修复后的备应用副本请求加入集群时,主应用副本当前正在进行业务处理的新消息。
具体地,故障的应用副本在完成修复后成为备应用副本,讲过修复后的备应用副本需要重新加入集群,以保证系统的高可用性。启用修复后的备应用副本,备应用副本可向当前正在运行的主应用副本发送消息对齐请求,基于消息对齐请求,可确定主应用副本当前正在进行业务处理的第一消息。
S206,获取接收时间在第一消息之后的第二消息,并查找接收时间在第一消息之前的历史消息。
其中,第二消息是主应用副本在第一消息对应的接收时间之后,从对外服务中新接收到的新消息。历史消息是主应用副本在第一消息对应的接收时间之前,从对外服务中接收到的消息。
具体地,修复后的备应用副本向当前正常运行的主应用副本发起查询消息处理进度请求,主应用副本在接收到请求后,向对应的备应用副本回复消息处理进度,确定第一消息,以使得修复后的备应用副本从该处理进度处开始接收第二消息,即新消息。同时,修复后的备应用副本可查找接收时间在第一消息之前的历史消息,以使得修复后的备应用副本和主应用副本保持一致。
在一个实施例中,经过修复后的备应用副本可从当前正常运行的主应用副本中获取历史消息,也可以从其他位置处获取,比如修复后的备应用副本可从对应的专用数据库或其他存储基础设施中获取历史消息。
S208,根据历史消息对应的接收时间,依次对历史消息进行业务处理。
具体地,集群中的主应用副本负责对外提供服务,同时接收外服务所产生的消息,每一个接收的消息都对应记录有消息的接收时间。因而,备应用副本从主应用副本中或者从其他的存储设备中获取历史消息,每一个历史消息也对应有相应的接收时间。备应用副本可根据历史消息对应的接收时间,依次对历史消息进行业务处理,以保证分布式软件系统的搞可用性。
S210,当历史消息处理完成后,根据第二消息的接收时间,依次对第二消息进行业务处理以使得本地的备应用副本重加入集群。
具体地,应用副本中的应用程序规定消息是按照接收消息的时间的先后顺序逐一进行处理的。因此,备应用副本获取到的第二消息,也就是新消息在历史消息未处理完之前,备应用副本会对新消息在本地进行缓存。只有当经过修复后的备应用副本获取的历史消息全部被处理完之后,备应用副本才会一次按照新消息的接收时间,依次对缓存的新消息进行业务处理,当缓存的新消息处理完成之后,表明本地的备应用副本重加入集群成功。
在一个实施例中,如图3所示,集群中包括一个主副本和多个备副本,主福本负责对外提供服务,备副本负责从主副本中备份数据,备份数据的实现过程可以是,当主副本从外服务中获取到新消息后,主副本将接受到的新消息复制给备副本,备副本在接收到主副本发送的新消息后,给主副本发送回复响应,以确定新消息的正常接收。当副本故障后,及时对故障的副本进行修复,修复后的副本重新以备副本的角色请求重新加入集群。启用修复后的备副本后,备副本首先向主副本发送查询消息处理进度请求,主副本在接收到备副本的请求后,向备副本回复消息处理进度,以实现消息处理进度的对齐。对齐消息处理进度后,备副本处消息处理进度对齐的位置开始接收新消息,并在本地进行缓存。此外,在接收新消息的同时,修复后的备副本向主副本发送历史消息请求,主副本在接收到请求后,向备副本发送历史消息。修复后的备副本依次对历史消息进行处理,历史消息处理完之后,再依次处理本地所缓存的新消息,在处理完缓存的新消息后,修复后的备副本重加入集群成功。本实施例中的主副本即主应用副本,备应用副本即备应用副本。
上述故障应用副本处理方法中,将集群中的应用副本分为主应用副本和备应用副本,主应用副本负责对外提供服务,备应用副本作为备用应用副本。当应用副本发生故障时,首先对故障的应用副本进行修复作为备应用副本,进而确定主应用副本当前正在进行业务处理的第一消息,使得将本地与当前主应用副本的消息对齐,并从对齐处开始获取接收时间在第一消息之后第二消息,即新消息,同时获取接收时间在第一消息之前的历史消息,使得新消息的获取和历史消息的获取并行进行。依次处理获取到的历史消息和接收到的新消息,在历史消息处理完后再继续处理新消息,当缓存的新消息处理完之后,故障的应用副本则完成了重加入集群的过程。这样,故障应用副本和当前的主应用副本只需要进行一次消息对齐,使得网络延迟减少,且新消息的获取和历史消息的获取并行进行,缩短了故障应用副本的恢复时长,保证了故障应用副本重加入集群的及时性,进而提升了分布式系统的可用性。
在一个实施例中,步骤S202,也就是启用经过故障修复后的备应用副本,并确定备应用副本所在集群中当前正常运行的主应用副本的步骤,具体包括:当主应用副本故障时,根据投票机制从集群中的至少一个备应用副本中筛选出票数最高的备应用副本作为集群中当前正常运行的主应用副本,故障的主应用副本在修复后作为备应用副本;当备应用副本故障时,修复后直接确定当前对应的主应用副本。
具体地,集群中发生故障的应用副本可以是主应用副本和备应用副本,各应用副本之间可相互通信,当发生故障的应用副本为主应用副本时,系统中的各备应用副本会发起投票,当任一备应用副本得到的票数超过所总票数的一半时,对应的备应用副本将提升为当前的主应用副本,故障的主应用副本在进行修复之后,可重新加入集群成为集群中的备应用副本。当发生的应用副本为备应用副本时,当前的主应用副本还是原来集群中的主应用副本,故障的备应用副本在进行修复之后,可直接确定当前对应的主应用副本,进而重新加入集群,。
上述实施例中,根据判断故障的应用副本为主应用副本还是备应用副本,对修复后的备应用副本重加入集群所需要确定的当前正常运行的主应用副本进行相应的确认,提升了当前主应用副本的确认效率和保证了准确性。
在一个实施例中,步骤S204,也就是确定在启用经过故障修复后的备应用副本时,主应用副本当前正在进行业务处理的第一消息的步骤,具体包括:获取消息查询请求,并将消息查询请求发送至主应用副本;根据消息查询请求,确定主应用副本中的消息所对应的消息标识;根据消息标识,确定在启用经过故障修复后的备应用副本时,主应用副本当前正在进行业务处理的第一消息。
其中,消息查询请求是备应用副本生成的查询消息处理情况的指令,用于本地备应用副本从主应用副本中查询消息的处理进度。消息标识是一种具有唯一标识消息的字符串,用于唯一确定各消息的身份。
具体地,修复后的备应用副本重新启用后,为了重新加入集群,看生成消息查询请求,并将消息查询请求发送至当前正常运行的主应用副本。主应用副本在接收到消息查询请求后,可根据消息查询请求确定主应用副本中的消息所对应的消息标识。进而备应用副本可根据消息标识,确定在启用经过故障修复后的备应用副本时,主应用副本当前正在进行业务处理的第一消息。
上述实施例中,通过向主应用副本发送消息查询请求,基于消息所对应的消息标识,查询主应用副本的消息处理进度,从而确定本地备应用副本从对应的位置开始接收新消息,这样,保证了备应用副本和主应用副本在消息处理进度上的一致性。
在一个实施例中,如图4所示,获取接收时间在第一消息之后的第二消息的步骤,具体包括:监测主应用副本接收第二消息的状态;当监测到主应用副本接收到第二消息时,获取复制消息请求,并将复制消息请求发送至主应用副本;根据复制消息请求,从主应用副本中获取接收时间在第一消息之后的第二消息。
其中,复制消息请求是备应用副本在监测到当前主应用副本接收到第二消息时所生成的请求指令,用于从主应用副本中获取第二消息。
具体地,主应用副本负责对外提供服务,实时接收外服务发送的消息。备应用副本可实时监测主应用副本接收第二消息的状态。当备应用副本监测到主应用副本接收到第二消息时,可生成复制消息请求,并将复制消息请求发送至主应用副本,主应用副本在接收到复制消息请求后,根据复制消息请求,在本地查找接收时间在第一消息之后的第二消息,并将第二消息发送给备应用消息。
上述实施例中,通过实时监测主应用副本接收第二消息,即新消息的状态,可快速确定主应用副本在什么时间接收了新消息,从而备应用副本可及时向主应用副本发送复制消息请求,以使得备应用副本快速从主应用副本中获得新消息,确保了消息获取的即时性,从而进一步提升分布式系统的可用性。
在一个实施例中,查找接收时间在第一消息之前的历史消息的步骤,具体包括:获取历史消息请求,并将历史消息请求发送至主应用副本;历史消息请求包括本地的消息信息;根据历史消息请求的消息信息,确定本地缓存的最新的消息所对应的第一时间;查找接收时间在第一消息之前、且在第一时间之后的历史消息。
其中,历史消息请求是备应用副本生成的历史消息获取指令,用于从主应用副本中获取历史消息。
具体地,当前主应用副本中存储有历史消息,备应用副本可从当前主应用副本中获取历史消息。备应用副本可生成历史消息请求,并将历史消息请求发送至主应用副本,主应用副本在接收在历史消息请求后,根据历史消息中携带的本地备应用副本的消息信息,确定本地缓存的最新的消息所对应的第一时间,进而在主应用副本中查询接收时间在第一消息之前、且在第一时间之后的历史消息。主应用副本将查询到的满足条件的历史消息发送至修复后的备应用副本。
上述实施例中,通过历史消息请求说携带的消息信息,可确定修复后的备应用副本在未发生故障时,从主应用副本中获取消息的情况。根据未发生故障之前获取消息的情况,根据之前获取消息的情况,确定从当前正常运行的主应用副本中获取本地未缓存过的历史消息,这样,提高了历史消息获取的效率。
在一个实施例中,历史消息从主应用副本查找,查找接收时间在第一消息之前、且在第一时间之后的历史消息的步骤,具体包括:判断本地和主应用副本各自对应的物理环境;当本地和主应用副本部署在同一台主机时,根据进程间的通信机制从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息;当本地和主应用副本部署在不同一台主机时,根据网络通信从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息。
具体地,修复后的备应用副本可部署在同一台主机上,也可部署在不同主机上,当修复后的备应用副本请求重新加入集群时,备应用副本可判断本地和主应用副本各自对应的物理环境。当本地和主应用副本部署在同一台主机时,备应用副本可根据进程间的通信机制将本地与当前主应用副本进行连接通信,通信通道建立后,备应用副本可从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息。当本地和主应用副本部署在不同一台主机时,备应用副本可根据网络通信将本地与当前主应用副本进行连接通信,通信通道建立后,备应用副本可从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息。
上述实施例中,通过判断本地和主应用副本各自所在的物理环境,确定本地和当前主应用副本的通信机制,进而根据各自对应的通信机制进行历史消息的获取,这样,进一步提升了历史消息的获取效率。
在一个实施例中,当本地和主应用副本部署在不同一台主机时,根据网络通信从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息的步骤,具体包括:当本地和主应用副本部署在不同一台主机时,获取主应用副本的网络通信参数;网络通信参数包括网络地址和端口;根据网络通信参数中的网络地址和端口,建立网络通信机制;根据网络通信机制,从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息。
其中,网络通信参数是网络信道中的传输参数,用于建立通信通道。具体地,主应用副本具有对应的网络通信参数,当本地和主应用副本部署在不同一台主机时,修复后的备应用副本可获取主应用副本的网络通信参数,进而备应用副本可根据网络通信参数中的网络地址和端口,建立网络通信机制。基于网络通信机制,可将备应用副本可当前的主应用副本建立通信,进而备应用副本可从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息。
在一个实施例中,网络通信参数的获取有多种方法,比如,可借助集中式的配置管理中心ZooKeeper(分布式系统的可靠协调系统)或Etcd(服务发现系统)来实现,主应用副本将通信参数写入配置管理中心,修复后的备应用副本可从配置管理中心读取对应的网络通信参数。故修复后的备应用副本还可以直接向主应用副本查询网络通信参数。当修复后的备应用副本和主应用副本之间已经建立了通信机制时,备应用副本还可以通过复用机制来获取网络通信参数。
上述实施例中,通过本地和主应用副本各自对应的网络通信参数中的网络地址和端口,快速建立本地和当前主应用副本之间的通信,保证了历史消息的顺利获取,缩短历史消息的获取时间,进一步提升了系统的可用性。
应该理解的是,虽然图2和图4的各个步骤按照顺序依次显示,但是这些步骤并不是必然按照顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,上述图2和图4中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
在一个实施例中,如图5所示,提供了一种故障应用副本处理装置500,包括:启用模块501、确定模块502、获取模块503和处理模块504,其中:
启用模块501,用于启用经过故障修复后的备应用副本,并确定备应用副本所在集群中当前正常运行的主应用副本。
确定模块502,用于确定在启用经过故障修复后的备应用副本时,主应用副本当前正在进行业务处理的第一消息。
获取模块503,用于获取接收时间在第一消息之后的第二消息,并查找接收时间在第一消息之前的历史消息。
处理模块504,用于根据历史消息对应的接收时间,依次对历史消息进行业务处理。
处理模块504还用于当历史消息处理完成后,根据第二消息的接收时间,依次对第二消息进行业务处理以使得本地的备应用副本重加入集群。
在一个实施例中,启用模块501还用于当主应用副本故障时,根据投票机制从集群中的至少一个备应用副本中筛选出票数最高的备应用副本作为集群中当前正常运行的主应用副本,故障的主应用副本在修复后作为备应用副本;当备应用副本故障时,修复后直接确定当前对应的主应用副本。
在一个实施例中,确定模块502还用于获取消息查询请求,并将消息查询请求发送至主应用副本;根据消息查询请求,确定主应用副本中的消息所对应的消息标识;根据消息标识,确定在启用经过故障修复后的备应用副本时,主应用副本当前正在进行业务处理的第一消息。
在一个实施例中,获取模块503还用于监测主应用副本接收第二消息的状态;当监测到主应用副本接收到第二消息时,获取复制消息请求,并将复制消息请求发送至主应用副本;根据复制消息请求,从主应用副本中获取接收时间在第一消息之后的第二消息。
在一个实施例中,获取模块503还用于获取历史消息请求,并将历史消息请求发送至主应用副本;历史消息请求包括本地的消息信息;根据历史消息请求的消息信息,确定本地缓存的最新的消息所对应的第一时间;查找接收时间在第一消息之前、且在第一时间之后的历史消息。
在一个实施例中,获取模块503还用于判断本地和主应用副本各自对应的物理环境;当本地和主应用副本部署在同一台主机时,根据进程间的通信机制从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息;当本地和主应用副本部署在不同一台主机时,根据网络通信从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息。
在一个实施例中,获取模块503还用于当本地和主应用副本部署在不同一台主机时,获取主应用副本的网络通信参数;网络通信参数包括网络地址和端口;根据网络通信参数中的网络地址和端口,建立网络通信机制;根据网络通信机制,从主应用副本中查找接收时间在第一消息之前、且在第一时间之后的历史消息。
上述故障应用副本处理装置,将集群中的应用副本分为主应用副本和备应用副本,主应用副本负责对外提供服务,备应用副本作为备用应用副本。当应用副本发生故障时,首先对故障的应用副本进行修复作为备应用副本,进而确定主应用副本当前正在进行业务处理的第一消息,使得将本地与当前主应用副本的消息对齐,并从对齐处开始获取接收时间在第一消息之后第二消息,即新消息,同时获取接收时间在第一消息之前的历史消息,使得新消息的获取和历史消息的获取并行进行。依次处理获取到的历史消息和接收到的新消息,在历史消息处理完后再继续处理新消息,当缓存的新消息处理完之后,故障的应用副本则完成了重加入集群的过程。这样,故障应用副本和当前的主应用副本只需要进行一次消息对齐,使得网络延迟减少,且新消息的获取和历史消息的获取并行进行,缩短了故障应用副本的恢复时长,保证了故障应用副本重加入集群的及时性,进而提升了分布式系统的可用性。
关于故障应用副本处理装置的具体限定可以参见上文中对于故障应用副本处理方法的限定,在此不再赘述。上述故障应用副本处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中,提供了一种计算机设备,该计算机设备可以是服务器,其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储故障应用副本处理数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种故障应用副本处理方法。
本领域技术人员可以理解,图6中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
在一个实施例中,提供了一种计算机设备,包括存储器和处理器,存储器存储有计算机程序,计算机程序被处理器执行时,使得处理器执行上述故障应用副本处理方法的步骤。此处故障应用副本处理方法的步骤可以是上述各个实施例的故障应用副本处理方法中的步骤。
在一个实施例中,提供了一种计算机可读存储介质,存储有计算机程序,计算机程序被处理器执行时,使得处理器执行上述故障应用副本处理方法的步骤。此处故障应用副本处理方法的步骤可以是上述各个实施例的故障应用副本处理方法中的步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限,RAM以多种形式可得,诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。