CN103716182A - 一种面向实时云平台的故障检测与容错方法及系统 - Google Patents

Abstract

本发明涉及一种面向实时云平台的故障检测与容错方法及系统，包括发送命令，提交任务，并将分配给工作节点的任务存储在相应路径下的客户端；用于监控各工作节点的运行状态，根据工作节点上传的心跳信息进行节点级故障检测与容错，执行故障节点中任务的迁移的全局状态监控模块；用于存储全局状态监控模块和各个工作节点的工作状态及心跳信息的全局状态存储模块；用于执行任务，运行守护进程来守护工作进程，并执行程序级故障检测与容错的工作节点；本发明中使整个集群的状态信息全部存储在Zookeeper系统中，实现节点的无状态架构，节点故障不会造成状态丢失，具有完善的故障检测与容错机制，实现多级容错，保障实时业务的不间断运行。

Description

一种面向实时云平台的故障检测与容错方法及系统

技术领域

本发明涉及实时云计算领域，尤其涉及一种面向实时云平台的故障检测与容错方法及系统。

背景技术

随着云计算、物联网等技术的兴起，数据正以前所未有的速度不断地增长和积累，并且越来越多地以大规模、连续的流的形式出现在应用程序中，其中最典型的应用就是监控应用，例如金融市场监控、网络监控、移动对象监控、入侵检查和生态系统监控等，实时应用对故障检测恢复及容错有着更高的需求。

为此工业界和学术界开发了很多数据流处理系统，包括斯坦福大学的STREAM、施乐公司的Tapestry、加州大学伯克利分校的Telegraph、布朗大学和麻省理工学院合作的Aurora，Apache的Hadoop Online以及Yahoo的S4。

低延迟数据流处理的新需求，给程序级及节点级的故障检测与恢复带来了新的挑战，目前主流云平台存在以下一些问题：

1、无法完全克服节点故障时的状态丢失，通常在节点上保存着状态信息，以及配置信息，业务程序文件等，一旦节点发生故障，将丢失状态信息。

2、无法完全消除主节点依赖。如twitter storm，虽然主节点故障时，工作节点依然可以运行，但大部分功能将会失效，如提交任务、故障检测等。

3、缺少一套全面、整体的故障检测与容错机制，使得程序级与节点级故障都能够及时检测与修复。

因此，我们需要一种面向实时云平台的多级故障检测与容错机制，以保障实时云平台的高可用性。

发明内容

本发明所要解决的技术问题是提供一种面向实时云平台的故障检测与容错方法及系统，实现所有节点无状态，能够及时准确的检测平台程序级与节点级故障，并采用相应策略进行故障恢复。

本发明解决上述技术问题的技术方案如下：一种面向实时云平台的故障检测与容错方法包括如下步骤：

步骤1：客户端向全局状态存储模块发送待处理的任务，并将将分配给各个工作节点的任务存储到全局状态存储模块的相应路径下；

步骤2：所述各工作节点每隔心跳时间到全局状态存储模块相应路径下，检测是否有待执行的任务，一旦发现新任务，便启动工作进程运行相应任务；

步骤3：所述每个工作节点内运行一个守护进程来守护在执行任务的工作进程，并执行程序级故障检测与容错；

步骤4：全局状态监控模块每隔心跳时间到全局状态存储模块中检查每个工作节点上传的心跳信息，并根据心跳信息进行节点级故障检测与容错。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步，所述全局状态监控模块和各个工作节点本地不保存状态信息，所有状态信息都保存全局状态存储模块中；所述全局状态监控模块与各工作节点间的通信，各工作节点间的通信，以及各工作节点的本地动作都是依靠全局状态存储模块中的全局状态来进行的。

进一步，步骤3中所述执行程序级故障检测与容错的具体实现为：

步骤3.1：守护进程每隔心跳时间检查在执行任务的工作进程的运行状态；

步骤3.2：检查是否有意外崩溃的工作进程，如果有则立即重新启动该工作进程，恢复其工作状态。

进一步，步骤4中所述执行节点级故障检测与容错的具体实现为：

步骤4.1：当检测到某节点上传心跳信息超时，进一步检测是网络故障还是该节点故障，

