承接前一天的本機部署，今天先把 Queue Mode 的設計與運作講清楚；明天直接用 Docker Compose 測試部署（含 Redis Cluster）。

為什麼 n8n 要設計 Queue Mode？

• 解耦觸發與執行：Main 負責 UI、Webhook/Triggers；Worker 專心跑工作，互不阻塞。
• 容易橫向擴展：Worker 可水平擴充（--scale），高併發時只加算力、不中斷 Main。
• 彈性與韌性：工作入列（Redis → Bull/BullMQ），Worker 宕機時任務仍在隊列，回來就能續跑。
• 更適合長任務/高 CPU I/O：避免把長時間工作卡在 Main 的事件循環。

n8n 各種角色與 workflow 的流程

• Main：接收觸發（Webhook、Schedule、App 事件），把 Execution 丟到 Redis。
• Redis：作為隊列（Bull/BullMQ）保存 wait/active/completed/failed/delayed 等狀態。
• Worker：從 Redis 取任務、執行、回報結果到 DB（建議 Postgres）。
• 常見誤解：DB 中 execution_entity.mode 出現的 manual/trigger/webhook 是「來源」，不是 Queue/Regular 的判斷欄位。Queue 與否看環境變數與實際行為（任務入列、Worker 抓取）。

設計注意

• Idempotent：節點/外部 API 最好具備「可重試不重做」能力。
• Stateless Worker：不要把狀態放本機；憑證/設定放 DB 或外部 Secret。
• 正確的外部 URL：Webhook 必須設定 WEBHOOK_URL（協定/網域/子路徑一致）。
• 資料庫：正式環境請用 Postgres（SQLite 只適合單人測試）。