CN111869163B - 一种故障检测的方法、装置及系统 - Google Patents

Abstract

一种故障检测的方法，所述方法应用于分布式的节点集群，所述节点集群包括多个节点，所述方法由所述多个节点中的任一节点执行，所述任一节点为第一节点，所述方法包括：所述第一节点判断是否满足健康度评估触发条件，当满足所述健康度评估触发条件时，所述第一节点根据所述第一节点与所述节点集群中的其它节点之间的心跳时延数据分别对所述节点集群中的其它节点健康度进行评估，并获得所述集群中的其它节点的健康度的评估结果。

Description

一种故障检测的方法、装置及系统

技术领域

本申请涉及通信领域，尤其涉及一种故障检测的方法、装置及系统。

背景技术

分布式系统由于具备高并发性、自治性、容错性、可靠性等先进特性，已被广泛的应用于工业界的各类控制系统中。在去中心化的集群中，每个节点以对等的方式出现且一般具备相似的功能。在这类集群中，任何一个单一节点出现故障或出现性能下降时，整个集群的性能不会受到较大的影响。为了在避免单点瓶颈的特质下应对节点或链路故障的出现，每个加入集群的节点都应该具备网络故障的检测能力和一定限度的集群管理能力。

在现有技术中，集群中每个节点都受其他一部分节点的故障检测机制的监视。当集群中某节点故障时，其监视者会发现这种故障，并向集群广播该故障消息。当集群中的管理节点(Leader)收到该条故障消息时将会对该节点进行计时，若计时结束前该节点仍然未恢复正常，则该故障节点会在计时结束时被该管理节点执行决策，如将该故障节点移出集群。

该方案的判决仅以时间作为依据，在某些情况下还会发生错误判决。如故障节点的故障表现为以一定概率丢包的情况，在该情况下故障节点仍然有机会与正常节点通信。但基于现有技术方案，可能因丢包的问题将正常的节点标记为故障并将该故障信息广播至集群中，若集群的管理节点收到了该故障报告，则会出现管理节点将正常节点移出集群的情况。因此，现有技术方案中的故障检测方案的故障检测的准确率较低。

发明内容

本申请实施例提供了一种故障检测的方法、装置及系统，用于提高故障检测的准确性。

第一方面，本申请实施例提供一种故障检测的方法，该方法应用于分布式的节点集群，节点集群包括多个节点，方法由多个节点中的任一节点执行，任一节点为第一节点，该方法包括：

第一节点在确定满足节点健康度评估触发条件的情况下，该第一节点根据第一节点与节点集群中的其它节点之间的心跳时延数据分别对节点集群中的其它节点健康度进行评估，并获得集群中的其它节点的健康度的评估结果。

在该实现方式中，第一节点获取了多组与节点集群中其它所有的节点的心跳时延数据，再根据这些心跳时延数据评估其它节点的健康状况，从而可以根据其它节点的健康状况的评估结果进行故障检测。这样，提高了故障检测的准确性。

一种可能的实现方式中，第一节点向节点集群中除第一节点意外的所有节点采集N组心跳时延数据其中，每组心跳时延数据包含M个心跳时延数据，N和M为大于1的整数，节点集群包含该第一节点。第一节点再根据N组心跳时延数据计算出第一节点至M个节点的通信情况的M个评估值，评估值越低，则通信情况越好，评估值大于或等于预设健康值所对应的节点为故障节点，M个节点中不包括该第一节点，节点集群的总数为M+1。该第一节点再将所计算得到的M个评估值中每个评估值与预设的健康值进行比较，若小于该预设健康值，则表示该评估值为健康值，对应的节点为健康节点或正常节点，若大于或者等于该预设健康值，则表示该评估值为不健康值，相应的，该评估值多对应的节点为不健康节点或为故障节点。

进一步的，第一节点还可以根据前述M个评估值中表示健康或者不健康的评估值的数量作为依据评估该第一节点自身是否健康。具体评估可以为：若为M个评估值中评估解雇表示健康值的评估值超过预设占比，比如超过百分之五十，则确定第一节点为故障节点。进一步的，当该第一节点确定自身为故障节点后，该第一节点可以根据故障决策规定的处理方式进行相应的处理，例如使自己空转或关闭。

在该实现方式中，第一节点获取了多组与节点集群中其它所有的节点的心跳时延数据，再根据这些心跳时延数据评估第一节点至每个节点的通信情况，从而根据通信情况的健康与否的占比确定第一节点是否为故障节点。从而使得每个节点都具备故障的自我评估能力，而无需依赖于节点集群中的其它节点进行故障评估，而且在判断自我为故障节点后自主进行空转或等处理。这样，可以一定程度上防止故障节点进行故障决策以及可能引起的多重故障处理等情况，从而使得故障检测的方式更为合理和高效，提高了故障检测的准确性和效率。

另一种可能的实现方式中，第一节点根据N组心跳时延数据计算M个评估值，可以为：

第一节点根据N组心跳时延数据中M个心跳时延数据的抖动情况计算M个评估值，其中，M个心跳时延数据的抖动情况为第一节点至所述M个节点中每个节点的心跳时延数据的抖动情况，心跳时延数据的抖动幅度越大，评估值越大。

一个心跳时延数据的抖动情况指的是第一节点至同一个节点的N个心跳时延数据所展示的抖动情况。抖动幅度越大，则表示通信情况越差，则评估值越大，若抖动越小，则表示通信情况越好，则评估值越小。该实现方式中，通过心跳时延数据的抖动情况计算评估值，使得评估值的计算更为合理，从而在后续的故障确定中更为准确。

可选的，第一节点还可以根据N组心跳时延数据中M个心跳时延数据的抖动情况、以及M个心跳时延数据的时延水平情况计算M个评估值，其中，M个心跳时延数据的时延水平情况为第一节点至M个节点中每个节点的心跳时延数据的时延水平情况。

时延水平情况表示第一节点至M个节点中某一节点的心跳往返的时延水平，比如，该时延水平为平均时延值，通过时延水平能够在一定程度上反应第一节点与其它节点的通信情况，因此，结合时延水平以及抖动情况可以更合理计算该评估值。

可选的，第一节点在根据N组心跳数据计算M个评估值之前，第一节点还可以先将N组心跳数据中的无效数据删除。由于在心跳时延数据采集时，可能会由于网络情况采集到一些无效数据，比如噪声数据，这些无效数据与实际的心跳时延数据区别一般是很大的，因此可以先通过滤波或降噪的方式删除掉其中的无效数据。

可选的，第一节点在计算得到M个评估值后，还可以对该M个评估值进行标准化处理，使得第一节点在不同时延网络环境下或者不同窗口大小的心跳时延数据的情况下均能进行统一的评估值的比较。

另一种可能的实现方式中，该方法还包括：

若M个评估值中大于预设健康值的数量超过预设占比，第一节点确定第一节点为故障节点，以及若M个评估值中大于预设健康值的数量未超过预设占比，第一节点则确定第一节点为正常节点。

若不健康的评估值的数量较多，则表示第一节点与多数的其它节点的通信情况都较差，那么第一节点则认为自己为故障节点。若不健康的评估值的数量较少，则表示第一节点与多数的其它节点的通信情况较好，那么第一节点则认为自己为正常节点。

可选的，当第一节点确定第一节点为故障节点之后，第一节点还可以将第一节点空转或者关闭。

其中，空转指的是第一节点不对该故障情况做任何处理，仍然进行当前正常的处理作业，等待管理节点将其移除；关闭指的是第一节点将第一节点中正在进行进程全部关闭。

