1. 先把RabbitMQ到底是个什么讲清楚

做后端开发这几年，RabbitMQ几乎成了我简历里跑不掉的一项技能。不管是刚入行的新人，还是写过几年业务的同学，只要聊到消息中间件，RabbitMQ总是绕不开的那个名字。热搜词里各种“rabbitmq安装”“rabbitmq启动失败”“rabbitmq面试题”挂了一整排，说明大家既不缺入门的热情，也缺一份能少走弯路的实操参考。

我个人的理解，RabbitMQ本质上就是一个消息路由器。你的服务A把一条消息丢给它，服务B有空了再来取，两边不需要同时在线，也不需要知道对方IP和端口，耦合就断开了。它最核心的三个价值是：异步解耦、削峰填谷、数据分发。

举个最直白的例子。用户下单这个动作，如果同步去扣库存、发短信、送积分、更新统计报表，一个接口可能就要等好几个下游响应，赶上大促直接拖垮主流程。有了RabbitMQ，订单服务只需要把“下单成功”这个事件丢到消息队列里，后面那些操作谁有空谁去做，用户那边毫秒级返回，体感完全不一样。

我最早接触RabbitMQ的时候，最困惑的就是它和Kafka到底怎么选。这里直接给结论：如果你的场景是业务消息、任务分发、需要灵活的路由规则、需要消息确认机制，RabbitMQ很合适；如果你的场景是海量日志采集、流量数据管道、追求超高吞吐，Kafka更合适。RabbitMQ胜在功能丰富、路由灵活、对开发者友好，这也是它长期占据中小团队首选位置的原因。

这篇文章我会按“从零部署到实际使用”的顺序，把Windows和Linux两条安装路线、管理后台的玩法、Python客户端的实操代码、以及我踩过的那些坑都串起来。不管你是想在公司搭建一套环境，还是为了面试突击消息队列知识，跟着走一遍应该都能有个完整的收获。

2. Windows安装RabbitMQ的正确姿势与典型翻车点

搜索“rabbitmq安装windows”的人特别多，我猜很多都是本地开发环境需要。Windows下装RabbitMQ，理论上是傻瓜式操作，但实际装的时候总能遇到几个匪夷所思的问题，我用一整节专门写这个。

2.1 先装Erlang/OTP，版本对应关系别搞错

RabbitMQ是用Erlang写的，所以第一步永远是装Erlang运行时。Windows下的安装包在Erlang官网下载，注意选中Windows 64位版本。

最容易翻车的地方是版本对应关系。RabbitMQ和Erlang的版本是有官方对应表的，比如RabbitMQ 3.12.x要求Erlang 26.x，RabbitMQ 4.1.x要求Erlang 27.x。如果你装了RabbitMQ 4.1却配了个Erlang 25，服务根本起不来，或者起来后管理后台各种报错。

我把目前常见的对应关系整理成了表格：

安装Erlang的时候没什么特别要求，一路Next即可。但装完必须手动配置环境变量，把ERLANG_HOME指向Erlang安装目录，然后把%ERLANG_HOME%\bin加到Path里。这一步很多人会漏，后果是RabbitMQ服务启动时找不到Erlang运行时，直接报错退出。

2.2 RabbitMQ安装与内置插件启用

Erlang搞定后，去RabbitMQ官网下载对应的Windows安装包。装的时候注意路径里不要出现空格和中文，我建议直接装在C:\RabbitMQ这种简洁路径下，避免后续踩到各种奇怪的坑。

安装完成后，以管理员身份打开PowerShell，进入RabbitMQ的sbin目录，比如C:\RabbitMQ\rabbitmq_server-3.12.10\sbin。先执行：

rabbitmq-service.bat install rabbitmq-service.bat start

如果一切正常，服务管理器里能看到RabbitMQ服务处于“正在运行”状态。

紧接着做两件非常关键的事。第一件，启用管理插件：

rabbitmq-plugins.bat enable rabbitmq_management

这个插件不启用，你就只能在命令行里操作，无法通过网页管理队列和交换机，对初学者极不友好。它是基于Web的管理控制台，默认端口是15672，浏览器访问http://localhost:15672，用默认账号guest/guest登录（仅限localhost）。

