Storm系列之——基本概念

写在前面的话:

        请允许我废话几句。这个系列的文章发布的时间是在我完成了Storm的项目开发之后才找出来时间写的,在研究Storm过程中,国内较好的参考文章实在有限,大多是入门和概念剖析。Storm的GoogleGroup对于新手来说实在不友好。有经验人士都不愿意回答新手的一些“愚蠢”的问题。现在因为Storm移交了Apache,正式启用了ApacheMailGroup就更不友好了……中间我走过不少弯路,自己摸索和看源码。虽然说自己理解的才是最深刻的,但是我觉得还是分享出来,减少大家走弯路时间,把注意力更多的放在Storm的应用探讨上。或许文章中会有错误,或许文章会“太监”,或许你只是遇到了一篇笔记而已。


介绍文章内写太多基本原理性东西,反而容易让人晕,所以在本篇中,只是点出基本概念模型,同时share一些基本资料给能力强的同学去研究。


转载请注明:转自http://blog.csdn.net/xeseo/article/details/17674775


有关Storm的一些信息片

Storm是由twitter在2011开源出来的产品,现在贡献给了Apache。

1. Storm官方主页:http://storm-project.net/ 看上去不是非常的Apache,所以以后有可能改为Apache的URL样式。

这个主页目前信息量有限。大多数好东西,在其github首页:https://github.com/nathanmarz/storm (最近刚刚把repo转移了到Apache孵化项目页https://github.com/apache/incubator-storm


2. 最重要的东西在这:https://github.com/nathanmarz/storm/wiki ,与Storm相关的概念性知识90%都在这里了。

不过作者把文章目录直接交给了github的Pages来管理,对于github新手来说可能会忽视这个有用的页面:https://github.com/nathanmarz/storm/wiki/_pages


3. 国内分享内容有深度的blog非StormContributor之一的徐明明的blog莫属:http://xumingming.sinaapp.com/category/storm/ 显然他不愧是Storm的贡献者之一啊,连文档管理都有Storm的风格。。。。。。


4. 写的非常好的,有图有证据的量子恒道官方博客Storm系列:http://blog.linezing.com/category/storm-quick-start?spm=0.0.0.0.rTjmpX 


Storm是什么?


以下是我的理解:

直接面向客户的互联网网页,如电子商务,都注重客户体验,所以客户操作尽量简单化,即流水线化,如登陆->搜索->下单->(推荐)->付款。所以,形象点,一个业务流程即一个流水。那么,如果具有相当大业务流程并发时,N个流水就变成了瀑布、长江、黄河。在这种情况下,传统的单机处理是无法满足性能需求的。必须得分布式处理。Storm就提供了一个分布式流处理框架,可以让开发者很容易的建立一个健壮的分布式程序,而不用过于关心底层分布式的实现。

基本模型


Storm的现实模型就是水流的处理,例如小区供水。
  • 数据来源定义为Spout源源不断的供给水流。
  • 水流在管道中流行,定义为Stream
  • 每个住户都会消费水,是Stream中的一个节点,定义为Bolt可能会将消费的水排放,也或许不排。
  • 一个小区的SpoutStreamBolt组合在一起,即一个拓扑结构,定义为Topology
红色强调部分,在Storm的实现中,真的就是这么做的。我会在后面的文章中去解释。

Storm实现:

Spout:        数据源,源源不断的发送元组数据 Tuple
Tuple:         元组数据的抽象接口,可以是任何类型的数据。但是必须要可序列化。
Stream:      Tuple的集合。一个 Stream内的 Tuple拥有相同的源。
Bolt:             消费Tuple的节点。消费后可能会排出新的 Tuple到该 Stream上,也可能会排到到其他 Stream,也或者根本不排。可并发。
Topology: 将 SpoutBolt整合起来的拓扑图。定义了 SpoutBolt的结合关系、并发数量、配置等等。

有图有真相:


Storm的特点


这里Storm的几个特性比较重要,是我们在选取是否使用Storm时要参考的:
  • 支持很多用户场景:
    • 处理消息->更新db,典型的流处理
    • 不停的实时查询,并把查询结果反馈给客户端
    • 通过其分布式框架,实现并行计算,把计算结果交给客户端(distribute RPC)
  • 纵向扩展性
    • 可以在Topology中的定义Spout、Bolt的并行度
  • 保证无数据丢失
  • 健壮
    • Storm的健壮是因为它只关系最核心的功能,弱化管理。因为简单而健壮。
  • 容错能力
    • 这个其实Storm的设计原则。Storm的任意节点,理论上都应该是一直运行而不停止的,即使遇到错误,直到被停止。后面的文中,我会提到如何正确的处理错误。
  • 多语言支持

基本工作框架


nimbus

很形象的取名,雨云,产生雨点的。它的作用有:

  • 整个topology的发起者,会把topology的jar包缓存到本地
  • 在提交topology时,分配资源
  • 在topology运行时,监听所有worker的心跳
  • 当某worker挂掉或收到重新分配请求时,重新分配资源
注意:
当一个topology被正常分配、启动后,nimbus只会监控supervisor的状态,为重新分配资源做准备。并不会做Stream中tuple分配到某节点这种事。
所以,如果nimbus在topology正常运行时挂掉,是不会影响该topology的正常运行的。它影响的是重新分配cluster资源。

supervisor

真正的工作节点。在其内部运行的可能是一个spout、亦可能是一个bolt。

  • 每一个supervisor会定义若干worker,每一个worker其实是一个独立的JVM进程,具有不同的端口号
  • 每一个worker内会维护一个线程池,每一个线程,在Storm中称为executor
  • 并行中的每一个spout、bolt对于supervisor中的worker来说是平等的,被认为是一个task。该task的执行会被worker分配到其内部线程池中的某一个或多个线程,即某一个或多个executor去执行
  • executor的数量<=spout数+bolt数+acker数 <= task总数。默认情况下是取=

注: acker 是个什么东西,后面的文章会讲述。这里暂且不提。


举例:


在该例子中,

blue spout并行度 = 2

green bolt并行度= 2

yellow bolt并行度 = 6

在不计acker的情况下,默认总的线程数 = 2+2+6 = 10. 两个节点的两个worker,在平均分配下,就是每个节点5个,即每个worker的线程池中有5个executor。

均匀分配,两个worker各得三个yellow bolt, 一个blue spout,和一个green bolt。

但是,green bolt在配置时,表明需要两个executor和四个task。所以在两个worker上,每个其实要处理 3(yellow bolt) + 1(blue spout) + 2(green bolt) = 6个task。

由于每个worker我们只配了5个executor,所以这6个task就在5个executor上轮循执行。而事实上,Storm做了优化,对于同一个类型的task,会交由同一个executor去处理。

所以,在每个节点上,会有固定的3个executor去执行yellow bolt, 一个固定的executor去执行blue spout,一个固定的executor去执行两个green spout。


zookeeper

zookeeper是Storm分布信息存储的地方。

  • nimbus会在zookeeper上建立topology的相关信息(包括如何分配)
  • supervisor会监听zookeeper,一旦有新的分配任务,就会去领下来去交由worker执行
  • zookeeper会保存worker的心跳情况,如果nimbus发现某个worker心跳丢失,就会重新分配资源

所以,这里真正会影响到集群运行的是zookeeper。一旦zookeeper挂掉,整个Storm就无法工作了。



评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值