[[384587]]

本文主要講解 MQ 的通用知識，讓大家先弄明白：如果讓你來設計一個 MQ，該如何下手?需要考慮哪些問題?又有哪些技術挑戰?

有了這個基礎后，我相信后面幾篇文章再講 Kafka 和 RocketMQ 這兩種具體的消息中間件時，大家能很快地抓住主脈絡，同時分辨出它們各自的特點。

對于 MQ 來說，不管是 RocketMQ、Kafka 還是其他消息隊列，它們的本質都是：一發一存一消費。下面我們以這個本質作為根，一起由淺入深地聊聊 MQ。

01 從 MQ 的本質說起

將 MQ 掰開了揉碎了來看，都是「一發一存一消費」，再直白點就是一個「轉發器」。

生產者先將消息投遞一個叫做「隊列」的容器中，然后再從這個容器中取出消息，最后再轉發給消費者，僅此而已。

上面這個圖便是消息隊列最原始的模型，它包含了兩個關鍵詞：消息和隊列。

1、消息：就是要傳輸的數據，可以是最簡單的文本字符串，也可以是自定義的復雜格式(只要能按預定格式解析出來即可)。

2、隊列：大家應該再熟悉不過了，是一種先進先出數據結構。它是存放消息的容器，消息從隊尾入隊，從隊頭出隊，入隊即發消息的過程，出隊即收消息的過程。

02 原始模型的進化

再看今天我們最常用的消息隊列產品(RocketMQ、Kafka 等等)，你會發現：它們都在最原始的消息模型上做了擴展，同時提出了一些新名詞，比如：主題(topic)、分區(partition)、隊列(queue)等等。

要徹底理解這些五花八門的新概念，我們化繁為簡，先從消息模型的演進說起(道理好比：架構從來不是設計出來的，而是演進而來的)

2.1 隊列模型

最初的消息隊列就是上一節講的原始模型，它是一個嚴格意義上的隊列(Queue)。消息按照什么順序寫進去，就按照什么順序讀出來。不過，隊列沒有 “讀” 這個操作，讀就是出隊，從隊頭中 “刪除” 這個消息。

這便是隊列模型：它允許多個生產者往同一個隊列發送消息。但是，如果有多個消費者，實際上是競爭的關系，也就是一條消息只能被其中一個消費者接收到，讀完即被刪除。

2.2 發布-訂閱模型

如果需要將一份消息數據分發給多個消費者，并且每個消費者都要求收到全量的消息。很顯然，隊列模型無法滿足這個需求。

一個可行的方案是：為每個消費者創建一個單獨的隊列，讓生產者發送多份。這種做法比較笨，而且同一份數據會被復制多份，也很浪費空間。

為了解決這個問題，就演化出了另外一種消息模型：發布-訂閱模型。

在發布-訂閱模型中，存放消息的容器變成了 “主題”，訂閱者在接收消息之前需要先 “訂閱主題”。最終，每個訂閱者都可以收到同一個主題的全量消息。

仔細對比下它和 “隊列模式” 的異同：生產者就是發布者，隊列就是主題，消費者就是訂閱者，無本質區別。唯一的不同點在于：一份消息數據是否可以被多次消費。

2.3 小結

最后做個小結，上面兩種模型說白了就是：單播和廣播的區別。而且，當發布-訂閱模型中只有 1 個訂閱者時，它和隊列模型就一樣了，因此在功能上是完全兼容隊列模型的。

這也解釋了為什么現代主流的 RocketMQ、Kafka 都是直接基于發布-訂閱模型實現的?此外，RabbitMQ 中之所以有一個 Exchange 模塊?其實也是為了解決消息的投遞問題，可以變相實現發布-訂閱模型。

包括大家接觸到的 “消費組”、“集群消費”、“廣播消費” 這些概念，都和上面這兩種模型相關，以及在應用層面大家最常見的情形：組間廣播、組內單播，也屬于此范疇。

所以，先掌握一些共性的理論，對于大家再去學習各個消息中間件的具體實現原理時，其實能更好地抓住本質，分清概念。

03 透過模型看 MQ 的應用場景

目前，MQ 的應用場景非常多，大家能倒背如流的是：系統解耦、異步通信和流量削峰。除此之外，還有延遲通知、最終一致性保證、順序消息、流式處理等等。

那到底是先有消息模型，還是先有應用場景呢?答案肯定是：先有應用場景(也就是先有問題)，再有消息模型，因為消息模型只是解決方案的抽象而已。

MQ 經過 30 多年的發展，能從最原始的隊列模型發展到今天百花齊放的各種消息中間件(平臺級的解決方案)，我覺得萬變不離其宗，還是得益于：消息模型的適配性很廣。

我們試著重新理解下消息隊列的模型。它其實解決的是：生產者和消費者的通信問題。那它對比 RPC 有什么聯系和區別呢?

通過對比，能很明顯地看出兩點差異：

1、引入 MQ 后，由之前的一次 RPC 變成了現在的兩次 RPC，而且生產者只跟隊列耦合，它根本無需知道消費者的存在。

2、多了一個中間節點「隊列」進行消息轉儲，相當于將同步變成了異步。

再返過來思考 MQ 的所有應用場景，就不難理解 MQ 為什么適用了?因為這些應用場景無外乎都利用了上面兩個特性。

舉一個實際例子，比如說電商業務中最常見的「訂單支付」場景：在訂單支付成功后，需要更新訂單狀態、更新用戶積分、通知商家有新訂單、更新推薦系統中的用戶畫像等等。

引入 MQ 后，訂單支付現在只需要關注它最重要的流程：更新訂單狀態即可。其他不重要的事情全部交給 MQ 來通知。這便是 MQ 解決的最核心的問題：系統解耦。

改造前訂單系統依賴 3 個外部系統，改造后僅僅依賴 MQ，而且后續業務再擴展(比如：營銷系統打算針對支付用戶獎勵優惠券)，也不涉及訂單系統的修改，從而保證了核心流程的穩定性，降低了維護成本。

這個改造還帶來了另外一個好處：因為 MQ 的引入，更新用戶積分、通知商家、更新用戶畫像這些步驟全部變成了異步執行，能減少訂單支付的整體耗時，提升訂單系統的吞吐量。這便是 MQ 的另一個典型應用場景：異步通信。

除此以外，由于隊列能轉儲消息，對于超出系統承載能力的場景，可以用 MQ 作為 “漏斗” 進行限流保護，即所謂的流量削峰。

我們還可以利用隊列本身的順序性，來滿足消息必須按順序投遞的場景;利用隊列 + 定時任務來實現消息的延時消費 ……

MQ 其他的應用場景基本類似，都能回歸到消息模型的特性上，找到它適用的原因，這里就不一一分析了。

總之，就是建議大家多從復雜多變的實踐場景再回歸到理論層面進行思考和抽象，這樣能吃得更透。

04 如何設計一個 MQ?

了解了上面這些理論知識以及應用場景后，下面我們再一起看下：到底如何設計一個 MQ?

4.1 MQ 的雛形

我們還是先從簡單版的 MQ 入手，如果只是實現一個很粗糙的 MQ，完全不考慮生產環境的要求，該如何設計呢?

文章開頭說過，任何 MQ 無外乎：一發一存一消費，這是 MQ 最核心的功能需求。另外，從技術維度來看 MQ 的通信模型，可以理解成：兩次 RPC + 消息轉儲。

有了這些理解，我相信只要有一定的編程基礎，不用 1 個小時就能寫出一個 MQ 雛形：

1、直接利用成熟的 RPC 框架(Dubbo 或者 Thrift)，實現兩個接口：發消息和讀消息。

2、消息放在本地內存中即可，數據結構可以用 JDK 自帶的 ArrayBlockingQueue 。

4.2 寫一個適用于生產環境的 MQ

當然，我們的目標絕不止于一個 MQ 雛形，而是希望實現一個可用于生產環境的消息中間件，那難度肯定就不是一個量級了，具體我們該如何下手呢?

1、先把握這個問題的關鍵點

假如我們還是只考慮最基礎的功能：發消息、存消息、消費消息(支持發布-訂閱模式)。

那在生產環境中，這些基礎功能將面臨哪些挑戰呢?我們能很快想到下面這些：

1、高并發場景下，如何保證收發消息的性能?

2、如何保證消息服務的高可用和高可靠?

3、如何保證服務是可以水平任意擴展的?

4、如何保證消息存儲也是水平可擴展的?

5、各種元數據(比如集群中的各個節點、主題、消費關系等)如何管理，需不需要考慮數據的一致性?

可見，高并發場景下的三高問題在你設計一個 MQ 時都會遇到，「如何滿足高性能、高可靠等非功能性需求」才是這個問題的關鍵所在。

2、整體設計思路

先來看下整體架構，會涉及三類角色：

另外，將「一發一存一消費」這個核心流程進一步細化后，比較完整的數據流如下：

基于上面兩個圖，我們可以很快明確出 3 類角色的作用，分別如下：

1、Broker(服務端)：MQ 中最核心的部分，是 MQ 的服務端，核心邏輯幾乎全在這里，它為生產者和消費者提供 RPC 接口，負責消息的存儲、備份和刪除，以及消費關系的維護等。

2、Producer(生產者)：MQ 的客戶端之一，調用 Broker 提供的 RPC 接口發送消息。

3、Consumer(消費者)：MQ 的另外一個客戶端，調用 Broker 提供的 RPC 接口接收消息，同時完成消費確認。

3、詳細設計

下面，再展開討論下一些具體的技術難點和可行的解決方案。

難點1：RPC 通信

解決的是 Broker 與 Producer 以及 Consumer 之間的通信問題。如果不重復造輪子，直接利用成熟的 RPC 框架 Dubbo 或者 Thrift 實現即可，這樣不需要考慮服務注冊與發現、負載均衡、通信協議、序列化方式等一系列問題了。

當然，你也可以基于 Netty 來做底層通信，用 Zookeeper、Euraka 等來做注冊中心，然后自定義一套新的通信協議(類似 Kafka)，也可以基于 AMQP 這種標準化的 MQ 協議來做實現(類似 RabbitMQ)。對比直接用 RPC 框架，這種方案的定制化能力和優化空間更大。

難點2：高可用設計

高可用主要涉及兩方面：Broker 服務的高可用、存儲方案的高可用。可以拆開討論。

Broker 服務的高可用，只需要保證 Broker 可水平擴展進行集群部署即可，進一步通過服務自動注冊與發現、負載均衡、超時重試機制、發送和消費消息時的 ack 機制來保證。

存儲方案的高可用有兩個思路：1)參考 Kafka 的分區 + 多副本模式，但是需要考慮分布式場景下數據復制和一致性方案(類似 Zab、Raft等協議)，并實現自動故障轉移;2)還可以用主流的 DB、分布式文件系統、帶持久化能力的 KV 系統，它們都有自己的高可用方案。

難點3：存儲設計

消息的存儲方案是 MQ 的核心部分，可靠性保證已經在高可用設計中談過了，可靠性要求不高的話直接用內存或者分布式緩存也可以。這里重點說一下存儲的高性能如何保證?這個問題的決定因素在于存儲結構的設計。

目前主流的方案是：追加寫日志文件(數據部分) + 索引文件的方式(很多主流的開源 MQ 都是這種方式)，索引設計上可以考慮稠密索引或者稀疏索引，查找消息可以利用跳轉表、二份查找等，還可以通過操作系統的頁緩存、零拷貝等技術來提升磁盤文件的讀寫性能。

如果不追求很高的性能，也可以考慮現成的分布式文件系統、KV 存儲或者數據庫方案。

難點4：消費關系管理

為了支持發布-訂閱的廣播模式，Broker 需要知道每個主題都有哪些 Consumer 訂閱了，基于這個關系進行消息投遞。

由于 Broker 是集群部署的，所以消費關系通常維護在公共存儲上，可以基于 Zookeeper、Apollo 等配置中心來管理以及進行變更通知。

難點5：高性能設計

存儲的高性能前面已經談過了，當然還可以從其他方面進一步優化性能。

比如 Reactor 網絡 IO 模型、業務線程池的設計、生產端的批量發送、Broker 端的異步刷盤、消費端的批量拉取等等。

4.3 小結

再總結下，要回答好：如何設計一個 MQ?

1、需要從功能性需求(收發消息)和非功能性需求(高性能、高可用、高擴展等)兩方面入手。

2、功能性需求不是重點，能覆蓋 MQ 最基礎的功能即可，至于延時消息、事務消息、重試隊列等高級特性只是錦上添花的東西。

3、最核心的是：能結合功能性需求，理清楚整體的數據流，然后順著這個思路去考慮非功能性的訴求如何滿足，這才是技術難點所在。

05 寫在最后

這篇文章從 MQ 一發一存一消費這個本質出發，講解了消息模型的演進過程，這是 MQ 最核心的理論基礎。基于此，大家也能更容易理解 MQ 的各種新名詞以及應用場景。

最后通過回答：如何設計一個 MQ?目的是讓大家對 MQ 的核心組件和技術難點有一個清晰的認識。另外，帶著這個問題的答案再去學習 Kafka、RocketMQ 等具體的消息中間件時，也會更有側重點。

本文轉載自微信公眾號「武哥漫談IT」，可以通過以下二維碼關注。轉載本文請聯系武哥漫談IT公眾號。