步骤4.2：判断同一时段内上传心跳信息超时的节点个数是否大于预设阈值，如果大于则认为是网络故障，节点内任务不迁移；如果小于则是该节点单独故障，将该节点内的任务迁移到其他空闲节点中运行。

进一步，步骤4.2中将故障节点中任务迁移到其他空闲节点继续运行的具体步骤为：

步骤4.2.1：通过节点选举算法给故障节点选一个空闲节点，如果找到空闲节点，执行步骤4.2.2；否则执行步骤4.2.5；

步骤4.2.2：更新上游相关节点和该故障节点存储于全局状态存储模块中的目的地址表，将目的地址更新为所选的空闲节点；

步骤4.2.3：将更新的目的地址表发送给上游相关节点，上游相关节点根据新目的地址向所选空闲节点发送数据；

步骤4.2.4：所选空闲节点向全局状态存储模块发送心跳信息时发现有需要执行的任务，所述空闲节点接收上游相关节点发送的数据，并启动工作进程执行该任务，结束；

步骤4.2.5：更新上游相关节点存储于全局状态存储模块中的目的地址表，将目的地址置为空；

步骤4.2.6：将更新的目的地址表发送给上游相关节点，上游相关节点检测到新目的地址为空，则停止向下游发送数据。

进一步，所述全局状态监控模块包括若干个主节点，并采用Zookeeper互斥锁实现多机热备，当正在工作的主节点出错后，自动释放互斥锁及对整个集群各个工作节点工作状态的监控，由竞争到互斥锁的主节点接管任务。

本发明解决上述技术问题的技术方案如下：一种面向实时云平台的故障检测与容错系统，包括客户端、全局状态监控模块、全局状态存储模块和若干个工作节点；

所述客户端，其用于向全局状态存储模块发送命令，提交任务，为各工作节点分配任务，并将分配给各个工作节点的任务存储到全局状态存储模块的相应路径下；

所述全局状态监控模块，其用于监控各工作节点的运行状态，根据工作节点上传的心跳信息进行节点级故障检测与容错；

所述全局状态存储模块，其用于将客户端分配给工作节点的任务存储在相应路径下，还用于存储全局状态监控模块和各个工作节点的工作状态及心跳信息；

所述工作节点，其用于每隔心跳时间到全局状态存储模块相应路径下，检测是否有待执行的任务，一旦发现新任务，便启动其内的工作进程运行相应任务；且每个工作节点内运行一个守护进程来守护在执行任务的工作进程，并执行程序级故障检测与容错。

在上述技术方案的基础上，本发明还可以做如下改进。

进一步，所述全局状态监控模块包括若干个主节点，并采用Zookeeper互斥锁实现多机热备，当正在工作的主节点出错后，自动释放互斥锁及对整个集群各个工作节点工作状态的监控，由竞争到互斥锁的主节点接管任务。

进一步，所述全局状态存储模块包括若干个Zookeeper节点，每个Zookeeper节点上运行一个守护进程，当守护进程检测到Zookeeper节点上的Zookeeper进程错误退出后，立即重新启动。

进一步，所述每个工作节点中还运行的守护进程为supervisor，其每隔心跳时间检查工作进程的运行状态，一旦发现工作进程意外崩溃，便重启该工作进程，恢复其原有工作状态。

本发明的有益效果是：

1.节点的无状态架构

整个集群的状态信息全部存储在可靠的Zookeeper系统中，节点本地没有状态存储，各节点间没有控制消息通信，节点间无相互依赖，节点故障不会造成状态丢失，节点故障也不会影响其他节点，节点由于无状态，故障替换时无需做IP欺骗；

2.完善的故障检测与容错机制

无论业务程序、平台程序或者物理节点的故障，都能及时通过心跳信息反映到Zookeeper系统中，并被平台发现；通过Supervisor->Worker->Task多级容错，保障实时业务的不间断运行；通过Master多机热备，实现主节点的容错；

3.摆脱对物理节点的依赖

当工作节点故障时，工作节点中的任务可自动迁移到其他空闲节点中；当主节点故障时，热备主节点自动接管Master工作；Zookeeper系统中只要有半数节点工作，系统就可正常运行。

