RSS订阅源。教程已帮带300+人遂转型Hadoop开发。

作者: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秒

 

相关文章