CN118264534A - 故障处理方法、装置、计算机设备及可读存储介质 - Google Patents

Abstract

本申请实施例提供了一种故障处理方法、装置、计算机设备及可读存储介质，属于计算机集群技术领域。方法包括：对信息采集实例的信息记录状态进行检测；当信息采集实例更新时，从信息采集实例中确定节点集群中各目标节点的更新时间；基于每个目标节点的更新时间，确定节点集群中更新的目标节点的更新数量；当更新数量大于预设阈值时，对节点集群中的每个目标节点进行状态检测，得到状态检测结果；当状态检测结果表征节点集群出现运行故障时，根据目标节点之间的通信连接状态，确定节点集群中的故障节点；根据信息采集实例记录的所有目标节点的节点状态信息对故障节点进行修复，以此，能够在不浪费系统负载的情况下，及时对节点集群进行修复。

Description

故障处理方法、装置、计算机设备及可读存储介质

技术领域

本申请涉及计算机集群技术领域，尤其涉及一种故障处理方法、装置、计算机设备及可读存储介质。

背景技术

Kubernetes(简称K8S)是一个用于自动部署、扩展和管理容器化应用程序的开源平台，K8S可以定义和管理有状态的服务，如Red i s集群。具体的，Red i s集群可以通过Goss i p协议来实现目标节点间的交互和状态同步，通过更新目标节点在对应的配置文件的IP地址等节点状态信息，确保Red i s集群在Kubernetes环境中的稳定运行。

然而，当K8S集群重启或者Red i s集群发生宕机(半数以上目标节点失效)的情况时，目标节点之间就无法通过Goss i p协议进行通信更新，从而导致整个Red i s集群无法正常运行。

相关技术中，一般通过设置定时周期来检测K8S中Red i s集群的状态，当检测到集群不可用的情况时，查找到对应的集群节点并对集群节点进行修复。然而，这样的方案可能会出现定时周期设置的频率过高，增加系统的不必要负载的问题，或者定时周期设置的频率过高低，导致无法及时发现Red i s集群宕机以作出及时修复的问题。

发明内容

本申请实施例的主要目的在于提出一种故障处理方法、装置、计算机设备及可读存储介质，能够在不浪费系统负载的情况下，及时对节点集群进行修复。

为实现上述目的，本申请实施例的第一方面提出了一种故障处理方法，所述方法包括：

对信息采集实例的信息记录状态进行检测；其中，所述信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；所述节点状态信息至少包括所述目标节点的更新时间；

当所述信息采集实例更新时，从所述信息采集实例中确定对应的节点集群中各目标节点的更新时间；

基于每个目标节点的更新时间，确定所述节点集群中更新的目标节点的更新数量；

当所述更新数量大于预设阈值时，对所述节点集群中的每个目标节点进行状态检测，得到状态检测结果；

当所述状态检测结果表征所述节点集群出现运行故障时，根据所述节点集群多个目标节点之间的通信连接状态，确定所述节点集群中的故障节点；

根据所述信息采集实例记录的所有所述目标节点的节点状态信息，对所述故障节点进行修复。

相应的，本申请实施例的第二方面提出了一种故障处理装置，所述装置包括：

状态检测模块，用于对信息采集实例的信息记录状态进行检测；其中，所述信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；所述节点状态信息至少包括所述目标节点的更新时间；

时间确定模块，用于当所述信息采集实例更新时，从所述信息采集实例中确定对应的节点集群中各目标节点的更新时间；

数量确定模块，用于基于每个目标节点的更新时间，确定所述节点集群中更新的目标节点的更新数量；

结果获取模块，用于当所述更新数量大于预设阈值时，对所述节点集群中的每个目标节点进行状态检测，得到状态检测结果；

故障确定模块，用于当所述状态检测结果表征所述节点集群出现运行故障时，根据所述节点集群多个目标节点之间的通信连接状态，确定所述节点集群中的故障节点；

节点修复模块，用于根据所述信息采集实例记录的所有所述目标节点的节点状态信息，对所述故障节点进行修复。

在一些实施方式中，所述信息采集实例还用于自动记录所述节点集群的最新修复时间；所述数量确定模块，还用于：

从所述信息采集实例中获取所述节点集群的最新修复时间；

依次将各个所述目标节点对应的更新时间与所述最新修复时间进行比较，得到第一比较结果；

根据所述第一比较结果，将所述更新时间在所述最新修复时间之后的目标节点的数量作为更新数量。

在一些实施方式中，所述节点获取模块，还用于：

根据所述信息采集实例，从所述节点集群中获取每个目标节点的通信连接状态；

当存在所述目标节点的通信连接状态为异常时，确定通信连接状态为异常状态的目标节点的异常数量；

将所述异常数量与阈值数量进行比较，得到第二比较结果；

基于所述第二比较结果，得到状态检测结果。

在一些实施方式中，所述故障确定模块，还用于：

通过所述信息采集实例，从所述节点集群中确定通信连接状态为异常状态的异常节点；

获取对应的所述异常节点的状态标识，当所述状态标识表征处于异常状态的目标节点为当前的异常节点时，将当前的所述异常节点确定为故障节点。

在一些实施方式中，所述目标节点的节点状态信息还包括各个节点的网络地址信息和端口信息；所述节点修复模块，还用于：

针对每个所述故障节点，从所述信息采集实例中获取对应的节点集群中所有目标节点的网络地址信息和端口信息；

将所有所述目标节点的网络地址信息和端口信息写入所述故障节点的配置文件中，并重启所述故障节点，以对所述故障节点进行修复。

在一些实施方式中，所述故障处理装置还包括定时检测模块，用于：

获取对所述节点集群进行状态检测的定时检测周期；

根据所述定时检测周期，对所述节点集群中各个目标节点的通信连接状态进行定时检测。

在一些实施方式中，所述故障处理装置还包括创建模块，用于：

针对每个节点集群，创建初始实例，并将所述初始实例的文件格式设置为预设格式；

