在現代的自動化系統中，工作流（Workflow）往往需要跨越長時間且經歷多個步驟，例如從偵測 Kubernetes 故障、執行 AI 根因分析，到等待人類在 Slack 上核准，最後才提交 GitOps 的拉取請求（Pull Request）。這類流程面臨的核心挑戰在於「持久化執行」（Durable Execution）：當執行過程中的伺服器因為記憶體不足（OOM）被殺掉或 Pod 被重新調度時，工作流不能直接遺失，而必須能從上一個完成的檢查點（Checkpoint）恢復。
通常開發者的首選是引入像 Temporal 或 AWS Step Functions 這樣的外部調度器（External Orchestrator）。這些系統負責協調步驟、保存狀態並分發任務。然而，引入外部調度器意味著增加了一個有狀態的複雜系統，開發團隊必須額外維護其部署、安全性、監控與升級，且調度器本身可能成為單點故障（Single Point of Failure）。此外，工作流的數據（如基礎設施拓撲、日誌）必須傳輸到外部系統，增加了安全審計的複雜度。
事實上，持久化執行的本質就是將狀態檢查點保存到持久化存儲中。既然大多數系統已經運行著 PostgreSQL 作為核心資料庫，那麼將 PostgreSQL 直接作為調度器，將狀態管理與業務資料整合在同一個可靠系統中，便成了一個更簡潔的選擇。
核心運作機制：將資料表轉化為併發隊列
要在沒有專門調度器處理的情況下實現工作流，關鍵在於如何讓多台無狀態的應用伺服器安全地領取任務。Kestrel Workflows 的做法是利用 PostgreSQL 的 SELECT ... FOR UPDATE SKIP LOCKED 語法。
這是一個強大的併發控制機制。當一個工作節點嘗試領取任務時，FOR UPDATE 會鎖定該行，而 SKIP LOCKED 則告訴其他併發的節點直接跳過已被鎖定的行，而不是在那裡阻塞等待。這使得單個 PostgreSQL 表能直接轉化為一個高效的併發工作隊列，保證每個工作流執行實例在同一時間僅由一個工作節點處理，實現了「恰好一次」（Exactly-once）的處理保證，而無需額外引入消息代理（Message Broker）或分散式鎖服務（如 Redis）。
在實務操作中，領取任務的交易（Transaction）必須保持極短。工作節點僅在交易中鎖定行、將狀態更新為「運行中」並寫入租約（Lease）時間後立即提交。如果將整個外部 API 調用或耗時步驟放在交易內，會導致資料庫行鎖定時間過長，嚴重影響系統吞吐量。
利用資料庫約束強制實現冪等性
持久化執行最擔心的問題是：當工作節點崩潰並由新節點接手時，重複執行已完成的步驟可能會導致副作用（Side Effect）。為了避免此問題，可以利用資料庫的完整性約束（Integrity Constraints）來強制實現冪等性（Idempotency）。
具體做法是建立一個操作輸出表（operation_outputs），將「執行 ID」與「步驟 ID」設為複合主鍵（Primary Key）。當一個步驟完成後，工作節點使用 INSERT ... ON CONFLICT DO NOTHING 將結果寫入。如果恢復後的節點嘗試重新執行該步驟，資料庫的主鍵約束會阻止重複寫入。工作節點只需檢查該表是否存在對應記錄，若存在則直接讀取結果並跳過執行。這樣一來，冪等性的保證由資料庫層級而非應用程式邏輯來維護，大幅降低了分散式系統的開發複雜度。
故障恢復與長時間等待的處理
針對工作節點在執行中突然消失（如 Pod 被驅逐）的情況，系統採用「租約與掃描器」（Lease and Sweeper）模式。工作節點在處理任務時會定期更新租約時間（Heartbeat）。系統會運行一個週期性的掃描程序，將那些租約已過期且狀態仍為「運行中」的任務重新設回「排隊中」，讓其他健康節點接手。
對於需要長時間等待（如等待人類核准）的步驟，則不需要讓線程在記憶體中睡眠，而是將其狀態設為「等待中」，並在專屬表中記錄一個喚醒時間（wake_at）。掃描器會定期檢查並將到期的等待任務重新投入隊列。這種方式無論等待兩小時或兩週，對系統資源的消耗僅僅是一行資料庫記錄。
實務影響、限制與優勢
這種將調度功能下沉到 PostgreSQL 的方案，在可觀測性（Observability）上有極大優勢。由於所有狀態都是關聯式資料，監控工作流變成了簡單的 SQL 查詢。開發者可以直接透過 JOIN 查詢分析「哪些修復方案在哪個步驟被拒絕」，而不需要將數據從 Key-Value 存儲導出到分析系統。同時，可靠性與安全性也隨之簡化，因為系統僅依賴於已經經過驗證的 PostgreSQL 高可用方案（如串流複製與多可用區故障轉移）。
然而，此方案並非適用於所有場景。在高併發壓力下，大量工作節點頻繁輪詢（Polling）會對 PostgreSQL 的連接數造成壓力，此時需要引入 PgBouncer 等連接池工具。此外，頻繁的更新與刪除會產生死元組（Dead Tuples）導致表膨脹（Bloat），需要對 Autovacuum 進行精細調優或使用分區表來隔離已完成的任務。
總結來說，如果業務場景是 I/O 密集型的自動化管線，且對分發延遲的要求在毫秒級以上，利用 PostgreSQL 實現持久化工作流能有效降低運維複雜度並提升數據一致性。但若需要支撐數千個工作節點且追求極低延遲的分發，則專門的外部調度器仍是更合適的選擇。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。