可选的，在第一节点确定第一节点为正常节点之后，该方法还包括：

第一节点根据M个评估值确定节点集群中的管理节点。

由于故障节点不能成为管理节点，因此，若第一节点为故障节点，则无需确定第一节点是否为管理节点。若第一节点为正常节点，则第一节点还需确定第一节点是否为管理节点。

确定管理节点的方式可以为：

第一节点根据M个评估值确定节点集群中评估值小于或等于所述预设健康值所对应的节点为正常节点，再获取所确定的正常节点的序号。第一节点将第一节点的序号与所获取的序号进行比较，若第一节点的序号小于所获取的序号的任意一个序号，则确定第一节点为管理节点。

在该实现方式中，是通过确定节点集群中所有正常节点中序号最小的节点为管理节点。可选的，确定管理节点的方式还可以为其它方式，比如，确定节点集群中所有正常节点中序号最大的节点为管理节点。本申请对此不做限定。该实现方式中，每个节点均能通过自我评估从而确定自己是否为节点集群中的管理节点，避免了多个节点为管理节点，从而产生多重故障决策所可能引起的故障处理冲突等情况。当节点自我评估为故障节点后，则不会参与管理节点的确认，从而故障节点不会成为管理节点，从而也提高了节点集群的稳定性。

另一种可能的实现方式中，在确定第一节点为管理节点之后，该方法还包括：

第一节点根据所述M个评估值移除或隔离所述M个节点中评估值大于所述预设健康值的节点的K个节点，K为大于或等于0的整数。

在该实现方式中，当第一节点确定为管理节点之后，第一节点则需要执行管理节点的管理功能，即将节点集群中为故障节点的节点均需要移除或者隔离。这样，减少了故障节点对节点集群的影响。

另一种可能的实现方式中，节点健康度触发条件为所述第一节点检测节点集群中存在的异常节点，或者第一节点接收到其它节点广播的存在异常节点的消息；在第一节点根据N组心跳时延数据计算M个评估值之前，该方法还包括：

第一节点判断异常节点在预设时长内是否恢复正常，若在预设时长内异常节点未恢复正常，则第一节点开始根据所采集到的N组心跳时延数据计算M个评估值。若在预设的时长内异常节点恢复正常，则第一节点无需进行评估值的计算。

在节点集群中，每个节点都有一个或多个其它节点对其进行监视，即实时检测该节点是否异常。比如，第一节点实时监视着第二节点，第一节点向第二节点发送测量信号，若第二节点未回复接收确认信息或者长时间未回复，则表示第二节点可能异常。从而第一节点则可以开始进行心跳时延数据的采集。

在实现方式中，先通过异常检测方式检测节点集群中是否存在可能异常的节点，若检测到的异常节点在较短的时间内恢复为正常，则无需进行后续的评估和故障的确定；若检测到的异常节点在较短的时间内未恢复正常，则表示在节点集群中出现了故障节点，则进行后续的评估以及故障节点的确定等步骤。这样，提高了系统资源的利用率。

第二方面，本申请实施例提供一种故障检测的装置，该装置具有实现上述第一方面中任意一种所描述实现方式中功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第三方面，本申请实施例提供一种故障检测的装置，该装置包括：处理器、存储器，处理器、存储器通过总线连接，存储器存储有计算机指令，处理器通过执行计算机指令用于实现如第一方面所描述的任意一种实现方式。

第四方面，本申请实施例提供一种可读存储介质，该存储介质存储有用于实现如第一方面所描述的任意一种实现方式的计算机指令。

第五方面，本申请实施例提供一种计算机程序产品，该计算机程序产品包括计算机软件指令，该计算机软件指令可通过处理器进行加载来实现如第一方面所描述的任意一种实现方式中的流程。

第六方面，本申请实施例提供一种芯片装置，该芯片系统包括处理器和存储器，处理器连接到存储器，该处理器可以运行存储器存储的指令，以使该芯片装置执行上述第一方面所描述的任意一种实现方式。

第七方面，本申请实施例提供一种故障检测的系统，该系统为分布式的集群系统，该节点集群系统中包括多个节点，其中，每个节点如实现第一方面任意实现方式的第一节点。

附图说明

图1为本申请实施例中故障检测的方法所应用的系统架构的一个实施例的示意图；

图2为本申请实施例中节点模块划分的一个实施例示意图；

图3为本申请实施例中节点的单元划分的一个实施例示意图；

图4为本申请实施例中故障检测的方法的一个实施例示意图；

图5为本申请实施例中触发心跳采集和评估的一个流程示意图；

图6为本申请实施例中评估模型的框架示意图；

图7为本申请实施例中故障检测的方法所应用的一个应用场景示意图；

图8为本申请实施例中故障检测的方法所应用的另一应用场景示意图；

图9为本申请实施例中故障检测的方法所应用的另一应用场景示意图；

图10为本申请实施例中故障检测的装置的一个实施例示意图；

图11为本申请实施例中故障检测装置的另一实施例示意图。

具体实施方式

本申请实施例提供了一种故障检测的方法、装置及系统，用于提高故障检测的准确率。

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

参照图1所示，图1为本申请实施例中故障检测的方法所应用的系统架构示意图。图1所展示的是一个节点集群，该节点集群中包括多个节点，为了方便描述，图1中的节点集群以四个节点为例进行说明，包括节点1、节点2、节点3以及节点4。四个节点相互连接，每个节点都被一个或多个其它节点监视。每个节点都具备异常检测模块、心跳采集模块以及评估决策模块，如图2所示。需要说明的是，本申请实施例所提供的故障检测方法可以适用于任何去中心化的、无专用故障检测节点的基于对等网络(peer to peer，P2P)方式组织的集群环境中(如Akka-Cluster的集群组织方式)。对此，本申请不做限定。

在本申请中，异常检测模块，用于实时检测节点所监视的其它节点的异常情况。比如，节点1通过异常检测模块检测到节点2可能异常，节点1则会将该异常信息进行广播，通知节点2、节点3以及节点4，并约定在预设时长内，比如10秒内若节点2未能恢复到正常情况，则所有节点进行评估决策。若在预设时长内节点2恢复到正常情况，则无需进行评估决策，具体可参考下面图4实例中步骤402的描述内容。

心跳采集模块，用于对节点集群中所有的节点进行心跳时延数据的采集，该心跳时延数据为一个节点至另一个节点的心跳往返时延。比如，当节点1检测到节点2可能异常时，节点1将该异常信息进行广播，节点集群中所有的节点则开始通过心跳采集模块对心跳时延数据进行采集。在一种实现方式中，心跳模块所采集的心跳时延数据为节点接收到异常信息的广播后，向节点集群中的其它节点发送心跳测量信息所采集到的心跳时延数据。通过该实现方式所采集的心跳时延数据能够较为准确地体现出整个节点集群的网络通信状况。另一种实现方式中，由于通过发送心跳测量信息采集心跳时延数据会耗费较大的采集时间，且在较短时间内采集到的心跳时延数据的数量不会太多。而采集到的心跳时延数据要用作后续的评估决策，越多数量的心跳时延数据评估决策的准确性越高。因此，在该实现方式中，节点在接收到异常信息的广播后，既通过向节点集群中的其它节点发送心跳测量信息采集一定数量的心跳时延数据，节点还可以采集一定数量的最新的历史心跳时延数据，历史心跳时延数据指的是节点在进行当前进行发送心跳测量信息之前，通过发送心跳测量信息所采集到的心跳时延数据。每个节点均需要采集N组心跳时延数据，该N为大于1的整数，比如，每个节点采集10组心跳时延数据，每个节点所采集到的心跳时延数据用于评估决策模块进行故障分析。

