张瑞151293780301. 为什么给 RabbitMQ 集群配负载均衡是刚需
先说一个场景：你负责的消息系统跑了两台 RabbitMQ 节点，平时流量不大，一切岁月静好。突然某天业务方做了大促，生产者疯狂 publish，消费者机器扩容，结果一台节点 CPU 直接飙到 90%，另一个节点闲得发慌。业务方吐槽消息延迟，运维排查半天发现客户端只连了其中一台节点。
这不是个例。RabbitMQ 本身是集群架构，但默认情况下客户端如果只配置一个节点的地址，它就是单点；配置多个地址，RabbitMQ 客户端库虽然会按列表轮询，可一旦某个节点挂掉，客户端重连逻辑未必能优雅处理，而且也没有基于后端节点真实负载的调度。这时候就需要在客户端和 RabbitMQ 集群之间挡一层 “流量调度器”——负载均衡器。
HAProxy 是我在实际项目里用得最顺手的方案。它轻量、配置清晰、支持四层 TCP 转发，非常适合做 RabbitMQ 这种 AMQP 协议的负载均衡。RabbitMQ 的 AMQP 协议走的是 TCP + 长连接，HAProxy 工作在四层（tcp mode）就能搞定，不用像 HTTP 那样解析七层，省掉很多麻烦。再加上 HAProxy 的 health check 能自动剔除挂掉的节点，生产环境下基本上就是 “配一次，稳定跑大半年”。
这篇文章我会把从零搭建 RabbitMQ 双节点集群 + HAProxy 负载均衡的完整过程写出来，包括集群搭建、HAProxy 配置参数解析、故障切换验证，以及我踩过的坑。适合正在选型消息中间件、或者已经被 RabbitMQ 高可用问题困扰的开发者参考。即使你还没用 Docker，我也会给出后续平滑迁移的思路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心设计思路与方案选型
2.1 为什么不是 Nginx 或 LVS
不少新手上来就问：Nginx 也能做负载均衡，为什么不用它？Nginx 本质上是七层反向代理，它的 stream 模块虽然也支持 TCP 转发，但设计重心还是 HTTP 场景，如果只是给 RabbitMQ 做四层转发，功能上可行，但配置手感和生态支撑不如 HAProxy 纯粹。你可能遇到 TLS 终止、会话保持、统计页面这些细节，HAProxy 默认就做得很顺手。
LVS 是内核态的负载均衡，性能天花板非常高，很多大型互联网公司在用。但部署要动网络结构，DR 模式还要调整 VIP、路由策略，对大多数中小团队来说太重了。HAProxy 是用户态进程，单机处理几万连接没什么问题，对 RabbitMQ 这种请求量级的产品绰绰有余。所以说，方案选型不是选性能最好的，而是选最合适当前团队运维能力、业务规模、故障恢复速度的。
2.2 等开销算法的实际意义
HAProxy 默认的负载均衡算法有 roundrobin、leastconn、source、uri 等。对 RabbitMQ 这种长连接型应用，别用 roundrobin，因为连接一旦建立就会一直占着。如果每台客户端只建立一条长连接，roundrobin 会把连接均匀分布到各节点；但麻烦在于如果某个客户端断开重连，或者有些客户端是多连接，时间长了节点连接数会失衡。
我最终用的是 leastconn，这个算法会实时把新连接分配给当前活动连接最少的节点。虽然 RabbitMQ 的负载压力不完全等同于连接数，但连接数是最直观的软负载指标。HAProxy 还有 update-failover 这种细节参数配合 leastconn 用，后面配置里会讲到。
如果你的网络里有多个机房的客户端，还可以考虑 source 算法，按客户端 IP 哈希固定到某个节点，减少跨机房访问。我这边单机房多客户端场景，leastconn 最实用。
2.3 集群拓扑设计
我推荐的最小高可用拓扑是：
- 两台 RabbitMQ 节点，互为主备（实际是镜像队列模式）
- 一台 HAProxy 做入口，下方挂两个节点
- 客户端只连接 HAProxy 的 VIP/地址
如果 HAProxy 本身也是单点，理论上它挂了所有流量就断了。很多团队会再起一台 HAProxy 做双活，然后用 keepalived 做 VIP 漂移。这个属于进阶内容，本文先覆盖单台 HAProxy + 双 RabbitMQ 节点的基础架构，但我在配置里会把 health check 和故障剔除做好，这样后面你加第二台 HAProxy 时只需要把同样的配置复制一份即可。
2.4 镜像队列的重要性
做负载均衡之前，首先要确认 RabbitMQ 集群本身是高可用的。很多新手以为 RabbitMQ 节点做一个普通集群就万事大吉，然后发现某个节点宕机后消息丢失。原因在于默认集群模式下，队列的元数据同步了，但队列主体数据只在某个节点上保存。换句话说，普通集群适合吞吐扩展，不适合高可靠。要保证消息不丢，必须用镜像队列。
从 RabbitMQ 3.8 开始官方推荐 Quorum Queue，这是基于 Raft 协议的队列，能替代镜像队列。我这边生产环境还在用镜像队列，因为历史原因，但如果你是从头搭建，建议直接用 Quorum Queue，配置 x-queue-type=quorum 即可。本文后面在集群配置时会提到这点，你根据自己版本选型即可。
3. 实操：从零搭建 RabbitMQ 集群
3.1 环境准备
我这里用 Docker Compose 来搭建，便于快速复现和迁移。相比直接在 Windows 上装 RabbitMQ 服务，Docker 部署最大的好处是环境隔离和一致性。如果你手头是 Windows 机器，想在本地折腾，官方 exe 安装包也能用，但注意集群节点之间通信需要改 hostname，Windows 上改 hostname 要重启，比较麻烦。
我的环境是两台 Linux 虚拟机，分别叫 rabbit-1 和 rabbit-2，IP 为 192.168.1.10 和 192.168.1.20。Docker 镜像版本用 rabbitmq:3.12-management，自带 web 管理插件，方便调试。生产环境建议去掉 management 插件镜像，减少暴露面，但本地玩就无所谓。
先创建目录结构：
bash复制mkdir -p /o