storm 第二篇

第一篇说一下nimbus和supervisor以及worker之间的关系

这一篇重要讲解这三者之间如何通过zookeeper通信的

上一篇没有说当zookeeper故障时会如何，在上一篇实际模型中zookeeper担任着nimbus与supervisor中的通信，nimbus与worker中间的通信，如果zookeeper死亡，那么这些通信都无法进行，这是一个单点故障，但是在实际的开发中zookeeper都会配置集群，所以不用担心zookeeper的问题。

我们先通过zookeeper的UI界面看看在真实的环境中时怎么样的

先看看我们不太需要关注的节点:当使用zookeeper的时候都是需要在zookeeper中注册的

/storm/nimbus这个节点  代表着nimbus node基础信息

/storm/leader-lock   所有nimbus的顺序标志 最小号为leader

/storm/blobstoremaxkeysequencenumber  记录了topology的文件名jar(storm代码可以install为jar然后在集群中运行),conf配置和code代码

/storm/blobstore  记录了上面文件名所在备份的nimbus node 地址

code备份所在的端口号地址  conf和code所在地址是一样的

/storm/credentials  保存了每一个topology的安全信息   topology-id  simple-1-1515649042 

然后我们看看 topology在zookeeper中的节点情况，看看我们需要重点关注的节点

在看看总体的交互图: 这张图是从源码解析中copy出来的   这部分我们联系实际的zkui界面来说

1. NimbusNimbus既需要在ZooKeeper中创建元数据，也需要从ZooKeeper中获取元数据。

下面简述图1-4中箭头1和箭头2的作用。

箭头1表示由Nimbus创建的路径，包括：

a. /storm/workerbeats/<topology-id>

其中对于路径a，Nimbus只会创建路径，不会设置数据（ 数据是由Worker设置的，后面会介绍 ）；

b./storm/storms/<topology-id>  在创建b路径时会设置好数据   value为设置的数据  它存储Topology本身的信息，包括它的名字、启动时间、运行状态、要使用的Worker数目以及每个组件的并行度设置。它的内容在运行过程中是不变的。

c. /storm/assigninents/<topology-id>   第一次为该Topology进行任务分配的时候创建数据，它存储了Nimbus为每个Topology分配的任务信息，包括该Topology在Nimbus机器本地的存储目录、被分配到的Supervisor机器到主机名的映射关系、每个Executor运行在哪个Worker上以及每个Executor的启动时间。该节点的数据在运行过程中会被更新。

其中对于路径a，Nimbus只会创建路径，不会设置数据（ 数据是由Worker设置的，后面会介绍 )对于路径b和c，Nimbus在创建它们的时候就会设置数据。a和b只有在提交新Topology的时候才会创建，且b中的数据设置好后就不再变化，c则在第一次为该Topology进行任务分配的时候创建，若任务分配计划有变，Nimbus就会更新它的内容。

箭头2表示Nimbus需要获取数据的路径，包括：

a./storm/workerbeats/<topology-id>/node-port    它存储由node和port指定的Worker的运行状态和一些统计信息，主要包括storm-id ( 也即topology-id )、当前Worker上所有Executor的统计信息（ 如发送的消息数目、接收的消息数目等）、当前Worker的启动时间以及最后一次更新这些信息的时间。在一个topologyid下面，可能有多个node-port节点。它的内容在运行过程中会被更新。这部分数据是由worker创建的，每有一个worker就会有一个节点。

b./storm/supervisors/<topology-id>  它存储Supervisor机器本身的运行统计信息，主要包括最近一次更新时间、主机名、supervisor-id、已经使用的端口列表、所有的端口列表以及运行时间。该节点的数据在运行过程中也会被更新。 这部分数据是由supervisor写入的  从图中可以看出有两个supervisor在工作

c./storm/errors/<topology-id>/<commpont-id>/e<sequential-id>  这部分数据是由executor写入的，可以获取当前所有的错误信息并通过UI呈现给用户