评估决策模块，用于根据心跳采集模块所采集到的N组心跳时延数据对节点之间的通信链路健康情况进行评估，并根据评估结果确定节点是否故障。比如，节点1根据所采集到的N组心跳时延数据的心跳抖动情况计算出节点1至其它节点的评估值。如，计算出节点1至节点2的评估值为2.3，节点1至节点3的评估值为3.1，节点1至节点4的评估值为1.4。节点1再根据预设的健康值确定哪些链路的评估值不健康。比如，预设的健康值为2.5，则可以确定节点1至节点2的链路正常，节点1至节点3的链路不正常，节点1至节点4的链路正常。节点1再通过评估决策模块根据所统计的多条链路的情况确定节点1是否为正常节点，若正常链路的数量超过预设占比，比如超过百分之五十，则确定该节点为正常节点，若正常链路的数量未超过预设占比，则确定该节点为故障节点。比如，上述举例中，可以确定节点1为正常节点。评估决策模块还用于节点确定该节点是否能够成为管理节点(Leader)，并具备当该节点为管理节点时移除或隔离故障节点的能力。比如，当节点1为正常节点时，该节点则根据其序号与其它为正常节点的序号确定节点1是否为管理节点，其中第一节点的序号为第一节点根据其IP地址以及端口号通过哈希运算后得到的，每个在加入该节点集群时均会将其所计算得到的序号所广播给所有节点，因此，第一节点中存储有所有的其它节点的序号。比如，该管理节点的确定方法为：确定为正常节点中序号最小的节点为管理节点，此处的正常节点指的是上述节点1通过评估后确定节点1为正常节点，则与节点1通信链路为健康的节点均为正常节点(比如上述的节点2和节点4)。当节点1确定节点1为管理节点后，节点1还需将节点集群中故障的节点3进行移除或者隔离。

需要说明的是，本申请中所描述的节点可以为服务器，也可以为终端，或者其它具备上述模块能力的设备，本申请对此不做限定。

本申请实施例中所描述的节点还可以以另一种形式体现，如图3所示，在该实施例中，该节点100包括处理器110、存储器120、网络控制器130以及网络接口131，处理器110、存储器120、网络控制器130以及网络接口131分别通过总线连接。其中，处理器110，用于控制网络接口131采集其它节点的心跳时延数据，并根据心跳时延数据计算多个评估值，并根据多个评估值决策节点100是否故障。当确定节点100为正常节点时，还需确定该节点100是否为管理节点。若确定该节点100为管理节点，处理器110还需根据评估值确定待移除或者隔离的故障节点。

存储器120，用于存储发送消息(例如，发送心跳测量消息)的时间，并根据网络控制器130收到的该消息的返回消息的时间，经由中央处理器110计算，得到并存储到该消息往返时延。

网络控制器130：依据中央处理器110的指令向目的节点经由网络接口131发送数据；相应的，在目的节点端，数据经由网络接口131，通过网络控制130器发送至中央处理器110。

参照图4所示，对本申请实施例中故障检测的方法进行示例性描述。该故障检测方法实施例应用在上述图1所述的系统架构中，其中的第一节点可以是上述图2或3所示实施例中的节点。该故障检测方法可以包括如下处理：

401、第一节点采集N组心跳时延数据。

其中，N组心跳时延数据中每组心跳时延数据包含M个心跳时延数据，M个心跳时延数据为第一节点至节点集群中M个节点的心跳时延数据，M个节点为节点集群中除第一节点以外的所有其它节点，N和M为大于1的整数，节点集群中的节点数量为M+1。

第一节点所采集的N组心跳时延数据是用于后续对其它节点进行健康度评估，在第一节点采集N组心跳时延数据之前，第一节点先判断是否满足节点健康度评估的触发条件，其判断方式为如下实现方式：

在一种实现方式中，节点集群中每个节点都有相邻的一个或多个节点对其监视。比如，节点集群中包括四个节点，分别为第一节点、第二节点、第三节点以及第四节点，第四节点监视第一节点，第一节点监视第二节点，第三节点监视第四节点。监视的方式为节点之间实时发送测量信号，比如，第一节点实时向第二节点发送测量信号，若未接收到第二节点的反馈确认或者反馈时延过高，则第一节点确认第二节点可能存在异常。此时，第一节点则可以进行心跳时延数据的采集。

在另一种实现方式中，基于上一种实现方式的监视机制，当第一节点未监视到第二节点出现异常，但第三节点监视到第四节点异常，且第三节点在节点集群中广播了第四节点异常的信息，第一节点接收到该异常信息后，也会触发第一节点进行心跳时延数据采集的步骤。

在另一种实现方式中，节点集群中所有的节点预先约定，按照预设的固定周期进行心跳时延数据的采集。比如，每隔10分钟，所有节点则进行心跳时延数据采集，采集10组心跳时延数据后结束采集，或者采集10秒后结束采集。

第一节点进行心跳时延数据采集时，需对节点集群中所有的节点均进行心跳时延数据采集。心跳时延数据采集的方式如图1实施例中所描述的通过发送心跳测量信息的方式或采集历史心跳时延数据的方式。第一节点采集N组心跳时延数据，其中，N组心跳时延数据中每组心跳时延数据包含M个心跳时延数据。N组心跳时延数据表示为第一节点在不同的N个时间点所采集到的心跳时延数据，M个心跳时延数据表示每组心跳时延数据中都有第一节点至其它所有节点的M个心跳时延数据，其它所有节点的数量为M。比如，第一节点所采集了两组心跳时延数据，包括第一组和第二组心跳时延数据，分别为：[1，2，1]、[3，4，5]，那么第一组心跳时延数据中则表示了第一节点至第二节点的心跳往返时延为1毫秒，第一节点至第三节点的心跳往返时延为2毫秒，第一节点至第四节点的心跳往返为1毫秒；第二组心跳时延数据中则表示了第一节点至第二节点的心跳往返时延为3毫秒，第一节点至第三节点的心跳往返时延为4毫秒，第一节点至第四节点的心跳往返为5毫秒。基于前述举例，那么N＝2，分别为前述的第一组和第二组；M＝3，表示其它节点的数量为3个，因此每组所采集到的心跳时延数据的数量也为3个。需要说明的是，本申请实施例中心跳往返的时延的单位可以为前述的毫秒，也可以为微秒或者秒。对此，本申请不做限定。

402、第一节点根据N组心跳时延数据计算M个评估值。

具体的实施例中，M个评估值用于指示第一节点与M个节点的通信情况，其中，评估值越低，通信情况越好。

在步骤401中已经描述了每组心跳时延数据都包含M个心跳时延数据，且该M个心跳时延数据指代第一节点分别与节点集群中其它每个节点所采集的心跳时延数据。第一节点在采集到N组心跳时延数据后，则表示第一节点分别对节点集群中所有的其它节点均进行了N次的心跳时延数据的采集。第一节点针对每个其它节点，都有N个在不同时间点所采集到的心跳时延数据，因此，第一节点可以对任何一个其它节点根据N个在不同时间点所采集到的心跳时延数据计算一个评估值，由于节点集群中其它节点的数量为M个，从而得到M个评估值。该M个评估值表示第一节点所计算的第一节点至节点集群中的其它M个节点的通信情况。比如，第一节点至第二节点的评估值较低，则表示第一节点与第二节点的通信情况较好。