第二件事，把rabbitmqctl加入PATH环境变量。把sbin目录完整追加到系统Path里，这样以后随时可以用rabbitmqctl status查看服务状态，不必每次cd到sbin目录。

2.3 典型问题快查：启动失败、端口占用、命令行不识别

Windows下的RabbitMQ安装问题，90%集中在下面几个场景，我把排查顺序写出来：

服务启动失败，查看日志路径。日志在%APPDATA%\RabbitMQ\log\目录下，文件名类似rabbit@你的主机名.log。打开看最后几十行，基本能定位问题。常见原因是Erlang版本不匹配、主机名解析异常、或配置文件语法错误。

端口被占用。RabbitMQ默认使用5672，如果你本机装过其他消息中间件或某进程占用了这个端口，服务会起不来。排查命令：

netstat -ano | findstr "5672"

找到占用进程的PID后，去任务管理器里定位并结束它，或者给RabbitMQ换端口。换端口的方法我在后面第五部分专门讲。

命令行执行rabbitmqctl报“不是内部或外部命令”。这个纯粹是环境变量没配好，把sbin目录加到系统Path后重新开一个终端窗口就行，不用重启电脑。

提示：Windows下如果你用的是PowerShell，执行rabbitmq-plugins可能遇到“无法加载文件...因为在此系统上禁止运行脚本”的报错。这是PowerShell执行策略问题，用管理员身份执行Set-ExecutionPolicy RemoteSigned，然后选Y即可解决。

3. Linux下安装部署RabbitMQ 4.1.x的完整流程

生产环境几乎清一色是Linux，热搜里的“rabbitmq 4.1.x 下载 安装部署 linux”也不是没道理。我以CentOS 7/8和Ubuntu 20.04/22.04为例，把两种最常见的方式都写一下。

3.1 CentOS/RHEL系安装步骤

CentOS上我通常用官方提供的rpm仓库方式安装，这种方式的好处是后续升级方便，依赖关系自动处理。

先安装基础依赖并配置仓库：

# 安装基础工具 sudo yum install -y epel-release sudo yum install -y wget # 添加Erlang仓库（根据你的CentOS版本选择） # CentOS 7: wget https://packages.erlang-solutions.com/erlang-rpm/centos/7/x86_64/esl-erlang-27.0-1.x86_64.rpm # CentOS 8/Stream: wget https://packages.erlang-solutions.com/erlang-rpm/centos/8/x86_64/esl-erlang-27.0-1.x86_64.rpm sudo rpm -Uvh esl-erlang-27.0-1.x86_64.rpm

Erlang装完后，安装RabbitMQ。从RabbitMQ官网下载对应系统的rpm包：

# 下载（以4.1.x为例，实际版本号请以官网为准） wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v4.1.0/rabbitmq-server-4.1.0-1.el8.noarch.rpm sudo rpm -Uvh rabbitmq-server-4.1.0-1.el8.noarch.rpm

这里有个经验之谈：下载rpm包时不要只看文件大小，一定要确认el后面跟的数字和系统版本匹配。el7的包装到el8上，大概率会有依赖冲突或者运行异常。

安装完成后，启动服务并设置开机自启：

sudo systemctl start rabbitmq-server sudo systemctl enable rabbitmq-server sudo systemctl status rabbitmq-server

启动成功后再启用管理插件：

sudo rabbitmq-plugins enable rabbitmq_management

如果是CentOS系统且有firewalld防火墙在运行，记得放行端口：

sudo firewall-cmd --permanent --add-port=5672/tcp sudo firewall-cmd --permanent --add-port=15672/tcp sudo firewall-cmd --reload

3.2 Ubuntu/Debian系安装步骤

Ubuntu上用apt装更容易。先用官方提供的脚本添加RabbitMQ签名密钥和仓库：

# 安装基础工具 sudo apt update sudo apt install -y curl gnupg apt-transport-https # 添加RabbitMQ官方签名密钥 curl -fsSL https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc | sudo gpg --dearmor --yes -o /usr/share/keyrings/rabbitmq-archive-keyring.gpg # 添加仓库（以Ubuntu 22.04 Jammy为例） echo "deb [signed-by=/usr/share/keyrings/rabbitmq-archive-keyring.gpg] https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-erlang/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/rabbitmq-erlang.list echo "deb [signed-by=/usr/share/keyrings/rabbitmq-archive-keyring.gpg] https://ppa.launchpadcontent.net/rabbitmq/rabbitmq-server/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/rabbitmq-server.list

