https://yennj12.js.org/yennj12_blog_V4/tags/idempotency/Recent content in Idempotency on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-13-idempotency-state-recovery-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-13-idempotency-state-recovery-zh/核心定義：Idempotency & State Recovery 是透過「執行前寫 Checkpoint、執行後 CAS 更新狀態、恢復時重播已完成步驟」的三段式協議，確保分佈式 Agent 在任意時間點中斷並重啟後，每個工具呼叫的副作用（扣款、通知、寫 DB）恰好執行一次，不多不少。 一、為什麼面試官問這個 面試官真正在測試的是你對 分佈式系統可靠性 與 副作用管理 的成熟度。這題的背後問題是：「你知不知道 Agent 不是函數——它的執行跨越多個 Pod、多個時間視窗，任何一步都可能在已產生副作用之後失敗？」 測試點一：副作用的不可逆性。 能否清楚區分「可重試的讀操作」與「不可重試的寫操作（發信、扣款、呼叫第三方 API）」，並說明為何後者必須有去重機制。面試官想知道你是否理解「at-least-once delivery」與「exactly-once semantics」的本質差異：前者是訊息系統的保證，後者是應用層必須自己實現的語意。 測試點二：一致性模型的選擇。 能否說明為何 Checkpoint 需要強一致性（Cloud Spanner external consistency）而非最終一致性（Firestore default mode），以及這個選擇的 latency 代價（~10ms vs ~1ms）。最終一致性在此場景下會造成新 Worker 讀到舊快照，誤判步驟未完成，重複執行已完成的工具。 測試點三：恢復路徑的完整性。 能否說明 StateGraph.update_state() 如何注入已完成步驟的輸出、跳過重新執行，並在 split-brain 情境下靠 Compare-And-Swap 避免雙 Worker 各自推進狀態。 弱答案長相： 「重試的時候我們就再跑一次，加個 try-catch 就好。」沒有提到去重 key、沒有提到 Checkpoint 持久化、沒有說明如何判斷哪些步驟已完成、也沒有提到下游服務如何識別重複呼叫。這個答案在面試官眼中等同於「不懂分佈式」。 強答案長相： 從「寫 pending → 執行 → 寫 completed（CAS）」三段式出發，說明 CAS 防止 split-brain，Recovery 時透過 StateGraph.update_state() 重播 StateGraph，最後給出具體數字：Spanner 寫入 ~10ms、恢復時間 < 100ms、重複通知率 0.