01

60 秒回答模板

Kafka 更像分布式提交日志，核心是 Topic 分区、顺序追加、页缓存、批量传输、ISR 副本和消费者自己维护 offset，适合日志采集、流式计算和高吞吐订阅。RocketMQ 更偏业务消息中间件，Topic 下有 MessageQueue，NameServer 管路由，Broker 提供普通、顺序、延迟、事务、重试和死信等能力，适合订单、交易、通知这类业务事件。选型要看吞吐规模、消息语义、顺序范围、事务一致性、延迟消息、消费重试、运维生态和团队经验。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

定位差异先讲清

Kafka 的抽象是可持久化、可回放的分区日志，适合事件流和数据管道；RocketMQ 的抽象更贴近业务消息，内置能力覆盖事务消息、延迟消息、重试和死信。

02

存储和复制机制不同

Kafka 依赖分区顺序追加、页缓存、批量和 ISR 复制提升吞吐；RocketMQ Broker 存 CommitLog 和 ConsumeQueue，NameServer 提供轻量路由发现。两者都能高可用，但运维模型不同。

03

顺序语义都有范围

Kafka 保证单 partition 内有序，RocketMQ 保证单 queue 内有序。全局有序通常意味着单分区或单队列，会牺牲并发和吞吐；业务上一般按订单号、用户号等 key 局部有序。

04

事务消息和 exactly-once 不等价

RocketMQ 事务消息通过半消息、本地事务和事务回查解决本地事务与发消息的一致性。Kafka exactly-once 更偏生产、消费和流处理链路内的事务语义，两者解决的问题边界不同。

05

消费失败治理要比较

RocketMQ 对业务重试、延迟重投、死信队列支持更直接；Kafka 通常依赖消费者控制 offset、重试 topic、DLQ 和流处理框架。面试回答要落到失败后怎么恢复。

03

易错点

  • 只说 Kafka 快、RocketMQ 业务强，不讲机制差异。
  • 把分区内有序或队列内有序说成全局有序。
  • 混淆 Kafka exactly-once 和 RocketMQ 事务消息的边界。
  • 选型只看性能，不考虑重试、死信、延迟消息和运维生态。
04

面试官追问

Kafka 为什么吞吐高？

分区并行、顺序追加磁盘、页缓存、批量发送、零拷贝和消费者顺序拉取共同提升吞吐。

Kafka 如何保证有序？

只保证单 partition 内顺序。相同业务 key 要路由到同一 partition；跨 partition 没有全局顺序保证。

RocketMQ 事务消息完整流程是什么？

先发送半消息，执行本地事务，再提交或回滚消息；如果结果未知，Broker 发起回查，由生产者根据本地事务状态决定。

Kafka exactly-once 和 RocketMQ 事务消息一样吗？

不一样。Kafka EOS 更关注 Kafka 读写和流处理状态的一致提交；RocketMQ 事务消息关注本地业务事务和消息发送的一致性。