共計 1465 個字符，預計需要花費 4 分鐘才能閱讀完成。

這篇文章給大家介紹  Storm 和 JStorm 該如何理解，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

簡單的概述 Storm 就是：JStorm 比 Storm 更穩定，更強大，更快，Storm 上跑的程序，一行代碼不變可以運行在 JStorm 上。直白的將 JStorm 是阿里巴巴的團隊基于 Storm 的二次開發產物，相當于他們的 Tengine 是基于 Ngix 開發的一樣。

現有 Storm 無法滿足一些需求

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

Storm 任務分配不平衡

RPC OOM 一直沒有解決

監控太簡單

對 ZK 訪問頻繁

JStorm 相比 Storm 更穩定

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

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

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

Supervisor 主線

Spout/Bolt 的 open/prepar

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

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

JStorm 相比 Storm 調度更強大

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

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

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

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

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

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

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

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

可以預約上一次成功運行時的任務分配，上次 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%

性能提升的原因：

Zeromq 減少一次內存拷貝

增加反序列化線程

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

優化 ack 代碼

優化緩沖 map 性能

Java 比 clojure 更底層

JStorm 的其他優化點

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

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

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

關于  Storm 和 JStorm 該如何理解就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。