附图说明

图1为本发明所述一种面向实时云平台的故障检测与容错系统框图；

图2为本发明所述一种面向实时云平台的故障检测与容错方法流程图；

图3为本发明所述步骤3的具体实现流程图；

图4为本发明所述步骤4的具体实现流程图；

图5为本发明所述步骤4.2的具体实现流程图；

图6为本发明所述全局状态存储模块（Zookeeper系统）中状态存储路径示意图；

图7为工作节点中的工作进程Worker的状态转移示意图；

图8为程序级和节点级故障检测与容错机制示意图。

附图中，各标号所代表的部件列表如下：

1、客户端，2、全局状态监控模块，3、全局状态存储模块，4、工作节点。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实例只用于解释本发明，并非用于限定本发明的范围。

本发明可以应用在诸如实时云平台、流计算平台等分布式结构的平台中，用于完成实时云平台的故障检测与容错功能。

如图1所示，一种面向实时云平台的故障检测与容错系统，包括客户端1、全局状态监控模块2、全局状态存储模块3和若干个工作节点4；

所述客户端1，其用于向全局状态存储模块2发送命令，提交任务，为各工作节点分配任务，并将分配给各个工作节点的任务存储到全局状态存储模块3；

所述全局状态监控模块2，用于监控各工作节点4的运行状态，根据工作节点上传的心跳信息进行节点级故障检测与容错；

所述全局状态存储模块3，其用于将客户端1分配给工作节点的任务存储在相应路径下，还用于存储全局状态监控模块2和各个工作节点4的工作状态及心跳信息；

所述工作节点4，其用于每隔心跳时间到全局状态存储模块3相应路径下，检测是否有待执行的任务，一旦发现新任务，便启动其内的工作进程运行相应任务；且每个工作节点内运行一个守护进程来守护在执行任务的工作进程，并执行程序级故障检测与容错。

本实施例中使用一台服务器作为Client客户端，负责向集群发布命令、提交Job及可执行程序等；并使用千兆网卡与交换机提供集群网络通信；使用两台服务器作为Master节点，一台监控整个集群工作状态，提供故障恢复与任务迁移功能，另一台作为热备使用；使用三台服务器作为Zookeeper节点，负责全局状态存储并负责与其他模块通信；使用五台服务器作为工作节点；每个工作节点上运行一个Supervisor进程，负责监控及控制Worker进程工作。

其中，所述全局状态监控模块2和各个工作节点4本地不保存状态信息，所有状态信息都保存全局状态存储模块3中；所述全局状态监控模块2与各工作节点4间的通信，各工作节点4间的通信，以及各工作节点4的本地动作都是依靠全局状态存储模块3中的全局状态来进行的。因此，任何节点故障都不会造成全局状态丢失。全局状态存储模块3（Zookeeper系统）中的状态是全局一致的，所以不会由于消息的丢失造成节点的不一致。

所述全局状态监控模块2包括若干个主节点，每个主节点上运行一个Master进程来对全局状态存储模块3进行监控，并采用Zookeeper互斥锁实现多机热备，同时启动多个Master程序，只有一个能获得互斥锁，当正在工作的主节点出错后，自动释放互斥锁及对整个集群各个工作节点工作状态的监控，由竞争到互斥锁的主节点接管任务。

所述全局状态存储模块3包括若干个Zookeeper节点，每个Zookeeper节点上运行一个守护进程，当守护进程检测到Zookeeper节点上的Zookeeper进程错误退出后，立即重新启动。

由于各个节点和各个任务都有状态需要存储，且彼此需要交互，为了保证存储信息的可靠性，因此采用Zookeeper系统作为存储系统，且各节点间的信息交互都通过Zookeeper系统完成。Zookeeper是一个高可用性的存储系统，以Fast Paxos算法为基础改进而来，在分布式环境中确保文件写入的一致性问题，并且能够保证只要Zookeeper系统中有半数以上节点工作正常，整个Zookeeper系统就能够正常工作；此外，Zookeeper系统采用Fail-fast策略，即遇到错误即退出，因此，在每台Zookeeper节点上运行一个守护进程，当此节点上的Zookeeper进程错误退出后，立即重新启动，实现双重保护。因此，采用Zookeeper系统作为状态存储系统可用性很高。

