storm教程（一）：storm基本概念和集群架构

一、storm 基本概念
对比Hadoop的批处理，Storm是个实时的、分布式以及具备高容错的计算系统。同Hadoop一样Storm也可以处理大批量的数据，然而Storm在保证高可靠性的前提下还可以让处理进行的更加实时；也就是说，所有的信息都会被处理。Storm同样还具备容错和分布计算这些特性，这就让Storm可以扩展到不同的机器上进行大批量的数据处理。他同样还有以下的这些特性：
易于扩展。对于扩展，你只需要添加机器和改变对应的topology（拓扑）设置。Storm使用Hadoop Zookeeper进行集群协调，这样可以充分的保证大型集群的良好运行。
每条信息的处理都可以得到保证。
Storm集群管理简易。
Storm的容错机能：一旦topology递交，Storm会一直运行它直到topology被废除或者被关闭。而在执行中出现错误时，也会由Storm重新分配任务。
尽管通常使用Java，Storm中的topology可以用任何语言设计。

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

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

总的来说，storm中的主从架构，基本上也符合这个规则。(以下纯属个人理解)不过storm对这个master/slave架构有着一定的扩展：
1、主节点Nimbus依然是负责在集群分发任务(Topology)的代码以及监控等。

2、从节点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。
要注意的是：一个worker同时只能运行一个Topology。如果此时我们想提交另外一个Topology，不管指定使用几个worker来执行，都只能在剩余的12个worker中来选择了！