生产环境里不会只部署一台 RabbitMQ。单节点一旦宕机，消息投递、消费和队列数据都可能受影响。所以 RabbitMQ 高可用面试题通常围绕三种方案展开：普通集群、镜像队列、仲裁队列。
一句话概括：普通集群主要共享元数据，不复制队列消息；镜像队列把队列消息同步到多个节点，是一主多从；仲裁队列用 Raft 做主从复制，是课件里推荐用来替代镜像队列的新方案。
普通集群
普通集群也叫标准集群。它的核心特点是：多个 RabbitMQ 节点组成集群，共享交换机、队列等元信息，但队列里的消息默认只在队列所在节点上。
普通集群的特点：
| 特点 | 说明 |
|---|---|
| 元数据共享 | 交换机、队列、绑定关系会在节点间同步 |
| 消息不复制 | 队列中的消息只在所属节点 |
| 可以跨节点访问 | 访问非队列所在节点时，会转发到真正节点 |
| 宕机风险 | 队列所在节点宕机，队列消息可能不可用或丢失 |
所以普通集群更像是“管理层面的集群”，不能单独解决队列消息高可用。
镜像队列
镜像队列是 RabbitMQ 传统的高可用方案，本质是一主多从。
先注意版本边界：镜像队列属于历史方案，RabbitMQ 新版本更推荐仲裁队列或 Stream。做存量系统面试时可以讲镜像队列，但新项目不要把它当成首选高可用方案。
镜像队列的特征：
| 特征 | 说明 |
|---|---|
| 主从结构 | 创建队列的节点是主节点，其他节点是镜像 |
| 消息同步 | 交换机、队列、消息会在镜像节点间同步 |
| 主节点处理操作 | 生产、消费等操作由主节点完成，再同步给镜像节点 |
| 故障切换 | 主节点宕机后，镜像节点可以提升为新主 |
镜像队列能提高可用性，但也有代价：同步复制会带来网络和磁盘压力。如果主节点在同步完成前宕机，仍可能出现数据丢失。
它还有一个容易误解的点：镜像队列提升的是可用性，不是横向分摊消费压力。一个队列仍然由 leader 处理主要操作，镜像节点复制数据，并不会让同一个队列的吞吐随着镜像数量线性增长。
仲裁队列
仲裁队列是 RabbitMQ 3.8 之后提供的队列类型，课件里明确说它用于替代镜像队列。
它同样是一主多从，但同步基于 Raft 协议，强调一致性和明确的复制语义。
Spring AMQP 中声明仲裁队列很简单：
@BeanpublicQueuequorumQueue(){returnQueueBuilder.durable("quorum.queue")// quorum 表示声明仲裁队列，用 Raft 复制替代传统镜像队列。.quorum().build();}仲裁队列的特点：
| 特点 | 说明 |
|---|---|
| 主从复制 | 和镜像队列一样有主节点和从节点 |
| Raft 协议 | 复制更强调一致性 |
| 配置简单 | 声明队列时指定quorum即可 |
| 更适合新项目 | 适合作为高可靠队列方案 |
三种方案对比
| 方案 | 是否复制消息 | 故障切换 | 适合场景 |
|---|---|---|---|
| 普通集群 | 否 | 队列所在节点宕机会影响消息 | 元数据集群、非关键队列 |
| 镜像队列 | 是 | 镜像可提升为主 | 存量系统、历史方案 |
| 仲裁队列 | 是 | 基于 Raft 选主 | 新系统、可靠性要求高的队列 |
面试里如果提到项目使用镜像队列，可以补一句：镜像队列是一主多从，主宕机后镜像节点提升为新主；如果要进一步降低同步不完整导致的数据丢失风险，可以考虑仲裁队列。
面试回答模板
可以这样答：
RabbitMQ 高可用可以从普通集群、镜像队列和仲裁队列三个层面回答。普通集群会在多个节点间共享交换机、队列等元数据，但队列里的消息默认只在队列所在节点，所以队列节点宕机会影响消息。镜像队列是一主多从，队列消息会同步到镜像节点，所有操作由主节点完成，主宕机后镜像节点可以提升为新主，但它是历史方案，新版本更推荐仲裁队列或 Stream，而且镜像队列提升的是可用性，不是让同一个队列线性扩吞吐。仲裁队列是 3.8 之后的新功能，同样是主从结构，但基于 Raft 协议做强一致复制，使用时声明队列为 quorum 即可，适合替代镜像队列。
小结
普通集群解决“多个节点统一管理”，镜像队列解决“队列消息多副本”，仲裁队列解决“更可靠的队列复制”。
