1.storm基本架構
storm的主從分別為Nimbus、Supervisor,工作進程為Worker.
2.計算模型
Storm的計算模型分為Spout和Bolt，Spout作為管口、Bolt作為中間節點，數據傳輸的單元為tuple,每個tuple都有一個值列表，
需要注意這個值列表是帶name列表的，Bolt只需要訂閱Bolt/Spout的值列表的某些name,就能獲得該Bolt/Spout傳過來的相應字段的數據。
需要清楚並行度是怎么計算的，並行度其實就是Task的數目(也就是Bolt/Spout的具體實例數)。
總並行度 = Spout的executor線程數 * Spout的每個executor的task數目 + ABolt的executor線程數 * ABolt的每個executor的task的數目 + BBolt的executor線程數*BBolt的每個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
TODO
5.Grouping機制 - 分組策略
TODO
6.事務
TODO
7.DRPC
TODO
8.Trident
TODO
9.實際問題
1）pv計算，典型的聚合場景
Spout消費MQ中的數據並發送出去。
第一個Bolt進行分詞和提取，判斷每條數據記錄，如果是訪問記錄，則emit出去1。
第二個Bolt進行局部的聚合，計算本地PV，並發送(thread_id,pv)標志線程級別的唯一性。
第三個Bolt進行全局聚合，計算總PV，這個全局聚合只能有一個，內部維護一個Hash<Long,Long>的數據結構(thread_id,pv)，收到數據后實時更新，然后實時/每隔一段時間對pv進行求和。
2）UV計算，典型的去重聚合場景
常規思路:與之前PV計算類似
Spout消費MQ中的數據並發送出去。
第一個Bolt進行一些預處理，將(session_id,1)為單位發送出去。
第二個Bolt訂閱第一個Bolt的數據，內部維護一個HashMap<String,Long>的結構存儲局部的(session_id,count)信息。然后把(thread_id,hashmap)發送出去。
第三個Bolt進行全局聚合，計算總的UV，這個全局聚合只能有1個，內部維護一個HashMap<Long,HashMap<String,Long>>的結構存儲(thread_id,hashmap(session_id,count)),
收到數據后實時進行更新，然后實時/每隔一段時間對UV進行session粒度的聚合。
特殊思路:我們可以想到在WordCount場景下不一定全局聚合只可以一個Bolt實例。完全可以通過hash(session_id)的方式，把相同的session_id控制在同一個的Bolt實例內。
Spout消費MQ中的數據並發送出去。
第一個Bolt進行一些預處理，將(hash_session_id,session_id,1)發射出去。
第二個Bolt注意要使用fieldsGrouping的方式，指定hash_session_id為grouping的依據字段，也就是說第一個Bolt發出的數據，只要hash_session_id相同，就會被發送到同一個Bolt實例。
第二個Bolt直接對session_id進行全局聚合，因為同一個session_id只會被發送到同一個Bolt實例，因此數據是准確的。內部直接維護一個HashMap<String,Long>的格式(session_id,count)。
這個Bolt實例可以有多個，將它們的數據分別持久化就可以了。