在沒有競態條件的情況下處理並發更新

問題
1

嗨各位，
我在使用 PostgreSQL 搭配 n8n，我想要了解在同一時間多個工作流更新同一筆紀錄的最佳方式。
例如，兩個 webhook 執行可能會嘗試同時更新同一行：UPDATE orders
SET status = ‘processed’
WHERE order_id = 1001;
我的顧慮是避免以下問題：
遺失的更新
競態條件
重複處理
資料不一致
我一直在研究列級鎖定（FOR UPDATE）、樂觀鎖定和交易，但我不確定哪種方法在生產 n8n 環境中效果最好。
對於使用 PostgreSQL 執行高並發工作流的人員：
• 你只依賴交易，還是也使用列級鎖定？
• 你何時會選擇樂觀鎖定而不是悲觀鎖定？
• 你經歷過死鎖嗎，你如何處理的？
• 在保持資料一致性而不影響效能方面有什麼生產建議嗎？
我很想聽聽其他人在真實的 n8n 部署中什麼有效果。

描述問題/錯誤/問題

錯誤訊息是什麼（如果有的話）？

請分享你的工作流

(在你的畫布上選擇節點，然後使用鍵盤快速鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 來複製並貼上工作流。)

分享最後一個節點返回的輸出

你的 n8n 設置資訊

  • n8n 版本：
  • 資料庫（預設：SQLite）：
  • n8n EXECUTIONS_PROCESS 設定（預設：own、main）：
  • 透過以下方式運行 n8n（Docker、npm、n8n cloud、桌面應用）：
  • 作業系統：
2

最佳方法取決於相同記錄的更新頻率，但對於大多數高並發工作流程，交易和行級鎖定搭配使用效果很好。

建議方法

使用交易並在更新前鎖定該行：BEGIN;

SELECT *
FROM orders
WHERE order_id = 1001
FOR UPDATE;

UPDATE orders
SET status = ‘processed’
WHERE order_id = 1001;

COMMIT;

這可以防止其他交易在當前交易完成之前修改同一行。

針對大容量系統
保持交易簡短
為經常查詢的欄位建立索引
如果更新衝突很少見，請使用樂觀鎖定

3

嗨 @Keira_Becky
對於像你範例這樣的單一狀態翻轉，跳過明確的鎖定，讓 UPDATE 本身充當守衛。一個原子語句，只有在行尚未被處理時才會觸及該行：

UPDATE orders
SET status = 'processed'
WHERE order_id = 1001 AND status <> 'processed'
RETURNING order_id;

第一次執行會更新該行，第二次執行時不匹配任何行，所以 RETURNING 返回空結果，然後你根據「我是否得到一行回傳」來分支判斷它是否已被處理。這在一個語句中消除了遺失更新和重複處理，無需多步驟交易。

如果你確實需要一個真正的讀取-修改-寫入並帶有明確的鎖定，它必須在單一 Execute Query 節點內運行，或打開該節點的 Transaction 選項。各個 Postgres 節點各自開啟自己的連線，所以在一個節點中取得的鎖會在下一個節點運行前被釋放，鎖就沒有作用了。

對於併發工作者提取批次時的死鎖，使用 SKIP LOCKED 讓各個工作者取得不同的行，而不是阻止在同一行上：

SELECT order_id
FROM orders
WHERE status = 'pending'
FOR UPDATE SKIP LOCKED
LIMIT 100;

然後在該節點上設定 Retry On Fail，這樣暫時性的序列化錯誤就只會重試。

4

嘿 @Keira_Becky

在任何接觸 PostgreSQL 的 n8n 工作流中，務必將資料庫操作包裝在單一交易中。在 n8n 中，這是透過「Start Transaction」節點、所需的 SELECT/UPDATE 陳述式和「Commit Transaction」（或在發生錯誤時執行 Rollback）來完成的。交易保證失敗會中止整個變更集合，防止部分更新，並即使在工作流當機時也能保持資料一致。

悲觀鎖定（SELECT … FOR UPDATE 或 FOR UPDATE SKIP LOCKED）最適合用在需要恰好一次處理、許多背景工作者爭奪相同少數行，或邏輯涉及多個必須保持同步的行時。鎖定會一直持有到交易提交為止，確保沒有其他工作流可以讀取或修改被鎖定的行，這樣可以消除遺失的更新和重複處理。

樂觀鎖定在競爭較少時效果最好。透過新增 version（或 updated_at）欄位，並使用 WHERE version = $oldVersion 這樣的條件進行更新，你可以讓並行背景工作者嘗試更新；只有第一個會成功，其他的則會偵測到衝突（受影響的行數為零）並可以重試。此方法避免了鎖定的額外負荷，適用於批次更新或無狀態 webhook 執行，其中簡單的重試迴圈就足夠了。

即使進行謹慎的鎖定，當工作流以不同的順序鎖定行時，也可能會發生死鎖。透過始終以確定性的順序獲取鎖定（例如，ORDER BY order_id ASC）、在佇列型處理中使用 SKIP LOCKED，以及為 40P01 死鎖錯誤實施重試邏輯來減輕死鎖。監控設定（例如 log_lock_waits = on）有助於快速發現死鎖事件。

若要保持高效能，請保持交易短暫，避免在交易內進行外部 HTTP 呼叫，並確保相關欄位（order_id、status、version）已建立索引。如果許多行需要進行相同的變更，請在單一 UPDATE 陳述式中對其進行批次處理，而不是為每一行衍生出一個單獨的工作流。使用有限的背景工作者集區和 SKIP LOCKED 可以減少鎖定競爭，並防止背景工作者在等待鎖定時處於閒置狀態。

當競爭罕見且你可以容許重試時，使用樂觀鎖定；當你必須保證單一執行緒存取或涉及多行商務規則時，切換到悲觀鎖定。對於佇列型處理，FOR UPDATE SKIP LOCKED 結合簡短的重試/退避迴圈是 n8n 中最常見的生產模式。遵循這些準則可以產生資料一致、高輸送量的工作流，而不會犧牲效能。

5

非常感謝 @Niffzy @Anshul_Namdev @kjooleng 詳細的解說

原子性 UPDATE … RETURNING 方法對於簡單的狀態轉換很有意義，而當多個相關變更需要一起進行時，交易和鎖定模式變得很重要。這澄清了何時在 n8n 生產工作流程中使用每種方法。感謝你們的見解