RabbitMQ、Kafka、RocketMQ 怎么选？它们的核心差异在哪？
结论先行：没有最好的 MQ，只有最匹配场景的 MQ。RabbitMQ 胜在路由灵活与协议成熟，适合中小流量、复杂路由与低延迟通知；Kafka 胜在吞吐与顺序，适合日志、流式计算与海量数据管道；RocketMQ 在电商可靠性场景做了强化（事务消息、延迟消息、消费重试），适合交易类业务。选型先定场景，再定吞吐与可靠性要求。
一、三款中间件对比
| 对比项 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 开发语言 | Erlang | Scala/Java | Java |
| 消息模型 | Exchange+Queue 路由 | Topic+Partition | Topic+Queue |
| 单机吞吐 | 万级 | 十万~百万级 | 十万级 |
| 可靠性 | 好（confirm+ack） | 好（副本+ISR） | 好（同步双写可配） |
| 顺序消息 | 弱（单队列） | 分区内强顺序 | 分区队列内强顺序 |
| 延迟/定时消息 | 需插件/死信拼 | 需自研 | 原生支持定时消息 |
| 消息过滤 | Exchange/Topic 灵活路由 | 弱（按分区） | Tag 过滤 |
| 事务消息 | 弱 | 事务型 producer | 原生半消息机制 |
| 消费重试/死信 | 完善 | 一般 | 完善（重试队列+死信） |
| 运维复杂度 | 低 | 高（元数据依赖） | 中 |
| 生态与云服务 | 云托管选择多 | 流处理/大数据生态强 | 阿里系生态完整 |
二、按场景对号入座
- 异步通知、任务分发、复杂路由（Exchange/Topic）：RabbitMQ。
- 日志采集、埋点、流式计算（Flink 对接）、数据管道：Kafka。
- 订单/交易、事务消息、延迟消息、需要精细化重试：RocketMQ。
- 事件驱动 + 事务消息解耦（下单成功广播给多个订阅方）：事务型能力优先 RocketMQ，避免自建本地消息表。
三、选型清单（面试表达顺序）
- 明确量级：峰值 QPS 是万级还是百万级，决定是否需要 Kafka 级吞吐。
- 明确语义：能否接受重复（至少一次）？能否接受乱序？是否需要事务/延迟消息？
- 明确团队：技术栈与运维能力决定 Kafka 的元数据依赖能不能扛住。
- 先 PoC 后上量：压吞吐、延迟、堆积恢复、宕机恢复再拍板。
- 预留退出通道：明确中间件异常时的降级路径（如切回同步调用），不要把架构绑死。
常见追问与记忆点
- 追问：Kafka 吞吐为什么高？顺序写磁盘 + 页缓存 + 零拷贝 + 分区并行，吞吐瓶颈主要在副本同步。
- 追问：RabbitMQ 能换成 Kafka 吗？能，但要接受路由语义变化与可能重复、可能乱序的消费模型，业务需幂等。
- 追问：最常踩的选型坑？拿 Kafka 扛交易强可靠场景、或拿 RabbitMQ 扛百万级吞吐，都是典型错配。
- 追问：公司已有两套 MQ 怎么办？统一收敛到一套为主，另一套平滑迁移，双 MQ 长期并存成本高。
- 记忆点：RabbitMQ 灵活、Kafka 快而大、RocketMQ 强可靠；选型 = 量级 × 语义 × 团队运维能力。