消息隊列是大型高并發(fā)架構(gòu)的核心，也是大廠重點考察的對象，下面我就全面來詳解消息隊列。

消息隊列

消息隊列，全稱是：“MessageQueue”，很多時候我們也簡稱為：“ MQ”，本質(zhì)就是一個保存消息的隊列。

如下圖所示：

允許不同的應用程序通過發(fā)送、和接收消息進行數(shù)據(jù)交換，從而實現(xiàn)系統(tǒng)解耦、提高系統(tǒng)可擴展性、和性能。

主要解決以下幾點問題：

1.異步通信

異步通信是指：系統(tǒng)中的組件通過消息隊列，進行異步消息傳遞，發(fā)送者不需要等待接收者處理完畢，即可繼續(xù)執(zhí)行其他任務。

比如：郵件服務異步發(fā)送郵件給用戶，注冊服務立即返回響應給用戶，而不必等待郵件發(fā)送完成，這就是典型的”異步通信“。

2.解耦

消息隊列使生產(chǎn)者，和消費者之間解耦，生產(chǎn)者只需將消息發(fā)送到消息隊列中，而不需要知道消息的最終處理者是誰。

這種解耦使得系統(tǒng)組件之間的依賴關(guān)系減少，提高了系統(tǒng)的靈活性、和可維護性。

3.可靠性

消息隊列可以保證消息的可靠傳輸，比如：可以通過持久化、和確認機制，確保消息不丟失。

4.流量削峰

消息隊列可以緩解突發(fā)流量對系統(tǒng)的壓力，比如：在搶購活動中，訂單請求量在短時間內(nèi)激增。

消息隊列：可以暫存這些訂單請求，后臺服務按能力逐步處理，防止系統(tǒng)癱瘓，這就是典型的”流量削峰“。

總之，消息隊列可以用于：解耦、異步處理、削峰填谷、和可靠傳輸...等場景，使得它在現(xiàn)代分布式系統(tǒng)、和微服務架構(gòu)中成為關(guān)鍵組件。

消息隊列原理

消息隊列的實現(xiàn)，如下圖所示：

MQ的整體架構(gòu)通常包括以下幾個組件：

生產(chǎn)者（Producer）：

生產(chǎn)者：是負責生成、和發(fā)送消息到消息隊列的應用程序、或組件。

生產(chǎn)者可以是任何生成數(shù)據(jù)的系統(tǒng)部分，比如：用戶操作觸發(fā)的事件、定時任務、數(shù)據(jù)采集系統(tǒng)。。。等。

還是舉一個例子：在電子商務系統(tǒng)中，訂單服務在用戶提交訂單后生成訂單消息，并將其發(fā)送到訂單處理隊列中，這就是生產(chǎn)者。

消息代理（Broker）：

生產(chǎn)者將生成的消息，發(fā)送到消息代理（Broker），并指定消息應存儲的隊列、或主題。

這里的代理(Broker)：就是負責消息接收、存儲、和分發(fā)消息的中間件。

• 接收消息：從生產(chǎn)者接收消息，并確認接收成功；

• 存儲消息：將消息存儲在內(nèi)存、或持久化存儲中，根據(jù)配置、和需求選擇存儲策略；

• 分發(fā)消息：根據(jù)消費者的訂閱、和隊列的配置，將消息傳遞給相應的消費者；

• 路由和負載均衡：決定消息的分發(fā)路徑，確保系統(tǒng)負載均衡、和高效運行。

消息隊列（Queue）：

queue就是：存儲消息的容器，按照一定順序傳遞消息。

消費者（Consumer）：

這個沒什么可說的，就是消費者：從消息隊列讀取并處理消息的應用程序、或組件。

消息體（Message）：

消息的內(nèi)容，包括消息頭（metadata）和消息體（payload）。

• 消息頭（Metadata）：包含消息的元數(shù)據(jù)，如消息ID、時間戳、優(yōu)先級、路由信息...等。

• 消息體（Payload）：實際傳遞的數(shù)據(jù)內(nèi)容，可以是文本、二進制數(shù)據(jù)、JSON、XML......等格式。

消息冪等性

除了考慮上面的設(shè)計外，還需要考到如何避免重復處理。

比如：如何確保消費者處理消息時具備冪等性，即同一消息多次處理不會造成副作用。

