消息隊(duì)列中間件

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

如下圖所示：

圖片

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

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

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

圖片

1.異步通信

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

2.解耦和解偶

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

圖片

3.削峰填谷

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

4.可靠性和持久化

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

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

消息隊(duì)列原理

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

圖片

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

1.生產(chǎn)者

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

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

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

2.消息存儲(chǔ)(Broker)

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

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

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

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

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

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

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

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

消息隊(duì)列類(lèi)型

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

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

圖片

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

2.發(fā)布訂閱

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

如下圖所示：

圖片

消息協(xié)議

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

1.JMS

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

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

2.AMQP

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

特點(diǎn)是：

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

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

3.MQTT

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

消息隊(duì)列有哪些

常見(jiàn)的消息隊(duì)列有：ActiveMQ、RocketMQ、Kafka、Pulsar、RabbitMQ等等。

如下圖所示：

圖片

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

選型比較

總的來(lái)說(shuō)

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

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

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