在所述初始实例中，确定所述节点集群对应的自定义对象和所述自定义对象对应的至少一个自定义字段，并将所述自定义对象和所述自定义字段写入所述初始实例中，得到信息采集实例；各所述自定义字段至少用于获取所述节点集群的最新修复时间，以及所述节点集群对应的更新时间、目标节点的通信连接状态、网络地址信息和端口信息；

在所述节点集群中启用所述信息采集实例。

为实现上述目的，本申请实施例的第三方面提出了一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现本申请第一方面实施例任一项所述的故障处理方法。

为实现上述目的，本申请实施例的第四方面提出了一种计算机可读存储介质，所述存储介质存储有计算机程序所述计算机程序被处理器执行时实现本申请第一方面实施例任一项所述的故障处理方法。

本申请实施例通过获取对信息采集实例的信息记录状态进行检测；其中，信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；节点状态信息至少包括目标节点的更新时间；当信息采集实例更新时，从信息采集实例中确定对应的节点集群中各目标节点的更新时间；基于每个目标节点的更新时间，确定节点集群中更新的目标节点的更新数量；当更新数量大于预设阈值时，对节点集群中的每个目标节点进行状态检测，得到状态检测结果；当状态检测结果表征节点集群出现运行故障时，根据节点集群多个目标节点之间的通信连接状态，确定节点集群中的故障节点；根据信息采集实例记录的所有目标节点的节点状态信息，对故障节点进行修复。以此，能够通过节点集群内的信息采集实例，实时采集和记录各个目标节点的节点状态信息，并通过更新的目标节点的更新数量来判断节点集群是否出现故障，从而对故障节点进行修复；如此，通过统计目标节点的更新数量与预设阈值进行比较，能够确定是否需要对节点集群进行状态检测，无需定时进行检测，且由于信息采集实例会获取实时的目标节点的状态，因此，可以根据信息采集实例中各目标节点的节点状态信息准确定位到故障节点并对故障节点进行及时修复。综上，本申请能够在不浪费系统负载的情况下，及时、高效地完成对节点集群的修复。

附图说明

图1是本申请实施例提供的故障处理系统的结构示意图；

图2是本申请实施例提供的K8S架构图；

图3是本申请实施例提供的故障处理方法的流程图；

图4是本申请实施例提供的故障处理装置的功能模块示意图；

图5是本申请实施例提供的计算机设备的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

Kubernetes(简称K8S)是一个用于自动部署、扩展和管理容器化应用程序的开源平台，K8S可以定义和管理有状态的服务，如Red i s集群。具体的，Red i s集群可以通过Goss ip协议来实现目标节点间的交互和状态同步，通过更新目标节点在对应的配置文件的IP地址等节点状态信息，确保Red i s集群在Kubernetes环境中的稳定运行。

然而，当K8S集群重启或者Red i s集群发生宕机(半数以上目标节点失效)的情况时，目标节点之间就无法通过Goss i p协议进行通信更新，从而导致整个Red i s集群无法正常运行。

相关技术中，一般通过设置定时周期来检测K8S中Red i s集群的状态，当检测到集群不可用的情况时，查找到对应的集群节点并对集群节点并手动获取其他节点的节点状态信息对集群节点进行修复。然而，这样的方案可能会出现定时周期设置的频率过高，增加系统的不必要负载的问题，或者定时周期设置的频率过高低，导致无法及时发现Red i s集群宕机以作出及时修复的问题，同时，由于需要手动获取其他节点的节点状态信息，修复的效率也较低。

基于此，本申请实施例提供了一种故障处理方法、装置、计算机设备及可读存储介质，能够在不浪费系统负载的情况下，及时、高效地完成对节点集群的修复。

本申请实施例提供的故障处理方法、装置、计算机设备及可读存储介质，具体通过如下实施例进行说明，首先描述本申请实施例中的故障处理系统。

请参照图1，在一些实施方式中，故障处理系统包括节点集群110、中控服务器120和终端130。

在一些实施方式中，节点集群110是由多个目标节点组成的集群，用于处理任务、监测目标节点的状态，目标节点可以是服务器、计算机等设备，目标节点之间通过协同工作以实现任务处理和资源管理。在一些实施方式中，节点集群110可以通过图2中的K8S架构管理和调度应用程序。具体的，K8S架构可以包括有节点集群微服务模块111、节点控制器模块112、节点集群控制器模块113。

其中，中控服务器120可以是负责管理和控制节点集群110的主服务器或控制节点。中控服务器120可以监视和管理节点集群110中的各个目标节点、分配任务和资源、实施集群级别的操作和管理、提供服务发现、配置管理、日志聚合和监控等集群服务。在一些实施方式中，K8S架构除了设置在节点集群110上，还可以设置在中控服务器120上，具体可以根据实际情况进行设置。

其中，终端130可以是用户与故障处理系统进行交互的设备，可以是电脑、手机等。在一些实施方式中，终端130设置前端用户界面模块131，通过前端用户界面模块131，用户可以操作界面，获取关于节点集群110健康状态的实时信息，创建、删除和更新监测节点集群110的任务，从而使得用户能够更轻松地进行集群管理，提供高效的操作流程。

具体的，前端用户界面模块131能够为用户提供直观的操作界面，用户可以通过操作界面获取有关节点集群健康状态的实时信息，并通过前端用户界面模块131创建、删除和更新监测节点集群的任务，之后将创建的任务以HTTP或HTTPS的方式发送到节点集群微服务模块111，以使得节点集群微服务模块111能够根据任务创建对应的信息采集实例。前端用户界面模块131通过直观且对用户友好的界面，使得用户能够更轻松地进行集群管理，为整个操作流程提供了更高的效率和可操作性。

具体的，节点集群微服务模块111主要用于负责管理节点集群系统的后端服务。节点集群微服务模块111能够处理来自于前端用户界面模块131发送的任务请求，解析并校验请求参数的合法性，并将任务的元数据持久化到数据库中。进一步的，节点集群微服务模块111还可以利用K8S提供的API服务创建、更新以及删除节点集群的信息采集实例。

