大红鹰葡京会Storm介绍(二)(第8首)实时可靠的开源分布式实时计算体系——Storm

作者:Jack47

分享同效仿今年新型Hadoop大数额教程以及100道Hadoop十分数据一定会面试题。

转载请保留作者及原文出处

坐链接经常于调和,需要之心上人要 加微信
ganshiyun666 来取最新下充斥链接,注明“OSC”

欢迎关注我之微信公众账号程序员杰克,两边的稿子会一起,也堪加加我之RSS订阅源。

 

本文是Storm系列之一,主要介绍Storm的架构设计,推荐读者以翻阅Storm介绍(一)的底蕴之上,阅读这无异首。本文只是作者的读书笔记,偏重于浅层次的架介绍,如果想实在懂里面设计上的衡量,还索要再次多的去看Storm源码。

课已拉300+人成功转型Hadoop开发,90%起薪超过20K,工资可比前翻了同等倍增。

略知一二Storm的架,有助于帮助我们知晓大型分布式系统设计被需要解决的问题,以及缓解问题之思路,帮助我们再好的进展Storm性能调优化。

百度Hadoop核心架构师亲自录制

架构

先行上一致摆设Storm的架构图,如果熟悉
GFS和Hadoop的架构,会发觉这些系统的架构图都坏接近。
大红鹰葡京会 1

Storm架构图

内容包括0基础入门、Hadoop生态系统、真实商业类实战3多数。其中经贸案例可以吃您点实际的养环境,训练好之开销力量。

各个节点的来意

如您熟悉Hadoop的语,可以这么做一下近似比较:

Hadoop Storm
JobTracker Nimbus(只有一个)
TaskTracker Supervisor(有很多个)
MapReduce任务 Topology

足见见Nimbus举凡调度器,WorkerTask的容器,Task凡是职责的的确实施者。

局部视频截图显示

起先拓扑

为当集群达启动一个拓扑,需要首先把代码打包改成一个“胖jar包”–必须带有有的倚重代码,除了Storm它本身,因为Storm集群会提供。然后在同一尊设置了storm命令行的机上经过storm jar指令来付拓扑:

storm jar my-topology-version-with-dependency.jar com.corp.MyTopology arg1 arg2

本条命令会并到Nimbus,上传jar包。接下来Nimbus会把拓扑的代码运送至多台不同的机械要JVM上。只有当拓扑在机器上安排成功了并且于JVM中初始化了后来,才能够真的开始拍卖消息。

大红鹰葡京会 2

Master结点(Master node)

以分布式系统中,调度服务非常重大,它的筹划,会一直关乎及网的运转效率,错误恢复(fail
over),故障检测(error detection)和档次扩展(scale)的力量。

集群达职责(task)的调度由一个Master节点来承担。这台机械及运行的Nimbus过程负责任务之调度。另外一个过程是Storm
UI,可以界面上查看集群和持有的拓扑的周转状态。

大红鹰葡京会 3

从节点(Slave node)

Storm集群上闹差不多只从节点,他们于Nimbus上下载拓扑的代码,然后去真正实施。Slave上的Supervisor过程是因此来监督及管理实际上运作工作代码的长河。在Storm
0.9过后,又大多矣一个历程Logviewer,可以用Storm
UI来查看Slave节点上的log文件。
于安排文件storm.yaml遭遇,决定了同等大机器及运行几个worker:

supervisor.slots.ports:
- 6700
- 6701
- 6702

流式计算解决方案-Storm

当Hadoop生态圈着,针对大数据开展批量测算时,通常需要一个要基本上只MapReduce作业来完成,但这种批量盘算方式是满足不了针对实时性要求强之光景。

Storm是一个开源分布式实时计算体系,它可以实时可靠地处理流数据。

本章内容:

1) Storm特点

2) Storm基本概念

3) Storm分组模式

4) Storm系统架构

5) Storm容错机制

6) 一个简单易行的Storm实现

ZooKeeper的作用

