#Kafka vs RocketMQ vs RabbitMQ

面试官问候选人小李："你们公司用的什么MQ？"

小李说："Kafka。"

面试官追问："为什么选Kafka而不是RocketMQ或RabbitMQ？"

小李愣了一下："呃...Kafka吞吐量高？"

面试官继续问："那什么时候用RocketMQ？什么时候用RabbitMQ？"

小李答不上来了。

【面试官心理】

这道题我考察的是候选人对MQ生态的全局认知。90%的候选人只会用一种MQ，说不出其他两种的优劣。能说出三者的核心差异、适用场景和选型依据的，是有技术视野的P6+。能说出"根据业务场景做技术选型"而不是"因为团队熟悉所以用"的，才是真正有架构思维的候选人。

#一、核心问题：三大 MQ 的本质差异 🔴

#1.1 问题拆解

第一层：基本认知 面试官问："Kafka、RocketMQ、RabbitMQ有什么区别？" 候选人答："Kafka吞吐高，RocketMQ功能全，RabbitMQ功能多..." 考察点：表面认知

第二层：架构差异 面试官追问："它们的消息模型一样吗？存储机制有什么不同？" 候选人答：...（拉开点1） 考察点：底层原理

第三层：场景适用 面试官追问："什么场景用Kafka？什么场景用RocketMQ？什么场景用RabbitMQ？" 候选人答：...（核心拉开点） 考察点：场景化选型能力

第四层：决策依据 面试官追问："如果让你从头设计一个新系统，你怎么选MQ？" 候选人答：...（P7区分点） 考察点：架构决策能力

#1.2 错误示范

候选人原话 A："RabbitMQ是 Erlang 写的，性能不如Java的Kafka。"

问题诊断：

• 用语言判断性能是错误的
• RabbitMQ的瓶颈从来不是语言，而是架构设计
• Erlang的并发模型反而更适合AMQP协议
• 暴露了对MQ架构的浅层理解

候选人原话 B："Kafka能做的RocketMQ都能做，选RocketMQ就行了。"

问题诊断：

• RocketMQ无法替代Kafka在大数据场景的地位
• 生态差距巨大（Kafka Connect、Streams、Flink等深度集成）
• 两者是互补关系，不是替代关系

候选人原话 C："RabbitMQ功能最全，所以是最好的MQ。"

问题诊断：

• 功能全不代表适合所有场景
• RabbitMQ的万级吞吐在百万级场景下根本不够用
• 没有"最好"，只有"最适合"

#1.3 标准回答

三大 MQ 的核心定位

Kafka：大数据场景的首选
  - 设计理念：日志/事件流处理
  - 吞吐量：百万级 TPS
  - 生态：最强（Flink、Spark、Storm、ES全部原生支持）
  - 适合：日志采集、实时分析、CDC、秒杀事件流

RocketMQ：交易链路的扛把子
  - 设计理念：可靠消息传输
  - 吞吐量：十万级 TPS
  - 功能：事务消息、延迟消息、顺序消息
  - 适合：订单链路、分布式事务、可靠消息通知

RabbitMQ：中小企业的小而美
  - 设计理念：灵活的消息路由
  - 吞吐量：万级 TPS
  - 功能：交换机、路由键、死信队列、延迟插件
  - 适合：小型系统、路由复杂场景、任务队列

【面试官心理】

这道题我想听到的是"场景驱动选型"而非"哪个MQ更好"。能说出"大数据用Kafka、交易用RocketMQ、小系统用RabbitMQ"并能解释每个结论背后的原因的，说明真正理解了三者的设计哲学。

#二、延伸问题：六维度全面对比 🟡

#2.1 核心维度对比表

#2.2 顺序消息对比

Kafka：
  按key hash到Partition → 单Partition内有序
  → 跨Partition无序
  → 实现简单，但顺序保证依赖Partition策略

RocketMQ：
  按key hash到Queue → 单Queue内有序
  → 消费端ConsumeOrderlyContext保证顺序消费
  → 支持失败暂停当前Queue重试

RabbitMQ：
  单队列 + 单消费者 → 全局有序
  → 多队列时需要应用层排序
  → 灵活但实现复杂

