RabbitMQ 理解集群模式：节点组成集群与元数据共享详解

原创于 2025-08-05 00:14:54 发布 · 1k 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#rabbitmq #集群模式 #学习

MQ 专栏收录该内容

156 篇文章

订阅专栏

RabbitMQ 理解集群模式：节点组成集群与元数据共享详解

在生产环境中，单节点 RabbitMQ 存在单点故障风险。为了实现高可用、高吞吐、可扩展，RabbitMQ 支持将多个节点组成集群（Cluster），共享用户、虚拟主机、队列定义等元数据，对外提供统一的消息服务。

本文将深入解析 RabbitMQ 集群的架构、工作原理、元数据共享机制、节点角色、集群模式与最佳实践。

一、RabbitMQ 集群的核心目标

目标	说明
✅ 高可用	某个节点宕机，服务仍可用（配合 HA 队列）
✅ 可扩展	通过增加节点提升连接数、吞吐量
✅ 统一管理	用户、vhost、策略等配置在集群中同步
✅ 负载均衡	客户端可连接任意节点，消息自动路由

⚠️ 注意：RabbitMQ 集群不自动复制消息数据，需配合 镜像队列（Mirrored） 或 仲裁队列（Quorum） 实现数据高可用

二、RabbitMQ 集群的基本架构

+----------------+     +----------------+     +----------------+
|  RabbitMQ Node |<--->|  RabbitMQ Node |<--->|  RabbitMQ Node |
|      A         |     |      B         |     |      C         |
+----------------+     +----------------+     +----------------+
       ↑                     ↑                     ↑
    Erlang VM             Erlang VM             Erlang VM
       ↑                     ↑                     ↑
   共享元数据（用户、vhost、队列定义、交换机、绑定等）

所有节点通过 Erlang 分布式协议通信
使用相同的 Erlang Cookie 认证
组成一个逻辑上的“单一消息代理”

三、集群中的节点角色

RabbitMQ 集群中的节点分为两种类型：

类型	说明	适用场景
Disc Node（磁盘节点）	将元数据持久化到磁盘，可作为配置源	至少需要 1 个
RAM Node（内存节点）	元数据仅保存在内存中，性能更高	用于扩展吞吐

✅ 最佳实践：

至少 2 个 Disc Node（避免单点故障）
其余为 RAM Node（提升性能）

四、共享的元数据（Metadata）

RabbitMQ 集群中，以下配置在所有节点间自动同步：

元数据类型	说明
✅ Users（用户）	用户名、密码、标签（Tags）
✅ Virtual Hosts（vhost）	虚拟主机定义
✅ Permissions（权限）	用户在 vhost 中的 configure/write/read 权限
✅ Queues（队列定义）	队列名称、是否持久化、参数（如 TTL、DLX）
✅ Exchanges（交换机定义）	交换机名称、类型、是否持久化
✅ Bindings（绑定）	Exchange 与 Queue 的路由关系
✅ Policies（策略）	镜像、TTL、队列模式等策略
✅ Parameters（参数）	Federation、Shovel 等插件参数

✅ 客户端连接任意节点，都能看到相同的资源视图

五、不共享的数据（需要 HA 机制）

以下数据不会自动复制，需通过高可用队列实现容错：

数据类型	说明
❌ 队列中的消息	默认只存在于一个节点（主节点）
❌ 未确认的消息（Unacked）	消费者未 ack 的消息
❌ 连接与信道状态	客户端连接在本地节点

✅ 解决方案：使用 Quorum Queue 或 镜像队列 实现消息跨节点复制

六、集群搭建步骤

1. 准备工作

所有节点安装相同版本 RabbitMQ
确保 Erlang Cookie 一致（位于 ~/.erlang.cookie 或 /var/lib/rabbitmq/.erlang.cookie）
开放端口：
- 4369：Erlang Port Mapper Daemon (epmd)
- 25672：Erlang 分布式通信
- 5672：AMQP
- 15672：Management UI（可选）

2. 停止应用并重置节点

# 在 node2 和 node3 上执行
rabbitmqctl stop_app
rabbitmqctl reset

3. 加入集群

# node2 加入 node1
rabbitmqctl join_cluster rabbit@node1

# node3 加入（可选为 RAM Node）
rabbitmqctl join_cluster --ram rabbit@node1

4. 启动应用

rabbitmqctl start_app

5. 验证集群状态

rabbitmqctl cluster_status

输出示例：

Cluster status of node 'rabbit@node1' ...
Basics
Cluster name: rabbitmq-cluster
Total nodes: 3
Nodes in this cluster: 
  rabbit@node1 (disc)
  rabbit@node2 (disc)
  rabbit@node3 (ram)

七、集群中的数据分布

1. 队列主节点（Leader）

每个队列有且只有一个 主节点（Leader）
所有读写操作由主节点处理
主节点宕机后，从节点选举新主（需 HA 队列）

2. 客户端连接任意节点

Producer → Node C → 消息被路由到 Queue 的主节点（Node A）
Consumer ← Node B ← 消息从主节点（Node A）获取

✅ 客户端无需知道队列在哪个节点

八、集群模式对比

模式	说明	适用场景
Classic Cluster	传统集群，配合镜像队列	旧系统兼容
Quorum Queue Cluster	基于 Raft，强一致性	推荐，关键业务
Stream Cluster	流式日志，高吞吐	日志、事件流

✅ 推荐使用 Quorum Queue 模式

九、高可用集群部署建议

项目	建议
节点数量	3 或 5 个（奇数）
Disc Node 数量	至少 2 个（防脑裂）
网络	同一局域网，低延迟
硬件	SSD、足够内存
负载均衡	使用 HAProxy 或 Keepalived 提供统一入口
监控	Prometheus + Grafana 监控各节点状态

十、常见问题解答（FAQ）

Q1：所有节点都必须是 Disc Node 吗？

❌ 不需要。建议 2 个 Disc Node + 多个 RAM Node。

Q2：如何修改集群节点？

添加：join_cluster
移除：forget_cluster_node
不能直接修改节点类型，需重置后重新加入

Q3：Erlang Cookie 不一致怎么办？

# 复制 cookie 到所有节点
scp /var/lib/rabbitmq/.erlang.cookie node2:/var/lib/rabbitmq/
chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie
chmod 600 /var/lib/rabbitmq/.erlang.cookie

Q4：集群中可以有不同版本的节点吗？

❌ 不推荐。可能导致兼容性问题。

Q5：客户端如何连接集群？

方式1：连接任意节点（适合测试）
方式2：使用 HAProxy 做负载均衡（生产推荐）

十一、最佳实践总结

实践	建议
✅ 使用 Quorum Queue 实现数据高可用	替代镜像队列
✅ 至少 2 个 Disc Node	防止单点故障
✅ 配置 HAProxy 负载均衡	对外提供统一入口
✅ 定期备份集群定义	`rabbitmqctl export_definitions`
✅ 监控各节点状态	内存、磁盘、连接数
✅ 避免跨机房部署	除非使用 Federation
✅ 使用相同版本和配置	避免兼容问题

十二、总结

特性	说明
共享元数据	用户、vhost、队列/交换机定义、绑定、策略
不共享数据	消息内容（需 HA 队列）
节点类型	Disc（持久化元数据）、RAM（高性能）
高可用依赖	Quorum Queue 或镜像队列
推荐模式	Quorum Queue 集群