实现步骤：
- 安装和配置jdk
- 安装和配置zookeeper
- 上传和解压storm
- 配置storm安装目录conf目录下的storm.yaml文件
storm.yaml配置示例：
注意配置项开头需要有空格，：后面需要跟空格，否则启动会报错
5.在storm安装目录下创建tmp目录
Storm配置说明
以下为必须修改的项：
1）storm.zookeeper.services:配置zookeeper集群的主机名称。
2）nimbus.host:指定了集群中nimbus的节点
3）supervisor.slots.ports:配置控制每个supervisor节点运行多少个worker进程。这个配置定义为
worker监听的端口的列表，监听端口的个数控制了supervisor节点上有多少个worker的插槽。
默认的storm使用6700~6703端口，每个supervisor节点上有4个worker插槽。
4）storm.local.dir:storm工作时产生的工作文件存放的位置，注意，要避免配置到/tmp下。
其他可选的常用修改项：
1）ui.port（default：8080）：这项配置指定了Storm UI的Web服务器监听的端口。
2）topology.message.timeout.secs（default：30）：这个配置项设定了一个tuple树需要
应答最大时间秒数限制，超过这个时间的认为已经执行失败（超时）。这个值设置得太小可能
会导致tuple反复重新发送。当这个选项生效时，spout必须设定来发送锚定的tuple。
3）topology.max.spout.pending（default：null）：在默认值null的时候，每当spout产生
了新的tuple，Storm会立即将tuple向后端数据流发送。
注：由于下游bolt执行可能有延迟，默认的数据发送行为可能导致topology过载，从而导致
消息处理超时。将本选项设置为非null大于0的数字时，Storm会暂停发送tuple到数据流直到
发送出去的tuple小于这个数字，起到了对spout限速的作用。这项配置和
topology.message.timeout.secs一起，是调节topology性能的最重要的两个参数。
Storm集群的启动
实现步骤：
进入第一台虚拟机的storm安装目录下的bin目录
- 启动nimbus 后台进程
执行：./storm nimbus >/dev/null 2>&1 &
- 启动supervisor 后台进程
执行：./storm supervisor >/dev/null 2>&1 &
- 启动 ui 后台进程
执行：./storm ui >/dev/null 2>&1 &
最后通过jps查看所有进程：
- 进入02,03虚拟机，启动supervisor进程
- 通过浏览器，访问01虚拟机的8080端口，进入ui管理页面
注意事项：ui进程必须和nimbus进程在同一台物理机上
Storm命令
–启动命令
**在启动storm之前确保storm使用的zookeeper已经启动且可以使用
1）storm nimbus
启动nimbus守护进程
2）storm supervisor
启动supervisor守护进程
3）storm ui
启动stormui的守护进程，从而可以通过webUI界面来监控storm运行过程
4）storm drpc
启动一个DRPC服务守护进程
–管理命令
1）storm jar topology_jar topology_class[arguments…]
向集群提交topology。它会使用指定的参数运行topology_class中的main()方法，同时上传
topology_jar文件到nimbus以分发到整个集群。提交后，Storm集群会激活并且开始运行
topology。topology中的main()方法需要调用StormSubmitter.submitTopology()方法，并且为
topology提供集群内唯一的名称。
2）storm kill topology_name[-w wait_time]
用来关闭已经部署的topology。
3）storm deactivate topology_name
停止指定topology的spout发送tuple
4）storm activate topology_name
恢复指定topology的spout发送tuple。
5）storm rebalance topology_name[-w wait_time][-n worker_count][-e
component_name=executor_count]
指定storm在集群的worker之间重新平均地分配任务，不需要关闭或者重新提交现有的
topology。当执行rebalance命令时，Storm会先取消激活topology，等待配置的的时间使剩
余的tuple处理完成，然后再supervisor节点中均匀的重新分配worker。重新分配后，Storm
会将topology恢复到之前的激活状态。
6）storm remoteconfvalue conf-name
用来查看远程集群中的配置参数值。
集群下运行Wordcount
实现步骤：
- 更改wordcountTopology的提交模式为集群模式
示例代码
public static void main(String[] args) throws Exception {
Config config=new Config();
LocalCluster cluster=new LocalCluster();
TopologyBuilder builder=new TopologyBuilder();
WordCountSpout spout=new WordCountSpout();
SplitBolt splitBolt=new SplitBolt();
WordCountBolt wordcountBolt=new WordCountBolt();
ReportBolt reportBolt=new ReportBolt();
builder.setSpout("wordcount_spout", spout,2);
builder.setBolt("split_bolt", splitBolt).shuffleGrouping("wordcount_spout");
builder.setBolt("wordcount_bolt", wordcountBolt).fieldsGrouping("split_bolt",new Fields("word"));
builder.setBolt("report_bolt", reportBolt).globalGrouping("wordcount_bolt");
StormTopology topology=builder.createTopology();
StormSubmitter.submitTopology("wordcount_topology",config,topology);
- 将项目打成jar包，并设定方法入口
- 上传到虚拟机
- 进入bin目录
执行：./storm jar word.jar cn.tarena.wordcount.WordCountTopology
可以通过控制台来检测信息流的实时状态
可以通过点击一下选项来控制topology
分别是：启用，暂停，均衡，杀掉
Storm并发机制
概述
Storm集群中的并发度主要由以下四个概念来决定：
1）Nodes–服务器
指的是Storm集群中的一个服务器，会执行Topology的一部分运算,一个Storm集群中包含一
个或者多个Node。
2）Workers–JVM进程
指一个Node上相互独立运作的JVM进程，每个Node可以配置运行一个或多个worker。一个
Topology会分配到一个或者多个worker上运行。
3）Executor–执行线程
指一个worker的jvm中运行的java线程。Storm默认会给每个executor分配一个task。
此外，多个task也可以指派给同一个executer来执行，但需要明确指定。
4）Task–bolt或spout实例的对象
task是spout和bolt的实例，他们的nextTuple()和execute()方法会被executors线程调用执
行。
Storm的并发度
Storm的默认并发设置值是1。
即：一台服务器(node)——为topology分配一个worker——每个executor执行一个task。
如下图所示：
此时唯一的并发机制出现在线程级。
在单机模式下增加并发的方式可以体现在分配更多的worker和executer给topology
如下图，增加worker进程：
如下图，增加executor线程：
注：单机模式下，增加worker的数量不会有任何提升速度的效果。
如果通过代码增加Strom的并发度
1）增加worker
可以通过API和修改配置两种方式修改分配给topology的woker数量。
代码示例：
Config config = new Config();
config.setNumWorkers(2);
2）增加Executor
代码示例：
builder.setSpout(spout_id,spout,2)
builder.setBolt(bolt_id,bolt,executor_num)
3）增加Task
代码示例：
builder.setSpout(…).setNumTasks(2);
builder.setBolt(…).setNumTasks(task_num);
通过单词统计案例来理解并发度
①现在，我们先来设定worker进程数量=2（默认是1）
config.setNumWorkers(2);
②接下来，我们更改executor和task的并发度
builder.setSpout(spout_id,spout,2) //将spout的executor并发度设为2。此外，如果不设定
task并发度，则task的并发度也为2，因为默认是一个线程执行一个task。
builder.setBolt(split_bolt_id,splitBolt,2).setNumTasks(4).shuffleGrouping(spout_id);//将
splitBolt的线程并发度设为2，task并发度为4。在这种情况下，相当于一个executor执行两
个splitBolt的task实例
builder.setBolt(wordcount_bolt_id,wordcountBolt,2)……//设定wordcountBolt的并发
度，
此外，ReportBolt的并发度未做设置，所以默认都是一个线程处理一个对应的task实例
最后如图所示（摘自于《Storm分布式实时计算模式》P16）：
1.Worker=2
2.SentenceSpout 线程并发度=2 任务并发度=2
3.Split Sentence Bolt 线程并发度=2 任务并发度=4
4.Word Count Bolt 线程并发度=4 任务并发度=4
5.Report Bolt 线程并发度=1 任务并发度=1
Storm数据流分组
概述
我们来考虑这样一种情况：
当一个做单词统计的topology的并发如上图时，我们需要考虑什么问题？
1）WordCountSpout——>SplitBolt，发送的数据是 一行一行的数据，任何一个SplitBolt
都可以进行处
2）SplitBolt——>WordcountBolt，发送的数据是 一个一个的单词，但这里就需要注意
了，因为WordcountBolt要根据单词进行词频统计，所以，这里有个原则是，同一个单词，
必须发给同一个WordcountBolt才行。
3）WordcountBolt——>ReportBolt，发送的数据是 {单词，频次}，reportBolt收到数据后
打印即可
所以根据上面的分析，我们需要制定消息流在Bolt之间的传输规则，即我们接下来要学习的
Strom消息流分组。
Stream消息流
消息流是Storm中最关键的抽象，是一个没有边界的Tuple序列，这些Tuple以分布式的方式
并行地创建和处理。定义消息流主要是定义消息流中的Tuple。每个消息流在定义时都会分配
一个ID，因为单向消息流很普遍，OutputFieldsDeclarer定义了一些方法可以定义一个流而
不用指定其ID。在这种情况下，该流有一个默认的ID。
Stream Grouping消息流组
定义Topology的其中一步是定义每个Bolt接受何种流作为输入。Stream Grouping（消息流
组）就是用来定义一个流如何分配Tuple到Bolt。Storm包括6种流分组类型。
1）随机分组（Shuffle Grouping）：随机分发元组到Bolt，并保证每个Bolt获得相等数量的
元组。
2）字段分组（Fields Grouping）：根据指定字段分割数据流并分组。例如，根据“user-
id”字段，具有该字段的Tuple被分到相同的Bolt，不同的“user-id”值则会被分配到不同的
Bolt。
底层是通过指定字段的hash值对Bolt数量取余来实现的。
注：在我们的单词统计案例中，就用到了这种分组，从而能够确保相同单词被发往同一个Bolt
去处理
3）全复制分组（All Grouping）：对于每一个Tuple来说，所有的Bolt都会收到，所有的
Tuple被复制到Bolt的所有任务上，需小心使用该分组。
4）全局分组（Global Grouping）：全部的流都分配到唯一的一个Bolt上，就是分配给ID最
小的Task。
注：这种模型是，对应的Bolt所设定的并发度没有意义，因为最后只有一个Bolt在进行处理。
5）不分组（None Grouping）：不分组的含义是，流不关心到底谁会收到它的Tuple。目前
无分组等效于随机分组。一般不用这种方式。
Strom集群中各角色说明
概述
每一个工作节点上运行的Supervisor监听分配给它那台机器的工作，根据需要启动/关闭工作
进程，每一个工作进程执行一个Topology的一个子集；一个运行的Topology由运行在很多
机器上的很多工作进程Worker组成。那么Storm的核心就是主节点（Nimbus）、工作节点
（Supervisor）、协调器（ZooKeeper）、工作进程（Worker）、任务线程（Task）。
主节点Nimbus
主节点通常运行一个后台程序——Nimbus。
Nimbus守护进程的主要职责是管理，协调和监控在集群上运行的topology。包括topology
的发布，任务指派，事件处理失败时重新指派任务。
将topology发布到Storm集群，将预先打包成jar文件的topology和配置信息提交
（submitting）到nimbus服务器上。一旦nimbus接收到了topology的压缩包，会将jar包分
发到足够数量的supervisor节点上。当supervisor节点接收到了topology压缩文件，nimbus
就会指派task（bolt和spout实例）到每个supervisor并且发送信号指示supervisoer生成足够
的worker来执行指派的task。
nimbus记录所有supervisor节点的状态和分配给它们的task。如果nimbus发现某个
supervisor没有上报心跳或者已经不可达了，它会将故障supervisor分配的task重新分配到集
群中的其他supervisor节点。
nimbus不会引起单点故障。这个特性是因为nimubs并不参与topology的数据处理过程，它
仅仅是管理topology的初始化，任务分发和进行监控。实际上，如果nimbus守护进程在
topology运行时停止了，只要分配的supervisor和worker健康运行，topology一直继续数据
处理。此时你只需要重启nimbus进程即可，无任何影响。
但要注意的是：在nimbus已经停止的情况下supervisor异常终止，因为没有nimbus守护进程
来重新指派失败这个终止的supervisor的任务，数据处理就会失败。不过这种概率是很小的，
因为nimbus进程一般不会宕掉。
目前storm官方出于nimbus宕机对集群影响不大的考虑，并没有实现nimbus的高可用方案。
如果你想宕掉nimbus进程，使用kill -9即可。
工作节点Supervisor
工作节点同样会运行一个后台程序——Supervisor，用于收听工作指派并基于要求运行工作
进程。而Nimbus和Supervisor之间的协调则通过ZooKeeper系统。
同样，你可以用kill-9来杀死Supervisor进程，然后重启就可以继续工作。
协调服务组件ZooKeeper
ZooKeeper是完成Nimbus和Supervisor之间协调的服务。Storm使用ZooKeeper协调集
群，由于ZooKeeper并不用于消息传递，所以Storm给ZooKeeper带来的压力相当低。在大
多数情况下，单个节点的ZooKeeper集群足够胜任，不过为了确保故障恢复或者部署大规模
Storm集群，可能需要更大规模的ZooKeeper集群。Nimbus、Supervisor与ZooKeeper的
关系如图所示。
Worker
具体处理事务进程Worker：运行具体处理组件逻辑的进程。
Task
具体处理线程Task：Worker中的每一个Spout/Bolt线程称为一个Task。在Storm 0.8之后，
Task不再与物理线程对应，同一个Spout/Bolt的Task可能会共享一个物理线程，该线程称为
Executor。