Storm 和JStorm

關於流處理框架，在先前的文章彙總已經介紹過Strom，今天學習的是來自阿里的的流處理框架JStorm。簡單的概述Storm就是：JStorm 比Storm更穩定，更強大，更快，Storm上跑的程序，一行代碼不變能夠運行在JStorm上。直白的將JStorm是阿里巴巴的團隊基於Storm的二次開發產物，至關於他們的Tengine是基於Ngix開發的同樣。

阿里擁有本身的實時計算引擎

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-源碼解析】