所述每个工作节点4中还运行的守护进程为supervisor，其每隔心跳时间检查执行任务的工作进程Worker的运行状态，一旦发现有工作进程Worker意外崩溃，便重启该工作进程，恢复其原有工作状态。

如图2所示，一种面向实时云平台的故障检测与容错方法包括如下步骤：

步骤1：客户端向全局状态存储块发送待处理的任务，并将分配给各个工作节点的任务存储到全局状态存储模块的相应路径下；

步骤2：所述各工作节点每隔心跳时间到全局状态存储模块相应路径下，检测是否有待执行的任务，一旦发现新任务，便启动工作进程运行相应任务；

步骤3：所述每个工作节点内运行一个守护进程来守护在执行任务的工作进程，并执行程序级故障检测与容错；

步骤4：全局状态监控模块每隔心跳时间到全局状态存储模块中检查每个工作节点上传的心跳信息，并根据心跳信息进行节点级故障检测与容错。

如图3所示，步骤3中所述执行程序级故障检测与容错的具体实现为：

步骤3.1：守护进程每隔心跳时间检查在执行任务的工作进程的运行状态；

步骤3.2：检查是否有意外崩溃的工作进程，如果有则立即重新启动该工作进程，恢复其工作状态。

如图4所示，步骤4中所述执行节点级故障检测与容错的具体实现为：

步骤4.1：当检测到某节点上传心跳信息超时，进一步检测是网络故障还是该节点故障，

步骤4.2：判断同一时段内上传心跳信息超时的节点个数是否大于预设阈值，如果大于则认为是网络故障，节点内任务不迁移；如果小于则认为是该节点单独故障，将该节点内的任务迁移到其他空闲节点中运行。

如图5所示，步骤4.2中将故障节点中任务迁移到其他空闲节点继续运行的具体步骤为：

步骤4.2.1：通过节点选举算法给故障节点选一个空闲节点，如果找到空闲节点，执行步骤4.2.2；否则执行步骤4.2.5；

步骤4.2.2：更新上游相关节点和该故障节点存储于全局状态存储模块中的目的地址表，将目的地址更新为所选的空闲节点；

步骤4.2.3：将更新的目的地址表发送给上游相关节点，上游相关节点根据新目的地址向所选空闲节点发送数据；

步骤4.2.4：所选空闲节点向全局状态存储模块发送心跳信息时发现有需要执行的任务，所述空闲节点接收上游相关节点发送的数据，并启动工作进程执行该任务，结束；

步骤4.2.5：更新上游相关节点存储于全局状态存储模块中的目的地址表，将目的地址置为空；

步骤4.2.6：将更新的目的地址表发送给上游相关节点，上游相关节点检测到新目的地址为空，则停止向下游发送数据。

本发明可实现程序级和节点级故障检测与容错

1.程序级故障检测与容错机制

业务程序为用户提供的独立的可执行程序或动态库；Worker为工作进程，每个Worker每隔心跳时间便检查Zookeeper系统中相应Znode信息，一旦发现有新任务，便启动进程运行业务程序；Supervisor为Worker的守护进程，Supervisor每隔心跳时间便检查Worker的运行状态，一旦发现有Worker意外崩溃，便重启该Worker进程，恢复其原有工作状态。

2.节点级故障检测与容错机制

Master每隔心跳时间便到Zookeeper系统中检查各个工作节点上传的心跳信息是否超时，进一步判断是网络故障还是该节点故障；如果同一时段超时节点个数大于某阈值，则认为整个通信系统瘫痪，节点中任务不做迁移；如果同一时段超时节点数小于阈值，则将故障节点中的所有Worker中的任务迁移到其他空闲节点中继续运行。

图6为Zookeeper系统中状态存储路径，其中节点、Job、Worker、Task、程序、节点心跳、Task心跳、Worker状态及全局标志位，分别存于图中对应的Znode中。

