学科已帮带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非常广阔,所以OutputField(Field)sDeclarer提供了不需要指定ID来声称一个流的函数(Spout和Bolt都亟待讲明输出的流)。那种情景下,流的ID是默认的“default”。

4) Spout

Spout(喷嘴,那一个名字很形象)是Storm中流的源于。平常Spout从外表数据源,如音信队列中读取元组数据并吐到拓扑里。Spout可以是举手之劳的(reliable)或者不可靠(unreliable)的。可靠的Spout可以在一个元组被Storm处理退步时再也展开处理,而非可靠的Spout只是吐数据到拓扑里,不关心处理成功或者败诉了。

图片 6 

Spout可以四回给多少个流吐数据。此时内需经过Output菲尔德(Field)(Field)sDeclarer的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可以给四个流吐出元组数据。此时亟需使用Output菲尔德(Field)sDeclarer的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的每个任务都可以获取相同数量的元组。

字段分组(Field(Field)s
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的瓶颈
  • 把ZooKeeper的贮存放到自己的磁盘上
  • 运用SSD会分明升级性能
  • 好端端情形下,Zookeeper的历次写操作都会一起到磁盘,这就导致了五回磁盘寻址操作(五次是多少,三遍是多少的日记)。当所有的worker都发心跳给ZooKeeper时,可能会明确影响属性(来源)。
    • 急需监控ZooKeeper节点的I/O负载
  1. 引进在生养环境上运行的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


假诺您看了本篇博客,觉得对你拥有收获,请点击右下角的“推荐”,让更六个人收看!

捐助杰克(Jack)47写作,打赏一个鸡蛋灌饼钱呢

图片 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秒

 

相关文章