storm使用要注意哪些點

這篇文章主要講解了“storm使用要注意哪些點”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“storm使用要注意哪些點”吧！

個人理解：storm是一個分布式、實時、流、計算、平臺，幾個特性從這名字中已經看出來了。

 一、實時，簡單理解就是數據進入系統要迅速被處理，也就是延遲要小。

 二、流，流具有什么特點，想象一下你站在長江岸邊，什么感覺，震撼？浩蕩？小弟沒看過，我理解的流就是①沒有阻塞②方向只能從高到低③流之間沒有影響④可以靈活改變流的方向（挖個溝，對應storm的grouping機制） ⑤不間斷

三、計算，這個概念其實比較廣，計算機處理任何東西一般都涉及計算，在這里我理解的還是沒有阻塞，也就是更傾向于計算，不要和外部過多資源進行交換，例如網絡、磁盤。。。

四、分布式，分布式大家聽的耳朵都起繭子了，個人有個人的理解，分布式一個比較重要的衡量指標就是可擴展性（線性、非線性）、資源對服務或用戶透明、具有一定的負載均衡能力、充分利用資源？（好像國內好多搞hadoop的都用牛逼服務器，貌似hadoop出來是為了利用那些過時老舊的機器的）、最好是無序。。。

五、平臺，這個好理解，它就是提供了以上四個主要特性的平臺，那滿足這個平臺要求的服務就可以在這個平臺上跳舞，一個好的平臺可以改變我們的命運哦~

六、可靠性，分布式系統那么多組件，某個出現了問題storm可以自動恢復

適應場景

    從以上5點可以總結出storm注重的是實時性、偏重計算、分布式特性、線性可擴展、流的特性。當然有了這些特性最終還是要靠到業務邏輯上，這個我寫過一篇基于storm做爬蟲的可能性，我覺得在爬蟲的場景里邊，用storm是再好不過的了，因為爬蟲一般是7*24小時不間斷的從網絡上獲取數據，構成了流，一般還要求實時性，就是盡快將最新的內容搞到自己的口袋里，計算量也不小涉及到各種數據的處理，然后遇到瓶頸后可以平滑的進行線性可擴展，無需停止服務，最主要一點是爬蟲種子間處理沒什么關聯，完全切合分布式的特性，總之等等吧，我覺得如果把爬蟲放到storm上猶如楊過獲得了一把屠龍刀。

注意幾點（實踐出真知？）

1. 一個worker被kill情況下，假如這個worker和其它worker沒有關系，貌似其它worker不會受影響，被kill的worker會被storm啟動，若和其它worker有關系，那么其它worker也會受影響，task會被重新啟動（類似于rebalance的效果，好像和rebalance的過程一樣）。

2. acker貌似是就近原則，一個spout的消息優先采用本地acker跟蹤，經測試效果看，一旦acker被kill，當這個acker再次被啟動的時候，其之前跟蹤的那些消息將迅速失敗。

3. acker無法被rebalance。

4. 大家都知道storm中nextTuple和ack或fail方法是在一個線程下執行的，經測試觀察，storm會先調用spout的nextTuple()然后再檢查ack(mid)或fail(mid)，再配合storm的pending機制，這個大家有時需要注意，在特定的需求下可能會有類似于死鎖的問題。（這里不詳細說明，如有需要可以留言給我，因為只是在我們的特定需求上出現過問題）。

5. storm雖然不建議大家在bolt或spout中new新的線程，但有時為了異步處理，也是不可避免的，經測試觀察，storm自己啟動的線程優先級比較高，假若你想自己的線程得到充分調用需要設置自己創建的線程優先級到更高（我一般直接到最大了，然后用lock機制，然后windows和類UNIX系統jvm線程優先級是有差別的，這個大家可以去深入了解下）。

6. 因為不同的機器可能資源不同，storm默認調度器機制基本是平均分配機制，這會導致，數據亂序情況比較嚴重。

7. storm先啟動你的spout然后再依次啟動不同機器上的bolt task，spout不會等bolt都啟動完成后才開始發數據，這時假如你有一個bolt初始化耗費1分鐘，然后你的消息超時設置的是30s，那在這個bolt啟動完成之前的消息會因為spout超時設置的比較短而導致消息超時，從而導致spout fail（mid）。 好吧，我承認這個我之前理解錯了，storm會執行spout的open和各個bolt的prepare，依次都初始化好后會激活spout（Activate spout），這時spout工作線程才開始執行nextTuple。

8. topology的TOPOLOGY_RECEIVER_BUFFER_SIZE設置成16會比較快，至少在我們業務上整體速度在1w+這個速度下，設置成16比8或32要快，當然不同的場景這個值可能會不同（這里要強調一下，storm中有四個buffer，理解起來比較別扭，而且四個buffer不是收/發對稱的，還是推薦大家去看官方文檔或權威一點的地去學習）

9. 先這么多。。。想起什么了，后期再補充

   
   

1. bolt處理錯誤不好往spout傳，也就是一個tuple處理失敗了，spout端只能知道失敗的消息的id，而不知道具體失敗的原因，這塊兒我覺得不是很靈活，當然要是在一個worker下不會有這種問題，只出現在分布式環境下。

2. bolt emit一個tuple雖然可以anchor（錨定）到一個list<Tuple>，但是collector的ack或fail方法只能接收單個tuple，不能直接ack/fail一個list<Tuple>，如下代碼：

   
   

3. collector.emit(TopoUtil.StreamId.DEFAULT, 
                   list,
                   new Values(sonSMessage));
   
   for (Tuple tuple : list) {
   	collector.ack(tuple);
   }

4.     storm rebalance 經測試看有點問題，就是-n參數只能從一開始提交的進程數rebalance到更小，不能從2rebalance到3 或4 或更大，-e參數沒有這個問題，但線程數是不能大于task數的，這個弄過storm都知道，前面需要注意

感謝各位的閱讀，以上就是“storm使用要注意哪些點”的內容了，經過本文的學習后，相信大家對storm使用要注意哪些點這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！