本節書摘來自華章計算機《storm分布式實時計算模式》一書中的第2章，第2.1節,作者：（美）p. taylor goetz brian o’neill 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
在本章中你将深入了解storm的技術棧，它的軟體依賴，以及搭建和部署storm叢集的過程。我們首先會在僞分布式模式下安裝storm，所有的元件都安裝在同一台機器上，而不是在多台機器上。一旦你了解了安裝和配置storm的基本步驟，我們就可以通過puppet這個工具進行自動化的安裝，這樣的話部署多節點的叢集可以節省大量的時間和精力。
本章包括以下内容：
組成storm叢集的不同元件和服務
storm的技術棧
在linux上安裝和配置storm
storm的配置參數
storm的指令行接口
使用服務提供工具puppet進行自動安裝
storm叢集遵循主/從（master/slave）結構，和hadoop等分布式計算技術類似，語義上稍有不同。主/從結構中，通常有一個配置中靜态指定或運作時動态選舉出的主節點。storm使用前一種實作方式。主/從結構中因為引入了單點故障的風險而被诟病，我們會解釋storm的主節點是半容錯的。
storm叢集由一個主節點（稱為nimbus）和一個或者多個工作節點（稱為supervisor）組成。在nimbus和supervisor節點之外，storm還需要一個apache zookeeper的執行個體，zookeeper執行個體本身可以由一個或者多個節點組成。如圖2-1所示。
https://yqfile.alicdn.com/12cb188dcbf5407b9b205dcfac49195ea0e677c7.png" >
nimbus和supervisor都是storm提供的背景守護程序，可以共存在同一台機器上。實際上，可以建立一個單節點僞叢集，把nimbus、supervisor和zookeeper程序都運作在同一台機器上。
2.1.1 了解nimbus守護程序
nimbus守護程序的主要職責是管理，協調和監控在叢集上運作的topology。包括topology的釋出，任務指派，事件處理失敗時重新指派任務。
将topology釋出到strom叢集，将預先打包成jar檔案的topology和配置資訊送出（submitting）到nimbus伺服器上。一旦nimbus接收到了topology的壓縮包，會将jar包分發到足夠數量的supervisor節點上。當supervisor節點接收到了topology壓縮檔案，nimbus就會指派task（bolt和spout執行個體）到每個supervisor并且發送信号訓示supervisoer生成足夠的worker來執行指派的task。
nimbus記錄所有supervisor節點的狀态和配置設定給它們的task。如果nimbus發現某個supervisor沒有上報心跳或者已經不可達了，它會将故障supervisor配置設定的task重新配置設定到叢集中的其他supervisor節點。
前面提到過，嚴格意義上講nimbus不會引起單點故障。這個特性是因為nimubs并不參與topology的資料處理過程，它僅僅是管理topology的初始化，任務分發和進行監控。實際上，如果nimbus守護程序在topology運作時停止了，隻要配置設定的supervisor和worker健康運作，topology一直繼續資料處理。要注意的是，在nimbus已經停止的情況下supervisor異常終止，因為沒有nimbus守護程序來重新指派失敗這個終止的supervisor的任務，資料處理就會失敗。
2.1.2 supervisor守護程序的工作方式
supervisor守護程序等待nimbus配置設定任務後生成并監控workers（jvm程序）執行任務。supervisor和worker都是運作在不同的jvm程序上，如果由supervisor拉起的一個woker程序因為錯誤（或者因為unix終端的kill-9指令，window的tskkill指令強制結束）異常退出，supervisor守護程序會嘗試重新生成新的worker程序。
看到這裡你可能想知道storm的有保障傳輸機制如何适應其容錯模型。如果一個worker甚至整個supervisor節點都故障了，storm怎麼保障出錯時正在處理的tuples的傳輸？
答案就在storm的tuple錨定和應答确認機制中。當打開了可靠傳輸的選項，傳輸到故障節點上的tuples将不會收到應答确認，spout會因為逾時而重新發射原始tuple。這樣的過程會一直重複直到topology從故障中恢複開始正常處理資料。
2.1.3 apache zookeeper簡介
zookeeper使用一個簡單的操作原語集合和分組服務，在分布式環境下提供了集中式的資訊維護管理服務。它是一種簡單但功能強大的分布式同步機制，允許用戶端的應用程式監控或者訂閱資料集中的部分資料，當資料産生，更新或者修改時，用戶端都會收到通知。使用常見的zookeeper模式或方法，開發者可以實作分布式計算所需要的很多種機制，比如leader選舉，分布式鎖和隊列。
storm主要使用zookeeper來協調一個叢集中的狀态資訊，比如任務的配置設定情況，worker的狀态，supervisor之間的nimbus的拓撲度量。nimbus和supervisor節點之間的通信主要是結合zookeeper的狀态變更通知和監控通知來處理的。
storm對zookeeper的使用相對比較輕量化，不會造成很重的資源負擔。對于重量級的資料傳輸操作，比如釋出topology時傳輸jar包，storm依賴thirft進行通信。我們将會看到，topology元件之間的資料傳輸（最影響效率的地方）是在底層進行的，并且經過了性能優化。
2.1.4 storm的drpc服務工作機制
storm應用中的一個常見模式期望将storm的并發性和分布式計算能力應用到“請求-響應”範式中。一個用戶端程序或者應用送出了一個請求并同步地等待響應。這樣的範式可能看起來和典型topology的高異步性、長時間運作的特點恰恰相反，storm具有事務處理的特性來實作這種應用場景，如圖2-2所示。
為了實作這個功能，storm将額外的服務（storm drpc）以及spout和bolt整合在一起工作，提供了可擴充的分布式rpc能力。
drpc功能是完全是可選的，當storm叢集中的應用有使用這個功能時，drpc服務節點才是必須的。
2.1.5 storm ui
storm ui也是可選功能，非常有用，會提供一個基于web的gui來監控storm叢集，對正在運作的topology有一定的管理功能。storm ui提供了已經釋出的topology的統計資訊，對監控storm叢集的運轉和topology的功能有很大幫助，如圖2-3所示。
https://yqfile.alicdn.com/1efd747bc6c4146a092e5a7ff476da7966ae25ca.png" >
storm ui隻能報告由nimubs的trhift api擷取的資訊，不會影響到topology上其他功能。storm ui可以随時開關而不影響任何topology的運作，在那裡它完全是無狀态的。它還可以用配置來進行一些簡單的管理功能，如開啟、停止、暫停和重新均衡負載topology。