ZooKeeper当Storm上无是故来做信息传用底,而是用来供协调服务(coordination
service),同时储存拓扑的状态与统计数据。

  • ZooKeeper相当于同一片黑板,SupervisorNimbus和worker都以上头留约定好的消息。例如Supervisor启动时,会在ZooKeeper上注册,Nimbus即可以窥见SupervisorSupervisor于ZooKeeper上留下心跳信息,Nimbus经这些心跳信息来针对Supervisor展开常规检测,检测出怪节点
  • 鉴于Storm组件(component)的状态信息囤积在ZooKeeper上,所以Storm组件就好任由状态,可以
    kill -9来杀死

    • 譬如说:Supervisors/Nimbus的又开不影响在运转中之拓扑,因为状态还当ZooKeeper上,从ZooKeeper上又加载一下虽好了
  • 故此来举行心跳
    • Worker通过ZooKeeper把孩子executor的气象以心跳的花样反映给Nimbus
    • Supervisor进程经过ZK把好的状态呢坐心跳的样式反映给Nimbua
  • 积存最近任务的荒谬情况(拓扑停止时会见去除)

1. Storm特点

当Storm出现之前,进行实时处理是深痛苦之事务,我们任重而道远的时间都花在关注为哪里犯消息,从哪接收信息,消息如何序列化,真正的工作逻辑只占了自代码的同不怎么部分。一个应用程序的逻辑运行于无数worker上,但这些worker需要各自独立安排,还欲安排消息队列。最深问题是系统特别脆弱,而且无是容错的:需要好管信息队列和worker进程工作正常化。

Storm完整地缓解了这些问题。它是吗分布式场景而老之,抽象了消息传递,会自行地在集群机器上连发地处理流式计算,让您放在心上让实时处理的业务逻辑。

Storm有如下特点:

1) 编程简单:开发人员只待关注应用逻辑,而且跟Hadoop类似,Storm提供的编程原语也颇简单

2) 高性能,低顺延:可以动用被广告找引擎这种要求对广告主的操作进行实时响应的光景。

3) 分布式:可以轻松应针对数据量大,单机搞不肯定的观

4) 可扩大:随着业务发展,数据量和计算量越来越不行,系统而是水平扩展

5) 容错:单个节点挂了不影响使

6) 消息未掉:保证信息处理

可Storm不是一个完好无损的缓解方案。使用Storm时你用关怀以下几点:

1) 如果采取的是上下一心的音信队列,需要参加消息队列做多少的发源及出现的代码

2) 需要考虑怎么做故障处理:如何记录信息处理的速,应针对Storm重开,挂掉的场面

3) 需要考虑如何做信息的回退:如果某些信息处理直接失败怎么收拾?

Storm的容错(Fault Tolerance)机制

正如“搭建一个Storm集群”同一中和介绍的一样,必须用工具要daemontools或者monit来监督Nimbus和Supervisor的后台进程。这样一旦Nimbus或者Supervisor经过挂掉,会被daemontools检测到,并开展更开。

NimbusSupervisor过程被设计成高速砸(fail
fast)的(当遇到好的情况,进程就见面挂掉)并且是随便状态的(状态都封存于Zookeeper或者在磁盘上)。

无限重大之是,worker进程不会见以Nimbus或者Supervisor挂掉而吃影响。这跟Hadoop是匪等同的,当JobTracker挂掉,所有的天职都见面没有了。

  1. 当Nimbus挂掉会怎么样?

    只要Nimbus是因引进的计处于进程监管(例如通过supervisord)之下,那其见面让再开,不会见发其它影响

    否则当Nimbus挂掉后:

    • 既存在的拓扑可以继续健康运转,但是非克交付新拓扑
    • 恰以运作的worker进程仍然可以继承工作。而且当worker挂掉,supervisor会一直重复开worker。
    • 挫折的任务不会见为分配至其它机器(是Nimbus的天职)上了
  2. 当一个Supervisor(slave节点)挂掉会怎样?

    如Supervisor是因引进的措施处于进程监管(例如通过(supervisord)[supervisord.org/])之下,那其见面让再度开,不会见生出任何影响

    要不当Supervisor挂掉:
    分配到就令机器的富有任务(task)会过,Nimbus会把这些任务(task)重新分配给其他机器。

  3. 当一个worker挂掉会咋样?

    当一个worker挂掉,supervisor会重开它。如果开行一直失败那么这worker也便非能够及Nimbus保持中心跳了,Nimbus会重新分配worker到其他机器

  4. Nimbus算是一个单点故障吗?
    假定Nimbus节点挂掉,worker进程仍然可以持续工作。而且当worker挂掉,supervisor会一直重复开worker。但是,没有了Nimbus,当用的时(如果worker机器挂掉了)worker就无能够叫重新分配到外机器了。
    因而答案是,Nimbus在“某种程度”上属于单点故障的。在骨子里被,这种状况没什么好莫了底,因为当Nimbus进程挂掉,不见面有悲惨的工作闹

