消息代理選型與 n8n 串接指南（RabbitMQ vs Kafka）

消息代理選型與 n8n 串接指南：RabbitMQ vs Kafka 完整比較

在臺灣技術社群，「消息代理」通常稱為「訊息代理」或「訊息佇列」，本文以「訊息代理」行文，H1 保留「消息代理」對應搜尋。

當你的自動化流程需要訊息代理──3 個判準

什麼時候不需要？先確認你的 n8n workflow 規模

如果你的 n8n 環境只有單一 workflow、沒有並行需求、偶爾執行失敗也可以接受，n8n 內建的重試機制已經足夠。快速自檢：保證不丟單、應付瞬間流量尖峰、讓多個服務獨立收發事件並彼此解耦──三項需求都沒有，現在還不需要導入訊息代理。

什麼時候該導入？三個明確訊號

削峰：瞬間大量 webhook 觸發（例如行銷活動同時數千人提交表單），n8n 單機消化不及，前端 broker 先接再慢慢派發。
保證傳遞：訂單、金流事件不能掉，需要 broker 的 persistent message 與 ack 機制。
多服務解耦：一個事件要同時觸發多條 workflow，producer 不需知道 consumer 是誰。

RabbitMQ vs Kafka 怎麼選？一張表做決定

維度	RabbitMQ	Kafka
架構類型	以訊息為單位（memory-based）	以串流為單位（log-based）
吞吐量	中（萬級 msg/s）	高（百萬級 msg/s）
消費模型	競爭消費（多 consumer 搶同一 queue）	Consumer Group（每組可獨立重複消費）
協定	AMQP 0-9-1	自有協定
典型場景	非同步任務（寄信、轉檔、簡訊）、微服務解耦	即時日誌採集、事件溯源、大數據 pipeline

選型一句話

中小團隊、非同步任務、需交易保證 → RabbitMQ。
大數據即時計算、日誌／事件串流 → Kafka 是業界標準。
兩者都要？可以，但先確認團隊維運能量；n8n 兩者都有原生節點可串。

n8n 怎麼串訊息代理？三個實戰場景

場景一：用 RabbitMQ 節點做非同步任務派發

n8n 原生 RabbitMQ node（producer）發訊息到 queue，RabbitMQ Trigger（consumer）在訊息抵達時自動觸發 workflow。實例：表單提交 → n8n 發到 queue → 另一條 workflow 消費後寄信 + 寫 CRM。n8n 另有 AMQP Sender／AMQP Trigger 節點，可接任何 AMQP 1.0 broker。

場景二：n8n queue mode──n8n 自己就是 broker 的消費者

n8n queue mode 用 Redis（內部走 Bull 佇列庫） 當 broker：main process 只推 job，worker 從 Redis 取工作執行。必要設定：EXECUTIONS_MODE=queue、QUEUE_BULL_REDIS_HOST、QUEUE_BULL_REDIS_PORT（預設 6379）。限制提醒：必須 PostgreSQL + Redis，SQLite 不支援。這不是「取代」RabbitMQ/Kafka，而是 n8n 內部的任務調度機制；兩者可並存。

場景三：RabbitMQ 連線斷線排查──已知坑與解法

社群曾回報 RabbitMQ 連線問題導致 n8n workflow 被自動停用（GitHub issue #9499）。排查步驟：檢查 n8n 日誌中的連線錯誤 → 確認 broker 端是否重啟或防火牆變更 → 重啟 workflow 並監控 heartbeat。

訊息代理的費用參考（2025–2026）

自架方案（開源免費）

RabbitMQ（開源，Docker 一鍵部署）：僅伺服器成本。以 GCP e2-micro 或 AWS t4g.micro 最低規格 VM 估算，月費約 NT$350–700。
Kafka（開源）：需自行維運 ZooKeeper／KRaft 叢集，建議至少 3 節點，月費約 NT$2,000–4,500。
Redis + Bull（隨 n8n queue mode 使用）：Redis 開源免費，雲端最低規格約 NT$200–450／月。

雲端托管方案（依用量計費）

Amazon MQ：按月平均儲存 GB 計費，支援 RabbitMQ 與 ActiveMQ。2025-07-15 起新 AWS 帳號 6 個月內有最高 $200 Free Tier credits（約 NT$6,400）。
CloudAMQP：⚠️ 未取得 2026 公開價目，請查官方價格頁。
Confluent Cloud：⚠️ 未取得 2026 公開價目，引用數字前須另行查實。

FAQ

Q1: 消息代理和訊息佇列（message queue）差在哪？

訊息佇列是訊息代理的核心元件之一；訊息代理除了 queue，通常還包含 exchange、routing、protocol translation 等能力。實務上兩詞常混用，但選型時要注意：你需要的只是 queue，還是完整的 broker（含 routing、topic exchange）？

Q2: 我的自動化流程什麼時候才真的需要 broker？

三個判準見上文。若只需「失敗重試」，n8n 內建 retry 就夠；若需削峰、保證不丟單、多服務解耦，才值得導入 broker。

Q3: RabbitMQ 和 Kafka 該選哪個？

一張表見上文。一句話：非同步任務 → RabbitMQ；即時串流／大數據 → Kafka。

Q4: n8n 要怎麼接 RabbitMQ／Kafka？需要自架嗎？

n8n 有原生 RabbitMQ node + RabbitMQ Trigger 以及 Kafka node。Broker 可自架（Docker 一鍵部署），也可用雲端托管（Amazon MQ、CloudAMQP、Confluent Cloud），看團隊維運偏好。

Q5: n8n queue mode 是不是就等於用了訊息代理？

是，n8n queue mode 就是 Redis（Bull）充當內部訊息代理，協調 main process 與多 worker 之間的任務派發。但它只處理 n8n 內部的 execution job，不負責外部服務間的通訊──外部服務仍需 RabbitMQ 或 Kafka。