可选的，若为步骤401所描述的第一节点监视到其它节点出现异常，或者第一节点接收到其它节点广播的异常信息的实现方式，则，在第一节点根据N组心跳时延数据计算M个评估值之前，本申请实施例还可以包括如下步骤：

判断异常节点在预设时长内是否恢复正常，若否，则执行第一节点根据N组心跳时延数据计算M个评估值的步骤；若是，则可不执行第一节点根据N组心跳时延数据计算M个评估值的步骤。

结合图5所示，由于该监视机制下的异常检测并非特别完善，有可能是链路问题或者极少的丢包情况导致的。比如，第二节点的实际情况为正常节点，那么第一节点在检测到第二节点异常后，第一节点还需继续对第二节点进行测量，若在一定时间内检测到第二节点恢复正常后，则无需进行评估值的计算，反之，若在一定时间内第二节点仍未恢复正常，则可以进行评估值的计算(评估值的计算方式参考本步骤后续部分的描述)。需要说明的是，第一节点在检测到异常节点，或者第一节点接收到其它节点广播的异常信息后，第一节点则开始进行心跳时延数据的采集。在采集阶段，第一节点继续对所监视的异常节点继续检测，或者继续接收其它节点广播的信息，若在一段时间内，异常节点未恢复正常，则第一节点进行评估值的计算，若在一段时间内，异常节点恢复正常，则第一节点无需进行评估值的计算。

第一节点在采集到N组心跳时延数据后，则可以根据所采集到的心跳时延数据对第一节点至其它节点之间的链路通信的健康情况进行评估，从而得到M个评估值。

可选的，本申请实施例还提供了一种根据N组心跳时延数据计算M个评估值的方法，为：第一节点根据N组心跳时延数据中M个心跳时延数据的抖动情况计算M个评估值，其中，所述M个心跳时延数据的抖动情况为第一节点至M个节点中每个节点的心跳时延数据的抖动情况，心跳时延数据的抖动幅度越大，评估值越大。下面进行举例说明：

比如，N等于3，第一节点所采集到3组心跳时延数据，分别为：[1，2，1]、[1，100，2]、[1，1，1]，根据这三组心跳时延数据可知，第一节点从第二节点所采集到的心跳时延数据均为1，无心跳抖动情况，从而表示第一节点至第二节点之间的通信平稳；第一节点从第三节点所采集到的心跳时延数据分别为2、100、1，该心跳抖动幅度较大，则表示第一节点至第三节点之间的通信链路可能较差；第一节点从第四节点所采集到的心跳时延数据分别1、2、1，则该心跳抖动较小，从而表示第一节点至第四节点之间的通信链路较好。

由于可靠性的要求，节点集群内节点间的通信常采用传输控制协议(transmission control protocol，TCP)来保证通信的可靠性。本申请提出了一套在TCP协议的基础上，依靠心跳的往返时延历史数据作为输入的节点网络健康度评估模型。图6为该评估模型的总体框架图。该评估模型主要由降噪滤波模块、时延水平评估模块、累计抖动模块、标准化模块、丢包影响模块构成，其中，降噪滤波模块、时延水平评估模块、标准化模块、丢包影响模块为可选模块。降噪滤波模块用于过滤掉一些无效的心跳时延数据；时延水平评估模块用于对心跳的往返时延的评估；累计抖动模块用于对同一节点不同时刻所采集到的心跳时延数据的抖动幅度大小进行计算；标准化模块用于对累计抖动模块所输出的抖动值进行标准化处理，使得不同时延水平的网络和不同的心跳时延数据的数量都能适配；丢包影响模块用于计算当出现丢包时对评估值的影响的大小。评估的步骤为：

1)对采集到的N组心跳时延数据通过降噪滤波模块进行一次降噪处理。

需要说明的是，第一节点在根据N组心跳时延数据进行通过评估模型进行评估计算时，所依据的对象是N组心跳时延数据中以单节点为维度的N个心跳时延数据进行逐一评估。比如，N＝2，M＝3，第一组和第二组心跳时延数据分别为[1，2，1]、[1，100，2]，第一节点在将这两组心跳时延数据输入评估模型时，是以(1，1)、(2，100)以及(1，2)的方式输入的，这样所计算得到的3个评估值则是分别针对3个节点的通信评估情况。

为了避免用户线程调度等因素导致心跳消息的处理被小概率拖延导致评估结果受到不良影响，本方案考虑对心跳时延数据进行滤波后再进行进一步评估。该模块的输入为采集的心跳时延数据T₀，Ln，Dw₀，输出为滤波后的心跳时延数据T，Ln，Dw，使用滤波强度参数：S。其中，T₀指代第一节点初步采集的其它节点中某一节点的多个心跳时延数据，Ln表示在第一节点在对某一节点进行心跳时延数据采集过程中所丢失的心跳时延数据的数量，Dw₀表示心跳时延数据T₀的窗口大小，该窗口大小为第一节点初步采集的某个节点的心跳时延数据的数量。T表示进行滤波后的多个心跳时延数据，Dw表示滤波后的心跳时延数据T的窗口大小。S表示该多个心跳时延数据中需要滤波掉的无效数据的数量，S为预设设置的常量。

在一种具体的实施方式中，一种降噪滤波的实现方式为，对心跳时延数据内最大的S个数据进行剔除操作，得到滤波后的心跳时延数据T及心跳时延数据的数量Dw＝len(T)+Ln，其中“len”为取向量长度运算符，即用于计算该滤波后的心跳时延数据T的数量，Ln表示丢失的心跳时延数据的数量，Dw表示滤波后心跳时延数据T的窗口大小。比如，S等于1，第一节点初步采集的某一节点的一组心跳时延数据为[-1，2，3，10]，“-1”表示丢失一个心跳时延数据，则Ln＝1，则T₀为[2，3，10]，Dw₀＝len(2，3，10)+1，即3+1＝4个。根据该滤波方式，则需要剔除掉其中的最大值10，剔除后得到的T为[2，3]，Ln为1，根据窗口大小Dw的计算公式得到Dw＝len(2，3)+1，即2+1＝3个。

2)对滤波降噪后的心跳时延数据通过时延水平评估模块、抖动累积模块、丢包影响模块，分别计算出网络的固有时延水平、时延的抖动情况、心跳丢失带来的影响。

时延水平评估模块：在丢包网络中，TCP ping-pong消息在发端应用层的观测时延有可能大于固有时延(丢包与TCP的重传机制引发)，若使用该时延的均值作为链路的固有时延的评估标准会存在评估值偏大的情况，进而对标准化步骤产生不良影响。为了尽可能准确的从ping-pong消息的时延历史中评估网络的固有时延，本方案假设目标网络的固有时延不会在心跳历史窗口内发生剧烈波动，这就使得心跳时延历史的大幅度波动主要由TCP重传机制引起。而由于概率性丢包的假设，我们认为在窗口内仍然有数量占比为p的包未受重传机制的影响，也就是没有丢包的完成了往返，使用此部分心跳包的心跳往返时延可以反映链路的固有时延。所以我们从心跳时延数据中选取最小的P*100％的部分，以该部分的均值作为衡量固有时延的标准。

该模块的输入为滤波后的心跳时延数据T，输出为评估的时延水平l，使用分位参量p进行时延评估，分位参量p为经验值，其含义是在该时延水平评估时取多少的心跳时延数据作为链路时延的评估依据。比如，p＝0.5，取百分比值为50％，则表示把一半的高时延的心跳时延数据剔除，留下一半低时延的心跳时延数据。评估算法为如下公式：

