關於 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 許可協議。轉載請註明來自 彭超 | Blog！