RabbitMQ 消费确认与预取：manual ack、reject、nack 与 QoS 的取舍

RabbitMQ 消费确认与预取：manual ack、reject、nack 与 QoS 的取舍

1. 先看一个真实故障：消息去哪了

假设你负责一个订单履约服务。上游把「订单已支付」事件写进 RabbitMQ，下游消费者负责扣减库存、发短信、写履约单。上线第一周一切正常，第二周某个凌晨消费者进程被 OOM Killer 杀掉，重启后运维发现：有 300 多笔订单明明支付成功了，但库存没扣、短信没发。翻日志，消费者在处理到第 120 条消息时被打断，后面 180 条根本没被消费。

问题出在哪里？RabbitMQ 默认使用自动确认（autoAck）。消费者从队列拿到消息的一瞬间，Broker 就把这条消息删掉了，不管你后续业务有没有跑完。消费者进程崩溃，那些「已投递但未处理完」的消息就永久消失了。所以自动确认的语义是「投递即成功」，而不是「处理即成功」。

要修复它，你需要一套手动确认（manual ack）机制：业务处理成功后才告诉 Broker「这条可以删了」；处理失败或进程挂掉时，让消息回到队列重新投递。但一旦引入手动确认，新问题马上出现：如果一次拉 100 条、并发处理，某条失败后要重投，会不会把已经处理成功的也一起重投？如果某条消息永远处理失败，会不会无限循环、把 CPU 打满？消费者卡死但连接不断，Broker 会不会一直等它？这些正是本文要回答的问题。

2. 一句话模型与全局框架

先把核心模型用一句普通中文说清楚：RabbitMQ 的消费确认，本质上是消费者与 Broker 之间围绕「这条消息我负责到底了没有」的一次显式对话；而预取（QoS）决定的是这条对话一次可以并行进行多少条。

为了不迷失在 API 细节里，先把它拆成三个角色和一条时间线：

• 生产者（Producer）：把消息发到交换机。
• 交换机与队列（Exchange / Queue）：交换机按路由规则把消息放进队列，队列是消息真正排队等待被取走的地方。
• 消费者（Consumer）：从队列取消息、执行业务、回执确认。

三者与 Broker 之间一次完整流转的顺序如下：

生产者                 Broker(交换机+队列)             消费者
  |  1. publish            |                            |
  |----------------------->|                            |
  |                        |  2. 入队, 等待投递          |
  |                        |  3. deliver (带 deliveryTag)| 
  |                        |--------------------------->|
  |                        |                            | 4. 执行本地业务
  |                        |                            | 5. 回执 ack/nack/reject
  |                        |<---------------------------|
  |                        |  6a. ack  -> 删除消息       |
  |                        |  6b. nack -> 重新入队/死信   |

这张图里有两个关键点，后文会反复用到。第一，deliveryTag 是 Broker 在单个信道（Channel）上给每条投递消息编的序号，从 1 开始递增；确认时必须带着这个序号，且确认只在该信道内有效。第二，ack 与 nack/reject 的区别不是「成功与失败」的情绪差别，而是Broker 后续怎么处置这条消息：是删除，还是放回队列，还是丢进死信交换机。

理解了这个框架，后面所有 API 都是在回答两个问题：这次回执针对哪条（或哪批）消息？Broker 收到后做什么？

3. AMQP 里的确认到底确认了什么

很多人以为 ack 是「客户端告诉服务端我收到了」。在 RabbitMQ 的语境里更准确的说法是：消费者告诉 Broker「这条消息的归属权可以从我身上摘掉了，你可以按你的策略处置它」。这句话有两层含义。

第一层是归属权转移。消息一旦被投递给某个消费者但未确认，Broker 会把它标记为 unacked。此时消息不在队列头部等待投递，也不算已删除，而是「押」在这个消费者对应的信道账上。如果消费者断开连接或信道关闭，Broker 会把该信道上所有 unacked 消息重新入队，投给其他消费者（或自己重连后再取）。这是可靠性的根本保障：崩溃不会丢消息，代价是可能重复。

