1. 先搞清楚 RabbitMQ 在系统里站的位置

第一次在生产环境看到 RabbitMQ 的队列堆积曲线一路飙到六位数，是一个大促前夜的压测现场。当时下单接口的响应时间从 200ms 涨到 3 秒，排查到最后发现不是数据库慢，而是下游的发券服务处理不过来，把整个调用链拖死了。那次之后我把 RabbitMQ 从“知道怎么发消息”重新学了一遍，因为真正难的不是写一个basicPublish，而是搞清楚消息在哪个环节可能丢、在哪个环节可能重复、在哪个环节会把上游拖垮。这篇内容就是把这几年踩过的坑、算过的参数、定过的规范整理一遍，面向的是已经用过消息队列但还没真正吃透 RabbitMQ 的同学，也照顾刚接触 AMQP 模型的新手，尽量把每个结论的来龙去脉讲清楚。

1.1 一次订单超时引发的架构反思

那次的调用链很典型：用户下单 → 订单服务写库 → 同步调用发券服务 → 同步调用积分服务 → 同步调用 Push 服务。五个服务串在一条链路上，任何一个慢，用户就得一直转圈。最要命的是发券服务依赖第三方接口，对方偶发 800ms 的抖动，直接把订单接口的 P99 拉到不可接受的水平。当时的临时方案是把发券和积分改成异步，用线程池丢后台跑，结果服务重启时丢了一批券，用户投诉电话打爆了客服。

问题出在“用线程池做异步”这件事本身：线程池没有持久化能力，进程一挂任务就没了；线程池没有重试能力，失败了只能打日志；线程池没有削峰能力，突发流量直接打穿下游。这三个缺口刚好就是消息队列最擅长补的位置。后来我们引入 RabbitMQ，把发券、积分、Push 全部改成发消息驱动，订单接口的 P99 立刻回到 200ms 以内，而且消息落在 Broker 的磁盘上，服务重启后消费者重新上线就能继续消费，一张券都不会少。

我想强调的是，选型这件事不是“有个队列就行”。当时对比过几种方案，最终选 RabbitMQ 的理由很实在：它对消息路由的支持最灵活，一个交换机可以按路由键精确分发、按通配符模糊分发、按消息头匹配分发，业务上“不同等级的订单走不同队列”这种需求写几行配置就搞定；它的管理台开箱即用，队列堆积、消费速率、连接数、通道数全部图形化，排查问题时省大量时间；它的协议成熟，Java、Python、Go、PHP 的客户端都很稳，团队里不同技术栈的服务都能接。至于吞吐，RabbitMQ 单机万级到数万级的量级对绝大多数业务系统完全够用，真到了十万级 QPS 的消息场景，那本来就是另一类架构该考虑的事。

这里补充一句基于常见实践的判断：如果你面对的是日志采集、埋点上报这类吞吐极高但允许丢少量数据的场景，RabbitMQ 不是最优解，专门做日志管道的组件会更合适；但如果你面对的是订单、支付、库存这类一条都不能丢、且需要复杂路由的业务消息，RabbitMQ 的可靠性和灵活性优势就非常明显。选型的第一步永远是先回答“我的消息能不能丢”，而不是“谁的基准测试数字更高”。

1.2 消息队列解决的四个真实问题

很多资料把消息队列的作用讲得很玄，其实落到工程上就四件事，我用我们系统的实际例子说。

解耦。订单服务在下单后需要通知发券、积分、Push、风控、数据仓库五个下游。如果同步调用，每新增一个下游就要改一次订单服务的代码，重新发布上线。改成发一条消息之后，订单服务只认交换机和路由键，下游谁要订阅谁自己建队列绑定，订单服务一行代码都不用动。我们后来加了“会员等级成长值”的服务，从接入到上线只花了半天，完全没碰订单服务。

异步。用户点下单，真正必须同步完成的只有“扣库存 + 写订单”这两步，其余全部可以后台做。把非核心链路异步化之后，接口响应时间取决于最慢的同步步骤，而不是所有步骤之和。这一条带来的用户体验提升是最直接的，也是最容易被忽视的。

削峰。秒杀场景下瞬时流量可能是平时的一百倍，但下游服务的处理能力是恒定的。消息队列在这里充当一个巨大的缓冲区，峰值流量先写进队列，消费者按自己的能力匀速取，队列长度就是“还没处理完的请求量”，这个数字比任何压测报告都真实。我们做过测算，一次持续 30 秒的峰值大概产生 12 万条消息，消费者单条处理耗时 50ms，8 个并发消费者，消化完需要 120000 × 50 / 8 / 1000 = 750 秒，也就是十二分半钟。这个数字提前算出来，才能决定是加消费者还是做限流。

