storm中worker、executor、task之间的关系

理清一下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