#2.3 事务消息对比

Kafka（弱）：
  - enable.idempotence=true + 事务producer
  - 保证：Producer端不重复发送
  - 不保证：Consumer端不重复消费
  - 本质：幂等语义，不是真正的事务

RocketMQ（强）：
  - TransactionListener.executeLocalTransaction()
  - 半消息 + 本地事务 + 回查机制
  - 保证：本地事务和消息发送的原子性
  - 业界最强的事务消息实现

RabbitMQ（弱）：
  - 插件支持（rabbitmq tx）
  - 功能有限，社区反馈不稳定
  - 一般用本地消息表代替

#2.4 延迟消息对比

Kafka（不支持）：
  - 没有原生延迟消息功能
  - 替代方案：外部定时任务 + 延迟Topic
  - 延迟精度差，依赖外部调度

RocketMQ（强）：
  - 原生支持延迟消息（16个延迟级别）
  - 延迟级别：1s, 5s, 10s, 30s, 1m, 2m, 3m, 4m, 5m, 6m, 8m, 10m, 20m, 30m, 1h, 2h
  - 超过2小时的延迟需要改造或换方案

RabbitMQ（插件支持）：
  - rabbitmq-delayed-message-exchange 插件
  - 支持任意延迟时间（毫秒级精度）
  - 但需要安装插件，部署复杂度增加

#三、生产避坑：选错 MQ 的代价

#3.1 坑一：用 RabbitMQ 做高吞吐场景

场景：团队用RabbitMQ处理日志，日均消息量10亿条。

问题：

• RabbitMQ的吞吐只有万级，根本扛不住
• 消息堆积严重，内存持续增长
• 最后RabbitMQ直接OOM崩溃

正确做法：

• 日志采集、大数据场景用Kafka
• RabbitMQ的定位不是高吞吐，是灵活路由

#3.2 坑二：用 Kafka 做事务消息

场景：团队用Kafka实现分布式事务。

问题：

• Kafka的"事务"只是幂等语义
• 本地事务和消息发送的一致性无法保证
• 需要自己实现消息表模式，复杂度极高

正确做法：

• 需要事务消息的场景用RocketMQ
• RocketMQ的事务消息是原生支持，生产可用

#3.3 坑三：用 Kafka 做小消息低延迟场景

场景：团队用Kafka处理聊天消息（单条消息<1KB，对延迟敏感）。

问题：

• Kafka的批量处理模型导致单条消息延迟高（linger.ms=10ms）
• 消息从发送到消费可能需要几十毫秒
• RabbitMQ的延迟只有微秒级

正确做法：

• 低延迟场景用RabbitMQ
• 或者把linger.ms设低（但会牺牲吞吐）

#四、工程选型：场景驱动的选型矩阵

#4.1 选型决策树

第一步：评估吞吐量需求

  吞吐量 >= 50万 QPS？
    → 是 → 必须选 Kafka
    → 否 → 进入第二步

第二步：是否需要事务消息？

  分布式事务、本地事务+消息一致性？
    → 是 → 必须选 RocketMQ
    → 否 → 进入第三步

第三步：是否需要灵活路由？

  交换机、路由键、多种消费模式？
    → 是 → 选 RabbitMQ
    → 否 → 选 Kafka（吞吐优先）或 RocketMQ（功能优先）

#4.2 场景化选型

#4.3 混用策略

大型系统通常不会只用一种MQ：

典型架构：

用户行为日志 → Kafka → Flink实时处理 → ES查询
                    → Kafka → 离线数仓（Hive）

订单交易链路 → RocketMQ → 库存服务（顺序）
                    → 积分服务（异步）
                    → 物流服务（事务）

任务调度 → RocketMQ延迟消息 → 订单超时检查
                          → 用户活跃检测

【面试官心理】

面试这道题，我会问一个开放问题："你们公司现在的MQ选型合理吗？如果让你重新选型，你会换吗？"能说出当前选型的优劣和潜在风险的，说明真正做过技术选型。只知道"现在用的挺好的为什么要换"的是缺乏技术判断力的P5。能说出"混用策略"和"如何渐进式迁移"的，是有架构视野的P7。