消息隊列中間件詳解，你學會了嗎？
消息隊列中間件
消息隊列就是Message Queue，本質就是一個保存消息的隊列。
如下圖所示：
圖片
消息隊列通常由一個中間件組件提供，它作為消息的中轉站，負責接收、存儲和轉發消息。發送者將消息發送到消息隊列中，接收者則從隊列中獲取消息進行處理。
消息中間件應用場景
消息隊列的應用場景，主要包含：異步、解耦、削峰等，如下圖所示：
圖片
1.異步通信
發送方和接收方不需要直接進行實時的通信，而是通過消息隊列中間件進行異步的消息傳遞
2.解耦和解偶
消息隊列可以將發送方和接收方解耦，使得它們可以獨立地進行開發、部署和維護
圖片
3.削峰填谷
消息隊列可以緩沖和平衡消息的流量，當發送方發送大量的消息時，消息隊列可以將消息暫存起來，并按照接收方的處理能力逐漸進行消費。
4.可靠性和持久化
消息隊列通常具有可靠的消息傳遞機制，可以確保消息在發送和接收過程中的可靠性。
一些消息隊列還支持消息的持久化，即將消息存儲到持久化存儲介質中，以防止消息丟失。
消息隊列原理
消息隊列中間件的原理，如下圖所示：
圖片
主要會包含：生產者、Broker、消費者...等。
1.生產者
生產者，主要負責發送消息，生產者將消息發送到消息隊列。
生產者根據業務邏輯生成消息，這些消息包含各種數據，例如：用戶請求、系統事件、日志記錄...等。
消費的類型：消息可以是文本、JSON、XML、或其他格式的......數據。
2.消息存儲(Broker)
Broker：主要負責接收、存儲和轉發消息，通常具有持久化機制，確保消息不丟失。
Broker還將消息分發給合適的消費者，可以通過輪詢、負載均衡...等方式進行調度。
以及，Broker需要等待消費者確認消息已被成功處理，然后才會將該消息從隊列中移除，確保消息不被丟失。
3.消費者接收消息
消費者是消息的接收者和處理者，它從消息隊列中讀取消息，并執行相應的業務邏輯。
消費者從Broker中讀取消息，可以是主動拉取（Pull）、或被動推送（Push）模式。
處理完成后，消費者需要向Broker發送確認信息，通知Broker該消息已被成功處理。
如果沒有確認，消息可以重新投遞，確保處理的可靠性。
消息隊列類型
消息隊列主要包含兩種：一個是點對點，一個是發布訂閱模型。
1.點對點
圖片
點對點的特點：每個消息只有一個消費者（Consumer），即一旦被消費，消息就不再在消息隊列中。
2.發布訂閱
發布訂閱模型包含三個角色：主題（Topic）、發布者（Publisher）、訂閱者（Subscriber）。
如下圖所示：
圖片
消息協議
消息協議是消息隊列中間件的重要組成部分，決定了消息的格式、傳輸方式、和通信規則。
1.JMS
Java Message Service（JMS）是Java平臺上用于消息通信的標準API，提供了一種通用的方式來創建、發送、接收和讀取消息。
比如：老牌的ActiveMQ，就是典型的JMS實現。
2.AMQP
AMQP，全程是“Advanced Message Queuing Protocol”，是一種開放標準的應用層協議。
特點是：
- AMQP協議設計為與平臺無關，支持多種編程語言；
- 通過交換機（Exchange），實現復雜的消息路由機制，包括：直接交換（Direct）、主題交換（Topic）...等。
- 支持消息確認、持久化、事務、死信隊列...等功能，確保消息的可靠傳遞和處理。
rabbitmq，就是典型的AMQP的實現。
3.MQTT
Message Queuing Telemetry Transport（MQTT），是一種輕量級的發布/訂閱消息協議，設計用于低帶寬、高延遲、或不可靠的網絡環境。
消息隊列有哪些
常見的消息隊列有：ActiveMQ、RocketMQ、Kafka、Pulsar、RabbitMQ等等。
如下圖所示：
圖片
- RabbitMQ：RabbitMQ是一個開源的消息隊列系統，它實現了AMQP（Advanced Message Queuing Protocol）協議，并提供了豐富的功能，如消息持久化、消息確認、靈活的路由和綁定等。
- Apache Kafka：Apache Kafka是一個分布式的流式平臺，它可以處理大規模的實時數據流。Kafka基于發布-訂閱模型，具有高吞吐量和持久性，適用于處理大量實時數據的場景。
- ActiveMQ：ActiveMQ是Apache基金會的一個開源消息中間件，支持JMS（Java Message Service）規范。它提供了多種通信模式，如點對點（P2P）和發布-訂閱（Pub/Sub），并具有可靠性、可擴展性和高可用性。
- Redis：Redis是一個內存數據庫，但也可以用作消息隊列。Redis提供了List、Pub/Sub等數據結構和命令，可以實現簡單的消息隊列功能。
- Apache Pulsar：Apache Pulsar是一個開源的分布式消息和流處理平臺，具有高性能、可擴展性和持久化特性。Pulsar支持多租戶、多數據中心部署和動態擴展，適用于大規模和復雜的消息隊列和流處理場景。
選型比較
ActiveMQ | JMS，多協議支持 | 成熟穩定，功能豐富，多語言支持 | 性能有限，管理復雜 | 中小規模企業應用，需要JMS功能支持的場景 |
RocketMQ | 高性能，強事務消息，分布式架構 | 高吞吐量低延遲，分布式，強一致性 | 社區支持少，運維復雜 | 互聯網和金融系統，高吞吐量和嚴格一致性場景 |
Kafka | 高吞吐量，日志式存儲，分區和復制 | 高性能，可擴展，生態系統豐富 | 延遲較高，不支持事務消息 | 大數據處理，實時流處理，需要高吞吐和擴展性場景 |
Pulsar | 多租戶，分層架構，原生流處理 | 高性能，持久化存儲，靈活擴展 | 學習曲線陡，社區和生態系統較小 | 云環境和企業系統，多租戶和高性能消息傳遞場 |
RabbitMQ | 基于AMQP，靈活路由，豐富插件 | 易于使用，功能豐富，多語言支持 | 性能有限，集群管理復雜 | 中小規模企業應用，復雜路由和消息確認場景 |
總的來說
互聯網和金融系統，高吞吐量和嚴格一致性場景，可以選擇：RocketMQ;
中小規模企業應用，復雜路由、和消息確認場景，可以選擇：RabbitMQ;
大數據處理，實時流處理，需要高吞吐、和擴展性場景，可以選擇Kafka。
