做后端的朋友应该都有这种体会：微服务拆得越细，服务之间的调用链就越长，任何一个环节出问题都可能把整个链路拖垮。这时候消息队列就派上用场了——削峰填谷、异步解耦、流量控制，全靠它。而在所有消息中间件里，RabbitMQ 绝对算是最经典、也最容易上手的一个。
很多新手看 RabbitMQ 的文档，第一眼就被“七种工作模式”这个概念吓住了，觉得好像要背七套不同的玩法。其实换个角度想，它没有这么复杂——七种模式本质上就是交换机（Exchange）和队列（Queue）不同组合方式。有人可能会问：为什么需要七种模式？就不能一套通吃吗？答案是不行，因为实际业务里消息投递的诉求差异太大了。有的场景只需要点对点发一条消息，有的场景想让所有服务都收到通知，还有的场景要按路由规则精准匹配。这七种模式，正好覆盖了从简单到复杂的各种投递需求。
这篇文章会把七种工作模式逐一拆开揉碎，讲清楚每一种模式解决什么问题、底层原理是什么、代码怎么写、实战里有哪些坑。还会把 RabbitMQ 的安装部署、常见启动失败排查、端口修改这些实操内容一并整理出来。不管你是刚接触消息队列的新手，还是已经在项目里接了 RabbitMQ 但只知道一种写法的老手，这篇文章都能帮你把整张地图拼完整。
1. 七种模式背后的核心武器：交换机与绑定关系
1.1 为什么搞懂交换机就搞懂了一半
先说一句容易让新手懵的话：在 RabbitMQ 里，生产者不会直接把消息扔进队列。这个消息会被先送到交换机，由交换机根据规则决定把它投递给哪个队列、投递给几个队列。
你可以把交换机想象成一个快递分拣中心。快递员（生产者）把包裹（消息）送到分拣中心，分拣中心看面单上的地址（routing key），然后决定包裹是交给某个快递网点（某个队列），还是复印几份分别交给多个网点（多个队列），或者直接把包裹撒给所有网点（广播）。
搞清楚这个流程，七种模式里的五种就已经通了。剩下的只是换不同的交换机类型、不同的路由规则而已。
RabbitMQ 一共有四种交换机类型：
| 交换机类型 | 路由规则 | 典型场景 |
|---|---|---|
| Direct Exchange | 精确匹配 routing key | 按级别分发日志、按命令字路由 |
| Fanout Exchange | 广播，忽略 routing key | 全局通知、配置变更广播 |
| Topic Exchange | 通配符匹配 routing key | 按主题订阅、多条件过滤 |
| Headers Exchange | 按消息头匹配 | 极少用，一般面试不会深挖 |
1.2 绑定关系才是灵魂
交换机和队列之间不是自动关联的，必须手动建立一条“绑定关系”（Binding）。绑定的时候可以指定一个 binding key，这个 key 就是交换机做路由判断的依据。
举个例子：
- Direct 交换机绑定了队列 A，binding key 是
error，那么只有 routing key 为error的消息才会进队列 A。 - Fanout 交换机绑定了一堆队列，消息进来后根本不管 routing key，所有绑定的队列各拿一份。
- Topic 交换机绑定队列 B，binding key 是
log.*，那么 routing key 为log.info、log.error的消息都能进队列 B，但user.login进不来。
一句话总结：交换机类型决定“怎么分发”，routing key 和 binding key 决定“分发给谁”。七种工作模式里，从第三种开始，每一种的本质都是在换交换机的玩法。
2. 七种工作模式逐个拆解
2.1 简单模式（Simple Queue）：最基础的点对点
这是 RabbitMQ 最朴素的一种用法：一个生产者，一个队列，一个消费者。生产者把消息发到队列，消费者从队列里取消息，消息被取走后队列里就没有了。
它的工作流程非常简单：
// 生产者：声明一个名为 hello 的队列，然后直接发消息 Channel channel = connection.createChannel(); channel.queueDeclare("hello", false, false, false, null); String message = "Hello RabbitMQ!"; channel.basicPublish("", "hello", null, message.getBytes());注意这里basicPublish的交换机名称是空字符串""，RabbitMQ 会使用默认交换机，直接把消息路由到 routing key（这里就是队列名 hello）对应的队列。所以简单模式本质上还是走了交换机，只是用了默认的那个。
消费者这边要做得稍微多一点：
Channel channel = connection.createChannel(); channel.queueDeclare("hello", false, false, false, null); DeliverCallback deliverCallback = (consumerTag, delivery) -> { String message = new String(delivery.getBody(), "UTF-8"); System.out.println("收到消息: " + message); }; channel.basicConsume("hello", true, deliverCallback, consumerTag -> {});第二个参数传true表示自动确认，也就是消费者一收到消息就自动回执给服务端，服务端就把这条消息删掉了。
适用场景：简单通知、测试环境验证、一次性任务。实际生产里这种模式用得很少，因为它的处理能力有限，但它是理解所有其他模式的基础。
2.2 工作队列模式（Work Queue）：能者多劳的竞争消费
如果生产消息的速度很快，一个消费者处理不过来怎么办？工作队列模式就是为解决这个问题设计的：还是同一个队列，但多个消费者同时监听，每条消息只会被其中一个消费者消费。
这里就涉及一个非常关键的参数：basicQos。
// 设置预取计数为1，让消费者一次只取一条消息，处理完并确认后才取下一条 channel.basicQos(1);如果不设置这个参数，RabbitMQ 会把队列里的消息按顺序分给各个消费者，你一条我一条，不管谁快谁慢，结果就是快的消费者干完了还得等，慢的消费者积压了一堆。设置了basicQos(1)之后，RabbitMQ 会变成“能者多劳”模式：谁处理完谁就来取，速度快的自然拿得多。
配套的是手动确认。消费者处理完业务后必须显式调用basicAck：
DeliverCallback deliverCallback = (consumerTag, delivery) -> { String message = new String(delivery.getBody(), "UTF-8"); try { System.out.println("开始处理: " + message); Thread.sleep(2000); // 模拟耗时任务 channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); } catch (Exception e) { channel.basicNack(delivery.getEnvelope().getDeliveryTag(), false, true); } }; // autoAck 必须传 false，由业务代码自己确认 channel.basicConsume("task_queue", false, deliverCallback, consumerTag -> {});为什么要手动确认？因为自动确认是消费者一拿到消息就回执，万一消费者在处理过程中宕机或者抛异常了，这条消息就从队列里丢了。改成手动确认后，如果处理失败还可以basicNack把消息扔回队列重试。
适用场景：任务分发、耗时操作批量处理。比如一个后台系统需要批量发送邮件、生成报表、处理图片缩略图，都可以把任务扔进队列，然后起多个消费者进程同时消费。
2.3 发布/订阅模式（Publish/Subscribe）：一播全收的广播
前面两种模式，一条消息只会被一个消费者处理。但实际业务里经常有一种需求：一条消息发出来，所有关心它的服务都要收到。典型场景是“配置变更通知”——配置中心改了配置，所有微服务都要感知到。
这种场景用发布/订阅模式，交换机类型是fanout。
// 生产者：声明一个 fanout 交换机，消息发过去后广播给所有绑定队列 Channel channel = connection.createChannel(); channel.exchangeDeclare("logs", "fanout"); String message = "配置已更新: 限流阈值 1000"; channel.basicPublish("logs", "", null, message.getBytes());消费者这边，要声明临时队列并绑定到交换机：
Channel channel = connection.createChannel(); channel.exchangeDeclare("logs", "fanout"); // queueDeclare() 不传参数，RabbitMQ 会生成一个随机名字的临时队列 // 连接断开时临时队列自动删除 String queueName = channel.queueDeclare().getQueue(); channel.queueBind(queueName, "logs", "");注意消费者不再直接监听一个固定名字的队列，而是让 RabbitMQ 生成一个随机队列名，然后绑定到交换机上。每个消费者都有自己独立的队列，交换机把消息复制转发给所有绑定的队列，所以每个消费者都能收到完整的一条消息。
踩坑提示：很多新手在发布订阅模式里，直接在消费者端声明队列，但忘记了声明交换机，或者忘记做绑定，结果消息发过去后直接被交换机丢弃了。再次强调，fanout 交换机本身就是忽略 routing key 的，绑定的时候 binding key 传空字符串""就行，不需要传任何具体的 key。
适用场景：配置广播、公告通知、缓存刷新（比如所有节点都要清空本地缓存）、订单状态变化通知多个下游系统。
2.4 路由模式（Routing）：带筛选条件的分发
如果广播模式下，只想让部分服务收到消息，部分不收呢？比如日志消息里有 info、warning、error 三个级别，只有 error 级别的日志需要发给告警服务，warning 和 info 级别的日志只需要入库服务处理。这时候就需要路由模式。
路由模式的交换机类型是direct，它的路由规则是精确匹配——消息的 routing key 必须和队列绑定的 binding key 完全一致，消息才会进入这个队列。
// 生产者：发送 error 级别日志，routing key 为 error channel.exchangeDeclare("direct_logs", "direct"); String routingKey = "error"; String message = "订单服务发生异常，堆栈信息..."; channel.basicPublish("direct_logs", routingKey, null, message.getBytes());消费者绑定的时候要指定自己关心的 binding key：
channel.exchangeDeclare("direct_logs", "direct"); String queueName = channel.queueDeclare().getQueue(); // 告警服务只关心 error 级别 channel.queueBind(queueName, "direct_logs", "error");这里有个很值得注意的细节：一个队列可以绑定多个 binding key。比如一个审计服务既想看 warning 又想看 error，那就绑定两次：
channel.queueBind(queueName, "direct_logs", "warning"); channel.queueBind(queueName, "direct_logs", "error");这样 warning 和 error 的消息都会进入同一个队列。而 routing key 是 info 的消息，跟这两个 binding key 都不匹配，自然会被交换机丢弃。
适用场景：按日志级别分类消费、按业务类型分发消息（订单消息、支付消息、库存消息各走各的队列）、指令分发系统。
2.5 主题模式（Topics）：最灵活的模糊匹配
路由模式虽然能筛选，但只能精确匹配，业务上不够灵活。比如我想匹配订单.创建、订单.支付、订单.取消这一整类主题，用 direct 模式就得绑定三次，太啰嗦了。主题模式就是为了解决这个问题。
主题模式的交换机类型是topic，它的 routing key 和 binding key 支持两个特殊符号：
*（星号）：匹配一个单词#（井号）：匹配零个或多个单词
单词之间用.分隔。比如 routing key 是order.created，binding key 是order.*，那就匹配上了。binding key 是order.#，也能匹配上，而且还能匹配order.paid.success这样的多级主题。
// 生产者：发送消息，routing key 描述消息的主题 channel.exchangeDeclare("topic_logs", "topic"); String routingKey = "order.paid.success"; String message = "订单支付成功，金额 199 元"; channel.basicPublish("topic_logs", routingKey, null, message.getBytes());消费者端可以按主题模式订阅：
channel.exchangeDeclare("topic_logs", "topic"); String queueName = channel.queueDeclare().getQueue(); // 关注所有 order 开头的消息 channel.queueBind(queueName, "topic_logs", "order.#"); // 或者只关注支付类消息 // channel.queueBind(queueName, "topic_logs", "*.paid.*");这里有个高频的坑：*只能匹配一个单词，#才能匹配多个单词。比如 binding key 写成order.*，那么 routing keyorder.paid.success是匹配不上的，因为order.paid.success是三个单词，*只对应paid那一个位置。很多新手以为*和模糊匹配里的%一样是任意长度，结果排查半天发现消息全都丢了。
适用场景：按业务主题订阅（订单、支付、库存、物流）、物联网设备按分类上报数据、按用户行为事件做个性化分发。这是七种模式里最灵活的一种，也是实际项目里用得最多的模式之一。
2.6 RPC 模式：请求响应的同步等待
前面几种模式都是单向的：生产者发完消息就完事，不关心结果。但有些场景是必须拿到返回结果的，比如客户端向服务端发起一个计算请求，需要等待服务端算完返回结果。
RabbitMQ 实现 RPC 的思路是这样：客户端创建一个临时队列用来接收响应，同时生成一个全局唯一的 correlationId 跟着请求消息一起发出去。服务端处理完消息后，把结果发回客户端指定的回调队列，并且带着同一个 correlationId。客户端根据 correlationId 判断这条响应是不是自己等的。
// RPC 客户端核心代码 String corrId = UUID.randomUUID().toString(); String replyQueueName = channel.queueDeclare().getQueue(); AMQP.BasicProperties props = new AMQP.BasicProperties.Builder() .correlationId(corrId) .replyTo(replyQueueName) .build(); // 发送请求到 rpc_queue，同时带上回调队列和关联ID channel.basicPublish("", "rpc_queue", props, message.getBytes());服务端这边稍微有点绕：它既要监听rpc_queue接收请求，又要拿到请求里带的 replyTo 队列，处理完把结果发过去。
需要特别提醒的是：能用 HTTP 或 gRPC 解决的简单同步调用，不要为了消息队列强行 RPC。RabbitMQ RPC 的本质是异步通信里塞同步等待，增加了消息中间件的复杂度，却没有带来异步的好处。更常见的做法是：客户端发消息后直接返回“已受理”，等后台处理完通过另一个队列或回调通知结果，这才是消息队列的正确姿势。
适用场景：确实需要跨系统请求响应、且不能直接 HTTP 调用的一些特殊场景，比如长时间任务提交后轮询结果、泛化调用等。实际业务里用得不多。
2.7 发布确认模式（Publisher Confirm）：消息可靠投递的最后一公里
最后一种模式严格来说不算“工作模式”，而是消息投递时的可靠性机制。但对于生产环境来说，这一种比前面六种更重要——消息发出去了，到底到没到 RabbitMQ？丢了没有？发布确认模式就是解决这个问题的。
核心步骤就两步：开启 confirm 模式，等待确认结果。
Channel channel = connection.createChannel(); // 开启发布确认模式 channel.confirmSelect(); String message = "这笔订单数据必须保证不丢"; channel.basicPublish("", "important_queue", null, message.getBytes()); // 同步等待确认：消息到达交换机后会返回确认 if (channel.waitForConfirms()) { System.out.println("消息已确认到达"); }confirmSelect()开启后，RabbitMQ 会为每一条发布的消息向生产者返回一个确认信号。如果消息被成功路由到队列，会收到确认；如果消息在到达交换机之前就失败了，会收到未确认的信号。
实际生产里，我建议把发布确认、队列持久化、消费者手动确认这三件事组合在一起用，才能保证消息“从发到收”全程不丢。具体来说：
- 队列持久化：声明队列时把 durable 参数设为 true，重启后队列还在
- 消息持久化：发消息时设置消息属性为持久化模式，重启后消息不丢
- 消费者手动确认：消费成功后回执，失败则重试
// 声明持久化队列 boolean durable = true; channel.queueDeclare("important_queue", durable, false, false, null); // 发送持久化消息 AMQP.BasicProperties props = new AMQP.BasicProperties.Builder() .deliveryMode(2) // 2 表示持久化 .build(); channel.basicPublish("", "important_queue", props, message.getBytes());适用场景：所有对数据一致性要求高的业务，尤其是订单、支付、账户流水这类不能丢的消息。银行转账、积分变动、交易订单，每一条都必须落袋为安。
3. 环境准备与启动排查：把 RabbitMQ 跑起来
聊完模式，说说实际部署。根据我这几年踩过的坑，90% 的 RabbitMQ 使用问题其实出在环境阶段，代码层面反而比较简单。这里结合我自己的实战经历，把 Windows 和 Linux 两条路线的关键点都过一遍。
3.1 Windows 下安装 RabbitMQ 的正确姿势
Windows 安装 RabbitMQ 最大的坑是Erlang 版本兼容性。RabbitMQ 对 Erlang 版本有严格的要求，版本太高或太低都会导致启动失败。
安装顺序不能乱：
- 先装 Erlang/OTP。去 Erlang 官网下载对应 Windows 安装包，注意版本要和 RabbitMQ 版本匹配。比如 RabbitMQ 4.1.x 要求的 Erlang 版本范围，官方文档里有明确说明。
- 安装 RabbitMQ。下载 Windows 版 exe 安装包，一路下一步。
- 必须要做的一件事：把 RabbitMQ 安装目录下的
sbin目录加到系统环境变量 PATH 里。否则后面执行命令行工具会提示找不到命令。 - 启动管理插件。
# 进入 RabbitMQ sbin 目录后执行 rabbitmq-plugins enable rabbitmq_management- 到 Windows 服务里把 RabbitMQ 服务启动起来，浏览器访问 http://localhost:15672 ，用默认账号 guest/guest 登录。
这里有一个大坑必须单独说：guest 用户默认只能在 localhost 地址访问。如果你本机测试没问题，但局域网内其他机器想连你的 RabbitMQ，就会报ACCESS_REFUSED。解决办法是创建一个自定义用户并给它设置权限：
rabbitmqctl add_user admin yourpassword rabbitmqctl set_user_tags admin administrator rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"3.2 Linux 下载安装部署
Linux 上我推荐直接用 RabbitMQ 官方提供的通用 Unix 安装包，不依赖系统包管理器，版本可控。以 RabbitMQ 4.1.x 为例：
# 1. 安装 Erlang（不同发行版命令略有差异，以 Ubuntu/Debian 为例） sudo apt-get install erlang-nox # 2. 下载 RabbitMQ 通用安装包 wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v4.1.0/rabbitmq-server-generic-unix-4.1.0.tar.xz # 3. 解压到指定目录 tar -xf rabbitmq-server-generic-unix-4.1.0.tar.xz mv rabbitmq_server-4.1.0 /usr/local/rabbitmq # 4. 启用管理插件 /usr/local/rabbitmq/sbin/rabbitmq-plugins enable rabbitmq_management # 5. 启动服务 /usr/local/rabbitmq/sbin/rabbitmq-server -detached启动后验证一下进程和端口：
ss -lntp | grep 5672 ss -lntp | grep 156725672 是 AMQP 协议端口，15672 是管理后台端口。两个端口都起来说明服务正常运行。
3.3 startup 失败排查：最常见的几种原因
我遇到过不少次 RabbitMQ 启动失败，总结下来主要就那么几类原因。这里直接列成速查表：
| 失败原因 | 现象 | 解决方法 |
|---|---|---|
| Erlang 版本不对 | 服务起不来，日志报版本不兼容 | 对照官方版本兼容表重新安装匹配的 Erlang |
| 主机名解析失败 | 日志里一直报 unable to connect to epmd | 检查 /etc/hosts，确保主机名能解析到 127.0.0.1 |
| 端口被占用 | 服务启动后立即退出，日志显示 Address already in use | 找到占用 5672 的进程并处理，或者换端口 |
| 数据目录权限问题 | 日志报 permission denied | 给 RabbitMQ 的数据目录和日志目录授权 |
| node 名称冲突 | 启动时报 node already running | 用 rabbitmqctl stop 清理旧进程，或删除 stale 节点信息 |
日志文件一般位于rabbitmq_home/log下，排查问题先看日志，不要瞎猜。
3.4 修改默认端口：5672 和 15672
有时候默认端口被公司防火墙策略限制，或者和其他服务冲突，需要改端口。修改端口只需要编辑 RabbitMQ 配置文件。
以 Windows 为例，配置文件在 RabbitMQ 安装目录下的etc/rabbitmq.conf：
# 修改 AMQP 端口 listeners.tcp.default = 5673 # 修改管理后台端口 management.listener.port = 15673改完后重启服务。这里有个细节：yaml 格式的老配置和 ini 格式的新配置不要混用，否则会有一个文件被忽略，导致配置不生效。平台默认的配置格式从 3.7 开始推荐使用 ini 格式，写起来也清晰。
4. 消息队列选型：RabbitMQ 和其他 MQ 的定位差异
很多人会问：现在市面上有 Kafka、RocketMQ、RabbitMQ，到底选哪个？这个话题我在跟团队做技术选型时反复讨论过，说说我的看法。
RabbitMQ 的核心优势在于灵活的路由能力。七大模式里的 fanout、direct、topic，这套交换机体系是 Kafka 和 RocketMQ 都不具备的。如果需要复杂的消息路由、按主题过滤、多消费者竞争消费，RabbitMQ 是最顺手的选择。它的缺点是吞吐量相对有限，单机性能虽然不算差，但跟 Kafka 比毕竟不是一个量级的。
Kafka 的定位是高吞吐日志流。它的设计目标是顺序读写、批量处理、水平扩展，适合用来做日志采集、用户行为追踪、大数据管道。RabbitMQ 做不了的每秒百万条级别吞吐，Kafka 可以轻松扛住。
RocketMQ 的定位介于两者之间。它在金融场景、电商交易链路里用得很多，因为它的事务消息和延迟消息特性在业界很出名，而且社区在可靠性方面做的非常扎实。如果是阿里系的架构体系，RocketMQ 通常是最顺手的。
| 对比维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 路由能力 | 强（交换机四种类型） | 弱（只有 topic 的 group 概念） | 中（tag 标签过滤） |
| 吞吐量 | 中 | 极高 | 高 |
| 消息可靠性 | 高（confirm + 事务） | 高（acks 可配置） | 极高（事务消息） |
| 延迟 | 微秒级 | 毫秒级（刷盘策略影响） | 毫秒级 |
| 学习曲线 | 平缓 | 偏陡 | 偏陡 |
| 典型场景 | 业务消息、任务分发、解耦 | 日志、流计算、大数据 | 交易、金融、电商 |
一句话选择建议：你需要在服务之间做复杂路由分发，选 RabbitMQ；你需要处理海量日志和流式数据，选 Kafka；你在做电商交易且需要事务消息，选 RocketMQ。没有最好的中间件，只有最适合当前场景的那个。
5. 实战中的高频故障与排错思路
5.1 消息丢失排查：链路三节点逐个验证
消息丢失是 RabbitMQ 使用中最痛的问题，没有之一。消息从生产者到消费者，经过三个环节，每一个环节都可能丢：
- 生产者发送到交换机失败 → 用发布确认解决
- 交换机路由到队列失败 → 检查绑定关系和 routing key 是否匹配；如果路由不到任何队列，消息默认会被丢弃
- 消费者处理失败且没有重试 → 手动确认 + 重试机制
排查思路就是围着这三个环节逐个验证。先确认交换机收到了多少消息，再看队列里有没有积压，最后看消费者有没有确认。RabbitMQ 管理后台的 Queues 页面可以看到每个队列的 Ready、Unacked、Total 三个数字。Ready 表示待消费，Unacked 表示已取走但未确认。如果 Unacked 持续上涨，说明消费者代码里忘了 basicAck，或者处理逻辑卡住了。
5.2 消息重复消费：幂等性是必修课
用 RabbitMQ 做消息消费，基本无法完全避免重复消息。原因很多：生产者重试导致重复发送，消费者处理完后在回执确认前宕机，RabbitMQ 重新投递。这是分布式架构里“at least once”语义的正常表现。
解决问题的唯一思路是消费端幂等。常见的幂等方案有三种：
- 数据库唯一约束：在处理消息前插入一条带有业务唯一键的记录，插入成功才继续处理，插入失败说明已经处理过
- 业务状态校验：比如订单状态已经是 PAID 了，再来一条支付成功消息，直接忽略
- Redis 去重：用消息的唯一 ID（可以用 correlationId 或业务订单号）作为 key 存 Redis，处理前先 SETNX，拿到锁才处理
5.3 连接池与 Channel 复用
这段是给进阶者看的。RabbitMQ 的 Connection 是 TCP 长连接，创建和销毁都很昂贵。Channel 是 Connection 上的逻辑信道，创建销毁就很便宜。
生产环境的规范做法是：一个进程只维护一个 Connection，所有线程共享这个 Connection，但每个线程用独立的 Channel。Channel 不是线程安全的，多个线程共用一个 Channel 会导致通道状态混乱。
// 正确做法：Connection 单例，Channel 按需创建（用完可关闭，或放入 ThreadLocal） Connection connection = connectionFactory.newConnection(); // 只创建一次 Channel channel = connection.createChannel(); // 每次使用创建 // ... 操作 channel.close(); // 操作完关闭 channel，但保持 connection 不关很多线上问题的根源就是每次调用都创建新的 Connection，连接数瞬间耗尽，或者一个 Channel 被多个线程乱用，导致 channel 报错。
5.4 管理后台常用命令速查
这几个命令是我在排障时用的最多的，整理成速查表方便快速查阅：
| 操作 | 命令 |
|---|---|
| 查看 node 状态 | rabbitmqctl status |
| 查看队列列表 | rabbitmqctl list_queues name messages consumers |
| 查看绑定关系 | rabbitmqctl list_bindings |
| 创建用户 | rabbitmqctl add_user username password |
| 设置用户权限 | rabbitmqctl set_permissions -p / username ".*" ".*" ".*" |
| 删除队列 | rabbitmqctl purge_queue queue_name |
| 重置 RabbitMQ | rabbitmqctl stop_app && rabbitmqctl reset && rabbitmqctl start_app |
6. 最后再聊几点实在的心得
RabbitMQ 的七种工作模式，学的时候用代码挨个跑一遍，你会发现理解速度远超纯看文档。我在教团队新人的时候，一定会让他们把官方教程里那七个 demo 跑通，再让他们回答一个问题：如果现在有一个订单系统，需要在下单成功后同时通知积分服务、库存服务、物流服务，你会选哪种模式？这个问题答对了，说明发布订阅和路由之间的边界真的想明白了。
再说说安装部署这件事。现在 Docker 这么方便，本地学习和测试完全可以直接用容器跑 RabbitMQ，一条命令的事：
docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:4.1-management这个镜像自带管理插件，起来就能用，比手动装 Erlang 和 RabbitMQ 省心太多。生产环境如果公司内部还没普及容器化，再用前面说的安装包方式去部署也完全来得及。
我在实际项目中还养成了一个习惯：每个队列在命名时就带上它的业务含义和模式类型。比如order.created.fanout、log.error.direct、task.worker.queue，这样看队列名就能猜出大概的架构设计，排障的时候效率会高不少。RabbitMQ 的优势在于它足够灵活，但灵活也意味着容易滥用。七种模式里不是每种都需要用到极致的配置，选对场景比堆砌功能重要得多。架构没有银弹，能把简单模式用好，已经能解决大部分业务问题了。
