2. RabbitMQ 核心概念回顾：交换机、队列、绑定、路由键、消息确认机制
在构建基于 OpenAPI 的消息契约之前，必须深入理解 RabbitMQ 的五大核心抽象。这些概念构成了消息路由与可靠投递的基石，也是后续契约描述与自动化复测的直接对象。
2.1 核心概念总览
RabbitMQ 采用 AMQP 0-9-1 模型，消息并非直接发送到队列，而是经过 交换机 路由到 队列，由消费者消费。下表总结了各核心角色的职责与关键属性：
| 概念 | 职责 | 关键属性 |
|---|---|---|
| 交换机 (Exchange) | 接收生产者发送的消息，并根据路由规则将消息分发到一个或多个队列。 | 名称、类型（direct/topic/fanout/headers）、持久化、自动删除 |
| 队列 (Queue) | 存储消息的缓冲区，消费者从队列中拉取或订阅消息。 | 名称、持久化、排他、自动删除、死信交换机、TTL |
| 绑定 (Binding) | 定义交换机和队列之间的关联关系，包含路由键规则。 | 源交换机、目标队列、路由键、绑定参数 |
| 路由键 (Routing Key) | 消息携带的标签，交换机根据绑定中的路由键模式进行匹配。 | 字符串（支持通配符 * 和 #） |
| 消息确认 (ACK/NACK) | 确保消息被成功处理或明确拒绝，防止消息丢失。 | 自动确认、手动确认、重回队列、死信 |
契约视角： 在 OpenAPI 规范中，上述每个概念及其属性都应被显式声明。例如，交换机类型决定了路由键的匹配算法，而确认机制则直接影响消费者端点的响应契约。
2.2 交换机类型与路由行为
交换机类型决定了消息的分发逻辑。四种内置类型覆盖了从广播到精确匹配的全部场景：
- Direct Exchange： 路由键精确匹配。消息的路由键必须与绑定键完全一致，才能路由到对应队列。适用于点对点、任务分发场景。
- Topic Exchange： 路由键模式匹配。绑定键支持通配符
*（匹配一个单词）和#（匹配零个或多个单词）。适用于按主题分类的发布/订阅。 - Fanout Exchange： 忽略路由键。将消息广播到所有与该交换机绑定的队列。适用于日志广播、事件通知。
- Headers Exchange： 忽略路由键，根据消息头属性匹配。绑定参数定义键值对规则，支持
x-match: all或any。适用于复杂路由条件。
实践建议： 在微服务架构中，Topic Exchange 是最灵活的选择。契约中应明确声明允许的路由键模式，避免生产者和消费者之间因模式不匹配导致消息丢失。
2.3 消息确认机制：可靠投递的保障
消息确认机制是 RabbitMQ 保证至少一次投递的核心。它分为两个阶段：
- 生产者确认（Publisher Confirm）： 生产者发送消息后，RabbitMQ 异步返回确认（basic.ack）或未确认（basic.nack）。生产者可据此决定是否重发。
- 消费者确认（Consumer ACK）： 消费者处理完消息后，向 RabbitMQ 发送确认（basic.ack）。若消费者未确认且连接断开，消息会重新入队（requeue）或进入死信队列。
下表对比了两种确认模式的关键差异：
| 维度 | 自动确认（autoAck=true） | 手动确认（autoAck=false） |
|---|---|---|
| 确认时机 | 消息投递给消费者后立即确认 | 消费者显式调用 basic.ack 后确认 |
| 消息丢失风险 | 高（消费者崩溃时消息可能丢失） | 低（消费者崩溃后消息可重新投递） |
| 吞吐量 | 高（无等待确认开销） | 相对较低（需等待业务处理完成） |
| 适用场景 | 可容忍少量丢失的日志、监控 | 订单、支付等关键业务 |
契约陷阱： 在 OpenAPI 契约中，如果未明确声明消费者端点的确认模式，测试框架将无法自动验证消息是否被正确确认或拒绝。务必在契约中标注
x-rabbitmq-consumer-ack-mode 等扩展字段。
2.4 核心路由流程示意图
下图展示了从生产者到消费者的完整消息路由路径，包含交换机、绑定、队列和确认机制：
2.5 死信队列与备用交换机
当消息无法被正常消费时，RabbitMQ 提供了两种容错机制：
- 死信队列（DLQ）： 消息被拒绝（basic.nack/basic.reject）且不重回队列、消息 TTL 过期、队列达到最大长度时，消息会被转发到指定的死信交换机，最终进入死信队列。这是隔离异常消息的标准模式。
- 备用交换机（Alternate Exchange）： 当交换机无法将消息路由到任何队列时（无匹配绑定），消息会被转发到备用交换机。用于捕获“迷路”消息，避免消息丢失。
契约化要点： 在 OpenAPI 契约中，死信交换机和备用交换机应作为队列和交换机的扩展属性声明。例如：
x-dead-letter-exchange 和 x-alternate-exchange。测试框架可据此自动验证异常路径的完整性。