首先从微观上来看: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的提交过程:
非本地模式下,客户端通过thrift调用nimbus接口,来上传代码到nimbus并触发提交操作.
nimbus进行任务分配,并将信息同步到zookeeper.
supervisor定期获取任务分配信息,如果topology代码缺失,会从nimbus下载代码,并根据任务分配信息,同步worker.
worker根据分配的tasks信息,启动多个executor线程,同时实例化spout、bolt、acker等组件,此时,等待所有connections(worker和其它机器通讯的网络连接)启动完毕,此storm-cluster即进入工作状态。
除非显示调用kill topology,否则spout、bolt等组件会一直运行。
nimbus是整个集群的控管核心,总体负责了topology的提交、运行状态监控、负载均衡及任务重新分配,等等工作。
zk就是一个管理者,监控者。
总之一句话:nimbus下命令(分配任务),zk监督执行(心跳监控,worker、supurvisor的心跳都归它管),supervisor领旨(下载代码),招募人马(创建worker和线程等),worker、executor就给我干活!其实说白了跟我们常见的军队管理是一个道理啊。
这里只是粗浅的分析了一下几者之间的关系,还没有谈论到负载均衡和任务调度,没有深入到代码层次