l＝mean(left(sort(T，ASC)，p*len(T)))

其中，mean代表向量内元素的均值，sort代表排序，ASC代表升序，len(T)代表对滤波后的心跳时延数据T取向量长度，即计算滤波后的心跳时延数据T的数量。

极端情况下，可以直接从历史中选取最小的历时时延作为输出结果，即

l＝min(T)

抖动累积模块：该模块用于计算心跳时延的抖动情况，累积的方法为将心跳历史曲线进行微分得到心跳变化矢量，使用绝对值将心跳变化矢量数量化，再对数量化的心跳变化率进行积分得到累计抖动值。

模块的输入为滤波后的心跳数据T，输出为累计抖动值A。计算累计抖动值采用如下公式：

A＝∑(|ΔT|)

其中ΔT表示对向量T进行一阶差分，结果为差分向量；|ΔT|表示对向量ΔT的逐个元素取绝对值，构成的新向量；∑(|ΔT|)表示对向量|ΔT|的元素求和，结果为抖动累积值A。

丢包影响模块：该模块用于计算丢包对评估值的影响，本方案中丢包影响模块的一种具体的实施方式为：将丢包影响系数Lf与丢包所占比例的乘积作为丢包影响模块的输出L并传递给标准化模块，其中Lf为经验值，比如Lf＝5。

丢包影响值L的计算公式为：

3)将上述三个模块的输出会作为标准化模块的输入，通过标准化模块使用这些计算结果计算出标准化的心跳时延抖动情况作为评估模型的输出。

从抖动累积模块的实现中可以看出，在丢包率不变的情况下，心跳时延数据的抖动情况也不会发生变化，表示网络情况比较稳定，但是随着心跳数据T的向量长度的增大，抖动累积值A也会随之增大；另一方面，在不同时延的网络中，例如百微秒级别时延的网络和百毫秒级别时延的网络中，在丢包率不变的情况下，随着时延增大，由于排队等因素引起的不确定性也会带来额外的抖动增加。

为了使抖动累积值A对不同时延水平的网络和不同的心跳时延数据T的向量长度的尺寸都能适配，以便决策者进行判决，模型需要对A进行标准化。

标准化模型使用链路平均时延水平l、心跳时延数据T的向量长度len(T)对抖动累计值A进行标准化，并将丢失心跳带来的影响L叠加在累计结果中。

该模块的输入为A，L，len(T)，l，输出为

使用如下公式对A进行标准化并与丢包影响的叠加：

输出量

的单位：1/s，反映单位时间内时延跳变的强度。

为了更清楚的描述上述各个模块的功能与使用，下面进行举例说明：

假设第一节点对第二节点所采集的的一组心跳时延数据为(1，2，1，5，3，260，-1，5，4，4)，其中-1代表心跳丢失。去掉丢失后的心跳后，则

T0＝(1，2，1，5，3，260，5，4，4)

Ln＝1

Dw0＝10

设降噪模块的强度S＝1，则心跳历史数据经过降噪模块后得到降噪后的心跳时延数据为：

T＝(1，2，1，5，3，5，4，4)

Ln＝1

Dw＝9

设时延水平评估模块的分位参数p＝0.5，则滤波后的心跳历史数据经过时延水平模块，其计算过程及结果l为：

sort(T，ASC)＝(1，1，2，3，4，4，5，5)

p*len(T)＝4

left(sort(T，ASC)，p*len(T0))＝(1，1，2，3)

l＝mean(left(sort(T，ASC)，p*len(T)))＝2.75

滤波后的心跳数据经过抖动累积模块，其计算过程及结果A为：

ΔT＝{Ti-Ti-1(0＜i＜len(T))}

上述公式表示为计算心跳时延数据T中两两之间的差值，即将心跳时延数据T中后一个心跳时延数据减去前一个心跳时延数据，得到如下结果：

ΔT＝(2-1，1-2，5-1，3-5，…，4-4)＝(1，-1，4，-2，2，-1，0)

ΔT＝(1，1，4，2，2，1，0)

A＝∑(|ΔT|)＝11

设丢包影响模块的丢包影响系数Lf＝5，则滤波后的心跳历史数据经过丢包影响模块，其结果L为：

L＝5*1/9＝0.56

时延水平l、抖动累积A、丢包影响L、T的长度len(T)经过标准化模块，其结果

为：

403、第一节点判断M个评估值中大于预设健康值的数量是否超过预设占比，若是，则执行步骤404，若否，则执行步骤405。

根据上述步骤402所描述的内容，第一节点根据N组心跳时延数据计算得到M个评估值后，则判断每个评估值是否健康。比如通过将每个评估值与预设的健康值进行比较，若评估值小于或等于预设健康值，则表示所对应的链路正常，若评估值大于预设评估值，则表示对应的链路故障。第一节点在计算得到每个评估值的健康情况后，再根据其中不健康评估值的数量确定第一节点是否为故障节点。比如，该预设占比为百分之五十，该确定的方式为，若不健康评估值的数量超过预设占比，则表示该第一节点至大多数的节点的链路都不健康，因此，则可以确定该第一节点故障；若不健康评估值的数量未超过预设占比，则表示第一节点至大部分的节点之间的链路为正常，则可以确定第一节点为正常节点，并且可以确定评估值小预设健康值的其它节点也是正常节点。

参照图6所示，在计算得到M个评估值

后，则将每个

与预设健康值thres进行比较，若小于该预设健康值thres，则表示该

为健康值，否则，则表示该

为不健康值。比如，根据步骤402中的举例中所计算的

为1.1，若预设健康值thres＝2.5，1.1＜2.5，则表示该

为健康值。

404、第一节点确定所述第一节点为故障节点。

若不健康评估值的数量超过预设占比，则表示该第一节点至大多数的节点的链路都不健康，因此，则可以确定该第一节点故障。在确定第一节点为故障节点后，第一节点可以进行自我关闭，以减少对节点集群的影响，第一节点还可以输出故障提示信息，用于提示用户第一节点故障。

可选的，第一节点在确认自己为故障节点之后，第一节点还可以将自己进行空转或关闭。其中，空转指的是第一节点不对该故障情况做任何处理，仍然进行当前正常的处理作业，等待管理节点将其移除；关闭指的是第一节点将第一节点中正在进行进程全部关闭。

405、第一节点确定所述第一节点为正常节点。

若不健康评估值的数量未超过预设占比，则表示第一节点至大部分的节点之间的链路为正常，则可以确定第一节点为正常节点。

406、第一节点根据M个评估值确定节点集群中的管理节点。

第一节点为在确定第一节点为正常节点后，第一节点则可以根据该M个评估值确定节点集群中的同样为正常的节点。确定的方式可以为将M个评估值与预设的健康值进行比较，若小于预设健康值，则表示所对应的节点为正常节点。从而第一节点再根据所确定的正常节点确定节点集群中的唯一管理节点。

可选的，确定管理节点的方式可以为：

第一节点获取M个节点中正常节点的序号。

节点的序号是每个节点根据其固有的IP地址或者端口号通过哈希计算所得到的序号，每个节点的序号在节点集群中互不相同。当有新的节点加入该节点集群中，该新的节点或者管理节点向节点集群中所有节点广播该新的节点的序号，因此，第一节点中存储有节点集群中所有节点的序号。第一节点则从所存储的所有节点的序号的集合中查找出此时为正常节点的序号。

第一节点将第一节点的序号与所获取的序号进行比较。

若第一节点的序号小于所获取的序号的任意一个序号，则确定第一节点为管理节点，反之，则确定第一节点不是管理节点。

