2. 消息队列基础回顾：核心概念与主流选型
在进入契约先行开发之前，必须先统一消息队列（Message Queue, MQ）的基础认知。本章从核心概念出发，梳理 Producer、Consumer、Topic、Queue、Broker 的职责与关系，再通过对比表格和架构图，帮助你在 Kafka、RabbitMQ、RocketMQ 之间做出合理选型。
2.1 核心概念与职责
消息队列的本质是异步通信中间件，它解耦了消息的生产与消费。以下五个概念构成 MQ 的骨架：
| 概念 | 英文 | 核心职责 | 类比（快递系统） |
|---|---|---|---|
| 生产者 | Producer | 发送消息到 Broker，不关心谁消费 | 寄件人 |
| 消费者 | Consumer | 从 Broker 拉取或接收消息，处理业务逻辑 | 收件人 |
| 主题 | Topic | 消息的逻辑分类，支持发布/订阅模式 | 快递标签（如“生鲜”“文件”） |
| 队列 | Queue | 消息的物理或逻辑存储单元，支持点对点模式 | 快递货架上的格子 |
| 代理 | Broker | MQ 服务端实例，负责存储、路由、分发 | 快递中转站 |
关键区分：Topic 是逻辑路由，Queue 是存储与消费单元。在 Kafka 中，Topic 下分多个 Partition（分区），每个 Partition 就是一个有序的 Queue；在 RabbitMQ 中，Exchange 根据路由键将消息投递到绑定 Queue。
2.2 消息流转架构
下图展示了一条消息从 Producer 到 Consumer 的完整路径，以及 Broker 内部 Topic 与 Queue 的关系：
架构要点：
- Producer 只与 Topic 交互，不感知 Consumer 的存在。
- Topic 将消息路由到对应的 Queue（或 Partition），实现存储与负载均衡。
- Consumer 从 Queue 拉取消息，支持单播（点对点）和广播（发布/订阅）两种模式。
2.3 主流 MQ 选型对比
当前生产环境最常用的三种消息队列是 Kafka、RabbitMQ 和 RocketMQ。选型时需关注吞吐量、可靠性、路由灵活性和运维成本。
| 对比维度 | Kafka | RabbitMQ | RocketMQ |
|---|---|---|---|
| 设计定位 | 分布式流处理平台 | 通用消息代理 | 分布式消息中间件 |
| 吞吐量 | 极高（百万级/秒） | 中等（万级/秒） | 高（十万级/秒） |
| 消息模型 | Topic + Partition | Exchange + Queue | Topic + Queue |
| 路由灵活性 | 弱（仅按 Topic 路由） | 强（多种 Exchange 类型） | 中（支持 Tag 过滤） |
| 消息可靠性 | 高（ISR 副本机制） | 高（Publisher Confirm + 镜像队列） | 高（同步双写 + 主从切换） |
| 顺序消息 | 支持（分区内有序） | 支持（单队列有序） | 支持（分区有序） |
| 事务消息 | 有限支持 | 不支持原生 | 原生支持 |
| 编程语言 | Java/Scala 为主 | Erlang（多语言客户端） | Java 为主 |
| 运维复杂度 | 高（依赖 Zookeeper/KRaft） | 低（独立进程，管理 UI 完善） | 中（需部署 NameServer） |
选型建议：
- 大数据管道、日志采集、流计算 → 首选 Kafka，吞吐量优势明显。
- 企业应用、微服务异步解耦、复杂路由 → 首选 RabbitMQ，灵活且易运维。
- 金融级交易、事务消息、阿里云生态 → 首选 RocketMQ，事务与可靠性突出。
2.4 三种 MQ 的架构对比图
以下 SVG 从组件视角对比三种 MQ 的内部架构差异，帮助你快速理解各自的设计哲学：
架构差异总结：
- Kafka 以 Partition 为并行单元，强调顺序写入和水平扩展，适合高吞吐流式场景。
- RabbitMQ 以 Exchange 为路由中枢，支持 direct、topic、fanout、headers 四种路由模式，灵活性最高。
- RocketMQ 在 Topic 下管理多个 MessageQueue，通过 NameServer 实现轻量级服务发现，事务消息是其杀手锏。
2.5 核心概念在契约开发中的映射
在后续章节中，我们将使用 OpenAPI 规范来定义 MQ 的契约。理解以下映射关系，是契约先行的基础：
| MQ 概念 | OpenAPI 契约元素 | 说明 |
|---|---|---|
| Topic / Exchange | path 或 channel |
作为消息的入口地址，在 AsyncAPI 中对应 channel |
| Message 结构 | schema（JSON Schema） |
定义消息体的字段、类型、必填约束 |
| Producer | publish 操作 |
描述消息的发送方、发送频率、重试策略 |
| Consumer | subscribe 操作 |
描述消息的接收方、消费确认方式 |
| Queue / Partition | bindings 扩展 |
在协议绑定中定义队列名称、分区数、持久化策略 |
学习提示：本章回顾的概念是后续所有契约定义的基础。如果你对 Kafka 的 Partition 与 Consumer Group 的 rebalance 机制、RabbitMQ 的 Exchange 类型、RocketMQ 的事务半消息等细节还不熟悉，建议先查阅对应官方文档，再进入第 3 章的 OpenAPI 实战。