第二层是批量语义 。Broker 不要求你逐条确认。basicAck(deliveryTag, multiple=true) 表示「这个 tag 以及它之前所有未确认的都算完成」。批量确认能显著减少网络往返，提升吞吐，但代价是精度下降：如果你只想确认第 100 条却用了 multiple=true，那 1 到 99 条也会被一并确认，一旦 1 到 99 里有处理失败的，就再也没机会重投了。

这里最容易误解的是：ack 的「成功」完全由你的业务代码定义，RabbitMQ 无法校验。你可以在根本没写数据库的情况下调用 ack，也可以在写库成功后忘记 ack。RabbitMQ 只记录「你有没有回执」，不记录「你回执得对不对」。因此确认逻辑必须和业务事务的边界对齐，这是后面幂等设计的伏笔。

4. 手动确认模式：把删除权从 Broker 拿回来

手动确认的开关是消费者注册时的 autoAck=false（在 Java 客户端里是 basicConsume 的 autoAck 参数）。这个开关一旦打开，你就有义务在合适时机调用 basicAck，否则消息会一直挂在 unacked 里，占内存、占队列配额，最终触发流控。

手动确认的典型正确姿势是「先业务、后确认」，并且要用 try/catch 包住业务，异常时走 nack 或 reject。下面这段是完整的可运行示例 ：环境是 JDK 17 + com.rabbitmq:amqp-client:5.20.0，Broker 是本机 localhost:5672，默认 guest/guest。它声明一个持久化队列，消费端显式 autoAck=false，业务成功才 ack。

// ManualAckDemo.java ------ 最小可运行的手动确认消费者
import com.rabbitmq.client.*;
import java.nio.charset.StandardCharsets;

public class ManualAckDemo {
    private static final String QUEUE = "demo.order.paid";

    public static void main(String[] args) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");
        factory.setPort(5672);
        factory.setUsername("guest");
        factory.setPassword("guest");

        Connection connection = factory.newConnection();
        Channel channel = connection.createChannel();
        // 持久化队列：durable=true，第三个参数 exclusive=false，自动删除=false
        channel.queueDeclare(QUEUE, true, false, false, null);

        // 生产一条消息，方便直接消费演示
        channel.basicPublish("", QUEUE, MessageProperties.PERSISTENT_TEXT_PLAIN,
                "order-1001 paid".getBytes(StandardCharsets.UTF_8));

        // autoAck=false 是手动确认的关键开关
        DeliverCallback deliverCallback = (consumerTag, delivery) -> {
            long tag = delivery.getEnvelope().getDeliveryTag();
            String body = new String(delivery.getBody(), StandardCharsets.UTF_8);
            try {
                // 模拟业务：真实场景这里是一次数据库写 + 一次 RPC
                handleBusiness(body);
                // 业务成功后才确认，multiple=false 表示只确认这一条
                channel.basicAck(tag, false);
                System.out.println("[ack] " + body);
            } catch (Exception e) {
                // 业务失败：拒绝并重新入队，交给其他消费者重试
                channel.basicNack(tag, false, true);
                System.err.println("[nack-requeue] " + body + " cause=" + e.getMessage());
            }
        };

        // 注意：第二个参数 autoAck=false
        channel.basicConsume(QUEUE, false, deliverCallback, consumerTag -> {});
        System.out.println("consumer started, waiting...");
        Thread.sleep(10_000);
        channel.close();
        connection.close();
    }

    private static void handleBusiness(String body) {
        if (body.contains("poison")) {
            throw new IllegalStateException("业务处理失败");
        }
        // 正常业务：写库、调用下游等
    }
}

运行方式：启动本地 RabbitMQ 后，javac -cp amqp-client-5.20.0.jar ManualAckDemo.java 再 java -cp .:amqp-client-5.20.0.jar:slf4j-api-1.7.36.jar ManualAckDemo。预期输出是先打印 consumer started，随后 [ack] order-1001 paid。

关键点有三处。第一，basicAck 放在 handleBusiness 之后而不是之前，这就是「先业务后确认」。第二，失败时用了 basicNack(tag, false, true)，第三个参数 requeue=true 表示回队列------但这个选择有风险，下一节会专门讲。第三，multiple=false 意味着精确确认单条，这是初学阶段最安全的默认选择。