可选的，第一节点根据序号确定管理节点的方式也可以有多种，具体可以根据节点集群中所有节点的约定而定，比如，可以根据序号最大的节点作为管理节点，或者随机确定一个节点为管理节点，并广播给其它节点等等。对此，本申请不做限定。

407、若确定第一节点为管理节点，则第一节点根据M个评估值移除或隔离所述M个节点中的K个节点，K个节点为评估值大于预设健康值的节点。

在确定第一节点为管理节点后，为了减少节点集群中故障节点对节点集群的影响，第一节点则需要将节点节点集群中故障的K个节点进行移除或者隔离。其中，移除的方式为第一节点将该K个故障节点的信息广播至节点集群中的所有节点，再收到所有节点的接收确认信息后，则断开该K个故障节点的通信连接。隔离的方式为第一节点将该K个故障节点的信息广播至节点集群中的所有节点，并通知所有节点将该K个节点拉入黑名单，使得所有节点暂时不与该K个节点进行通信。

本申请实施例中，每个节点通过对节点集群中所有的节点进行心跳时延数据的采集，并根据心跳时延数据计算出相应的评估值，根据评估值中为健康数量的占比确定节点是否故障，从而再确定节点集群中的管理节点，这样，提高了故障检测的准确率。

此外，通过本申请实施例所示的方案，每个节点都具备故障的自我评估能力，而无需依赖于节点集群中的其它节点进行故障评估，而且在判断自我为故障节点后自主进行空转或等处理。这样，可以一定程度上防止故障节点进行故障决策以及可能引起的多重故障处理等情况，从而使得故障检测的方式更为合理和高效，提高了故障检测的准确性和效率。

另外，本申请实施例中，每个节点均能通过自我评估从而确定自己是否为节点集群中的管理节点，避免了多个节点为管理节点，从而产生多重故障决策所可能引起的故障处理冲突等情况。当节点自我评估为故障节点后，则不会参与管理节点的确认，从而故障节点不会成为管理节点，从而也提高了节点集群的稳定性。

另外，本申请实施例中节点依靠心跳时延数据作为故障检测依据还可以克服现有技术的其他问题。现有的基于TCP协议的seq、ack序号判断目标节点的健康情况的方案的缺点是：集群中的节点的应用逻辑一般位于操作系统的用户空间中，该空间下应用逻层无法直接读取到位于系统底层内核态下网络互连协议(internet protocol，IP)协议栈中传输层的相关内容。如果采取进更进一步的机制来读取这些内容，则会增加系统的复杂性，以及对操作系统的依赖性，增加对节点的维护成本。本申请方案中，提出了在TCP协议的基础上，依靠心跳的往返时延历史数据作为输入的节点网络健康度评估模型，这样，基于传输层的心跳往返时延的采集，则能实现该评估模型，无需依赖于底层系统，减少了系统的复杂度，从而减少了节点维护的成本。

为了更清楚的阐述本申请的方案，下面结合图7所示应用场景，对本申请实施例中故障检测的方法的进行举例描述。图7所示的应用场景为由三个节点组成的节点集群内存在一个非管理(Leader)节点出现故障节点的情况下，本申请方案的触发及决策流程。

如图7所示，其中节点(Node)1为Leader节点，Node3为故障节点。在该实例中，因Node1丢失了较多来自Node3的心跳消息，故Node1认为Node3故障，并将该消息告知Node2。Node3同样因为丢失了较多来自Node1的消息，认为Node1故障，但Node3仍然将这条从全局角度看不正确的消息告知了Node2。这些消息触在各个节点内都触发了各自的心跳时延采集模块与评估决策计划，使得这些节点在决策周期(即上述实施例所描述的计算评估值并根据评估值确定自己是否为故障节点)结束后将进行评估与决策。若不进行评估而直接进行决策，则Node2将会认为自己是Leader节点，并将Node1、Node3从集群中移除。

经过决策周期，各节点分别进入各自的评估决策流程中。各节点依据评估结果进行自检。其中Node3由于两个评估结果均表示健康度为差，则其认为自己属于故障节点；Node1、Node2则发现存在至少一个其他节点的评估结果为良好，良好的节点数量达到评估值数量的一半，则他们认为自己处于正常工作的状态。又由于Node1的序号在Node1和Node2中最小，故Node1认为自己是集群的Leader节点，Node2的序号大于Node1的序号，认为自己不是集群的Leader。则Node1会在决策时刻时将Node3移出集群，Node3也会根据故障决策所规定的处理方式空转或将自己关闭。

参照图8所示的应用场景，图8为以五节点所组成的节点集群内存在一个管理节点故障和一个非管理节点故障情况时，本申请方案的触发及决策流程。

如图8所示，其中Node1为故障前的Leader节点，现在发生了故障，Node4为另一非Leader故障节点。其中图8中还展示了决策前各节点故障检测机制发现的节点故障情况。

经过决策周期，各节点分别进入各自的决策流程中。其中Node1、Node4因评估结果表明其到所有其他节点的状态都为差，则认为自己为故障节点。Node2、Node3、Node5则因为存在节点的评估结果为好，且这种评估为好的节点的数量大于评估值数量的半数，所以他们都认为自己是正常节点，又因这些正常节点中Node2的序号最小，故Node2被确定为新的Leader。Node2会将Node1与Node4从集群中移除，Node1与Node4也会根据故障决策所规定的处理方式空转或将自己关闭。

参照图9所示的应用场景，图9为以五节点所组成的节点集群内存在一个交换设备故障的情况时本申请方案的触发及决策流程。

如图9所示，假设其中故障的核心交换机的故障表现为以一定概率丢包。则因核心交换机故障导致的丢包将会导致五个节点间左集群与右集群的心跳消息往返时延的抖动或心跳消息的丢失。这种现象将最终被各节点的故障检测机制发现并触发各自的评估决策计划。

经过决策周期，各节点分别进入自己的评估决策流程。其中Node4、Node5因其自检结果表明超过半数的集群节点为不健康状态，则他们认为自己为故障节点(实质为处于不健康集群中)；Node1、Node2、Node3则因超过半数的节点的评估状态为好，所以这些节点认为自己为正常节点。又因为这些节点中Node1的序号最小，故Node1为集群的Leader。Node1根据评估结果将Node4、Node5从集群中移除；Node4、Node5也会根据集群故障所定义的规则将自己关闭或空转。

上述实施例所描述的实现方式中，为每个节点在进行评估值计算时，需要采集节点集群中所有的其它节点的心跳时延数据，从而计算该节点至每个节点的通信链路的评估值，再确定自己是否故障，进而判断自己是否为管理节点。可选的，本申请实施例还提供了另一种实现方式，如下描述：

在针对节点集群内节点较少的情况，认为单位时间内全网范围内心跳测量消息的发送是可以容忍的。然而，对于节点集群内节点数量较多的网络环境下，心跳测量消息可能带来较大的网络开销。因此，在本实现方式中，可以设计更进一步的方案：节点先通过粗粒度的心跳时延数据(即，尽可能少的心跳时延数据)自检，首先尝试排除自己是集群管理者的可能，则确定自己故障或者当自己为正常节点但自己的序号大于其它正常节点的序号。如果这种可能不能排除，则进行更细粒度的心跳时延数据(即，采集全网所有节点的心跳时延数据)进行自检，用来确认自己是领导者以进行决策。

