RabbitMQ on Snow

About RabbitMQ Interview

Fri, 17 Apr 2026 11:18:12 +0800

本文档覆盖 RabbitMQ 从基础到高级的所有面试高频考点，包含详细原理、实战方案和大厂面试标准答案，适用于校招、社招、中高级开发面试准备。

一、基础概念与架构篇

1. 为什么要使用消息队列？它解决了什么问题？

核心三大作用：

应用解耦
- 传统微服务间同步调用存在强耦合，任何一个服务故障都会导致整个链路失败。
- 通过 MQ 实现异步通信，服务间仅通过消息交互，无需感知对方状态，某服务临时故障时消息可暂存，恢复后继续处理。
- 典型场景：电商下单后，订单服务无需同步调用库存、物流、支付服务，仅需发送消息即可，各服务独立消费处理。
异步处理
- 对于非核心的耗时操作，通过 MQ 异步处理，主流程无需等待，大幅提升接口响应速度。
- 典型场景：用户注册后，发送短信、邮件、初始化积分等操作无需同步等待，通过 MQ 异步执行，注册接口响应时间从 500ms 降至 50ms。
流量削峰
- 在秒杀、大促等瞬时高流量场景，MQ 作为缓冲区，将瞬时高峰请求分散到一段时间内处理，避免后端服务被打垮。
- 典型场景：秒杀活动瞬时 2 万 QPS(Query Per Second)，后端服务仅能处理 1 万 QPS，通过 MQ 缓冲，将请求均匀分散到后续几秒处理，用户仅需延迟几秒收到结果，体验远好于被拒绝。

2. RabbitMQ 是什么？基于什么协议？

RabbitMQ 是一个开源的消息代理（Message Broker），基于 AMQP（Advanced Message Queuing Protocol，高级消息队列协议） 实现。

AMQP 是一个开放标准的应用层协议，定义了消息的流转、路由、可靠性等标准，支持复杂的路由规则和消息确认机制。
与其他 MQ 不同，RabbitMQ 严格遵循 AMQP 协议，提供了更丰富的企业级特性。

3. RabbitMQ 的核心组件有哪些？各自的作用是什么？

组件	作用
Producer（生产者）	创建并发送消息的客户端，负责将业务消息发送到 Exchange。
Consumer（消费者）	订阅队列并处理消息的客户端，消费完成后发送确认信号。
Exchange（交换器）	接收生产者的消息，根据路由规则将消息分发到绑定的队列，是消息路由的核心。
Queue（队列）	存储消息的缓冲区，消息最终会到达队列等待消费，遵循 FIFO 原则。
Binding（绑定）	定义 Exchange 和 Queue 之间的关联关系，以及路由规则（Binding Key）。
Connection（连接）	客户端与 Broker 之间的 TCP 长连接，负责网络通信。
Channel（信道）	Connection 内部的虚拟通道，所有 AMQP 命令都通过 Channel 执行，复用 TCP 连接，减少连接开销。
vHost（虚拟主机）	逻辑隔离单元，每个 vHost 拥有独立的 Exchange、Queue、权限，实现多租户隔离。

4. 什么是 Channel？为什么需要 Channel？

Channel 是 Connection 内部的虚拟连接，可以理解为 “轻量级的 TCP 连接”。
为什么需要 Channel？
1. 减少 TCP 连接开销：TCP 连接的创建和销毁开销很大，如果每个线程都创建一个 TCP 连接，高并发下系统会被大量连接耗尽资源。
2. 复用连接：一个 TCP 连接可以创建多个 Channel，多个线程可以共享同一个 Connection，每个线程使用独立的 Channel，既保证了线程隔离，又减少了连接数。
3. 高效通信：Channel 之间完全隔离，一个 Channel 的故障不会影响其他 Channel，而且 AMQP 协议通过 Channel ID 来区分不同的信道，效率极高。

5. 什么是 vHost？它的作用是什么？

vHost 是 RabbitMQ 中的逻辑隔离单元，相当于 Broker(也就是 RabbitMQ 服务器) 中的 “小集群”。

作用：
1. 多租户隔离：不同的业务、团队可以使用不同的 vHost，互相之间完全隔离，Exchange、Queue 的名称可以重复，不会冲突。
2. 权限控制：可以在 vHost 级别配置用户权限，限制用户只能访问特定的 vHost，保证数据安全。
3. 资源隔离：不同 vHost 的资源使用互相独立，避免某个业务的消息积压影响其他业务。

6. RabbitMQ 的 Exchange 有哪些类型？各自的路由规则是什么？

这是面试必考题，四种 Exchange 的区别一定要讲清楚：

Direct Exchange（直连交换机）
- 路由规则：精确匹配 Routing Key 和 Binding Key。
- 消息的 Routing Key 和队列的 Binding Key 完全一致时，消息才会被路由到该队列。
- 适用场景：点对点的消息发送，或者根据消息类型进行精确路由。
Topic Exchange（主题交换机）
- 路由规则：通配符模糊匹配，支持*和#通配符。
  - *：匹配一个单词（以.分隔的词）
  - #：匹配零个或多个单词
- 例如：Binding Key 为order.#，可以匹配order.create、order.pay.success等 Routing Key。
- 适用场景：发布订阅模式，根据主题进行灵活的消息路由，比如日志的不同级别、不同模块的消息。
Fanout Exchange（扇出交换机）
- 路由规则：广播模式，忽略 Routing Key，将消息广播到所有绑定的队列。
- 只要队列绑定了这个交换机，不管 Binding Key 是什么，都会收到消息。
- 适用场景：广播通知，比如集群内的配置更新、事件通知，所有订阅的服务都要收到消息。
Headers Exchange（头交换机）
- 路由规则：根据消息的 Header 属性进行匹配，忽略 Routing Key。
- 可以配置x-match参数，all表示所有 Header 都要匹配，any表示任意一个匹配即可。
- 适用场景：需要根据多个属性进行复杂路由的场景，使用较少，因为性能不如其他几种。

7. RabbitMQ 的消息最大能有多大？队列的长度有限制吗？

消息最大大小：默认是 128MB，可以通过配置修改。生产环境建议不要发送过大的消息，超过 10MB 的消息建议先上传到存储，然后发送存储地址。
队列长度：理论上没有限制，取决于服务器的内存和磁盘。但是消息过多会导致消息积压，影响性能，生产环境需要监控队列长度，设置告警。

二、工作机制与流转篇

1. RabbitMQ 中消息的完整流转过程是怎样的？

生产者建立 TCP 连接，创建 Channel。
生产者声明 Exchange、Queue，并通过 Binding Key 将两者绑定。
生产者发送消息到 Exchange，消息包含 Routing Key。
Exchange 根据自身类型和 Binding 规则，将消息路由到对应的 Queue。
如果消息无法路由到任何队列，且配置了mandatory=true，消息会返回给生产者；否则直接丢弃。
消费者监听 Queue，当有消息到达时，消费者获取消息，处理业务逻辑。
消费者处理完成后，发送 ACK 确认给 Broker，Broker 收到 ACK 后，将消息从队列中删除。
如果消费者处理失败，发送 NACK，Broker 会根据配置将消息重新入队，或者转发到死信队列。

2. RabbitMQ 有哪些工作模式？

这是基础面试题，对应不同的使用场景：

Simple（简单模式）：单生产者、单消费者，消息直接发送到队列，适用于简单的任务处理。
Work Queues（工作队列）：单生产者、多消费者，多个消费者竞争消费同一个队列的消息，实现任务的负载均衡，适用于耗时任务的处理。
Publish/Subscribe（发布订阅）：使用 Fanout 交换机，生产者发送消息到交换机，所有绑定的队列都能收到消息，实现广播。
Routing（路由模式）：使用 Direct 交换机，根据 Routing Key 精确匹配，实现消息的选择性接收。
Topic（主题模式）：使用 Topic 交换机，通配符匹配，实现更灵活的主题路由。

3. 什么是 ACK 机制？自动 ACK 和手动 ACK 的区别是什么？

ACK（Acknowledgement）是消费者向 Broker 确认消息已经处理完成的机制。

自动 ACK（autoAck=true）：
- Broker 一旦把消息发送给消费者，就会立即把消息从队列中删除，不管消费者有没有处理成功。
- 优点：性能高，简单。
- 缺点：如果消费者处理到一半宕机了，消息就会丢失，因为 Broker 已经把消息删了。
- 适用场景：不重要的消息，比如日志收集，丢了也没关系。
手动 ACK（autoAck=false）：
- 消费者处理完消息后，需要手动调用basic.ack告诉 Broker 处理完成，Broker 才会删除消息。
- 如果消费者宕机了，没有发送 ACK，Broker 会把消息重新分发给其他消费者。
- 优点：保证消息不丢失，可靠性高。
- 缺点：需要手动处理，稍微复杂一点。
- 适用场景：核心业务，比如订单、支付，必须保证消息处理成功。

4. 什么是 NACK？什么时候会用到？

NACK（Negative Acknowledgement）是消费者告诉 Broker 消息处理失败的机制。

当消费者处理消息失败时，可以调用basic.nack或者basic.reject，告诉 Broker 处理失败。
可以设置requeue参数：
- requeue=true：Broker 会把消息重新入队，分发给其他消费者重试。
- requeue=false：Broker 会把消息丢弃，或者转发到死信队列。
适用场景：处理失败的消息，比如网络异常、业务异常，需要重试或者进入死信队列处理。

5. 什么是 prefetch_count？它的作用是什么？

prefetch_count是消费者的预取数量，用来控制消费者在收到 ACK 之前，最多能从 Broker 那里拿多少个消息。

