CN111338914A - 故障通知方法及相关设备 - Google Patents

Abstract

本申请实施例提供了一种故障通知方法及相关设备，该方法应用于分布式集群中的设备，该设备包括探测设备和被探测设备；该方法包括：在该被探测设备检测到自身出现故障的情况下，该被探测设备向该探测设备发送广播报文；其中，该广播报文用于指示该被探测设备出现故障；该广播报文为不可靠传输协议的报文。采用本申请实施例，能够极大减少分布式集群中探测设备感知被探测设备出现故障的时间，从而避免因探测设备感知故障时间过长导致的业务时延大甚至中断的问题。

Description

故障通知方法及相关设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种故障通知方法及相关设备。

背景技术

在分布式系统中，故障探测主要是通过心跳探测等类似的探测技术发现故障设备。具体的，探测设备每隔一段时间(如3秒)会向分布式集群中的被探测设备发送一次心跳请求，被探测设备收到心跳请求后及时应答探测设备以表明自己可以正常提供业务服务。如果一段时间内(如10s，即发送了3个心跳请求)一直未收到被探测设备的应答，则探测设备认为该被探测设备出现故障。

但是心跳类探测技术探测时间过长，容易造成故障期间业务时延大甚至中断的问题。综上所述，如何解决故障探测时间过长导致故障期间业务时延大甚至中断的问题是本领域技术人员急需解决的技术问题。

发明内容

本申请实施例公开了一种故障通知方法及相关设备，能够极大减少分布式集群中探测设备感知被探测设备出现故障的时间，从而避免因探测设备感知故障时间过长导致的业务时延大甚至中断的问题。

第一方面，本申请公开了一种故障通知方法，该方法应用于分布式集群中的设备，这些设备包括探测设备和被探测设备。该方法包括：

在上述被探测设备检测到自身出现故障的情况下，上述被探测设备向上述探测设备发送广播报文；其中，上述广播报文用于指示上述被探测设备出现故障；该广播报文为不可靠传输协议的报文。

本申请中被探测设备主动检测自身的故障，一旦发现故障立即向探测设备发送故障通知，相比于现有技术，本申请可以使得探测设备快速感知到存在的故障并对故障做出响应，从而避免因探测设备感知故障时间过长导致的业务时延大甚至中断的问题。

在一种可能的实施方式中，上述故障为上述被探测设备的操作系统无法感知的故障；上述被探测设备包括主板和网卡；上述在上述被探测设备检测到自身出现故障的情况下，上述被探测设备向上述探测设备发送广播报文，包括：

上述被探测设备通过上述主板检测到上述被探测设备出现上述故障；上述被探测设备通过上述主板向上述网卡发送通知信号；上述通知信号为上述主板根据上述故障生成；上述被探测设备通过上述网卡根据上述通知信号向上述探测设备发送上述广播报文。

在本申请中，通过被探测设备的主板感知故障，并通过被探测设备的网卡主动向探测设备发送故障通知即上述广播报文，从而解决了被探测设备中操作系统无法感知的故障的通知问题。

在一种可能的实施方式中，上述广播报文注册在上述网卡的网卡驱动中。

在本申请中，预先将出现故障时的故障通知注册在网卡驱动程序中，一旦出现故障可以立即将故障通知消息发送给探测设备，便捷快速。

在一种可能的实施方式中，上述故障为上述被探测设备的操作系统能够感知的故障；上述在上述被探测设备检测到自身出现故障的情况下，上述被探测设备向上述探测设备发送广播报文，包括：

上述被探测设备通过上述操作系统检测到上述被探测设备出现上述故障；

上述被探测设备通过上述操作系统的内核通知链向上述探测设备发送上述广播报文。

本申请通过内核通知链向探测设备主动通知被探测设备出现故障，方便快捷。

在一种可能的实施方式中，上述内核通知链包括的回调函数中注册了上述广播报文；或者，上述内核通知链包括的回调函数用于生成上述广播报文。

