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