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地图