Storm 是如何跟蹤一條消息以及它衍生出來的消息都被成功處理的

2012·2彙總

咱們作 Notify Server 時能夠間接借鑑這個解決方案的思路。

 

Storm 是一個分佈式的、容錯的實時計算系統，由 Twitter 開源。

先不介紹術語和背景知識，直接來一些吸引眼球的內容：

 

一，Tuple Tree

spout 發射一個消息(tuple)，可能會致使成百上千的消息基於此消息被建立。這些消息構成一個樹狀結構，咱們稱之爲「tuple tree」。

tuple 是如何被跟蹤的呢？系統中有成千上萬的消息，若是爲每一個 spout 發送的消息都構建一棵樹的話，很快內存就會耗盡。因此，必須採用不一樣的策略來跟蹤每一個消息。

 

二，Acker 跟蹤 Tuple

acker 對於 tuple 的跟蹤算法是 storm 最大的突破。這個算法使得 對於任意大的一個 tuple tree， 它只須要恆定的20字節就能夠進行跟蹤了。

 

Storm 系統中有一組叫作「acker」的特殊任務，它們負責跟蹤 DAG（有向無環圖）中的每一個消息。每當發現一個 DAG 被徹底處理，它就向建立這個根消息的 spout 任務發送一個信號。

原理很簡單：

1）當一個消息被建立的時候（不管是在 spout 仍是 bolt 中），系統都爲該消息分配一個 64bit 的隨機值做爲id。這些 messageid 是 acker 用來跟蹤由 spout 消息派生出來的 tuple tree 的。

2）acker 對於每一個 tuple 保存一個 ack-val 的校驗值（一個64 bit數字），它的初始值是0。 而後每發射一個 tuple （即消息的建立），或者 ack 一個 tuple （即消息的被應答），那麼 tuple 的 id 都要跟 ack-val 異或一下，而且把獲得的值更新爲 ack-val 的新值。假設每一個發射出去的 tuple 都被 ack 了， 那麼最後 ack-val 必定是0(由於一個數字跟本身異或獲得的值是0)。

 

總的來講， ack-val 是這棵樹上全部建立的 tuple-id 以及 ack 的 tuple-id 一塊兒異或(XOR)。ack-val 表示了整棵樹的的狀態，不管這棵樹多大，只須要這個固定大小的數字就能夠跟蹤整棵樹。

每當 acker 發現一棵樹的 ack val 值爲0時，它就知道這棵樹已經被徹底處理了。

由於消息的隨機ID是一個64bit的值，所以ack val在樹處理完以前被置爲0的機率很是小。

 

三，Acker 有不少，選擇哪個呢？

當一個 tuple 須要 ack 的時候，它到底選擇哪一個 acker 來發送這個信息呢？

storm   用一致性哈希來把一個 tuple-message-id 對應到 acker  ， 由於每個 tuple 知道它全部的祖宗的 tuple-message-id， 因此它天然能夠算出要通知哪一個 acker 來 ack。

 

參考資源：

1）2011，徐明明， Storm翻譯稿系列；

2）2013，量子統計，Storm入門教程 第四章和 第五章；

3）2011，徐明明， Storm 如何保證消息不丟失；

贈圖一枚：