Fault Tolerance —— Storm的故障容错性

 本文讲解了Storm故障容忍性(Fault-Tolerance)的设计细节:当Worker、节点、Nimbus或者Supervisor出现故障时是如何实现故障容忍性,以及Nimbus是否存在单点故障问题。

当一个Worker挂了会怎样?

When a worker dies, the supervisor will restart it. If it continuously fails on startup and is unable to heartbeat to Nimbus, Nimbus will reassign the worker to another machine.

当一个Worker挂了,Supervisor会重启它。如果这个Worker连续在启动时失败,并且无法让Nimbus观察到它的心跳,Nimbus将这个Worker重新分配到另一台机器上。

当一个节点挂了会怎样?

The tasks assigned to that machine will time-out and Nimbus will reassign those tasks to other machines.

分配给这台机器的任务将会超时,并且Nimbus将这些任务重新分配给其它机器。

当Nimbus或者Supervisor daemon进程挂了会怎样?

The Nimbus and Supervisor daemons are designed to be fail-fast (process self-destructs whenever any unexpected situation is encountered) and stateless (all state is kept in Zookeeper or on disk). As described in Setting up a Storm cluster, the Nimbus and Supervisor daemons must be run under supervision using a tool like daemontools or monit. So if the Nimbus or Supervisor daemons die, they restart like nothing happened.

Nimbus和Supervisor daemon进程设计成快速失败(无论何时当遇到任何异常情况,将会执行自毁)和无状态(所有的状态都保存在Zookeeper或者磁盘上)。正如Setting up a Storm cluster中描述的,Nimbus和Supervior daemon进程必须在监控下运行,如使用daemontools或者monit工具。所以如果Nimbus或者Supervisor daemon进程挂了,它可以像什么异常也没有发生似的重新启动。

Most notably, no worker processes are affected by the death of Nimbus or the Supervisors. This is in contrast to Hadoop, where if the JobTracker dies, all the running jobs are lost.

非常重要的是,没有任何Worker进程会因Nimbus或者Supervisor的挂掉而受到影响。这个和Hadoop相反。在Hadoop中如果JobTracker挂了,所有运行的Job将会丢失。

Nimbus是否有单点故障?

If you lose the Nimbus node, the workers will still continue to function. Additionally, supervisors will continue to restart workers if they die. However, without Nimbus, workers won‘t be reassigned to other machines when necessary (like if you lose a worker machine).

当Nimbus节点出现故障,Worker将依然可以继续工作。此外,Supervisor将可以继续重启挂掉的Worker。然而,没有了Nimbus节点,Worker不能在需要的时候被重新分配到其它的机器。(就像你丢失了一台Woker机器)。

So the answer is that Nimbus is "sort of" a SPOF. In practice, it‘s not a big deal since nothing catastrophic happens when the Nimbus daemon dies. There are plans to make Nimbus highly available in the future.

所以答案是Nimbus是会有单点故障的问题。在实践中,这个不是大问题。Nimbus deamon进程挂掉不会引起任何灾难发生。在将来,计划将Nimbus设计成高可用。

Storm如何保证数据处理?

Storm提供了一些机制来保证即使在节点挂了或者消息被丢失的情况下也能正确的进行数据处理。可以参考 Guaranteeing message processing

参考链接:

Storm官方文档:Fault Tolerance

博文:storm的故障容错分析

时间: 2024-10-06 23:51:35

Fault Tolerance —— Storm的故障容错性的相关文章

VMware Fault Tolerance 概述及功能

VMware Fault Tolerance - 为您的应用程序提供全天候可用性 通过为虚拟机启用 VMware Fault Tolerance,最大限度地延长数据中心的正常运行时间,减少停机管理成本.基于 vLockstep 技术的 VMware Fault Tolerance 可使应用程序实现零停机.零数据丢失,同时消除了传统硬件或软件集群解决方案的成本和复杂性. 1.消除因硬件故障造成的停机VMware Fault Tolerance 是一项前沿技术,它通过创建实际上与主实例保持同步的虚拟

Fault Tolerance(FT)

