一個storm拓撲有一系列特殊的“acker”任務用來跟蹤 每一個spout傳送的所有tuple的dag（directed acyclic graph有向無環圖）。當一個acker看到一個dag完成以後，它會給創造spout touple的spout task傳送一個應答ack訊息。你可以設定一個拓撲的acker task的個數在Config.TOPOLOGY_ACKERS，預設情況下每個任務的每個worker有一個acker。

理解storm可靠性的最好方式是看tuple的生命週期和tuple dags。當一個拓撲中的一個tuple產生時，無論他是一個spout或者一個bolt，都會隨機給定一個64位的id，這些id用來讓ackers跟蹤dag中的每一個spout tuple。

每個tuple知道存在於他們的tuple 樹的spout tuple的ids（也就是這個tuple的源tuple的id（祖宗id）） ，問你在一個bolt中傳送一個新的tuple時，他的源spout tuple id會被複制給這個新的tuple。當一個tuple被ack，他傳送一個訊息到正確的acker task，資訊內容包括這個tuple tree是怎麼改變的。特別的，他會告訴acker“我是這個源spout tuple的tuple樹內部完成的，並且這些是從我產生的新的tuples”。（請繼續跟蹤他們）

例如，如果tuple“D"和”E“是基於tuple”C”產生的，那麼當C ack的時候，tuple 樹是這樣變化的：

由於C從樹中被刪除的同時D和E同時被新增進樹，這個樹絕不會被永久性的完成。

還有一些細節，正如前文所提到，你可以在一個拓撲中有一個任意個數的acker tasks，那麼引出一個問題：當拓撲中的一個tuple被ack了，他怎麼知道給哪個ack task傳送這個ack訊息呢？

storm使用mod hashing來處理spout tuple和ack task之間的對映。由於每個tuple都會攜帶他所處的所有tuple tree的所有源spout tuple id，因此他們知道要跟哪個ack task交流。

另一個storm的細節是ack tasks如何跟蹤哪一個spout task負責的所有spout tuple。當一個spout task傳送一個新的tuple，他簡單地給正確的acker傳送一個訊息告訴他他要跟蹤的任務id，然後當一個acker看到一個樹被完成，他知道要給哪個task id傳送完成訊息。

ack task不顯式跟蹤tuples的tuple tree，對於那些有幾千個節點或者更多的節點的大型tuple樹，跟蹤所有tuple tree可能會用ackers壓倒性的佔用記憶體。替而代之的是，ackers 採取不同的策略，每個源spout id只需要一個固定空間（20bites）。這個跟蹤演算法就是storm工作的關鍵，也是他所取得的重大突破之一。

一個acker儲存了一個從spout tuple id到 一對數值的一個對映。這一對值中，第一個值是task id，就是創造了spout touple 的task id（spout task id）這個id用來接收完成訊息。第二個值是64位的“ack cal”。ack val是整個tuple 樹的狀態的表現形式，無論這個樹多大或者多小，他都是所有無論是acked或者created的tuple id異或的結果。

當一個acker task發現一個ack val變成了0，他就知道這個tuple tree已經完成了。由於tuple id是一個隨機的64位數，ack val突然變成0 的機率及其小，數學上，每秒鐘10K ack，需要花50000000年才會出現一個錯誤。即使是這樣，那個拓撲的tuple失效了也只會導致資料丟失。

現在，總結storm是如何避免資料丟失的：

由於一個task掛掉了而導致一個tuple不能acked：這種情況下這個失效的tuple所在的樹的源spout tuple id將會超時，然後會被重發

acker task 掛掉：這種情況下所有這個acker跟蹤的spout tuple id會超時並且重發

spout task掛掉：這個spout交流的source將會重發訊息，例如，佇列如Kestrel和RabbitMQ 當一個使用者失去連線以後將會替換佇列中所有掛起的訊息。

因此，storm的可靠性機制是完全分散式的、可拓展的、和可容錯的。

acker task是輕量級的，一個拓撲中不需要太多acker task，你可以從storm UI（component id“_acker”）中跟蹤他們的效能，如果吞吐量看著不太對，你可能需要增加更多的acker tasks。

如果可靠性不重要，你可以忍受發生故障情況下的資料丟失，你可以不跟蹤spout tuple，不跟蹤可以減少一半的訊息傳送量，（因為一般每個樹裡的沒個tuple都有一個ack message要傳輸）還能減少頻寬。

有三種方法可以去除可靠性，這裡不詳述了