可以通過消息ID、狀態(tài)記錄等手段實現(xiàn)冪等性。

去重策略

對于可能重復的消息，設(shè)計去重策略，確保同一消息只被處理一次。

消息隊列類型

消息隊列主要包含兩種，一個是”點對點“，一個是”發(fā)布訂閱模型“。

1.點對點

在點對點模型中，消息在隊列中存儲，只有一個消費者可以消費該消息，一旦消息被消費，它就會從隊列中移除。

應用場景：

• 訂單處理系統(tǒng)：訂單服務將訂單消息放入隊列，每個訂單消息只需要被一個處理服務消費和處理。

2.發(fā)布/訂閱

在發(fā)布訂閱模型中，消息發(fā)布者將消息發(fā)送到主題（Topic），所有訂閱該主題的消費者都可以接收到消息。

如下圖所示：

每條消息可以被多個消費者消費，消息不會因為被某個消費者讀取而刪除。

發(fā)布訂閱模型包含三個角色：

• 發(fā)布者（Publisher）：生成并發(fā)送消息到主題的應用程序、或組件;

• 主題（Topic）：存儲消息的容器，允許多個消費者訂閱;

• 訂閱者（Subscriber）：訂閱主題并接收消息的應用程序、或組件。

應用場景：

• 日志收集系統(tǒng)：日志生成者將日志消息發(fā)布到主題，多個日志處理器（如：分析系統(tǒng)、監(jiān)控系統(tǒng)）訂閱該主題，接收日志消息進行處理。

3.點對點模式和發(fā)布訂閱模式的區(qū)別

主要體現(xiàn)在如下3點：

1、消息接收者的區(qū)別

點對點：每條消息只被一個消費者接收和處理。

發(fā)布訂閱：每條消息可以被,多個訂閱者接收、和處理。

2、消息存儲方式的區(qū)別

點對點：消息存儲在隊列中，消費者讀取后消息從隊列中刪除。

發(fā)布訂閱：消息存儲在主題中，所有訂閱者接收完消息后消息才會刪除。

3、適用場景的區(qū)別

點對點：適用于需要保證消息只處理一次的場景，如：任務處理、訂單處理。

發(fā)布訂閱：適用于需要廣播消息的場景，如：日志收集、事件通知。

常用的消息隊列？

以下是一些常用的消息隊列系統(tǒng)：

1.RabbitMQ

RabbitMQ是基于AMQP協(xié)議的開源消息代理，具有高可靠性、靈活的路由功能和豐富的插件。

采用Erlang語言開發(fā)，支持集群和高可用性配置。

廣泛應用于微服務架構(gòu)、異步通信、消息分發(fā)和實時數(shù)據(jù)處理。

2.Apache Kafka

Kafka是Apache的分布式流處理平臺，具有高吞吐量、低延遲、持久化和水平擴展能力。

架構(gòu)：采用分區(qū)和副本機制，保證高可用和數(shù)據(jù)可靠性。

應用：適用于實時數(shù)據(jù)流處理、日志收集、事件驅(qū)動系統(tǒng)和大數(shù)據(jù)分析。

性能：極高的吞吐量和低延遲，適用于大規(guī)模數(shù)據(jù)流處理、和分析場景。

3.ActiveMQ

ActiveMQ是Apache基金會的開源消息中間件，支持JMS規(guī)范，具有高性能、可靠性和靈活性。

適用于中等到高負載的場景，性能較為穩(wěn)定，但在高吞吐量場景下不如Kafka。

4.RocketMQ

RocketMQ是Apache的分布式消息中間件，最早是阿里開發(fā)的，具有高性能、低延遲、可靠性和水平擴展性。

架構(gòu)：基于分布式架構(gòu)，支持順序消息、事務消息和定時消息。

應用：廣泛應用于金融、電子商務和大數(shù)據(jù)領(lǐng)域。

性能：高吞吐量和低延遲，適用于大規(guī)模消息處理和傳輸。

5.Apache Pulsar

Pulsar是Apache的分布式消息流平臺，支持多租戶、水平擴展和低延遲。

采用多層架構(gòu)，分為存儲層和計算層，支持分區(qū)和副本機制。

適用于實時數(shù)據(jù)處理、日志收集和事件流處理，具有高吞吐量、低延遲，適用于大規(guī)模實時數(shù)據(jù)流處理。

閱讀原文：原文鏈接