然后更新并安装：

sudo apt update sudo apt install -y rabbitmq-server

Ubuntu下安装时要注意，仓库源里的Erlang版本可能比较旧，如果启动报错可以手动安装更新的Erlang版本，但一般官方源维护得不错，直接装就能用。

启动与自启：

sudo systemctl start rabbitmq-server sudo systemctl enable rabbitmq-server sudo rabbitmq-plugins enable rabbitmq_management

Ubuntu的ufw防火墙如果开着，同样需要放行端口：

sudo ufw allow 5672/tcp sudo ufw allow 15672/tcp

3.3 服务管理正确姿势：systemctl还是rabbitmqctl？

Linux下管理RabbitMQ服务，统一优先用systemctl操作服务本身，比如start/stop/restart/status，它是系统级的进程管理。rabbitmqctl则用于操作RabbitMQ内部的对象和状态，比如查看队列、创建用户、查看集群状态。

不要混用两个工具去做同一件事，比如用rabbitmqctl stop去关服务，容易导致systemd管理的服务状态紊乱，下次启动可能出现“节点未完全关闭”的提示。如果你确实用了rabbitmqctl stop意外关掉了进程，最稳妥的方式是执行sudo systemctl restart rabbitmq-server，让它重新接管。

服务起不来时，第一件事永远是看日志：

sudo tail -n 100 /var/log/rabbitmq/rabbit@$HOSTNAME.log

日志文件会随着运行时间变大，排查问题时用tail看最近的记录即可，不需要打开整个文件。

注意：Linux下RabbitMQ会在/var/lib/rabbitmq/mnesia/目录存放数据库文件。如果硬盘满了，服务会拒绝启动。日常运维一定要监控这块磁盘空间，别等到全站排队才想起来。

4. 核心概念与实际使用：从交换机到队列的完整链路

装好环境后，接下来就是理解RabbitMQ的工作模型。很多人面试挂在“消息怎么从生产者到消费者”这个问题上，其实就是没搞懂交换机、队列、绑定这三者的关系。

4.1 五个核心概念用大白话解释

• 生产者（Producer）：发消息的一方，就是你业务代码里的某个函数。
• 消费者（Consumer）：收消息的一方，订阅队列并处理消息。
• 队列（Queue）：消息的存储容器，本质是一个有序缓冲器。
• 交换机（Exchange）：消息分发中心，生产者不直接发消息到队列，而是发给交换机，由交换机根据规则路由到对应队列。
• 绑定（Binding）：交换机和队列之间的关联规则，规定哪些消息从交换机进到哪个队列。

用生活类比：交换机像快递分拣中心，队列是各个快递柜，绑定规则就是贴在包裹上的标签和分拣规则之间的对应关系。你寄快递时只需要把包裹交给分拣中心（发消息到交换机），不用管哪个快递柜会接收它。

这里有个初学者最常见的误区：以为生产者直接把消息塞到队列里。RabbitMQ里99%的场景，生产者都是把消息发给交换机，队列只是消费者订阅的目标。理解了这一点，后面的路由逻辑就好懂了。

4.2 四种交换机类型与选择逻辑

RabbitMQ内置四种交换机类型，各有各的适用场景：

我的建议是：初学阶段先把Direct和Fanout用熟，再碰Topic。很多业务只需要一个direct交换机配合不同routing key，就能覆盖大部分场景。Fanout适合“一个事件多个模块都需要响应”的广播需求。Topic功能最强大，但配置复杂度也跟着上来，用得不好容易把自己绕晕。

4.3 Python客户端实操：pika从入门到顺手

Python生态里操作RabbitMQ，最主流的库是pika。安装很简单：

pip install pika

先写一个最基础的生产者：

import pika # 建立连接 connection = pika.BlockingConnection( pika.ConnectionParameters(host='localhost', port=5672) ) channel = connection.channel() # 声明队列（如果不存在则创建，存在则复用） channel.queue_declare(queue='hello') # 发消息 channel.basic_publish( exchange='', routing_key='hello', body=b'Hello RabbitMQ!' ) print("[x] 消息已发送") # 关闭连接 connection.close()