如图7所示，为Worker状态转移示意图，Worker启动后，会定时向Zookeeper系统中相应Znode发送心跳，并检查其在Zookeeper中的状态，以此判断Worker下一步动作。Worker有两种稳定状态和四种中间状态，当Worker处于稳定状态时，表示Worker与相应Znode中的状态已同步，当Worker处于中间状态时，表示Worker与相应Znode中的状态未同步，需要达到某种稳定状态。条纹背景为稳定状态，白色背景为中间状态，直线指示Worker自行状态流动，虚线指示外部命令状态流动：

1.STAT_VOID（waiting）：稳定状态，表示Worker中无Task，且相应Znode中的状态信息也为STAT_VOID；

2.STAT_VOID（running）：中间状态，表示Worker中有Task，且相应Znode中的状态信息为STAT_VOID；

3.STAT_STANDBY（waiting）：中间状态，表示Worker中无Task，且相应Znode中的状态信息为STAT_STANDBY；

4.STAT_STANDBY（running）：中间状态，表示Worker中有Task，且相应Znode中的状态信息为STAT_STANDBY；

5.STAT_LIVE_ING(waiting)：中间状态，表示Worker中无Task，且相应Znode中的状态信息为STAT_LIVE_ING；

6.STAT_LIVE_ING(running)：稳定状态，表示Worker中有Task，且相应Znode中的状态信息为STAT_LIVE_ING；

状态之间的转换称为动作，图中实线为Worker自行状态流动动作，虚线为外部命令状态流动动作，具体为：

1.当Worker处于STAT_VOID（waiting）状态时，如无其他命令动作，则循环保持KEEP_STATUS动作，表示持续该稳定状态；

2.当Worker处于STAT_VOID（waiting）状态时，如有submit_job命令动作，则状态转移到STAT_STANDBY（waiting），表示Znode上有新任务需要执行，但Worker并未开始执行；

3.当Worker处于STAT_STANDBY（waiting）状态时，执行NEW_TASK动作，本地运行handle_local_tasks方法，则状态转移到STAT_LIVE_ING(running)，表示Znode上的新任务Worker开始执行；

4.当Worker处于STAT_LIVE_ING(running)状态时，如无其他动作，则循环保持KEEP_STATUS动作，表示持续该稳定状态；

5.当Worker处于STAT_LIVE_ING(running)状态时，执行外部命令re-submit-job，则状态保持，表示重新提交job信息；

6.当Worker处于STAT_LIVE_ING(running)状态时，执行CODE_CHANGDE动作，本地执行restart_local_tasks方法，则状态保持，表示检测到程序改变，执行新程序；

7.当Worker处于STAT_LIVE_ING(running)状态时，执行外部命令migrate topology，则状态转移到STAT_STANDBY（running），表示正在进行任务迁移；

8.当Worker处于STAT_STANDBY（running）状态时，执行TASK_CHANGED动作，本地执行change_local_tasks方法，则状态转移到STAT_LIVE_ING(running)，表示任务迁移完成；

9.当Worker处于STAT_LIVE_ING(running)状态时，执行外部命令killjob，则状态转移到STAT_VOID（running），表示相应Znode上任务结束，但Worker上还没有结束任务；

10.当Worker处于STAT_VOID（running）状态时，执行TASK_GONE动作，本地执行exit_local_tasks方法，则状态转移到STAT_VOID（waiting），表示Worker上的任务已经结束。

如上，通过Worker的多种状态及相互之间的转换动作，即可完成Worker的相关工作，如启动任务、重启任务、迁移任务、结束任务等。

如图8所示，为程序级和节点级故障检测与容错机制示意图。

1.程序级故障检测与容错实现。

Worker为工作进程，通过Worker状态检测及转移实现故障检测与容错，具体方法如下：

每个Worker每隔心跳时间便检查Zookeeper中相应Znode信息中的Worker状态，路径为/root/nodes/nodeX/status，无变更则执行KEEP_STATUS动作，保持原状态；

一旦接收到submit job命令，则状态由STAT_VOID（waiting）转移到STAT_STANDBY（waiting）；

继续执行NEW_TASK动作，本地运行handle_local_tasks方法，将状态转移到STAT_LIVE_ING(running)，此时进入稳定状态；

