这里做一些补充：
- worker是一个进程，由supervisor启动，并只负责处理一个topology，所以不会同时处理多个topology.
- executor是一个线程，由worker启动，是运行task的物理容器，其和task是1 -> N关系.
- component是对spout/bolt/acker的抽象.
- task也是对spout/bolt/acker的抽象，不过是计算了并行度之后。component和task是1 -> N 的关系.
supervisor会定时从zookeeper获取topologies、已分配的任务分配信息assignments及各类心跳信息，以此为依据进行任务分配。
在supervisor周期性地进行同步时，会根据新的任务分配来启动新的worker或者关闭旧的worker，以响应任务分配和负载均衡。
worker通过定期的更新connections信息，来获知其应该通讯的其它worker。
worker启动时，会根据其分配到的任务启动一个或多个executor线程。这些线程仅会处理唯一的topology。
executor线程负责处理多个spouts或者多个bolts的逻辑，这些spouts或者bolts，也称为tasks。
supervisor 和 worker 运行在相同的机器上，是不同的jvm进程
Strom集群结构是有一个主节点（nimbus）和多个工作节点（supervisor）组成的主从结构，主节点通过配置静态指定（还有一种主从结构是在运行时动态选举，比如zookeeper）。通常这种主从结构存在出现单点故障的风险，Storm通过特殊处理规避这种风险，后面将解释Storm的半容错结构。
nimbus与supervisor都是Storm提供的后台守护进程，之间的通信是结合Zookeeper的状态变更通知和监控通知来处理。如下图所示：
Storm对Zookeeper的使用相对比较轻量，不会造成很重的资源负担。单节点的Zookeeper集群能够满足大部分的需求，但是如果部署大型Storm集群，为了Storm的稳定性，就需要相对大点的Zookeeper集群。
nimbus
nimbus进程的主要职责是管理、协调和监控集群上运行的topology（包括topology的发布、任务指派、时间处理时重新指派任务等）。
topology的发布，需要将预先打成jar的topology和配置信息提交到nimbus服务器，当nimbus接收到topology压缩包，会将jar包分发到足够数量的supervisor节点上。当supervisor节点接收到topology压缩文件，nimbus就会指派task（bolt、spout实例）到每个supervisor并且发送信号指示supervisor生成足够的worker来执行指定task。
nimbus通过Zookeeper记录所有supervisor节点的状态和分配给它们的task。如果nimbus发现某个supervisor没有上报心跳或已经不可达，它将会把分配给故障supervisor的task重新分配给其他节点。
严格来讲，nimbus不会出现单点故障。这个特性是因为nimbus进程不参与topology（拓扑）的数据处理过程，仅仅是管理topology的初始化、任务分发和进行监控，所以如果nimbus在topology运行时停止，不会影响topology的运行。
supervisor
supervisor进程等待nimbus分配任务后生成并监控worker（jvm进程）执行任务。supervisor与worker运行在不同的jvm上，如果由supervisor启动的某个worker因为错误异常退出（或被kill掉），supervisor会尝试重新生成新的worker进程。
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的提交过程：
非本地模式下，客户端通过thrift调用nimbus接口，来上传代码到nimbus并触发提交操作.
nimbus进行任务分配，并将信息同步到zookeeper.
supervisor定期获取任务分配信息，如果topology代码缺失，会从nimbus下载代码，并根据任务分配信息，同步worker.
worker根据分配的tasks信息，启动多个executor线程，同时实例化spout、bolt、acker等组件，此时，等待所有connections（worker和其它机器通讯的网络连接）启动完毕，此storm-cluster即进入工作状态。
除非显示调用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