At-Least-Once Delivery
至少投遞一次
至少投遞一次會盡量避免訊息遺失，但同一則訊息可能送達不只一次。消費者必須能安全處理重複訊息。
deliver -> process -> acknowledge/delete; missing acknowledgement -> redeliver; event ID -> dedupeevt_784deliver -> process -> acknowledge/delete; missing acknowledgement -> redeliver; event ID -> dedupeJOB另一個例子
工作程序已儲存收據 `evt-42`，卻在刪除 Amazon SQS 訊息前停止。SQS 之後再次投遞同一則訊息。下一個工作程序看到已保存的事件 ID，就回傳原收據，不會再做一份。
主要部分
- 01穩定訊息 ID
- 02投遞嘗試
- 03工作程序做出的結果
- 04確認或刪除訊息
- 05重新投遞路徑
- 06重複處理紀錄
什麼時候用
遺失一項工作比重複處理更糟時，可以採用這種規則。每則訊息要有固定 ID。同一訊息再次送達時，不可多扣款、多寄信或多存一份。
什麼時候不要用
訊息送達不代表工作成功。不要承諾只會產生一次結果。扣款或外部操作都需要自己的防重複機制。
程式裡的名稱
deliver -> process -> acknowledge/delete; missing acknowledgement -> redeliver; event ID -> dedupe 上線前要檢查
檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。
預期成果：為這套系統設計或檢查 至少投遞一次 (At-Least-Once Delivery)，並讓資料保持正確、安全且容易維護。 使用者情境：工作程序已儲存收據 `evt-42`，卻在刪除 Amazon SQS 訊息前停止。SQS 之後再次投遞同一則訊息。下一個工作程序看到已保存的事件 ID，就回傳原收據，不會再做一份。 技術概念或控制措施：至少投遞一次 (At-Least-Once Delivery)。 適用理由：遺失一項工作比重複處理更糟時，可以採用這種規則。每則訊息要有固定 ID。同一訊息再次送達時，不可多扣款、多寄信或多存一份。 不應使用的情況：訊息送達不代表工作成功。不要承諾只會產生一次結果。扣款或外部操作都需要自己的防重複機制。 工程要求：定義輸入、輸出、介面約定，以及任何情況都不能破壞的規則。說明授權與輸入檢查範圍。定義失敗、逾時、重試和重複執行只生效一次的規則。也要定義資料搬移與相容限制。 營運要求：加入監控訊號與隱藏敏感資料的記錄。設定容量上限並寫好操作手冊。測試復原與回復上一版的流程。 驗收條件：介面約定與失敗路徑測試通過。重試或部分失敗時，資料與授權規則仍正確。效能上限、監控、復原與回復上一版的方法都已驗證。 證據與限制（證據邊界）：沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認：程式執行環境、資料位置、流量形態、資料一致需求和安全邊界。也要確認相容期間、服務目標（SLO）與回復上一版的限制。
檢查這份需求
請 AI 程式助手檢查目前如何使用 至少投遞一次 (At-Least-Once Delivery)。 定義：至少投遞一次會盡量避免訊息遺失，但同一則訊息可能送達不只一次。消費者必須能安全處理重複訊息。 正式環境檢查：檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。 修改程式前，先列出看到的證據、缺口、嚴重程度，以及最小且安全的修正。