STORM_0009_Lifecycle-of-a-topology/拓扑的生命周期

时间：2016-06-03 14:15:15 阅读：140 评论：0 收藏：0 [点我收藏+]

标签：

STORM拓扑的生命周期

本页的内容基于0.7.1代码，后来又很多的变化了。

详细解释了一个拓扑的生命周期：从提交拓扑，到supervisor启停workers

也解释了Nimbus怎么监视拓扑和拓扑在被killed的时候是怎么关闭的

首先是两个说明

真实运行的拓扑和用户声明的拓扑是不一样的，真实的拓扑包含隐含的流和隐含的acker bolt去管理acking 框架(保证了数据的处理)，这个隐含的拓扑是通过system-topology!函数实现的
storm-topology!函数在两个地方被使用

Starting a topology

storm jar这个命令用特定的参数去执行你的类，这个命令执行的唯一的特别的事情是设置storm.jar环境变量，为StormSubmitter后来的使用做准备
当使用StromSubmitter.submitTopology的时候，StormSubmitter会执行下面的行动

Jar包和配置都在本地放着，因为这些文件对于zookeeper来说太大，这些文件被拷贝到{Nimbus local dir}/stormdist/{topology id}
setup-storm-static写任务-组件映射到ZK
setup-heartbeats创建ZK目录，在目录中任务可以heartbeat

master-code-dir:被supervisor使用去下载正确的jars/configs
task->node+port：一个从任务id到运行它的worker节点的映射
node->host:从node id到host的映射，使得workers知道和哪个机器去连接实现和其他worker的通信。node id被用来id supervisor，这样多个supervisor可以运行在一个机器上。
task->start-time-secs:包含一个任务和一个nimbus开始任务的时间戳的映射。这被nimbus使用来监视拓扑。

一旦拓扑被指派，它们就初始化为一个不激活的状态。start-storm写数据到Zookeeper使得cluster知道拓扑被激活了，可以从spout发射tuples。
TODO集群状态图表
Supervisor在后台运行两个函数

对于没有代码的机器，从nimbus给他们下载代码
将这个节点应当运行什么：port->LocalAssignment写到文件系统。其中LocalAssignment包含一个拓扑id也包含workers的task id列表

worker连接另外的worker，并且启动一个线程去监视变化。如果一个worker得到了重新分配，这个worker就会重连其他的worker的新的状态。
监视无论这个拓扑时候是活着的，并且将这个状态存储在storm-active-atom变量中。这个变量被任务用来去决定调用不调用spout的nextTuple方法。
worker启动多线程处理多任务

Topology Monitoring

调度经常性的任务给timer thread去检查拓扑
Nimbus的行为表现为一个有限状态机
拓扑上的监视时间在每个“nimbus.monitor.freq.secs”被调用，这个通过reassign-transition调用reassign-topology
reassign-topology调用mk-assignments，这个函数第一次也被用来分配拓扑。mk-assignments也有能力增加更新拓扑。

Killing a topology

这个time默认就是timeout但是可以被Kill -w的命令重写
导致拓扑被停止，在真实关闭的等待时间给拓扑一个机会在关闭workers之前处理正在处理的事情
在Kill 事务中改变状态保证kill协议对Nimbus崩溃是可以容忍的，一旦启动，如果拓扑的状态是killed，Nimbus调度移除事件运行wait time seconds。

标签：

原文地址：http://www.cnblogs.com/kongchung/p/5555933.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

周排行