进一步的，节点控制器模块112可以通过K8S提供的HTTP应用程序接口主动查询K8S的目标节点的应用程序接口的资源对象并观察其变化，特别是当节点集群中的某个目标节点被删除或者重启时创建时，节点控制器模块112能够实时获取该资源变更信息，把目标节点的网络地址信息、端口信息以及更新时间写入到对应的节点集群的信息采集实例中。也即是说，节点控制器模块112能够对监测任务中的节点集群进行监测，并在目标节点更新或者变化时，将所有目标节点的节点状态信息写入到相应的节点集群的信息采集实例中。

具体的，节点集群控制器模块113可以通过K8S提供的HTTP应用程序接口主动查询信息采集实例并观察其变化，当信息采集实例更新时，节点集群控制器模块113会获取到目标节点的资源对象的所有信息并解析，检查节点集群中的更新时间晚于节点集群的最新修复时间的更新数量，如果更新数量达到或超过预设阈值，节点集群控制器模块113将对节点集群执行健康检查。

进一步的，在节点集群宕机的情况下，节点集群控制器模块113会从信息采集实例中将最新的所有目标节点的节点状态信息写入到目标节点对应的配置文件(nodes.conf文件)中，并最终重新启动目标节点。进一步的，节点集群控制器模块113还可以定时检查节点集群的状态，检查频次可以根据需求进行设置，以避免在目标节点没有更新时，由于其他原因使得节点集群宕机。

需要说明的是，节点控制器模块112会实时监测节点集群中各个目标节点的创建或者修改情况，在存在目标节点变化时，节点控制器模块112会自动将该目标节点的节点状态信息写入到信息采集实例中，而由于节点集群控制器模块113实时监测信息采集实例的更新，当信息采集实例更新时，节点集群控制器模块113会通过信息采集实例检查每个目标节点的更新时间晚于节点集群的最新修复时间的更新数量，若更新数量超过了预设阈值，则对节点集群执行健康检查。当检测到目标节点发生故障时，节点集群控制器模块113会确定故障节点，并将信息采集实例中的所有目标节点的节点状态信息写入故障节点的配置文件中，并重启该目标节点，使得目标节点能够保持与其他目标节点的信息的同步。

本申请实施例中的故障处理方法可以通过如下实施例进行说明。

需要说明的是，在本申请的各个具体实施方式中，当涉及到需要根据用户信息、用户行为数据，用户历史数据以及用户位置信息等与用户身份或特性相关的数据进行相关处理时，都会先获得用户的许可或者同意。而且，对这些数据的收集、使用和处理等，都会遵守相关法律法规和标准。此外，当本申请实施例需要获取用户的敏感个人信息时，会通过弹窗或者跳转到确认页面等方式获得用户的单独许可或者单独同意，在明确获得用户的单独许可或者单独同意之后，再获取用于使本申请实施例能够正常运行的必要的用户相关数据。

在本申请实施例中，将从故障处理系统的维度进行描述，该故障处理系统具体可以集成在计算机设备中。参见图3，图3为本申请实施例提供的晶圆检测系统的步骤流程图，本申请实施例以故障处理系统具体集成在如终端或服务器上为例，终端或服务器上的处理器执行故障处理方法对应的程序指令时，具体流程如下：

步骤101，对信息采集实例的信息记录状态进行检测；其中，信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；节点状态信息至少包括目标节点的更新时间。

可以理解的是，为了确定各个目标节点的更新时间，可以对信息采集的信息记录状态进行监测。具体来说，当目标节点更新时，或者目标节点所在的pod更新时，目标节点中的配置文件可能并未更新，此时，目标节点无法通过配置文件完成与其他节点的通信，从而导致目标节点出现故障，且在多数目标节点出现故障时，节点集群会出现宕机的情况。因此，可以对目标节点的更新状态进行监测。例如，可以通过节点控制器模块实时监测节点集群中各个目标节点的更新情况，并将该目标节点的节点状态信息写入到信息采集实例中，由此，信息采集实例中的信息记录状态也会随之更新。因此，对信息采集实例的信息记录状态进行检测，实际也是对目标节点的更新状态进行检测。通过对目标节点的更新状态进行检测，可以统计更新的目标节点，从而确定是否需要对节点集群进行故障的检测，以对故障进行及时修复，确保节点集群的正常运行。

其中，信息采集实例可以是用于实时获取和记录节点集群的相关信息、以及节点集群中各个目标节点的节点状态信息的自定义资源，信息采集实例可以通过yam l格式的文件来定义，具体可以自定义各个字段，并通过运行各字段获取相关的节点集群信息或者节点状态信息。

具体的，信息采集实例可以用来记录节点集群所在的K8S的命名空间、节点集群名称以及各个目标节点的信息，包括目标节点的名称、IP地址、端口号和创建运行时间。通过设置信息采集实例，系统可以自动监测节点集群的状态并实施必要的恢复操作，从而简化对节点集群的管理，提高系统的稳定性和自动化程度。

其中，信息记录状态可以是信息采集实例的更新状态，当目标节点更新时，信息采集实例中的目标节点的信息记录状态也会随之更新，因此，当信息记录状态表征信息采集实例更新时，可以确定存在节点集群或者目标节点的更新，进而根据更新的目标节点的个数来确定是否需要对节点集群进行检测。

其中，节点集群可以是Red i s集群，节点集群可以由多个目标节点之间进行协作，组成一个分布式的Red i s数据库系统。在节点集群中，数据被分片和分布存储在多个目标节点上，从而实现数据的水平伸缩和高可用性。

其中，目标节点可以是Red i s节点，每个目标节点在节点集群中代表一个独立的节点集群服务的实例，通常部署在一个单独的pod中。Pod是K8S中的最小部署单元，包括容器、运行容器所需的环境和配置信息。在K8S中，pod可以在节点集群的不同目标节点之间动态调度，其IP地址由K8S动态分配。因此，当目标节点所在的pod的IP地址和对应的目标节点的配置文件中指定的服务或节点的IP地址一致时，该目标节点可以与其他目标节点进行交互通信，以维持整个节点集群的稳定性和可用性，同时也维护数据的一致性和节点的健康状况。当超过一半的节点无法正常通信时，K8S集群会失去多数派(quorum)支持，进入不可用状态。因此，需要确保目标节点的配置文件中的IP地址与pod的IP地址一致，以避免这种情况的发生。

