CN109308227A - 故障检测控制方法及相关设备 - Google Patents
故障检测控制方法及相关设备 Download PDFInfo
- Publication number
- CN109308227A CN109308227A CN201810974297.XA CN201810974297A CN109308227A CN 109308227 A CN109308227 A CN 109308227A CN 201810974297 A CN201810974297 A CN 201810974297A CN 109308227 A CN109308227 A CN 109308227A
- Authority
- CN
- China
- Prior art keywords
- data memory
- target service
- fault detection
- business
- memory node
- 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.)
- Granted
Links
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/0751—Error or fault detection not based on redundancy
-
- 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
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)
- Debugging And Monitoring (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明实施例提供故障检测控制方法及相关设备,预先对具有不同属性的业务设置了相应故障检测模式,在实际应用中,通过获取目标业务(该分布式键值数据库支持的任一业务)的属性信息,从而确定与该目标业务的属性信息对应的故障检测模式为目标故障检测模式,按照该目标故障检测模式,实现多个数据存储节点的故障检测。可见,当分布式键值数据库当前实现不同属性的业务时,能够按照上述方式,选择各业务的属性信息对应的故障检测模式,实现对该业务的多个数据存储节点的故障检测,并不是采用固定的某一种故障检测模式,保证不同属性的业务能够及时恢复运行,进而保证业务访问效率,且提高了分布式键值数据库的应用范围。
Description
技术领域
本发明涉及故障检测领域,具体涉及一种故障检测控制方法及相关设备。
背景技术
近年来,随着数据量的高速增长,分布式数据库技术得到了快速发展,其中,分布式数据库通常包括多个数据存储节点,每个数据存储节点可以是一个计算机设备,为了保证分布式数据库运行的稳定性和可靠性,多个数据存储节点通常采用主从模式工作。
其中,键值数据库Redis作为目前常用的分布式数据库,利用自带的管理模块Sentinel监控Redis包含的多个数据存储节点,并通过投票决定是否执行自主故障迁移,即进行主备数据存储节点切换恢复业务,保证业务能够继续正常运行。
然而,本发明的发明人发现,Redis这种分布式键值数据库仅支持最终一致性业务,对多个数据存储节点的故障检测方法固定不变,限制了该分布式键值数据库的应用范围。
发明内容
有鉴于此,本发明实施例提供一种故障检测控制方法及其相关设备,能够按照目标业务的属性信息对应的目标故障检测模式,实现对多个数据存储节点的故障检测,满足了不同类型业务的故障检测需求,提高了分布式键值数据库的应用范围。
为实现上述目的,本发明实施例提供如下技术方案:
本发明实施例提供了一种故障检测控制方法,应用于分布式键值数据库,所述分布式键值数据库包含有控制节点集和数据存储节点集,所述数据存储节点集中的每一个数据存储节点存储有多个业务的数据,所述多个业务的数据通过不同分片进行区别,所述方法包括:
获取目标业务的属性信息;
确定与所述目标业务的属性信息对应的目标故障检测模式;
按照所述目标故障检测模式,对实现所述目标业务的多个数据存储节点进行故障检测。
本发明实施例还提供了一种故障检测控制装置,应用于分布式键值数据库,所述分布式键值数据库包含有控制节点集和数据存储节点集,且所述数据存储节点集中的每一个数据存储节点存储有多个业务的数据,所述多个业务的数据通过不同分片进行区别,所述装置包括:
属性信息获取模块,用于获取目标业务的属性信息;
目标故障检测模式确定模块,用于确定与所述目标业务的属性信息对应的目标故障检测模式;
故障检测模块,用于按照所述目标故障检测模式,对实现所述目标业务对应的多个数据存储节点进行故障检测。
本发明实施例还提供了一种计算机设备,所述计算机设备包括:至少一个存储器和至少一个处理芯片;所述存储器存储程序,所述处理芯片执行所述程序,以实现上述的故障检测控制方法。
基于上述技术方案,本发明实施例提供的故障检测控制方法及相关设备,本实施例预先对具有不同属性的业务设置了相应故障检测模式,在实际应用中,通过获取目标业务(该分布式键值数据库支持的任一业务)的属性信息,从而确定与该目标业务的属性信息对应的故障检测模式为目标故障检测模式,按照该目标故障检测模式,实现多个数据存储节点的故障检测。可见,当分布式键值数据库当前实现不同属性的业务时,能够按照上述方式,选择各业务的属性信息对应的故障检测模式,实现对该业务的多个数据存储节点的故障检测,并不是采用固定的某一种故障检测模式,保证不同属性的业务能够及时恢复运行,进而保证业务访问效率,且提高了分布式键值数据库的应用范围。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为本发明实施例提供的一种分布式键值数据库的结构示意图;
图2为本发明实施例提供的一种故障检测控制方法的流程示意图;
图3a为本发明实施例提供的一种确定目标故障检测模式的流程示意图;
图3b为本发明实施例提供的另一种确定目标故障检测模式的流程示意图;
图4a为现有的一种故障检测方法的流程示意图;
图4b为现有的另一种故障检测方法的流程示意图;
图5a为本发明实施例提供的一种故障检测方法的流程示意图;
图5b为本发明实施例提供的一种故障检测方法的场景示意图;
图6a为本发明实施例提供的另一种故障检测方法的流程示意图;
图6b为本发明实施例提供的另一种故障检测方法的场景示意图;
图7为本发明实施例提供的另一种故障检测控制方法的流程示意图;
图8为本发明实施例提供的又一种故障检测控制方法的流程示意图;
图9为本发明实施例提供的一种故障检测控制装置的结构示意图;
图10为本发明实施例提供的另一种故障检测控制装置的结构示意图;
图11为本发明实施例提供的又一种故障检测控制装置的结构示意图;
图12为本发明实施例提供的一种计算机设备的硬件结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例适用于分布式键值数据库中的各数据存储节点的故障检测的场景,该分布式键值数据库区别于传统的Redis,可以是是兼容Redis访问接口的分布式键值数据库CKV,参照图1所示的结构示意图,这种分布式键值数据库可以包括控制节点集和数据存储节点集,该控制节点集可以包括多个控制节点,且分为主控制节点和若干备控制节点,所述数据存储节点集包括多个数据存储节点(如图1中的Cache1、Cache2、Cache3),数据存储节点对外部设备作为一个整体,可以用来转发用户发起的业务访问请求,且每个数据存储节点可以存储多个业务的数据,具体可以将数据存储节点内容的存储区域划分成若干分片(如图1中的Shard),将每一个业务的业务数据分散存储到各数据存储节点中的一分片中,也就是说,每一个数据存储节点上可以存储多个业务的数据,不同业务的数据以Shard区分。本实施例可以将同一业务对应的多个分片组成的集合称为数据分片复制集ReplicaSet,如图1中的数据分片复制集A、数据分片复制集B、数据分片复制集C等等。
可见,如图1所示的分布式键值数据库中,一个数据存储节点上可以有多个分片,这多个分片分别对应不同的数据分片复制集,各数据分片复制集可以对应不同的业务实例,其中,各数据分片复制集中多个分片的的角色(如主角色或备角色)可以是随机确定的。当然,一个业务实例也可以对应多个数据分片复制集,本实施例对此不作限定。
另外,根据分片角色的不同,每一个数据分片复制集都可以包括一个主分片和若干个备分片,主分片可以用来实现相应业务的对外服务,备分片可以实现对相应业务运行过程中产生的数据进行备份,本实施例对该分布式键值数据库的具体工作过程不作详述。
需要说明,本实施例适用的分布式键值数据库并不局限于CKV,还可以是其他结构的分布式键值数据库,下文各实施例仅以图1所示的分布式键值数据库的结构为例进行说明。
参照图2,为本发明提供的一种故障检测控制方法实施例的流程示意图,该方法可以应用于分布式键值数据库,如图1所示的分布式键值数据库的结构示意图,该分布式键值数据库中的各控制节点和数据存储节点可以是不同功能的计算机设备,本实施例提供的该方法具体可以由起到控制功能的计算机设备实现,并不局限于作为控制节点的计算机设备,具体可以包括但并不局限于以下步骤:
步骤S11,获取目标业务的属性信息;
目标业务可以是用户当前需要使用的业务,即用户请求访问的业务,其可以是分布式键值数据库支持的任一业务。为了实现该业务,计算机设备通常会创建相应的业务进程,本实施例可以从该业务进程对应的数据中,获取目标业务的属性信息,该属性信息可以用来识别目标业务的类型等,本实施例对业务的属性信息包含的内容不做限定。
步骤S12,确定与该目标业务的属性信息对应的目标故障检测模式;
在本实施例中,可以针对不同类型的业务,设置相应的故障检测模式,来实现对该类型的业务的各分片进行故障检测,以便及时发现故障的主分片所在的数据存储节点,并使用该业务对应的可用的备分片替换该主分片,保证计算机设备能够继续对外提供该业务的服务。
其中,不同故障检测模式采用容错机制不同,对多个数据存储节点的故障检测方法不同,本实施例对实现不同类型业务的分布式键值数据库采用的故障检测模式的内容不作限定,可以基于该类型业务的属性信息确定,可以包括但并不局限于下文描述的故障检测模式。
本实施例中,目标业务的属性信息能够表征该目标业务的业务类型,因此,在获取目标业务的属性信息后,可以先确定目标业务的业务类型,再按照预先设定的不同类型业务与多种故障检测模式的对应关系,得到目标业务对应的目标故障检测模式,即确定对实现目标业务的分布式键值数据库进行故障检测的实现方式。
当然,用户也可以根据经验,得知目标业务的业务类型后,直接从输出的多种故障检测模式中,选择出目标故障检测模式,或直接输入本次对分布式键值数据库使用的故障检测模式等等,本实施例对步骤S22的具体实现方式不做限定。
步骤S13,按照该目标故障检测模式,对实现目标业务的多个数据存储节点进行故障检测。
对于分布式键值数据库中的各计算机设备,得知目标业务运行期间采用的目标故障检测模式后,可以按照该目标故障检测模式的具体内容执行,以实现对分布式键值数据库的多个数据存储节点的故障检测。其中,当目标故障检测模式的内容不同,该分布式键值数据库中各计算机设备实现故障检测执行的操作不同,具体可以参照下文相应实施例的描述。
综上所述,本实施例的分布式键值数据库能够支持多种故障检测模式,能够根据实际实现的目标业务的不同,可以选择相应的故障检测模式执行,保证实现目标业务的数据存储节点故障后,该目标业务能够及时恢复,拓宽了分布式键值数据库的支持的业务范围,提高了该分布式键值数据库的市场占有率。
可选的,结合上文描述,分布式键值数据库每一个数据存储节点存储有多个业务的数据,因此,同一时刻,该分布式键值数据库可以支持多个业务,各业务的属性信息可以不同,按照上述故障检测控制方法,本实施例可以针对每一种属性的业务,选择对应的故障检测模式,实现对多个数据存储节点中该业务对应的分片进行故障检测,从而使该分布式键值数据库可以执行不同的故障检测模式,以保证不同属性的业务的可靠工作。
在计算机设备确定对某一属性的业务后,选择其所使用的故障检测模式时,可以按照以下几种方式实现,但并不局限于下文所示的方式:
方式一:
参照图3a所示的流程示意图,本实施例可以预先配置多种故障检测模式,即开发人员预先编写实现各种故障检测模式的程序代码后,存储实现各种故障检测模式的程序代码,在用户已知分布式键值数据库当前需要实现的某一目标业务,以及不同属性的业务所需什么故障检测模式进行故障检测最合适的情况下,本实施例可以由用来进行数据库配置的计算机设备(其通常是起到控制功能的计算机设备,本实施例对其不作限定),直接输出分布式键值数据库支持的多种故障检测模式,如图3a所示的故障检测模式选择界面,用户可以从当前显示的多种故障检测模式中,选择出适用于该目标业务的故障检测模式,此时,可以生成相应的选择指令,以使计算机设备响应选择指令,得知被选择的故障检测模式,并将其作为目标业务的目标故障检测模式,从而在分布式键值数据库执行该目标业务期间,按照该目标故障检测模式的故障检测方法,对分布式键值数据库中的多个数据存储节点进行故障检测。同理,对于确定的其他目标业务,也可以按照上述方式确定其所需的目标故障检测模式。
需要说明,本实施例对计算机设备输出的多种故障检测模式的输出方式不作限定,可以是各故障检测模式的名称,如中心控制模式、自主选举模式等,也可以设置各故障检测模式唯一的模式标识,从而使计算机设备直接输出各故障检测模式对应的模式标识,用户可以根据显示的模式标识,来得知分布式键值数据库支持哪些故障检测模式,并选择当前需要的故障检测模式对应的模式标识等等,本实施例对模式标识包含的内容不作限定。
作为本发明一可选实施例,本实施例也可以在获取目标业务的属性信息后,直接将其或由其确定的目标业务类型展示在计算机设备的显示界面,此时,该显示界面也可以同时展示分布式键值数据库支持的多种故障检测模式,方便用户准确选择本次需要的目标故障检测模式。
可选的,在得到目标业务属性信息或目标业务的类型后,也可以由计算机设备根据存储的各类型的业务与各故障检测模式之间的对应关系,直接为用户推荐目标业务对应的目标故障检测模式,用户不需要了解各类型业务适合哪种故障检测模式,也能够准确配置分布式键值数据库本次采用的目标故障检测模式。
方式二:
参照图3b所示的流程示意图,本实施例可以由计算机设备自动选择本次需要的目标故障检测模式,具体的,可以根据各类业务的业务特点,及各种故障检测模式的检测特点,生成不同类型的业务与多种故障检测模式之间的对应关系,并对其进行存储,这样,在获取目标业务的属性信息后,由于该属性信息可以表征目标业务的类型,因此,本实施例可以直接利用该属性信息及存储的对应关系,查询目标业务的目标故障检测模式。
其中,基于上述不同类型的业务与多种故障检测模式之间的对应关系的存储方式的不同,尤其是不同类型业务的表示方式不同,上述查询得到目标故障检测模式的过程也会有所不同。若直接由属性信息表示不同类型的业务,那么,得到目标业务的属性信息后,可以直接从预存的对应关系中,查找与该目标业务的属性信息对应的故障检测模式,记为目标故障检测模式;若采用其他标识来表示业务类型,本实施例可以先由目标业务的属性信息,确定该目标业务的类型,再查找与该目标业务类型对应的目标故障检测模式等等,本实施例在此不再一一详述。
需要说明,本实施例对上述不同类型业务与多种故障检测模式的对应关系的存储方式不作限定,如表格方式、关系图方式等等。
在本发明实施例中,可以从数据的一致性角度考虑,或者说根据数据的存储机制差异角度考虑,将分布式键值数据库支持的业务类型分为强一致性业务和最终一致性业务这两种类型的业务,但并不局限于这种类型业务,本发明主要以这两种类型的业务为例进行说明。
其中,强一致性是指***中的某个数据被更新后,后续任何对该数据的读取操作都将得到更新后的数据;最终一致性是指***中的某个数据被更新后,后续对该数据的读取操作所得的数据,可能是更新后的数据,也可能是更新前的数据,通常在更新后需要一段时间,才能读取到更新后的数据。
在实际应用中,对于不同类型的业务,其需要的故障检测方式往往是不同的,然而,在传统的分布式键值数据库Redis中,利用其自带的管理模块Sentinel进行故障检测,仅能够实现对最终一致性业务的故障检测,即其采用的故障检测模式是固定不变的,且其需要在Sentinel中配置相应的业务及其所在数据存储节点信息,该Sentinel才能实现对该业务对应的多个数据存储节点进行故障检测,一旦该Sentinel所在的计算机设备故障不可恢复,将会导致其存储的配置信息丢失,无法实现对该业务的故障检测,具有很大局限性。
而且,参照图4a所示的基于Redis架构的故障检测方法的流程示意图,RedisSentinel在具体故障检测过程中,只有当超过50%的Sentinel进程确认Master节点故障,并选举出一Slave节点作为新的Master节点,才会进行主备节点切换,以恢复该业务服务,过程比较繁琐。
而对于强一致性业务,通常采用如图4b所示的***架构的分布式键值数据库支持实现,并利用Placement Driver(简称PD)这个全局中心总控节点,通过Raft算法(即用来管理日志复制的共识算法),保证数据的强一致性,避免数据丢失。
且,为了实现分布式键值数据库的强一致性业务的故障检测,就需要在分布式键值数据库中配置Placement Driver,并搭建如图4b所示的***架构,其与上文图4a所示的Redis Sentinel故障检测所需架构并不相同,所以,要使得分布式键值数据库既能够支持最终一致性业务的故障检测,又能够支持强一致性业务的故障检测,就要求该分布式键值数据库同时具有这两种架构,显然,这是不符合业务开发逻辑的。
为了使分布式键值数据库既能够支持最终一致性业务的故障检测,又能够支持强一致性业务的故障检测,本发明的发明人提出了基于同一***架构,实现两种不同模式的故障检测方法,分别用来实现对不同类型业务的故障检测,并简化了故障检测步骤,提高了故障检测灵活性及准确性。
具体的,结合上述实施例,本实施例可以在确定目标业务的属性信息对应的目标故障检测模式后,生成与该目标故障检测模式对应的触发指令,并将该触发指令发送至分布式键值数据库中的控制节点集或数据存储节点集,以使控制节点集或数据存储节点集实现对所述目标业务的多个数据存储节点的故障检测。至于是由控制节点集还是由数据存储节点集执行确定的目标故障检测模式,将由业务的属性信息确定,具体实现可以参照下文实施例的描述。
需要说明,关于本发明提出的各故障检测模式的具体实现方法,并不局限于下文描述的内容,可以根据实际需要对其进行合理调整,均属于本发明的保护范围,本实施例不再一一列举。
结合上图1所示的分布式键值数据库的结构示意图,当上述实施例的目标业务是最终一致性业务,本发明可以执行中心控制方式对应的故障检测模式,也就是说,本实施例将由分布式键值数据库中的控制节点集来实现对目标业务的多个数据存储节点的故障检测,参照图5a所示的流程示意图,控制节点集对目标业务的多个数据存储节点进行故障检测的过程可以包括但并不局限于以下步骤:
步骤S21,主控制节点对实现目标业务的待测数据存储节点进行心跳检测;
在本实施例中,参照图5b所示的流程示意图,分布式键值数据库中的中心控制节点Master节点(即控制节点)以集群形式存在,各Master节点分主备,由主Master节点负责管理集群,并周期性向各数据存储节点(如图5b中的Cache)发送心跳请求,检测各数据存储节点的状态及其包含的各分片的状态。
由此可见,主控制节点可以通过向待测数据存储节点发送心跳请求,实现对该待测数据存储节点及其包含的各分片的状态检测。当然,对于其他数据存储节点的心跳检测过程类似,本实施例在此不再一一详述。
其中,结合上文图1所示的分布式键值数据库的结构及其描述,实现目标业务的待测数据存储节点可以是,该目标业务对应的数据分片复制集包含的主分片所在的数据存储节点,但并不局限于此,其也可以是分布式键值数据库中的任一数据存储节点,也就是说,本实施例的主控制节点除了对目标业务对应的主分片所在的数据存储节点进行心跳检测,还可以对其他数据存储节点进行心跳检测,从而实现对各数据存储节点的故障检测。
步骤S22,主控制节点在预设时间内是否接收到待测数据存储节点反馈的响应信号,如果是,返回步骤S21;如果否,执行步骤S23;
本实施例对该预设时间的具体数值不作限定,若主控制节点是周期性的发送心跳请求,该预设时间可以是该周期的倍数,比如三个周期,即待测数据存储节点连续三个周期没有响应心跳请求,通过这种方式来确定待测数据存储节点当前状态是否正常。当然,本发明也可以采用其他方式对各数据存储节点进行故障检测,并不局限于本文描述的这种实现方式。
步骤S23,主控制节点向一备控制节点发送故障检测通知信息;
其中,该故障检测通知信息可以包含主控制节点认为故障的待测数据存储节点的相关信息,以使备控制节点据此得知哪个数据存储节点可能故障,从而直接对该数据存储节点进行心跳检测,本实施例对该故障检测通知信息包含的内容及其输出方式不作限定。
步骤S24,备控制节点对该待测数据存储节点进行心跳检测;
步骤S25,备控制节点在预设时间内未接收到待测数据存储节点反馈的响应信号,向主控制节点反馈故障检测结果;
可见,本实施例为了减少对数据存储节点的故障检测的误判,在主控制节点通过心跳检测方式,确定待测数据存储节点故障后,可以随机通知一台备控制节点所在的计算机设备,由该备控制节点确定该待测数据存储节点是否故障,检测方法与主控制节点检测方法类似,本实施例在此不再详述。
经过备控制节点对待测数据存储节点的二次检测,该待测数据存储节点仍未对接收到的心跳请求及时回应,本实施例将确定该待测数据存储节点故障,此时,备控制节点可以将这一检测结果反馈至主控制节点,以使主控制节点执行后续步骤。如上实施例分析,本实施例反馈至主控制节点的故障检测结果表明待测数据存储节点故障。
步骤S26,检测该待测数据存储节点是否包含有目标业务的主分片,如果是,执行步骤S28;如果否,进入步骤S27;
经过上述检测,确定待测数据存储节点故障后,由于该待测数据存储节点可以是分布式键值数据库中的任一数据存储节点,其可能包含该目标业务的主分片,也可能只包含该目标业务的备分片,在实际应用中,通常是由主分片负责业务的对外服务,因此,当业务对应的主分片故障,将会导致该业务停止工作,若仅是该业务对应的备分片故障,影响的是对该业务运行产生的业务数据的备份,并不会影响业务的正常工作。
所以,本实施例确定待测数据存储节点故障后,可以判断该待测数据存储节点是否包含实现目标业务的主分片,如果是,该目标业务将停止工作,无法对外提供服务;如果否,不影响目标业务对外服务。然而,结合上文对分布式键值数据库的分析,该待测数据存储节点还会包含对应其他业务的分片,也就是说,其可能包含实现其他业务的主分片,此时可以按照下文步骤S28及其以后步骤,对其他业务对应的数据分片复制集进行处理,本实施例在此不做详述。
步骤S27,主控制节点输出待测数据存储节点的维护提示信息;
继上文分析,确定故障的待测数据存储节点未包含实现目标业务的主数据存储节点,主控制节点可以输出相应的维护提示信息,以提醒相应维护人员对该待测数据存储节点进行维护,以使该待测数据存储节点能够恢复正常。
需要说明,本实施例对维护提示信息包含的内容及其输出方式不作限定,且对维护人员如何对故障的数据存储节点进行维护的实现方法也不作限定。
步骤S28,主控制节点从与主分片关联的至少一个备分片中,选择出新的主分片;
假设待测数据存储节点是图5a中的Cache1,目标业务对应的数据分片复制集是ReplicaA,主分片是Cache1中属于ReplicaA的Shard,即Leader Shard,在该Leader Shard故障后,需要从Cache2和Cache3中属于ReplicaA的Follower Shard(即目标业务对应的备分片)中选择一个作为新的Leader Shard,以恢复目标业务的服务。
可选的,本实施例可以通过比较这两个Follower Shard与故障的Leader Shard包含的数据的相似度,选择相似度较大的Follower Shard作为新的Leader Shard。当然,本发明也可以采用其他切换策略,从备分片中选择出新的主分片,并不局限于本实施例描述的这种基于相似度大小的切换策略。
步骤S29,主控制节点对目标业务的路由信息进行更新,并将更新后的路由信息发送至目标业务对应的多个数据存储节点;
实际应用中,CKV分布式键值数据库实现的每个业务可以对应唯一tid,并由控制中心的Master节点负责管理tid的路由表,即描述tid的Key存储在数据存储节点Cache的位置信息,本实施例可以将其称为路由信息。可见,本实施例中目标业务的路由信息记录的是该目标业务的业务数据的存储位置,即该业务的Key对应的Value的存储位置,当目标业务的主分片故障,将无法对外提供该目标业务的服务,按照上述方式恢复其服务后,目标业务的路由信息将发生变化,为保证目标业务后续正常运行,主控制节点将根据上述主备切换操作,更新该目标业务的路由信息,具体更新方法及路由信息包含的内容不做限定。
之后,主控制节点可以将目标业务更新后的路由信息发送至目标业务关联的各数据存储节点,仍以上述故障的待测数据存储节点是图5b中的Cache1为例进行说明,如图5b所示,主控制节点可以向Cache2和Cache3发送更新后的路由信息,Cache2和Cache3接收到更新户的路由信息后,将会回复因Cache1故障中断的ReplicaA的服务,即目标业务服务。
综上所述,在本实施例中,在确定实现目标业务的待测数据存储节点故障后,仅需要一个备控制节点再核实一次即可,相对于传统Redis Sentinel采用的50%Sentinel进程确定一数据存储节点故障的检测方法,简化了故障检测步骤,提高了数据存储节点故障检测效率,不需要在各控制节点分片配置各业务,即便主控制节点故障,可以选择一备控制节点作为主控制节点,按照上述方法继续进行故障检测,提高了对各数据存储节点故障检测的灵活性。
基于图1所示的分布式键值数据库,当上述实施例的目标业务是强一致性业务,本实施例可以执行自主选举方式的故障检测模式,具体由数据存储节点集实现对目标业务的多个数据存储节点的故障检测,参照图6a所示的流程示意图,该故障检测的具体实现过程具体可以包括但并不局限于下文描述的步骤:
步骤S31,目标业务的主分片所在的数据存储节点按照共识算法,向其他数据存储节点中目标业务的各备分片发送心跳请求;
如上文对本实施例分布式键值数据库的结构描述,实现业务的数据分片复制集包括一主分片及至少一个备分片,由该主分片实现该业务服务,而备分片用来实现对业务数据的备份。其中,该业务数据是通过备分片与主分片的同步操作得到的,且为了保证数据的强一致性,本实施例可以采用Raft这一共识算法实现业务数据的同步备份,具体实现过程本实施例不做详述。
在实际应用中,对于任一数据分片复制集中的各分片来说,主数据服务节点可以周期性地向其关联的各备分片发送心跳请求及同步数据,本实施例主要对分片的故障检测进行说明,因此,本实施例各步骤并未说明主分片与备分片之间的数据同步过程。
步骤S32,其他数据存储节点中目标业务的各备分片等待预设时间未接收到该心跳请求,确定该目标业务的主分片所在的数据存储节点故障;
参照图6b所示的结构及流程示意图,仍以数据分片复制集ReplicaA对应目标业务,其主分片故障(即Cache1中属于ReplicaA的Shard故障)为例进行说明,Cache1上ReplicaA中的Leader Shard停止向Cache2和Cache3上ReplicaA中的Follower Shard发送心跳请求,Cache2和Cache3等待预设时间未收到心跳请求,可以认为Cache1故障,实现目标业务的主分片无法再提供对外服务,目标业务中断。
可见,本实施例对于任一业务来说,可以由该业务的多个分片通过心跳检测方式,确定故障的数据存储节点,并检测该故障的数据存储节点包含该业务的主分片,将执行步骤S33;否则,不会影响该业务的正常运行,可以不作处理。
步骤S33,其他数据存储节点按照选举机制,从目标业务的各备分片中选举出新的主分片;
为了尽快回复目标业务服务,继上文实施例,可以由Cache2或Cache3上ReplicaA中的Follower Shard,向该ReplicaA中处于正常状态的Shard发送选举请求,以Cache2上ReplicaA中的Follower Shard发起选举请求为例进行说明,如图6b所示,其向Cache3发送选举请求,待该Cache3上ReplicaA中的Follower Shard同意,即大多数同意,可以将Cache2上ReplicaA中的Follower Shard作为新的Leader Shard。此时,Cache2上ReplicaA中的Leader Shard可以替代Cache1上ReplicaA中的原Leader Shard,向Cache3上ReplicaA中的Follower Shard发送心跳请求及同步数据。
步骤S34,该目标业务的新的主分片所在的数据存储节点响应主控制节点发送的心跳请求,将当前该目标业务的各分片的状态信息反馈至主控制节点;
在本实施例中,主控制节点可以周期性向各数据存储节点发送心跳请求,以便在一业务的主分片发生变化后,能够及时得知相关信息,通常情况下,该相关信息可以由业务对应的主分片反馈,如携带在心跳回包中上报给主控制节点。
其中,上报的相关信息即目标业务对应的各分片的状态属性信息,可以包括该目标业务对应的数据分片复制集中各分片的状态(如是否正常工作),及各分片的角色(即是主分片还是备分片)等。
步骤S35,主控制节点基于接收到的各分片的状态信息,更新目标业务的路由信息;
步骤S36,主控制节点将更新后的路由信息发送至实现该目标业务的多个数据存储节点。
如上文对状态信息的描述可知,其能够表明目标业务对应的各分片的角色是否发生变化,即是否进行了主备分片的切换,若发生切换,主控制节点可以从接收到的状态信息中,得知当前实现目标业务的主分片位于哪个数据存储节点中,从而据此来更新目标业务的路由信息,以便后续客户端请求该目标业务,能够得到及时响应。
如图6b所示,仍以上文描述的Cache1故障为例进行说明,当主控制节点更新目标业务的路由信息后,主要是发送给当前处于正常状态的Cache2和Cache3,以使后续这两个数据存储节点接收到业务访问请求后,能够根据更新后的路由信息,准确将该业务访问请求转发给相应的分片,保证客户端正常使用目标业务。
综上所述,本发明采用上文描述的故障检测模式,实现了对强一致性业务的故障检测,且这种故障检测方式能够直接将目标业务关联的各分片的状态及角色等信息,统一上报给主控制节点,不需要分批发送,,其相对于图4b所示的传统自主选举故障检测方式,减少了主控制节点与数据存储节点之间的通信次数,提供了检测效率。
综合上述对中心控制和自主选举两种故障检测模式的描述,这两种故障检测模式可采用一种***架构实现,并由开发人员预先编写实现这两种故障检测模式的程序代码,这样,在确定当前实现的目标业务的业务类型后,可以触发对应的故障检测模式的程序代码执行,即根据当前执行的业务类型,选择合适的故障检测模式,保证目标业务的可靠工作,拓宽分布式键值数据库CKV的用户范围,进而提高了分布式键值数据库CKV的市场占有率。
需要说明,基于本发明的构思,对于其他类型的业务,若上文给出的故障检测模式不适用,可以按照上述构思,由开发人员开发实现新的故障检测模式的程序代码,并重新开发能够调用多种故障检测模式的程序代码的故障检测程序,兼容新开发的故障检测模式的程序代码并执行,当确定目标业务类型是区别于其他类型的业务,可以按照上述方式,选择已编写的相应的故障检测模式的程序代码执行保证该其他类型的业务能够及时恢复正常工作。
作为本发明另一可选实施例,在上述实施例的基础上,应当理解,若分布式键值数据库中的一数据存储节点故障,将会导致各业务对应备分片数量减少,甚至如图5b所示的分布式键值数据库的结构,各业务都仅剩余一备分片进行业务数据的备份,若今后又出现一数据存储节点故障,将会导致各业务没有进行业务数据备份的分片,降低了业务运行的可靠性。
因此,为了提高业务运行的可靠性,本实施例在确定上述待测数据存储节点不可恢复后,增加新的数据存储节点,来增加各业务的备分片的数量。具体如图7所示的流程示意图,按照上述实施例描述的方式,确定故障的数据存储节点后,还可以执行但并不局限于以下步骤:
步骤S41,输出针对故障的数据存储节点的维护提示信息;
本实施例中,按照上述方式,确定待测数据存储节点故障,并针对其包含的主分片所在的数据分片复制集,重新选择出新的主分片后,主控制中心可以按照上文步骤S27描述的方式,通知维护人员对故障的该待测数据存储节点进行维护处理,具体处理方法不做限定。
步骤S42,获取该故障的数据存储节点的当前状态信息;
其中,此处获取的当前状态信息可以是在维护人员对故障的数据存储节点进行维护之后获取的,因此,其能够直接表明维护后的数据存储节点是否恢复正常。
步骤S43,若当前状态信息表明该故障的数据存储节点不可恢复,输出增加数据存储节点的***提示信息;
也就是说,维护人员对故障的数据存储节点进行维护之后,获取其状态信息仍表明该数据存储节点处于故障状态,可以认为该数据存储节点是不可恢复的,此时,可以在***中增加至少一台新的计算机设备,作为该***的数据存储节点工作。因此,在确定故障的数据存储节点不可恢复后,可以输出***提示信息,来提醒相关人员对本发明分布式键值数据库增加新的数据存储节点,本实施例对该***提示信息的内容及其输出方式不作限定。
步骤S44,利用增加的数据存储节点包含的多个分片,更新各业务的备分片的数量。
需要说明的是,本实施例对如何增加数据存储节点的方法不作限定,由于该数据存储节点可以是一台计算机设备,可以建立其与***中的其他计算机设备之间的通信关系,并通知其他计算机设备,增加的该计算机设备的角色,以使后续***运行中,增加的该计算机设备能够起到预设的作用。
另外,结合上文对数据存储节点和分片之间关系的描述,新增加的数据存储节点也会被划分成多个分片,这些分片可以被分配到各数据分片复制集中,以使每个数据分片复制集增加一个分片,作为对应业务的备分片工作。
可选的,在上述实施例描述的故障检测过程中,为了避免因计算机设备使用的网络抖动,导致数据存储节点故障误判,本实施例可以通过检测预设时间内,连续确定故障的待测数据存储节点的数量是否达到预设数量,若达到,可以输出相应的提示信息,来通知运维人员确认这些故障的数据存储节点是否真的发生故障,具体可以参照图8所示的流程示意图,在上述实施例的基础上,可以增加但并不局限于以下校验步骤:
步骤S51,当确定故障的待测数据存储节点,获取本次与上一次确定故障待测数据存储节点的时间间隔;
步骤S52,判断该时间间隔是否达到预设时间,如果否,进入步骤S53;如果是,执行步骤S54;
本实施例对该预设时间的具体数值不作限定,通常不会很大,以便在较短时间间隔内,连续确定两个待测数据存储节点故障,认为此时可能出现网络抖动造成的误判,可以及时通知相关运维人员进行检查。
步骤S53,输出故障核实信息;
其中,该核实提示信息可以用来提醒运维人员对确定故障的待测数据存储节点进行检查,因此,该提示信息可以包括确定故障的待测数据存储节点的标识信息等,其可以通过预先绑定相应运维人员的终端设备,从而以短信、邮件等方式,将该核实提示信息发送至终端设备了;当然,该提示信息也可以直接在主控制节点输出,以使管理该主控制节点的管理人员,及时通知运维人员对故障的待测数据存储节点进行检查等等,本实施例对该提示信息包含的内容及其输出方式不作限定。
步骤S54,输出故障提示信息。
本实施例中,该故障提示信息可以用来提醒运维人员对故障的数据存储节点进行维护,以使其能够恢复正常工作,若无法恢复正常工作,可以参照上文描述的方式,在***中增加新的数据存储节点,以使各业务具有足够的备分片进行业务数据同步,保证业务运行的可靠性。
需要说明的是,该故障提示信息可以采用上述核实提示信息的输出方式输出,即主控制节点输出或发送至运维人员的终端设备输出,当然,还可以直接通过故障的数据存储节点输出,本实施例对其输出方式及其包含的内容不作限定。
基于上述各实施例对本发明提出的故障检测控制方法的描述,该方法适用于图1所示的分布式键值数据库,即一种兼容Redis访问接口的键值数据库,其包含的起到控制、数据处理等不同作用的部分,可以是各种计算机设备,也就是说,本发明的分布式键值数据库可以由多个计算机设备组成,即上文各实施例描述的控制节点(即Master节点)、数据存储节点(即Cache)可以是独立的一台计算机设备。结合上文对该分布式键值数据库的结构描述,该***实现的各业务实例存放的数据,均可以以分片(即Shard)为基本单位,多个分片组成一个数据分片复制集(即Reploca),每个数据分片复制集中的多个分片有主(Leader)备(Fpllower)角色区分。
如上文分析,在客户端访问该分布式键值数据库某业务,可以将该业务记为目标业务,通过获取该目标业务的属性信息,来确定该目标业务的业务类型,如确定该目标业务属于最终一致性业务,还是属于强一致性业务,之后,选择与目标业务的业务类型对应的故障检测模式,作为目标故障检测模式,并由该***执行该目标故障检测模式的程序代码,实现对***中的多个数据存储节点的故障检测。
可见,在本发明提供的分布式键值数据库提供不同类型的业务时,其采用的对多个数据存储节点进行故障检测的方法不同,从而使该分布式键值数据库无论执行哪种类型的业务,都能够实现该业务的各数据存储节点进行故障检测,保证该业务的正常可靠运行。
可选的,上述基于业务类型,选择对应的故障检测模式过程可以在控制节点上实现,再由控制节点通知其他节点,当前需要执行的是哪个故障检测模式的程序代码,以使***中的各计算机设备能够准确执行相应的方法步骤,实现对当前类型业务的故障检测。当然,本发明也可以在其他计算机设备上完成上述故障检测模式的切换,并不局限于控制节点对应的计算机设备,实现过程类似,本实施例不再一一详述。
下面对本发明实施例提供的故障检测控制装置进行介绍,下文描述的故障检测控制装置可以认为是,计算机设备为实现本发明实施例提供的故障检测控制方法所需设置的程序模块;下文描述的故障检测控制装置的内容,可与上文描述的故障检测控制方法的内容相互对应参照。
参照图9,为本发明实施例提供的一种故障检测控制装置的结构示意图,该装置适用于分布式键值数据库,所述分布式键值数据库包含有多个控制节点及多个数据存储节点,且每一个数据存储节点存储有多个业务的数据,所述多个业务的数据通过不同分片区别,该装置可以包括但并不局限于以下功能模块:
属性信息获取模块91,用于获取目标业务的属性信息;
在本实施例中,该属性信息获取模块91可以包括:
服务进程获取单元,用于获取针对目标业务创建的目标服务进程;
业务属性提取单元,用于从所述目标服务进程中,提取所述目标业务的属性信息。
目标故障检测模式确定模块92,用于确定与所述目标业务的属性信息对应的目标故障检测模式;
故障检测模块93,用于执行所述目标故障检测模式,对实现所述目标业务对应的多个数据存储节点进行故障检测。
可选的,上述目标故障检测模式确定模块92可以包括:
输出单元,用于输出多种故障检测模式;
第一确定单元,用于响应选择指令,将被选择的故障检测模式作为目标业务的目标故障检测模式。
作为本发明另一可选实施例,如图10所示,该装置还可以包括:
对应关系获取模块94,用于获取不同类型的业务与多种故障检测模式之间的对应关系;
相应地,目标故障检测模式确定模块92包括:
业务类型确定单元921,用于利用所述目标业务的属性信息,确定目标业务的类型;
第二确定单元922,用于利用所述对应关系,得到与所述目标业务的类型对应的目标故障检测模式。
可选的,上述故障检测模块93可以包括:
指令生成单元,用于生成与所述目标故障检测模式对应的触发指令;
指令发送单元,用于将所述触发指令发送至所述控制节点集或所述数据存储节点集,以使所述控制节点集或所述数据存储节点集实现对所述目标业务的多个数据存储节点的故障检测。
在本实施例中,若目标业务是最终一致性业务,参照上图5a和图5b,上述指令发送单元具体将所述触发指令发送至所述控制节点集,由所述控制节点集实现对所述目标业务的多个数据存储节点的故障检测。
这种情况下,上述故障检测模块93可以包括:
第一心跳检测单元,用于由主控制节点对实现目标业务的待测数据存储节点进行心跳检测;
检测通知单元,用于当所述主控制节点在预设时间内未接收到所述待测数据存储节点反馈的响应信号,向一备控制节点发送故障检测通知信息;
第二心跳检测单元,用于由所述备控制节点对所述待测数据存储节点进行心跳检测;
第一故障确定单元,用于当所述备控制节点在所述预设时间内未接收到所述待测数据存储节点反馈的响应信号,由所述主控制节点确定所述待测数据存储节点故障;
主分片选择单元,用于当所述待测数据存储节点包含有所述目标业务的主分片,从与所述主分片关联的至少一个备分片中,选择出新的主分片;
路由信息更新单元,用于对所述目标业务的路由信息进行更新,并将更新后的路由信息发送至所述目标业务对应的多个数据存储节点。
作为另一可选实施例,若目标业务是强一致性业务,参照上图6a和图6b,指令发送单元具体将所述触发指令发送至所述数据存储节点集,由所述数据存储节点集实现对所述目标业务的多个数据存储节点的故障检测。
这种情况下,上述故障检测模块93可以包括:
第二故障确定单元,用于由所述目标业务的多个数据存储节点通过心跳检测方式,确定故障的数据存储节点;
选举单元,用于当故障的数据存储节点包含所述目标业务的主分片,由按照选举机制,从所述目标业务的各备分片中选举出选举出新的主分片;
状态信息反馈单元,用于由所述目标业务的新的主分片所在的数据存储节点响应主控制节点发送的心跳请求,将当前所述目标业务的各分片的状态信息反馈至主控制节点;
路由信息接收单元,用于接收所述主控制节点反馈的所述目标业务的更新后的路由信息。
可选的,在上述实施例的基础上,如图11所示,该装置还可以包括:
状态信息获取模块95,用于获取故障的数据存储节点的当前状态信息;
***提示模块96,用于在所述当前状态信息表明所述故障的数据存储节点不可恢复,输出增加数据存储节点的***提示信息;
更新模块97,用于利用增加的数据存储节点包含的多个分片,更新各业务的备分片的数量。
另外,为了避免网络抖动造成的故障误判,上述装置还可以包括:
故障间隔检测模块,用于检测预设时间内连续确定故障的待测数据存储节点的数量是否达到预设数量;
故障核实模块,用于当故障间隔检测模块的检测结果为是,输出故障核实信息。
综上,本发明实施例提供的故障检测控制装置可以根据各业务的属性信息,确定相应的故障检测模式为各业务的目标故障检测模式,从而按照该目标故障检测模式,实现对相应业务的多个数据存储节点的故障检测,而不是按照固定不变的故障检测模式,实现对各种实现的业务的故障检测,提高了业务故障检测的灵活性,保证了业务能够及时恢复运行。
本发明实施例还提供了一种计算机设备,该计算机设备可通过执行相应程序,实现上述程序模块的功能;计算机设备可选用PC、智能手机、平板电脑等用户设备,或服务器实现,图12示出了计算机设备的一种可选硬件结构,参照图12,该计算机设备可以包括:至少一个处理芯片1,至少一个通信接口2,至少一个存储器3和至少一个通信总线4;
在本发明实施例中,处理芯片1、通信接口2、存储器3、通信总线4的数量为至少一个,且处理芯片1、通信接口2、存储器3通过通信总线4完成相互间的通信;
处理芯片1可能是一个中央处理器CPU,或者是特定集成电路ASIC
(Application Specific Integrated Circuit),或者是被配置成实施本发明实施例的一个或多个集成电路。
存储器3可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatilememory),例如至少一个磁盘存储器。
其中,存储器3存储有程序,处理芯片1调用存储器3所存储的程序,以实现上述所述的故障检测控制方法的步骤,关于故障检测控制方法的具体步骤可以参照上述方法实施例相应部分的描述,本实施例在此不作赘述。
本发明实施例还提供一种存储介质,该存储介质存储有适于处理芯片调用的程序,以实现上述所述的故障检测控制方法的步骤,关于故障检测控制方法的具体步骤可以参照上述方法实施例相应部分的描述,本实施例在此不作赘述。
上述处理芯片调用的程序、及存储介质存储的程序,主要实现如下功能:
获取目标业务的属性信息;
确定与所述目标业务的属性信息对应的目标故障检测模式;
按照所述目标故障检测模式,对实现所述目标业务的多个数据存储节点进行故障检测。
需要说明,上述处理芯片调用的程序、及存储介质存储的程序还可以实现其他功能,具体以参照上述故障检测控制方法实施例相应部分的描述,本实施例在此不作赘述。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理芯片执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的核心思想或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种故障检测控制方法,其特征在于,应用于分布式键值数据库,所述分布式键值数据库包含有控制节点集和数据存储节点集,所述数据存储节点集中的每一个数据存储节点存储有多个业务的数据,所述多个业务的数据通过不同分片进行区别,所述方法包括:
获取目标业务的属性信息;
确定与所述目标业务的属性信息对应的目标故障检测模式;
按照所述目标故障检测模式,对实现所述目标业务的多个数据存储节点进行故障检测。
2.根据权利要求1所述的方法,其特征在于,所述确定与所述目标业务属性信息对应的目标故障检测模式,包括:
输出多种故障检测模式;
响应选择指令,将被选择的故障检测模式作为目标业务的目标故障检测模式。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
获取不同类型的业务与多种故障检测模式之间的对应关系;
所述确定与所述目标业务的属性信息对应的目标故障检测模式,包括:
利用所述目标业务的属性信息,确定目标业务的类型;
利用所述对应关系,得到与所述目标业务的类型对应的目标故障检测模式。
4.根据权利要求1所述的方法,其特征在于,所述按照所述目标故障检测模式,对实现所述目标业务的多个数据存储节点进行故障检测,包括:
生成与所述目标故障检测模式对应的触发指令;
将所述触发指令发送至所述控制节点集或所述数据存储节点集,以使所述控制节点集或所述数据存储节点集实现对所述目标业务的多个数据存储节点的故障检测。
5.根据权利要求4所述的方法,其特征在于,所述控制节点集包括一主控制节点及若干备控制节点,所述控制节点集实现对所述目标业务的多个数据存储节点的故障检测的过程包括:
所述主控制节点对实现目标业务的待测数据存储节点进行心跳检测;
若所述主控制节点在预设时间内未接收到所述待测数据存储节点反馈的响应信号,向一备控制节点发送故障检测通知信息,由所述备控制节点对所述待测数据存储节点进行心跳检测;
若所述备控制节点在所述预设时间内未接收到所述待测数据存储节点反馈的响应信号,所述主控制节点确定所述待测数据存储节点故障;
当所述待测数据存储节点包含有所述目标业务的主分片,所述主控制节点从与所述主分片关联的至少一个备分片中,选择出新的主分片;
所述主控制节点对所述目标业务的路由信息进行更新,并将更新后的路由信息发送至所述目标业务对应的多个数据存储节点。
6.根据权利要求1所述的方法,其特征在于,所述方法还包括:
获取故障的数据存储节点的当前状态信息;
若所述当前状态信息表明所述故障的数据存储节点不可恢复,输出增加数据存储节点的***提示信息;
利用增加的数据存储节点包含的多个分片,更新各业务的备分片的数量。
7.根据权利要求4所述的方法,其特征在于,所述数据存储节点集实现对所述目标业务的多个数据存储节点的故障检测的过程包括:
所述目标业务的多个数据存储节点通过心跳检测方式,确定故障的数据存储节点;
若故障的数据存储节点包含所述目标业务的主分片,按照选举机制,从所述目标业务的各备分片中选举出新的主分片;
所述目标业务的新的主分片所在的数据存储节点响应主控制节点发送的心跳请求,将当前所述目标业务的各分片的状态信息反馈至所述控制节点集中的主控制节点;
接收所述主控制节点反馈的所述目标业务的更新后的路由信息,所述更新后的路由信息基于所述目标业务的各分片的状态信息得到。
8.根据权利要求5所述的方法,其特征在于,所述方法还包括:
检测预设时间内连续确定故障的待测数据存储节点的数量是否达到预设数量;
若预设时间内连续确定故障的待测数据存储节点的数量达到预设数量,输出故障核实信息。
9.一种故障检测控制装置,其特征在于,应用于分布式键值数据库,所述分布式键值数据库包含有控制节点集和数据存储节点集,且所述数据存储节点集中的每一个数据存储节点存储有多个业务的数据,所述多个业务的数据通过不同分片进行区别,所述装置包括:
属性信息获取模块,用于获取目标业务的属性信息;
目标故障检测模式确定模块,用于确定与所述目标业务的属性信息对应的目标故障检测模式;
故障检测模块,用于按照所述目标故障检测模式,对实现所述目标业务对应的多个数据存储节点进行故障检测。
10.一种计算机设备,其特征在于,所述计算机设备包括:至少一个存储器和至少一个处理芯片;所述存储器存储程序,所述处理芯片执行所述程序,以实现权利要求1-8任意一项所述的故障检测控制方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810974297.XA CN109308227B (zh) | 2018-08-24 | 2018-08-24 | 故障检测控制方法及相关设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810974297.XA CN109308227B (zh) | 2018-08-24 | 2018-08-24 | 故障检测控制方法及相关设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109308227A true CN109308227A (zh) | 2019-02-05 |
CN109308227B CN109308227B (zh) | 2021-04-27 |
Family
ID=65223968
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810974297.XA Active CN109308227B (zh) | 2018-08-24 | 2018-08-24 | 故障检测控制方法及相关设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109308227B (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111460029A (zh) * | 2020-03-11 | 2020-07-28 | 中移动信息技术有限公司 | 数据同步方法和装置 |
CN111541608A (zh) * | 2020-04-16 | 2020-08-14 | 腾讯科技(深圳)有限公司 | 一种网络通信的方法、***以及相关装置 |
CN111782137A (zh) * | 2020-06-17 | 2020-10-16 | 杭州宏杉科技股份有限公司 | 路径故障处理方法及装置 |
CN112583664A (zh) * | 2020-12-08 | 2021-03-30 | 广东荣文科技集团有限公司 | 数据处理方法及相关装置 |
CN112818411A (zh) * | 2021-01-22 | 2021-05-18 | 深圳市今日投资数据科技有限公司 | 数据检测方法及装置 |
CN113326212A (zh) * | 2020-02-28 | 2021-08-31 | 加特兰微电子科技(上海)有限公司 | 数据处理方法、装置及相关设备 |
CN113553244A (zh) * | 2020-04-24 | 2021-10-26 | 阿里巴巴集团控股有限公司 | 异常检测方法及设备 |
CN113609104A (zh) * | 2021-08-19 | 2021-11-05 | 京东科技信息技术有限公司 | 一种部分故障的键值对分布式存储***访问方法及装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5247664A (en) * | 1991-03-28 | 1993-09-21 | Amoco Corporation | Fault-tolerant distributed database system and method for the management of correctable subtransaction faults by the global transaction source node |
CN105930498A (zh) * | 2016-05-06 | 2016-09-07 | ***股份有限公司 | 一种分布式数据库的管理方法及*** |
CN106407083A (zh) * | 2016-10-26 | 2017-02-15 | 华为技术有限公司 | 故障检测方法及装置 |
CN107102929A (zh) * | 2017-05-23 | 2017-08-29 | 郑州云海信息技术有限公司 | 故障的检测方法及装置 |
CN107870829A (zh) * | 2016-09-24 | 2018-04-03 | 华为技术有限公司 | 一种分布式数据恢复方法、服务器、相关设备及*** |
-
2018
- 2018-08-24 CN CN201810974297.XA patent/CN109308227B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5247664A (en) * | 1991-03-28 | 1993-09-21 | Amoco Corporation | Fault-tolerant distributed database system and method for the management of correctable subtransaction faults by the global transaction source node |
CN105930498A (zh) * | 2016-05-06 | 2016-09-07 | ***股份有限公司 | 一种分布式数据库的管理方法及*** |
CN107870829A (zh) * | 2016-09-24 | 2018-04-03 | 华为技术有限公司 | 一种分布式数据恢复方法、服务器、相关设备及*** |
CN106407083A (zh) * | 2016-10-26 | 2017-02-15 | 华为技术有限公司 | 故障检测方法及装置 |
CN107102929A (zh) * | 2017-05-23 | 2017-08-29 | 郑州云海信息技术有限公司 | 故障的检测方法及装置 |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113326212A (zh) * | 2020-02-28 | 2021-08-31 | 加特兰微电子科技(上海)有限公司 | 数据处理方法、装置及相关设备 |
CN113326212B (zh) * | 2020-02-28 | 2023-11-03 | 加特兰微电子科技(上海)有限公司 | 数据处理方法、装置及相关设备 |
CN111460029A (zh) * | 2020-03-11 | 2020-07-28 | 中移动信息技术有限公司 | 数据同步方法和装置 |
CN111460029B (zh) * | 2020-03-11 | 2024-04-19 | 中移动信息技术有限公司 | 数据同步方法和装置 |
CN111541608A (zh) * | 2020-04-16 | 2020-08-14 | 腾讯科技(深圳)有限公司 | 一种网络通信的方法、***以及相关装置 |
CN111541608B (zh) * | 2020-04-16 | 2022-07-19 | 腾讯科技(成都)有限公司 | 一种网络通信的方法、***以及相关装置 |
CN113553244A (zh) * | 2020-04-24 | 2021-10-26 | 阿里巴巴集团控股有限公司 | 异常检测方法及设备 |
CN111782137A (zh) * | 2020-06-17 | 2020-10-16 | 杭州宏杉科技股份有限公司 | 路径故障处理方法及装置 |
CN112583664A (zh) * | 2020-12-08 | 2021-03-30 | 广东荣文科技集团有限公司 | 数据处理方法及相关装置 |
CN112818411A (zh) * | 2021-01-22 | 2021-05-18 | 深圳市今日投资数据科技有限公司 | 数据检测方法及装置 |
CN113609104A (zh) * | 2021-08-19 | 2021-11-05 | 京东科技信息技术有限公司 | 一种部分故障的键值对分布式存储***访问方法及装置 |
CN113609104B (zh) * | 2021-08-19 | 2023-11-03 | 京东科技信息技术有限公司 | 一种部分故障的键值对分布式存储***访问方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN109308227B (zh) | 2021-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109308227A (zh) | 故障检测控制方法及相关设备 | |
CN100417081C (zh) | 检查和修复网络配置的方法和*** | |
CN106878473A (zh) | 一种消息处理方法、服务器集群及*** | |
US7340578B1 (en) | Method and apparatus for maintaining an accurate inventory of storage capacity in a clustered data processing system | |
KR100575497B1 (ko) | 내고장성 컴퓨터 시스템 | |
CN106254100A (zh) | 一种数据容灾方法、装置和*** | |
CN109074362A (zh) | 分布式***中的拆分和移动范围 | |
CN102833281B (zh) | 一种分布式自增计数的实现方法、装置及*** | |
CN106933843A (zh) | 数据库心跳检测方法以及装置 | |
CN113625945A (zh) | 分布式存储的慢盘处理方法、***、终端及存储介质 | |
CN109144534A (zh) | 服务模块动态更新方法、装置及电子设备 | |
CN111694612A (zh) | 配置检查方法、装置、计算机***及存储介质 | |
CN110149366A (zh) | 提高集群***可用性的方法、装置和计算机设备 | |
CN114816820A (zh) | chproxy集群故障修复方法、装置、设备及存储介质 | |
CN107291575B (zh) | 一种数据中心故障时的处理方法和设备 | |
CN110928945B (zh) | 一种针对数据库的数据处理方法及装置,数据处理*** | |
CN115878052A (zh) | Raid阵列巡检方法、巡检装置和电子设备 | |
CN114064343B (zh) | 一种区块链的异常处置方法及装置 | |
CN116401122A (zh) | 分布式存储***节点故障的处理方法、***、装置及介质 | |
CN111694724A (zh) | 分布式表格***的测试方法、装置、电子设备及存储介质 | |
CN109241110A (zh) | 订单管理方法及***、电子设备、存储介质 | |
CN113055203B (zh) | Sdn控制平面的异常恢复方法及装置 | |
CN116938881B (zh) | 一种实现动态ip池的方法、***、设备及可读存储介质 | |
CN117270888B (zh) | 一种云端应用部署方法、***、装置及计算机设备 | |
JP2020135701A (ja) | 情報処理システム、情報処理装置および情報処理プログラム |
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 |