作者:Jack47

转载请保留作者和原文出处

欢迎关注我的微信公众账号程序员杰克，两边的文章会同步，也可以添加我的RSS订阅源。

本文是Storm系列之一，主要介绍Storm的架构设计，推荐读者在阅读Storm介绍(一）的基础之上，阅读这一篇。本文只是作者的读书笔记，偏重于浅层次的架构介绍，如果想真正理解内部设计时候的权衡，还需要更多的去阅读Storm源码。

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

架构#

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

Storm架构图

各节点的作用##

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

Hadoop | Storm | 在Storm中发挥的作用|

----------|-------

JobTracker|Nimbus(只有一个)|

在集群中分发代码
给Slave机器/supervisor分配任务
失败检测(failure monitoring)
快速失败(fail fast)，无状态的(可以kill -9)

TaskTracker|Supervisor（有很多个)|

监听分配到自己所在机器的工作
根据Nimbus的指示来起停worker进程
快速失败，无状态的(可以kill -9)

MapReduce任务 | Topology |

一直处理消息(直到你kill它)
一个运行中的拓扑包含分散在很多机器上运行的多个worker进程

可以看到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负载