其中，节点状态信息可以是对节点集群中的每个目标节点的描述信息，包括节点的唯一标识、角色、通信连接状态和逻辑周期等信息。

例如，节点状态信息可以为Node ID、IP地址和端口、F l ags、Master ID、Last ping sent、Last pong received、Epoch、Status等等。具体的，在节点状态信息中，Node ID也即节点ID，是对目标节点的IP地址和端口进行哈希计算得到的哈希值；F l ags描述目标节点的状态和角色，例如，master表示当前目标节点是一个主节点，s l ave表示当前目标节点是一个从节点，myse l f表示当前目标节点是当前节点；对于Master ID，如果目标节点是一个从节点，Master ID表示目标节点的主节点的ID。Last pi ng sent是上次向目标节点发送探测包命令的时间戳。Last pong received是上次从目标节点接收到确认包响应的时间戳。Epoch是节点集群的逻辑周期，当集群拓扑发生变化时，逻辑周期会增加，用于实现对节点集群状态的一致性检查。Status是目标节点的通信连接状态，可以是非连接状态和连接状态。

其中，目标节点的更新时间可以是目标节点最后一次进行状态更新的时间，也可以说是目标节点所在的pod最后一次进行状态更新的时间，例如目标节点的修改时间、重启时间、删除时间等等。

在一些实施方式中，为了能够实时、准确地获取对应的节点集群和目标节点的节点状态信息，以根据所有节点的节点状态信息对故障节点进行修复，可以针对每个节点集群创建对应的信息采集实例，以对节点集群和目标节点的相关信息进行采集，维护节点集群的正常运行。示例性的，步骤101中的“信息采集实例”可以通过以下步骤创建得到：

(A.1)针对每个节点集群，创建初始实例，并将初始实例的文件格式设置为预设格式；

(A.2)在初始实例中，确定节点集群对应的自定义对象和自定义对象对应的至少一个自定义字段，并将自定义对象和自定义字段写入初始实例中，得到信息采集实例；各自定义字段至少用于获取节点集群的最新修复时间，以及节点集群对应的更新时间、目标节点的通信连接状态、网络地址信息和端口信息；

(A.3)在节点集群中启用信息采集实例。

其中，初始实例可以是信息采集实例的初始结构，对初始实例进行定义，可以生成信息采集实例。

其中，预设格式可以是创建初始实例时指定的文件格式，预设格式可以是JSON、yam l等格式，用于定义信息采集实例的结构和属性。一般来说，信息采集实例可以为一个yam l格式的文件。

其中，自定义对象可以是信息采集实例的不同的采集部分，代表特定的实体，每个自定义对象包括一个或者多个自定义字段，用于获取不同的配置项的信息。例如，自定义对象可以是用于定位和配置的对象，具体包括多个自定义字段，例如节点集群所在的K8S的命名空间和节点集群所在的K8S集群名称等等。可以理解的是，通过设置自定义对象，可以快速定位至对应的自定义字段，从而实现对应的数据的查询和获取。

其中，自定义字段用于描述和获取信息采集实例的自定义对象的特定数据。例如，在自定义对象为用于定位和配置的对象，那么自定义字段可以为节点集群所在的K8S的命名空间和节点集群所在的K8S集群名称等等。可以理解的是，通过设定自定义字段，可以在运行信息采集实例的过程中，直接有针对性地获取需要的数据，提高数据的获取效率。

在一些实施方式中，可以只对初始实例写入自定义字段，而无需写入自定义对象，本申请实时例不对具体预设格式进行限定，只要最终的信息采集实例能够准确采集节点集群和目标节点的状态信息即可。

其中，最新修复时间可以是节点集群最近一次进行维护或修复，使得节点集群恢复正常运行的时间。通过记录最新修复时间，并将目标节点的更新时间与最新修复时间进行比较，可以确定在系统恢复后新更新的目标节点，从而根据更新的目标节点的更新数量，确定是否需要对节点集群进行检测。

其中，网络地址信息是目标节点的IP地址，当目标节点为实例或者运行实例时，网络地址信息可以是实例的IP地址，端口信息是目标节点的端口号。

示例性的，信息采集实例的格式可以如下：

可以理解的是，以上内容仅作为本申请的其中一个实施例，在不脱离本申请构思的情况下，信息采集实例的内容可以进行增减，具体根据实际情况进行设置，本申请实施例对此不作限制。

可以理解的是，若只通过第三方的共享文件获取目标节点的节点状态信息，有可能出现信息获取不及时的问题，且当第三方文件出现故障时，就无法对故障的节点集群进行修复。本申请通过在K8S内部配置信息采集实例，通过信息采集实例自动获取最新的节点集群的信息和目标集群的状态信息，能够确保节点集群的正常运行，实现对故障节点的高效修复。

进一步的，信息采集实例可以用于实时采集对应的节点集群中的所有目标节点的节点状态信息。在得到信息采集实例之后，可以将信息采集实例安装至K8S的应用程序接口中，并启用信息采集实例，以使得信息采集实例能够获取各个目标节点的节点状态信息，以便于对节点集群进行检测和修复，提高系统的稳定性。

步骤102，当信息采集实例更新时，从信息采集实例中确定对应的节点集群中各目标节点的更新时间。

可以理解的是，由于目标节点更新之后，目标节点所在pod中的IP地址极有可能与目标节点的配置文件中的IP地址不一致，导致目标节点无法与其他目标节点进行通信交互，进而导致系统故障，因此，可以确定更新的目标节点的更新时间，以确定更新的目标节点的更新数量，以根据更新数量来确定是否需要对节点集群进行状态检测，确保节点集群的正常运行。

具体地，由于目标节点更新时，信息采集实例会对该目标节点的节点状态信息进行更新，因此，当信息采集实例更新时，极大可能存在目标节点更新的情况，可以在信息采集实例中，查询各目标节点并确定对应的节点集群中各目标节点的更新时间，以便于后续确定目标节点的更新数量。例如，查询到目表节点1的updateTime为2024-01-02 15:04:05，则表明该目标节点的更新时间为2024年1月2日，15时04分05秒。

