Message Queue 是什麼？老闆與 PM 必懂的非同步系統設計入門：RabbitMQ、Kafka、SQS 何時該用

晚上十一點五十九分，雙 11 的計時器倒數到零。前台流量瞬間翻 30 倍，下單按鈕被連點，伺服器 CPU 衝到 98%，資料庫連線池滿了，會員系統開始回 500，客服群組炸出滿屏訊息。

第二天的事後檢討會議上，工程主管攤手說「我們需要一個 Message Queue。」老闆愣了一下：「那是什麼？要花多少？要做多久？」

這個場景每年雙 11、母親節檔期、政府疫苗預約、演唱會搶票都會重演一次。Message Queue（訊息佇列）是現代軟體系統裡解決「流量爆量、處理變慢、模組互卡」最常用的一個基礎元件，但很多老闆與 PM 只在工程師求救時聽過名字，不知道它解什麼問題、值不值得投資、什麼時候該推外包導入。

這篇用「老闆視角 + PM 落地視角」拆給你：Message Queue 在哪些情境真的能救命、哪些情境是工程師過度設計、外包報價怎麼看、選 RabbitMQ 或 Kafka 該怎麼判斷。文章最後給你一張「6 題自我檢測」，回會議馬上能用。

Message Queue 到底是什麼？用便當店比喻一次說清楚

Message Queue 中文叫「訊息佇列」，本質是一個「中間人」。它把「請求方」與「處理方」拆開——請求方只負責「把訂單丟進排隊機」，處理方在後面慢慢拿、慢慢做。

換成便當店比喻會更直觀。傳統做法是「客人點餐 → 老闆當場煮 → 客人在櫃台站著等」，這就是同步處理。Message Queue 的做法是「客人點餐 → 拿號碼牌 → 走開做其他事 → 號碼響了再回來取」。中間那台叫號機，就是 Message Queue。

這個比喻可以幫你回答 90% 的「Message Queue 解什麼問題」。當你的系統碰到流量尖峰，沒有 Queue 的版本是「客人擠死櫃台、廚房卻一份份做不完、客人罵爆」；有 Queue 的版本是「客人快速拿號碼、走開逛街、廚房按節奏出餐」。前者體驗崩潰，後者體驗順暢，廚房負擔還沒變大。

AWS 對 Message Queue 的官方說明把這件事概括成三個價值：解耦（Decoupling）、削峰填谷（Buffering）、可重試（Retryability）。三個詞背後對應的是三類老闆會痛的問題——下面我們各拆一段。

沒有 Message Queue 會發生什麼？三個真實場景

場景一：電商雙 11，前台一卡、後台寄信全炸

沒有 Queue 的做法是「客人下單 → 同時寫資料庫、同時呼叫物流 API、同時寄信、同時通知會員系統」。任一環卡 0.5 秒，前台就多 0.5 秒。雙 11 流量一來，下單頁直接慢到 30 秒，客人手指滑掉就跑了。

加 Queue 之後，前台只負責「寫訂單 + 丟一則訊息進 Queue」，剩下的物流、寄信、通知由背景 worker 慢慢吃。前台從 30 秒回到 800ms，客人不會跑。

場景二：預約系統，第三方 API 掛掉，整個流程跟著爆

醫療診所或補習班的預約系統，常常要打第三方簡訊 API、Google Calendar、LINE 通知。第三方任何一個掛了 5 分鐘，沒有 Queue 的版本會把所有預約請求一起拖死，連能正常預約的客人都進不來。

有 Queue 的版本則是「預約寫進 DB、訊息丟 Queue」，第三方 API 掛了就讓 Queue 累積、worker 慢慢重試。客人面對的還是「預約已成功」。

場景三：政府／演唱會搶票，瞬間 10 萬人壓爆資料庫

沒有 Queue 的搶票系統，所有人同時打資料庫，連線數爆掉、整個系統不能用。Cloudflare 對 queue 與 backpressure 的解釋提到 queue 在這種場景的價值，就是把「瞬間 10 萬請求」變成「Queue 裡有 10 萬筆訊息、後端按處理能力消化」——資料庫永遠都不會超過自己處理得來的並發。

這三個場景之外，還有訂單對帳、推播、影音轉檔、報表批次、AI 跑 inference task 等。只要「不是當下要回給使用者」的工作，幾乎都可以丟 Queue。

RabbitMQ、Kafka、SQS、Redis Streams 怎麼選？

這是中小企業老闆最常問的問題，下面這張表照「業務場景」分，不照「技術名詞」分，比較好理解：

90% 的中小企業電商、預約、報名系統用 RabbitMQ 或 SQS 就夠了。Kafka 是設計給「每秒 100 萬訊息以上、需要保留歷史日誌做即時分析」的場景，新創或一般公司硬上 Kafka，通常運維成本會比業務收益還大。

如果你的系統已經跑在 AWS 上、流量也不大，SQS 是門檻最低的選擇。零運維、按用量計費、跟 Lambda 一接就能跑。我們在 PaaS 五大平台比較裡也提過 Zeabur 上一鍵起 RabbitMQ 是中小團隊很常見的路徑。

Confluent 的 Kafka 與 RabbitMQ 差異對照做了滿仔細的對照表，工程主管可以拿來跟外包討論需求。重點記一句話就好：Kafka 是「日誌資料庫」、RabbitMQ 是「工作分配器」，兩個用途差很多，不要互相比較。

導入 Message Queue 的真實費用：3 個報價區間拆解

外包報價最常見的踩雷點：許多廠商會把「Queue 建置」報得便宜，但漏了「重試機制、死信佇列、監控告警」這三件事。這三件事如果沒做，Queue 反而會吃掉訊息、讓你以為都送出去了，實際上掉了 5%。事後再補往往要重新走一輪。

我們在生產力管理系統裡的工單分派與通知模組、以及AnyTime 遠距團隊工具的計時推播，都有用到 RabbitMQ 做非同步任務分派。實務經驗是：第一條 queue 上線後，後續每條的增量成本會降到 30–50%，因為基礎建設已經做好。

不該導入 Message Queue 的 4 種情境

不是所有系統都需要 Queue。下面這幾種情境硬上 Queue，會讓系統更難維護：

一個簡單的判斷標準：把這個任務改成「使用者看不到立即結果，5 秒鐘後再通知他」，業務還能接受嗎？接受的話，適合 Queue；不接受，先不要動。

老闆視角：6 題自我檢測，要不要立刻找外包做

不需要工程背景也能跑完：

加總分數對應行動：

常見問題（FAQ）

結論：Queue 是工具，不是信仰

Message Queue 是現代軟體系統很常見的一個元件，但它不是「導入了就會更穩」的萬靈丹。它解的是「同步處理拖死前台」「外部依賴掛掉拖累整個系統」「流量尖峰壓垮資料庫」這三類痛點。沒這些痛點，先別動。

有的話，從一條 queue 開始、用託管服務、把監控與重試做好，三件事做好就能撐住 80% 的中小企業電商與報名系統。

想評估自家系統適不適合導入、要找哪一型的外包，可以從/services/custom-development開始聊，我們會根據你目前的流量、團隊規模、業務階段給出合理的導入路徑與報價。