談談消息隊列的流派

關於 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，能夠完成發送和讀取數據。

• 文章做者：彭超

• 本文首發於我的博客：https://antoniopeng.com/2020/06/15/mq/%E8%B0%88%E8%B0%88%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97%E7%9A%84%E6%B5%81%E6%B4%BE/

• 版權聲明：本博客全部文章除特別聲明外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明來自 彭超 | Blog！