参考：
https://www.cnblogs.com/followees/p/8998551.html
官方文档：
http://storm.apache.org/releases/1.2.3/javadocs/org/apache/storm/Config.html#NIMBUS_SEEDS
tar -zxvf apache-storm-1.0.5.tar.gz
cd apache-storm-1.0.5/conf
vi storm.yaml
官方文档推荐使用 nimbus.seeds 而不是 nimbus.host
storm.zookeeper.servers:
- "storm-01"
- "storm-02"
- "storm-03"
nimbus.seeds: ["storm-01", "storm-02"]
配置环境变量：
[hadoop@storm-01 apache-storm-1.0.5]$ STORM_HOME=/home/hadoop/apache-storm-1.0.5
[hadoop@storm-01 apache-storm-1.0.5]$ PATH=$PATH:$STORM_HOME/bin
[hadoop@storm-01 apache-storm-1.0.5]$ export STORM_HOME
这样只能临时生效
建议直接修改/etc/profile
export STORM_HOME=/home/hadoop/apache-storm-1.0.5
export PATH=$PATH:${STORM_HOME}/bin
执行
source /etc/profile
【profile 是全局文件，对所有用户有效】
注意：
nimbus和supervisors之间的协调工作要通过zookeeper
nimbus进程和supervisors进程是无法直接连接和无状态的，所有的状态由zookeeper维持，
这意味着我们可以 kill -9 xx 来直接杀死进程，而不需要做备份。
================================================= 分界线 =============================================================
Topology在Storm集群中分发
参考：强烈推荐
http://www.tianshouzhi.com/api/tutorials/storm/104
http://ifeve.com/storm-running-topologies-on-a-production-cluster/
理解 Storm 拓扑的并行度(parallelism)概念，调整并行度
http://ifeve.com/storm-understanding-the-parallelism-of-a-storm-topology/
https://www.cnblogs.com/duanxz/p/4701757.html
1、通过storm jar ... 命令来提交Topology的jar文件到nimbus所在机器。
这个命令会把jar文件上传到nimnus所在的机器上。
也就是说，无论这个命令是在主节点nimbus上执行的，或者是在其他的supervisor节点上执行的，都是首先上传到nimbus那台机器上
2、消息的可靠性处理
builder.setSpout("sentences" , new KestrelSpout("kestrel.backtype.com" ,
22133,
"sentence_queue",
new StringScheme()));
在 KestrlSpout 从 Kestrel 队列中取出一条消息时，可以看作它“打开”了这条消息。
也就是说，这条消息实际上并没有从队列中真正地取出来，而是保持着一个“挂起”状态，等待消息处理 完成的信号。
在挂起状态的消息不会被发送到其他的消费者中。
另外，如果消费者（客户端）断开了连接，所有处于挂起状态的消息都会重新放回到队列中。
在消息 “打开”的时候 Kestrel 会给客户端同时提供消息体数据和一个唯一的 id。
KestrelSpout 在使用 SpoutOutputCollector 发送 tuple 的时候就会把这个唯一的 id 当作“消息 id”。
一段时间之后，在 KestrelSpout 的 ack 或者 fail 方法被调用的时候，KestrelSpout 就会通过这个消息 id 向 Kestrel 请求将消息从队列中移除（对应 ack 的情况）或者将消息重新放回队列（对应 fail 的情况）。
如果你不关注消息的可靠性 —— 也就是说你不关心在失败情形下发生的 tuple 丢失 —— 那么你就可以通过不跟踪 tuple 树的处理来提升拓扑的性能。由于 tuple 树中的每个 tuple 都会带有一个应答消息，不追踪 tuple 树会使得传输的消息的数量减半。同时，下游数据流中的 id 也会变少，这样可以降低网络带宽的消耗。
有三种方法可以移除 Storm 的可靠性机制。
【第一种方法是将 Config.TOPOLOGY_ACKERS 设置为0，在这种情况下，Storm 会在 Spout 发送 tuple 之后立即调用 ack 方法，tuple 树叶就不会被跟踪了。】
第二种方法是基于消息本身移除可靠性。你可以通过在 SpoutOutputCollector.emit 方法中省略消息 id 来关闭 spout tuple 的跟踪功能。
最后，如果你不关心拓扑中的下游 tuple 是否会失败，你可以在发送 tuple 的时候选择发送“非锚定”的（unanchored）tuple。由于这些 tuple 不会被标记到任何一个 spout tuple 中，显然在他们处理失败的时候不会引起任何 spout tuple 的重新处理（注意，在使用这种方法时，如果上游有 spout 或 bolt 仍然保持可靠性机制，那么需要在 execute 方法之初调用OutputCollector.ack 来立即响应上游的消息，否则上游组件会误认为消息没有发送成功导致所有的消息会被反复发送）。