最终一致性。跨服务的分布式事务是另一个大话题，但 RabbitMQ 在这里的角色很清晰：本地事务和消息发送绑定，下游消费失败就重试，重试到成功为止。它保证的是最终一致，不是强一致，这个预期必须先跟业务方对齐，否则后面一定会扯皮。

1.3 什么场景不该用 RabbitMQ

这一节可能比前面更有价值。我见过太多团队把消息队列当万能药，结果引入了一堆新问题。

第一种不该用的场景是“调用方需要立即拿到返回值”。消息队列天然是单向的，你发出去就不管了，想要结果还得再搞一个回调队列，复杂度翻倍。如果一个操作用同步 RPC 就能在 100ms 内完成，而且失败后调用方需要立刻知道，那就老老实实用同步调用。

第二种是“消息量极小且可靠性要求极高”。比如一天只有几十条的配置变更通知，为了它维护一套 Broker 集群、监控、告警、值班，运维成本远超收益。这种场景用数据库轮询或者配置中心推送更划算。

第三种是“团队没有消费失败的处理能力”。消息队列把同步调用变成了异步，代价是失败处理变复杂了：失败了怎么办、重试几次、重试还失败进哪里、进了死信队列谁来处理、处理完怎么补偿。这些问题没有标准答案，必须结合业务定。如果团队连一个像样的重试和补偿机制都没设计，上线后一定会出现“消息丢了没人知道”或者“消息重复消费导致重复扣款”的事故。

一个简单的判断标准：如果你的业务能接受“消息延迟几秒到达”，并且你能说清楚“消息最终没处理成功时人工怎么兜底”，那就可以用；这两条有一条答不上来，先别急着上。

2. 核心模型：把 AMQP 那套骨架吃透

RabbitMQ 的概念不多，但每一个都有明确的职责边界，混着用就会出问题。我见过把 Connection 当 Channel 用的代码，一个请求建一个连接，压测时服务端直接拒绝新连接，报错信息还特别隐晦。这一章把模型从大到小捋一遍，每个概念都配上“为什么这么设计”的解释。

2.1 Connection 与 Channel 的复用逻辑

Connection 是客户端到 Broker 的 TCP 连接，Channel 是连接之上的逻辑通道。为什么要有 Channel 这一层？因为 TCP 连接的建立成本很高，三次握手加上 AMQP 协议握手，一次完整的连接建立大概要几毫秒到几十毫秒，高并发下这个开销完全不可接受。而 Channel 是纯逻辑的，创建和销毁几乎零成本，所以标准做法是：一个应用进程维护少量长连接，每个线程或每个业务复用一条 Channel，或者干脆用一个 Channel 池。

这里有个关键约束必须记住：Channel 不是线程安全的。多个线程往同一条 Channel 上并发发布消息，会出现消息交错、帧错乱，严重时直接断连。我们在早期代码里就犯过这个错，压测时偶发Unexpected frame报错，排查了两天才定位到是共享 Channel 导致的。正确做法有两种：一是每个线程持有独立的 Channel，二是用 ThreadLocal 绑定 Channel，三是在高并发场景下用 Channel 池，取用归还。第一种最简单，也最不容易出错。

还有一个容易忽略的点是连接的心跳。默认心跳间隔 60 秒，如果客户端因为长时间 GC 或者网络抖动没能及时响应心跳，Broker 会主动断开连接。这个机制本身是好的，能及时清理僵尸连接，但如果你的服务有大对象导致 Full GC 超过 60 秒，就会频繁断连重连，日志里一堆connection closed。这种情况要么调大心跳间隔，要么去治 GC，不要靠关闭心跳来掩盖问题。

2.2 Exchange / Queue / Binding 的三角关系

生产者从来不直接把消息发给队列，这一点是 RabbitMQ 和很多同类产品最大的区别。生产者只认交换机，交换机根据绑定规则把消息投递到一个或多个队列。这条链路是：生产者 → Exchange →（Binding）→ Queue → 消费者。

Exchange 本身不存储消息，它只是一个路由器。如果一条消息到了 Exchange 之后找不到任何匹配的 Binding，默认行为是直接丢弃，生产者完全无感知。这是新手最常踩的坑：代码跑通了，日志没报错，消费者就是收不到消息。排查的第一步永远是去管理台看这个 Exchange 上到底有几个 Binding，路由键写对没有。

