上文說到，zookeeper是nimbus和supervisor把裡面讀寫一些原數據信息的，具體會寫什麼信息呢，存儲心跳，會把心跳寫上去，具體讀取心跳信息的人再去zookeeper上面去讀取信息，第二塊兒呢， 調度信息，錯誤信息，當task執行錯誤的時候呢，把錯誤的信息寫到zookeeper上去，這樣的話，在webUI上我們就可以讀取這些信息，把情況給展示出來。
實際上呢，Storm用zookeeper呢，使用的非常簡單，它就把它當做一個高可用的KV來使用，storm使用zookeeper呢需求非常簡單，就是說讓整個集群別變成無狀態的，就是任何節點掛了呢，受影響都不大，包括nimbus這種master進程掛掉的話，整個集群都還是能工作的，它要做到這一點呢就需要把狀態信息元數據都存儲到一個KV裡面去，存儲到一個系統裡面去，最簡單的就是一個KV就解決了，之所以選用zookeeper呢，是因為它是一個分佈式的，高可用的小KV的一個系統，它裡面一般是3個或者5個機器，當它的機器壞掉的數目不超過一半的時候呢，zookeeper還是可用的，所以zookeeper在這裡起到了一個高可用的作用，比如說我們一般部署5臺機器，在宕掉一臺或者兩臺機器的時候呢，都能正常使用，都沒有問題。
storm用zookeeper呢，和其它的master/slave的技術使用zookeeper呢還是有點不一樣，比如hadoop他是一個典型的master/slave架構，但是在hadoop裡面呢，所有的salve都會向master去彙報狀態，比如mapreduce裡面的tracker都會向jobtracker彙報，這樣呢在jobtracker裡面的內存呢就會有所有tracker的狀態，同時在tracker向jobtracker彙報心跳的時候呢，jobtracker會在迴應裡面呢，帶上你要執行的task，tracker你要執行什麼task這樣的信息，hadoop這種方式的好處是比較直接，slave向master彙報心跳，master給slave一些指令，很簡單很清晰，storm之所以不採用這種架構是因為這種需要保證更好更高的可用性，因為如果宕機會有延遲，流式計算裡面對延遲接受度是比較低的，因為業務如果延遲10分鐘什麼的話，影響是很大的，storm就是要保證當任何掛掉的時候，業務可以穩定運行，所以它需要各個進程都是無狀態的。
比如nimbus，如果各個節點都向它彙報，如果nimbus一旦掛了，那就存在這些個狀態信息怎麼恢復的問題，各個節點連不上的時候，怎麼處理的問題，所以storm它的做法是各個節點都把狀態信息往zk上寫，因為zk我們認為是可靠地，這樣比如說如果nimbus掛了，那再新起一個nimbus，它去zk上面去取Supervisor的信息，它就可以立刻知道supervisor處於一個什麼狀態，supervisor也一樣，它不需要與nimbus通信，它的心跳是往，而它啟動task的時候呢，也不是從nimbus上面要task，而是 nimbus把Task放到zookeeper上面去，然後supervisor再去zk上面去讀，然後讀到task之後呢再去啟動task，所以相互之間通過zk做了一個解耦，zk又是高可用的，非常好的，又是集群的方式，達到了一個非常高的穩定性，這個從架構上來講的話呢，比hadoop的架構要更先進一些了。
那我們下面再來看看storm使用zk的時候都往zk裡面寫了一些什麼樣的東西。
1./storm/supervisors/supervisor-id
首先最基本的每個supervisor的信息它要寫進去吧，因為它要知道整個集群的狀態，還要寫一些topology的信息，name，id，狀態的信息，這個地方可能有些奇怪了，這裡為什麼叫storm-id而不叫topologyid？？？
2./storm/storms/storm-id
實際上這個地方就應該叫topology-id，只不過在storm最早開發的時候呢，它每一個topology不叫topology，叫一個storm，但是對外文檔都叫做了topology，內部的調用什麼沒改，還是沿用之前的，所以這裡看到的還是storm-id，這裡storms其實就是storm，storm-id是topology-id，所以大家以後要是深入到storm代碼裡面去的時候，有些storm-id的地方其實就是topology-id的意思，並不是兩個不一樣的東西，就是同一個東西。
3./storm/assignments/storm-id
當topolgy提交到集群裡面去之後呢，nimbus會對它進行調度，當然nimbus會把調度信息寫入到zookeeper裡面去，包括topology分配了多少個worker啊，每個worker有個id號啊，worker分配到哪些機器啊，等等這些信息。
4./storm/workerbeats/storm-id/node-port
那這些worker啟動來之後呢，它也需要把這些心跳信息寫到集群裡面去，方便後面去監控，每個worker它會把信息寫到對應的文件上面去，命名是node加port的形式，node就是supervisor的ID，port就是這個worker對應的port，因為不同的supervisor上對應的port一定也是唯一的，因為port是他們數據交換的端口，所以說這個地方node加port是可以保證唯一性的。
5./storm/errors/storm-id/component-id
最後一部分是錯誤信息，就是Spout和Bolt產生的錯誤會寫到zookeeper上面去，方便分析問題，這個error信息寫到zookeeper裡面的時候，這裡說明一下，它有個策略，就是每個component就是Spout或者Bolt，它最多寫最近的20條，這樣就防止往zk裡面存儲過多的數據，導致壓力太大，因為zk不適合存儲過多的數據，那你要是想看歷史的數據呢，那再storm的日誌裡面有，再去Storm的日誌裡面翻。
本人熱愛技術，喜歡交流學習，有什麼前瞻新技術大家一起加群（Q）：131322610 溝通學習
相關推薦