在一种可能的实施方式中，上述广播报文包括上述被探测设备在上述分布式集群中的唯一标识；其中，上述唯一标识为上述被探测设备最近一次加入上述分布式集群时重新生成的标识。

本申请将被探测设备在分布式集群中的唯一标识添加到故障通知中，探测设备可以根据该唯一标识对重复接收到的故障通知直接丢弃，从而节约了计算资源。

在一种可能的实施方式中，上述不可靠传输协议为用户数据报协议(userdatagram protocol，UDP)；上述被探测设备向上述探测设备发送的上述广播报文包括多个上述广播报文。

本申请采用UDP广播报文来承载故障通知的信息，能够利用UDP无连接协议特性，即使在设备掉电，操作系统宕机或主机、程序停止工作等情况下也能及时完成故障通知。采用UDP广播报文还可以在集群主故障或多点故障的情况下都能够实现故障通知。此外，通过向探测设备发送多个该广播报文可以避免UDP不可靠传输导致报文丢失的问题。

第二方面，本申请公开了一种故障通知设备，上述故障通知设备属于分布式集群中的被探测设备，上述分布式集群还包括探测设备；上述故障通知设备包括：

第一发送单元，用于在上述故障通知设备检测到自身出现故障的情况下，向上述探测设备发送广播报文；其中，上述广播报文用于指示上述故障通知设备出现故障；该广播报文为不可靠传输协议的报文。

在一种可能的实施方式中，上述故障为上述故障通知设备的操作系统无法感知的故障；上述故障通知设备包括主板和网卡；上述故障通知设备还包括第一检测单元和第二发送单元；

上述第一检测单元，用于通过上述主板检测到上述故障通知设备出现上述故障；

上述第二发送单元，用于通过上述主板向上述网卡发送通知信号；上述通知信号为上述主板根据上述故障生成；

上述第一发送单元，具体用于通过上述网卡根据上述通知信号向上述探测设备发送上述广播报文。

在一种可能的实施方式中，上述广播报文注册在上述网卡的网卡驱动中。

在一种可能的实施方式中，上述故障为上述故障通知设备的操作系统能够感知的故障；上述故障通知设备还包括第二检测单元；

上述第二检测单元，用于通过上述操作系统检测到上述故障通知设备出现上述故障；

上述第一发送单元，具体用于通过上述操作系统的内核通知链向上述探测设备发送上述广播报文。

在一种可能的实施方式中，上述内核通知链包括的回调函数中注册了上述广播报文；或者，上述内核通知链包括的回调函数用于生成上述广播报文。

在一种可能的实施方式中，上述广播报文包括上述故障通知设备在上述分布式集群中的唯一标识；其中，上述唯一标识为上述故障通知设备最近一次加入上述分布式集群时重新生成的标识。

在一种可能的实施方式中，上述不可靠传输协议为用户数据报协议UDP；上述被探测设备向上述探测设备发送的上述广播报文包括多个上述广播报文。

第三方面，本申请公开了一种故障通知设备，上述故障通知设备属于分布式集群中的被探测设备，上述分布式集群还包括探测设备。上述故障通知设备包括处理器、存储器以及通信接口；上述存储器、上述通信接口与上述处理器耦合，上述存储器存储有计算机程序，上述处理器执行上述计算机程序时，上述故障通知设备执行如下操作：

在上述被探测设备检测到自身出现故障的情况下，上述被探测设备向上述探测设备发送广播报文；其中，上述广播报文用于指示上述被探测设备出现故障；该广播报文为不可靠传输协议的报文。

在一种可能的实施方式中，上述故障为上述被探测设备的操作系统无法感知的故障；上述故障通知设备包括主板和网卡；上述在上述被探测设备检测到自身出现故障的情况下，上述被探测设备向上述探测设备发送广播报文，包括：