比如，节点集群中有100个节点，第一节点首先采集其它20个节点的心跳时延数据，计算出20个评估值，若超过半数的评估值为不健康值，则可以确定该第一节点为故障节点，从而确定了第一节点不会成为管理节点，因此该第一节点无需再做心跳时延数据的采集。若超过半数的评估值为健康值，则表示该第一节点为正常节点，该第一节点再比较自己与这20个节点中正常节点的序号，若确定该第一节点的序号不是最小序号，那么确定该第一节点也不会成为管理节点，从而无需再采集与其它节点的心跳时延数据。若该第一节点通过20个评估值确定为第一节点为正常节点且第一节点的序号与20个节点中正常节点的序号中比较是最小的，那么第一节点则有可能为管理节点。从而第一节点还需采集其它79个节点的心跳时延数据，并计算79个评估值，确定79个节点中的正常节点，从而在将第一节点的序号与79个节点中正常节点的序号进行比较，若第一节点的序号仍是最小的，则确定第一节点为管理节点，若第一节点的序号不是最小的，则确定第一节点不是管理节点。

由于在节点数量较多的节点集群中，一般情况下网络是较稳定的，出现大面积节点故障的情况较少，一般情况是出现极少数的故障节点。因此，通过本实现方式，一般也能准确地进行节点的自我故障检测，并且减少了网络的开销。

参照图10所示，图10为本申请实施例中故障检测的装置的一个实施例示意图，该装置600应用于分布式的节点集群，所述节点集群包括多个节点，所述方法由所述多个节点中的任一节点执行，所述任一节点为第一节点，所述装置为所述第一节点，该装置600包括：判断单元601以及评估单元602；

其中，判断单元601用于判断是否满足节点健康度评估触发条件，评估单元602用于用于当满足所述节点健康度评估触发条件时，根据所述第一节点与所述节点集群中的其它节点之间的心跳时延数据分别对所述节点集群中的其它节点健康度进行评估，并获得所述集群中的其它节点的健康度的评估结果。

具体的，判断单元601，用于执行图4实施例中步骤401中所描述的三种节点健康度评估触发的实现方式；

评估单元602，用于执行图4实施例中的步骤401至403。

可选的，所述评估单元602包括：

采集单元6021，用于执行图4实施例中的步骤401中所描述的内容；

计算单元6022，用于执行图4实施例中的步骤402。

可选的，所述装置600还包括：

删除单元605，用于在所述评估单元602根据所述N组心跳时延数据计算M个评估值之前，删除所述N组心跳时延数据中的无效数据；删除无效数据后的N组心跳时延数据用于计算所述M个评估值。

可选的，所述装置600还包括：

确定单元603，用于执行图4实施例中的步骤404。

可选的，确定单元603还用于执行图4实施例中的步骤405。

可选的，所述确定单元603还用于：执行图4实施例中的步骤406。

可选的，所述装置600还包括：

处理单元604，用于执行图4实施例中的步骤407。

图6实施例所描述的各个单元在运行时执行图4实施例中所描述的第一节点的执行步骤，详细内容可参照图4实施例，此处不做赘述。

图6实施例所述的装置还有另一个形式的实施例。

参照图11所示，对本申请实施例提供的一种故障检测的装置进行示例性介绍，该装置700包括：处理器701、存储器702、收发器703，所述处理器701、所述存储器702以及所述收发器703通过总线704连接，收发器703可以包括发送器与接收器，所述存储器702存储有计算机指令。其中，收发器703用于对其它节点进行心跳时延数据采集，存储器702用于存储收发器703所采集到的心跳时延数据，处理器701用于调用存储器702中的心跳时延数据进行评估其它节点的健康状况，并确定本节点是否为管理节点。

该处理器701至少用于判断是否满足节点健康度评估触发条件；

该处理器701至少还用于：当满足所述节点健康度评估触发条件时，根据所述第一节点与所述节点集群中的其它节点之间的心跳时延数据分别对所述节点集群中的其它节点健康度进行评估，并获得所述集群中的其它节点的健康度的评估结果。

具体的：

收发器703用于执行图4实施例中的步骤401；

存储器702用于存储所采集到的心跳时延数据；

处理器701用于执行图4实施例中的步骤402至407。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在另一种可能的设计中，当上述装置为设备内的芯片时，芯片包括：处理单元和通信单元，所述处理单元例如可以是处理器，所述通信单元例如可以是输入/输出接口、管脚或电路等。该处理单元可执行存储单元存储的计算机执行指令，以使该设备内的芯片执行上述实施例中任意一种资源调度的方法。可选地，所述存储单元为所述芯片内的存储单元，如寄存器、缓存等，所述存储单元还可以是所述终端内的位于所述芯片外部的存储单元，如只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)等。

其中，上述任一处提到的处理器，可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制上述第一方面无线通信方法的程序执行的集成电路。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

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

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

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

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (29)

1.一种故障检测的方法，所述方法应用于分布式的节点集群，所述节点集群包括多个节点，所述方法由所述多个节点中的任一节点执行，所述任一节点为第一节点，其特征在于，所述方法包括：

所述第一节点判断是否满足节点健康度评估触发条件；

当满足所述节点健康度评估触发条件时，所述第一节点采集N组心跳时延数据，所述N组心跳时延数据中每组心跳时延数据包含M个心跳时延数据，所述M个心跳时延数据为所述第一节点至节点集群中M个节点的心跳时延数据，所述M个节点为所述节点集群中的其它节点，其中，所述N和所述M为大于1的整数；

所述第一节点根据所述N组心跳时延数据计算M个评估值，所述M个评估值用于指示所述第一节点与所述M个节点的通信情况，其中，评估值大于预设健康值所对应的节点为故障节点；

若所述M个评估值中大于所述预设健康值的数量超过预设占比，所述第一节点确定所述第一节点为故障节点；以及

若所述M个评估值中大于预设健康值的数量未超过预设占比，所述第一节点确定所述第一节点为正常节点。

2.根据权利要求1所述的方法，其特征在于，所述第一节点根据所述N组心跳时延数据计算M个评估值，包括：

所述第一节点根据所述N组心跳时延数据中M个心跳时延数据的抖动情况计算M个评估值，其中，所述M个心跳时延数据的抖动情况为所述第一节点至所述M个节点中每个节点的心跳时延数据的抖动情况，心跳时延数据的抖动幅度越大，评估值越大。

3.根据权利要求2所述的方法，其特征在于，所述第一节点根据所述N组心跳时延数据中M个心跳时延数据的抖动情况计算M个评估值，包括：

所述第一节点根据所述N组心跳时延数据中M个心跳时延数据的抖动情况、以及M个心跳时延数据的时延水平情况计算M个评估值，其中，所述M个心跳时延数据的时延水平情况为所述第一节点至所述M个节点中每个节点的心跳时延数据的时延水平情况。

4.根据权利要求3所述的方法，其特征在于，所述第一节点根据所述N组心跳时延数据中M个心跳时延数据的抖动情况、以及M个心跳时延数据的时延水平情况计算M个评估值，包括：

所述第一节点根据所述N组心跳时延数据中M个心跳时延数据的抖动情况、M个心跳时延数据的时延水平情况以及M个心跳时延数据的丢包情况计算M个评估值，其中，所述M个心跳时延数据的丢包情况为所述第一节点至所述M个节点中每个节点的心跳时延数据的丢包情况，丢包数量越多，评估值越大。

5.根据权利要求2至4其中任意一项所述的方法，其特征在于，在所述第一节点根据所述N组心跳时延数据计算M个评估值之前，所述方法还包括：

所述第一节点删除所述N组心跳时延数据中的无效数据；删除无效数据后的N组心跳时延数据用于计算所述M个评估值。

