原文：http://blog.csdn.net/xeseo/article/details/17674775

写在前面的话：

        请允许我废话几句。这个系列的文章发布的时间是在我完成了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是什么？

https://github.com/nathanmarz/storm/wiki/Rationale 官方的 http://www.searchtb.com/2012/09/introduction-to-storm.html 淘宝 http://blog.linezing.com/2012/12/storm入门教程-第一章-前言?spm=0.0.0.0.rjCR7D 量子恒道 以下是我的理解： 直接面向客户的互联网网页，如电子商务，都注重客户体验，所以客户操作尽量简单化，即流水线化，如登陆->搜索->下单->(推荐)->付款。所以，形象点，一个业务流程即一个流水。那么，如果具有相当大业务流程并发时，N个流水就变成了瀑布、长江、黄河。在这种情况下，传统的单机处理是无法满足性能需求的。必须得分布式处理。Storm就提供了一个分布式流处理框架，可以让开发者很容易的建立一个健壮的分布式程序，而不用过于关心底层分布式的实现。

基本模型

Storm的现实模型就是水流的处理，例如小区供水。 数据来源定义为Spout，源源不断的供给水流。水流在管道中流行，定义为Stream。每个住户都会消费水，是Stream中的一个节点，定义为Bolt。可能会将消费的水排放，也或许不排。一个小区的Spout、Stream、Bolt组合在一起，即一个拓扑结构，定义为Topology。 红色强调部分，在Storm的实现中，真的就是这么做的。我会在后面的文章中去解释。 Storm实现： Spout：        数据源，源源不断的发送元组数据Tuple Tuple：         元组数据的抽象接口，可以是任何类型的数据。但是必须要可序列化。 Stream：     Tuple的集合。一个Stream内的Tuple拥有相同的源。 Bolt：             消费Tuple的节点。消费后可能会排出新的Tuple到该Stream上，也可能会排到到其他Stream，也或者根本不排。可并发。 Topology： 将Spout、Bolt整合起来的拓扑图。定义了Spout和Bolt的结合关系、并发数量、配置等等。 有图有真相：

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就无法工作了。