上述被探测设备通过上述主板检测到上述被探测设备出现上述故障；上述被探测设备通过上述主板向上述网卡发送通知信号；上述通知信号为上述主板根据上述故障生成；上述被探测设备通过上述网卡根据上述通知信号向上述探测设备发送上述广播报文。

在一种可能的实施方式中，上述广播报文注册在上述网卡的网卡驱动中。

在一种可能的实施方式中，上述故障为上述被探测设备的操作系统能够感知的故障；上述在上述被探测设备检测到自身出现故障的情况下，上述被探测设备向上述探测设备发送广播报文，包括：

上述被探测设备通过上述操作系统检测到上述被探测设备出现上述故障；

上述被探测设备通过上述操作系统的内核通知链向上述探测设备发送上述广播报文。

在一种可能的实施方式中，上述内核通知链包括的回调函数中注册了上述广播报文；或者，上述内核通知链包括的回调函数用于生成上述广播报文。

在一种可能的实施方式中，上述广播报文包括上述被探测设备在上述分布式集群中的唯一标识；其中，上述唯一标识为上述被探测设备最近一次加入上述分布式集群时重新生成的标识。

在一种可能的实施方式中，上述不可靠传输协议为用户数据报协议UDP；上述被探测设备向上述探测设备发送的上述广播报文包括多个上述广播报文。

第四方面，本申请公开了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行以实现上述第一方面任意一项所述的方法。

第五方面，本申请提供一种计算机程序产品，当该计算机程序产品中的计算机程序被计算机读取并执行时，上述第一方面任意一项所述的方法将被执行。

综上所述，本申请中被探测设备主动检测自身的故障，一旦发现故障立即向探测设备发送故障通知，相比于现有技术，本申请可以使得探测设备快速感知到存在的故障并对故障做出响应，从而避免因探测设备感知故障时间过长导致的业务时延大甚至中断的问题。

附图说明

下面将对本申请实施例中所需要使用的附图作介绍。

图1为本申请实施例提供的故障通知方法适用的系统架构示意图；

图2为本申请实施例提供的一种故障通知方法的流程示意图；

图3为本申请实施例提供的通过通知链实现故障通知的流程示意图；

图4为本申请实施例提供的通过网卡实现故障通知的流程示意图；

图5为本申请实施例提供的一种故障通知设备的逻辑结构示意图；

图6为本申请实施例提供的一种故障通知设备的硬件结构示意图。

具体实施方式

下面结合附图对本申请实施例中的技术方案进行描述。

为了更好的理解本申请实施例提供的一种故障通知方法，下面先对本申请实施例适用的场景进行示例性地描述。参阅图1，图1是本申请实施例提供的故障通知方法适用的系统构架示意图。如图1所示，系统构架可以包括一个或多个探测设备101和一个或多个被探测设备102。探测设备101和被探测设备102可以是属于同一个分布式集群中的设备。

探测设备101可以用于探测被探测设备102是否出现故障，以保证在被探测设备102出现故障的情况下及时响应，从而减少对业务处理的影响。在本申请实施例中，当被探测设备102出现故障时，该被探测设备102可以主动将出现的故障事件通知给探测设备101，从而极大减少了探测设备101感知到该故障的时间，进而避免了故障探测时间过长导致的业务时延大甚至中断的问题。

每一个探测设备101可以用于探测一个或多个被探测设备102是否出现故障，每一个被探测设备102也可以被一个或多个探测设备探测是否出现故障，具体的探测设备和被探测设备根据实际情况确定，本方案对此不做限制。

可选的，探测设备101可以是分布式集群中用于分发业务处理任务给被探测设备102的设备，被探测设备102可以是分布式集群中用于执行任务的设备。探测设备101需要知道被探测设备102是否出现故障，以保证在被探测设备102出现故障的情况下可以将由该被探测设备102执行的任务分配给其它正常的被探测设备102执行，从而保证任务的正常执行。

