3. RabbitMQ 核心概念回顾：Exchange、Queue、Binding、Routing Key、消息确认机制
在深入消息契约设计之前，必须统一团队对 RabbitMQ 核心概念的认知。本章将围绕五个核心要素展开：Exchange（交换机）、Queue（队列）、Binding（绑定）、Routing Key（路由键）以及消息确认机制。这些概念是消息契约的物理载体，契约的每一个字段最终都会映射到这些组件的配置上。
3.1 核心概念全景图
下图展示了消息从生产者到消费者的完整路径，以及各组件之间的协作关系：
3.2 Exchange（交换机）—— 消息的路由中枢
Exchange 是消息进入 RabbitMQ 后的第一站。它不存储消息，而是根据类型和绑定规则将消息分发到一个或多个队列。RabbitMQ 支持四种内置交换机类型：
| 类型 | 路由规则 | 典型场景 | Routing Key 匹配方式 |
|---|---|---|---|
| Direct | 精确匹配 | 单播、命令分发 | Routing Key 必须与 Binding Key 完全一致 |
| Topic | 模式匹配 | 多播、日志分级、事件路由 | 支持通配符 *（匹配一个词）和 #（匹配零个或多个词） |
| Fanout | 广播 | 全局通知、缓存刷新 | 忽略 Routing Key，消息发送到所有绑定队列 |
| Headers | 头部匹配 | 复杂条件路由 | 基于消息头部属性匹配，忽略 Routing Key |
契约实践要点：在 OpenAPI 消息契约中，Exchange 类型和名称应作为全局配置定义在
x-rabbitmq-exchange 扩展字段中。Topic 类型最灵活，推荐作为默认选择；Direct 类型适合命令式消息；Fanout 适合事件广播。
3.3 Queue（队列）—— 消息的存储与缓冲
Queue 是消息的存储容器，负责暂存尚未被消费的消息。队列的属性直接影响消息的持久性、可用性和消费行为：
- 名称（Name）：队列的唯一标识，在 vhost 内不可重复。
- 持久化（Durable）：声明为
true时，队列元数据在 RabbitMQ 重启后保留；消息的持久化还需消息本身设置delivery_mode=2。 - 排他性（Exclusive）：仅创建该队列的连接可用，连接关闭后自动删除。
- 自动删除（Auto-delete）：最后一个消费者取消订阅后自动删除队列。
- 参数（Arguments）：如死信交换机（DLX）、消息 TTL、队列长度限制等。
契约映射建议：每个 Queue 应在契约中声明其业务语义（如
order.created.queue）、持久化策略（默认 durable: true）以及死信配置。这些信息写入 x-rabbitmq-queue 扩展字段，供自动化部署工具解析。
3.4 Binding（绑定）与 Routing Key（路由键）—— 连接 Exchange 与 Queue 的规则
Binding 定义了 Exchange 与 Queue 之间的关联关系，而 Routing Key 是消息在绑定关系中的匹配依据。两者共同决定了消息的流向。
Binding 的三要素：
- 源 Exchange：消息从哪个交换机流出。
- 目标 Queue：消息进入哪个队列。
- Binding Key：与消息的 Routing Key 进行匹配的字符串（或模式）。
Routing Key 的使用规则：
- 由生产者随消息一起发送，是一个点号分隔的字符串（如
order.created.vip）。 - 对于 Direct 类型，Routing Key 必须与 Binding Key 完全一致。
- 对于 Topic 类型，Routing Key 与 Binding Key 进行通配符匹配。
- 对于 Fanout 类型，Routing Key 被忽略。
常见陷阱：Binding Key 与 Routing Key 的匹配规则容易混淆。在 Topic 类型中，
# 匹配零个或多个单词，* 匹配恰好一个单词。例如 Binding Key order.# 可以匹配 order.created 和 order.created.vip，而 order.* 只能匹配 order.created，不能匹配 order.created.vip。
3.5 消息确认机制 —— 保证消息不丢失
消息确认机制是 RabbitMQ 可靠性的核心，涉及生产者确认和消费者确认两个层面：
3.5.1 生产者确认（Publisher Confirms）
生产者发送消息后，RabbitMQ 会异步返回确认（basic.ack）或未确认（basic.nack）。这保证消息已到达 Broker 并被正确处理。
- 同步等待：调用
channel.waitForConfirms()，简单但性能较低。 - 异步监听：注册
ConfirmListener，性能高，推荐生产环境使用。 - 事务模式：
channel.txSelect()，性能最差，已不推荐。
3.5.2 消费者确认（Consumer Acknowledgements）
消费者处理完消息后，必须向 RabbitMQ 发送确认，Broker 才会删除该消息。确认模式有三种：
| 确认模式 | 行为 | 适用场景 | 风险 |
|---|---|---|---|
| 自动确认（autoAck=true） | 消息发送后立即确认，不等待处理结果 | 可丢失消息、日志收集 | 消费者崩溃时消息丢失 |
| 手动确认（autoAck=false） | 消费者处理完成后调用 basic.ack() |
订单处理、支付、关键业务 | 需确保处理逻辑完整，避免重复消费 |
| 否定确认（basic.nack） | 消费者处理失败，可重新入队或丢弃 | 临时错误重试、死信路由 | 需设置重试次数，防止无限循环 |
契约最佳实践：在 OpenAPI 消息契约中，应为每个消息操作（publish/subscribe）显式声明确认模式。例如，在
x-rabbitmq-consumer 扩展字段中设置 ack-mode: manual，并约定重试策略和死信队列名称。这确保所有微服务遵循统一的可靠性标准。
3.6 核心概念总结表
| 概念 | 职责 | 契约中如何体现 | 关键属性 |
|---|---|---|---|
| Exchange | 消息路由分发 | x-rabbitmq-exchange |
类型、名称、持久化、自动删除 |
| Queue | 消息存储缓冲 | x-rabbitmq-queue |
名称、持久化、排他性、死信配置 |
| Binding | 连接 Exchange 与 Queue | x-rabbitmq-binding |
源 Exchange、目标 Queue、Binding Key |
| Routing Key | 消息路由匹配依据 | 消息头或契约中的 routingKey 字段 |
字符串格式、通配符规则 |
| 消息确认 | 保证消息可靠传递 | x-rabbitmq-publisher / x-rabbitmq-consumer |
确认模式、重试策略、死信队列 |