Stories

Detail Return Return

【Spring開發】SpringCloud服務端高級框架第6篇:RabbitMQ部署指南,1.單機部署【附代碼文檔】 - Stories Detail

🏆🏆🏆教程全知識點簡介:微服務保護、服務異步通信、消息中間件部署、分佈式事務、搜索引擎、緩存、數據同步以及相關組件的安裝配置等技術要點。在微服務保護方面,介紹了 Sentinel 的基礎知識,包括雪崩問題、超時處理、艙壁模式、斷路器機制,以及不同服務保護技術的對比;講解了流量控制(簇點鏈路、流控模式、熱點參數限流)、隔離與降級(FeignClient 整合 Sentinel、線程隔離)、授權規則(自定義異常結果)及規則持久化(規則管理模式與 pull 模式),並演示了基於 Nacos 的規則持久化改造。服務異步通信部分探討了消息可靠性(生產者消息確認、Return 回調、ConfirmCallback)、死信交換機、TTL 隊列等高級應用。RabbitMQ 部署指南涵蓋了單機部署、DelayExchange 插件安裝、集羣部署、鏡像模式等內容。分佈式事務部分介紹了 CAP 定理、BASE 理論、常見解決方案,Seata 的基礎與部署(TC 服務部署、Nacos 配置、數據庫表創建)、多種事務模式(XA 模式及優缺點、四種模式對比)和高可用架構。分佈式搜索引擎章節講解了 Elasticsearch 的原理(ELK 技術棧、倒排索引)、索引庫與文檔操作、RestAPI 與 RestClient 的使用、排序與高亮、酒店搜索案例(分頁、競價排名、ad標記、算分函數)、自動補全、數據同步(同步調用、監聽 binlog)、集羣搭建與腦裂問題、分片存儲測試,以及單點 ES、Kibana、IK 分詞器安裝。緩存部分介紹了 Redis 持久化(RDB 與 AOF 對比)、單機安裝 Redis、Redis 集羣、多級緩存(JVM 進程緩存、Caffeine)、請求參數處理、Tomcat 查詢、HTTP 工具與 CJSON 工具類、Redis 緩存查詢。數據同步與網關部分包括 Canal 安裝(開啓 MySQL 主從、設置權限)、OpenResty 安裝(開發庫、目錄結構、環境變量配置)及運行流程。

<!-- start:bj1 -->

📚📚👉👉👉git倉庫code.zip 直接get:   https://gitee.com/xiaoshuai112/Backend/blob/master/Spring/Spr...    🍅🍅

<!-- end:bj1 -->

✨ 本教程項目亮點

🧠 知識體系完整:覆蓋從基礎原理、核心方法到高階應用的全流程內容
💻 全技術鏈覆蓋:完整前後端技術棧,涵蓋開發必備技能
🚀 從零到實戰:適合 0 基礎入門到提升,循序漸進掌握核心能力
📚 豐富文檔與代碼示例:涵蓋多種場景,可運行、可複用
🛠 工作與學習雙參考:不僅適合系統化學習,更可作為日常開發中的查閲手冊
🧩 模塊化知識結構:按知識點分章節,便於快速定位和複習
📈 長期可用的技術積累:不止一次學習,而是能伴隨工作與項目長期參考

🎯🎯🎯全教程總章節


🚀🚀🚀本篇主要內容

RabbitMQ部署指南

1.單機部署

在Centos7虛擬機中使用Docker來安裝。

1.1.下載鏡像

方式一:在線拉取

docker pull rabbitmq:3.8-management

方式二:從本地加載

在課前資料已經提供了鏡像包:

上傳到虛擬機中後,使用命令加載鏡像即可:

docker load -i mq.tar

1.2.安裝MQ

執行下面的命令來運行MQ容器:

docker run \
 -e RABBITMQ_DEFAULT_USER=itcast \
 -e RABBITMQ_DEFAULT_PASS=123321 \
 -v mq-plugins:/plugins \
 --name mq \
 --hostname mq1 \
 -p 15672:15672 \
 -p 5672:5672 \
 -d \
 rabbitmq:3.8-management

2.安裝DelayExchange插件

官方的安裝指南地址為:https://blog.rabbitmq.com/posts/2015/04/scheduling-messages-w...

上述文檔是基於linux原生安裝RabbitMQ,然後安裝插件。

因為 之前是基於Docker安裝RabbitMQ,所以下面 會講解基於Docker來安裝RabbitMQ插件。

2.1.下載插件

RabbitMQ有一個官方的插件社區,地址為:https://www.rabbitmq.com/community-plugins.html

