理清一下worker、executor、task、supervisor、nimbus、zk这几个之间的关系

先来看一张图

（图片来自：http://www.cnblogs.com/foreach-break/p/storm_worker_executor_spout_bolt_simbus_supervisor_mk-assignments.html）

　　首先从微观上来看：worker即进程，一个worker就是一个进程，进程里面包含一个或多个线程，一个线程就是一个executor，一个线程会处理一个或多个任务，一个任务就是一个task，一个task就是一个节点类的实例对象。

　　一个worker处理topology的一个子集，同一个子集可被多个worker同时处理，一个worker有且仅为一个topology服务，不会存在一个worker即处理topology1的几个节点，又处理topology2的几个节点；一个executor处理一个节点，但这个节点可能会有多个实例对象，所以可通过配置并发度和setNumTask来配置一个executor同时处理多少个task。默认情况下一个executor就处理一个task。如果处理多个task，executor会循环遍历执行task。

　　那么一个excutor处理多个task，有什么用？一种理解的是可以方便以后扩容。首先要知道，topology代码一旦提交到nimbus上去之后，task数量随之而定，以后永不再改变，甚至重启topology，都不会再改变task数量，除非改代码，再重新提交。而设置并行度就不一样了，我们不需要重新提交代码，就可以修改topology的并发，可以随时修改。但一个executor必须要处理一个task，如果以前我们默认有4个executor，4个task，即一个executor处理一个task，好了，我现在感觉现在并发不够，处理速度跟不上，想调高一些并发，调为8个，呵呵，但task数量只有4个，多出来的executor也只是闲着，所以调高并发也没卵用了。就像这里有4个苹果，也有4个人，一个人吃一个苹果要5分钟，现在需要在5秒钟内将苹果吃完，规则是一个苹果只能被一个人吃。现在一个人吃一个，并发为4，需要5分钟，显然满足不了，于是你调高并发，叫来8个人，因为一个苹果只能被一个人吃，所以另外4个不就是干瞪眼吗？还浪费资源。所以为了方便以后调并发数，还是要设置一下task数量的。

然后再来看看宏观的storm架构，要想理清整个架构，只看概念觉得枯燥，不如来看看一个topology从提交到运行的整个过程放松一下：

一个topology的提交过程：

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等组件会一直运行。

（图片来自：http://www.cnblogs.com/foreach-break/p/storm_worker_executor_spout_bolt_simbus_supervisor_mk-assignments.html）

nimbus是整个集群的控管核心，总体负责了topology的提交、运行状态监控、负载均衡及任务重新分配，等等工作。
zk就是一个管理者，监控者。

　　总之一句话：nimbus下命令（分配任务），zk监督执行（心跳监控，worker、supurvisor的心跳都归它管），supervisor领旨（下载代码），招募人马(创建worker和线程等)，worker、executor就给我干活！其实说白了跟我们常见的军队管理是一个道理啊。

　　这里只是粗浅的分析了一下几者之间的关系，还没有谈论到负载均衡和任务调度，没有深入到代码层次，后面会相继补充。如有错误欢迎批评指正！

参考博文：http://www.cnblogs.com/foreach-break/p/storm_worker_executor_spout_bolt_simbus_supervisor_mk-assignments.html