5. basicQos 预取：一次别给我太多

上一节的代码有一个隐藏问题：Broker 会把队列里的消息尽可能快地推给消费者，如果你的消费者只有一个线程处理，或者处理速度远低于投递速度，unacked 消息会快速堆积。放大到多消费者场景，还会出现「忙的消费者手里堆满未确认消息，闲的消费者没活干」的倾斜现象。这就是预取（prefetch）要解决的。

basicQos(prefetchCount, prefetchSize, global) 是消费者端给 Broker 的限制：在同一时间，最多允许有多少条「已投递但未确认」的消息挂在我这里。prefetchCount 是最常用的参数，prefetchSize 一般填 0（表示不按字节数限制），global 的语义要特别小心。

// 伪代码：展示 QoS 的两种作用域，不能直接运行
// 作用域一：仅对之后新建的消费者生效（RabbitMQ 常见语义）
channel.basicQos(10, false /* prefetchSize */, false /* global */);
channel.basicConsume(QUEUE, false, deliverCallback, cancelCallback);

// 作用域二：对当前信道上的所有消费者生效（global=true）
channel.basicQos(10, false, true);

先记住一个最小模型：QoS 不是限速器，而是「在途额度」。 它限制的是「未确认」的数量，不是每秒投递数量。只要你不 ack，额度就不会释放。因此 prefetchCount=1 意味着严格的一条一确认、串行处理；prefetchCount=100 意味着允许 100 条同时在途，适合高并发批量处理。

预取值	吞吐特性	内存与公平性	典型场景
1	低，几乎串行	内存占用最小，最公平	处理慢、单条成本高的任务
10~50	中等	较均衡	普通业务消费，多数场景的起点
100~500	高	unacked 堆积明显，消费者倾斜风险上升	批量计算、写入吞吐优先
0（不限制）	最高但不可控	容易 OOM 并触发流控	极少数实验场景，不建议生产

注意一个反直觉的地方：预取值越大，单条消息的端到端延迟可能越高。因为消息被推到某个消费者后，如果这个消费者在慢慢处理前面的消息，后面的消息只能等着，而另一个空闲消费者却取不到。所以「提高预取等于提高性能」只在批量、均匀、消费者数量少时成立。

6. reject 与 nack：拒绝之后的两种命运

业务失败时，你不能只 ack，也不能放着不管。RabbitMQ 给了两个 API：basicReject 和 basicNack。它们的关系可以用一句话概括：reject 是 nack 的单条版本，nack 能批量，reject 不能。

API	能否批量	参数	常见用途
basicAck(tag, multiple)	能	deliveryTag、multiple	业务成功，删除消息
basicReject(tag, requeue)	不能	deliveryTag、requeue	单条失败，明确重投或丢弃
basicNack(tag, multiple, requeue)	能	deliveryTag、multiple、requeue	批量失败，统一重投或丢弃

requeue=true 表示把消息放回队列，requeue=false 表示丢弃。丢弃并不等于消息消失得无影无踪------如果队列配置了死信交换机（DLX），消息会被转发到死信队列，供后续人工排查或延迟重试。这里把 DLX 的角色说清楚：它是队列的一个属性，消息因 nack（requeue=false）、TTL 过期或队列满而被丢弃时，Broker 会把它路由到 DLX。

一个常见错误是把 basicReject(tag, false) 当成「重试」。它其实是丢弃。要重试必须 requeue=true，但重试次数无法由 RabbitMQ 控制，只能靠你自己记录。下面是把「有限重试 + 死信」串起来的核心片段（属于简化代码，需配合 DLX 声明才能运行）：

