一、主流 MQ 架构与核心原理详解
1. RabbitMQ
（1）核心架构（AMQP 协议 + 交换机路由）
基于 Erlang 语言开发，遵循 AMQP（高级消息队列协议），核心组件分工明确：
| 组件 | 核心作用 |
|---|---|
| Broker | MQ 服务节点 / 集群，是消息转发、存储的核心载体 |
| Exchange | 交换机，接收生产者消息，根据路由规则将消息路由到指定 Queue |
| Queue | 消息队列，存储消息，是消费者的消费目标（点对点核心载体） |
| Binding | 绑定关系，关联 Exchange 和 Queue，定义路由规则（如通配符、精准匹配） |
| VHost | 虚拟主机，隔离不同租户的资源（Exchange/Queue/ 用户），实现多租户隔离 |
| Channel | 轻量级 TCP 连接，一个 Connection 可创建多个 Channel，减少 TCP 连接开销 |
（2）核心原理
- 消息模型 ：基于「交换机 + 队列」的灵活路由模型，支持 4 种交换机：
- Direct：精准路由（匹配指定 Routing Key）；
- Topic：通配符路由（支持
*/#匹配）； - Fanout：广播路由（忽略 Routing Key，转发到所有绑定的 Queue）；
- Headers：基于消息头匹配（极少用）。
- 存储机制：默认内存存储，支持持久化（先写磁盘再入内存），但磁盘为随机写，高吞吐场景性能弱；
- 高可用：镜像队列（Mirror Queue）------ 将 Queue 复制到多个 Broker 节点，主节点挂掉后从节点接管；
- 消费可靠性：支持手动 ACK（确认消费），只有消费者明确 ACK，MQ 才会删除消息，避免消息丢失；
- 核心特点：路由灵活、低延迟（毫秒级）、可靠性高，适合对路由逻辑要求高的场景。
2. Kafka
（1）核心架构（日志型存储 + 分区并行）
基于 Scala/Java 开发，面向大数据流处理，核心设计围绕「高吞吐」：
| 组件 | 核心作用 |
|---|---|
| Broker | 集群节点，存储 Topic 的 Partition 数据，处理生产 / 消费请求 |
| Topic | 消息主题，逻辑上的消息分类（如「用户行为日志」「订单消息」） |
| Partition | 分区，Topic 的物理拆分（每个 Partition 是有序日志文件），提升并行处理能力 |
| Replica | 副本，Partition 的备份（Leader/Follower），Leader 处理读写，Follower 同步数据 |
| Consumer Group | 消费者组，组内消费者共同消费一个 Topic 的不同 Partition（一个 Partition 仅被组内一个消费者消费） |
| KRaft/Zookeeper | 集群元数据管理（Kafka 2.8 + 用 KRaft 替代 Zookeeper），负责选主、节点发现 |
（2）核心原理
- 消息模型：基于「Topic-Partition」的发布订阅模型，无交换机，直接按 Topic 分区存储；
- 存储机制 ：消息以「Log Segment」形式顺序写磁盘（顺序写性能是随机写的 10 倍以上），支持数据压缩、过期删除、日志清理；
- 高可用：Partition 的 Leader-Follower 机制，Leader 挂掉后通过选举切换 Follower 为新 Leader；
- 消费模式：Pull（拉）模式，消费者主动拉取消息，可自主控制消费速率（避免 Push 模式的消费过载）；
- 核心特点：超高吞吐（十万级 / 秒）、持久化能力强，适合大数据流、日志采集等场景，但功能相对简单。
3. RocketMQ
（1）核心架构（阿里系 + 功能全面）
阿里开源（已捐 Apache），基于 Java 开发，融合 RabbitMQ 和 Kafka 的优点：
| 组件 | 核心作用 |
|---|---|
| NameServer | 轻量级注册中心，无状态，管理 Broker 节点信息（集群部署，无需主从） |
| Broker | 核心节点，分 Master/Slave，存储消息、处理生产 / 消费请求，支持消息过滤 |
| Topic | 消息主题，逻辑分类 |
| Queue | 队列，Topic 的物理拆分（对应 Kafka 的 Partition），分布在多个 Broker 上 |
| Producer/Consumer | 生产者 / 消费者，支持集群部署、批量发送、集群消费 / 广播消费 |
（2）核心原理
- 消息模型 ：基于「Topic-Queue」的发布订阅模型，支持Tag/SQL92 消息过滤（比 Kafka 灵活）；
- 存储机制：混合存储（内存映射 + 文件顺序写），性能接近 Kafka，支持消息持久化、过期清理；
- 高可用：Master-Slave 架构，Master 处理读写，Slave 同步数据，Master 挂掉后可手动 / 自动切换；
- 消费模式：伪 Push（底层 Pull），兼顾实时性和消费速率控制；
- 核心特点：原生支持事务消息、精准延时消息、消息轨迹，适配国内电商 / 金融场景，性能和功能平衡。
4. ActiveMQ
（1）核心架构（老牌 JMS 规范）
Apache 开源，老牌 MQ，基于 Java 开发，兼容 JMS（Java 消息服务）规范：
| 组件 | 核心作用 |
|---|---|
| Broker | MQ 服务节点，包含连接器（支持多协议）、消息存储、目的地（Queue/Topic） |
| Queue/Topic | 点对点队列 / 发布订阅主题（严格遵循 JMS 规范） |
| Message Store | 消息存储，支持内存、文件（KahaDB）、数据库（如 MySQL） |
（2）核心原理
- 消息模型：支持 JMS 规范的 P2P（点对点）、Pub/Sub（发布订阅），无灵活路由；
- 存储机制：支持多存储方式，但高并发下文件存储性能差；
- 高可用：支持 Master-Slave、集群部署，但高并发易宕机；
- 核心特点：兼容 JMS、协议多（AMQP/MQTT/OpenWire）、易上手，但性能和扩展性弱于新一代 MQ。
5. Pulsar
（1）核心架构（云原生新一代 MQ）
Apache 开源，新一代云原生 MQ，基于 Java/Go 开发，融合消息队列和流处理：
| 组件 | 核心作用 |
|---|---|
| Broker | 无状态节点，处理生产 / 消费请求，可弹性扩缩（不存储消息） |
| BookKeeper | 分布式存储集群，专门存储消息（分层存储：热数据存 SSD，冷数据存对象存储） |
| Topic | 分区主题，支持多租户、跨地域复制 |
| ZooKeeper | 管理集群元数据（Broker/BookKeeper 节点信息） |
（2）核心原理
- 消息模型：发布订阅模型，支持消息回溯、延迟消息、多租户；
- 存储机制：分层存储（BookKeeper），支持无限消息留存，云原生友好；
- 高可用：Broker 无状态，BookKeeper 多副本存储，天生支持弹性扩缩；
- 核心特点：云原生、跨地域部署、流批一体，但架构复杂，生态较新。
二、主流 MQ 核心对比表（面试 / 选型必看）
| 特性 | RabbitMQ | Kafka | RocketMQ | ActiveMQ | Pulsar |
|---|---|---|---|---|---|
| 开发语言 | Erlang | Scala/Java | Java | Java | Java/Go |
| 核心协议 | AMQP | 自定义协议 | 自定义（兼容 JMS） | JMS/AMQP/MQTT 等 | 自定义（兼容 Kafka） |
| 核心优势 | 路由灵活、低延迟、可靠性高 | 超高吞吐、持久化好 | 功能全（事务 / 延时）、国产适配 | 兼容 JMS、易上手 | 云原生、分层存储、多租户 |
| 吞吐量 | 中（万级 / 秒） | 极高（十万级 / 秒） | 高（十万级 / 秒） | 低（千级 / 秒） | 极高（十万级 / 秒） |
| 延迟消息 | 插件支持（精度低） | 不支持（需上层实现） | 原生支持（精准到秒） | 支持 | 原生支持 |
| 事务消息 | 支持 | 基础支持（幂等 + 事务） | 原生高可靠支持 | 支持 | 原生支持 |
| 消息回溯 | 有限支持 | 基于 Offset 回溯 | 基于 Offset 回溯 | 有限支持 | 任意时间回溯 |
| 高可用机制 | 镜像队列 | Partition 副本 | Master-Slave | Master-Slave | BookKeeper 多副本 |
| 运维复杂度 | 中 | 高（分区 / 副本管理） | 中 | 低 | 高（Broker+BookKeeper） |
| 适用场景 | 电商订单、即时通知、路由复杂场景 | 日志采集、监控数据、大数据流 | 电商交易、金融、国产大厂生态 | 小型系统、兼容 JMS 场景 | 云原生、跨地域、流批一体 |
| 缺点 | 高吞吐性能弱、Erlang 门槛高 | 功能简单、运维复杂 | 生态不如 RabbitMQ/Kafka | 高并发易宕机、性能差 | 生态新、架构复杂 |
三、核心总结（选型 + 面试要点）
1. 选型核心原则
- 「路由灵活、低延迟、可靠性」优先：选 RabbitMQ（如电商订单、即时通知）；
- 「超高吞吐、大数据流」优先：选 Kafka（如日志采集、监控数据、实时计算）；
- 「国内大厂生态、事务 / 延时消息」优先：选 RocketMQ（如阿里系电商、金融交易）；
- 「小型系统、快速上手」：选 ActiveMQ（不推荐高并发场景）；
- 「云原生、跨地域、流批一体」：选 Pulsar（新一代 MQ 首选）。
2. 面试高频考点
- Kafka 高吞吐的核心原因：顺序写磁盘、Partition 并行、零拷贝（sendfile）、批量发送；
- RocketMQ 对比 Kafka 的优势：支持精准延时消息、事务消息、Tag 消息过滤；
- RabbitMQ 高可用：镜像队列保证 Queue 副本同步，避免单点故障；
- Pulsar 的核心创新：Broker 无状态、分层存储（冷热数据分离），适配云原生弹性扩缩。