RabbitMQ集群高可用实战：HAProxy负载均衡配置与踩坑指南

生产环境里的 RabbitMQ 如果要扛住真实业务流量，单节点基本撑不了多久。内存被打满、磁盘告警、连接数飙升，任何一个坑都够运维喝一壶。我见过不少团队上了 RabbitMQ 集群，结果客户端只配了一个节点地址，节点一挂业务直接瘫痪。后来想明白了一件事：集群归集群，入口必须统一。本文就围绕“RabbitMQ HAProxy 负载均衡”这条主线，讲讲为什么要在 RabbitMQ 集群前面加一层 HAProxy，HAProxy 该怎么配置、健康检查怎么设计、客户端怎么接入，以及我在实际部署中踩过的一些坑。适合正在做 RabbitMQ 集群高可用改造、或者想理解消息中间件接入层设计的朋友参考。

1. 整体方案设计与选型思路

1.1 为什么要在 RabbitMQ 前面加一层 HAProxy

很多初学者对“集群”有个误解，觉得把三个 RabbitMQ 节点组成集群，客户端随便连哪个都行。理论上是这样，但实际生产中会遇到三个很现实的问题。

第一，客户端配置的是固定 IP。如果集群里某个节点宕机了，客户端不知道要切换地址，除非你在代码里写死多个地址并自己实现故障转移。大多数业务团队不会这么干，也不应该这么干。

第二，节点扩容或者缩容时，客户端配置要跟着改。今天三个节点，明天加到五个，所有客户端连接串都要动一遍，这是灾难级的运维成本。

第三，连接不均衡。三个节点，有的客户端连 A，有的连 B，有的连 C，时间一长每个节点的连接数和负载完全不一样，资源利用率很差。

HAProxy 在中间起的作用就是一个“统一入口”。它对外暴露一个虚拟地址和端口，客户端只认这一条路，HAProxy 再把请求按策略转发给后端的 RabbitMQ 节点。后端的节点挂了、加了、换了，客户端完全无感知，运维只需要改 HAProxy 配置就够了。

有人可能会问：用 Nginx 做 TCP 转发不行吗？行，Nginx 从 1.9 开始支持 stream 模块，也能做四层代理。但 HAProxy 在负载均衡算法、健康检查、连接调度、统计监控这些方面更成熟，尤其是对长连接场景的支持和细粒度的连接管理，HAProxy 明显更顺手。身边做消息中间件运维的朋友，绝大多数用的都是 HAProxy。

1.2 负载均衡方案的横向对比

为了把选型逻辑讲清楚，我列一下常见方案的对比，包括客户端多地址、Nginx TCP 代理、HAProxy、LVS 这几种。

另外提一个容易混淆的点：像 OpenFeign 内部集成的负载均衡（比如 Ribbon、Spring Cloud LoadBalancer）是客户端侧的负载均衡，属于“调用方自己做选择”的模式。而 HAProxy 这种是服务端接入层的负载均衡，对客户端透明。两者不是同一个层面，别搞混了。

从成本和收益角度综合考虑，大部分团队选 HAProxy 是最合理的。单机 HAProxy 跑满十万级并发连接毫无压力，对 RabbitMQ 这种规模的消息中间件来说完全够用。如果担心 HAProxy 自身单点，后面再加 Keepalived 做 VIP 漂移，这个我后面会展开讲。

1.3 “等开销负载均衡”到底是什么意思

热搜词里有个“等开销负载均衡”，我理解大家想问的是：负载均衡是怎样做到让每个后端节点的开销大致相等的。这里的“开销”可以理解为连接数、CPU、内存、网络带宽等资源消耗。

HAProxy 的 roundrobin（轮询）算法，就是让请求按顺序轮流分发到每个后端节点，每个节点接收的请求数量大致相同，这是一种“等开销”的思路。但实际生产中有个问题：RabbitMQ 的 AMQP 连接是长连接，客户端连上之后会一直保持，如果某个客户端发的消息量特别大，即使每个节点连接数差不多，节点间的真实负载也可能差异很大。

所以针对 RabbitMQ 这种长连接场景，我更推荐 leastconn（最小连接数）算法。HAProxy 会实时统计每个后端的活跃连接数，新连接永远分给当前连接数最少的节点。这样能在连接分配层面做到更贴近“等开销”的效果。具体配置用哪种，后面配置章节我会给出建议。

2. RabbitMQ 集群准备

2.1 节点规划与端口说明

在配置 HAProxy 之前，前提是要有一个健康的 RabbitMQ 集群。以三节点为例，我通常会这样规划：

需要说明的是，RabbitMQ 集群要求至少有一个磁盘节点。如果全部都是内存节点，重启后元数据会丢失。生产环境我一般建议全部用磁盘节点，尤其是节点数量不多的时候，磁盘节点更省心。

端口方面要清楚每个端口的作用：