// 简化代码：通过 x-death 头判断重试次数，超过阈值就丢进死信
DeliverCallback callback = (tag, delivery) -> {
    long dTag = delivery.getEnvelope().getDeliveryTag();
    Map<String, Object> headers = delivery.getProperties().getHeaders();
    int retry = extractRetryCount(headers); // 从 x-death 头里解析重试次数
    try {
        handleBusiness(new String(delivery.getBody(), StandardCharsets.UTF_8));
        tag.basicAck(dTag, false);
    } catch (Exception e) {
        if (retry < 3) {
            tag.basicNack(dTag, false, true);   // 前三次重投
        } else {
            tag.basicNack(dTag, false, false);  // 超过阈值，进死信队列
        }
    }
};

x-death 是 Broker 在消息因死信原因被投递时写入的头部，记录了死信原因和次数。它的具体字段在不同版本和不同死信原因下略有差异，所以解析逻辑要按你实际 Broker 版本验证，不要盲抄。如果你不想依赖它，更稳妥的做法是在业务侧用一张「消息去重/重试计数表」自己维护。

7. 重新入队风险：看似安全的 requeue=true

requeue=true 看起来是最省心的失败处理，失败了放回去再试嘛。但它藏着两个真实的生产事故源：饥饿 和风暴。

先说饥饿。RabbitMQ 重新入队时，默认会把消息放回队列头部附近。如果队列里只有这一条「毒消息」反复失败，而你只有一个消费者，它会被立刻再次投给同一个消费者，导致队列后面所有正常消息被无限期卡住。这就是经典的「毒消息阻塞」。多消费者只能缓解，不能根治：如果每个消费者都立刻拿到它并失败，整条队列的有效吞吐都会下降。

再说风暴。当一批消息因为同一个下游故障（比如数据库连接池耗尽）集体失败，requeue=true 会让它们几乎立刻回到队列并再次被投递，形成高频重试循环。这不仅把 CPU 和网络打满，还会持续刷日志，掩盖真正的故障原因。下面这张时序把两种风险串起来：

毒消息场景(单消费者, requeue=true):
消费者: 取 msg"b" -> 失败 -> nack(requeue=true) -> 重新入队(靠前)
消费者: 又取到 msg"b" -> 失败 -> nack(requeue=true) -> 循环...
队列:   [b][1][2][3]  <- 1/2/3 永远轮不到

批量故障场景(下游数据库不可用):
msg1..msg100 全部失败 -> 全部 requeue -> 立刻重新投递 -> 再次全部失败
时间轴: 重试间隔约等于 0, 直到数据库恢复或消息被拖入死信

正确的工程做法是给重试加上时间和次数约束 。时间约束靠延迟队列或 TTL + DLX；次数约束靠你自己记录的重试计数。当重试超限后，用 basicNack(tag, false, false) 把消息送到死信队列，让主队列继续前进。这个组合的完整链路是：主队列 -> 处理失败且未超限 -> 重投 -> 超限 -> DLX -> 死信队列 -> 人工或定时补偿。

8. 消费者超时与长时间未确认

还有一个隐蔽的失败模式：消费者既没 ack 也没 nack，业务卡在那里。常见原因是下游 RPC 没有超时、数据库慢查询、死锁或线程被阻塞。此时消息一直处于 unacked 状态，占用预取额度，消费者看起来「活着」但实际不干活。

RabbitMQ 有一个连接层面的 consumer_timeout（消费者确认超时，默认 30 分钟，可在配置中调整）。一旦某条投递在该时间内没有确认，Broker 会主动关闭这个信道，unacked 消息全部重新入队。这个机制保护的是集群资源不被卡死，但它的副作用是：如果配置为 30 分钟而你的业务正常处理需要 31 分钟，你的消息会被反复重投，形成难以排查的重复消费。

因此，业务处理时间必须明显小于 consumer_timeout，或者你需要为长任务设计另一种模式：先快速 ack 一条「已接收」记录，再做异步处理，用业务侧台账保证最终一致。很多团队用「先 ack 后处理」来绕过超时，但这就把可靠性责任完全转移到了自己身上，必须配套幂等和补偿机制，否则会丢消息。

9. 从一次投递到确认：完整链路推演

现在让一次真实消费完整走一遍，把前面所有概念串起来。场景：订单履约消费者，预取 20，业务是扣库存 + 发短信，下游偶尔超时。

