rabbitmq本身不提供生产者侧负载均衡，需由生产者主动连接多节点并轮询选择，配合镜像队列分散主节点、exchange分片及连接复用策略实现写压力均衡。
RabbitMQ 本身不直接提供生产者侧的“负载均衡”逻辑，它是一个消息中间件，负载分摊的关键在于客户端（生产者）如何连接和发送消息，而非 RabbitMQ 集群自动路由生产请求。真正起作用的是：生产者主动连接多个节点、使用合理连接/信道复用策略、配合集群拓扑与镜像队列设计，从而将写压力分散到不同节点上。
生产者多节点连接 + 轮询/随机选择
默认情况下，一个生产者只连一个 Broker 节点，所有 publish 请求都打到该节点，容易形成单点写入瓶颈。解决方法是让生产者维护一组集群节点地址，在创建 Connection 时轮询或随机选取目标节点：
- 初始化时配置多个节点 IP+端口（如 192.168.1.10:5672、192.168.1.11:5672、192.168.1.12:5672）
- 每次新建 Connection 前，用 ThreadLocal 或全局负载算法（如加权轮询）选一个节点，避免所有线程挤同一台
- 注意：Connection 是重量级对象，不要为每次发消息建新连接；应复用 Connection，按业务维度（如租户、场景）分配专属 Connection
启用镜像队列 + 均匀声明队列位置
即使生产者分散连接，若所有消息都发往同一个队列（比如都发到 order.queue），而该队列只在某节点上主写，压力仍集中。需配合镜像队列策略，让队列主副本尽可能分布在不同节点：
- 设置策略使队列自动镜像（如 ha-mode: all 或 ha-mode: exactly, ha-params: 3）
- 关键点：RabbitMQ 的队列主节点（master）由首次声明它的连接所在节点决定。因此，要让不同生产者连接不同节点后，各自声明自己的队列（或使用随机后缀），避免全量队列都在同一节点创建
- 例如：订单服务启动时，按实例 ID 或机器名生成队列名 order.queue.{host}，再声明 —— 这样主节点天然分散
使用 Exchange + 多绑定 + 生产者本地分片
若业务允许，可把单个逻辑队列拆成多个物理队列（如 order.queue.shard01 ~ shard08），通过 Exchange 绑定到同一交换器，并由生产者按 key 做一致性哈希或取模选择 shard：
- 定义一个 direct 或 topic Exchange，绑定 8 个队列，每个队列对应一个分片
- 生产者根据消息业务 ID（如 order_id）计算 hash % 8，决定发往哪个 routing key（即哪个 shard）
- 这样写请求天然分散到多个队列，而每个队列的主节点又可落在不同 Broker 上，双重分散写压力
- 注意：需保证消费者也按相同规则消费对应 shard，避免语义错乱
避免连接风暴与连接复用优化
高并发下，如果每个线程都新建 Connection，会迅速耗尽文件句柄和内存，反而压垮节点。必须做好连接生命周期管理：
- 一个 JVM 进程内，按用途（如普通消息、延迟消息、死信）建立有限个 Connection（建议 ≤ 5 个），每个 Connection 开多个 Channel（Channel 是轻量级的）
- 使用连接池（如 CachingConnectionFactory 在 Spring AMQP 中）或自研 Connection 管理器，支持失败自动切换节点
- 开启 heartbeat 和 connection recovery，防止网络闪断导致连接堆积或重连风暴
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
