Storm是什麼？

Storm是twitter公司開源捐獻給apache的一個實時流式資料處理的框架。 Storm是一個開源的分散式實時計算系統，可以簡單、可靠的處理大量的資料流。 特點在於來一條資料就馬上處理一條資料，具有低延遲、高可用、易擴充套件、資料不丟失等特點。 主要用於解決資料的實時計算以及實時處理的問題。 Storm有很多使用場景：如實時分析，線上機器學習，持續計算，分散式RPC，ETL等等。

Storm的特點

Storm有如下特點：

• 程式設計模型簡單 和hadoop一樣，Storm也為大資料的實時計算提供了一些簡單優美的原語，大大降低了開發並行實時處理的任務的複雜性，幫助開發者快速、高效的開發應用。

• 可擴充套件 在Storm叢集中真正執行topology的主要有三個實體：工作程序、執行緒和任務。 Storm叢集中的每臺機器上都可以執行多個工作程序，每個工作程序又可建立多個執行緒，每個執行緒可以執行多個任務，任務是真正進行資料處理的實體，我們開發的spout、bolt就是作為一個或者多個任務的方式執行的。 因此，計算任務在多個執行緒、程序和伺服器之間並行進行，支援靈活的水平擴充套件。

• 高可靠性 Storm可以保證spout發出的每條訊息都能被“完全處理”，這也是直接區別於其他實時系統的地方。 請注意，spout發出的訊息後續可能會觸發產生成千上萬條訊息，可以形象的理解為一棵訊息樹，其中spout發出的訊息為樹根，Storm會跟蹤這棵訊息樹的處理情況，只有當這棵訊息樹中的所有訊息都被處理了，Storm才會認為spout發出的這個訊息已經被“完全處理”。如果這棵訊息樹中的任何一個訊息處理失敗了，或者整棵訊息樹在限定的時間內沒有“完全處理”，那麼spout發出的訊息就會重發。 考慮到儘可能減少對記憶體的消耗，Storm並不會跟蹤訊息樹中的每個訊息，而是採用了一些特殊的策略，它把訊息樹當作一個整體來跟蹤，對訊息樹中所有訊息的唯一id進行異或計算，通過是否為零來判定spout發出的訊息是否被“完全處理”，這極大的節約了記憶體和簡化了判定邏輯，後面會對這種機制進行詳細介紹。 這種模式，每傳送一個訊息，都會同步傳送一個ack/fail，對於網路的頻寬會有一定的消耗，如果對於可靠性要求不高，可通過使用不同的emit介面關閉該模式。 上面所說的，Storm保證了每個訊息至少被處理一次，但是對於有些計算場合，會嚴格要求每個訊息只被處理一次，幸而Storm的0.7.0引入了事務性拓撲，解決了這個問題。

• 高容錯性 如果在訊息處理過程中出了一些異常，Storm會重新安排這個出問題的處理單元。Storm保證一個處理單元永遠執行（除非你顯式殺掉這個處理單元）。 當然，如果處理單元中儲存了中間狀態，那麼當處理單元重新被Storm啟動的時候，需要應用自己處理中間狀態的恢復。

• 支援多種程式語言 除了用java實現spout和bolt，你還可以使用任何你熟悉的程式語言來完成這項工作，這一切得益於Storm所謂的多語言協議。多語言協議是Storm內部的一種特殊協議，允許spout或者bolt使用標準輸入和標準輸出來進行訊息傳遞，傳遞的訊息為單行文字或者是json編碼的多行。 Storm支援多語言程式設計主要是通過ShellBolt, ShellSpout和ShellProcess這些類來實現的，這些類都實現了IBolt 和 ISpout介面，以及讓shell通過java的ProcessBuilder類來執行指令碼或者程式的協議。 可以看到，採用這種方式，每個tuple在處理的時候都需要進行json的編解碼，因此在吞吐量上會有較大影響。

• 支援本地模式 Storm有一種“本地模式”，也就是在程序中模擬一個Storm叢集的所有功能，以本地模式執行topology跟在叢集上執行topology類似，這對於我們開發和測試來說非常有用。

storm的架構模型

角色說明： nimbus：storm當中的主節點，負責資源分配和任務排程。主要用於接收客戶端提交的topology，以及分配任務的執行，nimbus可以有多個。

zookeeper：維持主節點與從節點的通訊，維持一些公共資訊，叢集的狀態監控以及nimbus分配的任務都寫入到zk當中來。

supervisor：storm當中的從節點，主要用於接收nimbus分配的任務，並負責管理自己的worker程序。

worker：執行具體的處理邏輯的程序，我們提交的任務，可以指定通過幾個程序來進行執行。

executor：執行緒的概念，執行器，真正執行我們的程式碼的東西，這個是執行緒的概念。

task：在新的版本（jstorm）當中已經沒有意義了

topology：我們提交的一個任務就是一個topology