Storm介绍(二) Storm介绍(二)
Storm介绍(二)
转载：https://www.cnblogs.com/Jack47/p/storm_intro-2.htmlcss
本文是Storm系列之一，主要介绍Storm的架构设计，推荐读者在阅读Storm介绍(一）的基础之上，阅读这一篇。本文只是做者的读书笔记，偏重于浅层次的架构介绍，若是想真正理解内部设计时候的权衡，还须要更多的去阅读Storm源码。html
理解Storm的架构，有助于帮助咱们理解大型分布式系统设计中须要解决的问题，以及解决问题的思路，帮助咱们更好的进行Storm性能调优化。node
架构
先上一张Storm的架构图，若是熟悉 GFS和Hadoop的架构，会发现这些系统的架构图都很相似。
git
Storm架构图github
各节点的做用
若是你熟悉Hadoop的话，能够这样作一下类比：apache
| 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中初始化了以后，才能真正开始处理消息。markdown
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这类实时计算框架的土壤的，但是为何没有作出来呢？