2. 主流消息队列产品对比：RabbitMQ、Apache Kafka、RocketMQ、ActiveMQ、Pulsar
在构建消息队列任务契约之前，必须理解不同消息中间件的底层架构与性能特征。本章从架构特点、性能指标与选型建议三个维度，对五款主流产品进行系统性对比，为后续基于 OpenAPI 的契约设计提供技术选型依据。
2.1 架构特点对比
五款消息队列在消息模型、存储方式、集群模式上存在本质差异，直接影响任务契约的字段定义与交互模式。
核心认知：消息队列的架构决定了其适用的业务场景。RabbitMQ 擅长复杂路由，Kafka 擅长高吞吐日志，RocketMQ 在金融场景中表现均衡，ActiveMQ 适合传统 JMS 集成，Pulsar 则通过存算分离实现弹性扩展。
2.2 性能指标对比
性能指标是选型的核心依据。以下表格从吞吐量、延迟、持久化能力、扩展性四个维度进行量化对比，数据基于社区基准测试与生产环境经验值。
| 指标维度 | RabbitMQ | Apache Kafka | RocketMQ | ActiveMQ | Pulsar |
|---|---|---|---|---|---|
| 单节点吞吐量 | 数万 msg/s | 数十万 ~ 百万 msg/s | 数十万 msg/s | 数千 ~ 数万 msg/s | 数十万 ~ 百万 msg/s |
| 端到端延迟 (P99) | < 1ms | 2 ~ 10ms | 1 ~ 5ms | 2 ~ 20ms | 1 ~ 5ms |
| 持久化机制 | 内存 + 磁盘 (可选) | 磁盘顺序写 | CommitLog 顺序写 | KahaDB / JDBC | BookKeeper 分段存储 |
| 水平扩展 | 集群 + 镜像队列 | 分区 + 副本 | 主从 + DLedger | 网络连接器 | 存算分离 + 分层 |
| 消息可靠性 | Confirm + 持久化 | ACK + ISR 副本 | 同步刷盘 + 主从 | 持久化 + 事务 | BookKeeper 副本 |
| 顺序消息 | 单队列有序 | 分区内有序 | 队列内有序 | 单队列有序 | 分区内有序 |
| 事务消息 | 不支持原生 | 支持 (EOS) | 原生支持 | 支持 (JMS XA) | 支持 |
性能解读：Kafka 和 Pulsar 在吞吐量上占据优势，适合大数据场景；RabbitMQ 在低延迟场景中表现最佳；RocketMQ 在事务消息与金融场景中具有独特优势；ActiveMQ 性能相对较弱，但兼容 JMS 标准。
2.3 选型建议与场景匹配
选型不应仅看性能数字，还需结合团队技术栈、运维能力、业务需求综合判断。以下列表给出典型场景的推荐方案。
- 金融交易 / 事务消息：推荐 RocketMQ。原生支持事务消息、半消息机制、消息回溯，适合对数据一致性要求极高的场景。
- 日志采集 / 流处理：推荐 Apache Kafka。高吞吐、持久化、分区顺序，与 Flink/Spark 生态集成成熟。
- 微服务异步解耦 / 复杂路由：推荐 RabbitMQ。灵活的 Exchange 与 Binding 机制，支持多种路由模式，延迟极低。
- 传统 JMS 集成 / 遗留系统：推荐 ActiveMQ。兼容 JMS 1.1 规范，适合与旧系统对接。
- 多租户 / 云原生 / 弹性扩展：推荐 Pulsar。存算分离架构，支持无限存储、多租户隔离、分层存储。
2.4 任务契约设计的影响因素
不同消息队列的协议与特性，直接影响 OpenAPI 契约中 servers、paths、schemas 的定义方式。以下列出关键差异点：
| 契约元素 | RabbitMQ | Kafka | RocketMQ | Pulsar |
|---|---|---|---|---|
| 连接协议 | AMQP 0-9-1 | 自定义二进制 | 自定义二进制 | Pulsar 二进制 |
| 路由方式 | Exchange + Routing Key | Topic + Partition Key | Topic + Tag | Topic + Key |
| 消息确认 | Consumer ACK | Offset Commit | ConsumeQueue Offset | Cumulative ACK |
| 重试机制 | 死信队列 | 重试 Topic | 重试队列 | 重试 Topic |
| OpenAPI 映射 | 需定义 Exchange/Binding | 需定义 Partition/Offset | 需定义 Queue/Tag | 需定义 Subscription |
契约设计注意：在 OpenAPI 规范中定义消息队列接口时，必须将消息队列特有的路由字段（如 Routing Key、Tag、Partition Key）显式声明为请求参数或消息头，否则客户端无法正确路由消息。