Storm_Storm solt资源不够,再次提交topo / storm 分发任务 浅谈

原文： http://www.tuicool.com/articles/7Fbe6nJ

Storm集群的资源是有限的，如果达到资源使用的临界点，会发生什么？

之前参考了不少资料，但都没有解释这个问题，这段时间不少朋友都问道这个问题，下面通过例证说明该现象。首先将之前一些资料做一些罗列：

资料1：

任务分配时 有两种情况：

  (a)task数目比worker多，例如task是[1 2 3 4],可用的slot只有[host1:port1 host2:port1]，那么最终是这样分配

{1: [host1:port1] 2 : [host2:port1]3 : [host1:port1] 4 : [host2:port1]}

可以看到任务平均地分配在两个worker上。

(b)如果task数目比worker少，例如task是[1 2]，而worker有[host1:port1 host1:port2 host2:port1 host2:port2]，那么首先会将woker排序，  将不同host间隔排列

，保证task不会全部分配到同一个机器 上，也就是将worker排列成

[host1:port1 host2:port1 host1:port2 host2:port2]

然后分配任务为

{1: host1:port1 , 2 : host2:port1}

资料2：

在Pluggable Scheduler之前，Twitter Storm里面对于用户提交的每个Topology进行任务分配是由nimbus来做的，nimbus的任务分配算法可是非常牛逼的哦，主要特点如下

• 在slot充沛的情况下，能够保证所有topology的task被均匀的分配到整个机器的所有机器上
• 在slot不足的情况下，它会把topology的所有的task分配到仅有的slot上去，这时候其实不是理想状态，所以。。
  • 在nimbus发现有多余slot的时候，它会重新分配topology的task分配到空余的slot上去以达到理想状态。
• 在没有slot的时候，它什么也不做

接下来，开始例证内容：

1. 集群情况

• 1 supervisor
• 4个slot
• 1GB mem/slot

2. 提交任务

顺序提交两个主要任务（等第1个任务开始正常运行后提交第2个）：

bin/storm jar examples/storm-starter/storm-starter-topologies-0.9.3.jar storm.starter.ExclamationTopology "ex"

bin/storm jar examples/storm-starter/storm-starter-topologies-0.9.3.jar storm.starter.WordCountTopology "wc"

提交截图如下：

可以看到：

第1个任务ex也正常运行，使用3个worker，即3个slot。

第2个任务wc正常运行，默认1个worker，即1个slot。

这是wc正常运行的截图：

3. 提交第3个任务

bin/storm jar examples/storm-starter/storm-starter-topologies-0.9.3.jar storm.starter.WordCountTopology "wc2"

该任务也是wordcount，但topo名字不同。

提交后截图如下：

4. Topo运行状态

1）ex运行正常

第1个运行，占用3个slot，运行正常，默认也是3个slot。

（2）wc运行正常

第2个运行，占用1个slot，但默认是启动3个slot。由于ex拓扑占用3个slot，总量是4，所以整个storm集群剩余slot是1个，wc只能有1个slot。 slot=worker，worker中可以运行多个executor，这里占用28个exeutors也就是28个线程，原则上，worker可以启动无限多个executor（资源足够的情况下）。所以，使用1个worker/slot处理这个拓扑是没问题的。

so，这也就是说明了，如果资源不足，新Topo申请资源时，会压缩配置，使用尽量理想的情况运行拓扑。

（3）wc2没有运行

第3个拓扑，因为集群没有任何资源slot，而同一个slot只能同时运行一个拓扑的任务，所以它只能等待，但是不会消亡，也不会提交不成功或者运行中失败。

那么就愉快的结束例证演示了。