步骤103，基于每个目标节点的更新时间，确定节点集群中更新的目标节点的更新数量。

可以理解的是，当节点集群中更新的目标节点的更新数量较少时，可以直接通过Goss ip协议进行通信，并更新目标节点的配置文件；而节点集群中更新的目标节点的更新数量较多时，已经无法再通过Goss ip协议更新众多目标节点的配置文件，由此，会导致节点集群宕机。因此，可以通过确认节点集群中的更新目标节点的数量，来判断是否已经超过了通过Goss ip协议无法进行正常通信的预设阈值(如更新的目标节点的数量超过了节点集群的目标节点数量的一半)，并确定是否需要对节点集群进行检测。

具体的，可以使用信息采集实例来获取当前节点集群的最新修复时间，若目标节点的更新时间晚于最新修复时间，这意味着在目标节点进行更新后，节点集群并没有进行相应的修复，这可能表明目标节点存在故障。例如，假设信息采集实例显示节点集群的最新修复时间是2022年1月1日12:00:00，而某个目标节点的更新时间是2022年1月1日12:05:00。这种情况下，目标节点更新后超过了最新修复时间，但节点集群并未进行修复，则可能表明该目标节点存在故障。

在一些实施方式中，信息采集实例还用于自动记录节点集群的最新修复时间。为了获取节点集群中目标节点的更新数量，可以将各个目标节点的更新时间与节点集群的最新修复时间进行比对，并对更新时间晚于最新修复时间的目标节点的数量进行统计，得到更新数量，以便于判断是否需要对节点集群进行检测。例如，步骤103可以包括：

(103.1)从信息采集实例中获取节点集群的最新修复时间；

(103.2)依次将各个目标节点对应的更新时间与最新修复时间进行比较，得到第一比较结果；

(103.3)根据第一比较结果，将更新时间在最新修复时间之后的目标节点的数量作为更新数量。

其中，最新修复时间可以是节点集群最近一次进行维护或修复，使得节点集群恢复正常运行的时间。

其中，第一比较结果可以是目标节点对应的更新时间晚于最新修复时间，或者目标节点对应的更新时间早于最新修复时间。可以理解的是，若目标节点的更新时间晚于最新修复时间，表示目标节点已经进行了更新并且很可能也更新了IP地址，且节点集群并未进行修复，有出现通信故障的可能性，因此需要进一步确认是否需要进行修复。另一方面，若目标节点的更新时间早于最新修复时间，说明该目标节点不存在故障，具体来说，在最新修复时间之前，即使存在故障，也已经被修复完毕，因此可以正常与其他目标节点进行交互。

其中，更新数量可以是目标节点对应的更新时间晚于最新修复时间的数量。

通过以上方式，可以确定节点集群的目标节点的更新数量，以此确定可能出现通信故障的节点的数量，以便于根据更新数量确定是否需要对节点集群进行状态检测。

步骤104，当更新数量大于预设阈值时，对节点集群中的每个目标节点进行状态检测，得到状态检测结果。

可以理解的是，当更新数量小于预设阈值时，说明目标节点之间可以根据Goss ip协议进行正常通信和更新，而当更新数量大于预设阈值时，说明目标节点之间可能已经无法根据Goss i p协议进行正常通信和更新，因此，需要对节点集群中的每个目标节点进行状态检测，以确认节点集群是否发生了故障。

其中，预设阈值是执行状态检测的条件值。当更新数量超过预设阈值时，表明目标节点的更新较为频繁。如果目标节点的IP地址都发生变化，仅依靠Goss i p协议可能无法确保目标节点之间的正常通信。这时，当前节点集群可能出现故障，需要对节点集群进行状态检测。例如，预设阈值可以根据对应节点集群的目标节点数量来确定。例如，预设阈值可以是目标节点数量的30％、40％或50％等。另外，预设阈值也可以根据经验值确定，比如设定为4个或6个等。

可以理解的是，在一般情况下，需要设置检测脚本与节点集群进行长连接，以定时对节点集群进行检测和修复。本申请不需要建立信息采集实例与节点集群的长连接，只有当需要对节点集群的目标节点进行状态检测时，节点集群控制器模块会与需要检测的节点集群建立连接，并在节点集群出现运行故障时，对节点集群修复完毕之后，取消节点集群控制器模块与对应的节点集群的连接。以此，能够节约系统的资源，提高检测的效率。

在一些实施方式中，当更新数量大于预设阈值时，节点集群控制器模块会与需要检测的节点集群连接，并通过信息采集实例中的自定义字段从每个目标节点的配置文件中获取各目标节点的通信连接状态，若存在目标节点的通信连接状态为异常时，则状态检测结果为异常。若是所有目标节点的通信连接状态均为正常时，说明节点集群不存在故障节点，状态检测结果为正常。

通过以上方式，可以对节点集群进行状态检测，以确定节点集群是否存在故障节点，从而及时对故障节点进行修复，提高系统的可靠性。

在一些实施方式中，为了得到每个节点集群的状态检测结果，可以检测每个目标节点的通信连接状态，以根据每个目标节点的通信连接状态来判断是否存在异常的目标节点，快速得到状态检测结果。例如，步骤104中的“对节点集群中的每个目标节点进行状态检测，得到状态检测结果”，可以包括：

(104.1)根据信息采集实例，从节点集群中获取每个目标节点的通信连接状态；

(104.2)当存在目标节点的通信连接状态为异常时，确定通信连接状态为异常状态的目标节点的异常数量；

(104.3)将异常数量与阈值数量进行比较，得到第二比较结果；

(104.4)基于第二比较结果，得到状态检测结果。

其中，通信连接状态可以是目标节点之间的通信情况，用于描述目标节点与其他目标节点之间的通信是否正常和稳定，通信连接状态可以包括正常连接状态和异常连接状态。其中，正常连接状态表明该目标节点能够与其他目标节点进行正常通信，异常连接状态表明该目标节点与其他目标节点之间存在通信异常，可能导致数据传输失败、交互失败等问题。