2. Storm与Hadoop区别

1) 定义及架构

Hadoop是Apache的一个档,是一个克对大量数额进行分布式处理的软件框架。

Storm是Apache基金会的抱项目,是采取叫流式数据实时处理领域的分布式计算系统。

 

Hadoop

Storm

系统角色

JobTracker

Nimbus

 

TaskTracker

Supervisor

 

Child

Worker

应用名称

Job

Topology

组件接口

Mapper/Reducer

Spout/Bolt

2) 应用方面

Hadoop是分布式批处理计算,强调批处理,常用来数据挖掘与剖析。

Storm是分布式实时计算,强调实时性,常用于实时性要求较高的地方。

3) 计算处理方式

Hadoop是磁盘级计算,进行测算时,数据以磁盘上,需要读写磁盘;Hadoop应用MapReduce的思考,将数据切片计算来拍卖大量之离线数据。Hadoop处理的数码要是既存放于HDFS上或者类似HBase的数据库被,所以Hadoop实现之时段是由此移动计量到这些存放数据的机械及来提高效率的。

Storm是内存级计算,数据直接通过网络导入内存。Storm是一个流计算框架,处理的数额是实时信息队列中之,需要写好一个Topology逻辑,然后将收到进来的数据开展处理,所以Storm是通过移动多少平均分配到机械资源来得到大效率的。

4) 数据处理者

多少来自:Hadoop是HDFS上有文件夹下之多寡,数据量可能因TB来算;而Storm则是实时新增的某某同画数量。

处理过程:Hadoop是Map阶段及Reduce阶段的;Storm是由于用户定义处理流程,流程中好分包多只步骤,每个步骤可以是数据源(SPOUT),也得是处理逻辑(BOLT)。

是不是终止:Hadoop最后要要收;而Storm没有终结状态,到结尾一步时,就终止于那,直到发生新数据上时再次重复开。

处理速度:Hadoop以处理HDFS上大方多少为目的,速度放缓;Storm只要处理新增的有平笔画数额即可,故此它的快慢特别快。

适用场景:Hadoop主要是处理同批数量,对时效性要求未赛,需要处理便提交一个JOB;而Storm主要是拍卖某平等增产多少的,故此时效性要求大。

小结,Hadoop和Storm并没真正优劣之分,它们只是当各自的领域上发生正值独特之习性而已,若是确拿它进行单独的比,反而是生去公允了。事实上,只有当最宜的端采取最当的不得了数量平台,才能够真正反映出她的价,也才能够真正为我们的办事提供极致便捷的助力!

硬件要求

3. Storm基本概念

1) Topology

一个Storm拓扑打包了一个实时处理程序的逻辑。一个Storm拓扑跟一个MapReduce的职责(job)是看似之。主要分是MapReduce任务最终见面结束,而拓扑会一直运行(当然直到你杀死它)。一个拓扑是一个由此流分组(Stream
Grouping)把Spout和Bolt连接到一起的拓扑结构。图的各个条边表示一个Bolt订阅了另Spout或者Bolt的输出流。一个拓扑就是一个错综复杂的大多阶段的流计算。

大红鹰葡京会 4 

2) Tuple

元组是Storm提供的一个轻量级的数码格式,可以用来包装而用实际处理的多少。元组是同样潮消息传递的中心单元。一个元组是一个命名的值列表,其中的每个值都足以是随便档次的。元组是动态地展开项目转化的—字段的花色不待事先声明。在Storm中编程时,就是在操作与转换由元组组成的流动。通常,元组包含整数,字节,字符串,浮点数,布尔值和字节数组等类。要惦记当元组中使从定义类型,就待贯彻自己之序列化方式。

大红鹰葡京会 5 

3) Stream

流是Storm中的骨干抽象。一个流由无限的元组序列组成,这些元组会给分布式并行地创建与拍卖。通过流中元组包含的字段名称来定义是流。

