我们知道Twitter Storm的所有的状态信息都是保存在Zookeeper里面，nimbus通过在zookeeper上面写状态信息来分配任务，supervisor，task通过从zookeeper中读状态来领取任务，同时supervisor, task也会定义发送心跳信息到zookeeper， 使得nimbus可以监控整个storm集群的状态， 从而可以重启一些挂掉的task。ZooKeeper 使得整个storm集群十分的健壮 — 任何一台工作机器挂掉都没有关系，只要重启然后从zookeeper上面重新获取状态信息就可以了。
本文主要介绍Twitter Storm在ZooKeeper中保存的数据目录结构，源代码主要是: backtype.storm.cluster。
一个要注意的地方是，作者在代码里面很多地方用到的storm-id, 其实就是topology-id的意思。我在邮件列表里面问了他一下， 他说以前他把topology叫做storm, 代码里面还没有改过来。
直接看下面的结构图：
1 /-{storm-zk-root} -- storm在zookeeper上的根
2 | 目录
3 |
4 |-/assignments -- topology的任务分配信息
5 | |
6 | |-/{topology-id} -- 这个下面保存的是每个
7 | topology的assignments
8 | 信息包括： 对应的
9 | nimbus上的代码目录,所有
10 | task的启动时间,
11 | 每个task与机器、端口的映射
12 |
13 |-/tasks -- 所有的task
14 | |
15 | |-/{topology-id} -- 这个目录下面id为
16 | | {topology-id}的topology
17 | | 所对应的所有的task-id
18 | |
19 | |-/{task-id} -- 这个文件里面保存的是这个
20 | task对应的component-id：
21 | 可能是spout-id或者bolt-id
22 |
23 |-/storms -- 这个目录保存所有正在运行
24 | | 的topology的id
25 | |
26 | |-/{topology-id} -- 这个文件保存这个topology
27 | 的一些信息，包括topology的
28 | 名字，topology开始运行的时
29 | 间以及这个topology的状态
30 | (具体看StormBase类)
31 |
32 |-/supervisors -- 这个目录保存所有的supervisor
33 | | 的心跳信息
34 | |
35 | |-/{supervisor-id} -- 这个文件保存的是supervisor
36 | 的心跳信息包括:心跳时间，主
37 | 机名，这个supervisor上worker
38 | 的端口号运行时间
39 | (具体看SupervisorInfo类)
40 |
41 |-/taskbeats -- 所有task的心跳
42 | |
43 | |-/{topology-id} -- 这个目录保存这个topology的所
44 | | 有的task的心跳信息
45 | |
46 | |-/{task-id} -- task的心跳信息，包括心跳的时
47 | 间，task运行时间以及一些统计
48 | 信息
49 |
50 |-/taskerrors -- 所有task所产生的error信息
51 |
52 |-/{topology-id} -- 这个目录保存这个topology下面
53 | 每个task的出错信息
54 |
55 |-/{task-id} -- 这个task的出错信息