可选的，探测设备101和被探测设备102分别是分布式集群中用于分发业务处理任务的从设备和主设备。从设备需要知道主设备是否出现故障，以保证在主设备出现故障的情况下可以将由该主设备执行的任务切换到该从设备来执行，从而保证任务的正常执行。

可选的，同一个设备既可以是探测设备也可以是被探测设备。例如，从上述两个可选的实施例中可以看到，分布式集群中用于分发业务处理任务的主设备既可以作为探测设备用于探测该分布式集群中用于执行任务的设备是否出现故障，又可以是被探测设备被其从设备监控探测是否出现故障。

需要说明的是，本申请实施例提供的故障通知方法适用的系统构架不限于图1所示架构，分布式系统中的集群架构都属于本申请实施例提供的故障通知方法适用的系统构架，此处不再赘述。

下面提供一种故障通知方法，该方法可以适用于上述图1所示的系统架构。参见图2，该方法包括但不限于如下步骤：

步骤201、被探测设备检测到自身出现故障。

在具体实施例中，本申请实施例涉及的故障包括两类，第一类是被探测设备的操作系统(operating system，OS)可以感知的故障，第二类是OS无法感知的故障即OS无法正常工作。

需要说明的是，本申请实施例所涉及的故障包括被探测设备无法正常执行业务处理任务的情况。

那么，第一类故障可以包括重启(reboot)、关机(shutdown)和初始化(init)等主动复位的情况以及包括内存溢出(oom)、急关断(emerge)、看门狗(watchdog)和不可预知的事情(panic)等发起的操作系统被动复位的情况。第一类故障还可以包括用杀死Kill命令结束进程和进程Crash等引起的进程故障。这里的进程Crash是指在正常设备系统运行过程中，因某种原因宕机，或者主机或程序停止工作等情况。

第二类故障可以包括被探测设备的OS异常复位或者直接掉电的情况，例如包括系统崩溃(system crash)、掉电、长按关机按钮和智能平台管理接口(intelligent platformmanagement interface，IPMI)强制下电等情况。IPMI是使硬件管理具备“智能化”的新一代通用接口标准。用户可以利用IPMI监视设备的物理特征，如温度、电压、电扇工作状态、电源供应以及机箱入侵等。

在本申请实施例中，针对上述两类故障，上述被探测设备分别采用两种不同的方式检测故障。具体的，对于第一类故障，被探测设备通过自身的操作系统来检测故障。对于第二类故障，被探测设备通过自身的主板来检测故障。

步骤202、该被探测设备向探测设备发送广播报文；其中，该广播报文用于指示该被探测设备出现故障；该广播报文为不可靠传输协议的报文。

在具体实施例中，上述广播报文包括目的端口，该目的端口为预设的端口，探测设备预先配置监听该预设的目的端口。当上述被探测设备将上述广播报文发送到该目的端口时，该探测设备可以接收到该广播报文。

可选的，不同的被探测设备发送的广播报文的目的端口可以不同，这些目的端口可以与被探测设备一一映射，探测设备可以通过接收到广播报文的端口号来确定是哪个被探测设备出现了故障。

可选的，上述广播报文中包括上述被探测设备的唯一标识，该唯一标识可以是在分布式集群中唯一标识该被探测设备的序列号或者标识码等。例如该唯一标识可以是会话标识sessionid等。在具体实施例中，探测设备接收到该广播报文后，可以根据该广播报文中的唯一标识确定是哪个被探测设备出现了故障。

此外，上述广播报文中包括被探测设备的唯一标识可以使得探测设备再次接收到相同的广播报文时，可以根据该唯一标识获知接收的为重复的报文，可以直接丢弃，从而节省了重复处理的计算资源。

