storm中supervisor控制著worker的生命週期，負責worker的啟停。
前端時間開發類似storm中這樣的一套系統時(worker和storm差別很大)腦裂的問題，supervisor負責啟動乙個worker，而最後上機器ps看到卻有兩個相同的worker，這兩個相同的worker反覆重啟導致一堆奇怪的現象。
supervisor與worker
storm中，supervisor主要有兩個執行緒。如下圖：
(圖來自twitter發的storm**)
10s執行一次的執行緒負責同步分配資訊等。
3s一次的執行緒負責啟動worker，建立worker需要的心跳目錄等。
問題就出在3s一次的sync-process執行緒上。
supervisor在sync-process中，大概會有一下動作：
1.殺掉超時或不合法的，刪除心跳目錄，注意，不合法的還包括workerid匹配不上的。
2.生成需要啟動的worker的workerid。
3.建立心跳目錄。
4.啟動worker。
5.等worker首次心跳直到超時。
合理的劇本應該是啟動好，supervisor等到worker心跳回來，正常執行。
但當時的情況時，worker在超時時間內沒有心跳回來，不是因為worker異常退出了，而是worker還沒來得及。
supervisor在下次迴圈時，刪除先前的心跳目錄，再次生成新的workerid，啟動乙個worker，這時就有兩個worker同時在執行。
worker1在worker2啟動成功心跳了(強制建立了心跳目錄)，但是此時worker1的id已經被worker2的id覆蓋了，所以worker1被認為不合法，被supervisor kill掉。
worker2也和先前的worker1一樣，心跳慢了一拍，啟動超時了，supervisor繼續啟動了worker3。
就這樣反覆重啟，機器上一直保留著兩個worker。如下圖。
導致這一現象的原因還是supervisor的worker啟動超時時間配得太小，worker啟動後沒有優先心跳導致，worker在心跳時也沒判斷心跳目錄是否存在。
所以解決方案是：
1.supervisor的worker啟動超時時間加大。
2.worker啟動後立即心跳。
3.worker心跳時判斷父目錄，不存在立即退出。
從這裡可以看出storm原本設計的合理性，在首次心跳超時的情況下，只會反覆起不來，而不會腦裂(不會有兩個worker同時服務)，因為storm worker在心跳目錄被刪了之後，再次心跳會由於目錄不存在而退出，而且worker在啟動後不會做額外的事，直接心跳。
Storm 配置 設定worker程序記憶體大小
storm中真正幹活的是各個worker，而worker由supervisor負責啟動。在topology啟動過程中我們會看到如下的啟動日誌 這就是啟動乙個worker程序，也就是乙個jvm程序。預設情況下，storm啟動worker程序時，jvm的最大記憶體是768m。但我在使用過程中，由於會在b...
短暫的北京之旅
總的來說，這次的北京之旅，是非常失敗的。因為沒有天時地利人和。什麼都沒有。真的感覺是很失敗的一次旅程。說句實在的，本來這次到北京來，我本人不是很願意來，因為領導只安排我乙個人來北京和客戶打交道。而我希望中間能夠有乙個人來協調這件事情。這樣以來，我無論做什麼事情都顯得特別的被動。幸好身邊的人還是不錯的...
短暫的產品經理之旅
終於還是沒有完成，自己的弱點暴露的一覽無遺，剛上手，進入乙個新的行業，沒有對這個行業進行深入了解之前就要開始做產品是不可思議的事情，想想是自己太天真了。沒有考慮到後果就直接的進入了產品這個領域。雖然只是工作了不到10天的時間，不過在這個時間裡也讓我感觸了很多，也許很多是我們程式設計師或者做開發的一直...