在 CentOS 上选择 RabbitMQ 高可用方案
一、方案总览与适用场景
- 普通集群：仅同步元数据，队列只存在于一个节点；某节点宕机会导致该节点上未被消费的消息不可达（持久化消息需等节点恢复）。适合允许短暂不可用、追求吞吐的场景。
- 镜像队列（Classic Queue Mirroring）：队列内容在多个节点间同步，单节点故障可切换；但会带来同步带宽与性能开销，节点越多开销越大。适合强一致与高可用优先的场景。
- 仲裁队列（Quorum Queue，RabbitMQ 3.8+）：基于 Raft 的副本机制，写入需多数派确认，故障恢复能力强，推荐作为新系统的默认队列类型。
- 跨机房/跨地域：用 Federation/Shovel 做队列/集群间的异步复制与桥接，适合灾备、多活与解耦。
- 入口高可用：在集群前放置 HAProxy + Keepalived（VRRP），对外暴露 VIP，避免负载均衡器单点。
以上要点分别来自对集群模式、镜像队列、仲裁队列与 Federation/Shovel 的实践与官方文档说明。
二、如何选择（决策表）
| 场景/诉求 |
推荐队列类型 |
拓扑与组件 |
关键配置要点 |
| 新系统、强一致、可容忍一定写入延迟 |
Quorum Queue |
3 节点以上集群；对外用 HAProxy+Keepalived |
队列声明 x-queue-type=quorum；镜像数通常设为 n/2+1；开启管理插件监控 |
| 已有系统、需快速提升可用性 |
镜像队列 Classic |
3 节点集群；HAProxy+Keepalived |
策略示例：ha-mode=exactly, ha-params=n/2+1, ha-sync-mode=automatic；避免 ha-mode=all |
| 吞吐优先、可接受短暂不可用 |
普通集群 |
多节点集群；HAProxy 分发连接 |
客户端均衡连接各节点；持久化+确认机制；故障节点恢复后重连 |
| 跨机房/跨地域容灾 |
Federation/Shovel |
多集群部署 |
按 vhost/exchange/queue 配置上游/下游；注意网络时延与一致性边界 |
| 云上托管、免运维 |
托管集群 + 镜像/仲裁策略 |
云厂商 RabbitMQ 服务 |
在控制台设置镜像/仲裁策略与参数；结合云 LB 与健康检查 |
说明：镜像队列的“n/2+1”可在保证高可用的同时控制网络与磁盘 I/O 开销；仲裁队列为 3.8+ 推荐的高可用队列类型；入口高可用建议 HAProxy+Keepalived 提供 VIP。
三、CentOS 上的落地要点
- 版本匹配与安装：确保 Erlang 与 RabbitMQ 版本匹配；在 CentOS 7 上常见可用组合如 Erlang 23.x + RabbitMQ 3.9.x；启用管理插件（15672）。
- 集群基础：
- 统一 Erlang Cookie（常见路径：/var/lib/rabbitmq/.erlang.cookie 或 /root/.erlang.cookie），权限 400；
- 配置 /etc/hosts 使节点可解析；
- 节点加入集群：stop_app → join_cluster → start_app；用 rabbitmqctl cluster_status 校验。
- 队列高可用：
- 镜像队列策略示例：对所有队列设置 exactly n/2+1 副本、自动同步：
rabbitmqctl set_policy ha-q ‘^’ ‘{“ha-mode”:“exactly”,“ha-params”:2,“ha-sync-mode”:“automatic”}’
- 仲裁队列：声明队列时设置 x-queue-type=quorum（客户端或策略方式）。
- 入口高可用：
- HAProxy 做 4 层 TCP 转发（5672）与健康检查；
- Keepalived 提供 VIP 与 VRRP 故障切换，避免单点。
- 防火墙与端口：放行 5672（AMQP）、15672（管理）、必要时 8100（HAProxy 统计）。
四、常见坑与优化建议
- 镜像队列并非“越多越好”：全量镜像（ha-mode=all）会放大网络与磁盘 I/O；优先使用 exactly n/2+1，在可用性与成本间平衡。
- 普通集群无法高可用：队列只在一个节点，宕机会影响未消费消息；若使用持久化，需等节点恢复才可继续消费。
- 节点类型与数量：集群至少保留 1 个磁盘节点 以持久化元数据；普通集群可混用 RAM/Disk，但请控制数量与角色。
- Cookie 与权限：Cookie 不一致会导致无法建集群；拷贝后注意 权限 400 与属主；为生产创建专用管理员账号与 vhost。
- 升级与队列类型：从 Classic Queue 迁移到 Quorum Queue 需评估应用兼容性（确认机制、幂等、重回队列策略等）。
