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翻譯稿系列；
3）2011，徐明明，
Storm 如何保證消息不丟失；
贈圖一枚：
