RabbitMQ 4.1.1初體驗

*為什么選擇 RabbitMQ？**

RabbitMQ 是一款可靠且成熟的消息代理和流處理中間件，可輕松部署在云端、本地數據中心或您的開發機上，目前已被全球數百萬用戶使用。
優勢在哪里
互操作性
RabbitMQ 支持多種開放標準協議，包括 AMQP 1.0 和 MQTT 5.0，并提供多種編程語言的客戶端庫，您只需選擇適合自己語言的版本即可，無需擔心廠商鎖定！

靈活性
RabbitMQ 提供多種功能組合，可自定義消息從生產者到單個或多個消費者的傳遞方式，如路由、過濾、流處理、聯邦傳輸等，應有盡有。

可靠性
通過消息確認機制和集群消息復制，RabbitMQ 能確保您的消息安全無誤。
在這里插入圖片描述
總結
RabbitMQ 是輕量級、易用、功能全面的消息中間件，適合需要靈活路由、多協議支持、高可靠性的場景。如果您的業務需要簡單的任務隊列或復雜的事件路由，RabbitMQ 是理想選擇；若是日志處理或大數據流，可考慮 Kafka。

常見使用場景示例

以下是來自社區或客戶的一些典型用例，幫助您更好地理解 RabbitMQ 的功能及其實際應用價值。

1. 解耦互聯服務（通過RabbitMQ實現通知系統）

在這里插入圖片描述

場景描述
你有一個后端服務，需要向終端用戶發送通知。通知有兩種渠道：

電子郵件（Email）
移動應用推送（Push Notification）

傳統做法可能是后端直接調用郵件服務和推送服務，但這會導致：

系統緊耦合：如果郵件服務宕機，可能影響整個通知流程。
無法應對突發流量：如果突然有大量通知請求，后端可能被壓垮。
維護困難：升級或維護某個通知服務時，需要停用整個系統。

RabbitMQ 的解決方案
使用 RabbitMQ 解耦后端服務和通知渠道，流程如下：

后端服務（Producer） 生成通知后，不直接調用郵件或推送服務，而是將消息發布到兩個獨立的隊列：
- email_queue（郵件隊列）
- push_queue（推送隊列）
郵件服務和推送服務（Consumer） 各自訂閱對應的隊列，并異步處理消息。
- [Backend Service]
  │
  ├── Publishes to → [email_queue] → Consumed by [Email Service]
  │
  └── Publishes to → [push_queue] → Consumed by [Push Notification Service]

2. 基于 RabbitMQ 的遠程過程調用（RPC）實現票務系統

在這里插入圖片描述
場景描述
你經營一個音樂廳，門票通過多個渠道銷售：

線上網站
線下自助終端（Kiosk）

所有渠道的訂單都需要經過復雜的票務庫存處理（如檢查余票、分配座位等），并且要求極低延遲的響應（用戶下單后需立即知道是否成功）。

傳統同步調用的問題

如果直接使用同步調用（如 HTTP API）：

高延遲：庫存服務處理時間不穩定，可能阻塞前端響應。
系統耦合：庫存服務宕機會導致所有銷售渠道不可用。
并發沖突：多個渠道同時搶票時，可能超賣（需依賴數據庫事務，性能低下）。

RabbitMQ 的 RPC 解決方案
通過 RabbitMQ 實現異步 RPC 調用，流程如下：

1、發布訂單請求
- 網站或終端（RPC Client）生成訂單，附帶唯一 correlation_id，發送到請求隊列
- [Client] → Publish to → [rpc_request_queue]
  (Message: {order_details, correlation_id})
2、處理訂單
- 庫存服務（RPC Server）從 rpc_request_queue 消費消息，處理業務邏輯（如檢查余票）。
3、返回響應
- 庫存服務將處理結果（成功/失敗）發送到響應隊列，并攜帶相同的 correlation_id：
- [Server] → Publish to → [rpc_reply_queue]
  (Message: {result, correlation_id})
4、客戶端接收響應
- 客戶端監聽 rpc_reply_queue，通過 correlation_id 匹配自己的請求，獲取結果。
- ±---------------+ ±------------------+
  | RPC Client | | RPC Server |
  | (Website/Kiosk)| | (Inventory Service)|
  ±------±-------+ ±--------±--------+
  | |
  | 1. Order + correlation_id|
  ±------------------------------------->+
  | |
  | 3. Result + correlation_id|
  <--------------------------------------+
  | |
  ±------±-------+ ±--------±--------+
  | rpc_request_queue | rpc_reply_queue |
  ±---------------+ ±------------------+

關鍵設計點

關聯 ID（correlation_id）
確保響應與請求正確匹配，避免多客戶端場景下的混亂。
隊列選擇
- 經典隊列（Classic Queue）：低延遲，但消息可能丟失（適合可重試場景）。
- 仲裁隊列（Quorum Queue）：高可靠性，通過多數節點確認保證消息安全（適合金融級場景）。
序列化處理
所有訂單按先進先出（FIFO）處理，避免超賣，無需數據庫事務。

