strom之nimbus

Storm

Storm的主线主要包括4条：nimbus, supervisor, worker和task。

Nimbus

要了解nimbus的具体做的操作，可以从提交一个topology的流程开始。

1.1  Prepare

Nimbus启动时候，运行了一个Thrift Server。它会在topology提交之前做以下四个工作。

      (1)  清理一些中断了的topology(nimbus目录下/storm.local.dir/stormdist下存在，zk中            storms/topologyid中不存在的topology): 删除ZK上相关信息(清理tasks/topologyid; storms/topologyid; assignments/topologyid这个三个目录)。

      (2)  将storms/下所有的topology设置为启动状态: 能转换成startup状态的两种状态分别是：killed和rebalancing。nimbus的状态转换是很有意思的事情，killed状态的topology在nimbus启动的时候会被干掉；rebalancing状态的topology在nimbus启动的时候会重新分发任务，状态会变成rebalancing的上一个状态。

 

举例： 当某个topology提交的时候，会被设置成active状态，假设storm集群增加机器了,你希望重新分发任务，可以将状态转换成rebalance状态，转换成这个状态要做这几件事：

首先，启动一个延迟TOPOLOGY-MESSAGE-TIMEOUT-SECS秒执行的事件，将当前状态转换成do-rebalance状态，在这之前会将当前topology的状态设置成rebalancing状态(注意设置和转换的区别，设置就是指将ZK上存储的topology的状态进行重新设置)。

然后，将rebalancing的状态转换成do-rebalance, 也就是将任务重新分发。

最后将状态设置成rebalancing的上一个状态active。

      (3) 每间隔NIMBUS-MONITOR-FREQ-SECS长时间将ZK上/storms 下所有的topology状态转换成monitor状态，并且将不活跃的storm清理掉。只有当状态为active和inactive的时候，才能转换成monitor状态，转换成该状态就是将任务重新分发，监控是否与上一次的分配情况不同，如果存在不同，则替换,这个过程ZK上存储的topology的状态是不会被设置的。

 

      (4)  删除过期的jar包: 过期时间为NIMBUS-INBOX-JAR-EXPIRATION-SECS。每间隔NIMBUS-CLEANUP-INBOX-FREQ-SECS长时间进行一次清理。

1.2  Submit topology

1.2.1  Submit

以下是提交一个topology的执行流程概述

      (1)  检查：检查所提交的topology是否已经是active状态，如果是，抛出异常。

      (2)  计数器：计数器+1，用来计算共提交了多少topology。

      (3)  为这个topology生一个id。

      (4)  计算要启动的acker的相关信息，每个acker都是一个bolt。根据配置的信息获取并发数等。

      (5) 获取topology的code和config。

      (6) 为该topology建立心跳目录(ZK:storm-zk-root/taskbeats/topologyid)。

      (7) 为该topology分配任务。

      (8) 设置storm状态为active。

1.2.2 Task assigned

这个是nimbus的重点，分配任务的流程：

(1)  获取所有的node+port：分配任务的目的就是将tasks分配到具体的node+port。

2)   获取该topology已经分配了的任务(如果是新提交的topology，则为空)。

(3)  为每个需要分配的task分配到具体node+port。合并(1)和(2)中所有的node和port。具体为什么要这样，还不是很清楚。因为通过(1)应该是可以获取所有的node+port。

(4)  将2)中需要重新分配的task的启动时间不变，其他新分配的任务的时间设置为当前时间。

(5)   将以上的信息Assignment写入到ZK中。

       1.2.3          scratch?

分配任务主要分为两种情况，代码中用scratch?来标识两种不同的情况(正常的分配任务和rebalance状态转换)。1.2.2中所说的需要分配的任务暗指此处的两种任务分配情况。

(1)     rebalance状态转换

这种原因导致的重新分发任务，与正常的分配任务的区别在于两点：

第一：所有的任务都认为是活跃任务，即认为任务心跳都未超时。

第二：所有的任务都需要重新分配，即认为所有端口都是空闲的端口，允许被分配任务。

举例说明：

假设：提交的topology确定有10个task, taskid分别为1,2,3,…10。有两个supervisor(n

ode1和node2)，每个supervisor可用的端口号为{6001, 6002, 6003}。

 

分配任务的目标是尽可能负载均衡，即每个node均衡，每个端口均衡, rebalance情况

下分配的结果为：

tasked

node+port

1、7

node1:6001

3、9

node1:6002

5

node1:6003

2、8

node2:6001

4、10

node2:6002

6

node2:6003

 

(2) 正常分配任务：

正常分配任务比rebalance多考虑两个问题，考虑task的心跳是否超时和哪些端口上分配的任务是符合负载均衡的，可以不需要重新分发。所以要重新分发的task是那些心跳超时和所在端口没有分配均衡的那些任务。

 

nimbus用了一个叫task-heartbeat-cache来存储task的心跳时间，而不是直接用写入到zk上的心跳时间，这么做的目的是防止各个node上面的时间不同步。

 

举例说明：

假设提交的topology，跟上个例子相同。确定有10个task, taskid分别为1,2,3,…10。有两个supervisor(node1和node2)，每个supervisor可用的端口号为{6001, 6002, 6003}。

首先，重新分配任务时，会先判断心跳超时的task，假设task1和task6心跳超时，task1和task6需要重新分配。

然后，判断哪些端口的分配是符合负载均衡的要求。 判断过程是这样的：共10个task，6个端口，按照负载均衡原则，应该是4个端口上分配两个task，2个端口上分配1个task。依次判断哪些端口不符合要求。如果按顺序来判断，node1:6001和node2:6002是不符合要求的，他们应该要被分别分配2个任务。所以两个端口的任务也需要重新分发。

最后，确定要重新分发的任务是1、4、7和10，可用的端口号是node1:6001和node2:6002。

按照每个node均衡，每个端口均衡的分配原则，分配结果如下：

tasked

node+port

1、7

node1:6001

4、10

node2:6002