storm使用要注意哪些點(diǎn)

這篇文章主要講解了“storm使用要注意哪些點(diǎn)”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“storm使用要注意哪些點(diǎn)”吧！

個(gè)人理解：storm是一個(gè)分布式、實(shí)時(shí)、流、計(jì)算、平臺(tái)，幾個(gè)特性從這名字中已經(jīng)看出來了。

 一、實(shí)時(shí)，簡(jiǎn)單理解就是數(shù)據(jù)進(jìn)入系統(tǒng)要迅速被處理，也就是延遲要小。

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

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

四、分布式，分布式大家聽的耳朵都起繭子了，個(gè)人有個(gè)人的理解，分布式一個(gè)比較重要的衡量指標(biāo)就是可擴(kuò)展性（線性、非線性）、資源對(duì)服務(wù)或用戶透明、具有一定的負(fù)載均衡能力、充分利用資源？（好像國(guó)內(nèi)好多搞hadoop的都用牛逼服務(wù)器，貌似hadoop出來是為了利用那些過時(shí)老舊的機(jī)器的）、最好是無序。。。

五、平臺(tái)，這個(gè)好理解，它就是提供了以上四個(gè)主要特性的平臺(tái)，那滿足這個(gè)平臺(tái)要求的服務(wù)就可以在這個(gè)平臺(tái)上跳舞，一個(gè)好的平臺(tái)可以改變我們的命運(yùn)哦~

六、可靠性，分布式系統(tǒng)那么多組件，某個(gè)出現(xiàn)了問題storm可以自動(dòng)恢復(fù)

適應(yīng)場(chǎng)景

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

注意幾點(diǎn)（實(shí)踐出真知？）

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

2. acker貌似是就近原則，一個(gè)spout的消息優(yōu)先采用本地acker跟蹤，經(jīng)測(cè)試效果看，一旦acker被kill，當(dāng)這個(gè)acker再次被啟動(dòng)的時(shí)候，其之前跟蹤的那些消息將迅速失敗。

3. acker無法被rebalance。

4. 大家都知道storm中nextTuple和ack或fail方法是在一個(gè)線程下執(zhí)行的，經(jīng)測(cè)試觀察，storm會(huì)先調(diào)用spout的nextTuple()然后再檢查ack(mid)或fail(mid)，再配合storm的pending機(jī)制，這個(gè)大家有時(shí)需要注意，在特定的需求下可能會(huì)有類似于死鎖的問題。（這里不詳細(xì)說明，如有需要可以留言給我，因?yàn)橹皇窃谖覀兊奶囟ㄐ枨笊铣霈F(xiàn)過問題）。

5. storm雖然不建議大家在bolt或spout中new新的線程，但有時(shí)為了異步處理，也是不可避免的，經(jīng)測(cè)試觀察，storm自己?jiǎn)?dòng)的線程優(yōu)先級(jí)比較高，假若你想自己的線程得到充分調(diào)用需要設(shè)置自己創(chuàng)建的線程優(yōu)先級(jí)到更高（我一般直接到最大了，然后用lock機(jī)制，然后windows和類UNIX系統(tǒng)jvm線程優(yōu)先級(jí)是有差別的，這個(gè)大家可以去深入了解下）。

6. 因?yàn)椴煌臋C(jī)器可能資源不同，storm默認(rèn)調(diào)度器機(jī)制基本是平均分配機(jī)制，這會(huì)導(dǎo)致，數(shù)據(jù)亂序情況比較嚴(yán)重。

7. storm先啟動(dòng)你的spout然后再依次啟動(dòng)不同機(jī)器上的bolt task，spout不會(huì)等bolt都啟動(dòng)完成后才開始發(fā)數(shù)據(jù)，這時(shí)假如你有一個(gè)bolt初始化耗費(fèi)1分鐘，然后你的消息超時(shí)設(shè)置的是30s，那在這個(gè)bolt啟動(dòng)完成之前的消息會(huì)因?yàn)閟pout超時(shí)設(shè)置的比較短而導(dǎo)致消息超時(shí)，從而導(dǎo)致spout fail（mid）。 好吧，我承認(rèn)這個(gè)我之前理解錯(cuò)了，storm會(huì)執(zhí)行spout的open和各個(gè)bolt的prepare，依次都初始化好后會(huì)激活spout（Activate spout），這時(shí)spout工作線程才開始執(zhí)行nextTuple。

8. topology的TOPOLOGY_RECEIVER_BUFFER_SIZE設(shè)置成16會(huì)比較快，至少在我們業(yè)務(wù)上整體速度在1w+這個(gè)速度下，設(shè)置成16比8或32要快，當(dāng)然不同的場(chǎng)景這個(gè)值可能會(huì)不同（這里要強(qiáng)調(diào)一下，storm中有四個(gè)buffer，理解起來比較別扭，而且四個(gè)buffer不是收/發(fā)對(duì)稱的，還是推薦大家去看官方文檔或權(quán)威一點(diǎn)的地去學(xué)習(xí)）

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

   
   

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

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

   
   

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

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

感謝各位的閱讀，以上就是“storm使用要注意哪些點(diǎn)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)storm使用要注意哪些點(diǎn)這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！