prefetch count 必须配合 manual ack 才生效，因为只有手动确认模式下，rabbitmq 才会根据未确认消息数限制推送；auto ack 模式下 prefetch 被完全忽略，导致消息持续涌入、内存堆积、重复消费。
prefetch count 不是调得越大越好，也不是越小越稳；它必须和你的消费者处理能力、ACK 模式、concurrency 数量三者对齐，否则要么压垮内存，要么饿死 CPU。
prefetch count 为什么必须配合 manual ACK 才生效？
不开启手动 ACK 时，prefetch 完全被忽略——RabbitMQ 会持续推送消息，直到 TCP 缓冲区满或连接断开。只有在 acknowledge-mode: manual 下，Broker 才会真正按 prefetch 限制未确认消息数。
- 默认
acknowledge-mode是auto，此时无论你配了prefetch: 1还是prefetch: 100，都等同于没设 - Spring Boot 中必须显式配置
acknowledge-mode: manual，且业务代码里要调用channel.basicAck()或basicNack() - 如果只改
prefetch却忘了开 manual ACK，你会看到：消息被快速拉取、堆积在消费者内存里、重启后大量重复消费
怎么算出合理的 prefetch 值？
核心公式不是数学推导，而是「单个消费者单位时间内能处理完几条」+「你愿为公平性牺牲多少吞吐」。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 假设单消费者平均处理一条消息耗时 300ms，那 1 秒最多处理约 3 条 →
prefetch设为 3~5 比较安全 - 若消息处理极快（如纯日志打点，
- 若消息处理极慢或不稳定（如含远程 HTTP 调用、数据库锁等待），
prefetch = 1是最稳妥选择：确保一条卡住不影响其他消费者分摊任务 - 注意：设
prefetch = 1并不等于性能差，它能显著提升多消费者场景下的负载均衡度，尤其在 K8s 弹性扩缩容时避免“一个 Pod 吃满、其余空转”
concurrency 和 prefetch 的组合陷阱
这两个参数作用域不同：concurrency 控制线程数（Listener Container 层），prefetch 控制每条 Channel 上每个消费者的未确认上限（Channel 层）。它们叠加后实际并发消息数 = concurrency × prefetch，但这个乘积不能直接当吞吐看。
- 比如
concurrency: 5+prefetch: 10→ 理论最多有 50 条消息在消费者端待处理，但如果其中 1 个线程卡死，这 10 条就堵死，其余 4 个线程仍可继续拿新消息 - 反过来，
concurrency: 10+prefetch: 1→ 共 10 个线程，但每个只持 1 条，Broker 会更均匀地把新消息分给空闲线程，适合 CPU 密集型或不可预测耗时的任务 - 切忌盲目提高
concurrency却保持高prefetch：容易导致 JVM 内存陡增（每条消息对象 + 处理上下文），GC 频繁甚至 OOM
最容易被忽略的一点：prefetch 是 per-consumer 的，但它的效果高度依赖 channel 生命周期管理。如果你用的是短生命周期 channel（比如每次消费都 new 一个），basicQos() 调用可能失效或被覆盖；Spring AMQP 默认复用 channel，所以优先信任 spring.rabbitmq.listener.simple.prefetch 配置，而非手写 channel.basicQos()。