其中，异常数量可以是在节点集群中通信连接状态为异常的目标节点的数量之和。

其中，阈值数量可以是在存在目标节点的通信连接状态异常情况下设定的一个预设值，用于作为判断标准，指示在出现异常数量达到预设值和未达到预设值时，分别应该得到的不同的状态检测结果。示例性的，阈值数量可以为2个、5个等，具体可以根据经验值设定。或者，阈值数量也可以是节点集群的目标节点的百分比，例如，阈值数量为所有目标节点的数量总和的10％，即当通信连接状态为异常状态的目标节点的异常数量超过所有目标节点的数量总和的10％时，则可以确定状态检测结果为节点集群故障。在一些实施方式中，也可以不设置阈值数量，只要存在目标节点的通信连接状态为异常状态，即得到节点集群处于故障状态的结论。

其中，第二比较结果可以是将异常数量与阈值数量进行比较之后得到的结论。当异常数量小于等于阈值数量时，表示目标节点的通信连接状态异常情况在可接受的范围内，可以通过Goss i p协议进行修复，或者节点集群尚能够维持正常运行，无需进行修复。当异常数量大于阈值数量时，表示目标节点的通信连接状态异常情况已经超过了设定的阈值，需要采取相应的故障处理措施。

具体的，信息采集实例存储有获取各个目标节点的连接状态的自定义字段，当需要对节点集群进行状态检测时，可以通过建立节点集群控制器模块与节点集群的连接，并通过信息采集实例的自定义字段，从各个目标节点中的配置文件获取各目标节点的f lags对应的状态，即获取通信连接状态，若某个目标节点的通信连接状态为fai l，说明此目标节点的通信连接状态为异常状态。

在一些实施方式中，当异常数量小于阈值数量时，则状态检测结果为未发生故障，当异常数量大于阈值数量时，则状态检测结果为发生故障。

通过以上方式，通过将异常数量与阈值数量进行比较，能够快速、准确地对节点集群的状态进行检测，并得到状态检测结果，以根据状态检测结果确定是否需要对节点集群进行修复。

步骤105，当状态检测结果表征节点集群出现运行故障时，根据节点集群多个目标节点之间的通信连接状态，确定节点集群中的故障节点。

可以理解的是，当目标节点处于异常状态时，可能是由于当前目标节点故障，或者与当前的目标节点连接的其他目标节点发生故障，因此，需要确定节点集群中的故障节点，以便于准确、快速地对节点集群进行修复。

其中，故障节点可以是在节点集群中出现运行故障的目标节点，故障节点所在的pod的IP地址与其对应的配置文件中的IP地址不相同，所以导致故障节点与其他目标节点的通信连接失败。

在一些实施方式中，可以通过信息采集实例中的状态标识，获取处于异常状态的目标节点的配置文件(nodes.conf文件)，并查看配置文件中的状态标识，确定处于异常状态的是否为当前的目标节点，若配置文件中的状态标识表征出现异常的为当前节点，则确定当前节点为故障节点。

进一步的，可以重复对节点集群中的每个处于异常状态的目标节点进行确认，直至所有处于异常状态的目标节点均确认完毕，即可得到节点集群的故障节点。

通过以上方式，可以通过信息采集实例快速获取异常状态的目标节点的配置文件，从而根据配置文件中的状态标识快速定位故障节点，以便于后续对故障节点进行修复，维持节点集群的正常运行。

在一些实施方式中，为了快速定位故障节点，可以确定连接状态为异常的目标节点的配置文件，从而对配置文件进行分析，确定当前处于异常状态的目标节点是否为故障节点。例如，步骤105中的“根据节点集群多个目标节点之间的通信连接状态，确定节点集群中的故障节点”可以包括：

(105.1)通过信息采集实例，从节点集群中确定通信连接状态为异常状态的异常节点；

(105.2)获取对应的异常节点的状态标识，当状态标识表征处于异常状态的目标节点为当前的异常节点时，将当前的异常节点确定为故障节点。

其中，异常节点可以是无法与其他目标节点正常通信的目标节点，异常节点不一定是故障节点，可能是与之通信的目标节点均出现故障，导致该目标节点出现异常，因此，需要对异常节点是否为故障节点进行确认。

其中，状态标识可以是异常节点中的配置文件的状态标识，状态标识为用于确定异常节点是否为当前节点。具体的，状态标识可以为f l ags，当异常节点的f l ags为mysel f时，表明该异常节点为故障节点。

在一些实施方式中，在信息采集实例和节点集群建立通信连接之后，信息采集实例可以通过自定义字段，该异常节点的状态标识，当该异常节点的状态标识表征当前异常节点为故障节点时，获取故障节点的节点标识，以便于后续准确地对故障节点进行修复。当该节点的状态标识表征当前异常节点为其他节点时，如状态标识为master或者s l ave时，则当前的异常节点并非故障节点，此时，可以通过获取得到的配置文件的端口信息查找到对应的master或者s l ave节点，以确定故障节点。

可以理解的是，通过确定故障节点，可以节约对非故障的异常节点进行修复的时间，以便于后续能够精确的对故障节点进行修复，提高了对节点集群进行修复的效率。

步骤106，根据信息采集实例记录的所有目标节点的节点状态信息，对故障节点进行修复。

可以理解的是，为了对节点集群进行修复，快速恢复节点集群的正常运行，可以对故障节点进行修复，直至所有故障节点修复完毕，节点集群恢复正常。具体的，由于信息采集实例记录了所有目标节点的状态信息，因此，可以直接将信息采集实例中的所有目标节点的状态信息写入故障节点的配置文件中，以实现对故障节点的修复。

具体的，故障节点的故障原因一般为配置文件内的网络地址信息过期，无法与其他目标节点进行通信，而信息采集实例保存了每个目标节点所运行的实例的最新节点状态信息，因此，为了确保节点集群的通信正常性和一致性，可以将信息采集实例中所有目标节点的节点状态信息写入到故障节点的配置文件中，以对故障节点进行修复。

