在2023年storm開源之前，由於hadoop的火紅，整個業界都在喋喋不休地談論大資料。hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明——延遲大，響應緩慢，運維複雜。
有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，很多的開源專案都是以彌補hadoop的實時性為目標而被創造出來。而在這個節骨眼上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就一點都不寂寞了。
知乎上有乙個挺好的問答： 問：實時處理系統（類似s4, storm）對比直接用mq來做好處在**？ 答：好處是它幫你做了： 1) 集群控制。2) 任務分配。3) 任務分發 4) 監控 等等。
需要知道storm不是乙個完整的解決方案。使用storm你需要加入訊息佇列做資料入口，考慮如何在流中儲存狀態，考慮怎樣將大問題用分布式去解決。解決這些問題的成本可能比增加乙個伺服器的成本還高。但是，一旦下定決定使用了storm並解決了那些惱人的細節，你就能享受到storm給你帶來的簡單，可拓展等優勢了。
技術的發展日新月異，資料處理領域越來越多優秀的開源產品。storm的過去是成功的，將來會如何發展，我們拭目以待吧。
Storm概念理解
組成 topology是storm裡的最高抽象概念，相當於hadoop裡的mapreduce，topology 流轉換圖 由spouts和bolts組成。spout建立stream，stream由無限的tuple 元組 構成。bolts接收spout流出的tuple並進行處理，處理後生成的新的tup...
storm併發度理解
乙個執行中的拓撲是由什麼組成的 worker程序，executors和tasks。storm是按照下面3種主要的部分來區分storm集群中乙個實際執行的拓撲的 worker程序 executors 執行緒 以及真正實施計算的 tasks 任務 先簡單回顧一下storm幾個核心概念 同時還有幾個關鍵的...
python裝飾器（還未看完）
參考 原函式無引數 def debug func def print debug enter format func.name return func debug defsay hello print hello 裝飾器引數為原函式，返回值為內部定義的函式 原函式有引數 def debug func...