實際應用擴展

機票預訂系統：多平臺同時搶票時，通過 RabbitMQ RPC 保證庫存一致性。
秒殺活動：突發流量下，用隊列緩沖請求，按序處理。

3、RabbitMQ流式處理（Streaming）詳解

在這里插入圖片描述

場景描述
你運營一個視頻平臺（如B站、YouTube）。當用戶上傳視頻后，系統需要完成多個后續任務：

1. 實時任務：立即通知訂閱該UP主的粉絲。

2、延遲任務：

視頻內容分析（如AI鑒黃、標簽提取）
轉碼生成多種清晰度的副本（如1080p、720p）
數據統計（如播放量預測）

傳統架構的問題
若用普通消息隊列（如RabbitMQ經典隊列）：

消息重復：每個任務需要獨立隊列，同一視頻上傳事件會被復制多份（通知隊列、轉碼隊列等），浪費資源。
無法回溯：消息被消費后即刪除，若分析服務崩潰，可能丟失數據。

RabbitMQ Streams的解決方案
1. 核心機制

持久化流（Stream）：
上傳服務將“新視頻”事件按順序追加到唯一流中（類似數據庫的WAL日志）。

[視頻上傳事件流]
──? [事件1: 視頻A上傳] → [事件2: 視頻B上傳] → [事件3: 視頻C上傳] → …

多消費者獨立訂閱：
每個后端服務（通知、轉碼、分析）可獨立讀取流中的事件，互不干擾。

2. 工作流程

2.1視頻上傳完成 → 事件寫入流（如video_upload_stream）。
2.2通知服務：
- 實時讀取最新事件，立即推送粉絲。
- 讀取后不刪除事件，其他服務仍可訪問。
2.3轉碼服務：
按自身速度消費事件，生成多分辨率視頻。
2.4分析服務：
每天凌晨批量讀取全天事件，運行離線分析。

3. 關鍵優勢

優勢	說明
高效無重復	所有任務共享同一流，無需為每個任務復制消息。
消費者獨立性	每個服務可自由控制讀取位置（如通知讀最新，分析讀歷史）。
消息可回溯	即使服務崩潰，重啟后可從斷點繼續消費，數據不丟失。
高吞吐	流式存儲針對順序讀寫優化，性能高于傳統隊列。

技術對比：Stream vs 經典隊列

特性	RabbitMQ經典隊列	RabbitMQ Streams
消息生命周期	消費后默認刪除	永久存儲（除非手動刪除）
多消費者	同一隊列消息只能被一個消費者	多消費者獨立讀取同一流
回溯能力	不支持	支持（通過偏移量定位）
適用場景	任務分發、RPC	事件溯源、日志處理

實際應用示例

視頻平臺（如案例所述）
電商訂單流水：
- 訂單創建事件寫入流，實時通知用戶、異步更新庫存、離線生成報表。
物聯網傳感器數據：
- 設備數據實時流，同時供監控告警和離線分析使用。

為何選擇RabbitMQ Streams？

解耦：上傳服務無需知道下游有哪些任務。
彈性：新增任務（如后續增加“視頻指紋提取”）只需新增一個消費者，無需改原有架構。
可靠性：消息持久化，即使服務器重啟也不丟失。

一句話總結： RabbitMQ Streams通過持久化、可共享的消息流，實現了高效、靈活的事件驅動架構，特別適合混合實時與離線處理的場景。

4、基于 RabbitMQ 的星際無人機（IoT）通信系統

在這里插入圖片描述

場景描述
你經營一家提供銀河系包裹配送的公司，擁有大量太空無人機（Space Drones）。這些無人機需要定期向位于系外行星 Kepler-438 b 的中央服務器上報狀態（如位置、電量、包裹狀態）。但星際網絡連接極不穩定，經常因行星軌道錯位或宇宙干擾中斷。
傳統方案的挑戰
若直接讓無人機通過 HTTP 或 TCP 連接中央服務器：

網絡不可靠：信號延遲高（可能幾小時到幾天），連接頻繁中斷。
數據丟失風險：斷網時無人機的狀態報告無法送達。
海量連接管理：數百萬無人機同時在線，服務器難以承受。

RabbitMQ 的解決方案

1. 分布式消息緩沖架構
- 每個無人機本地部署 RabbitMQ 節點：
  - 無人機將狀態報告先寫入本地 RabbitMQ（邊緣存儲），避免依賴實時網絡。
  - 數據持久化，即使無人機重啟也不會丟失。
- 上游中心化 RabbitMQ：
  - 位于 Kepler-438 b 的服務器運行主 RabbitMQ，接收所有無人機的最終數據。
2. 網絡恢復后同步數據
- 行星對齊時（網絡恢復）：
  本地 RabbitMQ 通過 Shovel/Federation 插件，將積壓的報告批量同步到上游服務器。
  - Shovel：單向跨節點消息轉移，適合臨時連接。
  - Federation：動態拓撲的消息同步，適合復雜網絡。