[1] Broker 投递 msg(tag=7) -> 消费者, unacked=7
[2] 消费者线程从处理池取线程执行
[3] 扣库存成功
[4] 发短信超时, 抛异常
[5] 判断重试次数 retry=0 < 3
[6] basicNack(7, false, true) -> Broker 重新入队
[7] Broker 再次投递 msg(tag=9) -> 可能给同一或另一消费者
[8] 再次失败... 直到 retry=3
[9] basicNack(tag, false, false) -> 消息进死信队列
[10] 死信消费者记录工单, 人工介入

这个链路里有三个设计决策点。第一，在第 6 步和第 9 步之间必须有重试计数，否则永远出不去。第二，第 7 步的重新投递可能换消费者，所以业务必须幂等------同一条消息被处理两次，扣库存不能扣两次。第三，第 10 步的死信不是终点，要有可观测的告警和补偿流程，否则死信队列会变成黑洞。

下面给出第二个完整示例 ：带幂等键和重试计数的消费者。环境同上，额外建议你在 MySQL 里有一张 t_msg_log(msg_id, status) 表。这里用内存 Map 模拟幂等表，保证单进程可运行；生产请替换为数据库或 Redis。

// IdempotentConsumer.java ------ 幂等 + 有限重试的完整消费者
import com.rabbitmq.client.*;
import java.nio.charset.StandardCharsets;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;

public class IdempotentConsumer {
    private static final String QUEUE = "demo.order.paid.idem";
    private static final int MAX_RETRY = 3;
    // 模拟幂等表：生产环境请换成数据库唯一索引或 Redis SETNX
    private static final Map<String, Boolean> DONE = new ConcurrentHashMap<>();
    // 模拟重试计数：生产环境请持久化，否则重启后计数丢失
    private static final Map<String, AtomicInteger> RETRY = new ConcurrentHashMap<>();

    public static void main(String[] args) throws Exception {
        ConnectionFactory f = new ConnectionFactory();
        f.setHost("localhost"); f.setPort(5672);
        f.setUsername("guest"); f.setPassword("guest");
        try (Connection conn = f.newConnection(); Channel ch = conn.createChannel()) {
            ch.queueDeclare(QUEUE, true, false, false, null);
            ch.basicQos(20); // 预取 20，控制 unacked 上限

            DeliverCallback onDeliver = (consumerTag, delivery) -> {
                long dTag = delivery.getEnvelope().getDeliveryTag();
                String msgId = delivery.getProperties().getMessageId();
                String body = new String(delivery.getBody(), StandardCharsets.UTF_8);

                if (msgId == null) { // 没有幂等键的消息直接拒绝，避免无法去重
                    ch.basicNack(dTag, false, false);
                    return;
                }
                if (DONE.containsKey(msgId)) { // 幂等命中，直接确认
                    ch.basicAck(dTag, false);
                    return;
                }
                try {
                    handleBusiness(body, msgId);
                    DONE.put(msgId, true);
                    ch.basicAck(dTag, false);
                } catch (Exception e) {
                    int times = RETRY.computeIfAbsent(msgId, k -> new AtomicInteger()).incrementAndGet();
                    boolean requeue = times < MAX_RETRY;
                    ch.basicNack(dTag, false, requeue); // 未超限重投，超限进死信
                    System.err.println("fail msgId=" + msgId + " times=" + times + " requeue=" + requeue);
                }
            };
            ch.basicConsume(QUEUE, false, onDeliver, t -> {});
            System.out.println("idempotent consumer started, prefetch=20");
            Thread.sleep(15_000);
        }
    }

    private static void handleBusiness(String body, String msgId) {
        // 真实业务：扣库存 + 发短信，必须使用 msgId 保证下游可去重
        System.out.println("handling " + msgId + " body=" + body);
    }
}

预期行为：同一条消息即使因 nack 被重投，第二次到达时 msgId 已在 DONE 里，直接 ack，不会重复扣库存。失败消息会在重试 3 次后走死信。最容易改错的地方有两个：msgId 必须在生产端就设置好并全局唯一；重试计数如果只放内存，进程重启后会归零，导致消息无限重试，生产必须持久化或改用 x-death 头。

