Storm Topology的生命周期过程分析

这里从提交一个topology和kill一个topology的过程来对topology的生命周期进行分析

1、提交topology，
通过StormSubmitter.submitTopology提交一个topology之后，客户端、Nimbus、Supervisor的行为如下，

Client:
Client通过Nimbus的Thrift接口上传jar到Nimbus的Inbox目录中，上传结束后，调用ThrifsubmitTopology接口正式提交了一个Topology

Nimbus:
接收到提交拓扑的命令后，对Topolopy做序列化，并建立Topolopy的静态的状态信息，
包括jar和config copy到本地目录{nimbus local dir}/stormdist/{topology id}中，
根据topology的信息在zookeeper中建立task->component的关系，在zookeeper中建立task的心跳目录。
以上静态的信息设置完成后，进入assign阶段，开始分配task到机器节点，
在zookeeper上的信息包括master-code-dir node->host task->node+port task->start-time-secs 
master-code-dir,supervisor是从Nimbus的这个位置下载jar和config信息的
task->node+port,Map taskid 到一个worker
node->host,节点到机器Hostname，node就代表supervisor，一台机器可以运行多个node
task->start-time-secs,nimbus launch 这个task的时间，用于nimbus监控这个task的hearbet是否超时（launch过程稍微长一些，launch的超时用这个nimbus.task.launch.secs限制）
assign完成以后，topology处于deactive模式，把上面的数据信息写入到zookeeper上，这样集群就可以知道该topology处于active状态，
nimnus节点就可以进行后续的动作，比如下载topology、运行发射tuple。

Supervisor：
根据assign信息，如果没有代码，那么就从nimbus下载代码，在本地保存woker的assign的数据（该woker对应的taskids等），
这个synchronize过程在zookeeper中的assign改变时发生，同时每隔10s也会做。
根据本地的这些信息，来start/stop worker。

Work,executor：
创建到其他woker的连接，并由单独的线程对连接进行监控，比如对worker重新进行了分配，那么就会自动调整连接到对应的woker上去。
监控整个topology的状态，只有处于active状态，才可以对spout进行nextTuple调用。
启动executors，一个executor对应一个线程，可以执行多个task，但是一个woker只能执行同一份spout/bolt的task。
其中每个task都会包含route的功能，根据stream和tuple返回目的地taskids。

2、Kill Topology：
通过Thrift的kill 接口发送命令给Nimbus；
nimbus收到命令后，进入了kill的流程，Topology的状态变为killed，可以对storm kill用-w参数，这将使topology变为deactive一直持续到-w的时间，
使得在真正关闭wokr前有机会把已经在运行的任务运行完成。
删除topology，清除zookeeper上的静态信息以及assign信息；
清除心跳目录和本地的jar/config目录。