消息隊列中間件

消息隊列就是Message Queue，本質(zhì)就是一個保存消息的隊列。

如下圖所示：

圖片

消息隊列通常由一個中間件組件提供，它作為消息的中轉(zhuǎn)站，負(fù)責(zé)接收、存儲和轉(zhuǎn)發(fā)消息。發(fā)送者將消息發(fā)送到消息隊列中，接收者則從隊列中獲取消息進(jìn)行處理。

消息中間件應(yīng)用場景

消息隊列的應(yīng)用場景，主要包含：異步、解耦、削峰等，如下圖所示：

圖片

1.異步通信

發(fā)送方和接收方不需要直接進(jìn)行實時的通信，而是通過消息隊列中間件進(jìn)行異步的消息傳遞

2.解耦和解偶

消息隊列可以將發(fā)送方和接收方解耦，使得它們可以獨(dú)立地進(jìn)行開發(fā)、部署和維護(hù)

圖片

3.削峰填谷

消息隊列可以緩沖和平衡消息的流量，當(dāng)發(fā)送方發(fā)送大量的消息時，消息隊列可以將消息暫存起來，并按照接收方的處理能力逐漸進(jìn)行消費(fèi)。

4.可靠性和持久化

消息隊列通常具有可靠的消息傳遞機(jī)制，可以確保消息在發(fā)送和接收過程中的可靠性。

一些消息隊列還支持消息的持久化，即將消息存儲到持久化存儲介質(zhì)中，以防止消息丟失。

消息隊列原理

消息隊列中間件的原理，如下圖所示：

圖片

主要會包含：生產(chǎn)者、Broker、消費(fèi)者...等。

1.生產(chǎn)者

生產(chǎn)者，主要負(fù)責(zé)發(fā)送消息，生產(chǎn)者將消息發(fā)送到消息隊列。

生產(chǎn)者根據(jù)業(yè)務(wù)邏輯生成消息，這些消息包含各種數(shù)據(jù)，例如：用戶請求、系統(tǒng)事件、日志記錄...等。

消費(fèi)的類型：消息可以是文本、JSON、XML、或其他格式的......數(shù)據(jù)。

2.消息存儲(Broker)

Broker：主要負(fù)責(zé)接收、存儲和轉(zhuǎn)發(fā)消息，通常具有持久化機(jī)制，確保消息不丟失。

Broker還將消息分發(fā)給合適的消費(fèi)者，可以通過輪詢、負(fù)載均衡...等方式進(jìn)行調(diào)度。

以及，Broker需要等待消費(fèi)者確認(rèn)消息已被成功處理，然后才會將該消息從隊列中移除，確保消息不被丟失。

3.消費(fèi)者接收消息

消費(fèi)者是消息的接收者和處理者，它從消息隊列中讀取消息，并執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。

消費(fèi)者從Broker中讀取消息，可以是主動拉?。≒ull）、或被動推送（Push）模式。

處理完成后，消費(fèi)者需要向Broker發(fā)送確認(rèn)信息，通知Broker該消息已被成功處理。

如果沒有確認(rèn)，消息可以重新投遞，確保處理的可靠性。

消息隊列類型

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

1.點(diǎn)對點(diǎn)

圖片

點(diǎn)對點(diǎn)的特點(diǎn)：每個消息只有一個消費(fèi)者（Consumer），即一旦被消費(fèi)，消息就不再在消息隊列中。

2.發(fā)布訂閱

發(fā)布訂閱模型包含三個角色：主題（Topic）、發(fā)布者（Publisher）、訂閱者（Subscriber）。

如下圖所示：

圖片

消息協(xié)議

消息協(xié)議是消息隊列中間件的重要組成部分，決定了消息的格式、傳輸方式、和通信規(guī)則。

1.JMS

Java Message Service（JMS）是Java平臺上用于消息通信的標(biāo)準(zhǔn)API，提供了一種通用的方式來創(chuàng)建、發(fā)送、接收和讀取消息。

比如：老牌的ActiveMQ，就是典型的JMS實現(xiàn)。

2.AMQP

AMQP，全程是“Advanced Message Queuing Protocol”，是一種開放標(biāo)準(zhǔn)的應(yīng)用層協(xié)議。

特點(diǎn)是：

• AMQP協(xié)議設(shè)計為與平臺無關(guān)，支持多種編程語言；
• 通過交換機(jī)（Exchange），實現(xiàn)復(fù)雜的消息路由機(jī)制，包括：直接交換（Direct）、主題交換（Topic）...等。
• 支持消息確認(rèn)、持久化、事務(wù)、死信隊列...等功能，確保消息的可靠傳遞和處理。

rabbitmq，就是典型的AMQP的實現(xiàn)。

3.MQTT

Message Queuing Telemetry Transport（MQTT），是一種輕量級的發(fā)布/訂閱消息協(xié)議，設(shè)計用于低帶寬、高延遲、或不可靠的網(wǎng)絡(luò)環(huán)境。

消息隊列有哪些

常見的消息隊列有：ActiveMQ、RocketMQ、Kafka、Pulsar、RabbitMQ等等。

如下圖所示：

圖片

1. RabbitMQ：RabbitMQ是一個開源的消息隊列系統(tǒng)，它實現(xiàn)了AMQP（Advanced Message Queuing Protocol）協(xié)議，并提供了豐富的功能，如消息持久化、消息確認(rèn)、靈活的路由和綁定等。
2. Apache Kafka：Apache Kafka是一個分布式的流式平臺，它可以處理大規(guī)模的實時數(shù)據(jù)流。Kafka基于發(fā)布-訂閱模型，具有高吞吐量和持久性，適用于處理大量實時數(shù)據(jù)的場景。
3. ActiveMQ：ActiveMQ是Apache基金會的一個開源消息中間件，支持JMS（Java Message Service）規(guī)范。它提供了多種通信模式，如點(diǎn)對點(diǎn)（P2P）和發(fā)布-訂閱（Pub/Sub），并具有可靠性、可擴(kuò)展性和高可用性。
4. Redis：Redis是一個內(nèi)存數(shù)據(jù)庫，但也可以用作消息隊列。Redis提供了List、Pub/Sub等數(shù)據(jù)結(jié)構(gòu)和命令，可以實現(xiàn)簡單的消息隊列功能。
5. Apache Pulsar：Apache Pulsar是一個開源的分布式消息和流處理平臺，具有高性能、可擴(kuò)展性和持久化特性。Pulsar支持多租戶、多數(shù)據(jù)中心部署和動態(tài)擴(kuò)展，適用于大規(guī)模和復(fù)雜的消息隊列和流處理場景。

選型比較

總的來說

互聯(lián)網(wǎng)和金融系統(tǒng)，高吞吐量和嚴(yán)格一致性場景，可以選擇：RocketMQ;

中小規(guī)模企業(yè)應(yīng)用，復(fù)雜路由、和消息確認(rèn)場景，可以選擇：RabbitMQ;

大數(shù)據(jù)處理，實時流處理，需要高吞吐、和擴(kuò)展性場景，可以選擇Kafka。