storm 中 work executor task关系

先来一个图，看看storm的架构

   这个架构很明显能看出来，有主有从，中间靠着zk进行一些联系和调度，然后主它主要的工作就是用一个资源分配进行任务的调度，然后从呢就是接收nimbus分配的任务，当接收到任务以后supervisor在它内部会启动和暂停属于自己管理的进程，这个进程在整个storm架构里面叫做worker，然后nimbus和supervisor分别代表不同的机器。

在一个executor线程上会执行很多个task。具体的说就是ececutor是线程，task是executor处理一个或者多个任务。

zk存在的意义：nimbus和supervisor是快速失败和无状态的。

         worker中每一个spout bolt的线程成为一个task

每一个spout和bolt会被当作很多task在整个集群里执行

每一个executor对应一个线程，在这个线程里运行多个task

这个图描述了三者之间的关系

一个worker进程执行的是一个topology的子集。不会存在一个worker为多个topology服务

一个worker进程会启动一个或多个executor线程来执行一个topology的compotent 也就是spout或者bolt

一个topology就是由于集群中的多台物理机上的worker构成的

一个executor是一个被worker进程启动的单独线程，每一个ececutoy都只会运行一个topology的component 

work》executor。tak 要想提高storm的并行度可以从三个方面来改造，worker》executor》task 增加work进程，增加executor线程，增加task实例。

来一段程序来说明吧：

    TopologyBuilder builder = new TopologyBuilder();
    builder.setSpout("spout", new RandomSentenceSpout(), 5).setNumTasks(4);    
    builder.setBolt("split", new SplitSentence(), 8).shuffleGrouping("spout");  
    builder.setBolt("count", new WordCount(), 4).fieldsGrouping("spout", new Fields("ming"));   

    Config conf = new Config();
    conf.setDebug(false);

    conf.setNumWorkers(3);                             
    StormSubmitter.submitTopology("word-count", conf, builder.createTopology());

　　一个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的提交过程：


非本地模式下，客户端通过thrift调用nimbus接口，来上传代码到nimbus并触发提交操作.nimbus进行任务分配，并将信息同步到zookeeper.supervisor定期获取任务分配信息，如果topology代码缺失，会从nimbus下载代码，并根据任务分配信息，同步worker.worker根据分配的tasks信息，启动多个executor线程，同时实例化spout、bolt、acker等组件，此时，等待所有connections（worker和其它机器通讯的网络连接）启动完毕，此storm-cluster即进入工作状态。除非显示调用kill topology，否则spout、bolt等组件会一直运行。

     nimbus下命令（分配任务），zk监督执行（心跳监控，worker、supurvisor的心跳都归它管），supervisor领旨（下载代码），招募人马(创建worker和线程等)，worker、executor就给我干活！