Storm元数据交互详解

一、Nimbus

Nimbus既需要在Zookeeper中创建元数据，也需要从Zookeeper中获取元数据。

如上图箭头1所示：

1、对于路径a，Nimbus只会创建路径，不会设置数据，数据是稍后由Worker设置的。

2、对于路基b和c，Nimbus在创建她们的时候就会设置数据。

3、路径a和b只有在提交新的Topology时才会创建，且b中的数据设置好以后就不会再变化；c在第一次为该Topology进行任务分配的时候会创建，若任务分配计划有变，Nimbus会更新它内容。

如上图箭头2所示：

1、Nimbus需要从路径a读取当前已经被分配的Worker的运行状态。根据该信息，Nimbus可以得知哪些Worker状态正常，哪些需要被重新调度。同时还会获取到该Worker上所有的Executor信息，这些信息会通过UI呈现给用户。

2、从路径b可以获取当前集群中所有Supervisor状态，通过这些信息可以得知哪些Supervisor上还有空闲资源可用，哪些Supervisor不再活跃，需要将已经分配到它的任务分配到其他节点上。

3、从路径c上可以获取当前所有的错误信息并通过UI展现给用户。

二、Supervisor

Supervisor也需要通过Zookeepr来创建和获取元数据。除此之外，Supervisor还通过监控指定的本地文件来监测由它启动的所有的Worker的运行状态。

1、箭头3表示Supervisor在Zookeeper中创建的路径是/storm/supervisor/<supervisor-id>。新节点加入时会在该路径下创建一个znode节点。值得注意的是，该节点是一个临时节点，一旦Supervisor与Zookeepr的连接超时或断开，该节点会被自动删除。该目录下的znode节点列表代表了目前活跃的Supervisor，这保证了Nimbus能够及时得知当前集群中机器的状态，这是Nimbus可以进行任务分配的基础，也是Storm具有容错性以及扩展性的基础。

2、箭头4表示Supervisor需要获取数据的路径是/storm/assignments/<topology-id>。这个路径是Nimbus写入的对Topology的任务分配信息，Supervisor从该路径可以获取到Nimbus分配给它的所有任务。Supervisor在本地保存了上次的分配信息，对比这两部分的信息可以得知分配信息是否有变化。若发生变化，则需要进行任务的移除和启动。

3、箭头9表示Supervisor会从LocalState中获取由它启动的所有Worker的心跳信息。Supervisor每隔一段时间检查一次这些心跳信息，如果发现某个Worker在这段时间内没有更新心跳信息，表明该Worker当前的运行状态出了问题。这时Supervisor会杀死这个Worker（Worker本质是一个进程），原本分配给这个Worker的任务就会被重新分配。

三、Worker

Worker也需要利用Zookeeper来创建和获取元数据，同时它还需要利用本地的文件来记录自己的心跳信息。

1、箭头5表示Worker在Zookeeper中创建的路径是/storm/workerbeats/<topology-id>/node-port。在Worker启动时，将创建一个与其对应的znode节点，相当于对自身进行注册。需要注意的是，Nimbus在Topology被提交时只会创建路径/storm/workerbeats/<topology-id>，而不会设置数据，数据则等Worker启动之后由Worker创建。这样安排的目的之一是为了避免多个Worker同时创建路径时导致冲突。

2、箭头6表示Worker需要获取/storm/assignments/<topology-id>路径的数据，这里包含分配给它的任务信息。

3、箭头8表示Worker在LocalState中保存心跳信息。LocalState实际上将这些信息保存在本地文件中，Worker用这些信息与Supervisor保持心跳，每隔几秒钟需要更新一次心跳信息。因为Worker与Supervisor属于不同的进程，因此Storm采用本地文件的方式来传递心跳。

四、Executor

Executor只会利用Zookeeper来记录自己的运行错误信息。箭头7表示Executor在Zookeeper中创建的路径，每个Executor会在运行过程中记录发生的错误。

五、心跳维持

由上可知，Nimbus、Supervisor和Worker两两之间都要维持心跳信息，它们的心跳信息如下：

1、Nimbus和Supervisor之间通过/storm/supervisor/<supervisor-id>路径对应的数据进行心跳保持。该节点是临时节点，只要Supervisor死掉，对应路径的数据就会被删掉，Nimbus就会将原本分配给改Supervisor的任务重新分配。

2、Worker和Nimbus之间通过/storm/workerbeats/<topology-id>/node-port路径中的数据进行心跳维持。Nimbus会每隔一段时间获取该路径下的数据，同时Nimbus还会在它的内存中保存上一次的信息。如果发现某个Worker的心跳信息有一段时间没有更新，就认为该worker已经死掉了，Nimbus会对任务进行重新分配，将分配到该Worker的任务分配给其他的Worker。

3、Worker与Supervisor之间通过本地文件（LocalState）进行心跳保持。