prefetchcount应根据业务场景动态设置：秒杀类设1确保串行防db打爆，普通业务≤200ms可设5～20，轻量处理可放宽至50～100；必须配合manual ack，且需在basicconsume前调用basic_qos并验证unacked值是否稳定在设定阈值。
核心是设对 prefetchCount，配合手动签收（autoAck=false），让 RabbitMQ 把消息“匀着发”，而不是一股脑全推给消费者。
prefetchCount 设多少才合理？
这不是固定值，得看单条消息处理耗时、消费者实例数、下游资源承受力：
- 秒杀/扣库存类场景：推荐 1。确保一条处理完再拿下一条，彻底避免 MySQL 并发写打爆
- 普通业务（如日志入库、通知发送）：单条处理 ≤ 200ms 且内存充足，可设 5～20
- 只有 1～2 个消费者、且处理很轻快：可放宽到 50～100，提升吞吐
- 千万别设为 0 或不设——等同于不限流，RabbitMQ 默认会预取无限条
必须配手动签收（autoAck = false）
这是 QoS 生效的前提。自动签收下，basicQos 完全无效：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 创建消费者时，
basicConsume(..., false, ...)第二个参数必须为 false - 每条消息处理成功后，显式调用
channel.basicAck(deliveryTag, false) - 出异常时，用
basicNack拒绝，并决定是否重回队列，不能漏掉 ack/nack
Spring Boot 中的推荐配置方式
比硬编码更清晰、易维护：
- application.yml 中写：
spring: rabbitmq: listener: simple: prefetch: 1 acknowledge-mode: manual - @RabbitListener 方法里接收
Channel和Message - 业务逻辑执行完毕、事务提交后，再调用
channel.basicAck(...)
要监控和验证是否生效
光配了不等于起作用，得看实际运行效果：
- 打开 RabbitMQ 管理界面（http://localhost:15672），进对应队列页，盯住 Unacked 列
- 如果长期卡在接近 prefetchCount 的数值（比如设了 1，Unacked 常为 1），说明限流已生效
- 如果 Unacked 持续飙升远超设置值，检查是否忘了关 autoAck，或消费逻辑阻塞/没正确 ack
- 单消费者吞吐跟不上时，优先加消费者实例数，而不是盲目调高 prefetchCount
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
