解析 Message Queues 與 Pub/Sub 的差別

發表於 更新於 分類於

在現代分散式系統架構中，非同步訊息傳遞是實現服務解耦、提升系統擴展性與可靠性的關鍵。而在眾多訊息傳遞模式中，Message Queues (消息隊列) 與 Publish-Subscribe (發布/訂閱，簡稱 Pub/Sub) 是最常被討論也最容易被混淆的兩種。本文將深入探討這兩種模式的核心差異、應用場景及各自的優缺點，幫助在系統設計時做出更明智的選擇。

關於術語的重要說明

在深入探討之前，必須澄清一個常見的混淆點。術語「Message Queue」常被用於兩種不同的語境：

  1. 作為一種設計模式 (Pattern)：特指本文將要介紹的「點對點」一對一訊息傳遞模型。
  2. 作為一類技術產品 (Technology)：泛指像 RabbitMQ、Apache Kafka、AWS SQS 等訊息中介軟體 (Message-Oriented Middleware)。

值得注意的是，大多數我們稱為「Message Queue」的技術產品，其功能非常強大，通常同時支援「點對點的佇列模式」和「一對多的發布/訂閱模式」。本文為了清晰地比較這兩種核心設計理念，將嚴格按照設計模式進行劃分，分別探討「Message Queue (點對點模式)」與「Pub/Sub (發布/訂閱模式)」的差異。

什麼是 Message Queue？

Message Queue (MQ) 遵循的是「點對點」(point-to-point) 的通訊模型、消費者競爭 (Competing Consumers) 模式。在這個模型中，訊息的生產者 (Producer) 將訊息發送到一個佇列 (Queue)，而消費者 (Consumer) 則從這個佇列中取出並處理訊息。

核心特性：

  • 一對一消費與負載平衡：一則訊息只會被一個消費者成功處理，這是此模式的黃金法則。即使有多個消費者（通常是同一個服務的多個實例）同時監聽同一個佇列，佇列中的一則訊息也只會被其中一個消費者取出處理。這種機制被稱為「競爭消費者」(Competing Consumers)，是實現任務分發與負載平衡的關鍵。
  • 訊息保留與確認：訊息在被消費者成功處理並發出確認 (Acknowledgement) 之前，會一直保留在佇列中，確保訊息不會遺失。如果消費者處理失敗，訊息可以被放回佇列由其他消費者處理。
  • 任務導向：此模式的意圖是委派一個任務。生產者不關心是哪個消費者執行，只關心這個任務最終會被完成。
  • 順序性：在許多使用案例中，Message Queue 能確保訊息的先進先出 (FIFO)，不過實際的傳遞順序有時會依據實作與設定而異。

理想應用場景：

  • 任務分發與負載平衡：當需要將耗時的任務分配給多個背景工作者 (Worker) 處理時，Message Queue 是絕佳選擇。
  • 非同步處理：將非必要的任務（如寄送電子郵件、產生報表）丟入佇列，讓主要應用程式能立即回應使用者請求，提升反應速度。
  • 流量削峰：在高併發場景下，利用佇列作為緩衝區，可以避免瞬間流量衝垮後端服務。

流程圖：競爭消費者模型

這個流程圖展示了典型的「競爭消費者」場景。多個背景工作者實例監聽同一個任務佇列，並從中競爭任務來執行，實現了工作負載的均衡。

sequenceDiagram
    participant Producer as 生產者 (Producer)
    participant Queue as 訊息佇列 (Queue)
    participant ConsumerA as 消費者 A (Consumer A)
    participant ConsumerB as 消費者 B (Consumer B)

    autonumber

    Producer->>+Queue: 發送訊息 M1
    note right of Producer: 訊息 M1 進入佇列等待處理
    Producer->>+Queue: 發送訊息 M2
    note right of Producer: 訊息 M2 進入佇列等待處理

    alt 訊息處理
        Queue-->>-ConsumerA: 分派訊息 M1
        note left of ConsumerA: 消費者 A 取得 M1 並開始處理

        Queue-->>-ConsumerB: 分派訊息 M2
        note right of ConsumerB: 消費者 B 取得 M2 並開始處理
    end

    ConsumerA->>Queue: 確認 (Ack) M1 處理完畢
    ConsumerB->>Queue: 確認 (Ack) M2 處理完畢

這個模式的核心是 工作分發 和 負載均衡。

  1. 發送訊息：生產者產生了兩則訊息 (M1, M2) 並把它們發送到同一個訊息佇列中。
  2. 訊息分派：佇列將訊息 M1 分派給了消費者 A，同時將訊息 M2 分派給了消費者 B。關鍵點在於，M1 不會再被 B 處理，M2 也不會再被 A 處理。
  3. 處理與確認：消費者各自處理完訊息後，會向佇列發送一個「確認 (Acknowledgement)」，通知佇列該訊息已被成功處理，可以從佇列中永久移除了。

什麼是 Publish-Subscribe (Pub/Sub)？

當需求從「把工作分給下一個有空的人」變成「把消息告訴所有關心這件事的人」時，就跨入了 Pub/Sub 的領域。

