At most Onece：最多一次，如果運算元處理事件失敗，事件將不再嘗試該事件。 At Least Onece：至少一次，如果運算元處理事件失敗，運算元會再次嘗試該處理事件，直到有一次成功。 Exactly Once：嚴格一次，通常有兩種方法實現： 1.分散式快照+狀態檢查點，思想就是對比檢查點和分佈 ...
-- At most Onece：最多一次，如果運算元處理事件失敗，事件將不再嘗試該事件。
-- At Least Onece：至少一次，如果運算元處理事件失敗，運算元會再次嘗試該處理事件，直到有一次成功。
Exactly-Once：嚴格一次，通常有兩種方法實現：
-- 1.分散式快照+狀態檢查點，思想就是對比檢查點和分散式快照中的狀態，如出現狀態不一致就回退到最小狀態處，重新計算。
-- 2.At least Onece + 去重，重播失敗的運算元，並刪除重覆運算元的結果。
-- 雖然從理論上看，分散式快照，和至少一次事件交付外加去重，這兩種機制之間存在差異，但兩者均可理解為至少一次處理外加冪等保證。
上文提到的兩種機制均使用持久的後端存儲作為事實來源（Source of truth），用於保存每個操作符的狀態，並自動提交狀態更新。對於機制 1（分散式快照 / 狀態檢查點），這個持久的後端存儲可用於保存流應用程式中全局一致的狀態檢查點（每個運算符的狀態檢查點）；對於機制 2（至少一次事件交付，外加去重），這個持久的後端存儲可用於保存每個運算符的狀態，以及為了追蹤哪些事件已經被成功處理過而為每個運算符生成的事務日誌。
狀態的提交或對事實來源的持久後端進行的更新可描述為事件（Occurring）的嚴格一次。然而在計算狀態的更新 / 改動，例如所處理的事件正在針對事件執行各種用戶定義的邏輯時，如果失敗則可能進行多次，這一點正如上文所述。換句話說，事件的處理可能會進行多次，但處理的最終結果只會在持久的後端狀態存儲中體現一次。因此 Streamlio 認為“實際一次（Effectively-once）”可以更精確地描述這樣地處理語義。
