storm介绍2

转载于：http://www.cnblogs.com/Jack47/p/storm_intro-2.html

理解Storm的架构，有助于帮助我们理解大型分布式系统设计中需要解决的问题，以及解决问题的思路，帮助我们更好的进行Storm性能调优化。

架构

先上一张Storm的架构图，如果熟悉 GFS和Hadoop的架构，会发现这些系统的架构图都很类似。

Storm架构图

各节点的作用

如果你熟悉Hadoop的话，可以这样做一下类比：

Hadoop	Storm
JobTracker	Nimbus(只有一个)
TaskTracker	Supervisor（有很多个)
MapReduce任务	Topology

可以看到

Nimbus

是调度器，

Worker

是

Task

的容器，

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中初始化了之后，才能真正开始处理消息。

Master结点(Master node)

在分布式系统中，调度服务非常重要，它的设计，会直接关系到系统的运行效率，错误恢复(fail over),故障检测(error detection)和水平扩展(scale)的能力。

集群上任务(task)的调度由一个

Master

节点来负责。这台机器上运行的

Nimbus

进程负责任务的调度。另外一个进程是Storm
UI，可以界面上查看集群和所有的拓扑的运行状态。

从节点(Slave node)

Storm集群上有多个从节点，他们从Nimbus上下载拓扑的代码，然后去真正执行。

Slave

上的

Supervisor

进程是用来监督和管理实际运行业务代码的进程。在Storm
0.9之后，又多了一个进程

Logviewer

,可以用Storm
UI来查看

Slave

节点上的log文件。

在配置文件

storm.yaml

中,决定了一台机器上运行几个worker:

supervisor.slots.ports:
- 6700
- 6701
- 6702

ZooKeeper的作用

ZooKeeper在Storm上不是用来做消息传输用的，而是用来提供协调服务(coordination service)，同时存储拓扑的状态和统计数据。
ZooKeeper相当于一块黑板，

Supervisor

，

Nimbus

和worker都在上面留下约定好的信息。例如

Supervisor

启动时，会在ZooKeeper上注册，

Nimbus

就可以发现

Supervisor

；

Supervisor

在ZooKeeper上留下心跳信息，

Nimbus

通过这些心跳信息来对

Supervisor

进行健康检测，检测出坏节点
由于Storm组件(component)的状态信息存储在ZooKeeper上，所以Storm组件就可以无状态，可以 kill -9来杀死
例如：Supervisors/Nimbus的重启不影响正在运行中的拓扑，因为状态都在ZooKeeper上，从ZooKeeper上重新加载一下就好了

用来做心跳
Worker通过ZooKeeper把孩子executor的情况以心跳的形式汇报给Nimbus
Supervisor进程通过ZK把自己的状态也以心跳的形式汇报给Nimbua

存储最近任务的错误情况(拓扑停止时会删除)

Storm的容错(Fault Tolerance)机制

正如“搭建一个Storm集群”一文介绍的一样，必须用工具如

daemontools

或者

monit

来监控Nimbus和Supervisor的后台进程。这样如果

Nimbus

或者

Supervisor

进程挂掉，会被

daemontools

检测到，并进行重启。

Nimbus

和

Supervisor

进程被设计成快速失败(fail
fast)的(当遇到异常的情况，进程就会挂掉)并且是无状态的(状态都保存在Zookeeper或者在磁盘上)。

最重要的是，worker进程不会因为

Nimbus

或者

Supervisor

挂掉而受影响。这跟Hadoop是不一样的，当JobTracker挂掉，所有的任务都会没了。

当Nimbus挂掉会怎样？
如果Nimbus是以推荐的方式处于进程监管(例如通过supervisord)之下，那它会被重启，不会有任何影响
否则当Nimbus挂掉后：
已经存在的拓扑可以继续正常运行，但是不能提交新拓扑
正在运行的worker进程仍然可以继续工作。而且当worker挂掉，supervisor会一直重启worker。
失败的任务不会被分配到其他机器(是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进程挂掉，不会有灾难性的事情发生

硬件要求

ZooKeeper

推荐精心设计过的机器，因为ZooKeeper是Storm的瓶颈
每个机器使用一个ZK的实例
注意因为同一台机器上的其他进程或者虚拟机他们是共享这台机器的，所以可能会影响ZK的性能(来源)

I/O是ZooKeeper的瓶颈
把ZooKeeper的存储放到自己的磁盘上
使用SSD会显著提升性能
正常情况下，Zookeeper的每次写操作都会同步到磁盘，这就导致了两次磁盘寻址操作(一次是数据，一次是数据的日志)。当所有的worker都发心跳给ZooKeeper时，可能会显著影响性能(来源)。
需要监控ZooKeeper节点的I/O负载

推荐在生产环境上运行的ZooKooper集群有至少3个节点，这样即使有一个ZooKeeper服务器挂掉了(例如进行维护)，也是可以的。

Storm安全性

原始设计Storm时，完全没有把安全性考虑在内

现在安全性能相关的功能在一步步加进来

Storm 0.9.x版本上的安全问题：
没有验证机制(authentication)，没有授权机制(authorization)
传输的数据(例如worker之间)没有加密
ZooKeeper上存储的数据没有访问限制
如果Nimbus的Thrift端口没有锁住，任意的用户代码都可以在节点上执行

更多Storm安全性方面的建议见这里

题外话：

在接触Storm之后，有个问题在我的脑海里升起，国内的大公司，比如Baidu，Ali，腾讯，都是有诞生Storm这类实时计算框架的土壤的，可是为什么没有做出来呢？

Apache Storm Basic Training
Fault tolerance

Storm in pictures

Storm 0.9 Basic Training