Queue 才是真正存消息的地方，它有几个属性必须在上线前想清楚：是否持久化、是否排他、是否自动删除、最大长度、最大优先级、死信交换机。持久化的队列在 Broker 重启后依然存在，非持久化的队列重启就没了。排他队列只对声明它的连接可见，连接断开自动删除，一般只用于临时场景。自动删除队列在最后一个消费者断开后删除，用的时候要非常小心，消费者短暂掉线就可能把队列删掉，消息全丢。

Binding 是连接 Exchange 和 Queue 的规则，可以带路由键，也可以带参数。一个队列可以绑定多个交换机，一个交换机也可以绑定多个队列，这是多对多关系。实际项目里我们通常按业务域划分交换机，比如订单域一个、营销域一个，然后按消息类型划分路由键，比如order.created、order.paid、order.cancelled，队列按消费方划分，一个消费方一个队列。这样下游要新增消费者，只需要自己声明队列并绑定到对应路由键，上游完全不用改。

2.3 四种交换机类型的适用边界

四种交换机类型各有明确的使用场景，选错了会导致路由逻辑变得极其别扭。

我的经验是：能用 direct 就别用 topic，能用 topic 就别用 headers。原因很朴素，路由规则越复杂，出问题时越难排查。曾经有一个项目用 headers 交换机按“地区 + 渠道 + 会员等级”三个维度路由，后来要加一个维度，发现已有的绑定关系有几十条，改一条要验证一整片，最后整个重构成了 direct 加多队列的方案。

fanout 有一个隐藏的坑：如果绑定了十个队列，一条消息就会被复制十份。队列本身不持久化还好，如果十个队列全是持久化队列，一条消息要写十次磁盘，吞吐直接掉一个数量级。所以 fanout 只适合“订阅方少且消息量不大”的广播场景。

topic 的匹配规则值得单独说一下：*匹配一个单词，#匹配零个或多个单词，单词之间用点分隔。比如order.*.paid能匹配order.vip.paid和order.normal.paid，但匹配不了order.vip.level.paid。写成order.#.paid就都能匹配。规则本身不难，难的是团队里每个人写的路由键风格不统一，最后变成一团乱麻。我们后来的规范是路由键必须三段式：域.对象.动作，谁违反谁改。

2.4 队列参数里那几个容易踩坑的开关

队列声明的时候有一堆参数，其中几个如果设置不当，后果是灾难性的。

x-max-length控制队列最大长度，超过之后默认从队头开始丢弃消息。这个默认行为非常危险，等于静默丢数据。正确的做法是配合x-overflow参数设成reject-publish，队列满了之后拒绝新消息，让生产者感知到背压，而不是悄悄把老消息扔掉。我们线上所有业务队列都强制要求设置这两个参数，最大长度按“消费者一小时的处理量”来估，超过就说明消费能力出问题了，应该告警而不是丢消息。

x-message-ttl控制消息存活时间，超时后消息会被丢弃或者进入死信队列。这个参数常被用来做延迟任务的兜底，但如果只设了 TTL 没设死信交换机，超时的消息就是直接消失，不会留下任何痕迹，排查起来非常痛苦。

x-dead-letter-exchange是死信交换机，消息变成死信之后会被转发到这里。什么情况算死信？三种：消费者手动拒绝且不重新入队、消息 TTL 过期、队列超长被丢弃。这个机制是可靠性设计的关键一环，后面会专门展开。

还有一个特别隐蔽的坑是队列参数的不一致。如果队列已经存在，消费者用不同的参数再去声明同名队列，RabbitMQ 会直接报错并关闭通道，错误码是PRECONDITION_FAILED。这个错在本地开发环境经常遇到，因为本地可能残留了旧的队列定义。处理方式要么去管理台把旧队列删掉，要么改队列名。生产环境更要注意，任何参数变更都必须走“新建队列 + 迁移消费者 + 删旧队列”的流程，不能直接改代码声明参数。

3. 从零跑通第一个 Demo

概念讲完必须落到能跑起来的代码上，否则都是纸上谈兵。这一章用一个完整的例子把生产者、消费者、管理台串起来，所有代码都是可以直接复制运行的。我用 Java 原生客户端来写，因为它最接近协议本身，理解了它之后再看 Spring AMQP 那些封装，就知道每一层在做什么。

3.1 容器化部署与关键端口

本地跑一个单机实例最省事的方式是容器，一条命令搞定。需要注意的是端口有三个：5672 是 AMQP 协议端口，程序和它打交道；15672 是管理台端口，浏览器和它打交道；4369 是集群发现用的，单机用不上但容器会监听。把前两个映射出来就够用。

