Erlang Mnesia 元数据、消息索引与持久化存储、内存换页、普通集群 vs 镜像队列 vs 现代 Quorum 队列（Raft 协议）。

存储机制与高可用集群

校招考察频度：☆ 中频（进阶拔高·Quorum 队列 Raft 共识） 生产导向主线：单机 RabbitMQ 即使配齐了持久化，一旦宿主机硬件损坏依旧会宕机停服。构建高可用集群是企业级生产的唯一出路。面试核心：Erlang Mnesia 元数据与消息物理落盘、普通集群 vs 镜像队列（Mirrored Queue）的脑裂痛点、现代基于 Raft 协议的 Quorum 队列底层机制，以及为什么 RabbitMQ 的吞吐量是万级而 Kafka 能达到百万级。

一、RabbitMQ 底层存储机制与内存换页

RabbitMQ 是由爱立信专门为电信高并发系统设计的 Erlang 语言 开发的。

1. 存储架构两件套

Mnesia 分布式数据库：存储 Exchange、Queue、Binding、VirtualHost、用户权限等元数据。这些数据在集群节点间自动实时广播同步。
消息存储引擎（Message Store）：
- msg_index（消息索引）：维护消息在磁盘文件中的段落偏移量、状态标记（Ready / Unacked / Acked）。
- msg_store（消息物理文件）：消息正文的存储容器。小消息（通常小于 4KB）会直接内嵌在索引文件中以减少一次磁盘 I/O 寻道；大消息分段追加写入 msg_store 数据块。

2. 内存报警与换页机制（Paging）

默认情况下，RabbitMQ 尽量将消息保存在内存中以获取微秒级的极速吞吐。
内存高水位告警（vm_memory_high_watermark）：默认阈值为物理内存的 40%。
一旦内存使用量触及该警戒线，Broker 会：
1. 触发流量控制（Flow Control），强制阻塞或挂起所有生产者的写入 Socket，禁止继续投递新消息。
2. 触发内存换页（Paging）：由后台刷盘进程将内存中的消息数据强行写入磁盘，并清空对应的内存占用，直到内存降回安全线以下才恢复生产。

二、集群高可用架构的三大演进阶段

在生产环境下部署 RabbitMQ 集群，历史上经历了三次架构演化：

【演进 1: 普通集群 (无容灾)】       【演进 2: 镜像队列 (全量复制易脑裂)】     【演进 3: Quorum 队列 (Raft共识强一致)】
    Node-A       Node-B            Master         Slave-1       Slave-2          Leader        Follower     Follower
   [Queue 1]      (空)             [Queue]  =====> [Queue] =====> [Queue]        [Queue]  ──Raft 日志复制──> [Queue]
 (A宕机Q1瘫痪!) (仅跨节点转发)      (网络开销巨大，分区易多主脑裂)                  (多数派落盘，自动防脑裂选主)

1. 阶段一：普通集群模式（Non-Mirrored Cluster·无容灾能力）

特点：集群内所有节点共享一份相同的元数据（Exchange、Binding 等），但是队列中的实际消息内容，有且仅保存在创建该队列的那台物理节点上！
访问过程：客户端如果连接到 Node-B，但想要消费 Node-A 上的队列，Node-B 会充当路由代理，在内部通过 Erlang 节点间通信向 Node-A 拉取数据并转交给客户端。
缺点：完全不具备高可用性。如果 Node-A 物理机宕机，Node-A 上的所有队列直接瘫痪，直到机器修好重启前无法对外提供任何服务。

2. 阶段二：镜像队列模式（Mirrored Queue·官方宣布废弃）

机制：在普通集群之上配置 Policy，指定队列的副本镜像到其他节点。由一个 Master 节点 负责全部客户端读写，多个 Slave 节点 被动接收 Master 的全量同步数据。
生产致命痛点：
1. 网络带宽开销巨大：写一条消息必须全量广播给所有 Slave，节点越多网络抖动越严重，集群整体吞吐随着节点增多急剧下降。
2. 网络分区与脑裂（Split-Brain）：一旦跨机架或跨网段发生网络抖动，Slave 可能误判 Master 宕机并私自选举成新的 Master，导致系统中同时存在两个 Master 接收写入，最终数据严重错乱破坏。
- 官方决议：RabbitMQ 官方宣布在 4.0 版本彻底移除镜像队列，全面强制推荐 Quorum 队列！