作用：
1. 实现公平调度：默认情况下，RabbitMQ 会把消息轮询分发给消费者，不管消费者的处理能力，可能导致有的消费者很忙，有的很闲。
2. 避免消息积压在消费者端：如果消费者处理很慢，Broker 还在不停的发消息，会导致消息都堆在消费者的内存里，浪费资源。
3. 负载均衡：通过设置prefetch_count=1，可以保证消费者处理完一个消息，Broker 才会发下一个，这样处理快的消费者就能处理更多的消息，实现公平的负载均衡。

三、消息可靠性保障篇

这是面试的重中之重，几乎所有大厂都会问这部分。

1. RabbitMQ 可能会出现消息丢失的场景有哪些？怎么解决？

消息丢失分为三个场景，每个场景都有对应的解决方案：

丢失场景	原因	解决方案
生产者到 Broker 丢失	网络异常，消息没发到 Broker；或者 Broker 收到了，但是还没处理，生产者就以为成功了。	生产者确认机制：事务机制或者 Confirm 模式。
Broker 内部丢失	Broker 宕机了，内存中的消息还没持久化到磁盘，重启后消息就没了。	消息持久化：队列、交换机、消息都要设置为持久化。
消费者到 Broker 丢失	消费者收到消息，还没处理完就宕机了，Broker 已经把消息删了。	消费者手动 ACK：处理完再发 ACK，没处理完的话 Broker 会重发。

2. 什么是生产者 Confirm 模式？它和事务机制有什么区别？

这两个都是用来保证生产者的消息能成功到达 Broker 的机制。

事务机制：
- 生产者开启事务（channel.txSelect()），发送消息，然后提交事务（channel.txCommit()）。
- 如果提交成功，说明消息已经成功到达 Broker；如果失败，事务回滚，生产者可以重发。
- 缺点：同步阻塞，性能非常低，吞吐量会下降 10 倍左右，生产环境基本不用。
Confirm 模式：
- 生产者将 Channel 设置为 Confirm 模式，所有发送的消息都会被分配一个唯一的 ID。
- 消息成功到达 Broker 后，Broker 会返回一个 ACK 给生产者；如果失败，返回 NACK。
- 这个过程是异步的，生产者可以一边发消息，一边等回调，性能非常高。
- Confirm 模式有三种实现：
  1. 单独确认：发一个，等一个确认，性能低。
  2. 批量确认：发一批，等一批的确认，吞吐量高，但是出问题不知道哪个消息失败了。
  3. 异步确认：通过回调函数处理 ACK/NACK，性能最高，生产环境推荐用这个。

两者的区别：

事务是同步的，Confirm 是异步的。
事务性能低，Confirm 性能高。
事务是强一致性的，Confirm 是最终一致性的。
生产环境优先用 Confirm 模式，事务基本不用。

3. 消息持久化要怎么做？是不是设置了持久化就一定不会丢消息？

持久化需要同时配置三个地方，缺一不可：

交换机持久化：声明 Exchange 的时候，设置durable=true，这样 Broker 重启后，Exchange 还在。
队列持久化：声明 Queue 的时候，设置durable=true，Broker 重启后，队列还在。
消息持久化：发送消息的时候，设置deliveryMode=2，这样消息会被持久化到磁盘，而不是只存在内存里。

注意：持久化也不能保证 100% 不丢消息！

因为 Broker 收到消息后，会先写到内存，然后异步刷到磁盘。如果在刷盘之前 Broker 宕机了，消息还是会丢。
要更高的可靠性，需要配合镜像队列，把消息同步到多个节点，只要有一个节点存活，消息就不会丢。

4. 什么是 mandatory 参数？什么是备份交换机？

mandatory 参数：
- 当生产者发送消息，Exchange 无法将消息路由到任何队列的时候，如果mandatory=true，Broker 会把消息返回给生产者；如果是 false，消息直接丢弃。
- 作用：让生产者感知到消息无法路由，避免消息悄无声息的丢失。
备份交换机（Alternate Exchange）：
- 可以给一个 Exchange 设置一个备份交换机，当这个 Exchange 的消息无法路由的时候，会把消息转发到备份交换机，而不是返回给生产者或者丢弃。
- 备份交换机一般用 Fanout 类型，绑定一个队列，所有无法路由的消息都会进入这个队列，然后可以有专门的消费者处理这些消息，或者报警。
- 作用：统一处理无法路由的消息，比 mandatory 更优雅，不用生产者处理返回的消息。

5. 什么是幂等性？为什么需要幂等性？怎么实现？

幂等性：同一个操作，执行一次和执行多次的结果是一样的，不会产生副作用。
为什么需要？
- 因为 RabbitMQ 的 “至少一次” 投递机制，可能会导致消息重复消费。
- 比如：消费者处理完消息，发 ACK 的时候网络断了，Broker 没收到 ACK，就会把消息重发给其他消费者，导致同一个消息被消费两次。
- 如果业务是扣库存、扣款，重复消费就会导致扣两次钱，出大问题。

实现幂等性的方案：

全局唯一消息 ID：
- 生产者给每个消息生成一个唯一的 ID，比如 UUID，或者业务 ID。
- 消费者收到消息后，先去 Redis 里查这个 ID 有没有存在过，用setnx原子操作，如果存在，说明已经消费过了，直接跳过；如果不存在，就处理业务，然后把 ID 存到 Redis。
业务唯一键 + 数据库唯一约束：
- 比如订单支付消息，用订单 ID 作为唯一键。
- 消费者处理的时候，先查数据库，这个订单有没有已经支付过了，如果有，就跳过。
- 或者在数据库里给订单 ID 加唯一约束，插入的时候如果重复就会报错，捕获报错跳过。
状态机判断：
- 业务有状态流转，比如订单的状态：待支付、已支付、已发货、已完成。
- 每次处理消息的时候，先判断当前状态是不是可以执行这个操作，比如已经是已支付了，就不能再执行支付操作了，直接跳过。
分布式锁：
- 处理消息之前，先抢锁，锁的 key 是消息 ID 或者业务 ID，抢到了才处理，没抢到就说明已经有其他线程在处理了，跳过。

6. RabbitMQ 的消息传输保障有哪些？

At most once（最多一次）：消息最多投递一次，可能会丢，不会重复。适用于不重要的消息，比如日志。
At least once（最少一次）：消息至少投递一次，不会丢，可能会重复。这是 RabbitMQ 默认的，也是大部分业务用的，需要配合幂等性来解决重复的问题。
Exactly once（恰好一次）：消息正好投递一次，不丢不重。RabbitMQ 本身做不到，需要业务层配合幂等性来实现。

四、高级特性与实战场景篇

1. 什么是死信队列（DLX）？什么时候消息会变成死信？

死信队列（Dead-Letter-Exchange，DLX），就是用来存放那些无法被正常消费的消息的队列，相当于 “垃圾回收站”。

消息变成死信的三种情况：

消息被拒绝了：消费者调用basic.reject或者basic.nack，并且设置了requeue=false，消息不会重新入队，就变成死信。
消息 TTL 过期了：消息设置了过期时间，到时间了还没被消费，就变成死信。
队列满了：队列达到了最大长度，新的消息进不来，最早的消息就会被挤出去，变成死信。

死信队列的作用：

处理失败的消息，比如消费失败的消息，不会直接丢了，而是放到死信队列，后续可以人工处理，或者重试。
实现延迟队列，这个是最常用的。比如订单超时取消，发送一个延迟消息，30 分钟后如果订单还没支付，这个消息就会过期，变成死信，消费者监听死信队列，处理超时订单。

2. RabbitMQ 怎么实现延迟队列？有哪些方式？

RabbitMQ 本身没有直接的延迟队列功能，但是可以通过两种方式实现：

方式一：TTL + 死信队列（最常用）

声明一个普通的队列，设置死信交换机和死信路由键。
发送消息的时候，给消息设置 TTL（过期时间），比如 30 分钟，就是订单 30 分钟超时。
消息发送到这个普通队列，因为设置了 TTL，30 分钟后消息过期，就会变成死信，转发到死信队列。
消费者监听死信队列，消息到达的时候，正好是 30 分钟后，就可以处理超时的订单了。

注意： 这种方式有个问题，如果队列里的消息顺序不对，比如先发送了一个 1 小时过期的消息，再发送了一个 1 分钟过期的消息，那么 1 分钟的消息会被 1 小时的消息挡住，要等 1 小时的消息过期了，它才能过期，导致延迟不准。所以如果要不同的延迟时间，最好是按延迟时间分队列。

方式二：延迟交换机插件

RabbitMQ 官方提供了rabbitmq_delayed_message_exchange插件，安装之后，就可以声明一个延迟类型的交换机。

发送消息的时候，在 Header 里设置x-delay，指定延迟的毫秒数。
交换机会把消息存起来，到时间了再投递到队列。
这种方式没有上面的顺序问题，支持任意的延迟时间，更灵活。

应用场景：订单超时取消、任务重试、定时通知。

3. 什么是优先级队列？

优先级队列可以让优先级高的消息先被消费。

创建队列的时候，设置x-max-priority参数，指定最大的优先级，比如 10。
发送消息的时候，设置priority属性，比如 5，优先级越高，越先被消费。
适用场景：需要优先处理重要消息的场景，比如大促的时候，VIP 用户的订单优先处理。

4. 什么是惰性队列？

惰性队列（Lazy Queue）是 RabbitMQ 3.6 之后引入的特性，默认情况下，RabbitMQ 会尽量把消息存在内存里，提高消费速度，但是如果消息积压很多，就会占用大量内存，甚至触发内存告警。