需要说明的是，如果被探测设备恢复正常，可以正常处理业务后，该被探测设备会重新生成自身在分布式集群中的唯一标识，并将该重新生成的唯一标识告知该分布式集群中的其他设备。因此，故障时发送的广播报文中包括的唯一标识为该被探测设备最近一次加入分布式集群时重新生成的标识。当探测设备接收到该被探测设备发送的广播报文时，如果该广播报文中的唯一标识不是该被探测设备新生成的唯一标识，那么可以直接丢弃，从而避免了误判故障的问题。

为了便于理解，举例说明：

例一、如果该探测设备是分布式集群中用于分配业务处理任务的设备，那么，该探测设备接收到该广播报文之后，获知该被探测设备无法正常执行业务处理任务。为了不影响业务的正常处理，该探测设备可以将该故障的被探测设备踢出该集群，即该探测设备不会再将业务处理任务分配给该被探测设备进行处理，会找其它可用的设备来处理相应地业务。直到该被探测设备恢复正常，并申请重新加入集群，此时该被探测设备会重新生成在该集群中的唯一标识号。

例二、如果该探测设备是分布式集群中分发业务处理任务的从设备，该被探测设备是分布式集群中分发业务处理任务的主设备，那么，该探测设备接收到该故障通知消息之后，获知该被探测设备无法正常执行业务处理任务的分发工作，为了不影响业务的正常处理，该探测设备会接管业务处理任务的分发工作。并可以将该故障的被探测设备踢出该集群，直到该被探测设备恢复正常，并申请重新加入集群，此时该被探测设备会重新生成在该集群中的唯一标识号。

上述采用不可靠传输协议来实现被探测设备对探测设备的主动故障通知，能够保证被探测设备出现故障的情况下，也可以向探测设备发送故障通知即上述广播报文，从而实现了探测设备对被探测设备的故障快速感知。

可选的，上述不可靠传输协议可以是用户数据报协议(user datagram protocol，UDP)，即上述广播报文为UDP广播报文。利用UDP无连接协议特性，即使在设备掉电，操作系统宕机或主机、程序停止工作等情况下也能及时完成故障通知。此外，采用UDP广播报文可以在集群主故障或多点故障的情况下都能够实现故障通知。

可选的，上述被探测设备可以连续发送多次上述广播报文给探测设备以保证探测和设备成功接收到该报文。例如，假设该广播报文为UDP广播报文，由于UDP的特性是尽最大努力交付，不保证可靠交付，因此可以多发几次广播报文以解决UDP丢包导致报文丢失的问题。

在具体实施例中，针对上述两类故障，被探测设备分别采用两种不同的方式向探测设备发送广播报文。具体的，对于第一类故障，被探测设备通过该设备操作系统的内核通知链向探测设备发送广播报文。对于第二类故障，被探测设备通过所述网卡向探测设备发送广播报文。

下面通过两个实施例来分别介绍上述被探测设备出现上述两类故障时实现故障主动通知的具体过程。

实施例一、被探测设备出现上述第一类故障时实现对探测设备的主动故障通知。

对于该第一类故障，被探测设备的OS内核中注册了故障的通知链，可选的，可以在该探测设备的业务启动时注册该通知链。

具体的，该通知链可以包括回调函数，当上述被探测设备的操作系统感知到故障的发生时，会调用该回调函数向探测设备发送上述广播报文。

可选的，该回调函数注册了上述广播报文，那么在该回调函数被调用时可以直接将该预先注册的广播报文发送给探测设备。

可选的，该回调函数可以用于生成上述广播报文，即该回调函数中只注册了上述广播报文中包括的信息例如被探测设备的唯一标识和目的端口号等。当该回调函数被调用时，需要先根据预先注册的信息生成该广播报文，再将生成的广播报文发送给探测设备。

为了便于理解实施例一，可以参见图3。图3中包括被探测设备的用户空间和操作系统空间，当用户空间的业务启动时，操作系统的内核中注册了故障的通知链，当操作系统感知到第一类故障出现时，调用该通知链实现故障的主动通知。具体的实现过程参见上述实施例一的描述，此处不再赘述。