注意一个细节：这里exchange=''表示使用默认交换机，此时routing_key直接对应队列名。这是最简单的情况，但实际项目中我更推荐显式创建交换机，保持路由清晰。

再看消费者：

import pika connection = pika.BlockingConnection( pika.ConnectionParameters(host='localhost') ) channel = connection.channel() channel.queue_declare(queue='hello') def callback(ch, method, properties, body): print(f"[x] 收到消息: {body.decode()}") # 手动确认消息已处理 ch.basic_ack(delivery_tag=method.delivery_tag) # 关闭自动确认，改为手动确认 channel.basic_consume( queue='hello', on_message_callback=callback, auto_ack=False ) print('[*] 等待消息，Ctrl+C退出') channel.start_consuming()

这里有个关键注意点：auto_ack=False。如果消费者处理消息时程序崩溃了，没有返回确认，RabbitMQ会把这条消息重新投递给其他消费者，保证不丢消息。如果是auto_ack=True，消息一旦投递就被标记为已确认，消费者可能还没处理完就挂了，消息就丢了。

实际开发中，我强烈建议永远手动确认。哪怕你的业务对数据丢失容忍度很高，也养成这个习惯，因为RabbitMQ的at-least-once投递语义配合手动确认，才算是把“不丢消息”这个底线兜住。

4.4 真实一点的分布式任务模型

啥时候用多个队列？举个订单过期通知的例子：用户下单后30分钟未支付，需要发短信提醒。这个场景不需要消息立刻被处理，但需要定时扫描订单状态。

架构思路：

import pika import json import time # 生产者：下单时把订单ID发到延迟队列 connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() # 声明死信交换机（专门处理过期消息） channel.exchange_declare(exchange='dlx_exchange', exchange_type='direct') channel.queue_declare(queue='order_timeout_queue', arguments={ 'x-message-ttl': 1800000, # 30分钟过期 'x-dead-letter-exchange': 'dlx_exchange', 'x-dead-letter-routing-key': 'order_timeout' }) channel.queue_bind( queue='order_timeout_queue', exchange='dlx_exchange', routing_key='order_timeout' ) # 发送订单ID order_data = json.dumps({'order_id': '123456'}) channel.basic_publish( exchange='', routing_key='order_timeout_queue', body=order_data ) print("[x] 订单超时任务已创建") connection.close()

然后消费者监听死信交换机上的消息：

import pika connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() channel.exchange_declare(exchange='dlx_exchange', exchange_type='direct') result = channel.queue_declare(queue='order_timeout_handler') channel.queue_bind( queue='order_timeout_handler', exchange='dlx_exchange', routing_key='order_timeout' ) def handle_timeout(ch, method, properties, body): print(f"处理超时订单: {body.decode()}") # 这里调用短信接口、关闭订单等逻辑 ch.basic_ack(delivery_tag=method.delivery_tag) channel.basic_consume( queue='order_timeout_handler', on_message_callback=handle_timeout, auto_ack=False ) print('[*] 监听超时订单...') channel.start_consuming()

这个模型其实就是利用了RabbitMQ的TTL（消息存活时间）和死信队列机制。消息在order_timeout_queue里躺30分钟，到期后自动转入dlx_exchange，再由对应消费者处理。我当时第一次跑通这个流程的时候，对RabbitMQ的好感直线上升——这种“定时但不占线程”的机制，用传统轮询要写一堆定时任务，用消息中间件就优雅很多。

4.5 面试题里那些高频概念，顺手梳理一下

结合热搜里的“rabbitmq面试题”，我把几个常被问到的问题跟我自己的理解写出来，应付技术面足够了：

Q1：RabbitMQ怎么保证消息不丢失？三个环节分别处理：生产者端开启publisher confirms，确认消息到达交换机；交换机到队列开启mandatory或备份交换机，防止路由失败；消费者端用手动确认，处理完再ack。三个环节都配齐了，基本能做到不丢。

Q2：多个消费者同时订阅一个队列，消息怎么分配？默认是轮询分发，RabbitMQ按顺序把消息均匀分给每个消费者。消费耗时差异大的时候可以用basic_qos(prefetch_count=1)，设置消费者每次只取一条，处理完再取下一条，避免某个消费者积压。

