Storm系列之——基本概念

寫在前面的話：

        請允許我廢話幾句。這個系列的文章發佈的時間是在我完成了Storm的項目開發之後才找出來時間寫的，在研究Storm過程中，國內較好的參考文章實在有限，大多是入門和概念剖析。Storm的GoogleGroup對於新手來說實在不友好。有經驗人士都不願意回答新手的一些“愚蠢”的問題。現在因爲Storm移交了Apache，正式啓用了ApacheMailGroup就更不友好了……中間我走過不少彎路，自己摸索和看源碼。雖然說自己理解的纔是最深刻的，但是我覺得還是分享出來，減少大家走彎路時間，把注意力更多的放在Storm的應用探討上。或許文章中會有錯誤，或許文章會“太監”，或許你只是遇到了一篇筆記而已。

介紹文章內寫太多基本原理性東西，反而容易讓人暈，所以在本篇中，只是點出基本概念模型，同時share一些基本資料給能力強的同學去研究。

轉載請註明：轉自http://blog.csdn.net/xeseo/article/details/17674775

---

有關Storm的一些信息片

Storm是由twitter在2011開源出來的產品，現在貢獻給了Apache。

1. Storm官方主頁：http://storm-project.net/ 看上去不是非常的Apache，所以以後有可能改爲Apache的URL樣式。

這個主頁目前信息量有限。大多數好東西，在其github首頁：https://github.com/nathanmarz/storm （最近剛剛把repo轉移了到Apache孵化項目頁https://github.com/apache/incubator-storm）

2. 最重要的東西在這：https://github.com/nathanmarz/storm/wiki ，與Storm相關的概念性知識90%都在這裏了。

不過作者把文章目錄直接交給了github的Pages來管理，對於github新手來說可能會忽視這個有用的頁面：https://github.com/nathanmarz/storm/wiki/_pages

3. 國內分享內容有深度的blog非StormContributor之一的徐明明的blog莫屬：http://xumingming.sinaapp.com/category/storm/ 顯然他不愧是Storm的貢獻者之一啊，連文檔管理都有Storm的風格。。。。。。

4. 寫的非常好的，有圖有證據的量子恆道官方博客Storm系列：http://blog.linezing.com/category/storm-quick-start?spm=0.0.0.0.rTjmpX 

Storm是什麼？

https://github.com/nathanmarz/storm/wiki/Rationale 官方的

http://www.searchtb.com/2012/09/introduction-to-storm.html 淘寶

http://blog.linezing.com/2012/12/storm%E5%85%A5%E9%97%A8%E6%95%99%E7%A8%8B-%E7%AC%AC%E4%B8%80%E7%AB%A0-%E5%89%8D%E8%A8%80?spm=0.0.0.0.rjCR7D 量子恆道

以下是我的理解：

直接面向客戶的互聯網網頁，如電子商務，都注重客戶體驗，所以客戶操作儘量簡單化，即流水線化，如登陸->搜索->下單->(推薦)->付款。所以，形象點，一個業務流程即一個流水。那麼，如果具有相當大業務流程併發時，N個流水就變成了瀑布、長江、黃河。在這種情況下，傳統的單機處理是無法滿足性能需求的。必須得分佈式處理。Storm就提供了一個分佈式流處理框架，可以讓開發者很容易的建立一個健壯的分佈式程序，而不用過於關心底層分佈式的實現。

基本模型

Storm的現實模型就是水流的處理，例如小區供水。

• 數據來源定義爲Spout，源源不斷的供給水流。
• 水流在管道中流行，定義爲Stream。
• 每個住戶都會消費水，是Stream中的一個節點，定義爲Bolt。可能會將消費的水排放，也或許不排。
• 一個小區的Spout、Stream、Bolt組合在一起，即一個拓撲結構，定義爲Topology。

紅色強調部分，在Storm的實現中，真的就是這麼做的。我會在後面的文章中去解釋。

Storm實現：

Spout：        數據源，源源不斷的發送元組數據Tuple

Tuple：         元組數據的抽象接口，可以是任何類型的數據。但是必須要可序列化。