实施例二、被探测设备出现上述第二类故障时实现对探测设备的主动故障通知。

在具体实施例中，由于出现上述第二类故障时，被探测设备的操作系统已经停止工作，无法感知，但是被探测设备的主板可以感知该第二类故障。此外，由于被探测设备的操作系统停止工作，因此也无法通过正常的通信方式通知探测设备该被探测设备出现了故障。

基于此，在本申请实施例中，可以通过被探测设备的网卡向探测设备发送故障通知即上述广播报文。具体的，被探测设备网卡的网卡驱动中注册了上述广播报文，并且在该网卡驱动中添加了当该被探测设备出现该第二类故障时，向探测设备发送该广播报文的处理逻辑即计算机程序。

在出现第二类故障的情况下，被探测设备可通过主板检测到该故障。然后，该主板根据该故障生成一个通知信号，并将该通知信号发送给给被探测设备的网卡，触发该网卡执行上述处理逻辑。即该网卡根据该通知信号将预先在网卡驱动中注册的广播报文发送给探测设备。

可选的，上述通知信号可以是硬件信号，例如可以是AC_LOST信号等。该通知信号也可以是其它自定义的信号，具体采用哪种信号，本方案对此不做限制。

为了便于理解实施例二，可以参见图4。图4中包括被探测设备的主板和网卡，当被探测设备的业务启动时，网卡的网卡驱动中注册了广播报文和相应的计算程序，当主板感知到第二类故障出现时，向网卡发出通知，触发网卡向探测设备发送该广播报文实现故障的主动通知。具体的实现过程参见上述实施例二的描述，此处不再赘述。

可选的，上述广播报文中可以包括具体故障的原因，例如是掉电故障还是重启故障等等。

可选的，不管是什么故障，出现故障后向探测设备发送的广播报文可以相同也可以不同，主要目的是告知探测设备某个被探测设备出现了故障，无法处理业务即可。

可选的，当出现第一类故障后引发第二类故障时，被探测设备可以先采用上述实施例一的方式向探测设备发送广播报文，然后由第一类故障引发的第二类故障触发被探测设备采用上述实施例二的方式向探测设备发送广播报文。这两次发送的广播报文可以相同也可以不相同，但都指示该被探测设备出现了故障，无法正常工作。为了便于理解，下面举例说明。

例三、假设被探测设备首先出现了需要关机的情况，那么操作系统在执行关机流程的时候会调用通知链的回调函数实现广播报文的发送。然后，被探测设备关机，关机之后操作系统无法工作，此时主板感知到这个情况，会触发网卡向探测设备发送广播报文。

可选的，当出现第一类故障后引发第二类故障时，在被探测设备已经采用上述实施例一的方式向探测设备发送广播报文后，可以不再采用上述实施例二的方式向探测设备发送广播报文。即对于由第一类故障引发的第二类故障，主板感知到该第二类故障后不再触发网卡向探测设备发送广播报文。

综上所述，本申请中被探测设备主动检测自身的故障，一旦发现故障立即向探测设备发送故障通知。现有技术中采用心跳探测类探测技术探测设备是否出现故障，整个过程需要10秒甚至几十秒，在这个过程中容易导致业务时延大甚至中断的问题。而本申请实施例能够将探测设备对被探测设备的故障的感知时间缩短至毫秒级别，从而避免因探测设备感知故障时间过长导致的业务时延大甚至中断的问题。此外，由于故障的感知时间缩短至毫秒级别，还可以避免因为网络时延/乱序等问题导致的被探测设备被误踢出集群的问题。

上述主要从探测设备和被探测设备之间的交互对故障通知方法进行了介绍。可以理解的是，各个设备为了实现上述对应的功能，其包括了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对探测设备和被探测设备等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图5示出了本申请实施例提供的一种故障通知设备的逻辑结构示意图，该故障通知设备可以是上述方法实施例中的被探测设备。该故障通知设备500可以包括：