Q3：消息积压了怎么办？先扩容消费者实例，配合prefetch限制防止盲目拉取。如果队列实在顶不住，可以考虑临时增加队列数量，用一致性哈希或按业务键分流。注意：RabbitMQ不是设计来扛海量消息的，长期积压说明你的业务量级可能该考虑别的方案了。

5. 服务管理与端口修改实战

“rabbitmq启动失败”“win下 rabbitmq服务 修改端口”这两个热词挂得很高，说明大家日常操作里确实经常被这类问题卡住。这一节重点讲两块：如何正确改端口、如何排查启动失败，都是可以直接照做的。

5.1 修改RabbitMQ默认端口5672

默认端口5672很容易被占用，尤其是开发机装了一堆中间件的情况下。修改端口的方法很直接，编辑RabbitMQ的配置文件。

Linux下配置文件位置：

sudo vim /etc/rabbitmq/rabbitmq.conf

如果文件不存在，自己创建即可。写入：

listeners.tcp.default = 5673

Windows下配置文件在RabbitMQ安装目录的etc\rabbitmq\rabbitmq.conf，同样写入这行配置。没有这个文件就新建一个，注意文件名必须精准叫rabbitmq.conf。

修改完重启服务：

# Linux sudo systemctl restart rabbitmq-server # Windows rabbitmq-service.bat stop rabbitmq-service.bat start

重启后验证端口是否生效：

netstat -tlnp | grep 5673

这里有个细节：修改端口后，客户端连接参数也要同步改。Python里写pika.ConnectionParameters(host='localhost', port=5673)，别只改服务端忘了客户端。

管理后台15672端口的修改方法同理：

management.tcp.port = 15673

5.2 启动失败的排查思路：从日志到配置逐层定位

服务起不来，最怕瞎猜。我总结了一套固定排查顺序，照着做基本能定位：

第一步，看系统日志和RabbitMQ日志。日志永远是最直接的信息来源。Linux下看/var/log/rabbitmq/下的.log文件，Windows下看%APPDATA%\RabbitMQ\log\。重点关注最后50行，出错原因基本都会写出来。

第二步，检查Erlang版本兼容性。用erl -version看当前Erlang版本，然后跟官网的RabbitMQ版本对应表核对。很多启动失败的根因就是版本太老或太新。

第三步，检查端口占用和hostname。先确认5672没被占用；再确认/etc/hostname里的主机名能正常解析，可以用hostname -f看看。RabbitMQ对主机名非常敏感，如果主机名解析失败，节点启动会直接失败。

第四步，检查配置文件语法。rabbitmq.conf用的是类INI格式，不能用Tab缩进，引号分号别乱写。配完可以用rabbitmqctl eval做语法检查，或者直接启动看有没有报错。

提示：Windows下如果重启后服务还是“已停止”状态，用管理员身份打开“事件查看器”，在Windows日志->应用程序里搜索RabbitMQ相关记录。Windows服务层面的错误，事件查看器里通常会给出比命令行更详细的信息。

5.3 内存与磁盘告警阈值调整

RabbitMQ默认有几个阈值，新手上路时最常见的是“发消息发不进去，连接被断掉”，一查日志发现resource-alarm。默认情况下，RabbitMQ在内存使用超过40%时就会触发告警，阻塞所有生产者连接。

这个阈值可以调，但不要照搬网上的“调到80%”，要结合你的机器内存和消息重要程度来定。如果RabbitMQ和业务服务部署在同一台机器上，建议保持默认甚至调低；如果是独立机器，可以适当放宽：

vm_memory_high_watermark.relative = 0.6 disk_free_limit.relative = 1.0

vm_memory_high_watermark.relative = 0.6表示内存使用达到物理内存的60%时开始阻塞。disk_free_limit.relative = 1.0表示磁盘剩余空间低于总空间的1%时阻塞写入。

调阈值只是缓解，真正该做的是优化消费者速度、清理无用队列、扩大机器规格。

5.4 用户权限与虚拟主机配置

安装完成后默认只有guest/guest账号，这个账号默认只能在localhost连接，没办法远程用。生产环境必须创建自己的用户和虚拟主机。

