storm中worker、executor、task之間的關係

理清一下worker、executor、task、supervisor、nimbus、zk這幾個之間的關係

先來看一張圖

 

（圖片來自：http://www.cnblogs.com/foreach-break/p/storm_worker_executor_spout_bolt_simbus_supervisor_mk-assignments.html）

　　首先從微觀上來看：worker即進程，一個worker就是一個進程，進程裏面包含一個或多個線程，一個線程就是一個executor，一個線程會處理一個或多個任務，一個任務就是一個task，一個task就是一個節點類的實例對象。

　　一個worker處理topology的一個子集，同一個子集可被多個worker同時處理，一個worker有且僅爲一個topology服務，不會存在一個worker即處理topology1的幾個節點，又處理topology2的幾個節點；一個executor處理一個節點，但這個節點可能會有多個實例對象，因此可經過配置併發度和setNumTask來配置一個executor同時處理多少個task。默認狀況下一個executor就處理一個task。若是處理多個task，executor會循環遍歷執行task。

　　那麼一個excutor處理多個task，有什麼用？一種理解的是能夠方便之後擴容。首先要知道，topology代碼一旦提交到nimbus上去以後，task數量隨之而定，之後永再也不改變，甚至重啓topology，都不會再改變task數量，除非改代碼，再從新提交。而設置並行度就不同了，咱們不須要從新提交代碼，就能夠修改topology的併發，能夠隨時修改。但一個executor必需要處理一個task，若是之前咱們默認有4個executor，4個task，即一個executor處理一個task，好了，我如今感受如今併發不夠，處理速度跟不上，想調高一些併發，調爲8個，呵呵，但task數量只有4個，多出來的executor也只是閒着，因此調高併發也沒卵用了。就像這裏有4個蘋果，也有4我的，一我的吃一個蘋果要5分鐘，如今須要在5秒鐘內將蘋果吃完，規則是一個蘋果只能被一我的吃。如今一我的吃一個，併發爲4，須要5分鐘，顯然知足不了，因而你調高併發，叫來8我的，由於一個蘋果只能被一我的吃，因此另外4個不就是乾瞪眼嗎？還浪費資源。因此爲了方便之後調併發數，仍是要設置一下task數量的。

而後再來看看宏觀的storm架構，要想理清整個架構，只看概念以爲枯燥，不如來看看一個topology從提交到運行的整個過程放鬆一下：

一個topology的提交過程：

1. 非本地模式下，客戶端經過thrift調用nimbus接口，來上傳代碼到nimbus並觸發提交操做.

2. nimbus進行任務分配，並將信息同步到zookeeper.

3. supervisor按期獲取任務分配信息，若是topology代碼缺失，會從nimbus下載代碼，並根據任務分配信息，同步worker.

4. worker根據分配的tasks信息，啓動多個executor線程，同時實例化spout、bolt、acker等組件，此時，等待全部connections（worker和其它機器通信的網絡鏈接）啓動完畢，此storm-cluster即進入工做狀態。

5. 除非顯示調用kill topology，不然spout、bolt等組件會一直運行。

（圖片來自：http://www.cnblogs.com/foreach-break/p/storm_worker_executor_spout_bolt_simbus_supervisor_mk-assignments.html）

nimbus是整個集羣的控管核心，整體負責了topology的提交、運行狀態監控、負載均衡及任務從新分配，等等工做。
zk就是一個管理者，監控者。

　　總之一句話：nimbus下命令（分配任務），zk監督執行（心跳監控，worker、supurvisor的心跳都歸它管），supervisor領旨（下載代碼），招募人馬(建立worker和線程等)，worker、executor就給我幹活！其實說白了跟咱們常見的軍隊管理是一個道理啊。

　　這裏只是粗淺的分析了一下幾者之間的關係，尚未談論到負載均衡和任務調度，沒有深刻到代碼層次，後面會相繼補充。若有錯誤歡迎批評指正！