前面讲的存储、客户端都局限在单节点。这一篇开始讲集群——多个 RabbitMQ 节点怎么组成一个逻辑整体。
RabbitMQ 集群有一个最容易被误解的特性，这个误解会直接影响高可用设计：集群默认不复制消息，只复制元数据。很多人以为「组了集群就有了高可用」，结果节点一挂消息全丢。这一篇先把集群的拓扑和这个关键特性讲清楚，为后面几篇（元数据、网络分区、容灾）打底。
集群是什么：共享元数据的节点组
RabbitMQ 集群是多个 broker 节点组成的逻辑组，它们之间共享：
- 元数据：用户、vhost、Exchange、Queue 的定义、Binding 规则、权限。这些在所有节点间同步。
- 不共享的是消息本身：默认情况下，一个队列的消息只存在声明它的那个节点上，不会自动复制到其他节点。
这个「元数据共享、消息不共享」的结构，意味着集群的默认能力是：
- 客户端可以连任意节点：因为元数据全节点都有，连哪个节点都能看到所有 Exchange、Queue 的定义。如果连到的节点上没有目标队列，它会透明转发到有队列的那个节点。
- 单节点故障会丢该节点上的队列消息：因为消息没复制，节点挂了它上面的队列（和消息）就没了（除非用了 Quorum/镜像，那是额外的复制层）。
所以集群本身解决的是「统一管理和访问」问题，不解决「高可用」问题。高可用要靠 Quorum Queue 或（已废弃的）镜像队列在集群之上做消息复制。这是理解 RabbitMQ 集群最重要的一点。
disk 节点与 ram 节点
集群里的节点有两种类型：
- disk 节点（持久节点）：把元数据持久化到磁盘。集群重启后，元数据从 disk 节点恢复。
- ram 节点（内存节点）：元数据只放内存，不持久化。重启后元数据丢失，要从其他节点同步。
ram 节点的存在是为了性能——元数据操作（声明队列、绑定）在 ram 节点上更快（不写盘）。但代价是 ram 节点重启后元数据丢失，必须依赖 disk 节点恢复。
集群的规则：集群里至少要有一个 disk 节点，负责持久化元数据。可以全是 disk 节点，也可以混合（多数 disk + 少数 ram）。元数据的变更（如新建队列）必须先在 disk 节点落盘，再同步给 ram 节点。
实际部署的常见形态：
- 小集群（3 节点）：全 disk 节点。简单、可靠，ram 节点的性能收益在元数据操作上不明显，不值得引入复杂度。
- 大集群（多节点）：2 个 disk 节点 + 若干 ram 节点。元数据操作集中在 ram 节点，性能更好；disk 节点保证持久化。
这里有个演进背景：在 Khepri（下一篇详谈）成为默认元数据存储后，disk/ram 的区分变得不那么重要——Khepri 基于 Raft，元数据本身就是多副本强一致的，不再依赖传统的 disk/ram 模型。但在理解 RabbitMQ 的历史和存量系统时，disk/ram 的概念仍然要懂。
集群与队列的关系
集群里，队列是「在某个节点上」的。声明队列时，如果不指定，队列会被创建在客户端连接的那个节点上（或按某种规则分配）。队列的元数据（定义、绑定）会同步到所有节点，但队列本身（消息）只在一个节点。
这就引出一个特性：客户端连到 A 节点，要消费 B 节点上的队列，可以工作。A 节点知道队列在 B 上，会透明地把消费请求转发到 B。但这个转发有网络开销，生产环境下，连接队列所在节点更高效。
要让队列在多节点上有副本（高可用），要用 Quorum Queue。Quorum Queue 的「多副本」是建立在集群之上的——它在集群的多个节点上各放一份副本，靠 Raft 同步。所以集群是 Quorum 的前提，Quorum 是集群之上的高可用层。
集群的网络要求
集群节点之间通过 Erlang 的分布式通信（基于 TCP）交换元数据和转发请求。对网络的要求：
- 节点间要能互相解析主机名（通常配置 hostname 或用 DNS）。
- Erlang cookie 要一致：节点间用同一个 cookie 鉴权，cookie 不同无法组集群。
- 网络延迟要低：元数据同步是同步操作，延迟高会拖慢所有元数据变更。
- 带宽要够：跨节点的消费转发、Quorum 的复制都要走网络。
跨可用区组集群时，节点间延迟可能几十毫秒，这会影响 Quorum 的写入吞吐（每条消息要等多数确认）。所以跨 AZ 集群要权衡——为了容灾拉远距离集群，要接受吞吐的损失。
集群规模的上限
RabbitMQ 集群不是越大越好。官方建议集群节点数控制在 3–7 个，原因：
- 元数据同步开销随节点数增长。每个元数据变更要同步到所有节点。
- Erlang 的全连接拓扑：节点间两两连接，连接数是 O(n²) 增长。
- Quorum 的 Raft 开销在大集群下更明显。
超过 7 个节点的集群，性能反而下降。更大的规模需求，应该用 Federation（跨集群联邦，第 25 篇讲）而不是单一大集群。
集群与高可用的层次关系
把集群、Quorum、镜像的关系理清楚，这是很多人混淆的点：
- 集群：多节点共享元数据，提供统一访问。不解决高可用。
- Quorum Queue：在集群之上，给单个队列做多副本（Raft），解决该队列的高可用。
- 镜像队列（已废弃）：曾经的另一个多副本方案，4.0 移除。
所以一个典型的高可用部署是：3 节点集群 + 核心队列用 Quorum 声明。集群提供基础设施，Quorum 提供队列级的高可用。两者缺一不可——没有集群，Quorum 无处部署副本；没有 Quorum，集群里的队列仍是单点。
收束：集群是基础设施，不是高可用本身
这一篇的核心是一个祛魅：RabbitMQ 集群本身不是高可用方案。它解决的是「统一管理和访问」，消息的高可用要靠 Quorum Queue 这类在集群之上做复制的机制。理解了这层关系，才不会在「组了集群」之后依然遇到节点挂了丢消息的尴尬。
下一篇讲集群的元数据存储——从 Mnesia 到 Khepri 的演进，那是理解集群内部一致性的关键。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。想跟完这套「图解 RabbitMQ」，欢迎关注公众号 「十三Tech」。
