共計 2629 個字符，預(yù)計需要花費 7 分鐘才能閱讀完成。
這篇文章主要講解了“storm 使用要注意哪些點”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學(xué)習(xí)“storm 使用要注意哪些點”吧！
個人理解：storm 是一個分布式、實時、流、計算、平臺，幾個特性從這名字中已經(jīng)看出來了。
一、實時，簡單理解就是數(shù)據(jù)進入系統(tǒng)要迅速被處理，也就是延遲要小。
二、流，流具有什么特點，想象一下你站在長江岸邊，什么感覺，震撼？浩蕩？小弟沒看過，我理解的流就是①沒有阻塞②方向只能從高到低③流之間沒有影響④可以靈活改變流的方向（挖個溝，對應(yīng) storm 的 grouping 機制）⑤不間斷
三、計算，這個概念其實比較廣，計算機處理任何東西一般都涉及計算，在這里我理解的還是沒有阻塞，也就是更傾向于計算，不要和外部過多資源進行交換，例如網(wǎng)絡(luò)、磁盤。。。
四、分布式，分布式大家聽的耳朵都起繭子了，個人有個人的理解，分布式一個比較重要的衡量指標(biāo)就是可擴展性（線性、非線性）、資源對服務(wù)或用戶透明、具有一定的負載均衡能力、充分利用資源？（好像國內(nèi)好多搞 hadoop 的都用牛逼服務(wù)器，貌似 hadoop 出來是為了利用那些過時老舊的機器的）、最好是無序。。。
五、平臺，這個好理解，它就是提供了以上四個主要特性的平臺，那滿足這個平臺要求的服務(wù)就可以在這個平臺上跳舞，一個好的平臺可以改變我們的命運哦~
六、可靠性，分布式系統(tǒng)那么多組件，某個出現(xiàn)了問題 storm 可以自動恢復(fù)
適應(yīng)場景
從以上 5 點可以總結(jié)出 storm 注重的是實時性、偏重計算、分布式特性、線性可擴展、流的特性。當(dāng)然有了這些特性最終還是要靠到業(yè)務(wù)邏輯上，這個我寫過一篇基于 storm 做爬蟲的可能性，我覺得在爬蟲的場景里邊，用 storm 是再好不過的了，因為爬蟲一般是 7 *24 小時不間斷的從網(wǎng)絡(luò)上獲取數(shù)據(jù)，構(gòu)成了流，一般還要求實時性，就是盡快將最新的內(nèi)容搞到自己的口袋里，計算量也不小涉及到各種數(shù)據(jù)的處理，然后遇到瓶頸后可以平滑的進行線性可擴展，無需停止服務(wù)，最主要一點是爬蟲種子間處理沒什么關(guān)聯(lián)，完全切合分布式的特性，總之等等吧，我覺得如果把爬蟲放到 storm 上猶如楊過獲得了一把屠龍刀。
注意幾點（實踐出真知？）
一個 worker 被 kill 情況下，假如這個 worker 和其它 worker 沒有關(guān)系，貌似其它 worker 不會受影響，被 kill 的 worker 會被 storm 啟動，若和其它 worker 有關(guān)系，那么其它 worker 也會受影響，task 會被重新啟動（類似于 rebalance 的效果，好像和 rebalance 的過程一樣）。
acker 貌似是就近原則，一個 spout 的消息優(yōu)先采用本地 acker 跟蹤，經(jīng)測試效果看，一旦 acker 被 kill，當(dāng)這個 acker 再次被啟動的時候，其之前跟蹤的那些消息將迅速失敗。
acker 無法被 rebalance。
大家都知道 storm 中 nextTuple 和 ack 或 fail 方法是在一個線程下執(zhí)行的，經(jīng)測試觀察，storm 會先調(diào)用 spout 的 nextTuple() 然后再檢查 ack(mid) 或 fail(mid)，再配合 storm 的 pending 機制，這個大家有時需要注意，在特定的需求下可能會有類似于死鎖的問題。（這里不詳細說明，如有需要可以留言給我，因為只是在我們的特定需求上出現(xiàn)過問題）。
storm 雖然不建議大家在 bolt 或 spout 中 new 新的線程，但有時為了異步處理，也是不可避免的，經(jīng)測試觀察，storm 自己啟動的線程優(yōu)先級比較高，假若你想自己的線程得到充分調(diào)用需要設(shè)置自己創(chuàng)建的線程優(yōu)先級到更高（我一般直接到最大了，然后用 lock 機制，然后 windows 和類 UNIX 系統(tǒng) jvm 線程優(yōu)先級是有差別的，這個大家可以去深入了解下）。
因為不同的機器可能資源不同，storm 默認(rèn)調(diào)度器機制基本是平均分配機制，這會導(dǎo)致，數(shù)據(jù)亂序情況比較嚴(yán)重。
storm 先啟動你的 spout 然后再依次啟動不同機器上的 bolt task，spout 不會等 bolt 都啟動完成后才開始發(fā)數(shù)據(jù)，這時假如你有一個 bolt 初始化耗費 1 分鐘，然后你的消息超時設(shè)置的是 30s，那在這個 bolt 啟動完成之前的消息會因為 spout 超時設(shè)置的比較短而導(dǎo)致消息超時，從而導(dǎo)致 spout fail（mid）。 好吧，我承認(rèn)這個我之前理解錯了，storm 會執(zhí)行 spout 的 open 和各個 bolt 的 prepare，依次都初始化好后會激活 spout（Activate spout），這時 spout 工作線程才開始執(zhí)行 nextTuple。
topology 的 TOPOLOGY_RECEIVER_BUFFER_SIZE 設(shè)置成 16 會比較快，至少在我們業(yè)務(wù)上整體速度在 1w+ 這個速度下，設(shè)置成 16 比 8 或 32 要快，當(dāng)然不同的場景這個值可能會不同（這里要強調(diào)一下，storm 中有四個 buffer，理解起來比較別扭，而且四個 buffer 不是收 / 發(fā)對稱的，還是推薦大家去看官方文檔或權(quán)威一點的地去學(xué)習(xí)）
先這么多。。。想起什么了，后期再補充
bolt 處理錯誤不好往 spout 傳，也就是一個 tuple 處理失敗了，spout 端只能知道失敗的消息的 id，而不知道具體失敗的原因，這塊兒我覺得不是很靈活，當(dāng)然要是在一個 worker 下不會有這種問題，只出現(xiàn)在分布式環(huán)境下。
bolt emit 一個 tuple 雖然可以 anchor（錨定）到一個 list Tuple，但是 collector 的 ack 或 fail 方法只能接收單個 tuple，不能直接 ack/fail 一個 list Tuple，如下代碼：
collector.emit(TopoUtil.StreamId.DEFAULT,
list,
new Values(sonSMessage));
for (Tuple tuple : list) {collector.ack(tuple);
}storm rebalance 經(jīng)測試看有點問題，就是 - n 參數(shù)只能從一開始提交的進程數(shù) rebalance 到更小，不能從 2rebalance 到 3 或 4 或更大，- e 參數(shù)沒有這個問題，但線程數(shù)是不能大于 task 數(shù)的，這個弄過 storm 都知道，前面需要注意
感謝各位的閱讀，以上就是“storm 使用要注意哪些點”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對 storm 使用要注意哪些點這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