Stream：     Tuple的集合。一個Stream內的Tuple擁有相同的源。

Bolt：             消費Tuple的節點。消費後可能會排出新的Tuple到該Stream上，也可能會排到到其他Stream，也或者根本不排。可併發。

Topology： 將Spout、Bolt整合起來的拓撲圖。定義了Spout和Bolt的結合關係、併發數量、配置等等。

有圖有真相：

Storm的特點

這裏Storm的幾個特性比較重要，是我們在選取是否使用Storm時要參考的：

• 支持很多用戶場景：
  • 處理消息->更新db，典型的流處理
  • 不停的實時查詢，並把查詢結果反饋給客戶端
  • 通過其分佈式框架，實現並行計算，把計算結果交給客戶端(distribute RPC)
• 縱向擴展性
  • 可以在Topology中的定義Spout、Bolt的並行度
• 保證無數據丟失
• 健壯
  • Storm的健壯是因爲它只關係最核心的功能，弱化管理。因爲簡單而健壯。
• 容錯能力
  • 這個其實Storm的設計原則。Storm的任意節點，理論上都應該是一直運行而不停止的，即使遇到錯誤，直到被停止。後面的文中，我會提到如何正確的處理錯誤。
• 多語言支持

基本工作框架

nimbus

很形象的取名，雨雲，產生雨點的。它的作用有：

• 整個topology的發起者，會把topology的jar包緩存到本地
• 在提交topology時，分配資源
• 在topology運行時，監聽所有worker的心跳
• 當某worker掛掉或收到重新分配請求時，重新分配資源

注意：

當一個topology被正常分配、啓動後，nimbus只會監控supervisor的狀態，爲重新分配資源做準備。並不會做Stream中tuple分配到某節點這種事。

所以，如果nimbus在topology正常運行時掛掉，是不會影響該topology的正常運行的。它影響的是重新分配cluster資源。

supervisor

真正的工作節點。在其內部運行的可能是一個spout、亦可能是一個bolt。

• 每一個supervisor會定義若干worker，每一個worker其實是一個獨立的JVM進程，具有不同的端口號
• 每一個worker內會維護一個線程池，每一個線程，在Storm中稱爲executor
• 並行中的每一個spout、bolt對於supervisor中的worker來說是平等的，被認爲是一個task。該task的執行會被worker分配到其內部線程池中的某一個或多個線程，即某一個或多個executor去執行
• executor的數量<=spout數+bolt數+acker數 <= task總數。默認情況下是取=

注： acker 是個什麼東西，後面的文章會講述。這裏暫且不提。

舉例：

在該例子中，

blue spout並行度 = 2

green bolt並行度= 2

yellow bolt並行度 = 6

在不計acker的情況下，默認總的線程數 = 2+2+6 = 10. 兩個節點的兩個worker，在平均分配下，就是每個節點5個，即每個worker的線程池中有5個executor。

均勻分配，兩個worker各得三個yellow bolt, 一個blue spout，和一個green bolt。

但是,green bolt在配置時，表明需要兩個executor和四個task。所以在兩個worker上，每個其實要處理 3(yellow bolt) + 1(blue spout) + 2(green bolt) = 6個task。

由於每個worker我們只配了5個executor，所以這6個task就在5個executor上輪循執行。而事實上，Storm做了優化，對於同一個類型的task，會交由同一個executor去處理。

所以，在每個節點上，會有固定的3個executor去執行yellow bolt, 一個固定的executor去執行blue spout，一個固定的executor去執行兩個green spout。

zookeeper

zookeeper是Storm分佈信息存儲的地方。

• nimbus會在zookeeper上建立topology的相關信息（包括如何分配）
• supervisor會監聽zookeeper，一旦有新的分配任務，就會去領下來去交由worker執行
• zookeeper會保存worker的心跳情況，如果nimbus發現某個worker心跳丟失，就會重新分配資源

所以，這裏真正會影響到集羣運行的是zookeeper。一旦zookeeper掛掉，整個Storm就無法工作了。