进一步的，将所有目标节点的节点状态信息写入到故障节点的配置文件中后，故障节点所运行的实例可以通过Goss i p协议进行广播，以通知其他目标节点或者处于异常状态的异常节点更新信息，实现节点之间信息的实时同步和传播，有利于整个节点集群的正常运行和通信。

在一些实施方式中，目标节点的节点状态信息还包括各个节点的网络地址信息和端口信息。可以理解的是，由于故障节点的故障原因一般是网络地址信息过期，因此，可以将所有目标节点的网络地址信息和对应的端口信息复制到配置文件中，从而实现对故障节点的修复，进而在对所有故障节点修复完毕之后，恢复节点集群的正常工作。示例性的，步骤106可以包括：

(106.1)针对每个故障节点，从信息采集实例中获取对应的节点集群中所有目标节点的网络地址信息和端口信息；

(106.2)将所有目标节点的网络地址信息和端口信息写入故障节点的配置文件中，并重启故障节点，以对故障节点进行修复。

其中，网络地址信息可以各目标节点在网络中的标识地址，用于唯一标识和定位目标节点在网络中的位置。网络地址信息可以是目标节点的IP地址或主机名等信息，用于当前的目标节点与其他目标节点之间的通信和数据传输。通过将所有网络地址信息写入故障节点的配置文件中，可以使得故障节点能够通过正确的IP地址信息与其他目标节点进行正常通信。

其中，端口信息可以是各目标节点上开放的网络端口号，用于识别和区分不同的应用或服务，每个目标节点通常会绑定到一个特定的端口号，以实现和其他目标节点的通信。

在一些实施方式中，还可以将除了网络地址信息和端口信息之外的其他节点状态信息写入故障节点中，例如各目标节点的状态信息等等，具体根据需求进行写入，本申请实施例不作具体限制。

可以理解的是，由于信息采集实例记录了各目标节点运行的实例的最新的节点状态信息，因此可以将信息采集实例中记录的各个目标节点的节点状态信息写入故障节点的配置文件中，并对目标节点进行重启，使得故障节点运行的实例的网络地址信息与配置文件中的网络地址信息一致，从而对故障信息进行快速修复。

在一些实施方式中，在对节点集群修复完毕时，将修复完毕时的时间作为节点集群的最新修复时间，以便于后续能够根据最新修复时间确定是否需要对节点集群进行检测。

可以理解的是，可以当节点集群中的节点均未更新但是由于其他原因导致节点集群故障时，或者，当目标节点的更新数量不足预设阈值时，就不会触发对节点集群的各个目标节点的状态检测，有可能由于这些小概率事件的发生导致节点故障，因此，可以设置定时检测周期对节点集群进行定时检测，具体包括：

(B.1)获取对节点集群进行状态检测的定时检测周期；

(B.2)根据定时检测周期，对节点集群中各个目标节点的通信连接状态进行定时检测。

其中，定时周期可以是系统定期对节点集群执行状态检测的时间周期，即系统会在每个固定的时间间隔内对节点集群中各个目标节点的进行定时的状态检测，以监测节点状态的变化、及时发现潜在的通信问题，并确保节点集群的正常运行和稳定性。

在一些实施方式中，可以在信息采集实例中设置定时周期的自定义字段，操作人员可以选择开启或者关闭定时周期。进一步的，可以根据节点集群的繁忙程度设定定时周期，例如，在节点集群较为繁忙的时间段可以设置定时周期为每小时执行一次状态检测，在节点集群较为空闲的时间段可以设置定时周期为每三小时执行一次状态检测，等等，以节约系统的算力资源，并确保节点集群的正常运行。

本申请实施例通过获取对信息采集实例的信息记录状态进行检测；其中，信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；节点状态信息至少包括目标节点的更新时间；当信息采集实例更新时，从信息采集实例中确定对应的节点集群中各目标节点的更新时间；基于每个目标节点的更新时间，确定节点集群中更新的目标节点的更新数量；当更新数量大于预设阈值时，对节点集群中的每个目标节点进行状态检测，得到状态检测结果；当状态检测结果表征节点集群出现运行故障时，根据节点集群多个目标节点之间的通信连接状态，确定节点集群中的故障节点；根据信息采集实例记录的所有目标节点的节点状态信息，对故障节点进行修复。以此，能够通过节点集群内的信息采集实例，实时采集和记录各个目标节点的节点状态信息，并通过更新的目标节点的更新数量来判断节点集群是否出现故障，从而对故障节点进行修复；如此，通过统计目标节点的更新数量与预设阈值进行比较，能够确定是否需要对节点集群进行状态检测，无需定时进行检测，且由于信息采集实例会获取实时的目标节点的状态，因此，可以根据信息采集实例中各目标节点的节点状态信息准确定位到故障节点并对故障节点进行及时修复。综上，本申请能够在不浪费系统负载的情况下，及时、高效地完成对节点集群的修复。

请参阅图4，本申请实施例还提供一种故障处理装置，可以实现上述故障处理方法，故障处理装置包括：

状态检测模块410，用于对信息采集实例的信息记录状态进行检测；其中，信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；节点状态信息至少包括目标节点的更新时间；

时间确定模块420，用于当信息采集实例更新时，从信息采集实例中确定对应的节点集群中各目标节点的更新时间；

数量确定模块430，用于基于每个目标节点的更新时间，确定节点集群中更新的目标节点的更新数量；

结果获取模块440，用于当更新数量大于预设阈值时，对节点集群中的每个目标节点进行状态检测，得到状态检测结果；

故障确定模块450，用于当状态检测结果表征节点集群出现运行故障时，根据节点集群多个目标节点之间的通信连接状态，确定节点集群中的故障节点；

节点修复模块460，用于根据信息采集实例记录的所有目标节点的节点状态信息，对故障节点进行修复。

该故障处理装置的具体实施方式与上述故障处理方法的具体实施例基本相同，在此不再赘述。在满足本申请实施例要求的前提下，故障处理装置还可以设置其他功能模块，以实现上述实施例中的故障处理方法。

本申请实施例还提供了一种计算机设备，计算机设备包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述故障处理方法。该计算机设备可以为包括平板电脑、车载电脑等任意智能终端。

