CN112328421A - 一种系统故障处理方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请实施例公开了一种可以用于故障检测的系统故障处理方法、装置、计算机设备和存储介质，可以向服务系统中的各服务节点定期发送心跳探测请求；当服务节点对心跳探测请求的响应不满足预设响应条件时，确定服务节点为待判断节点，确定在节点管理信息中待判断节点的节点状态为暂定故障状态；从第二故障处理节点获取待判断节点的节点状态；若待判断节点的节点状态中暂定故障状态的数量不低于预设阈值，将节点管理信息中待判断节点的节点状态，确定为故障状态；对故障状态的服务节点进行相应的故障处理，由此，可以快速确定服务系统中出现故障的服务节点，从而提升对故障的服务节点的处理速度，有利于保证服务系统的正常运行。

Description

一种系统故障处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，具体涉及一种系统故障处理方法、装置、计算机设备和存储介质。

背景技术

目前，很多服务系统包括多个服务节点，不同的服务节点都可以进行数据的存储，搜索和处理等等功能，例如检索系统，包括主节点和从节点等，为了服务系统的正常服务，需要能够及时确定服务节点中的故障节点，然后进行相应的故障处理。

相关技术中，对服务系统中服务节点的检测一般由人工进行，这种人工检测方式具有滞后性，一旦重要的服务节点发生故障容易导致整个系统不能正常提供服务，对于检索系统，尤其是处于实时性要求较高的检索场景中的检索系统，这种滞后性会带来灾难性的结果，不利于服务系统的快速恢复。

发明内容

本发明实施例提供一种系统故障处理方法、装置、计算机设备和存储介质，可以快速确定服务系统中出现故障的服务节点，从而提升对故障的服务节点的处理速度，有利于保证服务系统的正常运行。

本发明实施例提供一种系统故障处理方法，应用于服务系统中的第一故障处理节点，所述第一故障处理节点为所述服务系统中任一故障处理节点，该方法包括：

向所述服务系统中的各服务节点定期发送心跳探测请求，其中，所述服务系统还包括至少一个第二故障处理节点；

当服务节点对所述心跳探测请求的响应不满足预设响应条件时，确定所述服务节点为待判断节点，确定在节点管理信息中所述待判断节点的节点状态为暂定故障状态；

从第二故障处理节点获取所述待判断节点的节点状态，其中，所述第二故障处理节点为所述服务系统中除了所述第一故障处理节点之外的其他故障处理节点；

若所述待判断节点的节点状态中所述暂定故障状态的数量不低于预设阈值，将所述节点管理信息中所述待判断节点的节点状态，确定为故障状态；

对故障状态的服务节点进行相应的故障处理。

本发明实施例提供一种系统故障处理装置，应用于服务系统中的第一故障处理节点，所述第一故障处理节点为所述服务系统中任一故障处理节点，该装置包括：

心跳探测请求单元，用于向所述服务系统中的各服务节点定期发送心跳探测请求，其中，所述服务系统还包括至少一个第二故障处理节点；

主观下线检测单元，用于当服务节点对所述心跳探测请求的响应不满足预设响应条件时，确定所述服务节点为待判断节点，确定在节点管理信息中所述待判断节点的节点状态为暂定故障状态；

获取单元，用于从第二故障处理节点获取所述待判断节点的节点状态，其中，所述第二故障处理节点为所述服务系统中除了所述第一故障处理节点之外的其他故障处理节点；

客观下线检测单元，用于若所述待判断节点的节点状态中所述暂定故障状态的数量不低于预设阈值，将所述节点管理信息中所述待判断节点的节点状态，确定为故障状态；

故障处理单元，用于对故障状态的服务节点进行相应的故障处理。

在一个示例中，服务节点包括主节点和从节点，该系统故障处理装置还包括节点连接单元，用于在第一故障处理节点启动时，从配置信息中获取所述主节点的主节点信息；基于所述主节点信息建立与所述主节点的心跳连接，并基于所述心跳连接从所述主节点获取所述从节点的从节点信息；基于所述从节点的从节点信息，建立与所述从节点的心跳连接。

在一个示例中，若所述故障状态的服务节点为从节点，故障处理单元，用于向所述第二故障处理节点发送故障通知信息，所述故障通知信息用于触发所述第二故障处理节点将节点管理信息中所述待判断节点的节点状态更新为故障状态。

在一个示例中，若所述故障状态的服务节点为主节点，故障处理单元305，用于向所述第二故障处理节点发送首领选择请求，触发所述第二故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方，所述选择结果信息中包括全局故障处理节点的标识信息；接收选择结果信息，若基于所述选择结果信息确定所述第一故障处理节点被选择为全局故障处理节点，从所述从节点中选择新的主节点；向旧的主节点的其他从节点发送第一主节点切换信息，使得所述其他从节点从所述新的主节点进行数据同步。

在一个示例中，所述服务系统还包括服务代理模块，所述系统故障处理装置还包括主节点注册单元，用于在从配置信息中获取所述主节点的主节点信息后，基于所述主节点信息，将所述主节点注册到管理系统中，以便所述服务代理模块基于所述管理系统确定所述服务系统的主节点；

主节点注册单元，还用于在故障处理单元从所述从节点中选择新的主节点后，将所述管理系统中注册的主节点更新为所述新的主节点，以便所述服务代理模块接收到客户端发送的服务请求后，将所述服务请求转发至所述新的主节点进行处理。

在一个示例中，故障处理单元，用于：

从所述第二故障处理节点中，确定与所述第一故障处理节点具有相同选择次数的第二故障处理节点，作为所述第一故障处理节点的选民故障处理节点，其中，所述选择次数表示故障处理节点参与选择全局故障处理节点的次数；

向选民故障处理节点发送首领选择请求，触发所述选民故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方；

对所述第一故障处理节点的选择次数加一；

接收所述选民故障处理节点发送的选择结果信息，从所述选择结果信息中读取全局故障处理节点的标识信息，基于所述标识信息更新所述第一故障处理节点被选择为全局故障处理节点的被选票数；

当被选票数超过预设票数阈值时，确定所述第一故障处理节点为全局故障处理节点，从所述从节点中选择新的主节点。

在一个示例中，故障处理单元，用于向选民故障处理节点发送首领选择请求，触发所述选民故障处理节点将第一个接收到的首领选择请求对应的发送方，确定为具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至接收到的所有首领选择请求的发送方。

在一个示例中，系统故障装置还包括哨兵保活单元，用于向所述管理系统定期发送心跳探测请求，以避免所述管理系统在哨兵管理信息中删除所述第一故障处理节点；

故障处理单元，用于从所述管理系统中获取所述第二故障处理节点的处理节点信息，所述处理节点信息包括选择次数；基于所述处理节点信息确定与所述第一故障处理节点具有相同选择次数的第二故障处理节点，作为所述第一故障处理节点的选民故障处理节点。

在一个示例中，故障处理单元，用于：

从所述从节点中确定处于非故障状态的从节点作为候选从节点；

基于所述候选从节点的节点性能，从所述候选从节点中选择待定从节点；

从所述待定从节点中选择新的主节点。

在一个示例中，故障处理单元，用于：

从所述候选从节点中去除第一候选从节点，其中，所述第一候选从节点为在距离当前时刻的历史预设时长内未回复所述第一故障处理节点的从节点；

从所述候选从节点中去除第二候选从节点，其中，所述第二候选从节点为与旧的主节点断开同步链路超过预设时长阈值的从节点；

将剩余的候选从节点确定为待定从节点。

在一个示例中，所述主节点和从节点设置有优先级，故障处理单元，用于：

从所述待定从节点中选择所述优先级最高的从节点作为新的主节点；

若所述优先级最高的从节点有多个，从所述优先级最高的从节点中选择同步数据最完整的从节点作为新的主节点，所述同步数据为从节点从对应的主节点同步的数据；

若所述同步数据最完整的从节点有多个，从所述同步数据最完整的从节点中选择运行次数最小的从节点作为新的主节点；

若所述运行次数最小的从节点有多个，从所述运行次数最小的从节点中随机选择一个从节点作为新的主节点。

在一个示例中，系统故障装置还包括故障节点恢复单元，用于当所述故障状态的服务节点从所述故障状态恢复为正常工作状态时，通过与所述服务节点的心跳连接，向所述服务节点发送第二主节点切换信息，以便所述服务节点作为当前的主节点的从节点，基于所述当前的主节点进行数据同步。