其中包含各種各樣的插件,包括 要使用的DelayExchange插件:

大家可以去對應的GitHub頁面下載3.8.9版本的插件,地址為https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases/tag/3.8.9這個對應RabbitMQ的3.8.5以上版本。

課前資料也提供了下載好的插件:

2.2.上傳插件

因為 是基於Docker安裝,所以需要先查看RabbitMQ的插件目錄對應的數據卷。如果不是基於Docker的同學,請參考第一章部分,重新創建Docker容器。

之前設定的RabbitMQ的數據卷名稱為mq-plugins,所以 使用下面命令查看數據卷:

docker volume inspect mq-plugins

可以得到下面結果:

接下來,將插件上傳到這個目錄即可:

2.3.安裝插件

最後就是安裝了,需要進入MQ容器內部來執行安裝。我的容器名為mq,所以執行下面命令:

docker exec -it mq bash

執行時,請將其中的 -it 後面的mq替換為你自己的容器名.

進入容器內部後,執行下面命令開啓插件:

rabbitmq-plugins enable rabbitmq_delayed_message_exchange

結果如下:

3.集羣部署

接下來, 看看如何安裝RabbitMQ的集羣。

2.1.集羣分類

在RabbitMQ的官方文檔中,講述了兩種集羣的配置方式:

  • 普通模式:普通模式集羣不進行數據同步,每個MQ都有自己的隊列、數據信息(其它元數據信息如交換機等會同步)。例如 有2個MQ:mq1,和mq2,如果你的消息在mq1,而你連接到了mq2,那麼mq2會去mq1拉取消息,然後返回給你。如果mq1宕機,消息就會丟失。

Asciidoctor 文檔

  • 鏡像模式:與普通模式不同,隊列會在各個mq的鏡像節點之間同步,因此你連接到任何一個鏡像節點,均可獲取到消息。而且如果一個節點宕機,並不會導致數據丟失。不過,這種方式增加了數據同步的帶寬消耗。

先來看普通模式集羣, 的計劃部署3節點的mq集羣:

主機名 控制枱端口 amqp通信端口
mq1 8081 ---> 15672 8071 ---> 5672
mq2 8082 ---> 15672 8072 ---> 5672
mq3 8083 ---> 15672 8073 ---> 5672

集羣中的節點標示默認都是:rabbit@[hostname],因此以上三個節點的名稱分別為:

  • rabbit@mq1
  • rabbit@mq2
  • rabbit@mq3

2.2.獲取cookie

RabbitMQ底層依賴於Erlang,而Erlang虛擬機就是一個面向分佈式的語言,默認就支持集羣模式。集羣模式中的每個RabbitMQ 節點使用 cookie 來確定它們是否被允許相互通信。

要使兩個節點能夠通信,它們必須具有相同的共享秘密,稱為Erlang cookie。cookie 只是一串最多 255 個字符的字母數字字符。

每個集羣節點必須具有相同的 cookie。實例之間也需要它來相互通信。

先在之前啓動的mq容器中獲取一個cookie值,作為集羣的cookie。執行下面的命令:

docker exec -it mq cat /var/lib/rabbitmq/.erlang.cookie

Java67 博客

可以看到cookie值如下:

FXZMCVGLBIXZCDEMMVZQ

Eclipse Jetty 文檔

接下來,停止並刪除當前的mq容器, 重新搭建集羣。

docker rm -f mq

2.3.準備集羣配置

在/tmp目錄新建一個配置文件 rabbitmq.conf:

cd /tmp
# 創建文件
touch rabbitmq.conf

文件內容如下:

loopback_users.guest = false
listeners.tcp.default = 5672
cluster_formation.peer_discovery_backend = rabbit_peer_discovery_classic_config
cluster_formation.classic_config.nodes.1 = rabbit@mq1
cluster_formation.classic_config.nodes.2 = rabbit@mq2
cluster_formation.classic_config.nodes.3 = rabbit@mq3

再創建一個文件,記錄cookie

cd /tmp
# 創建cookie文件
touch .erlang.cookie
# 寫入cookie
echo "FXZMCVGLBIXZCDEMMVZQ" > .erlang.cookie
# 修改cookie文件的權限
chmod 600 .erlang.cookie

準備三個目錄,mq1、mq2、mq3:

cd /tmp
# 創建目錄
mkdir mq1 mq2 mq3

然後拷貝rabbitmq.conf、cookie文件到mq1、mq2、mq3:

# 進入/tmp
cd /tmp
# 拷貝
cp rabbitmq.conf mq1
cp rabbitmq.conf mq2
cp rabbitmq.conf mq3
cp .erlang.cookie mq1
cp .erlang.cookie mq2
cp .erlang.cookie mq3

