RabbitMQ多消费者负载均衡依赖prefetch设置：设为1实现公平分发，避免慢消费者积压；设过大导致消息囤积、负载不均；需配合手动ACK、concurrency配置及管理界面监控unack数与消费者数验证效果。
关键不在“堆数量”，而在于让消息在多个消费者之间真正流动起来——预取计数（prefetch）是调度权的开关，设得对，才能把并发能力变成实际吞吐。
prefetch 是怎么影响多消费者负载均衡的
当多个消费者监听同一个队列时，RabbitMQ 默认按“轮询”分发消息。但这个轮询不是实时的：它会先把一批消息推给某个消费者，等这批消息被确认（ack）后，再推下一批。如果 prefetch 设得太大（比如 50），一个消费者可能一口气拉走 50 条消息，卡在内存里慢慢处理；其他消费者明明空闲，却拿不到新任务——造成“忙的累死、闲的发呆”。
反过来，设为 1 就相当于“按需领取”：每个消费者处理完一条、确认一条，才被允许领下一条。这样消息天然向空闲消费者倾斜，负载更均匀。
不同场景下的推荐 prefetch 值
没有万能值，要结合单条消息处理耗时和消费者数量来定：
- CPU 密集型/耗时长（如图像识别、报表生成）：prefetch = 1。避免消息囤积在慢消费者手里，确保空闲实例能及时接活。
- I/O 等待型/耗时中等（如查库+写日志）：prefetch = 5～10。平衡网络开销与资源利用率，防止频繁等待下一批。
- 纯内存计算/极快响应（如简单字段校验）：prefetch = 20～50。减少 ACK 往返次数，压榨单线程吞吐。
必须配套的手动签收和并发配置
光调 prefetch 没用，以下三点缺一不可：
立即学习“Java免费学习笔记（深入）”；
- autoAck 必须设为 false —— 否则 RabbitMQ 一推送就认为成功，prefetch 完全失效；
- 每个消息处理完后显式调用 channel.basicAck(deliveryTag, false)，失败时用 basicNack 决定是否重试；
- Spring Boot 中通过 concurrency 控制消费者线程数（如 concurrency: "3-8"），配合 prefetch 才能发挥多线程优势。
怎么验证配置生效了
别只看代码有没有配，要盯住 RabbitMQ 管理界面的两个数字：
- messages_unacknowledged：整个队列未确认的消息总数。它应该稳定在 concurrency × prefetch 附近，大幅偏离说明某消费者卡住或配置没加载；
- consumers：活跃消费者数量。如果设了 concurrency=5 却只显示 1 个，可能是连接异常或监听器没启动。