Worker在稳定状态中通过心跳，监控是否有新的动作或命令。如，遇到业务程序Task崩溃，则自动执行NEW_TASK动作，本地执行handle_local_tasks方法重启业务程序；或遇到需要迁移业务的情况，执行migrate job命令，将状态转移到STAT_STANDBY（running）；

Supervisor为Worker的守护进程，Supervisor每隔心跳时间便检查其Worker的状态，通过linux ps命令监控Worker进程号，一旦发现Worker意外崩溃，便重启该Worker进程，恢复其原有工作状态。

Master程序采用Zookeeper互斥锁实现多机热备功能，同时启动多个Master程序，只有一个能获得互斥锁，当此Master程序意外出错后，自动释放锁及对集群的状态监控，由竞争到锁的热备Master接管任务。

Zookeeper锁实现方式如下：想获得锁的Master在Znode路径/root/tags/master_lock下创建临时节点，节点名为前缀+编号。竞争锁的时候，检查是否有编号小于自己的锁存在，若存在则对编号刚好小于自己的锁节点进行监听，直到监听的锁被撤销，便可获得锁；撤销锁只需删除临时节点即可。

2.节点级故障检测与容错

Master每隔心跳时间便到Zookeeper中检查各个节点上传的心跳信息（即/root/nodes/nodeX/heartbeat）是否超时，如果存在超时现象，则进一步判断是网络故障还是该节点故障，如果同一时段超时节点个数大于某阈值，则认为整个通信系统瘫痪，节点中的任务不做迁移；如果同一时段超时节点数小于阈值，则将故障节点中的所有Worker中的Task迁移到其他空闲节点中继续运行。

1）上述执行过程的运行结果如下：

1.使用Client客户端配置Job信息，使得五台Supervisor工作节点中每个Worker进程中运行一个Task线程，Task线程中的程序为简单的控制台循环输出“hello world!”；

2.使用linux kill命令结束业务Task线程，控制台不再输出；经过心跳时间后，Worker自动重启Task线程，控制台重新输出“hello world!”；

3.使用linux kill命令结束Worker进程，则Task进程同时结束，控制台不再输出；经过心跳时间后，Supervisor守护进程自动重启Worker进程，Worker启动后自动重启Task线程，控制台重新输出“hello world!”；

4.关闭某节点或使用linux kill命令结束Supervisor进程模仿某节点故障，心跳超时后，认为该节点故障，开始迁移，将故障节点中的Worker中的Task迁移到其他空闲节点中继续运行，通过Worker选举算法给故障Worker找到一个空闲Worker，并将上游Task的目的地址改为新的空闲Worker，将需迁移的Task的地址改为新Worker地址，迁移完成，业务在新节点中继续运行，观察新节点中输出“hello world”；

5.关闭Master所在节点，释放Zookeeper锁，则热备节点获得锁，接管Master工作。

6.关闭Zookeeper某节点，Zookeeper存储系统继续无缝运行。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种面向实时云平台的故障检测与容错方法，其特征在于，包括如下步骤：

步骤1：客户端向全局状态存储模块发送待处理的任务，并将分配给各个工作节点的任务存储到全局状态存储模块的相应路径下；

步骤2：所述各工作节点每隔心跳时间到全局状态存储模块相应路径下，检测是否有待执行的任务，一旦发现新任务，便启动工作进程运行相应任务；

步骤3：所述每个工作节点内运行一个守护进程来守护在执行任务的工作进程，并执行程序级故障检测与容错；

步骤4：全局状态监控模块每隔心跳时间到全局状态存储模块中检查每个工作节点上传的心跳信息，并根据心跳信息进行节点级故障检测与容错。

2.根据权利要求1所述一种面向实时云平台的故障检测与容错方法，其特征在于，所述全局状态监控模块和各个工作节点本地不保存状态信息，所有状态信息都保存全局状态存储模块中；所述全局状态监控模块与各工作节点间的通信，各工作节点间的通信，以及各工作节点的本地动作都是依靠全局状态存储模块中的全局状态来进行的。

3.根据权利要求1所述一种面向实时云平台的故障检测与容错方法，其特征在于，步骤3中所述执行程序级故障检测与容错的具体实现为：