每个流声明时且为与了一个ID。只有一个流的Spout和Bolt非常大,所以OutputFieldsDeclarer提供了非需指定ID来声称一个淌的函数(Spout和Bolt都急需声明输出的流淌)。这种情况下,流的ID是默认的“default”。

4) Spout

Spout(喷嘴,这个名字挺像)是Storm中流的起源。通常Spout从表面数据源,如信息队列中读取元组数据并呕吐到拓扑里。Spout可以是牢靠的(reliable)或者不可靠(unreliable)的。可靠的Spout能够当一个元组被Storm处理失败时还展开拍卖,而无可靠的Spout只是吐数据到拓扑里,不关注处理成还是败诉了。

大红鹰葡京会 6 

Spout可以同样糟糕让多独流吐数据。此时内需经OutputFieldsDeclarer的declareStream函数来声称多个流并在调用SpoutOutputCollector提供的emit方法时指定元组吐于哪个流。

Spout中最关键的函数是nextTuple,Storm框架会持续调用它失去开元组的轮询。如果无初的元组过来,就直返回,否则把新元组吐到拓扑里。nextTuple必须是非阻塞的,因为Storm在与一个线程里行Spout的函数。

Spout中另外两独至关重要的函数是Ack和fail。当Storm检测及一个自Spout吐出底元组在拓扑中打响拍卖完时调用Ack,没有成拍卖完时调用Fail。只有可靠型的Spout会调用Ack和Fail函数。

5) Bolt

当拓扑中颇具的计量逻辑都是在Bolt中贯彻的。一个Bolt可以处理任意数量之输入流,产生任意数量新的输出流。Bolt可以开函数处理,过滤,流的合并,聚合,存储到数据库等操作。Bolt就是流程上之一个处理单元,把多少的算计处理过程合理之拆分到几近个Bolt、合理设置Bolt的task数量,能够加强Bolt的处理能力,提升流水线的连发度。

大红鹰葡京会 7 

Bolt可以被多单流吐出元组数据。此时得利用OutputFieldsDeclarer的declareStream方法来声称多独流并在用[OutputColletor](https://storm.apache.org/javadoc/apidocs/backtype/storm/task/OutputCollector.html)的emit方法时指定给哪个流吐数据。

当您声明了一个Bolt的输入流,也便订阅了另外一个零部件的之一特定的输出流。如果希望订阅其他一个组件的持有流动,需要独自挨个订阅。InputDeclarer有语法糖来订阅ID为默认值的流。例如declarer.shuffleGrouping(“redBolt”)订阅了redBolt组件上的默认流,跟declarer.shuffleGrouping(“redBolt”,
DEFAULT_STREAM_ID)是相同之。

每当Bolt中极度紧要的函数是execute函数,它以一个初的元组当作输入。Bolt使用OutputCollector对象来吐生新的元组。Bolts必须也处理的每个元组调用OutputCollector的ack方法以便让Storm知道元组什么时让逐个Bolt处理终结了(最终就足以确认Spout吐出之某元组处理了了)。通常处理一个输入的元组时,会冲这个元组吐生零个要多独元组,然后确认(ack)输入的元组处理了了,Storm提供了IBasicBolt接口来机关完成确认。

须注意OutputCollector不是线程安全之,所以具有的呕吐数据(emit)、确认(ack)、通知未果(fail)必须来在与一个线程里。更多信息可参照问题一定

6) Task

每个Spout和Bolt会以差不多个任务(Task)的款式在集群达运行。每个任务对应一个实践线程,流分组定义了争由同组任务(同一个Bolt)发送元组到另外一组任务(另外一个Bolt)上。可以于调用TopologyBuilder的setSpout和setBolt函数时设置每个Spout和Bolt的连发数。

7) Component

组件(component)是对Bolt和Spout的统称

8) Stream Grouping

概念拓扑的早晚,一部分干活是点名每个Bolt应该花费如何流。流分组定义了一个流在一个花费它的Bolt内之多只任务(task)之间如何分组。流分组跟计算机网络中之路由功能是接近之,决定了每个元组在拓扑中之处理途径。

当Storm中产生七个放置的流分组策略,你吧足以由此落实CustomStreamGrouping接口来自定义一个流分组策略:

洗牌分组(Shuffle
grouping): 
轻易分配元组到Bolt的某个任务上,这样保证与一个Bolt的每个任务还能够抱一致数量的元组。

