消息队列对比与选型
本文对比当前知识库收录的 RabbitMQ、Kafka 和 RocketMQ。比较重点是架构语义、可靠性和运维边界，不使用脱离配置与硬件的固定吞吐量排名。
定位对比
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 产品定位 | 通用消息代理、工作队列 | 分布式事件流平台 | 面向业务事件的分布式消息平台 |
| 核心抽象 | Exchange、Binding、Queue | Topic、Partition、Offset | Topic、MessageQueue、Consumer Group |
| 主要优势 | 灵活路由、低延迟投递、协议与插件生态 | 高吞吐、持久保留、事件重放、流处理生态 | 顺序、延时、事务和业务消息模型 |
| 典型场景 | 异步任务、服务解耦、复杂路由 | 日志、埋点、CDC、流计算、事件溯源 | 订单、交易、延时任务、顺序业务事件 |
路由与数据模型
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 一级分类 | Exchange/Queue | Topic | Topic |
| 路由方式 | Direct、Topic、Fanout、Headers Exchange | Topic、Partition、Key | Topic、Tag、属性过滤、MessageQueue |
| 并行单位 | Queue 与 Consumer | Partition | MessageQueue |
| 广播方式 | 每个订阅者绑定独立 Queue | 不同 Consumer Group | 不同 Consumer Group 或广播消费 |
| 消费后数据 | 普通 Queue Ack 后删除 | 与消费进度独立，按保留策略删除 | 与消费进度独立，按存储策略删除 |
| 历史重放 | 普通 Queue 不适合；Stream 支持 Offset | 原生按 Offset 重放 | 可重置消费进度，具体能力依客户端与版本 |
RabbitMQ 的 Exchange 路由最灵活；Kafka 的 Partition Log 最适合长期事件流；RocketMQ 的 Topic、Tag 和业务消息类型更贴近交易系统。
顺序语义
| 组件 | 顺序边界 | 破坏顺序的常见因素 |
|---|---|---|
| RabbitMQ | 单 Queue 的投递顺序 | 多 Consumer、重新入队、优先级、故障恢复 |
| Kafka | 单 Partition | Key 分区变化、增加 Partition、并行处理与重试 |
| RocketMQ | MessageQueue 或 MessageGroup | 路由变化、并行消费、失败阻塞与重试 |
三者都不应默认理解成全局严格顺序。严格顺序通常会降低并发和故障恢复能力，应先确定业务 Key 的局部顺序边界。
可靠性与投递语义
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 生产确认 | Publisher Confirm | acks、幂等 Producer | 同步/异步发送结果 |
| 消费确认 | Ack/Nack | Offset Commit | 消费结果/Ack 与消费进度 |
| 常见投递语义 | At-Least-Once | At-Least-Once；受约束的 Kafka 内 Exactly-Once | At-Least-Once |
| 去重能力 | 业务幂等 | 幂等 Producer 去除会话内重试；业务仍需幂等 | 业务幂等，事务消息也不能替代 Consumer 幂等 |
| 失败处理 | Requeue、TTL 重试、DLX | 重试 Topic/应用策略、Offset 重放 | 内置重试与死信 |
任何组件都不能单独保证“业务绝对只执行一次”。Broker 语义必须和数据库事务、业务唯一键以及补偿流程一起设计。
事务能力
| 组件 | 事务解决的问题 | 不解决的问题 |
|---|---|---|
| RabbitMQ | AMQP Transaction 或 Confirm 管理发布结果 | 不与业务数据库组成统一事务 |
| Kafka | 原子写多个 Partition，并可原子提交输入 Offset | 不直接覆盖 MySQL 等外部副作用 |
| RocketMQ | Half Message、本地事务、提交/回滚和回查 | 属于最终协调，不是通用分布式 ACID |
高可用模块
| 层次 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 接入与发现 | 客户端多地址、负载均衡 | Bootstrap Broker 与元数据发现 | NameServer、Proxy |
| 控制面 | 集群元数据、Khepri/内部元数据机制 | KRaft Controller Quorum | NameServer 路由；Controller/DLedger 参与选主 |
| 数据面 | Quorum Queue 或 Stream 副本 | Partition Replica、Leader、ISR | Broker Master/Replica、CommitLog |
| 多数派机制 | Quorum Queue 的 Raft | Controller Raft；业务副本由 ISR 机制约束 | Controller 或 DLedger 模式 |
| 跨地域 | Federation、Shovel | 独立集群加异步复制 | 独立集群加复制或业务灾备 |
只部署三个节点不等于高可用：RabbitMQ 必须选择复制队列类型，Kafka 必须正确设置副本与最小 ISR，RocketMQ 必须明确复制和自动选主模式。
积压与保留
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 长期大规模保留 | 普通 Queue 不是主要方向；Stream 更合适 | 核心能力 | 支持业务消息保留和积压 |
| 消费与删除关系 | 普通 Queue Ack 后删除 | 相互独立 | 相互独立 |
| 积压主要成本 | Queue 索引、磁盘、恢复和重投 | 磁盘、保留、Consumer 追赶 | CommitLog、ConsumeQueue、Consumer 追赶 |
| 扩消费上限 | Queue/Consumer 与处理能力 | Partition 数 | MessageQueue 数 |
运维与生态
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 主要运行时 | Erlang/OTP | JVM | JVM |
| 配置重点 | Queue 类型、Policy、Prefetch、内存与磁盘水位 | Partition、副本、ISR、保留、KRaft | Broker 角色、复制、刷盘、队列与消费组 |
| 主要扩展 | Plugin、Federation、Shovel | Connect、Streams、流处理生态 | Proxy、各语言客户端、Spring、Dashboard |
| 运维难点 | Queue 堆积、Quorum 多数派、Erlang 兼容 | 分区规模、迁移、ISR、Controller、Rebalance | 路由、副本模式、顺序阻塞、重试死信 |
选型决策
| 需求 | 优先选择 | 原因 |
|---|---|---|
| 灵活 Exchange 路由、工作队列 | RabbitMQ | 路由模型成熟，Queue 语义直接 |
| 长期事件保留和任意 Offset 重放 | Kafka | Partition Log 是核心模型 |
| 日志、埋点、CDC、Flink/Spark 管道 | Kafka | 吞吐、重放和流处理生态完善 |
| 订单内顺序和延时业务消息 | RocketMQ | 原生业务消息模型清晰 |
| 本地事务结果与消息最终协调 | RocketMQ 或 Outbox | 事务消息支持回查，但仍需业务幂等 |
| 普通低延迟服务异步化 | RabbitMQ 或 RocketMQ | 根据路由复杂度、消息类型和已有平台决定 |
选型还应加入组织维度：已有运维平台、客户端语言、监控告警、故障演练和团队经验，通常比纸面性能差异更重要。