惰性队列会把消息直接存到磁盘里，不管有没有积压，这样即使消息积压几百万条，也不会占用太多内存。
缺点：消费的时候需要从磁盘读，性能会稍微低一点。
适用场景：消息可能会大量积压的场景，比如日志收集，或者非核心的业务，对性能要求不高，但是要避免内存被占满。

5. 怎么基于 RabbitMQ 实现 RPC？

RPC 就是远程调用，客户端发送请求，等待服务端返回结果。

实现步骤：
1. 客户端声明一个临时的回调队列，用来接收响应。
2. 客户端发送请求消息，消息里带上correlation_id（唯一 ID），还有reply_to（回调队列的名字）。
3. 服务端监听请求队列，收到请求后处理，然后把响应发送到回调队列，带上相同的correlation_id。
4. 客户端监听回调队列，收到响应后，根据correlation_id匹配对应的请求，把结果返回。
这样就实现了同步的 RPC 调用，RabbitMQ 官方的客户端也支持这个功能。

五、集群与高可用篇

1. RabbitMQ 的集群模式有哪些？区别是什么？

RabbitMQ 的集群主要有三种模式：

1. 普通集群模式（默认）

集群中的节点会同步元数据（Exchange、Queue 的定义），但是消息不会同步，消息只存在于创建它的那个节点上。
比如，节点 1 创建了一个队列，消息都存在节点 1，节点 2 的消费者消费这个队列的时候，会从节点 1 拉取消息。
缺点：没有高可用，如果节点 1 宕机了，这个队列的消息就丢了，因为其他节点没有备份。
适用场景：只是为了分担客户端的连接压力，不需要高可用的场景，生产环境基本不用。

2. 镜像队列模式（Mirrored Queues）

这是 RabbitMQ 3.8 之前的高可用方案，队列的消息会同步复制到所有的镜像节点。
主节点负责写，从节点同步数据，主节点宕机了，从节点会自动切换成新的主节点，消息不会丢。
缺点：同步复制的性能开销比较大，因为每个消息都要同步到所有节点，而且是基于 GM 协议，一致性不是很强，脑裂的时候可能会丢数据。

3. 仲裁队列模式（Quorum Queues）

这是 RabbitMQ 3.8 之后推荐的高可用方案，基于 Raft 协议实现。
比镜像队列更可靠，一致性更强，脑裂的处理更好，性能也更好。
支持多数派选举，只要多数节点存活，队列就可用，数据不会丢。
现在生产环境都推荐用仲裁队列，代替原来的镜像队列。

2. 集群中的磁盘节点和内存节点有什么区别？

磁盘节点：把元数据（用户、vHost、队列、交换机的信息）持久化到磁盘，重启后不会丢。
内存节点：元数据只存在内存里，性能更高，但是重启后元数据就丢了。
注意：集群中至少要有一个磁盘节点，不然所有节点都是内存节点的话，集群重启后所有的元数据都没了，相当于清空了。
内存节点一般用来做性能优化，比如对性能要求很高的节点，但是必须要有磁盘节点来存元数据。

3. 为什么集群建议用奇数个节点？

因为仲裁队列和 Raft 协议需要多数派（Quorum）来选举和确认。

比如 3 个节点，最多可以容忍 1 个节点宕机，只要 2 个节点存活，就能形成多数派，集群可用。
如果是 2 个节点，最多只能容忍 0 个节点宕机，因为 1 个节点宕机了，剩下的 1 个节点，无法形成多数派（需要 2 个中的 2 个），集群就不可用了，和单节点没区别。
所以奇数个节点，能在相同的节点数下，容忍更多的节点故障，比如 3 个节点比 2 个节点的可用性高，5 个比 4 个高。

4. 什么是脑裂？怎么解决？

脑裂就是集群因为网络分区，分成了两个小集群，每个小集群都认为对方宕机了，自己是主集群，各自写数据，等网络恢复后，就会有两个主节点，导致数据冲突、丢失。

RabbitMQ 的解决方式：

配置集群的恢复策略：
1. ignore：默认，自动恢复，但是可能会丢数据，只适合短暂的网络抖动。
2. pause_minority：暂停少数派的节点，少数派的节点会停止服务，等网络恢复，这样就不会出现两个主集群，保证数据一致。
3. autoheal：自动重启少数派的节点，恢复集群。
另外，仲裁队列基于 Raft 协议，本身就可以很好的处理脑裂的问题，比镜像队列更可靠。

5. 普通集群和镜像集群的消息同步机制有什么区别？

普通集群：只同步元数据，消息不同步，消息只在主节点。
镜像集群：消息同步到所有镜像节点，主节点写，从节点同步，同步方式有同步和异步。
仲裁队列：基于 Raft，多数派同步，写操作需要多数节点确认才成功，一致性更强。

六、性能优化与问题排查篇

1. 消息积压了怎么办？

消息积压是生产环境经常遇到的问题，也是面试常问的，处理分三步：

1. 紧急处理

修复消费者：先找到消费者慢的原因，比如代码有 bug、数据库慢，修复它，恢复消费速度。
临时扩容消费者：如果积压太多，临时加 N 倍的消费者实例，快速消费积压的消息。
临时转移消息：写一个临时的程序，把积压的队列的消息，转移到 N 个临时队列，然后部署 N 倍的消费者，并行消费，快速把积压的消息清掉。
生产者限流：如果生产者还在疯狂发消息，先限流，不让新的消息进来，先把旧的处理完。

2. 事后优化

优化消费者性能：比如把同步改成异步，批量处理，优化数据库操作，提升消费速度。
监控预警：监控队列长度，超过阈值就报警，提前发现问题，不要等积压了几百万才发现。
惰性队列：如果经常有积压，可以用惰性队列，避免内存被占满。

2. 怎么保证消息的顺序性？

RabbitMQ 本身只能保证单个队列内的消息是 FIFO 的，但是如果有多个消费者，或者重试，就会乱序。

保证顺序性的方案：

单队列单消费者：最简单的方式，一个队列只有一个消费者，这样消息就是按顺序处理的，但是性能低，吞吐量低。
业务分区：把需要保证顺序的消息，按业务 ID 哈希，分到同一个队列，比如同一个用户的消息，都发到同一个队列，同一个订单的消息都发到同一个队列，然后每个队列一个消费者，这样同一个业务的消息就是顺序的，不同的可以并行，兼顾性能和顺序。
消息序列号：生产者给消息加序列号，消费者收到后，按序列号排序，乱序的话就等前面的消息处理完再处理，但是这个比较复杂。

3. RabbitMQ 的内存告警是怎么回事？

RabbitMQ 有个内存水位线，默认是可用内存的 40%，当内存使用率超过这个阈值的时候，就会触发内存告警，然后阻塞生产者的连接，不让生产者发消息了，避免内存耗尽导致宕机。

这个时候需要处理：
1. 看是不是消息积压了，消费者没消费，导致消息都堆在内存里。
2. 清理掉没用的消息，或者加快消费速度。
3. 也可以调整内存水位线，但是不建议，因为内存不够还是会宕机。

4. RabbitMQ 的性能瓶颈在哪里？

磁盘 IO：如果开启了持久化，消息要刷到磁盘，磁盘的写入速度就是瓶颈，尤其是机械硬盘，SSD 会好很多。
网络：集群之间的同步，还有客户端的网络，高并发下网络可能会成为瓶颈。
内存：如果消息积压，内存不够，就会触发告警，阻塞生产者。
CPU：一般 CPU 不是瓶颈，除非有很多复杂的路由，或者加密、压缩。

5. 怎么监控 RabbitMQ？

Management 插件：自带的 Web 管理界面，可以看队列长度、连接数、消息速率。
API 监控：调用 RabbitMQ 的 HTTP API，获取监控指标，比如队列长度、消息数、内存使用率。
Prometheus + Grafana：用 RabbitMQ Exporter 把指标导出到 Prometheus，然后用 Grafana 做可视化，设置告警，比如队列长度超过 1 万就报警，内存超过阈值就报警。
关键监控指标：队列长度、消息生产 / 消费速率、连接数、信道数、内存使用率、磁盘使用率、节点状态。

七、对比选型与最佳实践篇

1. RabbitMQ、Kafka、RocketMQ 的区别？怎么选型？

特性	RabbitMQ	Kafka	RocketMQ
协议	AMQP	自定义	自定义
吞吐量	万级	百万级	十万级
延迟	微秒级	毫秒级	毫秒级
可靠性	高，支持事务、Confirm	高，副本机制	高，支持事务
路由	非常丰富，四种 Exchange	简单，按 Topic	丰富，支持 Tag
适用场景	企业级业务消息，解耦、异步	大数据、日志、流处理	电商、订单，高可靠

选型建议：

如果是业务系统，需要复杂的路由、可靠的消息投递，用 RabbitMQ，开发简单，功能丰富。
如果是大数据、日志收集、流处理，高吞吐量，用 Kafka。
如果是电商、金融，需要高可靠、事务消息，用 RocketMQ。

2. RabbitMQ 的最佳实践有哪些？

连接池：不要频繁创建连接，用连接池，复用连接，减少 TCP 开销。
信道复用：每个线程用独立的 Channel，不要多个线程共用一个 Channel，因为 Channel 不是线程安全的。
消息不要太大：超过 10MB 的消息不要发，先存到 OSS，然后发地址。
设置过期时间：不重要的消息设置 TTL，避免过期的消息还占着资源。
不要用自动 ACK：核心业务都用手动 ACK，保证消息不丢。
开启 Confirm 模式：生产者开启 Confirm，保证消息到达 Broker。
配置死信队列：所有核心队列都配置死信队列，处理失败的消息。
集群部署：生产环境不要用单机，一定要用集群，仲裁队列，保证高可用。
监控告警：一定要监控队列长度，提前发现积压问题。
幂等性：所有消费逻辑都要保证幂等，避免重复消费出问题。

