關於 MQ 的定義

Message Queue（MQ）訊息佇列中介軟體，通常我們在網上看到的對其定義是將訊息的傳送和接受分離來實現應用程式的非同步和解耦，給人的直覺是 MQ 是非同步的，用來解耦的。但這個只是 MQ 的效果，而不是目的。MQ 真正的目的是為了通訊，遮蔽底層複雜的通訊協議，定義了一套應用層上更加簡單的通訊協議。

一套分散式系統中兩個模組之間通訊要麼是 HTTP，要麼是 TCP，但這兩種協議其實都是原始的協議。前者實現通訊就必須要做到各客戶端都有 WebServer，而且不支援長連線；後者就更加原始了 — 粘包、心跳、私有的協議。

而 MQ 所要做就是在基於這些現有的協議之上構建一個更簡單的通訊（生產者/消費者）模型。它定義了兩個物件 —傳送資料的叫生產者，接受資料的叫消費者，提供一個 SDK 給我們自己定義生產者和消費者實現訊息通訊，且無視底層通訊協議。

帶 Broker 的流派

這個流派通常有一臺伺服器作為 Broker，所有的訊息都透過它進行中轉。生產者把訊息傳送給它就結束自己的任務了，最後 Broker 則把訊息主動推送給消費者（或者消費者主動輪詢）。

重 Topic 的 MQ

Kafka、Active MQ 就屬於這個流派：生產者傳送 key 和資料到 Broker，由 Broker 比較 key 之後決定給哪個消費者。

在這種模式下，Topic（主題訊息） 往往是一個比較大的概念，甚至一個系統中就可能只有一個 Topic。

雖然這兩種訊息佇列的架構一樣，但是 Kafka 的效能要比 Active MQ 的效能不知道高到多少倍，所以基本這種型別的 MQ 只有 Kafka一種備選方案。

輕 Topic 的 MQ

這種的代表是 RabbitMQ（AMQP）。生產者傳送 key 和資料，Borker 收到資料之後會根據 key 透過一定的邏輯計算出相應的佇列，最後消費者訂閱佇列。

在這種架構中 Queue 是非常輕量級的（在 RabbitMQ 中它的上限取決於你的記憶體），消費者關心的只是自己的 Queue；生產者不必關心資料最終給誰，只要指定 key 就行了。中間的那層對映在 AMQP 中叫 exchange（交換機）。

AMQP 中有四種 exchange：

Direct exchange：key 等於 queue。
Fanout exchange：無視 key，給所有的 queue 都來一份。
Topic exchange：key 可以用 “寬字元” 模糊匹配 queue。
Headers exchange：無視 key，透過檢視訊息的頭部後設資料來決定發給哪個 queue。

這種架構給通訊帶來了極大的靈活性，我們能想到的通訊方式都可以用這四種 exchange 表達出來。

不帶 Broker 的流派

ZeroMQ

不帶 Broker 的 MQ 代表就是 ZeroMQ。可以說是解決通訊問題的更高階 Socket，它被設計成了一個 “庫” 而不是一箇中介軟體，這種實現也可以達到沒有 Broker 的目的。

各節點之間的通訊都是傳送到彼此的佇列中，每個節點即是生產者也是消費者。類似於一套 Socket 的 API，可以完成傳送和讀取資料。

文章作者：彭超

本文首發於個人部落格：

版權宣告：本部落格所有文章除特別宣告外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明來自！

談談訊息佇列的流派