S17-J02 · MQ 选型：RabbitMQ / Kafka / RocketMQ

适用读者：要在三者之间做决定的人。
前置：S17-J01。
覆盖旧文：1545(104) 1546(149) 1843(104) 428(115) 998(66) 999(79) 1003(54) 1005(54) 1004(64) 1002(66) = 855 点。
上一篇：S17-J01 · 消息模型：Topic / 分区 / 消费组
下一篇：S17-J03 · 可靠投递。

1. 一句话结论

三者不是"谁更好"，是"为不同负载设计的"：RabbitMQ 强在路由灵活，Kafka 强在吞吐与回放，RocketMQ 强在事务消息与业务友好。

维度	RabbitMQ	Kafka	RocketMQ
模型	队列 + 交换机路由	分区日志	分区日志
吞吐	万级	十万+	十万级
消息回放	❌（消费即删）	✅（按位点重读）	✅
路由灵活性	最强（exchange/binding）	弱	中
延迟消息	需插件	❌	✅ 原生
事务消息	弱	需自己实现	✅ 原生
运维复杂度	低	中	中

2. 三个典型场景

场景	首选	理由
业务解耦、复杂路由（订单→多下游）	RabbitMQ	路由灵活、延迟低
日志/埋点/流式（高吞吐、可回放）	Kafka	顺序写 + 分区并行
电商核心链路（事务消息、延迟消息）	RocketMQ	原生事务/延迟/重试

判据三问：

① 需要回放历史消息吗？  需要 → Kafka/RocketMQ
② 需要复杂路由吗？      需要 → RabbitMQ
③ 需要事务消息吗？      需要 → RocketMQ

3. RabbitMQ 的三个关键概念（A-1546）

概念	说明
Exchange	决定路由规则（direct/topic/fanout）
Queue	存消息（消费后删除）
Channel	复用 TCP 连接（必须池化，A-428）

"为什么需要连接池"：Connection 是 TCP，创建成本高；Channel 是轻量复用——每线程一个 Channel，而不是每请求一个 Connection。

4. Kafka 为什么快（A-1842）

机制	说明
顺序写盘	追加写，避免随机 IO
零拷贝（sendfile）	减少内核/用户态复制
批量 + 压缩	减少网络与磁盘
分区并行	水平扩展

"快不等于低延迟"：Kafka 为吞吐优化，端到端延迟通常高于 RabbitMQ。

5. 五个误区

误区	真相
"Kafka 能替代 RabbitMQ"	路由能力差很多
"RabbitMQ 吞吐不够用"	万级够多数业务
"Kafka 延迟最低"	吞吐优先，延迟不一定
"事务消息人人都有"	RocketMQ 原生，Kafka 需自己实现
"选型只看性能"	运维/生态/团队熟悉度同样重要

6. 自检

三者的核心差异（模型/回放/路由）？
三个典型场景分别选谁？
RabbitMQ 为什么要连接池？
Kafka 快的四个机制？
"Kafka 延迟最低"为什么不一定成立？

7. 下一篇

S17-J03 · 可靠投递：不丢、不重、有序

选型讲完，下一篇讲最容易出事的一环：消息可靠性（含"重复消费"实测）。

本篇属于系列《S17 · 分布式与消息队列》。旧文来源：A-1545/1546/1843/428/998/999/1003/1005/1004/1002。