2.4.啓動集羣

創建一個網絡:

docker network create mq-net

docker volume create

運行命令

docker run -d --net mq-net \
-v ${PWD}/mq1/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf \
-v ${PWD}/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie \
-e RABBITMQ_DEFAULT_USER=itcast \
-e RABBITMQ_DEFAULT_PASS=123321 \
--name mq1 \
--hostname mq1 \
-p 8071:5672 \
-p 8081:15672 \
rabbitmq:3.8-management
docker run -d --net mq-net \
-v ${PWD}/mq2/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf \
-v ${PWD}/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie \
-e RABBITMQ_DEFAULT_USER=itcast \
-e RABBITMQ_DEFAULT_PASS=123321 \
--name mq2 \
--hostname mq2 \
-p 8072:5672 \
-p 8082:15672 \
rabbitmq:3.8-management

VisualVM 文檔

docker run -d --net mq-net \
-v ${PWD}/mq3/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf \
-v ${PWD}/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie \
-e RABBITMQ_DEFAULT_USER=itcast \
-e RABBITMQ_DEFAULT_PASS=123321 \
--name mq3 \
--hostname mq3 \
-p 8073:5672 \
-p 8083:15672 \
rabbitmq:3.8-management

2.5.測試

在mq1這個節點上添加一個隊列:

![image-20210717222833196](images/image-20210717222833196_2025072

Disruptor 文檔

4.鏡像模式

在剛剛的案例中,一旦創建隊列的主機宕機,隊列就會不可用。不具備高可用能力。如果要解決這個問題,必須使用官方提供的鏡像集羣方案。

官方文檔地址:https://www.rabbitmq.com/ha.html

4.1.鏡像模式的特徵

默認情況下,隊列只保存在創建該隊列的節點上。而鏡像模式下,創建隊列的節點被稱為該隊列的主節點,隊列還會拷貝到集羣中的其它節點,也叫做該隊列的鏡像節點。

但是,不同隊列可以在集羣中的任意節點上創建,因此不同隊列的主節點可以不同。甚至,一個隊列的主節點可能是另一個隊列的鏡像節點

用户發送給隊列的一切請求,例如發送消息、消息回執默認都會在主節點完成,如果是從節點接收到請求,也會路由到主節點去完成。鏡像節點僅僅起到備份數據作用

當主節點接收到消費者的ACK時,所有鏡像都會刪除節點中的數據。

總結如下:

  • 鏡像隊列結構是一主多從(從就是鏡像)
  • 所有操作都是主節點完成,然後同步給鏡像節點
  • 主宕機後,鏡像節點會替代成新的主(如果在主從同步完成前,主就已經宕機,可能出現數據丟失)
  • 不具備負載均衡功能,因為所有操作都會有主節點完成(但是不同隊列,其主節點可以不同,可以利用這個提高吞吐量)

4.2.鏡像模式的配置

鏡像模式的配置有3種模式:

ha-mode ha-params 效果
準確模式exactly 隊列的副本量count 集羣中隊列副本(主服務器和鏡像服務器之和)的數量。count如果為1意味着單個副本:即隊列主節點。count值為2表示2個副本:1個隊列主和1個隊列鏡像。換句話説:count = 鏡像數量 + 1。如果羣集中的節點數少於count,則該隊列將鏡像到所有節點。如果有集羣總數大於count+1,並且包含鏡像的節點出現故障,則將在另一個節點上創建一個新的鏡像。
all (none) 隊列在羣集中的所有節點之間進行鏡像。隊列將鏡像到任何新加入的節點。鏡像到所有節點將對所有羣集節點施加額外的壓力,包括網絡I / O,磁盤I / O和磁盤空間使用情況。推薦使用exactly,設置副本數為(N / 2 +1)。
nodes node names 指定隊列創建到哪些節點,如果指定的節點全部不存在,則會出現異常。如果指定的節點在集羣中存在,但是暫時不可用,會創建節點到當前客户端連接到的節點。

這裏 以rabbitmqctl命令作為案例來講解配置語法。

語法示例:

4.2.1.exactly模式

rabbitmqctl set_policy ha-two "^two\." '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'
  • rabbitmqctl set_policy:固定寫法
  • ha-two:策略名稱,自定義
  • "^two\.":匹配隊列的正則表達式,符合命名規則的隊列才生效,這裏是任何以two.開頭的隊列名稱
  • '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}': 策略內容

Add a new Comments

Some HTML is okay.