第一发送单元501，用于在故障通知设备500检测到自身出现故障的情况下，向上述探测设备发送广播报文；其中，上述广播报文用于指示故障通知设备500出现故障；该广播报文为不可靠传输协议的报文。

在一种可能的实施方式中，上述故障为故障通知设备500的操作系统无法感知的故障；故障通知设备500包括主板和网卡；故障通知设备500还包括第一检测单元和第二发送单元；

上述第一检测单元，用于通过上述主板检测到故障通知设备500出现上述故障；

上述第二发送单元，用于通过上述主板向上述网卡发送通知信号；上述通知信号为上述主板根据上述故障生成；

上述第一发送单元，具体用于通过上述网卡根据上述通知信号向上述探测设备发送上述广播报文。

在一种可能的实施方式中，上述广播报文注册在上述网卡的网卡驱动中。

在一种可能的实施方式中，上述故障为故障通知设备500的操作系统能够感知的故障；故障通知设备500还包括第二检测单元；

上述第二检测单元，用于通过上述操作系统检测到故障通知设备500出现上述故障；

上述第一发送单元，具体用于通过上述操作系统的内核通知链向上述探测设备发送上述广播报文。

在一种可能的实施方式中，上述内核通知链包括的回调函数中注册了上述广播报文；或者，上述内核通知链包括的回调函数用于生成上述广播报文。

在一种可能的实施方式中，上述广播报文包括故障通知设备500在上述分布式集群中的唯一标识；其中，上述唯一标识为故障通知设备500最近一次加入上述分布式集群时重新生成的标识。

在一种可能的实施方式中，上述不可靠传输协议为用户数据报协议；上述被探测设备向上述探测设备发送的上述广播报文包括多个上述广播报文。

图6所示，为本申请实施例提供的一种故障通知设备的可能的硬件结构示意图。故障通知设备600包括：处理器601、存储器602和通信接口603。处理器601、通信接口603以及存储器602可以相互连接或者通过总线604相互连接。

示例性的，存储器602用于存储第一车辆600的计算机程序和数据，存储器602可以包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-onlymemory，ROM)、可擦除可编程只读存储器(erasable programmable read only memory，EPROM)或便携式只读存储器(compact disc read-only memory，CD-ROM)等。通信接口603用于支持设备600进行通信，例如接收或发送数据。

示例性的，处理器601可以是中央处理器单元、通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理器和微处理器的组合等等。处理器601可以用于读取上述存储器602中存储的程序，执行上述图2以及可能的实施方式所述方法中被探测设备所做的操作。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行以实现上述图2以及可能的实施方式所述方法中被探测设备所做的操作。

本申请实施例还提供一种计算机程序产品，当该计算机程序产品中的计算机程序被计算机读取并执行时，上述图2以及可能的实施方式所述的方法将被执行。

综上所述，本申请中被探测设备主动检测自身的故障，一旦发现故障立即向探测设备发送故障通知，相比于现有技术，本申请可以使得探测设备快速感知到存在的故障并对故障做出响应，从而避免因探测设备感知故障时间过长导致的业务时延大甚至中断的问题。

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

Claims (16)

1.一种故障通知方法，其特征在于，所述方法应用于分布式集群中的设备，所述设备包括探测设备和被探测设备；所述方法包括：

在所述被探测设备检测到自身出现故障的情况下，所述被探测设备向所述探测设备发送广播报文；其中，所述广播报文用于指示所述被探测设备出现故障；所述广播报文为不可靠传输协议的报文。

2.根据权利要求1所述的方法，其特征在于，所述故障为所述被探测设备的操作系统无法感知的故障；所述被探测设备包括主板和网卡；

所述在所述被探测设备检测到自身出现故障的情况下，所述被探测设备向所述探测设备发送广播报文，包括：

所述被探测设备通过所述主板检测到所述被探测设备出现所述故障；

