RabbitMQ消费者天然支持负载均衡，因其Broker端基于AMQP协议的basic.qos与basic.consume预取机制实现服务端轮询分发：多个消费者连接同一队列时，Broker按prefetchCount（推荐设为1或10）自动分配未确认消息，并依赖手动ack、durable队列、持久化消息三者协同保障不丢失。
多个消费者实例连接同一个队列时，RabbitMQ 默认就具备负载均衡能力，不需要额外实现“集群负载均衡策略”——它靠的是 AMQP 协议层的 basic.qos 和 basic.consume 的预取机制，而不是你在 Java 侧手动分发消息。
为什么 RabbitMQ 消费者天然支持负载均衡
RabbitMQ 的负载均衡发生在 Broker 端：当多个消费者同时对同一队列调用 channel.basicConsume()，Broker 会按预取值（prefetchCount）轮询分发未确认（unack）的消息。这不是客户端算法，而是服务端调度行为。
关键点：
-
prefetchCount设置过大会导致消息堆积在某个消费者内存中，其他消费者空闲 - 设置为
1（即channel.basicQos(1)）最公平，但吞吐可能下降；设为10是常见折中 - 必须配合手动 ack（
channel.basicAck()），否则消息不会被重新分发 - 消费者进程崩溃或连接断开时，未 ack 的消息会自动 requeue（取决于
requeue参数）
Java 客户端必须配置的三项
不配这三项，所谓“高可用集群”只是多个进程连上去了，实际负载不均、故障不恢复、消息可能丢失。
立即学习“Java免费学习笔记（深入）”；
- 启用手动 ack：
channel.basicConsume(queueName, false, ...)第二个参数为false - 设置 QoS 预取：
channel.basicQos(1)或channel.basicQos(0, 10, false)（推荐显式指定 global=false） - 关闭自动重连的“假高可用”：
factory.setAutomaticRecoveryEnabled(false)—— 真正的高可用靠 Spring AMQP 的SimpleMessageListenerContainer或自建重连逻辑，原生客户端的 automatic recovery 在网络抖动时容易丢 ack 状态
消费者宕机后消息如何不丢失
这不是 Java 代码能单独解决的问题，依赖三处协同：
- 声明队列时设
durable=true（对应channel.queueDeclare(queueName, true, false, false, null)） - 发送消息时设
MessageProperties.DELIVERY_MODE_PERSISTENT（即2） - 消费者处理完后必须调用
channel.basicAck(deliveryTag, false)，且不能跳过异常分支
漏掉任意一项，重启 RabbitMQ 节点后消息就没了。尤其注意：Spring Boot 默认 spring.rabbitmq.listener.simple.acknowledge-mode=auto，这会让框架帮你 ack，但一旦业务逻辑抛异常又没配置 default-requeue-rejected=true，消息就进死信队列或直接丢弃。
别在 Java 层做“负载决策”
见过有人用 Redis 计数、ZooKeeper 选主、甚至 HTTP 接口协调多个消费者谁该消费哪条消息——完全没必要，而且引入单点和延迟。RabbitMQ 的队列本身就是分布式任务队列，它的并发消费模型已经过十年生产验证。
真正要花精力的地方是：
- 确保每个消费者实例的 JVM 堆内存和 GC 行为稳定（避免因 Full GC 导致 ack 延迟超时）
- 监控
queue_unacknowledged_messages指标，持续增长说明某些消费者卡住或没正确 ack - 使用
x-dead-letter-exchange给队列加死信路由，而不是让失败消息无限重试
高可用的关键不在“多连几个消费者”，而在“每个消费者都可靠地完成一次消息生命周期”。