字段分组(Fields
grouping): 
照指定的分组字段来开展流动的分组。例如,流是用配段“user-id”来分组的,那具一样“user-id”的元组就见面分开到和一个职责里,但是生两样“user-id”的元组就会分开及不同的任务里。这是均等种植十分重要的分组办法,通过这种流分组方式,我们就可以成功为Storm产出的音信在这”user-id”级别是严峻有序的,这对片针对时序敏感的施用(例如,计费系统)是深主要的。

Partial Key
grouping: 
同字段分组一样,流也是用指定的分组字段进行分组的,但是以差不多个下游Bolt之间是出负载均衡的,这样当输入数据有倾斜时可以再好之应用资源。这篇论文很好的分解了当下是安工作之,有哪优势。

All grouping: 流会复制给Bolt的享有任务。小心用这种分组办法。

Global
grouping:
 整个流会分配给Bolt的一个职责。具体一点,会分配为有极小ID的天职。

不分组(None grouping): 征非关心流是何许分组的。目前,None
grouping等价于洗牌分组。

Direct
grouping:
同一种特别的分组。对于如此分组的流淌,元组的劳动者决定消费者的谁任务会收到处理此元组。只能当宣称做直连的流(direct
streams)上宣示Direct
groupings分组方式。只能通过利用emitDirect系列函数来吐元组给直连流。一个Bolt可以经过提供的TopologyContext来得到消费者的职责ID,也可以经OutputCollector对象的emit函数(会回元组被发送到的任务的ID)来跟消费者之职责ID。

Local or shuffle
grouping:如果目标Bolt在和一个worker进程里产生一个要多只任务,元组就会通过洗牌的法门分配至这些跟一个历程内之天职里。否则,就和一般的洗牌分组一样。

大红鹰葡京会 8 

9) Reliability

Storm保证了拓扑中Spout产生的每个元组都见面为处理。Storm是由此跟每个Spout所起的有元组构成的树形结构并查获这棵树何时吃完好地拍卖来齐可靠性。每个拓扑对这些树形结构还产生一个关联的“消息超时”。如果以这个超时时间里Storm检测到Spout产生的一个元组没有为成功拍卖完毕,那Spout的此元组就处理失败了,后续会重新处理一全体。

以发挥Storm的可靠性,需要而当开立一个元组树被之同修边时告诉Storm,也用在拍卖完毕每个元组之后告诉Storm。这些都是经Bolt吐元组数据用的OutputCollector对象来好的。标记是以emit函数里成功,完成一个元组后需要使用Ack函数来报告Storm。

10) Workers

拓扑以一个要多只Worker进程的计运行。每个Worker进程是一个物理的Java虚拟机,执行拓扑的均等组成部分任务。例如,如果拓扑的出现设置成了300,分配了50只Worker,那么每个Worker执行6独任务(作为Worker内部的线程)。Storm会尽量将具有的天职均分及具备的Worker上。

ZooKeeper

  1. 推荐精心设计过之机器,因为ZooKeeper是Storm的瓶颈
    • 每个机器使用一个ZK的实例
    • 顾为同样台机械及的旁进程或虚拟机他们是共享这大机械的,所以可能会见影响ZK的性能(来源)
  2. I/O是ZooKeeper的瓶颈

  3. 将ZooKeeper的仓储放到自己的磁盘上

  4. 使用SSD会显著升级性
  5. 常规情形下,Zookeeper的每次写操作都见面同步到磁盘,这虽造成了少不善磁盘寻址操作(一糟糕是数,一糟糕是数码的日志)。当有着的worker都发心跳给ZooKeeper时,可能会见明白影响属性(来源)。

    • 欲监控ZooKeeper节点的I/O负载
  6. 引进以生产条件达标运行的ZooKooper集群有起码3单节点,这样就发生一个ZooKeeper服务器挂掉了(例如进行保障),也是可的。

4. Storm系统架构

大红鹰葡京会 9 

1) 主节点(Nimbus):

当分布式系统中,调度服务十分重大,它的计划,会一直关乎及系统的运转效率,错误恢复(fail
over),故障检测(error detection)和水准扩展(scale)的能力。

集群达职责(task)的调度由一个Master节点来负担。这令机器上运行的Nimbus进程负责任务之调度。另外一个过程是Storm
UI,可以界面及查看集群和拥有的拓扑的运作状态。

