考察点
选型题没有唯一答案，面试官看的是你能不能说出差异背后的架构原因，而不是罗列"Kafka 吞吐高、RocketMQ 功能全"这种结论。高分回答的框架：先讲三者定位的根本分歧（日志流 vs 业务消息 vs 云原生存储计算分离），再按业务场景给推荐，最后承认自己团队现状（语言栈、运维能力）也是选型变量。
参考答案
定位差异：三者从出身就不同
Kafka 本质是分布式提交日志（commit log），为日志采集和流式数据管道而生。分区 append-only、批量顺序读写，吞吐是它的绝对强项。消费模型是 pull，消费者自己管位移，配合 Kafka Streams/Flink 做流处理生态最成熟。代价是功能克制：早期没有延迟消息、死信队列、消息级重试，这些都要应用层自己补（延迟消息常见做法是多级延迟主题或者外部调度）。
RocketMQ 出身阿里电商场景，为业务消息设计：延迟消息（18 个固定级别，5.x 支持任意时间）、顺序消息、事务消息（半消息 + 回查机制，解决本地事务和发消息的一致性）、死信队列、消息轨迹，开箱即用。架构是 NameServer（轻量路由注册，AP）+ Broker 主从，5.x 引入了 Proxy 层和存储计算分离的尝试。吞吐不如 Kafka 极致（十万级 vs 百万级），延迟表现更稳，单条消息的小批量场景比 Kafka 友好。
Pulsar 是 Apache 顶级项目里最有野心的：存储计算分离架构——Broker 无状态只负责服务，存储交给 BookKeeper（bookie 节点），分区可以无限扩展、扩缩容不用搬数据。多租户、跨地域复制（geo-replication）是一等公民。还内置 Pulsar Functions 做轻量计算。代价是架构组件多（Broker + BookKeeper + ZooKeeper/etcd），运维复杂度最高，社区和国内人才储备比前两者薄。
关键维度对比
| 维度 | Kafka | RocketMQ | Pulsar |
|---|---|---|---|
| 设计定位 | 日志流/数据管道 | 业务消息 | 云原生消息+流 |
| 吞吐 | 最高，百万级 | 十万级 | 高，依赖 BookKeeper 调优 |
| 延迟 | 批量换取吞吐，毫秒级但毛刺多 | 稳定低延迟 | 低延迟，分层存储读冷数据会慢 |
| 延迟消息 | 无原生支持 | 原生（任意时长） | 原生（DelayedDelivery） |
| 事务消息 | 有（流式 EOS 方向） | 有（业务事务方向，带补偿回查） | 有（事务，较新） |
| 存储 | 本地盘分段日志 | 本地盘 CommitLog | BookKeeper 分层，可 offload 到对象存储 |
| 扩缩容 | 分区搬迁，重 | 队列搬迁，中等 | 无感（存储计算分离） |
| 生态 | 流处理生态最强 | 国内业务系统案例多 | 增长快但薄 |
有一个点单独说：三者的事务不是一回事。Kafka 事务服务的是流处理的 consume-transform-produce 原子性；RocketMQ 事务消息服务的是"本地数据库事务成功后消息一定可达"，带 Broker 主动回查；面试里混着讲会暴露理解不深。
选型逻辑
选 Kafka 的场景： 日志采集、用户行为埋点、Metrics 管道、CDC 数据同步、流处理（Flink/Kafka Streams）的数据源。一句话：数据量大、以流式消费为主、对功能要求简单的场景。大数据团队默认选项，没有之一。
选 RocketMQ 的场景： 电商交易、订单状态机、支付通知这类业务消息——需要延迟消息（超时关单）、事务消息（下单发券）、严格顺序、消息轨迹排查。Java 技术栈的业务团队用着最顺手，国内文档和案例多。
选 Pulsar 的场景： 多租户 SaaS 平台、跨机房跨地域复制刚需、存储分层（冷数据 offload 到 S3）需求明确、或者新项目想一步到位上存储计算分离。前提是有运维实力，否则 BookKeeper 的调优和排障会成为痛点。
最后说一个务实的点：选型不只看技术指标。团队熟悉程度、招聘市场、云厂商托管服务（各家云都有托管 Kafka 和 RocketMQ，Pulsar 的托管选择少）、已有中间件栈的统一性，经常是决定性因素。小公司同时维护两套消息中间件是运维灾难，能统一就统一。
可能的追问
- Kafka 没有延迟消息，业务上要延时重试怎么办？ 常见方案：多级延迟主题（delay-5s、delay-30s 等主题逐层转发）、外部调度（Redis ZSet/时间轮扫表触发）、或者干脆这类需求引一个 RocketMQ。要说出各自代价。
- Pulsar 存储计算分离的实际收益是什么？ 扩容 Broker 不搬数据、扩 bookie 不影响服务；分区数量不再是容量规划的死约束；冷数据自动分层省存储成本。代价是读冷数据路径变长。
- RocketMQ 的 CommitLog 和 Kafka 的分段日志有什么差别？ RocketMQ 所有主题写同一个 CommitLog 顺序文件，各 ConsumeQueue 只存索引，单机主题数多时写入依然顺序化；Kafka 每分区独立日志文件，分区数暴涨时文件句柄和随机写压力更大——这解释了 Kafka 对海量小主题的支持不如 RocketMQ。