八、大厂实战场景题

1. 电商订单超时未支付，怎么用 RabbitMQ 实现？

这是最经典的场景，答案就是延迟队列：

用户下单后，发送一个延迟消息，延迟 30 分钟，路由到订单超时队列。
消费者监听这个队列，30 分钟后收到消息。
消费者查询订单的状态，如果还是待支付，就取消订单，恢复库存。
如果用户在 30 分钟内支付了，就把这个延迟消息取消（或者消费的时候判断状态，跳过）。

实现方式可以用 TTL + 死信队列，或者延迟交换机插件。

2. 秒杀系统怎么用 RabbitMQ 削峰？

秒杀开始后，用户的下单请求，先发到 RabbitMQ，而不是直接到订单服务。
订单服务慢慢的从队列里消费消息，处理订单，按照自己的处理能力来，比如 1 万 / 秒。
这样瞬时的 2 万 QPS 的请求，就被 MQ 缓冲了，不会打垮订单服务。
用户端可以提示 “排队中”，等处理完了再通知用户。

3. 如何基于 RabbitMQ 实现分布式事务？

用最终一致性的方案，比如可靠消息最终一致性：

本地事务执行前，先把消息存到本地的消息表，状态是待发送。
本地事务执行成功，然后发送消息到 MQ。
有个定时任务，扫描本地消息表，把待发送的消息重发，保证消息一定能发到 MQ。
消费者收到消息，执行本地事务，执行成功后 ACK。
如果消费者执行失败，就重试，直到成功。

这样就保证了两个本地事务要么都成功，要么都失败，实现最终一致性。

4. 消息消费失败了，怎么重试？

消费者处理失败的时候，先判断重试次数，如果没到最大次数，就发送 NACK，设置requeue=true，让消息重新入队，重试。
但是直接重发的话，会马上重试，可能还是失败，所以可以用延迟重试，每次重试的间隔越来越长，比如 1s、2s、4s、8s，指数退避。
如果重试次数到了最大次数，还失败，就把消息转到死信队列，人工处理。

建议结合实际项目经验理解，面试时可以结合自己的项目案例来回答。

RabbitMQ Tutorial for Beginners (Go)

Mon, 30 Mar 2026 19:45:57 +0800

前言

RabbitMQ 是目前最流行的开源消息中间件之一，它基于 AMQP 协议（Advanced Message Queuing Protocol），能够帮我们实现系统解耦、异步通信、流量削峰等功能，是微服务架构中必不可少的组件。

读完这份教程，你将学会：

RabbitMQ 的核心概念，再也不怕听不懂术语
如何在各种系统上快速安装部署 RabbitMQ
如何用 Go 语言连接和操作 RabbitMQ
RabbitMQ 的 6 种核心工作模式，以及它们的适用场景
生产环境必备的高级特性：消息确认、持久化、死信队列等

一、RabbitMQ 核心概念：用快递站帮你搞懂

很多新手刚接触 RabbitMQ 时，会被一堆术语搞晕：生产者、消费者、交换机、队列… 别担心，我们用生活中最常见的快递站来类比，保证你一看就懂。

1.1 核心组件类比

想象一下，你开了一家淘宝店，每天要给全国各地的用户发快递。你不会自己一个个送快递，而是把包裹交给快递站，由快递站来帮你完成后续的配送。

RabbitMQ 就相当于这个 快递站，它的各个组件对应快递站的不同角色：

`RabbitMQ` 术语	快递站类比	作用说明
生产者 (Producer)	发快递的你（淘宝卖家）	负责生产消息，把消息发送给 `RabbitMQ`
消费者 (Consumer)	收快递的买家	负责从 `RabbitMQ` 接收并处理消息
交换机 (Exchange)	快递分拣中心	接收你发来的包裹，根据地址把包裹分到不同的快递柜
队列 (Queue)	小区的快递柜	用来暂存包裹，买家什么时候有空什么时候来取
绑定 (Binding)	分拣中心到快递柜的路线	告诉分拣中心：XX 地址的包裹，要放到 XX 快递柜里
路由键 (Routing Key)	包裹上的收货地址	你发包裹时写的地址，用来告诉分拣中心这个包裹要送到哪（也就是目的地）
虚拟主机 (VHost)	独立的快递园区	用来隔离不同的业务，比如淘宝的快递和京东的快递各用一个园区，互不干扰

1.2 消息流转的完整流程

搞懂了这些角色，整个消息流转的过程就非常清晰了：

你（生产者）打包好商品，写好收货地址（路由键），把包裹交给快递站（RabbitMQ）
包裹先送到分拣中心（交换机）
分拣中心根据你写的地址，按照之前定好的路线（绑定），把包裹放到对应的快递柜（队列）里
买家（消费者）下班后来到小区，从对应的快递柜里取出包裹，完成签收

整个过程中：

你不需要等买家签收，交完包裹就可以去忙别的了（异步处理）
就算买家今天没空取，包裹也会一直存在快递柜里，等他明天来取（消息存储）
双 11 包裹爆仓时，快递柜能帮你暂存所有包裹，不会因为突然的流量把系统冲垮（流量削峰）

1.3 架构图直观理解

下面这张架构图，能帮你更直观地理解这些组件之间的关系：

二、环境搭建：5 分钟搞定 RabbitMQ 服务

接下来我们要把 RabbitMQ 服务跑起来，这里我最推荐你用 Docker 来安装，因为它最简单，一行命令就能搞定，不用管什么依赖、版本问题。当然，我也会给你提供其他系统的安装方式。

2.1 推荐方式：Docker 一键安装

如果你已经装了 Docker，只需要执行下面这一条命令：

`1`	`docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management`

第一次运行会自动下载镜像，等它下载完了，容器就会启动成功了。我这里已经是下载好了，所以直接就启动了。

解释一下这几个参数：

-p 5672:5672：这是 RabbitMQ 的通信端口，我们的 Go 程序就是通过这个端口连接 RabbitMQ 的
-p 15672:15672：这是 Web 管理界面的端口，装完之后我们可以通过浏览器来可视化管理 RabbitMQ
rabbitmq:3-management：这个镜像已经内置了管理插件，不用我们手动装了

执行完之后，等个几十秒，容器启动成功就好了。

2.2 其他系统的安装方式

如果你不想用 Docker，也可以用系统包管理器安装：

Ubuntu/Debian

# 安装 Erlang 环境（RabbitMQ 是用 Erlang 写的）
sudo apt-get update
sudo apt-get install erlang

# 安装 RabbitMQ
sudo apt-get install rabbitmq-server

# 启动服务
sudo systemctl start rabbitmq-server

# 启用管理插件
sudo rabbitmq-plugins enable rabbitmq_management

CentOS/RHEL

# 添加 yum 源
sudo vim /etc/yum.repos.d/rabbitmq.repo

# 写入以下内容
[rabbitmq_server]
name=rabbitmq_server
baseurl=https://packagecloud.io/rabbitmq/rabbitmq-server/el/7/$basearch
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey

# 安装
sudo yum install -y rabbitmq-server

# 启动服务
sudo systemctl start rabbitmq-server

# 启用管理插件
sudo rabbitmq-plugins enable rabbitmq_management

Windows

直接去官网下载安装包：https://www.rabbitmq.com/download.html 下载完之后一路下一步安装就行，安装完成后服务会自动启动。

2.3 访问 Web 管理界面

不管你用哪种方式安装，装完之后，打开浏览器，访问：

`1`	`http://localhost:15672`

你会看到这样的登录界面：

默认用户名：guest
默认密码：guest

登录进去之后，你就能看到 RabbitMQ 的管理后台了，长这样：

这个后台非常有用，你可以在这里查看队列、交换机、连接数，还能手动发消息、查看消息堆积情况，后面我们跑代码的时候，也可以在这里实时看到消息的流转。

注意：默认的 guest 用户只能从 localhost 访问，如果你的 RabbitMQ 是部署在远程服务器上，需要新建一个管理员用户，我会在后面的最佳实践部分讲。

2.4 Go 客户端安装

RabbitMQ 服务装好了，接下来我们要准备 Go 语言的客户端，用来连接和操作 RabbitMQ。

官方推荐的 Go 客户端是 amqp091-go，这是原来的 streadway/amqp 的官方维护版本，现在已经完全替代了旧的库。

创建一个新的 Go 项目（空项目即可），然后执行下面的命令安装依赖：

# 初始化项目（如果是新项目）
go mod init rabbitmq-demo

# 安装 RabbitMQ 客户端
go get github.com/rabbitmq/amqp091-go

好了，到这里，我们的环境就全部准备好了！接下来我们就可以开始写代码，一个个体验 RabbitMQ 的工作模式了。

三、入门实战：Hello World 简单队列

我们从最简单的 简单队列 模式开始，这是 RabbitMQ 最基础的用法，就像我们平时发消息给一个人，一对一的通信。

3.1 模式说明

简单队列的结构非常简单：

`1`	`生产者 -> 队列 -> 消费者`

生产者把消息发送到一个队列
消费者从这个队列里读取消息
一条消息只能被一个消费者消费一次

这个模式非常适合简单的点对点通信，比如：下单成功后，通知库存服务扣库存。

3.2 编写生产者代码

首先，我们写一个生产者，用来发送消息：

// producer.go
package main

import (
    "log"

    amqp "github.com/rabbitmq/amqp091-go"
)

