最早在項目里碰到消息隊列這個需求是做一個訂單通知功能。當時就是兩臺服務之間傳消息一臺收訂單另一臺給用戶發(fā)通知硬編碼 HTTP 調用也能跑但接收方一旦出問題消息就丟了重試補償全得自己寫。換成 RabbitMQ 之后生產者和消費者徹底解耦發(fā)送方不需要關心對端在不在線接收方也不用手忙腳亂地處理瞬時并發(fā)。RabbitMQ 的“消息隊列 插件擴展”這套組合后來幾乎成了我項目里做異步和解耦的首選方案。這篇文章不打算從零開始講理論而是圍繞“安裝”和“插件”這兩條主線來寫怎么把 RabbitMQ 裝起來裝完怎么用插件擴展能力以及裝的過程中那些最容易讓人血壓升高的坑。市面上關于 RabbitMQ 的教程很多但大多是“給你命令、告訴你下一步”很少解釋關鍵選擇背后的原因。我會把每個步驟中需要考慮的版本、端口、權限、插件匹配這些問題也一并捋清楚看完你至少能在一臺新機器上獨立完成部署并且知道出了問題該往哪個方向查。1. 消息隊列那么多為什么大家最終都選了RabbitMQ1.1 一句話講清楚RabbitMQ是什么RabbitMQ 是一個基于 AMQP 0-9-1 協(xié)議的開源消息代理Message Broker用 Erlang 語言編寫。你可以把它理解成一個“中轉站”應用A把消息投遞到 RabbitMQ 上指定的位置應用B從這個位置上取走消息。關鍵在于A和B不需要同時在線也不用知道對方的存在。這個解耦能力在日常業(yè)務系統(tǒng)里非常實用。很多人剛開始接觸消息隊列時容易混淆一個概念RabbitMQ 本身不存儲業(yè)務數據它只是臨時保存消息直到消費者確認處理完為止。如果消費者一直不確認消息可以一直留在隊列里如果隊列里設置了消息 TTL超時沒消費的消息會被丟棄或者轉成死信。這套機制聽起來簡單但真正用好了可以做出很多高級功能比如延遲消息、重試隊列、消息審計。1.2 核心消息模型交換機、隊列、路由鍵的關系RabbitMQ 的消息流轉模型我一般這樣和新同事解釋生產者把消息交給交換機Exchange交換機根據路由鍵Routing Key把它投遞到一個或多個隊列Queue消費者再從隊列里取消息。交換機有四種主要類型決定了消息往哪里去Direct路由鍵精確匹配一條消息投到一個固定的隊列Topic路由鍵支持通配符匹配* 匹配一個詞、# 匹配零個或多個詞適合按主題分發(fā)Fanout忽略路由鍵把消息廣播到所有綁定的隊列Headers根據消息頭匹配實際用得較少。這里最容易犯的錯是“只創(chuàng)建隊列不創(chuàng)建交換機綁定”。消息發(fā)不出去、消費者收不到排查一圈下來往往是交換機和隊列之間根本沒有做 Binding。我以前也犯過這個毛病在管理頁面看到一個隊列于是往默認交換機里直接發(fā)消息結果隊列里啥都沒有折騰了半天才發(fā)現發(fā)錯交換機了。所以第一步理解模型遠比第一遍照抄命令重要。1.3 和Redis/Kafka相比RabbitMQ適合什么場景經常有人問有 Redis 的 List 可以做隊列有 Kafka 可以做高吞吐為什么還要用 RabbitMQ我的答案很直接它們解決的問題不一樣。Redis List適合輕量臨時隊列功能簡單消息丟失容忍度低沒有復雜的路由和確認機制Kafka天生面向海量日志和流處理場景吞吐量高但部署和維護成本高消息語義偏“拉取”RabbitMQ支持多種路由模式、消息確認、延遲隊列、死信隊列、優(yōu)先級隊列等企業(yè)級特性單機吞吐量雖不如 Kafka但在絕大多數業(yè)務系統(tǒng)里完全夠用。換句話說如果項目里要做異步通知、訂單超時關閉、任務分發(fā)這種“業(yè)務消息”場景RabbitMQ 的靈活性和穩(wěn)定性更有優(yōu)勢如果是數據管道、點擊流日志那優(yōu)先考慮 Kafka。選型這事沒有絕對正確只有適合當前業(yè)務所以安裝之前先判斷場景能少走很多彎路。2. 安裝前的版本匹配Erlang這一關怎么過2.1 RabbitMQ和Erlang版本對應關系RabbitMQ 是用 Erlang 寫的所以機器上必須裝一個匹配的 Erlang/OTP 運行時。很多人第一次裝 RabbitMQ最容易翻車的就是這一步隨便裝了個最新版 Erlang結果 RabbitMQ 服務啟動直接失敗日志里一堆看不懂的崩潰信息。官方文檔里其實維護了一張 RabbitMQ 與 Erlang 的版本兼容表比如新版本通常要求 Erlang 26.x老版本可能要求 Erlang 23.x 或 24.x。實際選擇原則很簡單以你下載的 RabbitMQ 版本對應的最低 Erlang 要求為準盡量不要裝高于官方推薦的主版本。比如 RabbitMQ 3.12.x 系列在 Erlang 25/26 上運行良好但如果你裝了 Erlang 27某些模塊可能就不兼容了。2.2 檢查開發(fā)環(huán)境里已有的Erlang在安裝 RabbitMQ 之前先檢查系統(tǒng)里是否已經有 Erlang避免后面裝重了或者環(huán)境變量沖突。Windows 下可以打開命令行erl -version正常情況下會輸出類似Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 15.0.1的信息。如果提示“不是內部或外部命令”說明 Erlang 還沒裝或者沒配環(huán)境變量。Linux 下可以這樣檢查erl -version # 或者查看安裝路徑 which erl erl -eval erlang:display(erlang:system_info(otp_release)), halt().最后一條命令會輸出 OTP 版本號比如26。我建議以這個輸出為準erl -version顯示的是模擬器版本不是完整的 OTP release 版本。這里有個細節(jié)RabbitMQ 官方 Windows 安裝包里Erlang 通常需要單獨安裝但 Linux 下如果通過發(fā)行版的包管理器安裝 RabbitMQErlang 可能會作為依賴自動裝上這時候版本是發(fā)行版幫你選好的一般不會有大問題。真正容易出問題的場景是手動下載 tar.gz 通用包安裝或者在內網離線環(huán)境里手動指定 Erlang RPM 包這時版本匹配就全靠自己把關了。2.3 常見版本錯誤示例與判斷方法我見過一個比較典型的報錯Windows 服務啟動時直接彈窗RabbitMQ service failed to start去 Windows 事件查看器里看應用程序日志發(fā)現里面有類似Failed to start erlang distribution或者Error when reading erlang cookie的內容。這類問題大概率出在 Erlang 版本不匹配或者 RabbitMQ 的erlang.cookie文件權限/內容異常。Linux 下啟動失敗時可以看日志journalctl -u rabbitmq-server -n 100 --no-pager或者直接查看/var/log/rabbitmq/下的startup_err日志。如果看到{error,{cannot_write_enabled_plugins_file,/etc/rabbitmq/enabled_plugins,...}}那是目錄權限問題如果看到{init terminating in do_boot,{undef,...}}往往和 Erlang 版本不匹配有關因為某些模塊不存在或者版本不對。判斷方法很粗暴但有效把報錯信息里出現的關鍵詞比如undef、badmatch、erlang、otp拼在一起去日志里搜索基本能定位是版本問題還是權限問題。版本問題優(yōu)先調整 Erlang 版本權限問題直接處理 RabbitMQ 安裝目錄和配置文件的屬主。3. 三套環(huán)境下的安裝實操記錄3.1 Windows圖形化安裝和服務啟動Windows 上安裝 RabbitMQ 總體比較省心流程是先裝 Erlang再裝 RabbitMQ Windows 安裝包。第一步下載并安裝匹配的 Erlang 安裝程序。安裝過程中建議記住安裝目錄通常默認是C:\Program Files\Erlang OTP。裝完手工確認一次erl -version能執(zhí)行再繼續(xù)下一步。第二步安裝 RabbitMQ。安裝包默認會注冊一個 Windows 服務服務名一般是RabbitMQ。安裝完不要急著直接打開管理頁面很多新手會卡在這一步網頁打不開。原因很簡單默認的管理插件還沒啟用。啟動服務有兩種方式圖形化方式是在“服務”窗口里找到 RabbitMQ 服務右鍵啟動命令行方式更直觀net start RabbitMQ如果啟動失敗先用sc query RabbitMQ查看服務狀態(tài)再去事件查看器找詳細日志。還有一個常見坑安裝路徑不能包含中文或空格過多否則 Erlang 啟動節(jié)點時解析路徑可能出現意外行為。3.2 Linux含歐拉/內網離線環(huán)境yum/apt與通用包Linux 下安裝路徑比較多樣。互聯網環(huán)境下CentOS/RHEL 系可以直接用官方 yum 倉庫Ubuntu/Debian 用 apt 倉庫也可以下載官方提供的通用 tar.gz 包。這里重點說幾個容易出錯的地方。CentOS 系使用官方倉庫前需要先安裝 RabbitMQ 提供的倉庫配置包然后執(zhí)行sudo yum update -y sudo yum install -y rabbitmq-serverUbuntu 下類似sudo apt update sudo apt install -y rabbitmq-server裝完之后啟動并設置開機自啟sudo systemctl enable rabbitmq-server sudo systemctl start rabbitmq-server但很多生產環(huán)境是內網隔離的尤其是國產化環(huán)境比如在歐拉系統(tǒng)上裝 RabbitMQ。內網環(huán)境沒法直接用 yum/apt 拉包這時候我一般走“離線 RPM 包 通用包”的方案在一臺能聯網的同系統(tǒng)機器上用yum download或apt download把 Erlang 和 RabbitMQ 的 RPM/deb 包下載下來把包傳到內網機器用rpm -ivh或dpkg -i安裝如果依賴關系復雜就用 RabbitMQ 官方提供的 generic-unix 壓縮包解壓后手工配置環(huán)境變量。通用包安裝方式類似這樣# 解壓到指定目錄 tar -xzf rabbitmq-server-generic-unix-*.tar.xz -C /opt # 設置環(huán)境變量 export PATH/opt/rabbitmq_server-3.12.x/sbin:$PATH # 啟動服務前臺運行便于看日志 rabbitmq-server start內網離線安裝的關鍵是版本一致Erlang 和 RabbitMQ 的版本關系必須吃透因為離線環(huán)境里可沒有“重裝一遍”的試錯成本。3.3 Docker Compose極簡部署如果只是為了開發(fā)測試或者不想污染宿主機環(huán)境Docker 是效率最高的方式。一條docker run就能起一個帶管理插件的服務docker run -d \ --name rabbitmq \ -p 5672:5672 \ -p 15672:15672 \ rabbitmq:3.12-management注意官方鏡像分為普通版和管理版rabbitmq:3.12默認不包含 management 插件要帶網頁管理界面必須使用帶-management后綴的鏡像或者rabbitmq:3.12-management-alpine這種輕量版。用 Docker Compose 管理更清晰適合團隊統(tǒng)一鏡像版本version: 3.8 services: rabbitmq: image: rabbitmq:3.12-management container_name: rabbitmq restart: always ports: - 5672:5672 - 15672:15672 - 1883:1883 environment: TZ: Asia/Shanghai volumes: - rabbitmq_data:/var/lib/rabbitmq volumes: rabbitmq_data:這里有幾個細節(jié)值得注意。第一端口映射要按需放行5672 是 AMQP 主端口15672 是管理頁面1883 是后面要講的 MQTT 插件端口。如果你后面打算啟用 MQTT最好在 compose 文件里提前把 1883 映射出去。第二容器數據卷一定要掛載。/var/lib/rabbitmq存放隊列數據、消息和持久化數據不掛載的話容器一刪數據全沒了。第三Docker 部署不等于“不會掛”。容器里的 RabbitMQ 同樣存在主機名解析、內存閾值這些問題只是被 Docker 的隔離環(huán)境隱藏掉了一部分。我見過很多生產事故排查到最后發(fā)現是容器內存限制導致 RabbitMQ 自動暫停了消費者這個后面講。3.4 啟動后必須做的自檢服務啟動后先別急著配插件做一遍基礎自檢能省很多事# 檢查服務狀態(tài) rabbitmqctl status # 查看節(jié)點名稱、端口監(jiān)聽情況 netstat -tlnp | grep 5672rabbitmqctl status能輸出 RabbitMQ 版本、節(jié)點名、內存使用、已安裝插件列表等信息。如果這條命令能正常返回說明 Erlang 節(jié)點已經起來了核心問題解決了 80%。如果命令超時或連接不上大概率是節(jié)點沒有正常啟動繼續(xù)查日志。Linux 下還可以用 systemd 檢查服務狀態(tài)systemctl status rabbitmq-server看到active (running)不代表節(jié)點一定健康因為 systemd 只管進程不管 Erlang 節(jié)點內部狀態(tài)。所以最靠譜的仍然是以rabbitmqctl status的輸出為準。4. 插件機制與management插件的啟用4.1 插件默認裝在哪、怎么查看RabbitMQ 的能力有一部分是內建的另一部分通過插件擴展。插件目錄通常在兩個位置一個是 RabbitMQ 安裝目錄下的plugins文件夾Linux 下一般在/usr/lib/rabbitmq/lib/rabbitmq_server-x.x.x/plugins另一個是用戶目錄下的~/.rabbitmq/plugins用于手動放置第三方插件。查看當前已有的插件列表rabbitmq-plugins list輸出結果里帶[E*]標記的表示這個插件已經啟用比如[E*] rabbitmq_management 3.12.x。沒啟用的是空白或者[ ]。列出插件之后你會發(fā)現RabbitMQ 內置插件其實非常多常用的包括rabbitmq_management網頁管理控制臺和 REST APIrabbitmq_mqttMQTT 協(xié)議接入適合物聯網設備rabbitmq_web_mqtt打通瀏覽器 WebSocket 和 MQTTrabbitmq_stomp/rabbitmq_web_stompSTOMP 協(xié)議適合前端實時推送rabbitmq_delayed_message_exchange延遲消息交換機插件需要額外下載rabbitmq_shovel、rabbitmq_federation跨節(jié)點消息同步和轉發(fā)。啟用插件的命令非常簡單rabbitmq-plugins enable rabbitmq_management執(zhí)行后如果輸出The following plugins have been configured to apply且下面包含rabbitmq_management就表示啟用成功。RabbitMQ 會把啟用的插件列表寫入enabled_plugins文件Linux 下一般在/etc/rabbitmq/enabled_plugins。如果該文件不存在或沒寫入權限啟用會失敗。4.2 啟用management插件并配置管理賬號rabbitmq_management插件是絕大多數人接觸 RabbitMQ 的第一站它提供兩個核心東西一個是瀏覽器訪問的 15672 端口頁面另一個是 RabbitMQ 的 HTTP REST API。很多自動化運維腳本就是直接調它的 15672 API 來創(chuàng)建隊列、查看連接的。默認情況下安裝完成后訪問http://localhost:15672用guest/guest登錄。這里有個安全策略RabbitMQ 默認只允許guest用戶從 localhost 訪問。如果你是在服務器上裝完然后從本地瀏覽器遠程訪問 15672會直接提示登錄失敗或者被拒絕。這是新手最常見的困惑之一。解決辦法不是去修改guest的權限而是顯式創(chuàng)建一個管理員賬號并分配權限# 創(chuàng)建用戶 rabbitmqctl add_user admin your_password # 將用戶設為管理員 rabbitmqctl set_user_tags admin administrator # 在 vhost / 下授予該用戶所有資源的配置、讀寫權限 rabbitmqctl set_permissions -p / admin .* .* .*這里的三組.*分別對應 configure、write、read 權限可以精細化控制。在管理頁面上也可以進入 Admin 菜單操作但命令行腳本化更利于重復執(zhí)行和交接。創(chuàng)建完管理員賬號后用admin重新登錄網頁可以看到 Overview、Connections、Channels、Exchanges、Queues 等菜單。在生產環(huán)境中我一般會讓開發(fā)人員只讀部分資源運維保留管理員權限避免有人誤刪交換機或隊列。RabbitMQ 的權限模型基于 vhost虛擬主機 資源 操作理解和利用好這套模型比一股腦用 guest 安全得多。5. 業(yè)務向插件實戰(zhàn)MQTT接入和延遲消息隊列5.1 用rabbitmq_mqtt把物聯網設備接進來管理插件只是基礎真正讓 RabbitMQ 在業(yè)務里發(fā)光的是各種協(xié)議插件。很多場景里后端服務用 AMQP 連接而移動端、硬件設備端又不想折騰 AMQP 這么重的協(xié)議這時候 MQTT 就派上用場了。啟用 MQTT 插件rabbitmq-plugins enable rabbitmq_mqtt rabbitmq_web_mqttrabbitmq_mqtt讓 RabbitMQ 可以接收 MQTT 客戶端的連接默認監(jiān)聽 1883 端口rabbitmq_web_mqtt則提供了瀏覽器 WebSocket 的接入能力。啟用之后給 MQTT 客戶端創(chuàng)建一個專用賬號rabbitmqctl add_user mqtt_user secret rabbitmqctl set_permissions -p / mqtt_user .* .* .*然后用 MQTTX 這類工具做連接測試。MQTTX 是現在比較常見的跨平臺 MQTT 測試工具新建連接時填入以下信息Name隨意標識用Hostmqtt://localhost或服務器 IPPort1883Username / Password第一步創(chuàng)建的用戶名和密碼Client ID每個連接必須唯一測試時可以寫成mqttx-test-001。連接成功后訂閱一個主題比如device/001/data然后用另一個客戶端往同一主題發(fā)布一條消息訂閱端能立即收到。這里要注意MQTT 的主題和 RabbitMQ 的隊列不是一回事。MQTT 主題通過內部的 topic exchange 轉發(fā)到隊列理解這個映射關系調試時才不會亂了方向。在實際項目中我還習慣在 RabbitMQ 管理頁面里觀察 MQTT 連接情況。如果看到連接數異常增長多半是設備沒有正確發(fā)送心跳或者客戶端 ID 沖突。MQTT 的客戶端 ID 是全局強制唯一的兩個設備用了同一個 ID其中一個會被踢下線。這個坑在嵌入式設備堆疊測試時特別容易踩。5.2 延遲消息插件外賣超時、訂單取消怎么實現業(yè)務里經常需要“過一段時間再執(zhí)行某個操作”比如用戶下單后 15 分鐘未支付就自動取消外賣超時未接單就提醒客服介入。這種需求RabbitMQ 內置功能里有一種簡單實現給隊列設置消息 TTL再配合死信交換機實現“延遲到達另一個隊列”的效果。但這種方式配置繁瑣時間精度也有限于是我更推薦使用延遲消息插件。rabbitmq_delayed_message_exchange插件不是 RabbitMQ 內置的需要單獨下載對應版本的.ez插件文件然后放置到插件目錄再啟用# 放置插件文件后刷新插件列表 rabbitmq-plugins list | grep delayed # 啟用延遲消息插件 rabbitmq-plugins enable rabbitmq_delayed_message_exchange啟用之后在管理頁面的 Exchange 類型里會多出一個x-delayed-message選項代碼里聲明交換機時要指定這個類型。在 Java/Spring Boot 項目中關鍵配置大概是Bean public CustomExchange delayedExchange() { MapString, Object args new HashMap(); args.put(x-delayed-type, direct); return new CustomExchange(delayed.exchange, x-delayed-message, true, false, args); } Bean public Binding binding() { return BindingBuilder.bind(delayedQueue()).to(delayedExchange()).with(delayed.routing.key).noargs(); }發(fā)送消息時通過消息頭指定延遲時間MessageProperties properties new MessageProperties(); properties.setDelay(15000); // 延遲15秒 Message message new Message(order cancel.getBytes(), properties); rabbitTemplate.send(delayed.exchange, delayed.routing.key, message);這里要注意延遲消息插件的內部實現是創(chuàng)建了一個x-delayed-message類型的交換機每條消息延遲到期后會進入綁定的隊列。如果消息量特別大或者延遲時間跨度特別長會占用額外的 Erlang 進程資源所以要評估好使用范圍。另外插件版本必須和 RabbitMQ 主版本匹配RabbitMQ 升級后插件不升級節(jié)點很可能啟動失敗。5.3 前端接入用web_mqtt連接瀏覽器還有一個常見需求前端頁面要實時接收后端推送的消息比如訂單狀態(tài)變化、站內信提醒。傳統(tǒng)方式是前端輪詢 HTTP 接口但既浪費資源也不夠實時。用rabbitmq_web_mqtt插件前端可以通過 WebSocket 直接訂閱 MQTT 主題。接入思路大概是后端服務用 AMQP 往某個交換機發(fā)布消息RabbitMQ 將消息路由到一個內部隊列前端用 MQTT.js 通過 WebSocket 連接到ws://rabbit服務器:15675前端訂閱指定的 MQTT 主題消息直接推到瀏覽器。這里 15675 就是rabbitmq_web_mqtt插件的 WebSocket 端口需要在防火墻上放行。前端連接時同樣需要用戶名密碼所以安全方面要設計好要么用獨立只讀賬號要么通過后端簽發(fā)短時憑證。直接把管理員賬號暴露在前端是極其危險的做法一旦信息泄露整個 vhost 的數據都暴露了。我見過有團隊為了圖省事前端寫死 guest/guest然后在公網服務器上跑 RabbitMQ最后整個消息集群被刷爆這個教訓希望大家別踩。6. 安裝和使用中最容易踩的坑按現象排查6.1 服務起不來端口、hosts、epmdRabbitMQ 啟動失敗的原因五花八門但有一個高頻問題在 Linux 上尤其常見epmd報錯或者節(jié)點無法啟動。Erlang 節(jié)點啟動時需要通過epmd進程注冊一個節(jié)點名比如rabbitmyhost。如果主機名對應的 IP 在/etc/hosts里解析不到節(jié)點啟動就會失敗?，F象是啟動日志里出現類似Error: unable to perform an operation on node rabbitmyhost但節(jié)點名可能確實是myhost這是因為hostname命令返回的機器名沒有在/etc/hosts里映射到127.0.0.1。解決辦法很簡單echo 127.0.0.1 $(hostname) /etc/hosts然后重啟rabbitmq-server。這個問題在云服務器上特別常見因為云主機的私有 IP 和hostname解析經常不一致。另一個高頻原因是端口被占用。RabbitMQ 默認監(jiān)聽 5672如果之前裝過其他軟件占用了這個端口或者之前啟動過一個 RabbitMQ 實例沒關掉新的節(jié)點會起不來。檢查方式netstat -tlnp | grep 5672 lsof -i:5672如果發(fā)現進程存在但不是預期的 RabbitMQ就需要停掉沖突進程或者修改 RabbitMQ 的端口配置。Windows 下服務起不來的原因更多集中在 Erlang 版本和運行庫缺失。有些精簡版系統(tǒng)的機器缺少 Visual C RedistributableErlang 安裝后運行直接崩潰。遇到這種情況先裝官方 Visual C 運行庫再重新啟動服務。6.2 網頁打不開guest用戶限制與網絡策略服務已經跑起來了rabbitmqctl status也正常但瀏覽器訪問 15672 就是打不開。排查鏈路一般是這樣第一步確認管理插件已啟用。執(zhí)行rabbitmq-plugins list看rabbitmq_management是否有[E*]標記。第二步確認端口在監(jiān)聽。Linux 下ss -tlnp | grep 15672如果這個命令沒輸出說明插件雖然啟用了但 Erlang 節(jié)點里的 web 應用沒起來。一般重啟一下服務就能解決systemctl restart rabbitmq-server第三步確認防火墻和云安全組放行了對 15672 的訪問。很多云服務器有一個“安全組”概念單純在系統(tǒng)里關掉防火墻還不夠需要去云控制臺放行端口。這個因素最容易忽略現象就是“本機可以訪問遠程死活連不上”。第四步用 guest 登錄被拒絕。要記住guest 用戶即使密碼正確也只能從本機訪問。想遠程使用管理頁面一定是用新建的管理員賬號否則會一直在登錄頁打轉。而且別指望改了 guest 密碼就能解決問題RabbitMQ 在配置層面默認限制了 guest 的本地訪問能力。6.3 消息不路由交換機和綁定關系的排查如果服務正常、頁面正常但消息發(fā)出去后消費者就是收不到通常問題出在路由環(huán)節(jié)。我之前排查過很多類似問題最后發(fā)現都是同一個套路生產者沒有用對交換機。排查信息最直接的工具有兩個# 查看所有交換機、隊列和綁定關系 rabbitmqctl list_exchanges rabbitmqctl list_queues rabbitmqctl list_bindingslist_exchanges會顯示默認交換機名稱是空字符串類型為 direct以及所有自定義交換機。list_bindings會顯示交換機到隊列的綁定關系和路由鍵。如果發(fā)現綁定關系是空的說明生產者發(fā)到交換機但交換機沒有綁定到隊列消息自然沒地方去。還有一類常見場景是隊列名字存在多個消費者時消息被平均分配。RabbitMQ 默認按輪詢方式把消息發(fā)給消費者每個消費者拿到的消息數量大致均衡。如果某個消費者處理特別快、另一個特別慢你會發(fā)現快的那個一直在消費慢的那個堆積嚴重。這不是故障是 RabbitMQ 默認行為。如果希望“同一時間一條消息只被一個消費者處理”可以調整 Qos prefetch 參數如果希望廣播給所有消費者就用 fanout 交換機。這個設計差異在工作分配和發(fā)布訂閱場景中特別重要。6.4 關于內網離線環(huán)境再補充兩句前面提到歐拉系統(tǒng)內網安裝很多人還會問“內網沒法下載插件怎么辦”。其實思路和安裝包一樣提前在允許聯網的環(huán)境下載好對應版本的.ez插件文件傳到內網后放到插件目錄執(zhí)行rabbitmq-plugins enable即可。關鍵在于版本號必須完全一致否則 Erlang 加載插件時會因為模塊版本不匹配而報錯。另外離線環(huán)境經常遇到系統(tǒng)依賴缺失。比如缺少socat、logrotate這些工具RabbitMQ 官方安裝腳本在安裝時會提示依賴不滿足但它不一定阻止安裝。我建議離線環(huán)境安裝時記錄所有缺少的依賴一次性下載好帶進去避免半路卡住。通用 tar.gz 包對系統(tǒng)依賴的要求相對低一些更適合離線場景。還有一點很實際內網環(huán)境通常沒有域名解析如果 RabbitMQ 節(jié)點名稱里帶了主機名要確保局域網里所有節(jié)點都能通過/etc/hosts互相解析。RabbitMQ 集群部署時尤其依賴這一點很多跨節(jié)點通信失敗最后都是這個原因。7. 安裝完成后的日常維護與使用建議裝好 RabbitMQ 只是開始生產環(huán)境里后續(xù)的維護才真正考驗功底。先說權限和責任邊界。給團隊的賬號要按角色分配開發(fā)人員給讀寫權限運維保留管理員權限。每個業(yè)務線最好建獨立的 vhost業(yè)務之間用 vhost 隔離。我以前維護過一個集群多個團隊共用一個 vhost某個團隊誤刪了交換機其他團隊全部受影響事后復盤就是 vhost 沒分清楚。關于消息堆積和內存閾值也要提前了解。RabbitMQ 默認在內存使用率達到 40% 時會進入 flow control暫停接收新的消息磁盤空間低于配置閾值時會主動阻塞生產者。這個機制是保護性的但第一次遇到的人會以為是系統(tǒng)卡死了。所以部署的時候內存閾值和磁盤限制要根據機器規(guī)格提前規(guī)劃否則業(yè)務高峰期可能突然“停擺”。最后提一下消費端的冪等設計。RabbitMQ 的消息投遞是 at-least-once 語義消費者可能收到重復消息。這不是安裝配置能解決的事而是在消費端通過唯一業(yè)務鍵做去重。很多項目上線后才追著這個問題補方案不如一開始就定好約定生產者發(fā)消息時帶上業(yè)務主鍵消費者處理前先查一下是否已處理過。這樣即使消息重投也不會造成重復下單、重復扣款這類嚴重問題。8. 一點裝機后的個人體會裝了這么多次 RabbitMQ我的體會是安裝本身不難難的是把版本匹配、插件啟用、用戶權限、網絡策略這些細節(jié)串起來。每次在群里看到有人問“RabbitMQ 裝好了為什么連不上”十有八九是卡在了 guest 用戶或者防火墻。所以這次寫文章我把這些零散的經驗集中整理了一遍希望你能少走我走過的彎路。如果只是在本地學習測試我建議直接用 Docker 拉起一個帶 management 的鏡像在一個隔離環(huán)境里把所有插件都試一遍MQTT、延遲消息、WebSocket 全部開了逐個驗證。等熟悉了插件機制和排查思路再上生產環(huán)境去手動部署這樣心態(tài)會穩(wěn)很多踩坑成本也最低。如果后續(xù)你打算做集群或者接入高并發(fā)場景到時候再深入討論也不遲。