在本发明的一些实施例中，还可以提供一种计算机设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如上所述方法的步骤。

在本发明的一些实施例中，还可以提供一种存储介质，其上存储有计算机程序，当计算机程序在计算机上运行时，使得所述计算机执行如如上所述方法的步骤。

采用本申请实施例，第一故障处理节点可以向服务系统中的各服务节点定期发送心跳探测请求，其中，服务系统还包括至少一个第二故障处理节点；当服务节点对心跳探测请求的响应不满足预设响应条件时，确定服务节点为待判断节点，确定在节点管理信息中待判断节点的节点状态为暂定故障状态；从第二故障处理节点获取待判断节点的节点状态，其中，第二故障处理节点为服务系统中除了第一故障处理节点之外的其他故障处理节点；若待判断节点的节点状态中暂定故障状态的数量不低于预设阈值，将节点管理信息中待判断节点的节点状态，确定为故障状态；对故障状态的服务节点进行相应的故障处理，基于故障处理节点的设置，可以快速确定服务系统中出现故障的服务节点，从而提升对故障的服务节点的处理速度，有利于保证服务系统的正常运行。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1a是本发明实施例提供的系统故障处理方法的流程图；

图1b是本发明实施例提供的服务系统的结构示意图；

图2a是本发明实施例提供的故障处理节点的初始化方法的流程图；

图2b是本发明实施例提供的故障处理节点对主节点、从节点和故障处理节点自身的健康检查方法的流程图；

图2c是本发明实施例提供的故障处理节点对服务节点的客观下线判断方法的流程图；

图2d是本发明实施例提供的全局故障处理节点的选举方法的流程图；

图2e是本发明实施例提供的主节点的故障转移方法的流程图；

图3是本发明实施例提供的系统故障处理装置的结构示意图；

图4是本发明实施例提供的计算机设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供一种系统故障处理方法、装置、计算机设备和存储介质。

其中，系统故障处理方法适用于服务系统，服务系统包括多个服务节点以及至少两个故障处理节点，每个服务节点设置有对应的数据库，其中，服务节点可以是由计算机设备组成，该计算机设备可以为服务器等设备。

本实施例中系统故障处理装置可以集成在服务系统中，系统故障处理装置可以由计算机设备实现，该计算机设备可以为服务器等设备。

其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。

本实施例的系统故障处理装置可以集成在服务器中，可选的，可以以应用程序等形式集成于服务器中。

本实施例提供的系统故障处理方法可以包括：

向服务系统中的各服务节点定期发送心跳探测请求，其中，服务系统还包括至少一个第二故障处理节点；

当服务节点对心跳探测请求的响应不满足预设响应条件时，确定服务节点为待判断节点，确定在节点管理信息中待判断节点的节点状态为暂定故障状态；

从第二故障处理节点获取待判断节点的节点状态，其中，第二故障处理节点为服务系统中除了第一故障处理节点之外的其他故障处理节点；

若待判断节点的节点状态中暂定故障状态的数量不低于预设阈值，将节点管理信息中待判断节点的节点状态，确定为故障状态；

对故障状态的服务节点进行相应的故障处理。

以下分别进行详细说明。需说明的是，以下实施例的描述顺序不作为对实施例优选顺序的限定。

本发明实施例将从系统故障处理装置的角度进行描述，该系统故障处理装置具体可以集成在服务器中，例如，可以以应用程序的形式集成在服务器中。

本发明实施例提供的一种系统故障处理方法，该方法可以由服务器的处理器执行，该系统故障处理方法可以应用于服务系统，服务系统包括至少两个服务节点，本实施例的服务系统可以是检索系统，该检索系统可以用于在基于CV(Computer Vision,计算机视觉)技术的智慧零售商场中的人脸身份检索、客流检索等高可用检索场景，引入本实施例的方案后将为整个智慧零售系统提供更加实时性、数字化、高可用的检索信息，以便商场和店铺根据客流变动和顾客提醒类型制定更为合理的经营决策从而助力客户营收的提高。

如图1a所示，该系统故障处理方法的流程可以如下：

101、向服务系统中的各服务节点定期发送心跳探测请求，其中，服务系统还包括至少一个第二故障处理节点；

本实施例中的服务系统的类型和功能不限，可以是检索系统等等，该检索系统可以提供各种类型的检索服务，例如1:N人体轨迹检索以及1：N人脸检索等等，其中，1:N人体轨迹检索为：在大规模人体轨迹数据库中找出与待检索人体轨迹相似度最高的一个或多个人体轨迹。1：N人脸检索为：在大规模人脸数据库中找出与待检索人脸相似度最高的一个或多个人脸。检索性能与库规模N大小相关。

