【流式計算】Twitter Storm原始碼分析之ZooKeeper中的目錄結構
阿新 • • 發佈：2019-01-25
作者: xumingming | 可以轉載, 但必須以超連結形式標明文章原始出處和作者資訊及版權宣告
我們知道Twitter Storm的所有的狀態資訊都是儲存在Zookeeper裡面，nimbus通過在zookeeper上面寫狀態資訊來分配任務，supervisor，task通過從zookeeper中讀狀態來領取任務，同時supervisor, task也會定義傳送心跳資訊到zookeeper， 使得nimbus可以監控整個storm叢集的狀態， 從而可以重啟一些掛掉的task。ZooKeeper 使得整個storm叢集十分的健壯 — 任何一臺工作機器掛掉都沒有關係，只要重啟然後從zookeeper上面重新獲取狀態資訊就可以了。本文主要介紹Twitter
Storm在ZooKeeper中儲存的資料目錄結構，原始碼主要是: backtype.storm.cluster, 廢話不多說，直接看下面的結構圖：
一個要注意的地方是，作者在程式碼裡面很多地方用到的storm-id, 其實就是topology-id的意思。我在郵件列表裡面問了他一下， 他說以前他把topology叫做storm, 程式碼裡面還沒有改過來。
| 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
/-{storm-zk-root} -- storm在zookeeper上的根
| 目錄
|
|-/assignments -- topology的任務分配資訊
| |
| |-/{topology-id} -- 這個下面儲存的是每個
| topology的assignments
| 資訊包括： 對應的
| nimbus上的程式碼目錄,所有| task的啟動時間,
| 每個task與機器、埠的對映
|
|-/tasks -- 所有的task
| |
| |-/{topology-id} -- 這個目錄下面id為
| | {topology-id}的topology
| | 所對應的所有的task-id
| |
| |-/{task-id} -- 這個檔案裡面儲存的是這個
| task對應的component-id：
| 可能是spout-id或者bolt-id
|
|-/storms -- 這個目錄儲存所有正在執行
| | 的topology的id
| |
| |-/{topology-id} -- 這個檔案儲存這個topology
| 的一些資訊，包括topology的
| 名字，topology開始執行的時
| 間以及這個topology的狀態
| (具體看StormBase類)
|
|-/supervisors -- 這個目錄儲存所有的supervisor
| | 的心跳資訊
| |
| |-/{supervisor-id} -- 這個檔案儲存的是supervisor
| 的心跳資訊包括:心跳時間，主
| 機名，這個supervisor上worker
| 的埠號執行時間
| (具體看SupervisorInfo類)
|
|-/taskbeats -- 所有task的心跳
| |
| |-/{topology-id} -- 這個目錄儲存這個topology的所
| | 有的task的心跳資訊
| |
| |-/{task-id} -- task的心跳資訊，包括心跳的時
| 間，task執行時間以及一些統計
| 資訊
|
|-/taskerrors -- 所有task所產生的error資訊
|
|-/{topology-id} -- 這個目錄儲存這個topology下面
| 每個task的出錯資訊
|
|-/{task-id} -- 這個task的出錯資訊
|