6.根据权利要求1所述的方法，其特征在于，在所述第一节点确定所述第一节点为故障节点之后，所述方法还包括：

所述第一节点将所述第一节点空转或关闭。

7.根据权利要求6所述的方法，其特征在于，在所述第一节点确定所述第一节点为正常节点之后，所述方法还包括：

所述第一节点根据所述M个评估值确定所述节点集群中的管理节点。

8.根据权利要求7所述的方法，其特征在于，所述第一节点根据所述M个评估值确定所述节点集群中的管理节点，包括：

所述第一节点根据所述M个评估值确定所述节点集群中的所有正常节点，其中，评估值小于或等于所述预设健康值，则表示对应的节点为正常节点；

所述第一节点获取所确定的正常节点的序号；

所述第一节点将所述第一节点的序号与所获取的序号进行比较，若所述第一节点的序号小于所述所获取的序号的任意一个序号，则确定所述第一节点为管理节点。

9.根据权利要求8所述的方法，其特征在于，在确定所述第一节点为管理节点之后，所述方法还包括：

所述第一节点根据所述M个评估值移除或隔离所述M个节点中的K个节点，所述K个节点为评估值大于所述预设健康值的节点。

10.根据权利要求1至4其中任意一项所述的方法，其特征在于，所述节点健康度评估触发条件为所述第一节点检测所述节点集群中存在的异常节点，或者所述第一节点接收到其它节点广播的存在异常节点的消息。

11.根据权利要求10所述的方法，其特征在于，在所述第一节点根据所述N组心跳时延数据计算M个评估值之前，所述方法还包括：

所述第一节点判断所述异常节点在预设时长内是否恢复正常；

所述第一节点在所述异常节点在预设时长内未恢复正常的情况下执行所述根据所述N组心跳时延数据计算M个评估值的步骤。

12.根据权利要求1至4其中任意一项所述的方法，其特征在于，所述节点健康度评估触发条件为所述第一节点检测到当前时刻为预设周期时刻。

13.根据权利要求8或9所述的方法，其特征在于，所述序号为节点根据其网络协议IP地址以及端口号按照预设算法得到的数值。

14.一种故障检测的装置，所述装置应用于分布式的节点集群，所述节点集群包括多个节点，所述装置由所述多个节点中的任一节点，所述任一节点为第一节点，所述装置为所述第一节点，其特征在于，所述装置包括：

判断单元，用于判断是否满足节点健康度评估触发条件；

评估单元，用于当满足所述节点健康度评估触发条件时，根据所述第一节点与所述节点集群中的其它节点之间的心跳时延数据分别对所述节点集群中的其它节点健康度进行评估，并获得所述集群中的其它节点的健康度的评估结果；

所述评估单元包括：

采集单元，用于采集N组心跳时延数据，所述N组心跳时延数据中每组心跳时延数据包含M个心跳时延数据，所述M个心跳时延数据为所述第一节点至节点集群中M个节点的心跳时延数据，所述M个节点为所述节点集群中除第一节点以外的所有其它节点，其中，所述N和所述M为大于1的整数；

计算单元，用于根据所述N组心跳时延数据计算M个评估值，所述M个评估值用于指示所述第一节点与所述M个节点的通信情况，其中，评估值大于预设健康值所对应的节点为故障节点；

所述装置还包括：

确定单元，用于在所述计算单元根据所述N组心跳时延数据计算M个评估值之后，若所述M个评估值中大于所述预设健康值的数量超过预设占比，确定所述第一节点为故障节点；以及若所述M个评估值中大于预设健康值的数量未超过预设占比，确定所述第一节点为正常节点。

15.根据权利要求14所述的装置，其特征在于，所述计算单元具体用于：

根据所述N组心跳时延数据中M个心跳时延数据的抖动情况计算M个评估值，其中，所述M个心跳时延数据的抖动情况为所述第一节点至所述M个节点中每个节点的心跳时延数据的抖动情况，心跳时延数据的抖动幅度越大，评估值越大。

16.根据权利要求15所述的装置，其特征在于，所述计算单元具体用于：

根据所述N组心跳时延数据中M个心跳时延数据的抖动情况、以及M个心跳时延数据的时延水平情况计算M个评估值，其中，所述M个心跳时延数据的时延水平情况为所述第一节点至所述M个节点中每个节点的心跳时延数据的时延水平情况。

17.根据权利要求16所述的装置，其特征在于，所述计算单元具体用于：

根据所述N组心跳时延数据中M个心跳时延数据的抖动情况、M个心跳时延数据的时延水平情况以及M个心跳时延数据的丢包情况计算M个评估值，其中，所述M个心跳时延数据的丢包情况为所述第一节点至所述M个节点中每个节点的心跳时延数据的丢包情况，丢包数量越多，评估值越大。

18.根据权利要求15至17其中任意一项所述的装置，其特征在于，所述装置还包括：

删除单元，用于在所述评估单元根据所述N组心跳时延数据计算M个评估值之前，删除所述N组心跳时延数据中的无效数据；删除无效数据后的N组心跳时延数据用于计算所述M个评估值。

19.根据权利要求14所述的装置，其特征在于，所述装置还包括：

处理单元，用于在所述确定单元确定所述第一节点为故障节点之后，将所述第一节点空转或关闭。

20.根据权利要求19所述的装置，其特征在于，所述确定单元还用于：

在确定所述第一节点为正常节点之后，根据所述M个评估值确定所述节点集群中的管理节点。

21.根据权利要求20所述的装置，其特征在于，所述确定单元具体用于：

据所述M个评估值确定所述节点集群中的所有正常节点，其中，评估值小于或等于所述预设健康值，则表示对应的节点为正常节点；

获取所确定的正常节点的序号；

将所述第一节点的序号与所获取的序号进行比较，若所述第一节点的序号小于所述所获取的序号的任意一个序号，则确定所述第一节点为管理节点。

22.根据权利要求21所述的装置，其特征在于，所述装置还包括：

处理单元，用于在所述确定单元确定所述第一节点为管理节点之后，根据所述M个评估值移除或隔离所述M个节点中的K个节点，所述K个节点为评估值大于所述预设健康值的节点。

23.根据权利要求14至17其中任意一项所述的装置，其特征在于，所述节点健康度评估触发条件为所述第一节点检测所述节点集群中存在的异常节点，或者所述第一节点接收到其它节点广播的存在异常节点的消息。

24.根据权利要求23所述的装置，其特征在于，所述判断单元还用于：

在所述计算单元根据所述N组心跳时延数据计算M个评估值之前，判断所述异常节点在预设时长内是否恢复正常；

所述计算单元在所述异常节点在预设时长内未恢复正常的情况下根据所述N组心跳时延数据计算M个评估值。

25.根据权利要求14至17其中任意一项所述的装置，其特征在于，所述节点健康度评估触发条件为所述第一节点检测到当前时刻为预设周期时刻。

26.根据权利要求21或22所述的装置，其特征在于，所述序号为节点根据其网络协议IP地址以及端口号按照预设算法得到的数值。

27.一种故障检测的系统，所述系统为分布式的节点集群系统，所述节点集群系统中包括多个节点，所述多个节点中每个节点如权利要求14至26中任一项所述的第一节点。

28.一种故障检测的装置，包括：处理器、收发器以及存储器，其中，所述处理器、所述收发器以及所述存储器通过总线连接，所述存储器存储有计算机指令，所述处理器通过执行计算机指令用于实现如权利要求1至13中任意一项所述的方法。

29.一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至13中任意一项所述的方法。

Images