第四章 消息队列选型对比：Kafka / RocketMQ / Pulsar
消息队列选型是架构决策能力的直接体现，面试中常以开放题考察候选人的技术视野与工程判断力。核心不在于「哪个更好」，而在于「如何评估」。
✧ 选型核心公式： 业务场景需求 × 技术指标匹配 × 生态运维成本 = 最优解
选型因素全景对比
| 评估维度 | Kafka | RocketMQ | Pulsar |
|---|---|---|---|
| 吞吐量 | 极高（百万 msg/s） | 高（数十万 msg/s） | 高（数十万 msg/s） |
| 延迟 | 毫秒级 | 毫秒级 | 毫秒级 |
| 消息可靠性 | 高（ISR + ACK 机制） | 高（事务 + 半消息） | 极高（BookKeeper 持久化） |
| 顺序保证 | 分区内有序 | 全局有序支持 | 分区内有序 |
| 事务消息 | 支持（2.8+） | 原生支持 | 支持 |
| 多租户 | 弱（需物理隔离） | 中（队列隔离） | 强（原生多租户） |
| 运维复杂度 | 中（依赖 ZK） | 中（NameServer） | 高（BookKeeper 组件多） |
| 社区成熟度 | 极高 | 高 | 中 |
| 典型场景 | 日志采集 / 流计算 / 大数据管道 | 交易系统 / 事务消息 / 金融场景 | 云原生 / 多租户平台 / 跨地域复制 |
记忆口诀： 高吞吐选 Kafka，事务一致选 RocketMQ，云原生多租户选 Pulsar。
选型回答框架
面试中遇到选型问题时，用以下四步结构回答，体现系统化思维：
面试官追问路径
面试官会在选型回答基础上，沿着四个方向深挖技术细节：
⚠ 避坑总提示： 选型对比切忌「背参数表」。面试官要的是你的决策逻辑 —— 从业务场景出发，用指标衡量，用对比验证，最后落地结论。不要只说「Kafka 吞吐高」，要说「在这个日志场景下，Kafka 的吞吐优势能直接降低机器成本 40%」。
高频面试问答
🎯 面试问题
在进行消息队列技术选型时，你会从哪些维度进行评估？请给出你的分析框架。
📌 面试官考察点
- 系统化架构思维 —— 是否具备多维度评估能力
- 技术广度 —— 对主流 MQ 的优劣势理解
- 工程落地经验 —— 能否结合真实场景做取舍
📐 回答框架
采用「场景 → 指标 → 对比 → 结论」四步法：
- 场景需求：明确业务对吞吐、延迟、可靠性、事务的核心要求
- 指标量化：列出 TPS、P99 延迟、持久化周期、运维成本等可测量指标
- 特性对比：在相同环境下对比 Kafka / RocketMQ / Pulsar 的表现
- 推荐结论：给出选择并说明理由，附带 trade-off 说明
✏️ 简短示例回答
我会从四个维度评估：吞吐与延迟、可靠性语义、生态运维、成本。Kafka 适合高吞吐日志场景，RocketMQ 适合事务消息，Pulsar 适合多云原生架构。选型本质是业务需求与技术特性的匹配。
🔍 可能追问
- 如果业务需要全局严格有序消息，你会怎么选？
- 你认为 Pulsar 的存算分离架构在什么场景下是优势？
⚠ 避坑提醒：不要只列功能对比表。要结合业务场景讲决策逻辑，例如「在这个场景下，我们为了事务消息选择了 RocketMQ，但牺牲了一定的吞吐弹性」。
🎯 面试问题
请对比 Kafka、RocketMQ、Pulsar 在消息投递语义和一致性保障方面的差异。
📌 面试官考察点
- 消息可靠性机制的理解深度
- 分布式一致性模型认知
- 对「exactly-once」实现代价的认知
📐 回答框架
分别阐述三种 MQ 的投递语义保证等级，对比实现机制的差异，最后说明性能与一致性的 trade-off。
- Kafka：ISR + acks 参数，支持 at-least-once / exactly-once（需事务 API）
- RocketMQ：事务消息 + 半消息机制，最终一致性
- Pulsar：BookKeeper 持久化层，严格顺序 + exactly-once
✏️ 简短示例回答
Kafka 通过 ISR 机制和 acks 参数实现 at-least-once 和 exactly-once；RocketMQ 通过事务消息和半消息机制实现最终一致；Pulsar 通过 BookKeeper 的持久化层实现严格顺序和 exactly-once。三者在一致性模型上各有取舍。