1.storm基本架构
storm的主从分别为Nimbus、Supervisor,工作进程为Worker.
2.计算模型
Storm的计算模型分为Spout和Bolt，Spout作为管口、Bolt作为中间节点，数据传输的单元为tuple,每个tuple都有一个值列表，
需要注意这个值列表是带name列表的，Bolt只需要订阅Bolt/Spout的值列表的某些name,就能获得该Bolt/Spout传过来的相应字段的数据。
需要清楚并行度是怎么计算的，并行度其实就是Task的数目。
总并行度 = Spout的executor线程数 * Spout的每个executor的task数目
3.流式计算框架对比
流计算框架按数据流的粒度不同分为两种：
1）原生的流处理，这种以消息/记录为传输处理单位进行挨个处理
以消息/记录为单位进行处理 ： Storm 、Samza 、Flink
2)微批处理，这种以一批消息/记录为单位进行小批次的批处理
以小批次消息/记录为单位进行小批次批处理：Storm Trident 、Spark Streaming
使用这两种方式，导致本质上，原生的流处理比微批处理的方式延时更低一些。
其中:
1)Storm、Samza、Flink因为其使用原生的流处理，因此Latency都很低。而使用微批处理的Storm Trident以及Spark Streaming延时不是很低。
2)关于数据传输可靠性，有“At-least-once"至少一次、”Exactly-once"精确一次、“At-most-once"至多一次三种语义。
可靠性排序： 精确一次 > 至少一次 -> 至多一次
3)对于流处理框架的选择，在不同的场景下会有不同
3.1 ： 可靠性优先，必须保证“精确一次”： 这时，我们会从Storm Trident 、Spark Streming 以及 Flink当中选取，但是Storm Trident和Spark Streaming是微批处理的，所以延时相对原生批处理的Flink高。
而且Flink的吞吐量与Spark Streaming都是比较高的。因此采用Flink是可靠性优先的最优选择。
3.2 : 实时性优先，要求超低延时： 这时，我们只能选择Storm,Storm 底层采用ZeroMQ,处理速度是常见的MQ中最快的。但是这个选择一是状态管理需要自行完成，二是可靠性只能到“至少一次”级别，需要自己处理到“精确一次”，三是吞吐量很低。
4.常用的API
5.Grouping机制 - 分组策略
6.事务
7.DRPC
8.Trident
9.实际问题
1）如何进行聚合计数?
使用Storm做聚合一般思路为 ”局部聚合 + 全局聚合“。
第一个Bolt从MQ接收到数据之后，首先进行拆分，将一条记录拆分并提取需要的字符串，并emit发射出去。
第二个Bolt订阅第一个Bolt的数据，使用一个内部的hashMap对象进行聚合的聚合，并将HashMap对象发射出去。
第三个Bolt将订阅第二个Bolt的数据，使用一个内部的HashMap<String,HashMap<String,Integer>>的结构存储