Storm 和JStorm

由于storm的內核是clojure編寫的，目前阿里巴巴公司已經有開源的Copy版本Jstorn，以下本ID為你帶來其中相關區別。

關于流處理框架，在先前的文章匯總已經介紹過Strom， 今天學習的是來自阿里的的流處理框架JStorm。簡單的概述Storm就是：JStorm 比Storm更穩定，更強大，更快，Storm上跑的程序，一行代碼不變可以運行在JStorm上。直白的將JStorm是阿里巴巴的團隊基于Storm 的二次開發產物，相當于他們的Tengine是基于Ngix開發的一樣。以下為阿里巴巴團隊放棄直接使用Storm選擇自行開發JStorm的原因：

阿里擁有自己的實時計算引擎

1. 類似于hadoop 中的MR

2. 開源storm響應太慢

3. 開源社區的速度完全跟不上Ali的需求

4. 降低未來運維成本

5. 提供更多技術支持，加快內部業務響應速度

現有Storm無法滿足一些需求

1. 現有storm調度太簡單粗暴，無法定制化

2. Storm 任務分配不平衡

3. RPC OOM一直沒有解決

4. 監控太簡單

5. 對ZK 訪問頻繁

JStorm相比Storm更穩定

1. Nimbus 實現HA：當一臺nimbus掛了，自動熱切到備份nimbus

2. 原生Storm RPC：Zeromq 使用堆外內存，導致OS 內存不夠，Netty 導致OOM；JStorm底層RPC 采用netty + disruptor保證發送速度和接受速度是匹配的

3. 新上線的任務不會沖擊老的任務：新調度從cpu，memory，disk，net 四個角度對任務進行分配，已經分配好的新任務，無需去搶占老任務的cpu，memory，disk和net

4. Supervisor主線

5. Spout/Bolt 的open/prepar

6. 所有IO, 序列化，反序列化

7. 減少對ZK的訪問量：去掉大量無用的watch；task的心跳時間延長一倍；Task心跳檢測無需全ZK掃描。

JStorm相比Storm調度更強大

1. 徹底解決了storm 任務分配不均衡問題

2. 從4個維度進行任務分配：CPU、Memory、Disk、Net

3. 默認一個task，一個cpu slot。當task消耗更多的cpu時，可以申請更多cpu slot

4. 默認一個task，一個memory slot。當task需要更多內存時，可以申請更多內存slot

5. 默認task，不申請disk slot。當task 磁盤IO較重時，可以申請disk slot

6. 可以強制某個component的task 運行在不同的節點上

7. 可以強制topology運行在單獨一個節點上

8. 可以自定義任務分配，提前預約任務分配到哪臺機器上，哪個端口，多少個cpu slot，多少內存，是否申請磁盤

9. 可以預約上一次成功運行時的任務分配，上次task分配了什么資源，這次還是使用這些資源

JStorm相比Storm性能更好

JStorm 0.9.0 性能非常的好，使用netty時單worker 發送最大速度為11萬QPS，使用zeromq時，最大速度為12萬QPS。

• JStorm 0.9.0 在使用Netty的情況下，比Storm 0.9.0 使用netty情況下，快10%， 并且JStorm netty是穩定的而Storm 的Netty是不穩定的

• 在使用ZeroMQ的情況下， JStorm 0.9.0 比Storm 0.9.0 快30%

性能提升的原因：

1. Zeromq 減少一次內存拷貝

2. 增加反序列化線程

3. 重寫采樣代碼，大幅減少采樣影響

4. 優化ack代碼

5. 優化緩沖map性能

6. Java 比clojure更底層

JStorm的其他優化點

1. 資源隔離。不同部門，使用不同的組名，每個組有自己的Quato；不同組的資源隔離；采用cgroups 硬隔離

2. Classloader。解決應用的類和Jstorm的類發生沖突，應用的類在自己的類空間中

3. Task 內部異步化。Worker 內部全流水線模式，Spout nextTuple和ack/fail運行在不同線程

 具體如何實現，請參考本ID的的博文系列  【jstorm-源碼解析】

來自：http://my.oschina.net/u/1791874/blog/308401