在 Ubuntu 上实现 RabbitMQ 高可用
一、架构选型与前置准备
- 架构建议：至少部署3 个节点的集群，节点类型包含磁盘节点（disc）与内存节点（ram）；集群中必须至少有1 个磁盘节点，推荐2 个磁盘 + 1 个内存以兼顾可靠性与吞吐。对于队列类型，优先使用仲裁队列（Quorum Queues），基于 Raft 提供更强的一致性与自动选主；经典镜像队列（Mirrored Queues）已不推荐。仲裁队列至少需要3 个节点参与。为提升入口可用性，建议在前面放置 HAProxy 或同等负载均衡器进行连接分发与健康检查。以上选型与做法适用于 Ubuntu 20.04/22.04 等常见 LTS 版本。
二、Ubuntu 上的集群部署步骤
- 主机与解析：为每台机器设置唯一主机名（如 node1、node2、node3），并在所有节点的 /etc/hosts 中写入所有节点的 IP 与主机名 映射，确保节点间可互相解析。
- 安装与启停：在所有节点安装 Erlang 与 RabbitMQ（可使用 APT 官方仓库或系统仓库），完成后启动服务并启用管理插件以便观测与运维（管理端口默认为 15672）。
- 形成集群：选择第一个节点为种子节点，其余节点依次执行“stop_app → reset → join_cluster → start_app”加入集群；加入时可按需指定 –ram 成为内存节点，未指定即为磁盘节点。示例（在 node2 上）：
- rabbitmqctl -n rabbit2 stop_app
- rabbitmqctl -n rabbit2 reset
- rabbitmqctl -n rabbit2 join_cluster rabbit@node1
- rabbitmqctl -n rabbit2 start_app
- 验证：在任意节点执行 rabbitmqctl cluster_status，应能看到所有节点及其类型（disc/ram）。
三、队列与数据的高可用配置
- 仲裁队列（推荐）：在业务代码声明队列时指定参数 x-queue-type=quorum，队列将基于 Raft 自动完成复制与选主，具备更强的数据安全性与自动故障转移能力。适用于对消息不丢要求较高的场景。
- 镜像队列（兼容旧系统）：如仍需使用经典镜像队列，可通过策略将所有或匹配前缀的队列镜像到多个节点，例如：
- rabbitmqctl set_policy ha-all “^” ‘{“ha-mode”:“all”}’
注意：镜像队列为传统方案，存在网络分区时的一致性与可用性权衡，官方已不推荐，且在 3.13+ 版本中默认禁用。
- 持久化配合：为降低消息丢失风险，业务侧建议将队列与消息设置为持久化（durable=true），并结合发布确认（publisher confirms）与消费者确认（ack）机制共同使用。
四、入口高可用与运维要点
- 负载均衡与健康检查：在 HAProxy 中配置 5672（AMQP）与 15672（管理）前端与健康检查后端，示例片段：
- frontend rabbitmq bind *:5672
default_backend rabbitmq_nodes
- backend rabbitmq_nodes balance roundrobin
server rabbit1 10.0.0.11:5672 check
server rabbit2 10.0.0.12:5672 check
server rabbit3 10.0.0.13:5672 check
生产上建议配合 TCP 健康检查 与 虚 IP（VIP）/Keepalived 实现入口层面的故障转移与平滑切换。
- 网络与分区处理：确保节点间 4369（epmd）/25672（集群分发）/5672/15672 等端口放通；对可能发生的网络分区，建议配置 cluster_partition_handling = pause_minority 并结合业务容忍度选择自动恢复策略，以降低“脑裂”风险。
- 资源与告警：在 /etc/rabbitmq/rabbitmq.conf 中设置关键水位与磁盘阈值，例如：
- vm_memory_high_watermark.relative = 0.7
- disk_free_limit.absolute = 50MB
同时启用管理插件并监控 /var/log/rabbitmq/ 日志与管理界面指标，及时处置内存、磁盘与连接告警。