// 错误处理的辅助函数
func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

func main() {
    // 1. 连接到 RabbitMQ 服务器
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")
    defer conn.Close() // 函数结束时关闭连接

    // 2. 创建一个通道（Channel），所有的操作都是通过通道完成的
    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")
    defer ch.Close()

    // 3. 声明一个队列，队列的名字叫 "hello"
    q, err := ch.QueueDeclare(
        "hello", // 队列名称
        false,   // 是否持久化（重启后队列是否保留）
        false,   // 是否自动删除（没有消费者时自动删除队列）
        false,   // 是否排他（只有当前连接能访问）
        false,   // 是否不等待
        nil,     // 额外参数
    )
    failOnError(err, "无法声明队列")

    // 4. 要发送的消息
    body := "Hello World! 这是我的第一条 RabbitMQ 消息"

    // 5. 发送消息
    err = ch.Publish(
        "",     // 交换机名称，这里用默认的交换机
        q.Name, // 路由键，这里就是队列的名字
        false,  // 是否强制
        false,  // 是否立即
        amqp.Publishing{
            // ContentType 是消息的内容类型，这里我们用 text/plain 表示纯文本
            ContentType: "text/plain", // 消息的内容类型
            Body:        []byte(body), // 消息的内容，转成字节数组
        })
    failOnError(err, "无法发送消息")

    log.Printf(" [x] 已发送消息: %s", body)
}

3.3 编写消费者代码

然后，我们写一个消费者，用来接收消息：

// consumer.go
package main

import (
	"log"

	amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
	if err != nil {
		log.Panicf("%s: %s", msg, err)
	}
}

func main() {
	// 1. 同样的，先连接 RabbitMQ，创建通道
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	failOnError(err, "无法连接到 RabbitMQ")
	defer conn.Close()

	// 2. 创建一个通道（Channel），所有的操作都是通过通道完成的
	ch, err := conn.Channel()
	failOnError(err, "无法创建通道")
	defer ch.Close()

	// 3. 同样声明队列，这里要和生产者的队列名一致
	// 为什么要两边都声明？因为我们不知道生产者和消费者谁先启动
	// 如果队列已经存在，声明操作不会做任何事，只会返回队列的信息；如果队列不存在，声明操作会创建一个新的队列，所以很安全
	q, err := ch.QueueDeclare(
		"hello", // 队列名称
		false,   // 是否持久化（重启后队列是否保留）
		false,   // 是否自动删除（没有消费者时自动删除队列）
		false,   // 是否排他（只有当前连接能访问）
		false,   // 是否不等待
		nil,     // 额外参数
	)
	failOnError(err, "无法声明队列")

	// 4. 注册消费者，监听这个队列的消息
	msgs, err := ch.Consume(
		q.Name, // 要监听的队列名称
		"",     // 消费者名称，空的话服务器会自动生成
		true,   // 是否自动确认（后面会详细讲）
		false,  // 是否排他（只有当前连接能访问）
		false,  // 是否本地
		false,  // 是否不等待
		nil,    // 额外参数
	)
	failOnError(err, "无法注册消费者")

	// 5. 启动一个协程来处理消息
	// 因为接收消息是阻塞的，所以我们要放到协程里，不阻塞主程序
	go func() {
		for d := range msgs {
			// 收到消息了！
			log.Printf(" [x] 收到消息: %s", d.Body)
		}
	}()

	log.Printf(" [*] 等待消息中... 按 CTRL+C 退出")
	// 阻塞主程序，不让它退出
	<-make(chan bool)
}

3.4 运行测试

现在我们来运行一下：

首先打开另一个终端，运行生产者：

`1`	`go run producer.go`

生产者这边会输出： [x] 已发送消息: Hello World! 这是我的第一条 RabbitMQ 消息

在生产者终端看到这个输出，说明消息已经成功发送到 RabbitMQ 了。

同时我们可以在 Web 管理后台的 Queues 标签页里看到 hello 队列，点击进去可以看到消息数量是 1，说明消息已经进入队列了。

在下方的 Get messages 标签页里，我们也能看到这条消息的内容：

再先打开一个终端，运行消费者：

`1`	`go run consumer.go`

你会看到输出： [*] 等待消息中... 按 CTRL+C 退出，说明消费者已经启动，在等消息了。然后会再输出： [x] 收到消息: Hello World! 这是我的第一条 RabbitMQ 消息，说明消费者成功接收到了消息。

我们也可以在 Web 管理后台看到，hello 队列里的消息数量从 1 变成了 0，说明消息已经被消费者取走了。

完美！我们的第一个 RabbitMQ 程序就跑通了！

四、工作队列：任务分发与负载均衡

接下来我们看第二个模式：工作队列（Work Queue）。

4.1 模式说明

工作队列的结构是这样的：

`1`	`生产者 -> 队列 -> 多个消费者`

它的作用是什么呢？当我们有很多耗时的任务要处理时，我们可以启动多个消费者，让它们一起分担这些任务，实现负载均衡。

比如，我们有 10 个图片压缩的任务，启动两个消费者，每个消费者处理 5 个，这样处理速度就快了一倍。

4.2 轮询分发 vs 公平分发

RabbitMQ 默认的分发方式是轮询分发：它会把任务按顺序一个一个分给消费者，不管这个消费者有没有处理完上一个任务。

这就会有个问题：如果有一个任务特别耗时，另一个很快，就会导致一个消费者忙死，另一个闲死。

所以我们一般会用公平分发：告诉 RabbitMQ，一次只给一个消费者发一个任务，等这个消费者处理完了，再给它发下一个。这样就能保证任务会均匀地分给空闲的消费者。

4.3 代码实现

我们来写个例子，模拟任务处理：

生产者：发送任务

// task_producer.go
package main

import (
	"log"
	"strconv"
	"strings"
	"time"

	amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
	if err != nil {
		log.Panicf("%s: %s", msg, err)
	}
}

func main() {
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	failOnError(err, "无法连接到 RabbitMQ")
	defer conn.Close()

	ch, err := conn.Channel()
	failOnError(err, "无法创建通道")
	defer ch.Close()

	// 声明队列，这次我们把队列设为持久化
	q, err := ch.QueueDeclare(
		"task_queue", // 队列名
		true,         // 持久化，RabbitMQ 重启后队列不丢
		false,        // 不自动删除
		false,        // 不排他
		false,        // 不等待
		nil,
	)
	failOnError(err, "无法声明队列")

	// 发送10个任务
	for i := 0; i < 10; i++ {
		// 任务内容，我们用点来表示任务的耗时，一个点代表1秒
		// 比如 "task3 ..." 表示这个任务要处理3秒
		// strconv.Itoa(i)：把整数 i 转换成字符串，这样我们就能看到每个任务的编号了
		// strings.Repeat(".", i/2)：重复 i/2 次点号，这样任务的耗时就会随着 i 的增加而增加
		task := "task" + strconv.Itoa(i) + " " + strings.Repeat(".", i/2)
		err = ch.Publish(
			"",     // 默认交换机
			q.Name, // 路由键
			false,
			false,
			amqp.Publishing{
				// 消息也设为持久化，这样重启后消息不丢
				DeliveryMode: amqp.Persistent,
				ContentType:  "text/plain",
				Body:         []byte(task),
			})
		failOnError(err, "无法发送消息")
		log.Printf(" [x] 发送任务: %s", task)

		time.Sleep(100 * time.Millisecond)
	}
}

消费者：处理任务

// worker.go
package main

import (
	"bytes"
	"log"
	"time"

	amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
	if err != nil {
		log.Panicf("%s: %s", msg, err)
	}
}

func main() {
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	failOnError(err, "无法连接到 RabbitMQ")
	defer conn.Close()

	ch, err := conn.Channel()
	failOnError(err, "无法创建通道")
	defer ch.Close()

	q, err := ch.QueueDeclare(
		"task_queue", true, false, false, false, nil,
	)
	failOnError(err, "无法声明队列")

	// 关键！设置预取计数，开启公平分发
	// Qos 是 Quality of Service 的缩写，意思是服务质量，这个设置告诉 RabbitMQ 在同一时间只给一个消费者分发一个消息，直到这个消费者处理完了并确认了这个消息，RabbitMQ 才会给它分发下一个消息。这样就能实现公平分发了，不会让某个消费者因为处理慢而积压大量消息。
	// 告诉 RabbitMQ，一次只给我一个任务，我处理完了你再给我下一个
	err = ch.Qos(
		1,     // 预取数量
		0,     // 预取大小
		false, // 是否全局
	)
	failOnError(err, "无法设置 Qos")

	// 注册消费者，注意这里我们把自动确认关了，这样我们就可以在处理完消息后手动确认。
	msgs, err := ch.Consume(
		q.Name, "",
		false, // 自动确认设为 false，我们要手动确认
		false, false, false, nil,
	)
	failOnError(err, "无法注册消费者")

	go func() {
		for d := range msgs {
			log.Printf(" [x] 开始处理任务: %s", d.Body)

			// 模拟任务处理，点的数量就是耗时
			t := time.Duration(bytes.Count(d.Body, []byte("."))) * time.Second
			time.Sleep(t)

			log.Printf(" [x] 任务处理完成: %s", d.Body)

			// 手动确认消息，告诉 RabbitMQ：这个消息我处理完了，你可以删了
			d.Ack(false)
		}
	}()

	log.Printf(" [*] 工作进程已启动，等待任务...")
	<-make(chan bool)
}

4.4 运行测试

现在我们来测试一下：

1个工作进程 : 1个生产者先启动工作进程：

`1`	`go run worker.go`