3. 協議選擇
- MQTT 協議：
  - 無人機與本地 RabbitMQ 之間使用 MQTT（輕量級 IoT 協議），支持：
    - 低功耗（適合太空設備）。
    - 高并發連接（百萬級無人機）。
  - RabbitMQ 通過 MQTT 插件 兼容此協議

系統架構圖

[無人機 Drone 1] → [本地 RabbitMQ] -
[無人機 Drone 2] → [本地 RabbitMQ] → 行星對齊時同步 → [上游 RabbitMQ (Kepler-438 b)] → [中央服務器]
… /
[無人機 Drone N] → [本地 RabbitMQ]

核心優勢（Benefits）

優勢	說明
離線優先	無人機在網絡中斷時仍能持續記錄數據，不會丟失報告。
彈性網絡適應	僅在網絡可用時同步，容忍高延遲和間歇性連接。
高并發支持	MQTT 協議優化海量設備連接，RabbitMQ 集群橫向擴展。
解耦與可靠性	中央服務器無需知道無人機是否在線，消息最終一致。

關鍵技術組件

1、RabbitMQ Shovel

將本地隊列的消息自動轉發到上游交換器。
配置示例：

{rabbitmq_shovel, [{shovels, [{drone_to_central, [{sources, [{brokers, ["localhost"]}]},{destinations, [{brokers, ["kepler-438b.server"]}]},{queue, <<"drone_reports">>}]}]}
]}

2、RabbitMQ Federation

跨星球的 RabbitMQ 節點形成聯邦，按需同步消息。
適合長期網絡不穩定的場景。

3、MQTT 插件

啟用 MQTT 協議支持：

rabbitmq-plugins enable rabbitmq_mqtt

對比其他消息中間件

特性	RabbitMQ (+MQTT)	Kafka	AWS IoT Core
離線支持	??（邊緣節點緩沖）	?（需持續連接）	??（但需額外配置）
協議兼容性	MQTT/AMQP/STOMP	自定義協議	僅MQTT/HTTP
部署復雜度	中（需配置Shovel）	高	低（全托管）
適用場景	邊緣計算+最終一致性	高吞吐日志流	純云端IoT

實際應用擴展

地球上的類似場景：
- 遠洋船舶、油田設備在衛星網絡間歇可用時的數據上報。
- 軍事無人機在敵占區的隱蔽通信。

其他行業：

智能電網（電表數據批量同步）。
自動駕駛車隊（離線時本地存儲，網絡恢復后上傳）。

總結
通過 RabbitMQ 的分布式消息隊列 + MQTT 協議，該系統實現了：

抗網絡中斷：邊緣節點緩沖數據，行星對齊時同步。
海量設備管理：MQTT 支持百萬級無人機連接。
靈活性：Shovel/Federation 適應不同網絡拓撲。
這種架構是 深空通信、邊緣計算、IoT 設備管理 的理想選擇！ 🚀

RabbitMQ工作模型

在這里插入圖片描述
rabbitmq和mysql作類比，理解rabbitmq概念：

broker 相當于mysql服務器
virtual host相當于數據庫（一個mysql服務器可以有多個數據庫，一臺broker可以有多個虛擬主機）
queue相當于表（一個數據庫有多張表，一個虛擬主機有多個隊列）
消息相當于記錄（一張表中有多條記錄，一個隊列中有多條消息）

消息隊列有三個核心要素： 消息生產者、消息隊列、消息消費者；
生產者（Producer）：發送消息的應用；（java程序，也可能是別的語言寫的程序）
消費者（Consumer）：接收消息的應用；（java程序，也可能是別的語言寫的程序）
代理（Broker）：就是消息服務器，RabbitMQ Server就是Message Broker；
連接（Connection）：連接RabbitMQ服務器的TCP長連接；
信道（Channel）：連接中的一個虛擬通道，消息隊列發送或者接收消息時，都是通過信道進行的；
虛擬主機（Virtual host）：一個虛擬分組，在代碼中就是一個字符串，當多個不同的用戶使用同一個RabbitMQ服務時，可以劃分出多個Virtual host，每個用戶在自己的Virtual host創建exchange/queue等；（分類比較清晰、相互隔離）
交換機（Exchange）：交換機負責從生產者接收消息，并根據交換機類型分發到對應的消息隊列中，起到一個路由的作用；
路由鍵（Routing Key）：交換機根據路由鍵來決定消息分發到哪個隊列，路由鍵是消息的目的地址；
綁定（Binding）：綁定是隊列和交換機的一個關聯連接（關聯關系）；
隊列（Queue）：存儲消息的緩存；
消息（Message）：由生產者通過RabbitMQ發送給消費者的信息；（消息可以為任何數據，字符串，user對象，json串，圖片，mp3，視頻等等）