所述被探测设备通过所述主板向所述网卡发送通知信号；所述通知信号为所述主板根据所述故障生成；

所述被探测设备通过所述网卡根据所述通知信号向所述探测设备发送所述广播报文。

3.根据权利要求2所述的方法，其特征在于，所述广播报文注册在所述网卡的网卡驱动中。

4.根据权利要求1所述的方法，其特征在于，所述故障为所述被探测设备的操作系统能够感知的故障；

所述在所述被探测设备检测到自身出现故障的情况下，所述被探测设备向所述探测设备发送广播报文，包括：

所述被探测设备通过所述操作系统检测到所述被探测设备出现所述故障；

所述被探测设备通过所述操作系统的内核通知链向所述探测设备发送所述广播报文。

5.根据权利要求4所述的方法，其特征在于，所述内核通知链包括的回调函数中注册了所述广播报文；或者，所述内核通知链包括的回调函数用于生成所述广播报文。

6.根据权利要求1至5任一项所述的方法，其特征在于，所述广播报文包括所述被探测设备在所述分布式集群中的唯一标识；其中，所述唯一标识为所述被探测设备最近一次加入所述分布式集群时重新生成的标识。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述不可靠传输协议为用户数据报协议UDP；所述被探测设备向所述探测设备发送的所述广播报文包括多个所述广播报文。

8.一种故障通知设备，其特征在于，所述故障通知设备属于分布式集群中的被探测设备，所述分布式集群还包括探测设备；所述故障通知设备包括：

第一发送单元，用于在所述故障通知设备检测到自身出现故障的情况下，向所述探测设备发送广播报文；其中，所述广播报文用于指示所述故障通知设备出现故障；所述广播报文为不可靠传输协议的报文。

9.根据权利要求8所述的故障通知设备，其特征在于，所述故障为所述故障通知设备的操作系统无法感知的故障；所述故障通知设备包括主板和网卡；所述故障通知设备还包括第一检测单元和第二发送单元；

所述第一检测单元，用于通过所述主板检测到所述故障通知设备出现所述故障；

所述第二发送单元，用于通过所述主板向所述网卡发送通知信号；所述通知信号为所述主板根据所述故障生成；

所述第一发送单元，具体用于通过所述网卡根据所述通知信号向所述探测设备发送所述广播报文。

10.根据权利要求9所述的故障通知设备，其特征在于，所述广播报文注册在所述网卡的网卡驱动中。

11.根据权利要求8所述的故障通知设备，其特征在于，所述故障为所述故障通知设备的操作系统能够感知的故障；所述故障通知设备还包括第二检测单元；

所述第二检测单元，用于通过所述操作系统检测到所述故障通知设备出现所述故障；

所述第一发送单元，具体用于通过所述操作系统的内核通知链向所述探测设备发送所述广播报文。

12.根据权利要求11所述的故障通知设备，其特征在于，所述内核通知链包括的回调函数中注册了所述广播报文；或者，所述内核通知链包括的回调函数用于生成所述广播报文。

13.根据权利要求8至12任一项所述的故障通知设备，其特征在于，所述广播报文包括所述故障通知设备在所述分布式集群中的唯一标识；其中，所述唯一标识为所述故障通知设备最近一次加入所述分布式集群时重新生成的标识。

14.根据权利要求8至13任一项所述的故障通知设备，其特征在于，所述不可靠传输协议为用户数据报协议UDP；所述被探测设备向所述探测设备发送的所述广播报文包括多个所述广播报文。

15.一种故障通知设备，其特征在于，所述故障通知设备包括处理器、存储器以及通信接口；所述存储器、所述通信接口与所述处理器耦合，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时，所述故障通知设备执行如权利要求1至7任一项所述的方法。

16.一种计算机程序产品，其特征在于，所述计算机程序产品存储有计算机程序，所述计算机程序被处理器执行以实现权利要求1至7任意一项所述的方法。

Images