请参阅图5，图5示意了另一实施例的计算机设备的硬件结构，计算机设备包括：

处理器510，可以采用通用的CPU(Centra l Process i ngUn it，中央处理器)、微处理器、应用专用集成电路(App l i cat i onSpec i f i c I ntegratedCi rcu it，ASI C)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案；

存储器520，可以采用只读存储器(ReadOn l yMemory，ROM)、静态存储设备、动态存储设备或者随机存取存储器(RandomAccessMemory，RAM)等形式实现。存储器520可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器520中，并由处理器510来调用执行本申请实施例的故障处理方法；

输入/输出接口530，用于实现信息输入及输出；

通信接口540，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WI F I、蓝牙等)实现通信；

总线550，在设备的各个组件(例如处理器510、存储器520、输入/输出接口530和通信接口540)之间传输信息；

其中处理器510、存储器520、输入/输出接口530和通信接口540通过总线550实现彼此之间在设备内部的通信连接。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述故障处理方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的目标节点包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

本领域技术人员可以理解的是，图中示出的技术方案并不构成对本申请实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

应当理解，在本申请中，“至少一个(项)”和“若干”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，可以通过其他的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其他的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括多指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例的方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-On ly Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序的介质。

以上参照附图说明了本申请实施例的优选实施例，并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本申请实施例的权利范围之内。

Claims (10)

1.一种故障处理方法，其特征在于，所述方法包括：

对信息采集实例的信息记录状态进行检测；其中，所述信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；所述节点状态信息至少包括所述目标节点的更新时间；

当所述信息采集实例更新时，从所述信息采集实例中确定对应的节点集群中各目标节点的更新时间；

基于每个目标节点的更新时间，确定所述节点集群中更新的目标节点的更新数量；

当所述更新数量大于预设阈值时，对所述节点集群中的每个目标节点进行状态检测，得到状态检测结果；

当所述状态检测结果表征所述节点集群出现运行故障时，根据所述节点集群多个目标节点之间的通信连接状态，确定所述节点集群中的故障节点；

根据所述信息采集实例记录的所有所述目标节点的节点状态信息，对所述故障节点进行修复。

2.根据权利要求1所述的故障处理方法，其特征在于，所述信息采集实例还用于自动记录所述节点集群的最新修复时间；所述基于每个目标节点的更新时间，确定所述节点集群中更新的目标节点的更新数量，包括：

从所述信息采集实例中获取所述节点集群的最新修复时间；

依次将各个所述目标节点对应的更新时间与所述最新修复时间进行比较，得到第一比较结果；

根据所述第一比较结果，将所述更新时间在所述最新修复时间之后的目标节点的数量作为更新数量。

3.根据权利要求1所述的故障处理方法，其特征在于，所述对所述节点集群中的每个目标节点进行状态检测，得到状态检测结果，包括：

根据所述信息采集实例，从所述节点集群中获取每个目标节点的通信连接状态；

当存在所述目标节点的通信连接状态为异常时，确定通信连接状态为异常状态的目标节点的异常数量；

将所述异常数量与阈值数量进行比较，得到第二比较结果；

基于所述第二比较结果，得到状态检测结果。

4.根据权利要求1所述的故障处理方法，其特征在于，所述根据所述节点集群多个目标节点之间的通信连接状态，确定所述节点集群中的故障节点，包括：

通过所述信息采集实例，从所述节点集群中确定通信连接状态为异常状态的异常节点；

获取对应的所述异常节点的状态标识，当所述状态标识表征处于异常状态的目标节点为当前的异常节点时，将当前的所述异常节点确定为故障节点。

5.根据权利要求1所述的故障处理方法，其特征在于，所述目标节点的节点状态信息还包括各个节点的网络地址信息和端口信息；所述根据所述信息采集实例记录的所有所述目标节点的节点状态信息，对所述故障节点进行修复，包括：

针对每个所述故障节点，从所述信息采集实例中获取对应的节点集群中所有目标节点的网络地址信息和端口信息；

将所有所述目标节点的网络地址信息和端口信息写入所述故障节点的配置文件中，并重启所述故障节点，以对所述故障节点进行修复。

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

获取对所述节点集群进行状态检测的定时检测周期；

根据所述定时检测周期，对所述节点集群中各个目标节点的通信连接状态进行定时检测。

7.根据权利要求1所述的故障处理方法，其特征在于，所述信息采集实例通过以下步骤创建得到：

针对每个节点集群，创建初始实例，并将所述初始实例的文件格式设置为预设格式；

在所述初始实例中，确定所述节点集群对应的自定义对象和所述自定义对象对应的至少一个自定义字段，并将所述自定义对象和所述自定义字段写入所述初始实例中，得到信息采集实例；各所述自定义字段至少用于获取所述节点集群的最新修复时间，以及所述节点集群对应的更新时间、目标节点的通信连接状态、网络地址信息和端口信息；

在所述节点集群中启用所述信息采集实例。

8.一种故障处理装置，其特征在于，所述装置包括：

状态检测模块，用于对信息采集实例的信息记录状态进行检测；其中，所述信息采集实例用于根据节点集群中任一目标节点更新的节点状态信息进行信息记录状态更新；所述节点状态信息至少包括所述目标节点的更新时间；

时间确定模块，用于当所述信息采集实例更新时，从所述信息采集实例中确定对应的节点集群中各目标节点的更新时间；

数量确定模块，用于基于每个目标节点的更新时间，确定所述节点集群中更新的目标节点的更新数量；

结果获取模块，用于当所述更新数量大于预设阈值时，对所述节点集群中的每个目标节点进行状态检测，得到状态检测结果；

故障确定模块，用于当所述状态检测结果表征所述节点集群出现运行故障时，根据所述节点集群多个目标节点之间的通信连接状态，确定所述节点集群中的故障节点；

节点修复模块，用于根据所述信息采集实例记录的所有所述目标节点的节点状态信息，对所述故障节点进行修复。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的故障处理方法。

10.一种计算机可读存储介质，所述存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7任一项所述的故障处理方法。