[Jstorm]Jstorm章1 Jstorm架構淺析

1、總體架構

JStorm 的總體架構圖以下：

其中 W 表示 worker，T 表示 task。

從圖中咱們能夠看到 JStorm 在設計上將集羣中的節點分爲 nimbus 和 supervisor 兩類。其中 nimbus 節點至關於整個集羣的調度者，基於 ZK 對整個集羣進行調度，supervisor 節點則是整個集羣中實際運行 topology 的節點。在一個 supervisor 節點中通常會啓動多個 worker 進程，每一個 worker 進程又包含多個 task 線程。咱們提交的 topology 任務通常會包含多個組件（spout 和 bolt），每一個組件依據其並行度配置會分配到相應數量的 task 任務，而每個 task 任務都運行在對應的 task 線程上面。JStorm 是一個重度依賴於 ZK 的分佈式調度系統，全部的工做組件（nimbus、supervisor、worker，以及 task）都會與 ZK 進行交互上報和更新本身的運行狀態，同時獲取其餘工做組件的運行狀態來指導本身接下去的運行。

2、工做過程

簡單陳述一下一個 topology 任務從提交到運行的基本執行過程。

當咱們按照 JStorm 的開發規範實現好本身的 topology 以後，咱們須要將其打成 jar 包並執行相應的命令將其發佈到集羣，這期間咱們主要是和 nimbus 節點進行通訊，nimbus 會啓動一個 thrift 服務，而提交任務的過程實際上就是一次 RPC 請求的過程。

Nimbus 節點會爲本次任務提交請求建立對應的傳輸通道，而後等待用戶上傳 topology 的 jar 文件到本地。上傳完成以後，nimbus 節點會依據用戶的配置以及集羣的運行狀態開始爲當前 topology 制定運行方案，包括須要分配多少 task，這些 task 須要多少 worker 進行執行，對應的 worker 須要落地到哪些 supervisor 節點才能保證集羣的均衡等。當方案制定完成以後，nimbus 會將運行方案寫入 ZK 對應的路徑下面，並告知用戶本次任務提交成功。

Supervisor 節點會按期檢查 ZK 的任務分配路徑以肯定是否有新的任務須要執行，若是正好任務是被分配給當前 supervisor 節點，則 supervisor 會從 nimbus 節點下載當前 topology 對應的 jar 文件，並按照 nimbus 制定的運行方案在本地啓動相應的 worker 去執行 topology 任務。同時 supervisor 會監控本地 worker 的運行狀態，若是存在運行異常的 worker，則將其 kill 掉並通知 nimbus 從新分配。

Nimbus 節點做爲調度者在實際中以單節點的形式運行，早期的 storm 在設計上沒有引入 HA 機制，因此對於 nimbus 節點而言存在單點的隱患，雖然 nimbus 上的數據都是無狀態的，可是當 nimbus 節點宕機以後，仍是會在必定程度上影響整個集羣的正常運行。JStorm 在改造時引入了 HA 機制，在 JStorm 中能夠同時啓動多個 nimbus 節點，這些節點在初始時都是 follower 角色，它們會將自身的節點信息上報給 ZK，而後依據優先級競選成爲 leader，期間須要 ZK 的介入來保證競選結果的一致，當 nimbus leader 宕機以後，候選的 follower 會立刻頂替一個上來，以保證集羣的正常運行。