docker run -d --name rabbit-demo \ -p 5672:5672 \ -p 15672:15672 \ -e RABBITMQ_DEFAULT_USER=dev \ -e RABBITMQ_DEFAULT_PASS=dev123456 \ rabbitmq:3.12-management

这里选带-management后缀的镜像，因为它内置了管理台插件。如果用了不带后缀的镜像，管理台是打不开的，需要进容器手动执行rabbitmq-plugins enable rabbitmq_management。这个细节文档里写得很小，但新手经常卡在这里。

启动之后访问http://localhost:15672，用上面设置的用户名密码登录。如果登录不进去，先看容器日志里有没有Server startup complete，再看端口有没有被占用，最后确认镜像版本。默认的guest用户只能从本机登录，容器场景下访问会被拒绝，所以一定要自定义用户，这也是上面命令里设置环境变量的原因。

3.2 生产者代码与确认模式

生产者的核心就三件事：建连接、建通道、发消息。但要做到可靠，还得加上确认机制。下面这段代码把连接复用、通道复用、发布确认都包含了。

public class ProducerDemo { private static final String EXCHANGE = "biz.order"; private static final String ROUTING_KEY = "order.created"; public static void main(String[] args) throws Exception { ConnectionFactory factory = new ConnectionFactory(); factory.setHost("localhost"); factory.setPort(5672); factory.setUsername("dev"); factory.setPassword("dev123456"); factory.setVirtualHost("/"); // 连接超时与心跳，避免网络抖动导致长时间卡死 factory.setConnectionTimeout(5000); factory.setRequestedHeartbeat(30); try (Connection conn = factory.newConnection(); Channel channel = conn.createChannel()) { // 声明交换机：持久化、不自动删除 channel.exchangeDeclare(EXCHANGE, BuiltinExchangeType.TOPIC, true, false, null); // 开启发布确认 channel.confirmSelect(); for (int i = 0; i < 100; i++) { String body = "{\"orderId\":\"NO" + i + "\",\"amount\":99.00}"; AMQP.BasicProperties props = new AMQP.BasicProperties.Builder() .deliveryMode(2) // 2 表示消息持久化 .contentType("application/json") .messageId(UUID.randomUUID().toString()) .build(); channel.basicPublish(EXCHANGE, ROUTING_KEY, props, body.getBytes(StandardCharsets.UTF_8)); // 同步等待确认，生产环境通常用批量确认或异步回调 boolean acked = channel.waitForConfirms(3000); if (!acked) { System.err.println("消息未被确认，需要重发: " + body); } } } } }

这段代码里有几个点值得展开。deliveryMode(2)是消息持久化标记，但光有它不够，交换机和队列也必须声明为持久化，三者缺一，重启后消息照样丢。confirmSelect()开启发布确认之后，Broker 收到消息并落盘（如果是持久化消息）才会回一个 ack，这样生产者才能确认消息真的到了。waitForConfirms是同步等待，简单但会阻塞，一次发一条等一条，吞吐上不去。生产环境的做法是批量确认：每发 100 条waitForConfirms一次，或者用异步回调addConfirmListener，后者性能最好但代码复杂一些。

还有一个必须加的是mandatory标记和ReturnListener。前面说过，消息到了交换机但找不到队列会被静默丢弃，加上mandatory=true之后，这种情况会触发一条 return 回调，生产者就能感知到“消息没进队列”。

channel.addReturnListener(returned -> { String msg = new String(returned.getBody(), StandardCharsets.UTF_8); System.err.println("消息无法路由，replyCode=" + returned.getReplyCode() + ", msg=" + msg); }); channel.basicPublish(EXCHANGE, ROUTING_KEY, true, props, body.getBytes(StandardCharsets.UTF_8));

confirm和return的区别要分清楚：confirm 告诉你“Broker 收到了”，return 告诉你“收到了但没找到队列”。前者是可靠性保障，后者是路由正确性保障，两个都要有，缺一不可。

3.3 消费者代码与手动 ACK

消费者最容易写错的地方是自动确认。autoAck=true的意思是消息一到客户端就被标记为已消费，Broker 立刻把它删掉，后面你处理成功了还是抛异常了，Broker 都不关心。这个模式只在“丢了也无所谓”的场景下能用，业务消息一律用autoAck=false加手动确认。

public class ConsumerDemo { private static final String QUEUE = "queue.order.created.coupon"; private static final String EXCHANGE = "biz.order"; private static final String ROUTING_KEY = "order.created"; public static void main(String[] args) throws Exception { ConnectionFactory factory = new ConnectionFactory(); factory.setHost("localhost"); factory.setUsername("dev"); factory.setPassword("dev123456"); Connection conn = factory.newConnection(); Channel channel = conn.createChannel(); channel.exchangeDeclare(EXCHANGE, BuiltinExchangeType.TOPIC, true, false, null); // 声明队列：持久化、非排他、不自动删除、带死信交换机 Map<String, Object> queueArgs = new HashMap<>(); queueArgs.put("x-dead-letter-exchange", "biz.dlx"); queueArgs.put("x-dead-letter-routing-key", "order.created.dead"); queueArgs.put("x-max-length", 100000); queueArgs.put("x-overflow", "reject-publish"); channel.queueDeclare(QUEUE, true, false, false, queueArgs); channel.queueBind(QUEUE, EXCHANGE, ROUTING_KEY); // 一次只预取 20 条，避免单个消费者囤积过多消息 channel.basicQos(20); DeliverCallback onMessage = (tag, delivery) -> { String body = new String(delivery.getBody(), StandardCharsets.UTF_8); long deliveryTag = delivery.getEnvelope().getDeliveryTag(); try { // 业务处理：这里换成真正的发券逻辑 handleCoupon(body); // 手动确认，multiple=false 表示只确认这一条 channel.basicAck(deliveryTag, false); } catch (Exception e) { // 处理失败：requeue=false 表示不重回队列，直接进死信 channel.basicNack(deliveryTag, false, false); System.err.println("处理失败，已转死信: " + body + ", 原因: " + e.getMessage()); } }; channel.basicConsume(QUEUE, false, onMessage, tag -> {}); // 保持主线程存活 Thread.sleep(Long.MAX_VALUE); } private static void handleCoupon(String body) { /* 真实业务逻辑 */ } }

basicQos(20)这个参数的含义是：在收到确认之前，最多再推送 20 条给我。它直接影响消息在消费者之间的分布。如果不设，Broker 会把队列里的消息一股脑推给第一个连上来的消费者，导致一个消费者累死、其他消费者闲着。这个值设多少有讲究，后面单独讲。

basicNack的第三个参数requeue是关键。设成true消息会重新回到队列头，看起来很美好，但如果这条消息本身是“毒消息”（比如格式错误，处理必然失败），它会被反复投递、反复失败，形成一个死循环，把消费者彻底卡死，同时日志被刷爆。所以业务处理失败时一律设false，让它进死信队列，由人工或专门的补偿程序处理，这是踩过坑之后的定论。

3.4 管理台指标怎么看

管理台不是用来看热闹的，几个指标直接决定排查方向。

Ready / Unacked / Total。Ready 是等待投递的消息数，Unacked 是已经投递给消费者但还没确认的消息数，Total 是两者之和。如果 Ready 一直涨，说明消费速度跟不上生产速度，方向是加消费者或者查消费慢的原因；如果 Unacked 一直涨，说明消费者拿到了消息但迟迟不确认，方向是查消费逻辑是不是卡住了或者prefetch设太大了。

Publish / Deliver / Ack / Redeliver 速率。这四个曲线放在一起看特别有用。正常情况下发布速率和确认速率应该接近。如果 Redeliver 有明显尖峰，说明在频繁重新投递，要么是消费者频繁异常，要么是requeue=true导致了循环。

Connections / Channels。连接数缓慢上涨不下降，基本可以断定有连接泄漏，找创建连接的地方看有没有关闭。通道数同理。我们定过一个规则：连接数超过阈值持续 10 分钟就告警，因为正常业务下连接数应该是稳定的。

队列的消费者数量。如果某个队列的消费者数量是 0 但还在收消息，消息就会一直堆着。这种情况通常发生在消费者服务重启失败或者注册失败，是最容易发现也最容易忽略的问题。

4. 消息不丢：一条消息的完整可靠链路

“消息会不会丢”是每个用消息队列的人都绕不开的问题。答案很明确：会丢，而且在生产端、Broker 端、消费端三个环节都可能丢。想要不丢，三个环节都要兜住，缺一个就前功尽弃。这一章按链路顺序讲清楚每一环要做什么。

4.1 生产端 confirm 与 return 的双保险

生产端丢失的场景是：消息发出去了，但 Broker 没收到。可能因为网络中断、Broker 宕机、队列满了被拒。如果生产者不知道这件事，消息就永远消失了。

confirm机制解决的就是这个问题。开启之后，每条消息会分配一个递增的序号，Broker 处理完回一个 ack 或者 nack。ack 表示收到并落盘（针对持久化消息），nack 表示处理失败。生产者收到 nack 或者超时没收到回应，就应该重发。

三种实现方式各有取舍：

批量同步的做法是攒够 100 条或者等 200ms，调一次waitForConfirms，如果返回 false 就把这一批全部重发。这里有个细节要注意：waitForConfirms返回 false 时，你并不知道具体哪一条失败了，只能整批重发，所以消费端必须做幂等。异步监听则是通过回调拿到具体失败的序号，可以只重发那几条，但需要自己维护一个未确认消息的映射表，内存管理要小心，别越积越多。

return机制配合mandatory使用，解决的是“消息到了交换机但没有队列接收”的情况。这种情况生产者默认完全无感知，加上 mandatory 之后会触发回调。生产环境的规范是：所有业务消息发送都必须设mandatory=true并注册 ReturnListener，收到 return 就记告警，因为这意味着路由配置出了问题，属于必须人工介入的异常。

4.2 Broker 端持久化的三处设置

Broker 端的丢失场景是：消息收到之后还在内存里，Broker 重启就没了。要避免这个，必须让消息落到磁盘。但持久化不是设一个地方就行，交换机、队列、消息三处都要设，缺一不可。

交换机和队列的持久化是在声明时通过durable=true指定的。这里有个常见误解：交换机持久化了，它绑定的队列就自动持久化吗？不是，绑定关系本身也是需要持久化的，声明队列时 durable 为 true 才管用。如果队列是非持久化的，Broker 重启后队列消失，里面的消息自然也没了，跟消息本身是否持久化没关系。

消息的持久化是通过deliveryMode=2指定的。但要注意，即使三处都设了，消息也不是“立刻”落盘。RabbitMQ 有批量刷盘的机制，消息先写进内存缓冲，攒一批再 fsync。这个窗口期通常是几十毫秒，如果这时候 Broker 进程崩溃（不是机器断电），消息还在内存里，也会丢。想要更严格的保证，要么用 publisher confirm 等 ack（ack 是在落盘之后才回的），要么接受这个极小概率的窗口。

还有一个容易被忽略的点是惰性队列。RabbitMQ 3.6 之后引入了x-queue-mode=lazy参数，开启后消息会尽可能早地写入磁盘，内存里只保留少量索引。好处是内存占用极低，可以堆积千万级消息不 OOM；坏处是吞吐会下降，因为每条消息都要走磁盘。这个参数适合“消息量大但对延迟不敏感”的场景，比如离线任务队列，不适合高频低延迟的业务消息。

4.3 消费端手动 ACK 与幂等设计

消费端的丢失场景是：消息拿到了，处理到一半进程挂了，但已经自动确认了，消息就没了。解决办法只有一个，就是关闭自动确认，处理成功之后再手动 ack。

手动 ack 的时机很重要。有一种写法是“拿到消息先 ack，然后再处理业务”，这样即使处理失败也不会重投，看似避免了重复消费，实际上是把丢失的风险放大了——处理失败的消息彻底没了。正确顺序永远是“先处理，成功了再 ack”。

但 ack 之后还有另一个问题：ack 发出去了，但网络抖动导致 Broker 没收到，Broker 会认为这条消息没被消费，重新投递给其他消费者。这就产生了重复消费。所以只要用了手动 ack 加重试，就必须做幂等，这不是可选项，是必选项。

幂等的实现方式按业务选：

唯一键去重。消息体里带一个全局唯一的 messageId，消费前先查一下这个 id 有没有处理过。查的方式可以是数据库唯一索引、Redis 的 setnx、或者一张专门的消息消费记录表。数据库唯一索引最可靠，但每次都要写库，性能一般；Redis 快但有极小概率丢数据，适合对一致性要求不那么极端的场景。

状态机约束。订单状态从“待支付”到“已支付”，消费支付成功消息时，用UPDATE ... WHERE status = '待支付'这样的条件更新，影响行数为 0 就说明已经处理过，直接 ack。这种方式天然幂等，不依赖额外的去重表，是我最推荐的。

业务本身幂等。比如“设置用户积分余额为 100”是幂等的，“增加用户积分 10 分”不是。设计消息的时候尽量往幂等的方向靠，能省掉很多麻烦。

4.4 可靠性不是白来的：性能代价测算

把所有可靠性措施都开满，性能会掉多少？我给一组实测参考值，环境是单机、4 核 8G、机械盘，消息体 1KB。

这组数字的意义不是让你记住，而是让你明白可靠性的代价在哪。单条同步 confirm 把吞吐砍掉了一个数量级，这就是为什么生产环境几乎不会用它。批量确认的代价就温和得多，是我们实际采用的方案。

另一个常被忽略的代价是磁盘。一条 1KB 的消息，加上各种元数据，实际占用可能在 1.5KB 到 2KB 之间。如果队列堆积了一千万条，磁盘占用接近 20G。这个账要提前算，别等磁盘写满了才发现。

5. 高频故障排查实录

用了几年 RabbitMQ，出问题的场景高度集中，就那么几类。这一章按“现象 → 原因 → 处置”的顺序整理，附上一张速查表，遇到问题可以直接对号入座。

5.1 消息堆积的三种成因与处置

堆积是最常见的告警，但成因完全不同，处置方式也完全不同，不能一概而论“加消费者”。

第一种：消费能力不足。特征是发布速率稳定，消费速率也稳定，但消费速率小于发布速率，队列长度线性增长。处置很简单，加消费者就行。但加之前先确认瓶颈在哪：如果消费者 CPU 打满了，加机器有效；如果消费者在等数据库，加机器只会让数据库更慢；如果消费者在等第三方接口，加机器也没用，得改架构或者做限流。我们遇到过一次，加了三倍消费者堆积反而更严重，最后发现是下游数据库连接池被撑爆，所有请求都在等连接。

第二种：消费者卡死。特征是消费速率突然掉到零或者接近零，Unacked 数一直很高。常见原因有三种：消费逻辑里有死锁、有阻塞调用没有超时、或者prefetch设得太大导致单个消费者囤了一堆消息在本地处理不完。处置是先看线程栈，定位卡在哪一行，然后重启消费者。预防措施是给所有外部调用加超时，prefetch不要设太大。

第三种：生产端突发流量。像大促、定时任务同时触发这种，瞬时发布速率可能是平时的一百倍。这种堆积其实是设计预期内的，队列的作用就是吸收它。处置方式不是加消费者（加多少都可能被瞬间打满），而是提前做容量规划：算清楚峰值消息量、消费者的处理能力、允许的消化时间，据此设置队列的最大长度和告警阈值。消化时间超过预期才需要人工介入。

5.2 连接与通道泄漏

连接数持续上涨不下降，最终 Broker 达到最大连接数限制，新连接全部被拒，整个服务不可用。这类问题的排查思路很固定。

先用管理台的 Connections 页面看连接来源，按客户端 IP 或者连接名分组，找到是哪个服务在涨。然后去那个服务的代码里搜newConnection，看有没有对应的close。最常见的写法错误是把连接创建放在循环或者方法内部，用完忘了关，每次请求泄漏一个。

第二常见的是没有用 try-with-resources 或者 finally 块，代码中间抛异常，关闭语句被跳过。这种在日志里通常能看到大量业务异常，连接泄漏是它的副作用。

第三是连接池配置问题。有些框架的连接池默认最大连接数很小，但复用逻辑有问题，导致频繁创建新连接。这种情况看连接的平均存活时间就能判断，如果大量连接的存活时间是几秒，基本就是池的配置问题。

Channel 的泄漏同理，只不过 Channel 泄漏的表现是通道数上涨，最终也会拖垮 Broker。规范做法是 Channel 用完就关，或者明确由框架托管，不要自己随手createChannel又不管。

5.3 常见问题速查表

这张表我打印出来贴在工位上过，出问题时对着看，能省掉大量瞎猜的时间。

排查顺序建议固定为：先看管理台的队列指标，再看消费者日志，最后看 Broker 日志。反过来做往往会绕远路，因为 Broker 日志里全是协议层的细节，信息密度低。

6. 工程实践里的几个取舍

前面讲的都是“怎么做对”，这一章讲“怎么做好”。同样能跑通的方案，在参数、结构、部署方式上的差异，会决定系统在压力下是稳如老狗还是频频告急。

6.1 prefetch 预取值的计算

basicQos的预取值设多少合适，这个问题我被问过很多次。设太小，消费者频繁往返拉消息，吞吐上不去；设太大，消息在单个消费者本地囤积，负载不均，而且一旦这个消费者挂了，那批消息要等连接超时才能重新投递。

我的经验公式是：prefetch ≈ 单条消息平均处理耗时（毫秒） × 目标吞吐（条/秒） / 消费者数量，再取一个不超过 100 的上限。举个例子，单条处理 50ms，单个消费者目标吞吐 20 条/秒，那理论上 prefetch 设 1 就够（50 × 20 / 1000 = 1）。但实际网络往返有开销，设成 10 到 20 更稳。如果单条处理只要 1ms，目标吞吐 500 条/秒，那 prefetch 设 50 到 100 是合理的。

另一条经验是：处理快的场景（毫秒级）把 prefetch 调大，处理慢的场景（几百毫秒以上）把 prefetch 调小。因为处理慢的时候，囤积在本地队列里的消息如果消费者挂了，重新投递的延迟会很长，而且这些消息在 Unacked 状态占着内存。

还有一个特殊情况是消费者数量远多于队列数量。RabbitMQ 的队列是单点的，一个队列的消息只会投给连接到它的消费者，不存在“多个队列负载均衡”的概念。所以如果有 10 个消费者连同一个队列，prefetch 的作用就是把消息均匀分下去。如果 prefetch 设得很大，第一个连上的消费者可能把消息全拿走，其他九个干看着，这就是典型的负载不均。

6.2 死信队列与延迟消息的实现路径

死信队列不是一个特殊类型的队列，它就是一个普通队列，只是被别的队列通过x-dead-letter-exchange指定为“处理不了的消息往这儿送”。它的价值在于：让失败的消息有迹可循，而不是消失。

标准的死信链路是这样的：业务队列绑定死信交换机，死信交换机再绑定死信队列，死信队列有一个专门的消费者负责记录日志、发告警、或者做自动补偿。死信队列的消息不建议自动消费，因为每一批死信都值得人工看一眼，搞清楚为什么失败。我们团队的做法是死信队列只做归档和告警，补偿动作由人工确认后通过管理台重新投递。

延迟消息是另一个高频需求，RabbitMQ 本身不直接支持延迟队列，得绕一下。最常用的方案是 TTL + 死信：声明一个队列不设消费者，所有消息设 TTL，队列绑定死信交换机，消息过期后自动转到真正的消费队列。这个方案有个严重缺陷：队列是先进先出的，TTL 也是按队头判断的，如果先投进去一条 30 分钟的消息，再投一条 1 分钟的消息，那条 1 分钟的消息要等前面 30 分钟的过期了才能被处理。所以这个方案只适合“所有消息延迟时间相同”的场景。

如果延迟时间不固定，就要给每个延迟档位建一个队列，比如 1 分钟一个队列、5 分钟一个队列、30 分钟一个队列，生产者按需投到对应队列。这个方案笨但稳，实际项目里用得最多。另一种思路是用延迟插件，但插件有版本兼容问题，升级时要格外小心，而且它把延迟消息存在本地，集群切换时可能丢，所以核心业务还是推荐多队列方案。

6.3 集群与镜像队列的取舍

单机部署的 RabbitMQ 挂了整个消息链路就断了，所以生产环境基本都要集群。但集群有两种模式，选错了会带来完全不同的运维体验。

普通集群模式下，元数据（交换机、队列定义、绑定关系）会在所有节点同步，但队列里的消息只存在创建它的那个节点上。好处是吞吐高、资源利用率高；坏处是那个节点挂了，队列就不可用了，要等节点恢复。这种模式适合“能接受短暂不可用”的场景。

镜像队列模式下，队列的消息会同步到多个节点，主节点挂了从节点自动顶上，可用性大幅提升。代价是每条消息要同步写多个节点，吞吐下降明显，而且同步本身会占用网络带宽。更麻烦的是脑裂问题，网络分区时可能出现两个主节点，产生数据不一致，需要人工介入恢复。

我的建议是：除非业务明确要求“RabbitMQ 单节点故障不能中断消息链路”，否则优先用普通集群加多副本部署，把可用性保障放在应用层（生产者重连、消费者重试）。镜像队列的复杂度往往被低估，运维成本远超预期。如果确实需要强可用，那就要配好pause_minority或者autoheal的分区处理策略，并且在监控里盯住网络分区的告警。

还有一个部署上的细节：交换机和队列的声明最好在应用启动时统一做，可以写一个初始化类，把所有的交换机、队列、绑定关系一次性声明好。这样避免了“某个服务先启动发现队列不存在，参数还写错了”的问题，也让整个消息拓扑有据可查。我们现在的做法是把拓扑定义集中在一个配置类里，谁要新增队列就改这个类，代码评审的时候能一眼看出拓扑变化。

最后分享一个我们团队摸索出来的小习惯：每个业务队列都配一个看板，把发布速率、消费速率、堆积量、死信数量四个指标放一起。每天上班第一件事看一眼，曲线不平就说明有事。这个习惯比任何告警都管用，因为很多问题在变成告警之前，曲线已经显示出苗头了。