vSphere Fault Tolerance通过创建和维护与主虚拟机相同,并且可在发生故障切换时随时替换主虚拟机的辅助虚拟机,来确保虚拟机的连续可用性,其实就是一为某一个虚拟机创建一个完全相同的副本.可以为虚拟机启用vSphere Fault Tolerance.比获得比vSphere HA所提供的级别更高的可用性和数据保护,从而确保业务连续性.Fault Tolerance时基于ESXi主机平台构建的(使用VMware vLockstep技术),它通过在单独主机上一虚拟锁步方式运行相同的虚拟

Practical Byzantine Fault Tolerance

来自论文Practical Byzantine Fault Tolerance 本文旨在进行Byzantine faults的容错,文章开门见山提出了新算法的优势:可工作在异步环境(如Internet),响应时间可以获得比之前算法超过一个数量级的提升.当然肯定会有limitation伴随,我们试着找出它们. 一开始文章就告诉我们有一个问题还没能解决:fault-tolerant privacy. ?Normal-Case Operation 提出了Buffered requests,可以减少系统

Flink Program Guide (9) -- StateBackend : Fault Tolerance(Basic API Concepts -- For Java)

State Backends 本文翻译自文档Streaming Guide / Fault Tolerance / StateBackend ----------------------------------------------------------------------------------------- 使用Data Stream API编写的程序通常以多种形式维护状态: ·  窗口将收集element或在它被触发后聚合element ·  Transformation方法可能会

Apache Flink fault tolerance源码剖析(四)

上篇文章我们探讨了Zookeeper在Flink的fault tolerance中发挥的作用(存储/恢复已完成的检查点以及检查点编号生成器). 这篇文章会谈论一种特殊的检查点,Flink将之命名为--Savepoint(保存点). 因为保存点只不过是一种特殊的检查点,所以在Flink中并没有太多代码实现.但作为一个特性,值得花费一个篇幅来介绍. 检查点VS保存点 使用数据流API编写的程序可以从保存点来恢复执行.保存点允许你在更新程序的同时还能保证Flink集群不丢失任何状态. 保存点是人工触发

Apache Flink fault tolerance源码剖析(一)

因某些童鞋的建议,从这篇文章开始结合源码谈谈Flink Fault Tolerance相关的话题.上篇官方介绍的翻译是理解这个话题的前提,所以如果你想更深入得了解Flink Fault Tolerance的机制,推荐先读一下前篇文章理解它的实现原理.当然原理归原理,原理体现在代码实现里并不是想象中的那么直观.这里的源码剖析也是我学习以及理解的过程. 作为源码解析Flink Fault Tolerance的首篇文章,我们先暂且不谈太有深度的东西,先来了解一下:Flink哪里涉及到检查点/快照机制来

Apache Flink fault tolerance源码剖析完结篇

这篇文章是对Flinkfault tolerance的一个总结.虽然还有些细节没有涉及到,但是基本的实现要点在这个系列中都已提及. 回顾这个系列,每篇文章都至少涉及一个知识点.我们来挨个总结一下. 恢复机制实现 Flink中通常需要进行状态恢复的对象是operator以及function.它们通过不同的方式来达到状态快照以及状态恢复的能力.其中function通过实现Checkpointed的接口,而operator通过实现StreamOpeator接口.这两个接口的行为是类似的. 当然对于数据

Apache Flink fault tolerance源码剖析(三)

上一篇文章我们探讨了基于定时任务的周期性检查点触发机制以及基于Akka的actor模型的消息驱动协同机制.这篇文章我们将探讨Zookeeper在Flink的Fault Tolerance所起到的作用. 其实,Flink引入Zookeeper的目的主要是让JobManager实现高可用(leader选举). 因为Zookeeper在Flink里存在多种应用场景,本篇我们还是将重心放在Fault Tolerance上,即讲解Zookeeper在检查点的恢复机制上发挥的作用. 如果用一幅图表示快照机制

Flink Program Guide (7) -- 容错 Fault Tolerance(DataStream API编程指导 -- For Java)

false false false false EN-US ZH-CN X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt