作者|骨來
本文從異步、解耦、削峰填谷等核心應用場景，以及消息中間件常用協定、推拉模式對比來解答此問題。
什麼是消息中間件
作為一種典型的消息代理元件（Message Broker），是企業級應用系統中常用的消息中間件，主要應用于分布式系統或元件之間的消息通訊，提供具有可靠、異步和事務等特性的消息通信服務。應用消息代理元件可以降低系統間耦合度，提高系統的吞吐量、可擴充性和高可用性。
分布式消息服務主要涉及五個核心角色，消息釋出者（Publisher）、可靠消息元件（MsgBroker）、消息訂閱者（Subscriber）、消息類型（Message Type）和訂閱關系（Binding），具體描述如下：
- 消息釋出者，指發送消息的應用系統，一個應用系統可以發送一種或者多種消息類型，釋出者發送消息到可靠消息元件 (MsgBroker)。
- 可靠消息元件，即 MsgBroker，負責接收釋出者發送的消息，根據消息類型和訂閱關系将消息分發投遞到一個或多個消息訂閱者。整個過程涉及消息類型校驗、消息持久化存儲、訂閱關系比對、消息投遞和消息恢複等核心功能。
- 消息訂閱者，指訂閱消息的應用系統，一個應用系統可以訂閱一種或者多種消息類型，消息訂閱者收到的消息來自可靠消息元件 (MsgBroker)。
- 消息類型：一種消息類型由 TOPIC 和 EVENTCODE 唯一辨別。
- 訂閱關系，用來描述一種消息類型被訂閱者訂閱，訂閱關系也被稱為 Binding。
核心功能特色
可為不同應用系統間提供可靠的消息通信，降低系統間耦合度并提高整體架構的可擴充性和可用性。
可為不同應用系統間提供異步消息通信，提高系統吞吐量和性能。
釋出者系統、消息代理元件以及訂閱者系統均支援叢集水準擴充，可依據業務消息量動态部署計算節點。
支援事務型消息，保證消息與本地資料庫事務的一緻性。
遠端調用RPC和消息MQ差別
談到消息隊列，有必要看下RPC和MQ的本質差別，從兩者的定義和定位來看，RPC（Remote Procedure Call）遠端過程調用，主要解決遠端通信間的問題，不需要了解底層網絡的通信機制；消息隊列（MQ）是一種能實作生産者到消費者單向通信的通信模型。核心差別在于RPC是雙向直接網絡通訊，MQ是單向引入中間載體的網絡通訊。單純去看隊列，隊列是一種特殊的線性表，特殊之處在于它隻允許在表的前端（front）進行删除操作，而在表的後端（rear）進行插入操作，和棧一樣，隊列是一種操作受限制的線性表。進行插入操作的端稱為隊尾，進行删除操作的端稱為隊頭。在隊列前面增加限定詞“消息”，意味着通過消息驅動來進行整體的架構實作。RPC和MQ本質上是網絡通訊的兩種不同的實作機制，RPC同步等待結果對比于MQ在異步、解耦、削峰填谷等上的特征顯著差異主要有以下幾點差異：
- 在架構上，RPC和MQ的差異點是，Message有一個中間結點Message Queue，可以把消息存儲起來。
- 同步調用：對于要立即等待傳回處理結果的場景，RPC是首選。
- MQ的使用，一方面是基于性能的考慮，比如服務端不能快速的響應用戶端（或用戶端也不要求實時響應），需要在隊列裡緩存；另外一方面，它更側重資料的傳輸，是以方式更加多樣化，除了點對點外，還有訂閱釋出等功能。
- 随着業務增長，有的處理端調用下遊服務太多或者處理量會成為瓶頸，會進行同步調用改造為異步調用，這個時候可以考慮使用MQ。
核心應用場景
針對MQ的核心場景，我們從異步、解耦、削峰填谷等特性進行分析，差別于傳統的RPC調用。尤其在引入中間節點的情況下，通過空間（擁有存儲能力）換時間（RPC同步等待響應）的思想，增加更多的可能性和能力。
▐ 異步通信
針對不需要立即處理消息，尤其那種非常耗時的操作，通過消息隊列提供了異步處理機制，通過額外的消費線程接管這部分進行異步操作處理。
▐ 解耦
在應用和應用之間，提供了異構系統之間的消息通訊的機制，通過消息中間件解決多個系統或異構系統之間除了RPC之外另一種單向通訊的機制。
▐ 擴充性
因為消息隊列解耦了主流程的處理過程，隻要另外增加處理過程即可，不需要改變代碼、不需要調整參數，便于分布式擴容。
▐ 分布式事務一緻性
在2個應用系統之間的資料狀态同步，需要考慮資料狀态的最終一緻性的場景下，利用消息隊列所提供的事務消息來實作系統間的資料狀态一緻性。
▐ 削峰填谷
在通路量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量無法提前預知；如果為了能處理這類瞬間峰值通路提前準備應用資源無疑是比較大的浪費。使用消息隊列在突發事件下的防脈沖能力提供了一種保障，能夠接管前台的大脈沖請求，然後異步慢速消費。
▐ 可恢複性
系統的一部分元件失效時，不會影響到整個系統。消息隊列降低了應用間的耦合度，是以即使一個處理消息的應用挂掉，加入隊列中的消息仍然可以在系統恢複後被處理。
▐ 順序保證
在大多使用場景下，資料處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證資料會按照特定的順序來進行處理。
▐ 大量堆積
通過消息堆積能力處理資料遷移場景，針對舊資料進行全量遷移的同時開啟增量消息堆積，待全量遷移完畢，再開啟增量，保證資料最終一緻性且不丢失。
▐ 資料流處理
分布式系統産生的海量資料流，如：業務日志、監控資料、使用者行為等，針對這些資料流進行實時或批量采集彙總，然後導入到大資料實時計算引擎，通過消息隊列解決異構系統的資料對接能力。
▐ 業界消息中間件對比
詳細的對比可以參考：
https://blog.csdn.net/wangzhipeng47/article/details/107134024消息中間件常用協定
▐ AMQP協定
AMQP即Advanced Message Queuing Protocol,提供統一消息服務的進階消息隊列協定,是應用層協定的一個開放标準,為面向消息的中間件設計。基于此協定的用戶端與消息中間件可傳遞消息，并不受用戶端/中間件不同産品，不同開發語言等條件的限制。
優點：可靠、通用
▐ MQTT協定
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通訊協定，成為物聯網的重要組成部分。該協定支援所有平台，幾乎可以把所有聯網物品和外部連接配接起來，被用來當做傳感器和緻動器（比如通過Twitter讓房屋聯網）的通信協定。
優點：格式簡潔、占用帶寬小、移動端通信、PUSH、嵌入式系統
▐ STOMP協定
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協定，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協定。STOMP提供一個可互操作的連接配接格式，允許用戶端與任意STOMP消息代理（Broker）進行互動。
優點：指令模式（非topic/queue模式）
▐ XMPP協定
XMPP（可擴充消息處理現場協定，Extensible Messaging and Presence Protocol）是基于可擴充标記語言（XML）的協定，多用于即時消息（IM）以及線上現場探測。适用于伺服器之間的準即時操作。核心是基于XML流傳輸，這個協定可能最終允許網際網路使用者向網際網路上的其他任何人發送即時消息，即使其作業系統和浏覽器不同。
優點：通用公開、相容性強、可擴充、安全性高，但XML編碼格式占用帶寬大
▐ 基于TCP/IP自定義的協定
有些特殊架構（如：redis、kafka、rocketMQ等）根據自身需要未嚴格遵循MQ規範，而是基于TCP/IP自行封裝了一套二進制編解碼協定，通過網絡socket接口進行傳輸，實作了MQ的标準規範相關功能。
消息中間件推和拉模式對比
Push推模式：服務端除了負責消息存儲、處理請求，還需要儲存推送狀态、儲存訂閱關系、消費者負載均衡；推模式的實時性更好；如果push能力大于消費能力，可能導緻消費者崩潰或大量消息丢失
Push模式的主要優點是：
- 對使用者要求低，友善使用者擷取需要的資訊
- 及時性好，伺服器端即時地向用戶端推送更行的動态資訊
Push模式的主要缺點是：
- 推送的資訊可能并不能滿足用戶端的個性化需求
- Push消息大于消費者消費速率額，需要有協調QoS機制做到消費端回報
Pull拉模式：用戶端除了消費消息，還要儲存消息偏移量offset，以及異常情況下的消息暫存和recover；不能及時擷取消息，資料量大時容易引起broker消息堆積。
Pull拉模式的主要優點是：
- 針對性強，能滿足用戶端的個性化需求
- 用戶端按需擷取，伺服器端隻是被動接收查詢，對用戶端的查詢請求做出響應
Pull拉模式主要的缺點是：
- 實時較差，針對于伺服器端實時更新的資訊，用戶端難以擷取實時資訊
- 對于用戶端使用者的要求較高，需要維護位點
▐ 相關資料
建議學習以下的技術文檔，了解更多詳細的技術細節和實作原理，加深對消息中間件的了解和應用，同時可以下載下傳開源的源代碼，本地調試相應的代碼，加深對技術原理的了解和概念的掌握，以及在實際生産中更多的掌握不同的消息隊列應用的場景下，高效和正确地使用消息中間件。
RocketMQ資料：
https://github.com/apache/rocketmq/tree/master/docs/cnKafka資料：
http://kafka.apache.org/documentation/#introduction阿裡雲RocketMQ文檔：
https://help.aliyun.com/document_detail/112010.html賽事資訊
正在進行中的“2021第二屆雲原生程式設計挑戰賽”中有“針對冷熱讀寫場景的RocketMQ存儲系統設計”這個賽道，其中RocketMQ這個主題與本文内容息息相關。
看完這篇文章後，對此領域有興趣的同學可以點選閱讀原文，擷取賽事相關資訊。