storm 架构篇

Storm集群，利用了分布式系统中经典的master/slave架构。以下显示的是一个Storm集群，其中master节点为Nimbus，slave节点有四个，称之为supervisor。

在传统的master/slave架构中，都是master节点负责任务的接受、分配、监控等管理任务，从节点负责任务的执行。

总的来说，storm中的主从架构，基本上也符合这个规则。(以下纯属个人理解)不过storm对这个master/slave架构有着一定的扩展：

主节点Nimbus依然是负责在集群分发任务(Topology)的代码以及监控等。

从节点Supervisor的任务有点改变，其并不是自己直接执行任务。在接受到一个任务的时候，Supervisor会启动一个或多个进程(称之为Worker)，来处理任务。所以实际上，任务最终都是分配到了worker上。

默认情况下，一个supervisor最多可以启动4个进程，也就是启动四个worker，当然我们也可以进行修改。这样设计的目的实际上是为了充分利用现代多核CPU的特性，storm是计算密集型的框架，一台机器只启动一个进程太浪费了，因此supervisor同时启动多个进程(worker)来进行处理任务。事实上，你可以这样理解，nimbus分配任务时，它是不关心有几个supervisor的，其关心的是有多少个worker，因为任务(Topology)最终都是通过worker来执行的。假设我们向Storm集群中提交一个Topology，指定由四个worker来执行。那么nimbus最终就会分配四个worker来执行这个任务，至于这个4个worker是分配在一个还是多个supervisor节点上，nimbus是不关心的。

让我们用一个案例来进行更加详细的说明：

假设我们现在有一个Storm集群，一台nimbus和4台supervisor，默认情况下，一个supervisor可以启动4个worker。因此如下图所示，我们的集群中现在有16个worker。现在我们向这个集群中提交一个Topology，指定要有4个worker来执行。图中星号标记的就是使用到的worker。

从图中，我们可以看到这四个worker分配在supervisor1(1个worker)、supervisor2(2个worker)和supervisor3(1个worker)上。可以看到，并不是一个supervisor分配一个worker。这是因为nimbus是对Topology的任务分配，是针对worker来的，我们指定了Topology要四个worker，然后我们总共有16个worker，storm只要从这个16个worker中选择四个worker就行了，并不会平均分配。这就有可能导致，选择出来的worker中，可能有些是位于同一个supervisor中的，例如案例中就有2个worker位于supervisor2上，而另外一些supervisor可能不需要执行任务，例如supervisor4。