2) 从节点(Supervisor)

Storm集群上发出差不多只由节点,他们打Nimbus上下载拓扑的代码,然后去真正实施。Slave上之Supervisor进程是因此来监督同管理实际上运作工作代码的经过。在Storm
0.9后,又基本上矣一个历程Logviewer,可以就此Storm
UI来查阅Slave节点上的log文件。

3) 协调服务Zookeeper:

ZooKeeper在Storm上无是因此来开信息传用底,而是用来提供协调服务(coordination
service),同时储存拓扑的状态与统计数据。

l Supervisor,Nimbus和worker都以ZooKeeper留下约定好之音。例如Supervisor启动时,会在ZooKeeper上注册,Nimbus就得窥见Supervisor;Supervisor在ZooKeeper上预留心跳信息,Nimbus通过这些心跳信息来对Supervisor进行正常检测,检测出异常节点

l 由于Storm组件(component)的状态信息存储于ZooKeeper上,所以Storm组件就可无状态,可以
kill -9来杀死

譬如说:Supervisors/Nimbus的重复开不影响在运转中的拓扑,因为状态都于ZooKeeper上,从ZooKeeper上再也加载一下就算好了

l 用来举行心跳

Worker通过ZooKeeper把孩子executor的情景以心跳的款式反映给Nimbus

Supervisor进程经过ZK把温馨之状态也为心跳的形式反映给Nimbua

l 存储最近任务的一无是处情况(拓扑停止时会去)

4) 进程Worker

运转具体处理组件逻辑的进程,一个Topology可能会见当一个还是多个worker里面执行,每个worker是一个物理JVM并且实施总体Topology的均等有些

诸如:对于并行度是300底topology来说,如果我们采取50只工作进程来实施,那么每个工作经过会处理中的6个tasks,Storm会尽量都匀的工作分配为有的worker

5) Task

Worker中的各国一个spout/bolt的线程称为一个task,每一个spout和bolt会被用作很多task在整集群里行,每一个executor对诺到一个线程,在这个线程上运行多只task,Stream Grouping则是概念怎么由一堆task发出tuple到另外一堆task,可以调用TopologyBuilder类的setSpout和setBolt来安装并行度(也就是出微个task)

 

Storm安全性

原本设计Storm时,完全没拿安全性考虑在内
现安性能相关的效益以一步步加以进去
Storm 0.9.x版及之安康问题:

  1. 未曾说明机制(authentication),没有授权机制(authorization)
  2. 传的多寡(例如worker之间)没有加密
  3. ZooKeeper上囤积的数量没有看限制
  4. 设Nimbus的Thrift端口没有沿住,任意的用户代码都得以节点上实行

还多Storm安全性方面的提议见这里

题外话:
以点Storm之后,有只问题在本人之脑际里升腾,国内的坏庄,比如Baidu,Ali,腾讯,都是发出出生Storm这好像实时计算框架的土的,可是怎么没有召开下呢?

Apache Storm Basic
Training
Fault
tolerance

Storm in pictures

Storm 0.9 Basic
Training


假如您看了本篇博客,觉得对你有得,请点击右侧下角的“推荐”,让再多人口观看!

捐助Jack47写作,打赏一个鸡蛋灌饼钱吧

大红鹰葡京会 10

微信打赏

大红鹰葡京会 11

支付宝打赏

5. Storm容错机制

Storm的容错机制包括架构容错和多少容错。

1) 架构容错:

Nimbus和Supervisor进程被规划改为很快砸(fail
fast)的(当遇到好的动静,进程就会见挂掉)并且是随便状态的(状态且保留于Zookeeper或者在磁盘上)。

无限关键的凡,worker进程不会见以Nimbus或者Supervisor挂掉而为影响。这与Hadoop是匪一致的,当JobTracker挂掉,所有的任务还见面没了。

当Nimbus挂掉会怎么?

设若Nimbus是因引进的法子处于进程监管(例如通过supervisord)之下,那她会叫再度开,不见面产生其他影响。

否则当Nimbus挂掉后:

l 已经存在的拓扑可以继续健康运转,但是不能够交到新拓扑

l 正在周转的worker进程仍然可继承工作。而且当worker挂掉,supervisor会一直还开worker。

l 失败的任务不见面让分配至另外机器(是Nimbus的天职)上了