步骤3.1：守护进程每隔心跳时间检查在执行任务的工作进程的运行状态；

步骤3.2：检查是否有意外崩溃的工作进程，如果有则立即重新启动该工作进程，恢复其工作状态。

4.根据权利要求1所述一种面向实时云平台的故障检测与容错方法，其特征在于，步骤4中所述执行节点级故障检测与容错的具体实现为：

步骤4.1：当检测到某节点上传心跳信息超时，进一步检测是网络故障还是该节点故障，

步骤4.2：判断同一时段内上传心跳信息超时的节点个数是否大于预设阈值，如果大于则认为是网络故障，节点内任务不迁移；如果小于则是该节点单独故障，将该节点内的任务迁移到其他空闲节点中运行。

5.根据权利要求4所述一种面向实时云平台的故障检测与容错方法，其特征在于，步骤4.2中将故障节点中任务迁移到其他空闲节点继续运行的具体步骤为：

步骤4.2.1：通过节点选举算法给故障节点选一个空闲节点，如果找到空闲节点，执行步骤4.2.2；否则执行步骤4.2.5；

步骤4.2.2：更新上游相关节点和该故障节点存储于全局状态存储模块中的目的地址表，将目的地址更新为所选的空闲节点；

步骤4.2.3：将更新的目的地址表发送给上游相关节点，上游相关节点根据新目的地址向所选空闲节点发送数据；

步骤4.2.4：所选空闲节点向全局状态存储模块发送心跳信息时发现有需要执行的任务，所述空闲节点接收上游相关节点发送的数据，并启动工作进程执行该任务，结束；

步骤4.2.5：更新上游相关节点存储于全局状态存储模块中的目的地址表，将目的地址置为空；

步骤4.2.6：将更新的目的地址表发送给上游相关节点，上游相关节点检测到新目的地址为空，则停止向下游发送数据。

6.根据权利要求1所述一种面向实时云平台的故障检测与容错方法，其特征在于，所述全局状态监控模块包括若干个主节点，并采用Zookeeper互斥锁实现多机热备，当正在工作的主节点出错后，自动释放互斥锁及对整个集群各个工作节点工作状态的监控，由竞争到互斥锁的主节点接管任务。

7.一种面向实时云平台的故障检测与容错系统，其特征在于，包括客户端、全局状态监控模块、全局状态存储模块和若干个工作节点；

所述客户端，其用于向全局状态存储模块发送命令，提交任务，为各工作节点分配任务，并将分配给各个工作节点的任务存储到全局状态存储模块的相应路径下；

所述全局状态监控模块，用于监控各工作节点的运行状态，根据工作节点上传的心跳信息进行节点级故障检测与容错；

所述全局状态存储模块，其用于将客户端分配给工作节点的任务存储在相应路径下，还用于存储全局状态监控模块和各个工作节点的工作状态及心跳信息；

所述工作节点，其用于每隔心跳时间到全局状态存储模块相应路径下，检测是否有待执行的任务，一旦发现新任务，便启动其内的工作进程运行相应任务；且每个工作节点内运行一个守护进程来守护在执行任务的工作进程，并执行程序级故障检测与容错。

8.根据权利要求7所述一种面向实时云平台的故障检测与容错系统，其特征在于，所述全局状态监控模块包括若干个主节点，并采用Zookeeper互斥锁实现多机热备，当正在工作的主节点出错后，自动释放互斥锁及对整个集群各个工作节点工作状态的监控，由竞争到互斥锁的主节点接管任务。

9.根据权利要求7所述一种面向实时云平台的故障检测与容错系统，其特征在于，所述全局状态存储模块包括若干个Zookeeper节点，每个Zookeeper节点上运行一个守护进程，当守护进程检测到Zookeeper节点上的Zookeeper进程错误退出后，立即重新启动。

10.根据权利要求7所述一种面向实时云平台的故障检测与容错系统，其特征在于，所述每个工作节点中还运行的守护进程为supervisor，其每隔心跳时间检查工作进程的运行状态，一旦发现工作进程意外崩溃，便重启该工作进程，恢复其原有工作状态。

Images