本实施例中的服务系统可以基于云技术(Cloud technology)实现，云技术(Cloudtechnology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

本实施例中的服务系统可以是云服务系统，服务节点可以基于云技术部署成云服务系统中的云节点。

本实施例的该服务系统中的服务节点可以是具有不同功能的服务节点，或者是具有相同功能的服务节点，例如该服务节点包括主节点和从节点，主节点用于处理客户端向服务器系统发起的服务请求，从节点从主节点中同步数据保持数据一致性，当主节点发生故障时，从节点可以变为主节点接替主节点响应客户端的服务请求。

下面以服务系统为检索系统为例，结合图1b，对服务系统的结构和功能进行描述，参考图1b，服务系统包括(检索)主节点和(检索)从节点以及服务代理模块，其中，主节点和从节点都设置有用于存储数据的数据库，主节点的数据库为主库，从节点的数据库为从库。

上述服务代理模块面向客户端，可以接收客户端发送的服务请求如检索请求，完成检索请求过滤，以及检索请求的分发，一般的，检索请求会被服务代理模块发送至主节点，由主节点进行响应给出响应结果，服务代理模块会将响应结果发送给客户端。其中，服务请求还可以包括读类请求，服务代理模块可以根据各个节点的负载合理选择处理读请求的节点，实现读类请求的负载均衡。

其中，从节点和主节点之间建立有连接，从节点可以与主节点进行数据同步，尽量保证从库中的数据与主库中的数据的一致性，使得主节点需要切换时，能够确定同步性较好的从节点接替主节点工作。

为了更好地管理主从节点，实现主从节点的快速故障检测和故障转移，参考图1b。本实施例的服务系统中还增设了故障处理层和管理系统，该故障处理层包括至少两个故障处理节点，如图1b中的故障处理节点1-3。该管理系统可以是ETCD(一个高可用的Key/Value存储系统，主要用于分享配置和服务发现)系统或者其他可用的系统，本实施例对此没有限制。其中，故障处理节点可以是具有故障发现和处理功能的装置，故障处理节点可以基于相关技术中的哨兵技术设置，每一个故障处理节点可以视为一个哨兵节点。

本实施例中，故障处理节点可以分为第一故障处理节点和第二故障处理节点，这两种故障处理节点只是一种相对的概念，即故障处理层中的任意一个故障处理节点都可以视为第一故障处理节点，对于某个第一故障处理节点而言，故障处理层中的其他故障处理节点可以视为该第一故障处理节点对应的第二故障处理节点。所以可以理解的是，在某些示例中，第二故障处理节点中的故障处理节点也可以被视为第一故障处理节点。

例如，故障处理层包括8个故障处理节点A1-A8，假设在一个示例中，A1为第一故障处理节点，则A2-A8是第二故障处理节点，在另一示例中，A2为第一故障处理节点，A1、A3-A8为第二故障处理节点。

所以，故障处理层的每一个故障处理节点都可以被视为第一故障处理节点，从而执行本实施例中系统故障处理方法的步骤。

本实施例的ETCD内部可以采用raft协议作为一致性算法，可以实现服务注册发现、负载均衡、基于watcher的分布式通知等功能。raft算法是一种典型的分布式环境首领选举算法。本实施例的管理系统与服务代理模块连接，第一故障处理节点可以将主节点注册到管理系统中，具体的可以将主节点的节点地址注册到管理系统中，以便服务代理模块确定检索系统的主节点。本实施例中管理系统中设置有哨兵过期机制，即在一定的检测时长(可配置)内没有接收到故障处理节点(包括第一故障处理节点和第二故障处理节点)的心跳探测请求，则确定故障处理节点过期，将哨兵管理信息中该故障处理节点的信息清除，对应的，故障处理节点会周期性地向管理系统发送心跳，以便管理系统将故障处理节点确定为正常工作的故障处理节点，避免管理系统将该故障处理节点清除。

本实施例中，第一故障处理节点与服务节点之间的心跳探测请求，一个重要作用是探测第一故障处理节点与服务节点之间的心跳连接是否正常，当然，可以理解的是，心跳探测请求中还可以携带其他需要的信息。

每个第一故障处理节点与主从节点之间会建立心跳连接，第一故障处理节点基于心跳连接会周期性从服务节点读取心跳信息，该心跳信息包括服务节点的复制偏置量、从节点优先级等信息，第一故障处理节点可以进行服务节点的故障判断如下线判断以及之后的故障转移、故障转移成功后新主节点的管理系统注册以及基于ETCD哨兵过期机制的哨兵注册发现。

为了便于理解本实施例的方案，在此介绍本实施例涉及的几个主要概念：

1、运行ID。每个服务节点或故障处理节点在服务启动时都会自动生成一个唯一ID，用以区分不同运行的进程，服务节点或故障处理节点每启动一次运行ID就增加1。运行ID可以理解为服务节点和故障处理节点对应的进程的启动次数。

2、复制偏置量offset。同步数据的偏移量，主从节点都会维护一个已成功同步数据的复制偏置offset。主节点每次接收M字节检索请求后，都会将字节的同步偏移量也即offset加M。从节点每次收到从主节点同步M字节数据后都会更新从节点的同步偏移量也即offset。

3、从节点优先级。每个服务节点都设置有从节点优先级，该从节点优先级指的是该服务节点作为从节点时的优先级，该优先级一般通过配置文件指定，可以根据节点所在机器资源如计算资源、存储资源等确定。其中，优先级越小排名越靠前。该从节点优先级在第一故障处理节点进行故障转移选取新的主节点时发挥作用。

4、选择次数。故障处理节点选举全局故障处理节点的计数器，故障处理节点每参与一次全局故障处理节点选择(无论是选择还是被选择)时，无论该次是否成功选出全局故障处理节点，该选择次数的值都会自增一次，初始值为1。

本实施例的系统故障管理方案包括至少四个方面：

第一方面、启动初始化：启动初始化主要是故障处理服务根据配置建立第一故障处理节点与主从节点心跳连接以及注册主节点和可用故障处理节点到ETCD；

第二方面、运行时健康检查：主要是通过第一故障处理节点定期心跳机制，完成第一故障处理节点对主从节点服务的健康检查以及第一故障处理节点自身健康状态的更新；

第三方面、下线判断：主要是联合第一故障处理节点的主观下线判断和多个故障处理节点(包括第一故障处理节点和第二故障处理节点)投票的客观下线判断，进行服务节点的故障状态(如下线)的判断，避免第一故障处理节点误判引起的不必要故障转移(如主节点切换)带来的开销；

第四方面、故障处理：包括基于raft算法的全局故障处理节点选择以及基于多层次过滤的服务节点的主从故障转移，保证所选出的新主节点数据最完整、最新，将故障转移带来的损失降到最低。

步骤101-105主要涉及第二至四方面的方案。

本实施例中，在启动初始化阶段，第一故障处理节点可以建立与主从节点的心跳连接。可选的，步骤101之前，还可以包括：

在第一故障处理节点启动时，从配置信息中获取主节点的主节点信息；

基于主节点信息建立与主节点的心跳连接，并基于心跳连接从主节点获取从节点的从节点信息；

基于从节点的从节点信息，建立与从节点的心跳连接。

其中，第一故障处理节点的配置信息可以预先写入故障处理节点(对应的存储空间)中，第一故障处理节点在启动后可以自动读取配置信息，从而获取主节点的主节点信息。其中该主节点的主节点信息包括但不限于主节点地址等等。第一故障处理节点可以基于主节点地址建立与主节点的心跳连接。

上述基于心跳连接从主节点获取从节点的从节点信息的具体方案可以包括：基于与主节点的心跳连接，向主节点发送心跳探测请求(可以称为第一心跳探测请求)，接收主节点响应于心跳探测请求发送的主节点属性信息，该主节点属性信息包括但不限于复制偏置量offset、运行ID、从节点的从节点信息等等。

本实施例的从节点信息包括但不限于从节点地址，第一故障处理节点可以基于从节点地址建立与从节点的心跳连接。在建立心跳连接之后，第一故障处理节点可以向从节点发送心跳探测请求(可以称为第二心跳探测请求)，接收从节点响应于心跳探测请求发送的从节点属性信息，该从节点属性信息包括但不限于运行ID、复制偏置量offset、从节点优先级等信息，故障处理节点接收该从节点属性信息后，可以将该从节点属性信息存储至自身的节点管理信息中。

本实施例中，每个故障处理节点都可以与所有的服务节点建立心跳连接。所以可以理解的是，故障处理节点的节点管理信息中包含所有服务节点的节点属性信息。

本实施例中，步骤“从配置信息中获取主节点的主节点信息”后，还可以包括：

基于主节点信息，将主节点注册到管理系统中，以便服务代理模块基于管理系统确定服务系统的主节点。

其中，若第一故障处理节点与主节点的心跳连接失败，则第一故障处理节点可以向管理系统发送主节点删除信息，触发管理系统将该主节点的信息删除。

本实施例中，故障处理层的故障处理节点的数量为多个，在一个示例中，可以设置某一个故障处理节点为注册故障处理节点，若第一故障处理节点为注册故障处理节点，在第一故障处理节点启动后的主节点注册流程中，由第一故障处理节点将主节点注册到管理系统中，在注册成功后，第一故障处理节点还可以将注册成功的信息发送给对应的第二故障处理节点，以触发第二故障处理节点建立与主节点的连接。

在另一个示例中，每一个故障处理节点在启动后，都可以向ETCD发送主节点注册信息，该主节点注册信息包括主节点地址，ETCD可以在接收第一个主节点注册信息后进行主节点注册，向发送该主节点注册信息的故障处理节点发送主节点注册成功的信息，以及在接收到其他主节点注册信息后，直接向对应的故障处理节点发送主节点注册成功的信息。故障处理节点在接收到主节点注册成功的信息后，可以进入与主节点的心跳连接建立过程。

其中，第一故障处理节点还可以定期向管理系统发送心跳探测请求(可以称为第三心跳探测请求)，该心跳探测请求中可以携带第一故障处理节点的地址信息，避免管理系统认为与第一故障处理节点的心跳连接过期而在哨兵管理信息中删除第一故障处理节点。其中，管理系统接收到第一故障处理节点的心跳探测请求后，可以更新哨兵管理信息中该第一故障处理节点的地址信息，从而保持第一故障处理节点的地址信息的有效性。当然，如果管理系统未接收到某第一故障处理节点的心跳探测请求的连续时长，超过预设时长阈值(可配置)，则管理系统可以确定该第一故障处理节点过期，从哨兵管理信息中删除该第一故障处理节点的信息。

其中，第一、二、三心跳探测请求中携带的信息可以不同。三种请求的作用可以不完全相同。

下面结合图2a，对第一故障处理节点的启动初始化阶段的方案进行详细的描述，参考图2a，第一故障处理节点的启动初始化方法包括步骤201-214：

201、在启动后读取配置信息，从配置信息中获取第一故障处理节点需要监督的主节点的主节点信息；

202、基于主节点信息注册主节点到ETCD系统；

203、建立与主节点的心跳连接；

204、向主节点发送第一心跳探测请求，该第一心跳探测请求中携带从节点信息获取请求；

205、判断主节点是否正常响应该第一心跳探测请求，若是，则进入步骤206，若否，则进入步骤207；

其中，若在第一心跳探测请求的发送时刻之后的预设主节点响应时长内，第一故障处理节点接收到主节点发送的响应于第一心跳探测请求的主节点响应信息，则确定主节点正常响应该第一心跳探测请求。

206、解析主节点响应信息，获取复制偏置offset以及主节点对应的从节点的从节点信息，进入步骤208；

207、删除ETCD中注册的主节点；

208、判断响应信息中是否包含从节点信息，若是，则进入步骤209，若否，则进入步骤212；

209、基于从节点信息建立与从节点的心跳连接；

210、基于与从节点的心跳连接向从节点发送第二心跳探测请求，该第二心跳探测请求中携带属性信息获取请求；

211、判断从节点是否正常响应该第二心跳探测请求，若是，则进入步骤212，若否，则进入步骤207；

其中，若在第二心跳探测请求的发送时刻之后的预设从节点响应时长内，第一故障处理节点接收到该从节点发送的响应于第二心跳探测请求的从节点响应信息，则确定从节点正常响应该第二心跳探测请求。

212、解析从节点响应信息，获取并缓存复制偏置和从节点优先级；

213、发送第一故障处理节点的地址信息至ETCD系统。

102、当服务节点对心跳探测请求的响应不满足预设响应条件时，确定服务节点为待判断节点，确定在节点管理信息中待判断节点的节点状态为暂定故障状态；

其中，有效响应条件可以根据实际需要设置，例如设置为服务节点针对心跳探测请求的响应时长不超过第一预设响应时长阈值，和/或服务节点针对心跳探测请求的响应信息中包含特定信息，和/或服务节点针对心跳探测请求的连续未响应时长不超过第二预设响应时长阈值。

其中，该特定信息可以根据实际需求设置，例如该特定信息包括复制偏置、运行ID等等。又例如，特定信息还可根据主节点和从节点分别进行设置，从节点对应的特定信息还可以包括从节点优先级。

其中，主节点和从节点对应的第一预设响应时长阈值可以不同，第二预设响应时长阈值可以不同。

本实施例中，上述步骤101-102，可以视为第一故障处理节点服务运行时的运行健康检查的一部分，可以快速发现疑似故障的服务节点，从而确定出故障状态(如下线状态)的服务节点。

本实施例中，将结合图2b对主节点、从节点以及第一故障处理节点的健康检查方案进行详细描述。

可选的，参考图2b，主节点的健康检查方法包括：

301、第一故障处理节点向主节点定期发送第一心跳探测请求；

303、第一故障处理节点确定主节点针对第一心跳探测请求的响应是否正常，是，则进入步骤303，否，则进入步骤306；

303、第一故障处理节点解析主节点针对第一心跳探测请求的响应信息，获取响应信息中的主节点的复制偏置以及对应的从节点的从节点信息；

其中，该响应信息中还可以包括其他的信息，如主节点的运行ID等，本实施例对此没有限制。

304、第一故障处理节点基于从节点信息更新自身的节点管理信息中的从节点信息；

305、第一故障处理节点进行与从节点的心跳检查。

306、第一故障处理节点不断向主节点发送第一心跳探测请求；

307、第一故障处理节点确定主节点针对第一心跳探测请求的连续未响应时长是否超过第二预设响应时长阈值，若否，则进入步骤303，若是，则进入步骤308；

308、第一故障处理节点在节点管理信息中记录该主节点的节点状态为暂定故障状态。

其中，该暂定故障状态可以理解为第一故障处理节点主观上确定的下线状态，即主观下线状态。

可选的，参考图2b，从节点的健康检查方法包括：

401、第一故障处理节点向从节点定期发送第二心跳探测请求；

403、第一故障处理节点确定从节点针对第二心跳探测请求的响应是否正常，是，则进入步骤403，否，则进入步骤406；

403、第一故障处理节点解析从节点针对第二心跳探测请求的响应信息，获取从节点属性信息；

其中，从节点属性信息可以包括从节点的复制偏置以及从节点优先级以及其他的信息，如从节点的运行ID等，本实施例对此没有限制。

404、第一故障处理节点基于从节点属性信息更新自身的节点管理信息中的从节点属性信息；

405、第一故障处理节点进行与ETCD的心跳检查。

406、第一故障处理节点不断向从节点发送第二心跳探测请求；

407、第一故障处理节点确定从节点针对第二心跳探测请求的连续未响应时长是否超过第二预设响应时长阈值，若否，则进入步骤403，若否，则进入步骤408；

408、第一故障处理节点在节点管理信息中记录该从节点的节点状态为暂定故障状态。

可选的，参考图2b，第一故障处理节点的健康检查方法包括：

501、第一故障处理节点定期向ETCD发送第三心跳探测请求，该第三心跳探测请求中携带有第一故障处理节点的地址信息；

502、ETCD检测未接收到第一故障处理节点的第三心跳探测请求的连续时长，是否超过哨兵心跳时长阈值，若是，则进入步骤503，若否，则进入步骤504；

503、ETCD删除哨兵管理信息中该第一故障处理节点的信息；

504、ETCD基于第三心跳探测请求更新第一故障处理节点的地址信息。

该运行时的健康检查主要完成运行过程中主从节点的运行状态检查，及时发现不可用节点以进行故障处理。

本实施例中，第一故障处理节点对主节点、从节点以及第一故障处理节点自身的健康检查可以不具有上述的先后触发关系，即第一故障处理节点对主节点、从节点以及第一故障处理节点自身的健康检查方案可以是相互独立的。

103、从第二故障处理节点获取待判断节点的节点状态，其中，第二故障处理节点为服务系统中除了第一故障处理节点之外的其他故障处理节点；

本实施例中，第一故障处理节点可以从管理系统中获取第二故障处理节点的地址信息，基于该地址信息与第二故障处理节点分别建立投票连接以进行客观下线投票。

可选的，步骤“从第二故障处理节点获取待判断节点的节点状态”，可以包括：

从管理系统中获取第二故障处理节点的地址信息，基于该地址信息与第二故障处理节点分别建立投票连接；其中，该投票连接可以理解为用于与第二故障处理节点进行通信的连接；

基于投票连接向第二故障处理节点发送投票请求，投票请求用于询问第二故障处理节点该待判断节点是否为暂定故障状态；

接收第二故障处理节点响应于投票请求反馈的投票信息，该投票信息包括该待判断节点的状态标识信息，该状态标识信息用于标识待判断节点是否为暂定故障状态。

可选的，本实施例的暂定故障状态可以理解为服务节点的下线状态，投票请求用于询问其他装置该待判断节点是否下线。

104、若待判断节点的节点状态中暂定故障状态的数量不低于预设阈值，将节点管理信息中待判断节点的节点状态，确定为故障状态；

其中，待判断节点的节点状态中的暂定故障状态，指的是管理系统中所有在线的故障处理节点(包括第一故障处理节点和第二故障处理节点)的节点管理信息中，待判断节点的节点状态中的暂定故障状态。

预设阈值可以根据实际需要设置，例如，设置为在线故障处理节点的数量一半等等。

可以理解的是，本实施例中，每一个故障处理节点都可以视为第一故障处理节点，并且将服务系统中除该第一故障处理节点外的其他故障处理节点视为该第一故障处理节点对应的第二故障处理节点，所以某一个第一故障处理节点也可能是服务系统中不同于该第一故障处理节点的某故障处理节点，所对应的第二故障处理节点，所以本实施例的第一故障处理节点也会接收到其他故障处理节点发送的投票请求。

本实施例的方法还包括：当第一故障处理节点接收到其他故障处理节点发送的投票请求后，基于投票请求确定待判断节点，获取该第一故障处理节点的节点管理信息中该待判断节点的节点状态，基于该节点状态向投票请求的发送方发送投票信息。

其中，服务节点的该故障状态为所有在线的故障处理节点投票产生，所以可以理解的是，该故障状态可以理解为客观下线状态。

105、对故障状态的服务节点进行相应的故障处理。

本实施例中，对于服务节点为主节点和从节点的不同情况，故障处理的具体方案不同。当故障状态的服务节点为从节点时，可以更新所有第二故障处理节点中该从节点的节点状态，当故障状态的服务节点为主节点时，进入全局故障处理节点选择和故障转移步骤。

下面结合图2c，对服务节点的故障状态的判断方法进行示例说明。

参考图2c，服务节点的故障状态的判断方法包括：

601、当第一故障处理节点检测到待判断节点为主观下线后，通过ETCD获取当前检索系统中所有在线的第二故障处理节点的信息；

其中，第一故障处理节点和在线的第二故障处理节点可以视为构成集群。

602、当第一故障处理节点检测到待判断节点为主观下线后，通过ETCD获取当前检索系统中所有在线的第二故障处理节点的信息。

603、第一故障处理节点通过投票连接询问第二故障处理节点此待判断节点是否下线；

604、当某第二故障处理节点收到询问后会查询节点管理信息中该待判断节点的节点状态并返回该节点状态(或节点状态标识)至对应的第一故障处理节点；

605、第一故障处理节点统计待判断节点的节点状态为下线状态的数量；

606、若下线状态的数量超过当前集群内的故障处理节点(所有在线的故障处理节点)数目的一半(阈值，可配置)，该第一故障处理节点将此待判断节点的节点状态更改为客观下线状态；

607、第一故障处理节点判断待判断节点是否为主节点，若是，则进入步骤608、若否，则进入步骤609；

608、通知集群中第二故障处理节点更新从节点的信息；

其中，可以更新从节点的节点状态。

609、若该节点为检索主节点，则第一故障处理节点触发全局故障处理节点选举与故障处理流程。

上述的节点下线状态的判断，在针对单个哨兵节点的主观判断的基础上，引入了基于投票机制的多哨兵节点联合判断，避免单个哨兵带来的误判。

可选的，当故障状态的服务节点为从节点时，步骤“对故障状态的服务节点进行相应的故障处理”，可以包括：

向第二故障处理节点发送故障通知信息，故障通知信息用于触发第二故障处理节点将节点管理信息中，待判断节点的节点状态更新为故障状态。

在本实施例中，当确定待判断节点为故障状态的第一故障处理节点的数量为至少两个时，每个该第一故障处理节点都可以向其他故障处理节点发送故障通知信息。

可选的，当故障状态的服务节点为主节点，步骤“对故障状态的服务节点进行相应的故障处理”，可以包括：

向第二故障处理节点发送首领选择请求，触发第二故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方，选择结果信息中包括全局故障处理节点的标识信息；

接收选择结果信息，若基于选择结果信息确定第一故障处理节点被选择为全局故障处理节点，从从节点中选择新的主节点；

向旧的主节点的其他从节点发送第一主节点切换信息，使得其他从节点从新的主节点进行数据同步。

本实施例中，主节点故障处理权限，可以理解为对出现故障状态的主节点进行故障处理如故障转移的权限，如当出现故障状态的主节点时，从从节点中选择新的主节点替代该故障状态的节点的权限。

其中，第一故障处理节点可以向各个第二故障处理节点都发送首领选择请求，也可以先确定第二故障处理节点中在线(在管理系统中)的故障处理节点，然后向这些在线的第二故障处理节点都发送首领选择请求。在一个示例中，该首领选择请求可以携带有该发送请求的故障处理节点的标识信息，该标识信息可以包括故障处理节点的选择次数，运行ID等信息。

在一个示例中，全局故障处理节点的标识信息可以包括全局故障处理节点的选择次数，运行ID等信息。

本实施例的全局故障处理节点基于第二故障处理节点的选择确定，当发送首领选择请求的第一故障处理节点的数量为至少两个时，每个发送首领选择请求的第一故障处理节点，也可能会接收其他第一故障处理节点发送的首领选择请求。

可选的，在第一故障处理节点从从节点中选择新的主节点后，本实施例的方法还可以包括：

将管理系统中注册的主节点更新为新的主节点，以便服务代理模块接收到客户端发送的服务请求后，将服务请求转发至新的主节点进行处理。

其中，故障处理节点可以将管理系统中注册的主节点的节点地址更新为新的主节点的节点地址。

可选的，本实施例的所有故障处理节点具有选择次数这一属性，该选择次数表示故障处理节点参与选择全局故障处理节点的次数。

可选的，步骤“向第二故障处理节点发送首领选择请求，触发第二故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方”，可以包括：

从第二故障处理节点中，确定与第一故障处理节点具有相同选择次数的第二故障处理节点，作为第一故障处理节点的选民故障处理节点，其中，选择次数表示故障处理节点参与选择全局故障处理节点的次数；

向选民故障处理节点发送首领选择请求，触发选民故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方；

对第一故障处理节点的选择次数加一。

步骤“接收选择结果信息，若基于选择结果信息确定第一故障处理节点被选择为全局故障处理节点，从从节点中选择新的主节点”，可以包括：

接收选民故障处理节点发送的选择结果信息，从选择结果信息中读取全局故障处理节点的标识信息，基于标识信息更新第一故障处理节点被选择为全局故障处理节点的被选票数；

当被选票数超过预设票数阈值时，确定第一故障处理节点为全局故障处理节点，从从节点中选择新的主节点。

其中，若第一故障处理节点，确定第一故障处理节点为全局故障处理节点，可以向其他所有第二故障处理节点发送选举成功通知信息，选举成功通知信息可以包括第一故障处理节点的标识信息，用于告知接收到该通知信息的故障处理节点，该全局故障处理节点的身份，并且终止本次的全局故障处理节点的选择。

若第一故障处理节点确定自身未被选为全局故障处理节点，或者自身的被选票数未超过预设票数阈值，则第一故障处理节点会等待其他故障处理节点发送的选举成功通知信息，若在一定等待时长(可设置)内未接收到选举成功通知信息，则第一故障处理节点可以重新执行“从第二故障处理节点中，确定与第一故障处理节点具有相同选择次数的第二故障处理节点，作为第一故障处理节点的选民故障处理节点”的步骤，直到选出全局故障处理节点为止。

当然，若该第一故障处理节点未被选为全局故障处理节点，则该第一故障处理节点不执行“从从节点选择新的主节点”的步骤。

其中，可以理解的是，本实施例的方法还可以包括：

当第二故障处理节点接收到首领选择请求后，从发送首领选择请求的故障处理节点中选择全局故障处理节点；

该第二故障处理节点向接收到的首领选择请求对应的故障处理节点发送选择结果信息，该选择结果信息中包括选择的全局故障处理节点的标识信息。

其中，当第二故障处理节点接收到第一个首领选择请求候，可以解析该首领选择请求中的标识信息，将发送该首领选择请求的故障处理节点确定为全局故障处理节点，基于该首领选择请求中的标识信息生成全局故障处理节点的标识信息，向发送该第一个首领选择请求的故障处理节点发送包含该标识信息的选择结果信息。当该故障处理节点接收到其他首领选择请求时，可以向发送首领选择请求的故障处理节点发送该选择结果信息。

可选的，步骤“向选民故障处理节点发送首领选择请求，触发选民故障处理节点从发送首领选择请求的第一故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方”，可以包括：

向选民故障处理节点发送首领选择请求，触发选民故障处理节点将第一个接收到的首领选择请求对应的发送方，确定为具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至接收到的所有首领选择请求的发送方。

可选的，步骤“从第二故障处理节点中，确定与第一故障处理节点具有相同选择次数的第二故障处理节点，作为第一故障处理节点的选民故障处理节点”，可以包括：

从管理系统中获取第二故障处理节点的处理节点信息，处理节点信息包括选择次数；

基于处理节点信息确定与第一故障处理节点具有相同选择次数的第二故障处理节点，作为第一故障处理节点的选民故障处理节点。

在一个示例中，第一故障处理节点也可以基于之前的选举连接向第二故障处理节点发送在线询问信息，在线询问信息中包括选择次数询问信息，第一故障处理节点可以根据第二故障处理节点基于在线询问信息的反馈信息，确定与自身具有相同选择次数的第二故障处理节点作为选民故障处理节点。

可以理解的是，本实施例中所有确定服务节点处于故障状态的第一故障处理节点都可以发起上述的首领选择请求。

当第一故障处理节点接收到选民故障处理节点发送的选择结果信息后，从选择结果信息中读取全局故障处理节点的标识信息，如读取运行ID和选择次数，若运行ID和选择次数为该故障处理节点的运行ID和选择次数匹配(如相同)，则该第一故障处理节点确定自身的被选票数加1。

本实施例中，可以在预设选举时长内统计所有第一故障处理节点的被选票数，若该票数超过预设票数阈值(如超过在线哨兵的一半)，则确定该第一故障处理节点为全局故障处理节点。

或者，本实施例中，第一故障处理节点还可以将自身的被选票数发送给注册故障处理节点，触发注册故障处理节点根据接收到的第一故障处理节点的被选票数，从第一故障处理节点中选择全局故障处理节点，生成选择结果信息发送给(向注册故障处理节点发送了被选票数)的第一故障处理节点。其中，注册故障处理节点可以选择被选票数最高的第一故障处理节点为全局故障处理节点。

其中，无论选举成功与否，本次参与选举的所有故障处理节点(包括发送和接收首领选择请求的故障处理节点)的选择次数都要加1，避免参与历史选举的故障处理节点对当前选举流程的影响(如上一轮的首领选择请求在选举超过预设选举时长后才返回选择结果信息)。

下面将结合图2d，对全局故障处理节点的选举流程进行描述。

参考图2d，全局故障处理节点的选举方法包括：

701、第一故障处理节点设置主节点为下线状态；

702、第一故障处理节点从ETCD获取所有在线第二故障处理节点的处理节点信息；

703、第一故障处理节点从在线第二故障处理节点中选择选择次数与自身相同的哨兵作为自身的选民故障处理节点；

704、第一故障处理节点向选民故障处理节点发送首领选择请求；

其中，首领选择请求包括判断哨兵的运行ID和选择次数。

705、选民故障处理节点接收首领选择请求；

706、选民故障处理节点判断首领选择请求是否是第一个到达，是则进入步骤707，否，则进入步骤708；

707、选民故障处理节点将第一个接收到的首领选择请求对应的故障处理节点确定为全局故障处理节点，进入步骤708；

708、选民故障处理节点向接收的首领选择请求对应的故障处理节点发送选择结果信息，该选择结果信息包括全局故障处理节点的运行ID和选择次数；

709、第一故障处理节点接收并解析选择结果信息；

710、第一故障处理节点确定选择结果信息中的运行ID和选择次数是否与自身的运行ID和选择次数一致，若是，进入步骤711，若否，进入步骤715；

711、第一故障处理节点将自身的被选票数加1；

712、第一故障处理节点在发送首领选择请求后的预设选举时长阈值内统计自身的被选票数；

713、若第一故障处理节点的被选票数超过预设票数阈值，进入步骤714，否则，进入步骤715；

714、第一故障处理节点确定自身为全局故障处理节点；

715、参与本次首领选举的所有第二故障处理节点的选择次数加1。

其中，步骤714之后，第一故障处理节点可以向其他所有在线第二故障处理节点发送首领通知信息，通知自己被选举为全局故障处理节点，触发第二故障处理节点将选择次数加1。

在完成全局故障处理节点的选举后，全局故障处理节点可以对已经下线的主节点进行故障转移操作(即主节点切换操作)。

可选的，步骤“从从节点中选择新的主节点”，可以包括：

从从节点中确定处于非故障状态的从节点作为候选从节点；

基于候选从节点的节点性能，从候选从节点中选择待定从节点；

从待定从节点中选择新的主节点。

本实施例中的节点性能，可以是任意可衡量从节点的性能的信息，如从节点对第一故障处理节点的响应速度，从节点的运行ID，从节点的复制偏置等等。

可选的，从从节点中确定处于非故障状态的从节点作为候选从节点，可以包括：从第一故障处理节点的节点管理信息中获取各从节点的节点状态，基于节点状态确定处于非故障状态的从节点作为候选从节点。

可选的，本实施例中，步骤“基于候选从节点的节点性能，从候选从节点中选择待定从节点”，可以包括：

从候选从节点中去除第一候选从节点，其中，第一候选从节点为距离当前时刻的预设历史时长内未回复第一故障处理节点的从节点；

从候选从节点中去除第二候选从节点，其中，第二候选从节点为与旧的主节点断开同步链路超过预设时长阈值的从节点；

将剩余的候选从节点确定为待定从节点。

其中，预设历史时长可以根据需要设置，例如距离当前时刻之前的3分钟等等。预设时长阈值也可以根据需要设置，例如设置为1分钟，30秒等时长。

本实施例中，可以只去除第一候选从节点或第二候选从节点，也可以将第一候选从节点和第二候选从节点都从候选从节点中去除。

在一个示例中，从待定从节点中选择新的主节点，包括：

从待定从节点中选择优先级最高的从节点作为新的主节点；

若优先级最高的从节点有多个，从优先级最高的从节点中选择同步数据最完整的从节点作为新的主节点，同步数据为从节点从对应的主节点同步的数据；

若同步数据最完整的从节点有多个，从同步数据最完整的从节点中选择运行次数最小的从节点作为新的主节点；

若运行次数最小的从节点有多个，从运行次数最小的从节点中随机选择一个从节点作为新的主节点。

本实施例中同步数据的完整性可以根据从节点的复制偏置确定，复制偏置越大，同步数据的完整性越高。从节点的运行次数，可根据从节点的运行ID确定。运行次数越大，则说明从节点的进程的重启次数越大，从节点的性能越不稳定，所以基于运行次数，可以选择运行状态良好的从节点作为新的主节点。

下面结合图2e，对主节点的故障转移方法进行示例说明。

参考图2e，主节点的故障转移方法包括：

801、第一故障处理节点获取旧的主节点的所有从节点的节点属性信息；

其中，该节点属性信息包括从节点的节点状态、对第一故障处理节点的心跳探测请求的最新响应时刻、与旧的主节点的同步链接的最新连接时刻、从节点的优先级、复制偏置、运行ID等等信息。

802、第一故障处理节点从所有从节点中选择非故障状态的从节点作为候选从节点；

803、第一故障处理节点从候选从节点中去除最新响应时刻与当前时刻的时间差超过预设历史时长的从节点；

804、第一故障处理节点从候选从节点中去除与旧的主节点的同步链接的断线时长超过预设时长阈值的从节点；

805、第一故障处理节点从候选从节点中选择优先级最高的从节点作为新的主节点；

806、若优先级最高的从节点有多个，第一故障处理节点从优先级最高的从节点中选择复制偏置最大的从节点作为新的主节点；

807、若复制偏置最大的从节点有多个，第一故障处理节点从复制偏置最大的从节点中选择运行次数最小的从节点作为新的主节点；

808、若运行次数最小的从节点有多个，第一故障处理节点从运行次数最小的从节点中随机选择一个从节点作为新的主节点；

809、第一故障处理节点通过心跳连接通知旧的主节点的其他从节点从该新的主节点进行数据同步；

其中，第一故障处理节点可以通过心跳连接向旧的主节点的其他从节点发送第一主节点切换信息，以便其他从节点从该新的主节点进行数据同步。

810、第一故障处理节点在ETCD将注册的主节点更新为该新的主节点。

本实施例中，在主节点切换之后，故障处理节点还可以定期向故障状态的服务节点如故障的主节点发送心跳探测请求，在接收到针对心跳探测请求的响应信息后，基于响应信息的接收情况，确定故障状态的服务节点是否从故障状态恢复为正常工作状态。

可选的，可以在故障的服务节点响应心跳探测请求的连续时长达到预设正常响时长阈值后，确定故障的服务节点恢复为正常工作状态。

可选的，本实施例的方法还包括：

当故障状态的服务节点从故障状态恢复为正常工作状态时，通过与服务节点的心跳连接线向服务节点发送第二主节点切换信息，以便服务节点作为当前的主节点的从节点，基于当前的主节点进行数据同步。

其中，第二主节点切换信息可以携带当前的主节点的节点信息，如节点地址等信息。恢复正常的服务节点可以基于该节点地址建立与该当前的主节点的连接，从该主节点进行数据同步。

可选的，采用本实施例的方案具有以下的有益效果：

(1)、可以有效提升服务系统的可用性。相关技术中的主从同步检索系统对于主节点的健康检查和故障转移主要由系统维护者进行人工检查和处理，具有检查的滞后性和转移的繁琐性。很可能出现在该主节点出现故障导致整个服务系统不用时才发现主节点故障和处理，这将直接导致大量数据丢失，对于实时性检索场景将是灾难性的结果，即使是商场中的身份建档等非实时检索场景如果不能快速恢复服务系统，也会直接导致建档失败。

而本实施例提出的多哨兵健康检查和故障处理引入心跳检查、ETCD服务注册与watch机制的保证了检索主从节点的自动化健康检查和快速故障发现和处理。

(2)、提升数据一致性。相关技术中的主从同步检索系统对于检索主节点的故障转移主要是人工从众多从节点中选择复制偏置最大的作为新的主节点进行处理，没有考虑从节点的运行状态和是否可用，这有可能导致故障转移失败或前后主从数据不一致问题。

而本实施例提出的多哨兵故障处理引入了多哨兵主客观下线判断、基于raft的哨兵首领选举以及多层次过滤的新主选择机制大大保证了新主的运行可用性和数据可信度，保证故障转移地成功和数据的一致性。

同时多哨兵机制的自动化健康检查与故障处理可以降低故障误判断带来的转移开销、提高健康检查的健壮性。

(3)、适用性广。本方案适用当前主流硬件平台包括PC机、服务器等；提供的高可用检索系统适用当前主要的商场场景下的身份建档、客流、提醒等检索需求。

为了更好地实施以上方法，相应的，本发明实施例还提供一种系统故障处理装置，该系统故障处理装置具体集成在服务器中，应用于服务系统中的第一故障处理节点，第一故障处理节点为服务系统中任一故障处理节点，该服务系统还包括多个服务节点。

参考图3，该装置包括：

心跳探测请求单元901，用于向服务系统中的各服务节点定期发送心跳探测请求，其中，服务系统还包括至少一个第二故障处理节点；

主观下线检测单元902，用于当服务节点对心跳探测请求的响应不满足预设响应条件时，确定服务节点为待判断节点，确定在节点管理信息中待判断节点的节点状态为暂定故障状态；

获取单元903，用于从第二故障处理节点获取待判断节点的节点状态，其中，第二故障处理节点为服务系统中除了第一故障处理节点之外的其他故障处理节点；

客观下线检测单元904，用于若待判断节点的节点状态中暂定故障状态的数量不低于预设阈值，将节点管理信息中待判断节点的节点状态，确定为故障状态；

故障处理单元905，用于对故障状态的服务节点进行相应的故障处理。

在一个示例中，服务节点包括主节点和从节点，该系统故障处理装置还包括节点连接单元，用于在第一故障处理节点启动时，从配置信息中获取主节点的主节点信息；基于主节点信息建立与主节点的心跳连接，并基于心跳连接从主节点获取从节点的从节点信息；基于从节点的从节点信息，建立与从节点的心跳连接。

在一个示例中，若故障状态的服务节点为从节点，故障处理单元，用于向第二故障处理节点发送故障通知信息，故障通知信息用于触发第二故障处理节点将节点管理信息中待判断节点的节点状态更新为故障状态。

在一个示例中，若故障状态的服务节点为主节点，故障处理单元305，用于向第二故障处理节点发送首领选择请求，触发第二故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方，选择结果信息中包括全局故障处理节点的标识信息；接收选择结果信息，若基于选择结果信息确定第一故障处理节点被选择为全局故障处理节点，从从节点中选择新的主节点；向旧的主节点的其他从节点发送第一主节点切换信息，使得其他从节点从新的主节点进行数据同步。

在一个示例中，服务系统还包括服务代理模块，系统故障装置还包括主节点注册单元，用于在从配置信息中获取主节点的主节点信息后，基于主节点信息，将主节点注册到管理系统中，以便服务代理模块基于管理系统确定服务系统的主节点；

主节点注册单元，还用于在故障处理单元从从节点中选择新的主节点后，将管理系统中注册的主节点更新为新的主节点，以便服务代理模块接收到客户端发送的服务请求后，将服务请求转发至新的主节点进行处理。

在一个示例中，故障处理单元，用于：

从第二故障处理节点中，确定与第一故障处理节点具有相同选择次数的第二故障处理节点，作为第一故障处理节点的选民故障处理节点，其中，选择次数表示故障处理节点参与选择全局故障处理节点的次数；

向选民故障处理节点发送首领选择请求，触发选民故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方；

对第一故障处理节点的选择次数加一；

接收选民故障处理节点发送的选择结果信息，从选择结果信息中读取全局故障处理节点的标识信息，基于标识信息更新第一故障处理节点被选择为全局故障处理节点的被选票数；

当被选票数超过预设票数阈值时，确定第一故障处理节点为全局故障处理节点，从从节点中选择新的主节点。

在一个示例中，故障处理单元，用于向选民故障处理节点发送首领选择请求，触发选民故障处理节点将第一个接收到的首领选择请求对应的发送方，确定为具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至接收到的所有首领选择请求的发送方。

在一个示例中，系统故障装置还包括哨兵保活单元，用于向管理系统定期发送心跳探测请求，以避免管理系统在哨兵管理信息中删除第一故障处理节点；

故障处理单元，用于从管理系统中获取第二故障处理节点的处理节点信息，处理节点信息包括选择次数；基于处理节点信息确定与第一故障处理节点具有相同选择次数的第二故障处理节点，作为第一故障处理节点的选民故障处理节点。

在一个示例中，故障处理单元，用于：

从从节点中确定处于非故障状态的从节点作为候选从节点；

基于候选从节点的节点性能，从候选从节点中选择待定从节点；

从待定从节点中选择新的主节点。

在一个示例中，故障处理单元，用于：

从候选从节点中去除第一候选从节点，其中，第一候选从节点为在距离当前时刻的历史预设时长内未回复第一故障处理节点的从节点；

从候选从节点中去除第二候选从节点，其中，第二候选从节点为与旧的主节点断开同步链路超过预设时长阈值的从节点；

将剩余的候选从节点确定为待定从节点。

在一个示例中，主节点和从节点设置有优先级，故障处理单元，用于：

从待定从节点中选择优先级最高的从节点作为新的主节点；

若优先级最高的从节点有多个，从优先级最高的从节点中选择同步数据最完整的从节点作为新的主节点，同步数据为从节点从对应的主节点同步的数据；

若同步数据最完整的从节点有多个，从同步数据最完整的从节点中选择运行次数最小的从节点作为新的主节点；

若运行次数最小的从节点有多个，从运行次数最小的从节点中随机选择一个从节点作为新的主节点。

在一个示例中，系统故障装置还包括故障节点恢复单元，用于当故障状态的服务节点从故障状态恢复为正常工作状态时，通过与服务节点的心跳连接，向服务节点发送第二主节点切换信息，以便服务节点作为当前的主节点的从节点，基于当前的主节点进行数据同步。

采用本申请实施例，基于故障处理节点的设置，可以快速确定服务系统中出现故障的服务节点，从而提升对故障的服务节点的处理速度，有利于保证服务系统的正常运行。

此外，本发明实施例还提供一种计算机设备，该计算机设备可以为终端或者服务器，如图4所示，其示出了本发明实施例所涉及的计算机设备的结构示意图，具体来讲：

该计算机设备可以包括一个或者一个以上处理核心的处理器1001、一个或一个以上计算机可读存储介质的存储器1002、电源1003和输入单元1004等部件。本领域技术人员可以理解，图4中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器1001是该计算机设备的控制中心，利用各种接口和线路连接整个计算机设备的各个部分，运行或执行存储在存储器1002内的软件程序和/或模块，以及调用存储在存储器1002内的数据，执行计算机设备的各种功能和处理数据，从而对计算机设备进行整体监控。可选的，处理器1001可包括一个或多个处理核心；优选的，处理器1001可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，调制解调处理器也可以不集成到处理器1001中。

存储器1002可用于存储软件程序以及模块，处理器1001运行存储在存储器1002的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器1002可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据计算机设备的使用所创建的数据等。此外，存储器1002可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器1002还可以包括存储器控制器，以提供处理器1001对存储器1002的访问。

计算机设备还包括给各个部件供电的电源1003，优选的，电源1003可以电源管理系统与处理器1001逻辑相连，从而电源管理系统实现管理充电、放电、以及功耗管理等功能。电源1003还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该计算机设备还可包括输入单元1004，该输入单元1004可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

尽管未示出，计算机设备还可以包括显示单元等，在此不再赘述。具体在本实施例中，计算机设备中的处理器1001会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器1002中，并由处理器1001来运行存储在存储器1002中的应用程序，从而实现各种功能，如下：

向服务系统中的各服务节点定期发送心跳探测请求，其中，服务系统还包括至少一个第二故障处理节点；

当服务节点对心跳探测请求的响应不满足预设响应条件时，确定服务节点为待判断节点，确定在节点管理信息中待判断节点的节点状态为暂定故障状态；

从第二故障处理节点获取待判断节点的节点状态，其中，第二故障处理节点为服务系统中除了第一故障处理节点之外的其他故障处理节点；

若待判断节点的节点状态中暂定故障状态的数量不低于预设阈值，将节点管理信息中待判断节点的节点状态，确定为故障状态；

对故障状态的服务节点进行相应的故障处理。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以指令来完成，或指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本发明实施例还提供一种存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本发明实施例所提供的系统故障处理方法。

根据本申请的一个方面，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例中的各种可选实现方式中提供的方法。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

其中，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。

由于该存储介质中所存储的指令，可以执行本发明实施例所提供的系统故障处理方法中的步骤，因此，可以实现本发明实施例所提供的系统故障处理方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本发明实施例所提供的一种系统故障处理方法、装置、计算机设备和存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种系统故障处理方法，其特征在于，应用于服务系统中的第一故障处理节点，所述第一故障处理节点为所述服务系统中任一故障处理节点，所述方法包括：

向所述服务系统中的各服务节点定期发送心跳探测请求，其中，所述服务系统还包括至少一个第二故障处理节点；

当服务节点对所述心跳探测请求的响应不满足预设响应条件时，确定所述服务节点为待判断节点，确定在节点管理信息中所述待判断节点的节点状态为暂定故障状态；

从第二故障处理节点获取所述待判断节点的节点状态，其中，所述第二故障处理节点为所述服务系统中除了所述第一故障处理节点之外的其他故障处理节点；

若所述待判断节点的节点状态中所述暂定故障状态的数量不低于预设阈值，将所述节点管理信息中所述待判断节点的节点状态，确定为故障状态；

对故障状态的服务节点进行相应的故障处理。

2.根据权利要求1所述的系统故障处理方法，其特征在于，所述服务节点包括主节点和从节点，所述向所述服务系统中的各服务节点定期发送心跳探测请求前，还包括：

在第一故障处理节点启动时，从配置信息中获取所述主节点的主节点信息；

基于所述主节点信息建立与所述主节点的心跳连接，并基于所述心跳连接从所述主节点获取所述从节点的从节点信息；

基于所述从节点的从节点信息，建立与所述从节点的心跳连接。

3.根据权利要求1所述的系统故障处理方法，其特征在于，若所述故障状态的服务节点为从节点，所述对故障状态的服务节点进行相应的故障处理，包括：

向所述第二故障处理节点发送故障通知信息，所述故障通知信息用于触发所述第二故障处理节点将节点管理信息中所述待判断节点的节点状态更新为故障状态。

4.根据权利要求2所述的系统故障处理方法，其特征在于，若所述故障状态的服务节点为主节点，所述对故障状态的服务节点进行相应的故障处理，包括：

向所述第二故障处理节点发送首领选择请求，触发所述第二故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方，所述选择结果信息中包括全局故障处理节点的标识信息；

接收选择结果信息，若基于所述选择结果信息确定所述第一故障处理节点被选择为全局故障处理节点，从所述从节点中选择新的主节点；

向旧的主节点的其他从节点发送第一主节点切换信息，使得所述其他从节点从所述新的主节点进行数据同步。

5.根据权利要求4所述的系统故障处理方法，其特征在于，所述服务系统还包括服务代理模块，

从配置信息中获取所述主节点的主节点信息后，还包括：

基于所述主节点信息，将所述主节点注册到管理系统中，以便所述服务代理模块基于所述管理系统确定所述服务系统的主节点；

从所述从节点中选择新的主节点后，还包括：

将所述管理系统中注册的主节点更新为所述新的主节点，以便所述服务代理模块接收到客户端发送的服务请求后，将所述服务请求转发至所述新的主节点进行处理。

6.根据权利要求5所述的系统故障处理方法，其特征在于，所述向所述第二故障处理节点发送首领选择请求，触发所述第二故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方，包括：

从所述第二故障处理节点中，确定与所述第一故障处理节点具有相同选择次数的第二故障处理节点，作为所述第一故障处理节点的选民故障处理节点，其中，所述选择次数表示故障处理节点参与选择全局故障处理节点的次数；

向选民故障处理节点发送首领选择请求，触发所述选民故障处理节点从发送首领选择请求的故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至首领选择请求的发送方；

对所述第一故障处理节点的选择次数加一；

所述接收选择结果信息，若基于所述选择结果信息确定所述第一故障处理节点被选择为全局故障处理节点，从所述从节点中选择新的主节点，包括：

接收所述选民故障处理节点发送的选择结果信息，从所述选择结果信息中读取全局故障处理节点的标识信息，基于所述标识信息更新所述第一故障处理节点被选择为全局故障处理节点的被选票数；

当被选票数超过预设票数阈值时，确定所述第一故障处理节点为全局故障处理节点，从所述从节点中选择新的主节点。

7.根据权利要求6所述的系统故障处理方法，其特征在于，所述向选民故障处理节点发送首领选择请求，触发所述选民故障处理节点从发送首领选择请求的第一故障处理节点中，选择具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至所述首领选择请求的发送方，包括：

向选民故障处理节点发送首领选择请求，触发所述选民故障处理节点将第一个接收到的首领选择请求对应的发送方，确定为具有主节点故障处理权限的全局故障处理节点，并生成选择结果信息发送至接收到的所有首领选择请求对应的发送方。

8.根据权利要求6所述的系统故障处理方法，其特征在于，还包括：

向所述管理系统定期发送心跳探测请求，以避免所述管理系统在哨兵管理信息中删除所述第一故障处理节点；

所述从所述第二故障处理节点中，确定与所述第一故障处理节点具有相同选择次数的第二故障处理节点，作为所述第一故障处理节点的选民故障处理节点，包括：

从所述管理系统中获取所述第二故障处理节点的处理节点信息，所述处理节点信息包括选择次数；

基于所述处理节点信息确定与所述第一故障处理节点具有相同选择次数的第二故障处理节点，作为所述第一故障处理节点的选民故障处理节点。

9.根据权利要求4所述的系统故障处理方法，其特征在于，从所述从节点中选择新的主节点，包括：

从所述从节点中确定处于非故障状态的从节点作为候选从节点；

基于所述候选从节点的节点性能，从所述候选从节点中选择待定从节点；

从所述待定从节点中选择新的主节点。

10.根据权利要求9所述的系统故障处理方法，其特征在于，所述基于所述候选从节点的节点性能，从所述候选从节点中选择待定从节点，包括：

从所述候选从节点中去除第一候选从节点，其中，所述第一候选从节点为在距离当前时刻的历史预设时长内未回复所述第一故障处理节点的从节点；

从所述候选从节点中去除第二候选从节点，其中，所述第二候选从节点为与旧的主节点断开同步链路超过预设时长阈值的从节点；

将剩余的候选从节点确定为待定从节点。

11.根据权利要求9所述的系统故障处理方法，其特征在于，所述主节点和从节点设置有优先级，从所述待定从节点中选择新的主节点，包括：

从所述待定从节点中选择所述优先级最高的从节点作为新的主节点；

若所述优先级最高的从节点有多个，从所述优先级最高的从节点中选择同步数据最完整的从节点作为新的主节点，所述同步数据为从节点从对应的主节点同步的数据；

若所述同步数据最完整的从节点有多个，从所述同步数据最完整的从节点中选择运行次数最小的从节点作为新的主节点；

若所述运行次数最小的从节点有多个，从所述运行次数最小的从节点中随机选择一个从节点作为新的主节点。

12.根据权利要求1-11任一项所述的系统故障处理方法，其特征在于，还包括：

当所述故障状态的服务节点从所述故障状态恢复为正常工作状态时，通过与所述服务节点的心跳连接，向所述服务节点发送第二主节点切换信息，以便所述服务节点作为当前的主节点的从节点，基于所述当前的主节点进行数据同步。

13.一种系统故障处理装置，其特征在于，应用于服务系统中的第一故障处理节点，所述第一故障处理节点为所述服务系统中任一故障处理节点，所述装置包括：

心跳探测请求单元，用于向所述服务系统中的各服务节点定期发送心跳探测请求，其中，所述服务系统还包括至少一个第二故障处理节点；

主观下线检测单元，用于当服务节点对所述心跳探测请求的响应不满足预设响应条件时，确定所述服务节点为待判断节点，确定在节点管理信息中所述待判断节点的节点状态为暂定故障状态；

获取单元，用于从第二故障处理节点获取所述待判断节点的节点状态，其中，所述第二故障处理节点为所述服务系统中除了所述第一故障处理节点之外的其他故障处理节点；

客观下线检测单元，用于若所述待判断节点的节点状态中所述暂定故障状态的数量不低于预设阈值，将所述节点管理信息中所述待判断节点的节点状态，确定为故障状态；

故障处理单元，用于对故障状态的服务节点进行相应的故障处理。

14.一种计算机设备，其特征在于，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如权利要求1至12中任一项所述方法的步骤。

15.一种存储介质，其上存储有计算机程序，其特征在于，当计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至12中任一项所述方法的步骤。

Images