Publish-Subscribe (Pub/Sub) 是一種「一對多」的廣播模型。在此模型中，發布者 (Publisher) 將訊息（或事件）發布到一個特定的「主題」(Topic)，所有訂閱了該主題的訂閱者 (Subscriber) 都會收到這則訊息的副本並各自處理。

核心特性：

  • 一對多通訊：一則訊息可以被多個訂閱者接收並各自處理。 發布者與訂閱者之間是解耦的，發布者不需要知道有誰訂閱了訊息，甚至不知道是否有任何訂閱者存在。
  • 事件導向：此模式的意圖是廣播一個事件。發布者只是在宣告「某件事發生了」（例如：使用者下單了），而不關心後續誰會對這個事件做出反應，也不關心反應是什麼。
  • 主題式分類：訊息是依據「主題」進行分類的，訂閱者可以選擇性地訂閱感興趣的主題。
  • 即時性：Pub/Sub 通常被用於即時事件的通知與傳播，採取的是「即發即忘」(fire-and-forget) 的模式，可靠性保障通常較 Message Queue 低。

理想應用場景：

  • 事件驅動架構 (Event-Driven Architecture)：當系統中某個狀態發生改變時（例如：使用者下單），透過 Pub/Sub 將此「事件」通知給所有相關的不同微服務（如庫存服務、通知服務、數據分析服務）。
  • 即時通知：應用於推播通知、即時聊天、股價更新等需要將單一事件廣播給大量使用者的場景。
  • 數據扇出 (Data Fan-out)：將一份數據（如 IoT 感測器數據）同時發送給多個後端系統進行儲存、分析和監控。

流程圖

這個流程圖展示了「一對多」的廣播模式。不同的服務訂閱同一個主題，當事件發生時，它們都會收到通知並執行各自的業務邏輯。

sequenceDiagram
    participant Publisher as 發布者
    participant Topic as 主題 (Topic/Exchange)
    participant QueueA as 佇列 A (給庫存服務)
    participant QueueB as 佇列 B (給通知服務)
    participant StockService as 庫存服務
    participant NotificationService as 通知服務

    autonumber

    Publisher->>Topic: 發布「使用者下單」事件
    note over Topic, QueueB: Topic 將事件扇出 (Fan-out) 給所有訂閱者

    par
        Topic-->>QueueA: 複製事件到佇列 A
    and
        Topic-->>QueueB: 複製事件到佇列 B
    end

    QueueA-->>StockService: 傳遞事件
    StockService->>StockService: 處理：扣減庫存

    QueueB-->>NotificationService: 傳遞事件
    NotificationService->>NotificationService: 處理：寄送 E-mail
  1. 發布事件：發布者向主題發布一個 E1 事件。
  2. 並行廣播 (par…end)：par 區塊表示動作是同時發生的。主題將事件並行地廣播給所有訂閱者。
  3. 獨立處理：每個訂閱者在收到事件後，開始執行各自的內部邏輯，彼此之間互不干擾。

核心差異總結

特性 Message Queue Publish-Subscribe (Pub/Sub)
核心意圖 任務導向 (Task-Oriented) 事件導向 (Event-Oriented)
通訊模型 點對點 (一對一) 發布/訂閱 (一對多)
訊息消耗 一則訊息只被一個消費者處理。 一則訊息會被所有訂閱者處理。
耦合度 生產者與單一消費者解耦。 發布者與多個訂閱者完全解耦。
可靠性 可靠性高，通常有訊息確認機制。 可靠性相對較低，可能因訂閱者離線而遺失訊息。
主要用途 任務分發、負載平衡、非同步處理。 事件廣播、即時通知、數據串流。

備註: 雖然 Pub/Sub 可以配置為「即發即忘」(fire-and-forget) 模式，但現代主流系統（如 Kafka, RabbitMQ）通常會為訂閱者維護獨立的佇列或日誌偏移量 (offset)，確保即使訂閱者短暫離線，也能在重新上線後接收到錯過的訊息，實現高可靠性。

如何選擇？

選擇 Message Queue 還是 Pub/Sub，完全取決於具體需求：

  • 如果需要確保每一項任務都只被執行一次，並且希望在多個工作者之間分攤處理壓力，那麼 Message Queue 是首選。
  • 如果需要將一個事件通知給多個不同的處理單元，並且強調服務間的完全解耦與即時性，那麼 Pub/Sub 會是更合適的模式。

在某些複雜的系統中，甚至會將兩者結合使用。例如，一個服務透過 Pub/Sub 接收到事件通知後，再將具體的處理任務放入 Message Queue 中，交由後端工作者執行。

結論

Message Queues 和 Pub/Sub 都是構成現代化分散式系統的重要基石。理解它們之間最根本的差異——「一對一」的任務導向與「一對多」的事件廣播——是設計出高效、可擴展且穩健系統的第一步。希望本文釐清了術語上的混淆，並能幫助你在未來的技術選型中，更有信心地從設計意圖出發，做出正確的決策。