消息队列基础：RabbitMQ/Kafka 核心概念与投递语义
在构建基于 OAuth 2.0 的契约测试体系时，消息队列是承载令牌分发、事件通知与异步验证的核心基础设施。本章聚焦 RabbitMQ 与 Kafka 两大主流消息中间件，梳理其核心概念与消息投递语义，为后续接口版本安全验证奠定基础。
2.1 RabbitMQ 核心概念
RabbitMQ 基于 AMQP 0-9-1 协议，采用 Exchange（交换机）与 Queue（队列）解耦生产者与消费者。消息先到达 Exchange，再根据绑定规则路由到一个或多个队列。
| 概念 | 说明 | 典型用途 |
|---|---|---|
| Exchange | 接收生产者消息，按类型和绑定键路由 | 消息分发入口 |
| Queue | 存储消息，供消费者拉取或推送 | 异步任务、事件存储 |
| Binding | Exchange 与 Queue 之间的路由规则 | 定义消息流向 |
| Routing Key | 消息携带的路由标识 | 匹配 Binding 规则 |
Exchange 类型
- Direct Exchange：Routing Key 精确匹配，适用于点对点通信。
- Topic Exchange：Routing Key 支持通配符（
*匹配一个词，#匹配零或多个词），适用于多条件路由。 - Fanout Exchange：忽略 Routing Key，广播到所有绑定队列。
- Headers Exchange：基于消息头属性匹配，不依赖 Routing Key。
契约测试视角：在 OAuth 2.0 场景中，Topic Exchange 常用于按令牌类型（如
access.token.*）或版本号（如 v2.refresh.#）路由消息，便于接口版本隔离。
2.2 Kafka 核心概念
Kafka 是一个分布式流处理平台，以 Topic 和 Partition 为核心，强调高吞吐与持久化。与 RabbitMQ 不同，Kafka 不采用 Exchange 概念，而是直接由生产者向 Topic 写入消息。
| 概念 | 说明 | 典型用途 |
|---|---|---|
| Topic | 消息的逻辑分类，类似数据库表 | 事件流分类 |
| Partition | Topic 的物理分片，保证顺序与并行 | 水平扩展、有序消费 |
| Consumer Group | 一组消费者协同消费 Topic 分区 | 负载均衡、容错 |
| Offset | 消息在分区内的唯一序号 | 消费位置追踪 |
Partition 与 Consumer Group 的关系
- 一个 Partition 只能被同一 Consumer Group 内的一个消费者实例消费。
- Partition 数量决定 Consumer Group 内的最大并行度。
- 新增消费者实例会触发 Rebalance，重新分配分区。
契约测试注意：Kafka 的 Partition 顺序保证仅在分区内有效。若 OAuth 2.0 令牌版本验证依赖全局顺序，需将相同令牌 ID 路由到同一分区（如按令牌哈希取模）。
2.3 消息投递语义
消息投递语义定义了生产者发送消息与消费者接收消息之间的可靠性保证。在 OAuth 2.0 契约测试中，投递语义直接影响令牌状态变更的验证准确性。
| 语义 | 生产者行为 | 消费者行为 | 适用场景 |
|---|---|---|---|
| At Most Once | 发送后不等待确认 | 消费后不提交 Offset | 日志、监控（允许丢失） |
| At Least Once | 等待 Broker 确认（ACK） | 消费后提交 Offset，可能重复 | 令牌撤销通知（需幂等） |
| Exactly Once | 事务或幂等生产者 | 事务性消费 + 幂等处理 | 金融级令牌版本变更 |
RabbitMQ 投递语义实现
- Publisher Confirm：生产者开启 Confirm 模式，Broker 返回 ACK 确保消息到达 Exchange。
- Consumer ACK：消费者处理完成后手动发送 ACK，否则消息重新入队。
- 持久化：设置消息
delivery_mode=2和队列durable=true，防止重启丢失。
Kafka 投递语义实现
- acks 参数：
acks=0（不等待）、acks=1（Leader 确认）、acks=all（所有副本确认）。 - enable.idempotence：开启幂等生产者，防止重复写入。
- 事务 API：跨分区原子写入，实现 Exactly Once 语义。
契约测试关键点：在验证 OAuth 2.0 接口版本时，建议使用 At Least Once 语义配合幂等消费者。例如，令牌撤销事件可能重复投递，但消费者通过令牌 ID 去重，确保契约断言只执行一次。
2.4 RabbitMQ 与 Kafka 对比
| 维度 | RabbitMQ | Kafka |
|---|---|---|
| 模型 | Exchange + Queue | Topic + Partition |
| 路由 | 灵活（Direct/Topic/Fanout/Headers） | 按 Partition Key 哈希 |
| 顺序保证 | 单队列内有序 | 单分区内有序 |
| 吞吐量 | 万级/秒 | 百万级/秒 |
| 消息留存 | 消费后删除（默认） | 基于时间/大小保留 |
| 契约测试适配 | 适合点对点、版本隔离 | 适合高吞吐事件流、重放验证 |
选型建议：若 OAuth 2.0 系统需要精细路由（如按令牌版本分发到不同验证服务），优先 RabbitMQ Topic Exchange；若需要高吞吐事件溯源与历史重放（如审计令牌变更记录），优先 Kafka。