Push vs Pull 消费模式、QoS 预取计数（prefetch_count 能者多劳）、自动 vs 手动 ACK/NACK/Reject、工作队列多消费者并发分摊。

消费模型与并发机制

校招考察频度：★ 高频（核心必考·消费端稳定性防线） 生产导向主线：消息到了队列，消费者如何高效、安全地取出来处理？很多生产事故都是因为配置了错误的消费模式导致的（如贪婪推送打崩内存、自动 ACK 导致业务异常数据静默蒸发）。面试核心：Push 推模式 vs Pull 拉模式底层差异、QoS 预取数量（prefetch_count）与能者多劳原则、消费端手动 ACK/NACK/Reject 机制、以及工作队列多消费者并发模型。

一、Push（推模式） vs Pull（拉模式）

在 AMQP 协议中，消费者从队列获取消息有两种截然不同的方式：

模式	核心方法	运作机制	优势与局限	生产适用场景
Push（推模式）	`channel.basicConsume(...)`	消费者向 Broker 注册监听回调。一旦队列中有消息，Broker 主动、持续将消息推向消费者。	极高吞吐、微秒级超低延迟。缺点是若不加流控容易压垮消费者内存。	生产 99% 场景的主流选择（Spring AMQP 默认）
Pull（拉模式）	`channel.basicGet(...)`	消费者主动向 Broker 发起一次 HTTP/TCP 轮询请求：“有消息吗？给我一条”。	消费节奏完全由客户端掌控；缺点是吞吐极低，频繁轮询浪费大量网络与 CPU 资源。	批处理离线任务、低频定点巡检、需要精确控制单条拉取节奏的场景

二、消费端流量控制：QoS 与 `prefetch_count`（能者多劳原则）

这是 RabbitMQ 消费端调优与高并发面试中最核心的一道大题！

1. 默认“贪婪推送”带来的生产灾难

在未配置 QoS 的情况下，RabbitMQ 默认采用无限贪婪推送策略：
如果队列中积压了 5 万条消息，消费者一上线，Broker 会瞬间把这 5 万条消息全部无脑推送给该客户端！
灾难后果：
1. 消费者应用的 JVM 堆内存或 Python 进程内存被海量未处理消息瞬间塞满，直接触发 OOM（内存溢出崩溃）！
2. 如果集群中有两个消费者 A 和 B，A 处理单条需要 50ms（性能慢），B 处理单条需要 2ms（性能快）。默认轮询分发会导致 A 堆积了大量任务痛苦卡死，而性能强劲的 B 早就闲着等米下锅，造成极大的算力倾斜与浪费。

2. `channel.basicQos(prefetch_count)` 解法

QoS（服务质量保证）：通过设置 prefetch_count，限制每个 Consumer 信道上允许存在的“未确认（Unacknowledged）消息最大条数”。

[Queue: 待消费消息 1000 条]
      |
      |-- basicQos(1): Broker 每次只推送 1 条
      v
[Consumer 实例]  --- 正在处理中... (Unacked = 1)
      |
      |-- 只有当消费端手动调用 basicAck() 后，Unacked 归 0!
      v
[Broker 收到 ACK] ---> 允许推送下一条新消息!

生产调优建议：
- prefetch_count = 1：严格能者多劳。处理快的节点拿到更多任务，最安全，但因为每条都要等待 ACK 往返，网络利用率不是最高。
- 生产黄金实践值：通常设置为 50 ~ 250。既保持了足够的消息管道流水线预取缓冲（跑满吞吐），又牢牢守住了消费者的内存安全线。

三、消费端确认机制（ACK / NACK / Reject）

消息被消费者拿到后，如何向 Broker 汇报任务结果？

1. 自动确认（`autoAck = true`·生产严禁使用）

只要 Broker 把消息通过网络发给了消费者，无论消费者是否收到、是否抛出异常、或者在处理中途突然断电崩溃，Broker 立即将消息从队列中物理删除！
业务异常或网络断开时，消息彻底永久蒸发，无法追溯。生产环境绝对禁止开启 autoAck=true！

2. 手动确认（`autoAck = false`·生产唯一标准）

消费者在完成本地数据库事务落库后，主动通过当前 Channel 调用以下方法之一：

// 1. 成功处理: 向 Broker 发送 ACK，Broker 将消息从队列中安全移除
// deliveryTag: 消息唯一交付序号
// multiple: 是否批量确认 (false: 仅确认当前单条; true: 确认当前及之前所有小于该 tag 的消息)
channel.basicAck(deliveryTag, false);

// 2. 处理失败拒绝单条: basicReject
// requeue: true (放回队列头部/尾部重新派发给其他消费者); false (直接丢弃或送入死信队列 DLX)
channel.basicReject(deliveryTag, false);

// 3. 处理失败批量拒绝: basicNack
// 支持批量拒绝多条消息，配合 requeue 标志控制去向
channel.basicNack(deliveryTag, false, false);

[!CAUTION] 警惕 requeue = true 造成的死循环死锁：如果因为代码空指针异常（NPE）或数据脏数据导致消费失败，若盲目指定 requeue=true，消息被退回队列后又会立即被再次推送并再次报错抛异常，导致CPU 100% 空转、刷爆磁盘日志！ 生产规范：捕获不可恢复的业务异常时，必须指定 requeue=false，让消息流向 死信队列（DLX），配合人工报警排查！

四、Work Queues 工作队列模型（多消费者分摊并发）

当单个消费者的处理速度跟不上生产者的发送速度时，RabbitMQ 允许多个 Consumer 绑定到同一个 Queue：

多消费者并发竞争模型: 任务自动分摊，单条消息只被消费一次

竞争消费者模式（Competing Consumers）：
- 队列中的每条消息，有且仅会被其中的一个 Consumer 成功接收并消费。
- 结合 basicQos，系统能自动根据各 Worker 服务器的算力强弱实现弹性的动态负载均衡。

面试高频追问

什么是 RabbitMQ 的 QoS？prefetch_count 配为 0 是什么意思？
- QoS 是信道级别的流量控制机制，prefetch_count 规定了消费端未确认消息的滑动窗口大小。
- 如果配置为 0，代表无限制（即默认的贪婪推送），Broker 会把队列里所有的消息一股脑全灌给消费者，极易引发消费者内存崩溃 OOM。
消息消费失败时，应该调用 basicReject 还是抛异常？
- 生产环境应该显式捕获异常，并区分错误类型：
- 如果是偶发性网络抖动或下游短暂超时，可重试有限次数；
- 如果是业务参数错误或坏数据，严禁无脑 requeue=true（会导致死循环），应调用 basicReject(deliveryTag, false) 将坏消息送入死信队列（DLX）隔离，并告警人工介入。
消费者正在处理消息时突然崩溃宕机，未确认的消息会丢失吗？
- 绝不会丢失。因为开启了手动 ACK（autoAck=false），Broker 维护着该消息为“Unacknowledged”状态并监控与消费者的 TCP 连接。一旦检测到消费者连接断开，Broker 会立即自动将该消息重新放回队列（Ready 状态），并自动派发给下一个健康的活跃消费者。