这三个都属于主流消息中间件，但设计目标不同：
- RabbitMQ ：偏传统消息队列，强调低延迟、复杂路由、消费确认
- Kafka ：偏分布式日志/流平台，强调超高吞吐、持久化、可回放
- Pulsar ：偏云原生流平台，强调Kafka 类吞吐 + 更强多租户/存储分离
如果你做系统选型，核心要先看：
- 你更关注单条消息实时性
- 还是关注海量吞吐
- 还是关注多租户、跨地域、长期存储
1. 一句话结论
- RabbitMQ 适合：任务队列、订单处理、异步解耦、低延迟业务、复杂路由
- Kafka 适合：日志、埋点、事件流、数据管道、大数据、事件溯源
- Pulsar 适合：企业级云原生消息平台、多租户、跨地域复制、长时间保留、高吞吐流场景
2. 核心架构差异
RabbitMQ
- 基于 AMQP
- 核心概念：
ProducerExchangeQueueConsumer
- 消息先进 Exchange，再根据规则路由到 Queue
- 强项是路由能力很强
特点
- 点对点、发布订阅、Topic、死信队列、延迟队列，都比较成熟
- Broker 中心化特征更强
- 更像"智能消息调度中心"
Kafka
- 本质是分布式提交日志
- 核心概念：
TopicPartitionProducerConsumer GroupOffset
- 消息写入 Partition 后，按顺序追加
- Consumer 自己记录 offset，Broker 不负责"删消息后即完成"
特点
- 强项是顺序写磁盘、批量发送、吞吐高
- 消息保留一段时间，可重复消费
- 更像"高吞吐事件流平台"
Pulsar
- 架构上比 Kafka 更"云原生"
- 核心分成两层：
- Broker：处理收发
- BookKeeper：负责持久化存储
- 即计算层和存储层分离
特点
- 多租户能力强
- Topic 扩展更灵活
- 长期存储、跨机房复制能力更强
- 更像"企业级分布式消息/流平台"
3. 吞吐量对比
下面数字是行业常见经验值，实际会受很多因素影响：
- 消息大小（1KB / 10KB / 100KB）
- 是否持久化
- 是否开启副本
- 是否要求 ACK
- 网络带宽
- 磁盘类型（SSD / NVMe）
- 消费端速度
所以这些数字适合做量级判断，不是绝对值。
单机/单节点典型吞吐量量级
| 产品 | 典型吞吐量 | 说明 |
|---|---|---|
| RabbitMQ | 2万 ~ 10万 msg/s | 小消息、简单队列、适度 ACK |
| RabbitMQ（持久化+确认） | 1万 ~ 5万 msg/s | 业务常见真实场景 |
| Kafka | 10万 ~ 100万+ msg/s | 顺序写、批量发送优势明显 |
| Kafka（高副本/强可靠） | 5万 ~ 50万+ msg/s | 仍通常高于 RabbitMQ |
| Pulsar | 10万 ~ 80万+ msg/s | 接近 Kafka，视 BookKeeper 配置而定 |
| Pulsar（高可靠副本） | 5万 ~ 40万+ msg/s | 取决于 ledger / 存储集群规模 |
按 MB/s 的大致量级
假设小消息场景：
| 产品 | 常见吞吐带宽 |
|---|---|
| RabbitMQ | 数十 MB/s |
| Kafka | 数百 MB/s，优秀集群可更高 |
| Pulsar | 数百 MB/s |
延迟对比
| 产品 | 典型延迟 |
|---|---|
| RabbitMQ | 亚毫秒到几毫秒，低延迟优势明显 |
| Kafka | 几毫秒到十几毫秒，偏吞吐导向 |
| Pulsar | 几毫秒级，一般略高于 RabbitMQ，接近 Kafka |
结论
- 低延迟优先：RabbitMQ
- 极限吞吐优先：Kafka
- 高吞吐 + 云原生能力：Pulsar
4. 可靠性与消息语义
RabbitMQ
支持：
- ACK
- NACK
- 重试
- 死信队列
- 持久化队列
- Publisher Confirm
优势
- 单条消息可靠投递控制非常细
- 业务开发容易理解
不足
- 高吞吐下可靠性配置会明显拉低性能
Kafka
支持：
- At-most-once
- At-least-once
- Exactly-once（特定条件下）
- 副本复制
- ISR 机制
优势
- 持久化非常强
- Consumer 可以重放历史消息
- 非常适合做事件审计、日志回溯
不足
- "消息消费成功后删除"这种传统队列语义不如 RabbitMQ 直观
Pulsar
支持：
- ACK / NACK
- 延迟投递
- 重试队列
- 死信队列
- 多种订阅模式
- 多租户隔离
优势
- 功能兼具传统 MQ 和流平台特性
- 长时间保留与可回放能力很好
不足
- 体系更复杂，调优门槛更高
5. 运维复杂度对比
RabbitMQ 运维
优点
- 上手最简单
- 管理台成熟
- 单机、小集群容易搭建
- 问题排查相对直观
难点
- 队列堆积时，内存/磁盘压力明显
- 集群扩展能力一般
- 大规模场景下性能调优不如 Kafka/Pulsar 顺手
运维复杂度
- 中等偏低
Kafka 运维
优点
- 大规模生产实践非常成熟
- 社区文档多
- 生态完整（Connect、Streams、Flink、Spark）
难点
- 需要理解：
- 分区数规划
- 副本数
- ISR
- Consumer Group Rebalance
- 磁盘容量与保留策略
- 分区一旦设计不合理，后面调整成本较高
- 监控项较多
运维复杂度
- 中等偏高
Pulsar 运维
优点
- 架构先进
- 多租户、跨地域、分层存储做得更好
- 扩容思路清晰
难点
- 组件更多：
- Broker
- BookKeeper
- ZooKeeper（旧架构）/ 新协调组件
- 存储层与计算层分离意味着可扩展性强，但部署更复杂
- 团队需要更强的平台化能力
运维复杂度
- 高
6. 开发复杂度对比
| 维度 | RabbitMQ | Kafka | Pulsar |
|---|---|---|---|
| 入门难度 | 低 | 中 | 中高 |
| API 理解成本 | 低 | 中 | 中 |
| 概念复杂度 | Exchange/Queue/Binding | Topic/Partition/Offset | Topic/Subscription/Broker/BookKeeper |
| 业务开发直觉性 | 很强 | 一般 | 中等 |
| 生态工具丰富度 | 高 | 很高 | 中高 |
总结
- 最容易写业务代码：RabbitMQ
- 最容易做大数据/流式处理集成：Kafka
- 平台化能力最强但理解成本更高：Pulsar
7. 顺序性对比
RabbitMQ
- 单个队列可近似保持顺序
- 但多消费者并发时顺序容易被打散
Kafka
- 单 Partition 内严格有序
- 全局顺序需要单分区，吞吐会受限
Pulsar
- 分区 Topic 内有序
- 非分区 Topic 可有更强顺序语义，但扩展性下降
结论
- 要分区有序：Kafka / Pulsar 都很好
- 要传统队列顺序消费：RabbitMQ 也可，但高并发时要谨慎
8. 扩展性对比
RabbitMQ
- 能扩展，但不是它的最强项
- 队列热点问题明显
- 海量堆积和超大规模集群场景不如 Kafka/Pulsar
Kafka
- 非常适合水平扩展
- 增加 Broker、增加 Partition 后吞吐能明显提升
Pulsar
- 理论上扩展性最好
- 因为收发和存储分离，更利于独立扩容
结论
- 超大规模扩展：Pulsar、Kafka 优于 RabbitMQ
9. 功能对比
| 功能 | RabbitMQ | Kafka | Pulsar |
|---|---|---|---|
| 复杂路由 | 强 | 弱 | 中 |
| 消息重放 | 弱 | 强 | 强 |
| 死信队列 | 强 | 一般 | 强 |
| 延迟消息 | 支持 | 需变通/生态支持 | 支持 |
| 事务消息 | 一般 | 支持一定事务语义 | 支持部分能力 |
| 多租户 | 弱 | 一般 | 强 |
| 跨地域复制 | 一般 | 可做 | 强 |
| 长期存储 | 不擅长 | 强 | 强 |
10. 使用场景对比
RabbitMQ 适合场景
- 订单异步处理
- 短任务削峰填谷
- 邮件/短信发送
- 支付结果通知
- RPC 异步调用
- 需要复杂路由规则的业务系统
- 低延迟要求高的应用
典型关键词
- 业务消息
- 任务队列
- 工作流通知
- 解耦
Kafka 适合场景
- 用户行为埋点
- 日志采集
- 大数据管道
- 事件驱动架构
- 事件溯源
- 数据同步
- 实时数仓
- 流式处理
典型关键词
- 海量写入
- 可回放
- 高吞吐
- 数据平台
Pulsar 适合场景
- 企业级统一消息平台
- 多业务线、多租户隔离
- 跨机房、跨地域复制
- 云原生平台
- 实时消息 + 流存储统一
- 长周期数据保留
- 平台中台化建设
典型关键词
- 多租户
- 云原生
- 分层存储
- 企业级平台
11. 限制与短板
RabbitMQ 的限制
- 吞吐量上限明显低于 Kafka/Pulsar
- 消息堆积多时压力大
- 不适合日志型海量流数据
- 长时间保留和重放能力弱
Kafka 的限制
- 路由能力弱，不适合复杂消息分发
- 延迟通常不如 RabbitMQ
- 运维复杂度较高
- 小业务场景容易"用重了"
Pulsar 的限制
- 部署最复杂
- 社区成熟度虽高，但整体生态仍略小于 Kafka
- 团队学习成本高
- 对平台工程能力要求更高
12. 如何选型
选 RabbitMQ，如果你需要
- 低延迟
- 复杂路由
- 传统异步任务队列
- 快速落地
- 中小规模业务解耦
选 Kafka，如果你需要
- 高吞吐
- 可回放
- 事件流
- 数据平台
- 与 Flink/Spark/大数据生态联动
选 Pulsar，如果你需要
- 企业级统一消息平台
- 多租户
- 云原生
- 跨地域复制
- 长期演进的平台能力
13. 最后给一个实战建议
如果你是普通业务系统选型：
- 中小型业务系统 ：优先
RabbitMQ - 数据平台 / 埋点 / 日志 / 海量事件 ：优先
Kafka - 大型平台型团队 / 云原生中台 / 多租户企业平台 ：优先
Pulsar