10. QoS、ack 与业务并发怎么配合

当消费者内部用线程池并发处理时，QoS 的语义会变得微妙。假设预取是 20，消费者用 4 个线程处理，那么同一时刻最多 20 条在途、最多 4 条在跑，其余 16 条在内存队列里排队。这没问题，但要注意两点。

第一，ack 必须在处理线程里调用，且要小心 Channel 的线程安全 。RabbitMQ Java 客户端的 Channel 不是线程安全的，多线程同时 ack 需要自己加锁，或者为每个线程开独立 Channel。很多「偶发 ack 无效」的 bug 都源于此。共享 Channel 上的 deliveryTag 序号是全局递增的，批量 ack 时尤其容易误伤。

第二，预取要略大于并发线程数，但不能太大。如果预取等于线程数，当某条消息处理特别慢时，其他空闲线程就没有新消息可拿，吞吐下降；如果预取远大于线程数，内存里堆积的业务数据会变多，且消费者倾斜更严重。一个可用的经验起点是「预取 = 并发线程数 × 2」，再根据压测调整。

第三种完整场景是生产端配合 ：消息带 messageId，队列声明 DLX，消费端使用预取与有限重试。下面的命令块展示如何用 rabbitmqadmin 或管理 API 观察 unacked 与死信情况，这属于可复现的排查操作，前置条件是开启 management 插件。

# 查看队列深度、消费者数、未确认数（需要 management 插件与本地 admin 工具）
rabbitmqadmin list queues name messages messages_unacknowledged consumers

# 输出示例（真实字段随版本略有差异）:
# +----------------------+----------+-------------------------+-----------+
# |         name         | messages | messages_unacknowledged | consumers |
# +----------------------+----------+-------------------------+-----------+
# | demo.order.paid.idem |      120 |                      20 |         1 |
# +----------------------+----------+-------------------------+-----------+

# 查看某个队列的死信配置与消息数
rabbitmqadmin list queues name arguments dead_letter_exchange

messages_unacknowledged 长期等于预取值，通常说明消费者的处理速度跟不上投递速度，或者有消息卡住没确认；messages 持续增长则说明整体消费能力不足。这两个指标是排查消费问题的第一入口。

11. 设计取舍：可靠、吞吐与重复之间的三角

到这里可以把所有取舍收拢成一张决策表。核心矛盾是：你要可靠性，就要手动确认和重试；你要重试，就可能重复消费；你要高吞吐，就要放大预取，但放大预取会让失败重投的粒度变粗、内存压力变大。

目标	推荐配置	需要接受的代价
宁可重复、不可丢失	manual ack + 有限重试 + 死信 + 幂等	业务侧必须实现幂等，重复不可避免
高吞吐批量处理	prefetch 100~500 + 批量 ack(multiple=true)	精度下降，失败时可能整批重投
严格顺序、低延迟	prefetch=1 + 单消费者	吞吐低，扩展性差
长任务	先 ack 再异步处理 + 本地任务表	可靠性责任转移到业务侧
失败隔离	nack(requeue=false) + DLX	需要维护死信消费与告警

有一个反直觉但重要的结论：在分布式系统里，「恰好一次」几乎不可能，工程上追求的是「至少一次 + 幂等」。 所以与其纠结怎么防止重复，不如把幂等做扎实。幂等键可以是业务单号、消息 messageId，或者由「业务主键 + 操作类型」拼出来。

另一个取舍是批量 ack 的边界。批量 ack 能省网络往返，但它把多条消息的命运绑在一起。只有在「同一批消息要么都成功、要么都可安全重试」时才用，且必须保证批内不会混入处理结果不同的消息。如果做不到，就老老实实单条 ack。

12. 生产实践建议与常见误区

生产实践建议 部分，先给几条可以直接落地的规则。第一，所有重要业务队列都关闭自动确认，使用 manual ack。第二，预取值从 20 起步，压测后再调，不要一上来就设 0。第三，失败重试必须有次数上限和时间间隔，推荐用 DLX + TTL 做延迟重试，而不是立刻 requeue=true。第四，所有可能重复消费的业务都必须有幂等键和唯一约束。第五，为每个消费队列配置死信队列，并对死信数量做告警，死信为 0 不代表正常，突然增长才是信号。