3. 阶段三：现代高可用黄金标准——Quorum 队列（基于 Raft 协议）

在 RabbitMQ 3.8 引入，是现代企业级生产高可用集群的绝对唯一推荐方案：

声明方式：arguments.put("x-queue-type", "quorum")。
底层架构：每个 Quorum 队列本质上是一个运行在 Erlang 上的 Raft 共识协议状态机。
多数派写入原则（Quorum）：
- 一个包含 3 个节点的 Quorum 队列，生产者写入消息时，Leader 节点将 Raft 日志追加并同步给 Followers。
- 只要满足 多数派（3 节点中的 2 节点，即 $N/2 + 1$ ）成功将日志写入磁盘并确认，Broker 就立即向生产端返回 Confirm ACK。
绝对防御脑裂：即便发生网络分区，只有处于多数派分区的节点才能合法选出新 Leader，少数派分区自动拒绝写入，从根本上在数学层面上消除了脑裂风险。

三、硬核性能对比：为什么 RabbitMQ 是万级 TPS，而 Kafka 能到百万级？

这是高级架构面中最经典的底层权衡考题：

维度	RabbitMQ（万级 ~ 十万级 TPS）	Apache Kafka（百万级 TPS）
消息模型与复杂度	遵循强 AMQP 规范：每条消息都要经历 Exchange 的动态 Binding 路由计算、多消费者竞争、复杂的 ACK 确认状态机流转。	纯追加日志（Append-only CommitLog）：没有复杂的交换机路由，生产只管无脑往分区末尾追加，极度轻量。
内存与虚拟机架构	运行在 Erlang BEAM 虚拟机内部：消息以 Erlang 进程消息的形式在内存中传递，经历应用层堆栈解析，无法绕过内存拷贝。	依赖操作系统内核（OS PageCache）：数据直接写入操作系统页缓存，避开了 JVM GC 停顿，并利用 Linux `sendfile` 零拷贝技术直接由网卡拉取数据。
批处理设计哲学	单条消息低延迟优先：专为在线业务交易打造，单条消息端到端延迟在微秒到毫秒级，不强制客户端攒批。	极限吞吐优先：必须在客户端强制攒批（`batch.size` 与 `linger.ms`），成百上千条消息打包压缩后一次性通过网络喷出。
消息消费后动作	消费者 ACK 后，队列必须实时从磁盘和内存中物理擦除消息，带来额外的随机写与碎片整理开销。	消费仅仅是向前移动消费者位移 Offset 指针，物理日志完全保留数天，对磁盘没有任何删除写惩罚。

面试高频追问

Quorum 队列相比传统的镜像队列（Mirrored Queue）有哪些巨大优势？
- 镜像队列采用非强一致的主从全量同步，网络分区时极易脑裂导致数据丢失；
- Quorum 队列基于工业级 Raft 共识协议构建，只有多数派节点持久化才确认，彻底消除了脑裂风险，故障切主期间数据安全更有数学级保障。
RabbitMQ 集群中的节点有哪两种类型？生产怎么配？
- 磁盘节点（Disk Node）：将元数据存储在磁盘上。集群中至少需要 2 个或全量磁盘节点以保证元数据不丢失。
- 内存节点（RAM Node）：将元数据存储在内存中，操作极快。
- 生产规范：传统做法是 2 磁盘节点 + N 内存节点；但在现代硬件和 Quorum 队列普及后，官方强烈建议所有生产节点全部配置为磁盘节点。
既然 Kafka 吞吐高出百倍，为什么大部分企业业务系统依然离不开 RabbitMQ？
- 业务系统（如电商、金融、OA）的核心诉求是：微秒级低延迟、复杂的动态路由绑定、消息级 TTL、延时重试队列、死信机制与单条精确 ACK。这些精细化的业务控制功能 Kafka 统统不具备（Kafka 擅长大吞吐日志收集与流计算）。适合的才是最好的。