我們做 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。 參考資源： 2）2013，量子統計，Storm入門教程

第四章和第五章；