创建命令如下：

# 创建虚拟主机 rabbitmqctl add_vhost /myvhost # 创建用户 rabbitmqctl add_user myuser mypassword123 # 授权用户能访问指定虚拟主机（配置、写、读三种权限） rabbitmqctl set_permissions -p /myvhost myuser ".*" ".*" ".*"

三个".*"分别对应配置权限、写权限、读权限的正则表达式。生产环境建议按最小权限原则收紧，比如只给某个用户读权限：

rabbitmqctl set_permissions -p /myvhost readonly_user "" "" ".*"

这样客户端的连接配置也要跟着改：

credentials = pika.PlainCredentials('myuser', 'mypassword123') connection = pika.BlockingConnection( pika.ConnectionParameters( host='your-server-ip', port=5672, virtual_host='/myvhost', credentials=credentials ) )

我刚开始用的时候忽略虚拟主机这层概念，所有队列都堆在默认的/下，后来项目一多，队列命名冲突就到手上了。虚拟主机本质上就是RabbitMQ内部的环境隔离机制，不同团队、不同环境用不同的vhost，互不干扰，这是生产环境的标配做法。

6. 运维监控与常见问题速查

文章最后这块，我把日常运维中一定会用到的一些操作和问题排查方法做个集中总结。跟前文提到的启动排查不同，这里聚焦的是运行期间的维护，覆盖率更高，而且很多是我亲手踩出来的经验。

6.1 常用命令速查表

rabbitmqctl list_queues是平时用得最多的命令。如果messages_ready长期暴涨，说明消费者速度跟不上；如果messages_unacknowledged很高，说明消费者拿了消息但处理不完，可能要查业务代码是不是有阻塞。

6.2 队列积压的定位思路

消息积压是运维里最常遇到的事。排查顺序是：先看队列消息数，再确认消费者是否在线，最后看消费逻辑是否有瓶颈。

rabbitmqctl list_queues name messages consumers

如果consumers是0，说明消费者挂了或者没连上，先恢复消费端。如果消费者在线但积压严重，大概率是消费逻辑太慢，优先考虑加消费者实例或用prefetch_count调优。

6.3 连接数被打满怎么办

RabbitMQ默认连接数没有硬性限制，但每建一条TCP连接都要占用文件描述符和内存。如果你的应用是高频创建短连接，很容易把服务拖垮。这是初学者最容易忽略的问题。

解决方案：客户端复用连接。Python的pika.BlockingConnection每次用完close()后，下一次又要重新握手、鉴权、建TCP连接，费时费力。正确做法是做成全局单例，发送消息时只创建channel，不频繁开连接。

如果连接数实在太多，可以在rabbitmq.conf里限制：

channel_max = 100

但这是治标不治本，连接数和并发量的设计还是要从应用层面优化。

6.4 常见错误的排查惯用手法

报错NOT_ALLOWED - access to vhost '/' refused：用户没有访问该虚拟主机的权限，用rabbitmqctl set_permissions重新授权。

报错connection refused：端口不通，检查服务进程、防火墙、云安全组。

报错channel error: reply-code=404, reply-text=NOT_FOUND：交换机或队列不存在，检查生产者和消费者的声明是否一致，很可能名字拼写不一致或者顺序问题。

管理后台登录不进去：guest账号只在localhost能登录，远程访问必须创建新账号并授权。

最后分享几点个人体会

RabbitMQ这东西，装起来不难，用起来不难，但真正用对，需要一段时间的思考和踩坑。我在实际维护中感受最深的是，很多问题的根源不在RabbitMQ本身，而在使用方式——连接不复用、确认机制配错、路由设计混乱、队列声明不一致，这些才是真正可能把系统搞挂的隐患。

如果你刚开始接触，建议先在本地跑通“生产者-交换机-队列-消费者”的完整链路，用管理后台去看消息流转过程，再去尝试TTL、死信队列、延时队列这些进阶玩法。把路由模型吃透了，后面不管是迁移到集群还是换Kafka，思维切换都会很顺畅。

最后还有一个小技巧：给队列和交换机起名字的时候，一定要带环境标识。比如order_dev_queue、order_prod_queue，相信我，等你同时在三个环境上调试的时候，你会感谢这个习惯的。