这些天对storm源码进行了部分解读，做一个阶段性的总结。
nimbus启动过程：
sd.join();
1 验证是否是本地模式，如果是，则抛出异常，退出，否则启动nimbus
2 addHook, 增加nimbus退出时的清理工作{1, 停止线程，2 停止thrift服务，3 断开zk}
3 构造出一个nimbusData的数据结构{线程池，配置文件，上传下载文件的timeCacheMap}
4 清理之前的topology,清理的是在zk但不在本地的topo
5 初始化topologyAssgen线程，轮训机制，监控清理线程
6 设置zk上所有topo的状态为启动
7 初始化thrift网络服务
supervisor启动过程：
1 更新supervisorinfo到zk
2 每10s从zk同步一次SynchronizeSupervisor{
1 下载新的topology任务
2 release无用的work
3 启动新的task到 localstate
4 add一个syncProcessEvent
}
3 通过syncProcessEvent事件run SyncProcesses{
kill useless worker
start new worker
}
4 创建心跳线程，同步SupervisorInfo to ZK
work启动过程：
main启动入参：topology_id, supervisor_id, work_id, port (work的粒度是一个topology)
WorkerShutdown sd = mk_worker(conf, null, topology_id, supervisor_id, Integer.parseInt(port_str), worker_id);
new work(){
1 创建一个worktransfer， 一个消息发送器
2 通过这个worktransfer，创建相应的task线程
3 构造WorkerVirtualPort 当work收到tuples时，依据taskId进行分发
4 创建刷新链接，zkActive,更新heartbeat等线程
5 创建一个消息发送子组件 ，通过不同的taskId从worktransfer取各自的消息，然后发送出去，轮训执行
}
nimbus和supervisor通信走zk，而每个supervisor内部work内部通信走LocalState
work, component,exectuor,task关系：
一个Topology可以包含一个或多个worker(并行的跑在不同的machine上), 所以worker process就是执行一个topology的子集, 并且worker只能对应于一个topology
一个worker可用包含一个或多个executor, 每个component (spout或bolt)至少对应于一个executor, 所以可以说executor执行一个compenent的子集, 同时一个executor只能对应于一个component
Task就是具体的处理逻辑对象, 一个executor线程可以执行一个或多个tasks
但一般默认每个executor只执行一个task, 所以我们往往认为task就是执行线程, 其实不然
task代表最大并发度, 一个component的task数是不会改变的, 但是一个componet的executer数目是会发生变化的
当task数大于executor数时, executor数代表实际并发数