你会看到输出： [*] 工作进程已启动，等待任务...，说明消费者已经启动了。

然后启动生产者：

`1`	`go run task_producer.go`

你会看到，生产者发送了 10 个任务，工作进程一个人吃了 10 个任务，处理完一个才处理下一个。

2个工作进程 : 1个生产者启动两个工作进程，打开两个终端，都运行：

`1`	`go run worker.go`

然后运行生产者：

`1`	`go run task_producer.go`

你会看到，两个工作进程会自动分担这 10 个任务，快的消费者会处理更多的任务，慢的也不会被拖累，这就是公平分发的效果。

这里要重点注意：我们把自动确认关了，用了手动确认。这非常重要！如果消费者处理到一半崩溃了，手动确认的话，RabbitMQ 会把这个任务重新放回队列，交给另一个消费者处理，不会丢消息。

五、发布订阅：广播消息给所有消费者

接下来是 发布 / 订阅（Publish/Subscribe） 模式，这个模式下，一条消息会被发送给所有的消费者，也就是广播。

5.1 模式说明

发布订阅的结构是这样的：

`1`	`生产者 -> 交换机(Fanout) -> 多个队列 -> 多个消费者`

这里我们用到了 Fanout 类型的交换机，这种交换机的作用很简单：它会把收到的所有消息，广播给所有绑定到它的队列，完全不管路由键是什么。

比如，我们做一个日志系统，所有服务的日志都发给这个交换机，然后：

一个消费者把日志存到磁盘
一个消费者把日志打印到屏幕
一个消费者把日志发到监控系统所有消费者都能收到同一条日志消息，互不干扰。

5.2 代码实现

生产者：发送日志

// log_producer.go
package main

import (
	"context"
	"log"
	"strconv"
	"time"

	amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
	if err != nil {
		log.Panicf("%s: %s", msg, err)
	}
}

func main() {
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	failOnError(err, "无法连接到 RabbitMQ")
	defer conn.Close()

	ch, err := conn.Channel()
	failOnError(err, "无法创建通道")
	defer ch.Close()

	// 声明一个 Fanout 类型的交换机
	err = ch.ExchangeDeclare(
		"logs",   // 交换机名称
		"fanout", // 类型：fanout 就是广播
		true,     // 持久化
		false,    // 自动删除
		false,    // 内部
		false,    // 不等待
		nil,
	)
	failOnError(err, "无法声明交换机")

	// 每隔1秒发一条日志
	for i := 0; ; i++ {
		logMsg := "这是一条日志消息，序号: " + strconv.Itoa(i)

		// 发送消息到交换机
		err = ch.PublishWithContext(
			context.Background(),
			"logs", // 交换机名称
			"",     // 路由键，fanout 模式下这个参数会被忽略，随便写什么都行
			false, false,
			amqp.Publishing{
				ContentType: "text/plain",
				Body:        []byte(logMsg),
			})
		failOnError(err, "无法发送消息")
		log.Printf(" [x] 发送日志: %s", logMsg)

		time.Sleep(1 * time.Second)
	}
}

消费者 1：打印日志到屏幕

// log_console.go
package main

import (
	"log"

	amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
	if err != nil {
		log.Panicf("%s: %s", msg, err)
	}
}

func main() {
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	failOnError(err, "无法连接到 RabbitMQ")
	defer conn.Close()

	ch, err := conn.Channel()
	failOnError(err, "无法创建通道")
	defer ch.Close()

	// 同样声明交换机，要和生产者的一致，否则消费者无法接收到消息
	err = ch.ExchangeDeclare("logs", "fanout", true, false, false, false, nil)
	failOnError(err, "无法声明交换机")

	// 而且我们把 exclusive 设为 true，这样消费者断开连接后，队列会自动删除
	q, err := ch.QueueDeclare(
		"log_console_queue", // 队列名
		false,               // 不持久化
		false,               // 不自动删除
		true,                // 排他，连接断了就删
		false,               // 不等待
		nil,
	)
	failOnError(err, "无法声明队列")

	// 把队列绑定到交换机上
	err = ch.QueueBind(
		q.Name, // 队列名
		"",     // 路由键，fanout 模式下忽略
		"logs", // 交换机名
		false,
		nil,
	)
	failOnError(err, "无法绑定队列")

	// 消费消息
	msgs, err := ch.Consume(q.Name, "", true, false, false, false, nil)
	failOnError(err, "无法注册消费者")

	go func() {
		for d := range msgs {
			log.Printf(" [控制台消费者] 收到日志: %s", d.Body)
		}
	}()

	log.Println(" [*] 控制台日志消费者已启动")
	<-make(chan bool)
}

消费者 2：把日志存到文件

// log_file.go
package main

import (
	"log"
	"os"

	amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
	if err != nil {
		log.Panicf("%s: %s", msg, err)
	}
}