Nimbus需要从路径a读取当前已被分配的Worker的运行状态。根据该信息，Nimbuss可以得知哪些Worker状态正常，哪些需要被重新调度，同时还会获取到该Worker所有Executor统计信息，这些信息会通过UI呈现给用户。从路径b可以获取当前集群中所有Supervisor的状态，通过这些信息可以得知哪些Supervisor上还有空闲的资源可用，哪些Supervisor则已经不再活跃，需要将分配到它的任务分配到其他节点上。从路径c上可以获取当前所有的错误信息并通过UI呈现给用户。集群中可以动态增减机器，机器的增减会引起ZooKeeper中元数据的变化，Nimbus通过不断获取这些元数据信息来调整任务分配，故Storm具有良好的可扩展性。当Nimbus死掉时，其他节点是可以继续工作的，但是不能提交新的Topology , 也不能重新进行任务分配和负载调整，因此目前Nimbus还是存在单点的问题。

2. Supervisor

同Nimbus类似，Supervise也要通过ZooKeeper来创建和获取兀数据。除此之外，Supervisor还通过监控指定的本地文件来检测由它启动的所有Worker的运行状态。下面简述图1 -4中箭头3 、箭头4和箭头9的作用。

/storm/supervisors/<supervisor-id>    新节点加人时，会在该路径下创建一个节点。

箭头3表示Supervisor在ZooKeeper中创建的路径是/storm/supervisors/<supervisor-id>。新节点加人时，会在该路径下创建一个节点。值得注意的是，该节点是一个临时节点（ 创建ZooKeeper节点的一种模式），即只要Supervisor与ZooKeeper的连接稳定存在，该节点就一直存在；一旦连接断开，该节点则会被自动删除。该目录下的节点列表代表了目前活跃的机器。这保证了Nimbus能及时得知当前集群中机器的状态，这是Nimbus可以进行任务分配的基础，也是Storm具有容错性以及可扩展性的基础。

/storm/assignments/<topology-id>  从zookeeper上面获取关于topology的信息，然后做出反应

箭头4表示Supervisor需要获取数据的路径是/storm/assignments/<topology-id>。我们知道它是Nimbus写人的对Topology的任务分配信息，Supervisor从该路径可以获取到Nimbus分配给它的所有任务。Supervisor在本地保存上次的分配信息，对比这两部分信息可以得知分配信息是否有变化。若发生变化，则需要关闭被移除任务所对应的Worker , 并启动新的Worker执行新分配的任务。Nimbus会尽量保持任务分配的稳定性。

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

3. Worker

Worker也需要利用Zookeeper来创建和获取元数据，同时它还需要利用本地的文件来记录自己的心跳信息。下面简述图4-1中箭头5、箭头6和箭头8的作用。

/storm/workerbeats/<topology-id>/node-port  有几个worker就会有几个节点 worker数量可以设定

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

/storm/assignments/<topology-id>  第一次为该Topology进行任务分配的时候创建数据，它存储了Nimbus为每个Topology分配的任务信息，包括该Topology在Nimbus机器本地的存储目录、被分配到的Supervisor机器到主机名的映射关系、每个Executor运行在哪个Worker上以及每个Executor的启动时间。该节点的数据在运行过程中会被更新

箭头6表示Worker需要获取数据的路径是/storm/assignments/<topology-id>,Worker会从这些任务分配信息中取出分配给它的任务并执行。

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

4. ExecutorExecutor只会利用ZooKeeper来记录自己的运行错误信息，下面简述图4-1中箭头7的作用。

箭头7表示Executor在ZooKeeper中创建的路径是/storm/errors/<topology-id>/<commpont-id>/e<sequential-id>。每个Executor会在运行过程中记录发生的错误。

5. 小结从前面的描述中可以得知，Nimbus 、Supervisor以及Worker两两之间都需要维持心跳信息，它们的心跳关系如下:

Nimbus和Supervisor之间通过/storm/supervisors/<supervisors-id>路径对应的数据进行心跳保持。Supervisor创建这个路径时釆用的是临时节点模式，所以只要Supervisor死掉，对应路径的数据就会被删掉，Nimbus就会将原本分配给该Supervisor的任务重新分配。

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

Worker跟Supervisor之间通过本地文件（ 基于LocalState ) 进行心跳保持。