当一个Supervisor(slave节点)挂掉会怎样?

苟Supervisor是为引进的法子处于进程监管(例如通过(supervisord)[supervisord.org/])之下,那其见面让重新开,不见面来任何影响

要不当Supervisor挂掉:分配至就台机器的备任务(task)会过,Nimbus会把这些任务(task)重新分配给其他机器。

当一个worker挂掉会咋样?

当一个worker挂掉,supervisor会重开它。如果开行一直失败那么此时worker也就是非能够和Nimbus保持中心跳了,Nimbus会重新分配worker到另外机器。

Nimbus算是一个单点故障吗?

比方Nimbus节点挂掉,worker进程仍然可以连续做事。而且当worker挂掉,supervisor会一直还开worker。但是,没有了Nimbus,当得之早晚(如果worker机器挂掉了)worker就无能够为重新分配到其他机器了。

故答案是,Nimbus在“某种程度”上属于单点故障的。在骨子里中,这种状态没什么大莫了的,因为当Nimbus进程挂掉,不见面发生悲凉的事务闹

2) 数据容错:

Storm中之各级一个Topology中都含有一个Acker组件。
Acker组件的职责就是是跟从某task中之Spout流出的诸一个messageId所绑定的Tuple树中之有着Tuple的处理状态。如果当用户安装的最为深超时时间(timetout
可以经过
Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS来指定)内这些Tuple没有让统统处理,那么Acker会告诉Spout该信息处理失败,相反则会告诉Spout该信息处理成,它会独家调用Spout中的fail和ack方法。

6. 一个大概的Storm实现

实现一个拓扑包括一个spout和个别只bolt。Spout发送单词。每个bolt在输入数据的尾部增加字符串“!!!”。三独节点排成一修线:spout发射于首个bolt,然后,这个bolt再发射于老二只bolt。如果spout发射元组“bob”和“john”,然后,第二独bolt将发射元组“bob!!!!!!”和“john!!!!!!”。

1) 其中Topology代码如下,定义整个网络拓扑图:

TopologyBuilder builder = new TopologyBuilder();

builder.setSpout("words", new TestWordSpout(), 10);

builder.setBolt("exclaim1", new ExclamationBolt(), 3)              .shuffleGrouping("words");

builder.setBolt("exclaim2", new ExclamationBolt(), 2)

             .shuffleGrouping("exclaim1");

2) Spout实现:

public void nextTuple() {

        Utils.sleep(100);

        final String[] words = new String[] {"nathan", "mike", "jackson",                                                                           "golda", "bertels"};

        final Random rand = new Random();

        final String word = words[rand.nextInt(words.length)];

        _collector.emit(new Values(word));

}

3) Bolt实现:

public static class ExclamationBolt implements IRichBolt {

        OutputCollector _collector;

        public void prepare(Map conf, TopologyContext context, OutputCollector collector) {

                _collector = collector;

        }

        public void execute(Tuple tuple) {

                _collector.emit(tuple, new Values(tuple.getString(0) + "!!!"));

                _collector.ack(tuple);

        }

        public void cleanup() {

        }

        public void declareOutputFields(OutputFieldsDeclarer declarer) {

                declarer.declare(new Fields("word"));

        }

}

7. Storm常用配置

1) Config.TOPOLOGY_WORKERS:

斯装置用有些只办事进程来执行此topology。比如,如果你管其装成25,
那么集群中一共会有25单java进程来实行这个topology的拥有task。如果您的这个topology里面所有组件加起来一共发150之并行度,那么每个过程中会时有发生6单线程(150
/ 25 = 6)。

2) Config.TOPOLOGY_ACKERS:

其一布局安装acker任务之并行度。默认的acker任务并行度为1,当系统中发生恢宏的信息时,应该当增强acker任务的并发度。设置为0,通过者方式,当Spout发送一个音的当儿,它的ack方法将马上为调用;

3) Config.TOPOLOGY_MAX_SPOUT_PENDING:

以此装置一个spout
task上面最多来微个尚未处理的tuple(没有ack/failed)回复,
我们引进您设置是布局,以预防tuple队列爆掉。

4) Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS:

斯布局storm的tuple的超时时间 –
超过这时空之tuple被当处理失败了。这个装置的默认设置是30秒

 

相关文章

admin

网站地图xml地图