伴隨著資訊科技日新月異的發展，資訊呈現出爆發式的膨脹，人們獲取資訊的途徑也更加多樣、更加便捷，同時對於資訊的時效性要求也越來越高。舉個搜尋場景中的例子，當乙個賣家發布了一條寶貝資訊時，他希望的當然是這個寶貝馬上就可以被賣家搜尋出來、點選、購買啦，相反，如果這個寶貝要等到第二天或者更久才可以被搜出來，估計這個大哥就要罵娘了。再舉乙個推薦的例子，如果使用者昨天在**上買了一雙襪子，今天想買一副泳鏡去游泳，但是卻發現系統在不遺餘力地給他推薦襪子、鞋子，根本對他今天尋找泳鏡的行為視而不見，估計這哥們心裡就會想推薦你妹呀。其實稍微了解點背景知識的碼農們都知道，這是因為後台系統做的是每天一次的全量處理，而且大多是在夜深人靜之時做的，那麼你今天白天做的事情當然要明天才能反映出來啦。
全量資料處理使用的大多是鼎鼎大名的hadoop或者hive，作為乙個批處理系統，hadoop以其吞吐量大、自動容錯等優點，在海量資料處理上得到了廣泛的使用。但是，hadoop不擅長實時計算，因為它天然就是為批處理而生的，這也是業界一致的共識。否則最近這兩年也不會有s4,storm,puma這些實時計算系統如雨後春筍般冒出來啦。先拋開s4,storm,puma這些系統不談，我們首先來看一下，如果讓我們自己設計乙個實時計算系統，我們要解決哪些問題。
低延遲。都說了是實時計算系統了，延遲是一定要低的。
高效能。效能不高就是浪費機器，浪費機器是要受批評的哦。
分布式。系統都是為應用場景而生的，如果你的應用場景、你的資料和計算單機就能搞定，那麼不用考慮這些複雜的問題了。我們所說的是單機搞不定的情況。
可擴充套件。伴隨著業務的發展，我們的資料量、計算量可能會越來越大，所以希望這個系統是可擴充套件的。
容錯。這是分布式系統中通用問題。乙個節點掛了不能影響我的應用。
好，如果僅僅需要解決這5個問題，可能會有無數種方案，而且各有千秋，隨便舉一種方案，使用訊息佇列+分布在各個機器上的工作程序就ok啦。我們再繼續往下看。
容易在上面開發應用程式。親，你設計的系統需要應用程式開發人員考慮各個處理元件的分布、訊息的傳遞嗎？如果是，那有點麻煩啊，開發人員可能會用不好，也不會想去用。
訊息不丟失。使用者發布的乙個寶貝訊息不能在實時處理的時候給丟了，對吧？更嚴格一點，如果是乙個精確資料統計的應用，那麼它處理的訊息要不多不少才行。這個要求有點高哦。
在2023年storm開源之前，由於hadoop的火紅，整個業界都在喋喋不休地談論大資料。hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明——延遲大，響應緩慢，運維複雜。
有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，很多的開源專案都是以彌補hadoop的實時性為目標而被創造出來。而在這個節骨眼上storm橫空出世了。
storm帶著流式計算的標籤華麗麗滴出場了，看看它的一些賣點：
下面，我們簡單地認識一下storm這個產品。
storm主要分為兩種元件nimbus和supervisor。這兩種元件都是快速失敗的，沒有狀態。任務狀態和心跳資訊等都儲存在zookeeper上的，提交的**資源都在本地機器的硬碟上。
下圖是乙個topology設計的邏輯圖的例子。
下圖是topology的提交流程圖。
下圖是storm的資料互動圖。可以看出兩個模組nimbus和supervisor之間沒有直接互動。狀態都是儲存在zookeeper上。worker之間通過zeromq傳送資料。
雖然，有些地方做得還是不太好，例如，底層使用的zeromq不能控制記憶體使用(下個release版本，引入了新的訊息機制使用netty代替zeromq），多語言支援更多是噱頭，nimbus還不支援ha。但是，就像當年的hadoop那樣，很多公司選擇它是因為它是唯一的選擇。而這些先期使用者，反過來促進了storm的發展。
storm已經發展到0.8.2版本了，看一下兩年多來，它取得的成就：
從開源時候的0.5.0版本，到現在的0.8.0+，和即將到來的0.9.0+。先後新增了以下重大的新特性：
transactional topologies和trident都是針對實際應用中遇到的重複計數問題和應用性問題的解決方案。可以看出，實際的商用給予了storm很多良好的反饋。
我們只需要實現每個分析的過程，而storm幫我們把訊息的傳送和接受都完成了。更加激動人心的是，你只需要增加某個bolt的並行度就能夠解決掉某個結點上的效能瓶頸。
在流式處理領域裡，storm的直接對手是s4。不過，s4冷淡的社群、半成品的**，在實際商用方面輸給storm不止一條街。
如果把範圍擴大到實時處理，storm就一點都不寂寞了。
當然，storm也有yarn-storm專案，能讓storm執行在hadoop2.0的yarn框架上，可以讓hadoop的mapreduce和storm共享資源。
知乎上有乙個挺好的問答： 問：實時處理系統（類似s4, storm）對比直接用mq來做好處在**？ 答：好處是它幫你做了： 1) 集群控制。2) 任務分配。3) 任務分發 4) 監控 等等。
需要知道storm不是乙個完整的解決方案。使用storm你需要加入訊息佇列做資料入口，考慮如何在流中儲存狀態，考慮怎樣將大問題用分布式去解決。解決這些問題的成本可能比增加乙個伺服器的成本還高。但是，一旦下定決定使用了storm並解決了那些惱人的細節，你就能享受到storm給你帶來的簡單，可拓展等優勢了。
技術的發展日新月異，資料處理領域越來越多優秀的開源產品。storm的過去是成功的，將來會如何發展，我們拭目以待吧。
Storm 最火的流式處理框架
在2011年storm開源之前，由於hadoop的火紅，整個業界都在喋喋不休地談論大資料。hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明 延遲大，響應緩慢，運維複雜。有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，...
Storm流式處理框架概述
hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明 延遲大，響應緩慢，運維複雜。有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，很多的開源專案都是以彌補hadoop的實時性為目標而被創造出來。而在這個節骨眼上storm...
Storm 高效能流式計算處理框架
storm supervisor worker topology yarn mrstrom spout bolt mrdag有向無環圖 tuple stream spout bolt fields分組 all global none direct local or shuffle worker 程序...