<h4>前言：</h4>
因为前面讲个那3个demo都是local topology运行，所以对storm集群状态下的工作情况没有介绍太多，写面我们来详细描述一下。
<h4>一、集群状态管理及工作调度</h4>
storm的集群表面上看和hadoop的集群非常像。但是在Hadoop上面你运行的是MapReduce的Job, 而在Storm上面你运行的是Topology。它们是非常不一样的一个关键的区别是： 一个MapReduce Job最终会结束， 而一个Topology运永远运行（除非你显式的杀掉他）。
在storm的集群里面有两种节点： 控制节点(master node)和工作节点(worker node)。控制节点上面运行一个后台程序：Nimbus， 它的作用类似Hadoop里面的JobTracker。Nimbus负责在集群里面分布代码，分配工作给机器， 并且监控状态。每一个工作节点上面运行一个叫做Supervisor的应用（类似 TaskTracker）。Supervisor会监听分配给它那台机器的工作，根据需要 启动/关闭工作进程。每一个工作进程执行一个Topology（类似 Job）的一个子集；一个运行的Topology由运行在很多机器上的很多工作进程 Worker（类似 Child）组成。
<pre>
</pre>
<b>集群状态管理：</b>
集群的状态是通过一个storm-cluster-state的对象来描述的。
其提供了许多功能接口，比如：
1、zookeeper相关的基本操作，如create-node、set-data、remove-node、get-children等.
2、心跳接口，如supervisor-heartbeat!、worker-heatbeat!等.
3、心跳信息，如executors-beats等.
4、启动、更新、停止storm，如update-storm!等.
<b>任务调度：</b>
1、zookeeper是整个集群状态同步、协调的核心组件。
2、supervisor、worker、executor等组件会定期向zookeeper写心跳信息
3、当topology出现错误、或者有新的topology提交到集群时，topologies信息会同步到zookeeper。
4、nimbus会定期监视zookeeper上的任务分配信息assignments，并将重新分配的计划同步到zookeeper。
所以，nimbus会根据心跳、topologies信息及已分配的任务信息为依据，来重新分配任务。
<h4>二、supervisor的工作原理：</h4>
<pre>
</pre>
1、worker是一个进程.
2、executor是一个线程，是运行tasks的物理容器.
3、task是对spout/bolt/acker等任务的逻辑抽象.
supervisor会定时从zookeeper获取拓补信息topologies、任务分配信息assignments及各类心跳信息，以此为依据进行任务分配。在supervisor同步时，会根据新的任务分配情况来启动新的worker或者关闭旧的worker并进行负载均衡。worker通过定期的更新connections信息，来获知其应该通讯的其它worker。worker启动时，会根据其分配到的任务启动一个或多个executor线程。这些线程仅会处理唯一的topology。 如果有新的tolopogy被提交到集群，nimbus会重新分配任务。executor线程负责处理多个spouts或者多个bolts的逻辑，这些spouts或者bolts，也称为tasks。具体有多少个worker，多少个executor，每个executor负责多少个task，是由配置和指定的parallelism-hint共同决定的，但这个值并不一定等于实际运行中的数目。如果计算出的总的executors超过了nimbus的限制，此topology将不会得到执行。
<h4>三、topology提交过程</h4>
1.非本地模式下，客户端通过thrift调用nimbus接口，来上传代码到nimbus并触发提交操作.
2.nimbus进行任务分配，并将信息同步到zookeeper.
3.supervisor定期获取任务分配信息，如果topology代码缺失，会从nimbus下载代码，并根据任务分配信息，同步worker.
4.worker根据分配的tasks信息，启动多个executor线程，同时实例化spout、bolt、acker等组件，此时，等待所有connections（worker和其它机器通讯的网络连接）启动完毕，此storm-cluster即进入工作状态。
5.除非显示调用kill topology，否则spout、bolt等组件会一直运行。