func main() {
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	failOnError(err, "无法连接到 RabbitMQ")
	defer conn.Close()

	ch, err := conn.Channel()
	failOnError(err, "无法创建通道")
	defer ch.Close()

	err = ch.ExchangeDeclare("logs", "fanout", true, false, false, false, nil)
	failOnError(err, "无法声明交换机")

	q, err := ch.QueueDeclare("log_file_queue", false, false, true, false, nil)
	failOnError(err, "无法声明队列")

	err = ch.QueueBind(q.Name, "", "logs", false, nil)
	failOnError(err, "无法绑定队列")

	// 打开文件，准备写日志
	f, err := os.OpenFile("app.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()

	msgs, err := ch.Consume(q.Name, "", true, false, false, false, nil)
	failOnError(err, "无法注册消费者")

	go func() {
		for d := range msgs {
			logMsg := string(d.Body)
			log.Printf(" [文件消费者] 保存日志到文件: %s", logMsg)
			// 写入文件
			f.WriteString(logMsg + "\n")
			f.Sync()
		}
	}()

	log.Println(" [*] 文件日志消费者已启动")
	<-make(chan bool)
}

5.3 运行测试

现在运行一下:

先启动控制台消费者：

`1`	`go run log_console.go`

再启动文件消费者：

`1`	`go run log_file.go`

最后启动生产者：

`1`	`go run log_producer.go`

你会发现，两个消费者都能收到所有的日志消息！生产者发一条，两个消费者各收到一条，完美实现了广播的效果。

六、路由模式：精准定向分发消息

接下来是路由模式（Routing），这个模式下，我们可以根据消息的类型，把消息发给指定的消费者。

6.1 模式说明

路由模式用的是 Direct 类型的交换机，这种交换机会根据路由键的精确匹配来转发消息。

比如，我们还是做日志系统，这次我们想：

error 级别的日志，存到磁盘，用来排查问题
info、warning 级别的日志，只打印到屏幕

那我们就可以：

生产者发消息时，给 error 日志的路由键设为 error，info 的设为 info，warning 的设为 warning
存磁盘的消费者，只绑定 error 这个路由键
打印屏幕的消费者，绑定 info 和 warning 两个路由键

这样，error 日志两个消费者都能收到，info 日志只有屏幕消费者能收到，非常灵活。

6.2 代码实现

生产者：按级别发日志

// routing_producer.go
package main

import (
    "context"
    "log"
    "time"

    amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

func main() {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")
    defer conn.Close()

    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")
    defer ch.Close()

    // 声明 Direct 类型的交换机
    err = ch.ExchangeDeclare(
        "logs_direct", // 交换机名
        "direct",      // 类型：direct
        true, false, false, false, nil,
    )
    failOnError(err, "无法声明交换机")

    // 模拟发不同级别的日志
    logs := []struct {
        level   string
        message string
    }{
        {"info", "这是一条普通的信息日志"},
        {"warning", "这是一条警告日志"},
        {"error", "这是一条错误日志！系统出问题了"},
    }

    for _, l := range logs {
        err = ch.PublishWithContext(
            context.Background(),
            "logs_direct", // 交换机
            l.level,       // 路由键，就是日志级别
            false, false,
            amqp.Publishing{
                ContentType: "text/plain",
                Body:        []byte(l.message),
            })
        failOnError(err, "无法发送消息")
        log.Printf(" [x] 发送[%s]日志: %s", l.level, l.message)

        time.Sleep(500 * time.Millisecond)
    }
}

消费者 1：只接收 error 日志，存到磁盘

// error_consumer.go
package main

import (
    "log"
    "os"

    amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

func main() {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")
    defer conn.Close()

    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")
    defer ch.Close()

    err = ch.ExchangeDeclare("logs_direct", "direct", true, false, false, false, nil)
    failOnError(err, "无法声明交换机")

    q, err := ch.QueueDeclare("", false, false, true, false, nil)
    failOnError(err, "无法声明队列")

    // 只绑定 error 路由键
    err = ch.QueueBind(q.Name, "error", "logs_direct", false, nil)
    failOnError(err, "无法绑定队列")

    f, err := os.OpenFile("error.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
    if err != nil {
        log.Fatal(err)
    }
    defer f.Close()

    msgs, err := ch.Consume(q.Name, "", true, false, false, false, nil)
    failOnError(err, "无法注册消费者")

    go func() {
        for d := range msgs {
            logMsg := string(d.Body)
            log.Printf(" [Error消费者] 保存错误日志: %s", logMsg)
            f.WriteString(logMsg + "\n")
            f.Sync()
        }
    }()

    log.Println(" [*] Error 消费者已启动，只处理 error 日志")
    <-make(chan bool)
}

消费者 2：接收所有日志，打印到屏幕

// all_log_consumer.go
package main

import (
    "log"

    amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

func main() {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")
    defer conn.Close()

    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")
    defer ch.Close()

    err = ch.ExchangeDeclare("logs_direct", "direct", true, false, false, false, nil)
    failOnError(err, "无法声明交换机")

    q, err := ch.QueueDeclare("", false, false, true, false, nil)
    failOnError(err, "无法声明队列")

    // 绑定 info 路由键
    err = ch.QueueBind(q.Name, "info", "logs_direct", false, nil)
    failOnError(err, "无法绑定队列")
    // 绑定 warning 路由键
    err = ch.QueueBind(q.Name, "warning", "logs_direct", false, nil)
    failOnError(err, "无法绑定队列")
    // 绑定 error 路由键
    err = ch.QueueBind(q.Name, "error", "logs_direct", false, nil)
    failOnError(err, "无法绑定队列")

    msgs, err := ch.Consume(q.Name, "", true, false, false, false, nil)
    failOnError(err, "无法注册消费者")

    go func() {
        for d := range msgs {
            log.Printf(" [控制台消费者] 收到日志: %s", d.Body)
        }
    }()

    log.Println(" [*] 控制台消费者已启动，处理所有级别日志")
    <-make(chan bool)
}

6.3 运行测试

运行一下：

启动 error 消费者：

`1`	`go run error_consumer.go`

启动控制台消费者：

`1`	`go run all_log_consumer.go`

启动生产者：

`1`	`go run routing_producer.go`

你会看到：

error 日志，两个消费者都收到了
info 和 warning 日志，只有控制台消费者收到了

完美！这就是精准路由的效果。

七、主题模式：通配符灵活路由

接下来是最灵活的主题模式（Topic），这个模式下，路由键支持通配符，我们可以做更复杂的消息过滤。

7.1 模式说明

主题模式用的是 Topic 类型的交换机，它和 Direct 很像，但是它的路由键匹配支持通配符：

*：匹配一个单词
#：匹配零个或多个单词

这里的单词，是用点 . 分隔的。

比如，我们的路由键可以是 order.create、order.update、user.register 这种格式，然后：

order.*：可以匹配 order.create、order.update，但是匹配不了 user.register
#：可以匹配所有的路由键
*.create：可以匹配 order.create、user.create

这个模式非常适合多层级的消息路由，比如我们要按模块、按操作类型来过滤消息。

7.2 代码实现

我们来做一个订单和用户的消息通知系统：

生产者：发送不同类型的消息

// topic_producer.go
package main

import (
	"context"
	"log"
	"time"

	amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
	if err != nil {
		log.Panicf("%s: %s", msg, err)
	}
}

func main() {
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	failOnError(err, "无法连接到 RabbitMQ")
	defer conn.Close()

	ch, err := conn.Channel()
	failOnError(err, "无法创建通道")
	defer ch.Close()

	// 声明 Topic 类型的交换机
	err = ch.ExchangeDeclare(
		"events_topic", // 交换机名
		"topic",        // 类型：topic
		true, false, false, false, nil,
	)
	failOnError(err, "无法声明交换机")

	// 模拟发送不同的事件
	events := []struct {
		routingKey string
		message    string
	}{
		{"order.create", "用户创建了新订单"},
		{"order.update", "订单状态更新了"},
		{"user.register", "新用户注册了"},
		{"user.login", "用户登录了"},
	}

	for _, e := range events {
		// Publish只能发送消息到交换机，路由键由我们指定，消费者根据路由键来决定是否接收消息
		// 而PublishWithContext可以指定上下文，支持超时等功能
		err = ch.PublishWithContext(
			context.Background(), // 上下文：这里使用背景上下文，表示没有特定的超时或取消条件
			"events_topic",       // 交换机名
			e.routingKey,         // 路由键，消费者根据这个键来决定是否接收消息
			false, false,
			amqp.Publishing{
				ContentType: "text/plain",
				Body:        []byte(e.message),
			})
		failOnError(err, "无法发送消息")
		log.Printf(" [x] 发送事件[%s]: %s", e.routingKey, e.message)

		time.Sleep(500 * time.Millisecond)
	}
}

消费者 1：只关心订单相关的事件

// order_consumer.go
package main

import (
    "log"

    amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

func main() {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")
    defer conn.Close()

    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")
    defer ch.Close()

    err = ch.ExchangeDeclare("events_topic", "topic", true, false, false, false, nil)
    failOnError(err, "无法声明交换机")

    q, err := ch.QueueDeclare("", false, false, true, false, nil)
    failOnError(err, "无法声明队列")

    // 绑定 order.*，匹配所有 order 开头的事件
    err = ch.QueueBind(q.Name, "order.*", "events_topic", false, nil)
    failOnError(err, "无法绑定队列")

    msgs, err := ch.Consume(q.Name, "", true, false, false, false, nil)
    failOnError(err, "无法注册消费者")

    go func() {
        for d := range msgs {
            log.Printf(" [订单服务] 收到事件: %s", d.Body)
        }
    }()

    log.Println(" [*] 订单服务消费者已启动，只处理订单相关事件")
    <-make(chan bool)
}

消费者 2：关心所有的事件

// all_event_consumer.go
package main

import (
    "log"

    amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

func main() {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")
    defer conn.Close()

    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")
    defer ch.Close()

    err = ch.ExchangeDeclare("events_topic", "topic", true, false, false, false, nil)
    failOnError(err, "无法声明交换机")

    q, err := ch.QueueDeclare("", false, false, true, false, nil)
    failOnError(err, "无法声明队列")

    // 绑定 #，匹配所有的事件
    err = ch.QueueBind(q.Name, "#", "events_topic", false, nil)
    failOnError(err, "无法绑定队列")

    msgs, err := ch.Consume(q.Name, "", true, false, false, false, nil)
    failOnError(err, "无法注册消费者")

    go func() {
        for d := range msgs {
            log.Printf(" [监控服务] 收到所有事件: %s", d.Body)
        }
    }()

    log.Println(" [*] 监控服务消费者已启动，处理所有事件")
    <-make(chan bool)
}

7.3 运行测试

运行一下：

启动订单消费者：

`1`	`go run order_consumer.go`

启动监控消费者：

`1`	`go run all_event_consumer.go`

启动生产者：

`1`	`go run topic_producer.go`

你会看到：

订单相关的两个事件，两个消费者都收到了
用户相关的两个事件，只有监控消费者收到了

这就是主题模式的灵活之处，你可以用通配符很方便地做各种消息过滤。

八、RPC 模式：同步远程调用

前面的模式都是异步的，但是有时候我们需要同步的调用：我发一个请求，然后等你给我返回结果，这就是 RPC（远程过程调用）模式。

8.1 模式说明

RPC 模式的流程是这样的：

客户端发送一个请求消息，同时指定两个东西：
- reply_to：告诉服务端，处理完结果要把响应发到哪个队列
- correlation_id：请求的唯一 ID，用来区分不同的请求
服务端收到请求，处理，然后把响应发到 reply_to 指定的队列，并且带上 correlation_id
客户端监听响应队列，根据 correlation_id 找到对应的响应

这样就实现了同步的远程调用。

8.2 代码实现

我们来实现一个计算斐波那契数的 RPC 服务：

RPC 服务端

// rpc_server.go
package main

import (
    "log"
    "strconv"

    amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

// 计算斐波那契数
func fib(n int) int {
    if n == 0 {
        return 0
    }
    if n == 1 {
        return 1
    }
    return fib(n-1) + fib(n-2)
}

func main() {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")
    defer conn.Close()

    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")
    defer ch.Close()

    // 声明 RPC 请求队列
    q, err := ch.QueueDeclare(
        "rpc_queue", // 请求队列名
        false, false, false, false, nil,
    )
    failOnError(err, "无法声明队列")

    // 设置 Qos，保证公平分发
    err = ch.Qos(1, 0, false)
    failOnError(err, "无法设置 Qos")

    msgs, err := ch.Consume(
        q.Name, "", false, false, false, false, nil,
    )
    failOnError(err, "无法注册消费者")

    log.Println(" [*] RPC 服务已启动，等待请求...")

    for d := range msgs {
        // 解析请求参数
        n, err := strconv.Atoi(string(d.Body))
        if err != nil {
            log.Printf("无效的参数: %s", d.Body)
            d.Ack(false)
            continue
        }

        log.Printf(" [.] 计算 fib(%d)", n)
        // 计算结果
        response := fib(n)

        // 把响应发回给客户端
        err = ch.Publish(
            "", // 默认交换机
            d.ReplyTo, // 客户端指定的响应队列
            false, false,
            amqp.Publishing{
                ContentType:   "text/plain",
                CorrelationId: d.CorrelationId, // 带上请求的ID
                Body:          []byte(strconv.Itoa(response)),
            })
        failOnError(err, "无法发送响应")

        // 确认请求消息
        d.Ack(false)
    }
}

RPC 客户端

// rpc_client.go
package main

import (
    "log"
    "math/rand"
    "strconv"
    "time"

    amqp "github.com/rabbitmq/amqp091-go"
)

func failOnError(err error, msg string) {
    if err != nil {
        log.Panicf("%s: %s", msg, err)
    }
}

type RPCClient struct {
    conn         *amqp.Connection
    channel      *amqp.Channel
    callbackQueue amqp.Queue
    corrID       string
    responses    map[string]chan string
}

func NewRPCClient() *RPCClient {
    conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
    failOnError(err, "无法连接到 RabbitMQ")

    ch, err := conn.Channel()
    failOnError(err, "无法创建通道")

    // 声明回调队列，用来接收响应
    callbackQueue, err := ch.QueueDeclare(
        "", false, false, true, false, nil,
    )
    failOnError(err, "无法声明回调队列")

    // 监听回调队列
    msgs, err := ch.Consume(
        callbackQueue.Name, "", true, false, false, false, nil,
    )
    failOnError(err, "无法注册消费者")

    client := &RPCClient{
        conn:         conn,
        channel:      ch,
        callbackQueue: callbackQueue,
        responses:    make(map[string]chan string),
    }

    // 后台协程处理响应
    go client.handleResponses(msgs)

    return client
}

func (c *RPCClient) handleResponses(msgs <-chan amqp.Delivery) {
    for d := range msgs {
        // 根据 correlationId 找到对应的响应通道
        corrId := d.CorrelationId
        if ch, ok := c.responses[corrId]; ok {
            ch <- string(d.Body)
        }
    }
}

func (c *RPCClient) Call(n int) (string, error) {
    // 生成唯一的 correlationId
    c.corrID = strconv.Itoa(rand.Intn(999999))
    ch := make(chan string)
    c.responses[c.corrID] = ch

    // 发送请求
    err := c.channel.Publish(
        "", "rpc_queue", false, false,
        amqp.Publishing{
            ContentType:   "text/plain",
            CorrelationId: c.corrID,
            ReplyTo:       c.callbackQueue.Name, // 告诉服务端响应发到哪
            Body:          []byte(strconv.Itoa(n)),
        })
    failOnError(err, "无法发送请求")

    // 等待响应
    response := <-ch
    delete(c.responses, c.corrID)
    return response, nil
}

func (c *RPCClient) Close() {
    c.conn.Close()
}

func main() {
    client := NewRPCClient()
    defer client.Close()

    // 调用 RPC，计算 fib(30)
    log.Println(" [x] 请求 fib(30)")
    res, err := client.Call(30)
    failOnError(err, "RPC 调用失败")

    log.Printf(" [.] 结果: %s", res)
}

8.3 运行测试

运行一下：

先启动服务端：

`1`	`go run rpc_server.go`

然后启动客户端：

`1`	`go run rpc_client.go`

客户端会输出：

1
2

[x] 请求 fib(30)
[.] 结果: 832040

我们就实现了一个基于 RabbitMQ 的 RPC 调用。

可以单独运行 rpc_client.go ，然后去 Web 管理界面查看 rpc_queue 队列，你会看到客户端发出的请求消息，服务端处理完后，消息就会从队列里消失。

九、生产环境必备：高级特性

到这里，RabbitMQ 的核心工作模式我们就都讲完了，接下来我们讲几个生产环境必须要掌握的高级特性。

9.1 消息确认机制（ACK）

前面我们已经提到过，消息确认机制是保证消息不丢失的关键。

当你把 autoAck 设为 true 时，RabbitMQ 把消息发出去之后，就立刻把消息删了，不管消费者有没有处理完。如果消费者刚收到消息，还没处理就崩溃了，那这个消息就丢了。

而当你把 autoAck 设为 false 时，RabbitMQ 会等消费者手动调用 d.Ack() 之后，才会把消息删掉。如果消费者崩溃了，RabbitMQ 会把这个消息重新放回队列，发给其他消费者，保证消息不会丢。

除了 Ack，还有两个方法：

d.Nack(false, true)：拒绝这个消息，并且让它重新入队，用来重试
d.Nack(false, false)：拒绝这个消息，并且直接丢弃，用来处理坏消息

9.2 消息持久化

持久化是为了保证 RabbitMQ 重启之后，消息不会丢。要实现完整的持久化，你需要同时设置三个地方：

队列的 durable 参数设为 true：这样 RabbitMQ 重启后，队列不会丢
消息的 DeliveryMode 设为 amqp.Persistent：这样消息会被存到磁盘，重启后不会丢
交换机的 durable 参数设为 true：这样交换机重启后不会丢

注意：这三个要同时设置，缺一不可！不然还是会丢消息。

9.3 发布确认（Publisher Confirm）

前面的 ACK 是消费者给 RabbitMQ 的确认，那生产者怎么知道消息真的被 RabbitMQ 收到了呢？这就需要发布确认机制。

开启发布确认后，RabbitMQ 收到消息后，会给生产者发一个确认，告诉生产者：我收到了。如果没收到，生产者就可以重试。

代码示例：

// 开启发布确认
err = ch.Confirm(false)
failOnError(err, "无法开启确认")

// 创建一个通道来接收确认
confirms := ch.NotifyPublish(make(chan amqp.Confirmation, 1))

go func() {
    for confirm := range confirms {
        if confirm.Ack {
            log.Printf("消息 %d 已被服务器确认", confirm.DeliveryTag)
        } else {
            log.Printf("消息 %d 被服务器拒绝了", confirm.DeliveryTag)
            // 重试发送
        }
    }
}()

9.4 死信队列（DLQ）

死信队列，就是用来存放那些死掉的消息的队列。什么是死信？就是：

消息被消费者拒绝了，并且没有重新入队
消息过期了（TTL 到了）
队列满了，消息放不下了

这些消息不会直接被扔掉，而是会被转发到死信交换机，然后存到死信队列里，我们可以后续排查问题，或者重试处理。

最常见的用法就是用死信队列实现延迟消息：比如我们要做订单超时关闭，下单后 30 分钟没支付，就自动关闭订单。

我们可以这样做：

声明一个普通队列，设置它的 TTL 是 30 分钟，并且设置死信交换机
下单的时候，把消息发到这个队列
30 分钟后，消息过期了，就会被转发到死信队列
我们的消费者监听死信队列，收到消息后，就去检查订单状态，如果没支付就关闭

代码示例：

// 声明死信交换机
err = ch.ExchangeDeclare("dlx_exchange", "direct", true, false, false, false, nil)
failOnError(err, "无法声明死信交换机")

// 声明死信队列
dlq, err := ch.QueueDeclare("dlq_queue", true, false, false, false, nil)
failOnError(err, "无法声明死信队列")

// 绑定死信队列到死信交换机
err = ch.QueueBind(dlq.Name, "order_timeout", "dlx_exchange", false, nil)
failOnError(err, "无法绑定死信队列")

// 声明延迟队列，设置 TTL 和死信交换机
args := amqp.Table{
    "x-message-ttl":             30 * 60 * 1000, // 30分钟，单位毫秒
    "x-dead-letter-exchange":    "dlx_exchange",  // 死信交换机
    "x-dead-letter-routing-key": "order_timeout", // 死信路由键
}
delayQueue, err := ch.QueueDeclare("delay_queue", true, false, false, false, args)
failOnError(err, "无法声明延迟队列")

这样，我们把订单消息发到 delay_queue，30 分钟后，它就会自动跑到 dlq_queue 里，我们的消费者就可以处理了。

十、最佳实践与常见问题

最后，给你一些生产环境的最佳实践：

10.1 用户权限管理

默认的 guest 用户只能本地访问，生产环境一定要新建用户，不要用默认的：

# 添加用户
rabbitmqctl add_user myuser mypassword

# 设置用户为管理员
rabbitmqctl set_user_tags myuser administrator

# 给用户授权
rabbitmqctl set_permissions -p / myuser ".*" ".*" ".*"

10.2 连接与重连

RabbitMQ 的连接是会断的，网络抖动、服务重启都会导致连接断开，所以实际开发时，你的客户端一定要有重连机制，不要断了就直接挂了。

可以把连接的代码放在一个循环里，连接失败了就等几秒钟再重试：

for {
    conn, err := amqp.Dial("amqp://myuser:mypassword@localhost:5672/")
    if err != nil {
        log.Printf("连接失败，5秒后重试: %s", err)
        time.Sleep(5 * time.Second)
        continue
    }
    // 连接成功，继续后续操作
    break
}

如果连接后发生网络抖动，导致连接断开了，也要监听连接的 NotifyClose 通道，及时重连：

conn, err := amqp.Dial("amqp://myuser:mypassword@localhost:5672/")
failOnError(err, "无法连接到 RabbitMQ")

// 监听连接关闭事件
notifyClose := conn.NotifyClose(make(chan *amqp.Error, 1))

go func() {
    err := <-notifyClose
    log.Printf("连接关闭: %s", err)
    // 重连逻辑
    for {
        conn, err = amqp.Dial("amqp://myuser:mypassword@localhost:5672/")
        if err != nil {
            log.Printf("重连失败，5秒后重试: %s", err)
            time.Sleep(5 * time.Second)
            continue
        }
        log.Println("重连成功")
        break
    }
}()

10.3 幂等性消费

网络问题可能会导致消息重复投递，所以你的消费端一定要保证幂等性：就是同一个消息，消费多少次，结果都是一样的。

常见的做法：

用消息的唯一 ID，存到 Redis，消费之前先查一下有没有处理过
数据库的唯一索引，防止重复插入
业务状态机，比如订单状态，只有待支付的才能处理超时，已经支付的就忽略

10.4 监控

一定要开启监控，监控队列的堆积情况、连接数、消息速率，有问题及时报警。RabbitMQ 的管理后台已经提供了很多指标，你也可以用 Prometheus 来采集。

总结

恭喜你！看完这份教程，你已经掌握了 RabbitMQ 的核心用法了！

我们从最基础的概念开始，一步步学会了：

RabbitMQ 的核心组件和消息流转
6 种核心工作模式：简单队列、工作队列、发布订阅、路由、主题、RPC
生产环境必备的高级特性：ACK、持久化、死信队列
各种场景下的 Go 代码实现

RabbitMQ 是一个非常强大的工具，掌握了它，你就能在分布式系统中轻松实现异步通信、解耦、削峰这些功能。

接下来，你可以自己动手把这些代码跑一遍，加深理解，然后就可以在你的项目中使用它了！