Storm原理

并发机制
对于并发度的配置, 在storm里面可以在多个地方进行配置, 优先级为：
defaults.yaml < storm.yaml < topology-specific configuration < internal component-specific configuration < external component-specific configuration

• worker processes的数目, 可以通过配置文件和代码中配置, worker就是执行进程, 所以考虑并发的效果, 数目至少应该大亍machines的数目
• executor的数目, component的并发线程数，只能在代码中配置(通过setBolt和setSpout的参数), 例如, setBolt(“green-bolt”, new GreenBolt(), 2)
• tasks的数目, 可以不配置, 默认和executor1:1, 也可以通过setNumTasks()配置

Topology的worker数通过config设置，即执行该topology的worker（java）进程数。它可以通过 storm rebalance 命令任意调整。

Config conf = newConfig();
conf.setNumWorkers(2); //用2个worker
topologyBuilder.setSpout(“blue-spout”, newBlueSpout(), 2); //设置2个并发度
topologyBuilder.setBolt(“green-bolt”, newGreenBolt(), 2).setNumTasks(4).shuffleGrouping(“blue-spout”); //设置2个并发度，4个任务
topologyBuilder.setBolt(“yellow-bolt”, newYellowBolt(), 6).shuffleGrouping(“green-bolt”); //设置6个并发度
StormSubmitter.submitTopology(“mytopology”, conf, topologyBuilder.createTopology());

• 动态的改变并行度
  Storm支持在不 restart topology 的情况下, 动态的改变(增减) worker processes 的数目和 executors 的数目, 称为rebalancing. 通过Storm web UI，或者通过storm rebalance命令实现：
  storm rebalance mytopology -n 5 -e blue-spout=3 -e yellow-bolt=10

Worker进程间通信

• 对于worker进程来说，为了管理流入和传出的消息，每个worker进程有一个独立的接收线程 (对配置的TCP端口supervisor.slots.ports进行监听);
  对应Worker接收线程，每个worker存在一个独立的发送线程 ，它负责从worker的transfer-queue 中读取消息，并通过网络发送给其他worker
• 每个executor有自己的incoming-queue 和outgoing-queue 。
  Worker接收线程将收到的消息通过task编号传递给对应的executor(一个或多个)的incoming-queues;
  每个executor有单独的线程分别来处理spout/bolt的业务逻辑，业务逻辑输出的中间数据会存放在outgoing-queue中，当executor的outgoing-queue中的tuple达到一定的阀值，executor的发送线程将批量获取outgoing-queue中的tuple,并发送到transfer-queue中。
• 每个worker进程控制一个或多个executor线程，用户可在代码中进行配置。其实就是我们在代码中设置的并发度个数

消息容错
（1）总体介绍
在storm中，可靠的信息处理机制是从spout开始的。
一个提供了可靠的处理机制的spout需要记录他发射出去的tuple，当下游bolt处理tuple或者子tuple失败时spout能够重新发射。
Storm通过调用Spout的nextTuple()发送一个tuple。为实现可靠的消息处理，首先要给每个发出的tuple带上唯一的ID，并且将ID作为参数传递给SoputOutputCollector的emit()方法：collector.emit(new Values(“value1”,”value2”), msgId);
给每个tuple指定ID告诉Storm系统，无论处理成功还是失败，spout都要接收tuple树上所有节点返回的通知。如果处理成功，spout的ack()方法将会对编号是msgId的消息应答确认；如果处理失败或者超时，会调用fail()方法。

（2）基本实现
Storm 系统中有一组叫做”acker”的特殊的任务，它们负责跟踪DAG（有向无环图）中的每个消息。
acker任务保存了spout id到一对值的映射。第一个值就是spout的任务id，通过这个id，acker就知道消息处理完成时该通知哪个spout任务。第二个值是一个64bit的数字，我们称之为”ack val”， 它是树中所有消息的随机id的异或计算结果。
ack val表示了整棵树的的状态，无论这棵树多大，只需要这个固定大小的数字就可以跟踪整棵树。当消息被创建和被应答的时候都会有相同的消息id发送过来做异或。 每当acker发现一棵树的ack val值为0的时候，它就知道这棵树已经被完全处理了。

（3）可靠性配置
有三种方法可以去掉消息的可靠性：
将参数Config.TOPOLOGY_ACKERS设置为0，通过此方法，当Spout发送一个消息的时候，它的ack方法将立刻被调用；
Spout发送一个消息时，不指定此消息的messageID。当需要关闭特定消息可靠性的时候，可以使用此方法；
最后，如果你不在意某个消息派生出来的子孙消息的可靠性，则此消息派生出来的子消息在发送时不要做锚定，即在emit方法中不指定输入消息。因为这些子孙消息没有被锚定在任何tuple tree中，因此他们的失败不会引起任何spout重新发送消息。

任务提交的过程

组件本地目录树

zookeeper目录树