常见误区则集中在下面几点：

• 误区一：以为 autoAck=true 只是「自动帮我 ack 一下」。实际上它让消息在投递瞬间就被删除，业务失败即丢失。
• 误区二：以为 basicReject(tag, false) 是重试。它是丢弃，要重试必须 requeue=true。
• 误区三：以为 requeue=true 一定会回到队尾。它通常会被放到靠近头部的位置，从而阻塞后面的消息。
• 误区四：以为 QoS 是限速。它限制的是未确认数量，不限制投递速率。
• 误区五：在业务成功前就 ack，以换取「不重复」。这等于用丢消息换去重，非常危险。
• 误区六：多个线程共享一个 Channel 并各自 ack。Channel 非线程安全，可能引发连接层异常或确认错乱。

13. 排障清单：从现象到动作

现象	可能原因	排查动作
消息莫名消失	使用了 autoAck 且业务失败	检查消费者 autoAck 参数，改为 false
unacked 长期不降	业务卡住、未 ack、超时	看 messages_unacknowledged，检查下游超时与线程栈
队列积压但消费者空闲	预取过小或消费者倾斜	调大预取，增加消费者或优化处理速度
同一条消息反复重投	毒消息 + requeue=true	加最大重试次数，超限进死信
消息被重复消费	重投 + 无幂等	引入幂等键与唯一约束
连接被 Broker 关闭	消费者确认超时	检查处理耗时与 consumer_timeout 配置

排查顺序建议是：先看队列指标（深度、unacked、消费者数），再看消费者日志（是否 ack、是否异常循环），最后看 Broker 日志（是否有连接或信道被关闭）。不要一上来就改预取值，先把「有没有确认」这个根因定位清楚。

14. 面试/复盘问题

1. autoAck=true 和 autoAck=false 在消息生命周期上的差别是什么？分别在什么时机删除消息？
2. basicAck 的 multiple=true 有什么语义？什么场景下会误伤已经成功的消息？
3. basicReject 和 basicNack 的区别是什么？什么时候必须用 nack？
4. requeue=true 会带来哪些风险？如何设计有限重试？
5. basicQos 限制的是什么？为什么 prefetch=0 通常不建议用于生产？
6. 消费者超时触发后，RabbitMQ 会做什么？这对业务处理时间有什么要求？
7. 为什么说「至少一次 + 幂等」比追求「恰好一次」更现实？你会怎么设计幂等键？

这些问题可以当作团队评审的检查项：如果你的消费者代码答不上第 2、4、7 题，说明它在失败路径上的行为是不确定的。

15. 总结

把全文收回到一张框架图：生产端负责让消息可路由、可去重；Broker 负责排队、投递和在未确认时保留消息；消费端负责在业务成功后确认、失败时受控重试、超限进死信。 手动确认解决「丢消息」，预取解决「堆积与倾斜」，nack/reject 解决「失败怎么处置」，死信与幂等解决「重试之后怎么办」。

最后给一条可以直接执行的判断规则：先关闭 autoAck、把预取设为 20、给失败加最大重试次数、给业务加幂等键、给队列加死信。 这五步做完，你就已经避开了绝大多数消费端事故。剩下的调优------预取调多大、并发开多少、批量 ack 用不用------都可以在压测中慢慢找答案。

16. 参考资料

• RabbitMQ 官方文档：Consumer Acknowledgements and Publisher Confirms
• RabbitMQ 官方文档：Confirms (Publisher Confirms) 与 Consumer Prefetch
• RabbitMQ 官方文档：Dead Lettering、TTL 与 Queue Length Limit
• RabbitMQ 官方文档：Consumer Timeout（consumer_timeout）配置说明
• RabbitMQ Java Client API 文档：Channel、DeliverCallback、basicAck、basicNack、basicQos
• AMQP 0-9-1 规范（amqp.org）
• 《RabbitMQ 实战指南》相关章节（朱忠华）