RocketMQ vs Kafka：性能、功能与适用场景的全维度对比

一句话结论（30s）

RocketMQ vs Kafka 不是谁更好，而是谁更合适，因为两者的基因从诞生就不同——Kafka 源于日志聚合、为高吞吐流式数据而生，RocketMQ 源于阿里交易链路、为在线业务可靠性而生。关键设计差异在存储模型：Kafka 每 Topic 每 Partition 独立目录（Topic 一多就退化为随机 IO），RocketMQ 所有 Topic 共用一个 CommitLog 顺序写（Topic 增多几乎不降吞吐）。核心权衡：Kafka 用 sendfile 零拷贝在批量传输上更高效，RocketMQ 用 mmap 在需要过滤/事务等复杂逻辑时更灵活；判断标准是「丢了消息会不会叫醒 tech lead」——会就选 RocketMQ。

核心原理（2min）

对比逻辑：吞吐上 Kafka 略胜但怕多 Topic（千级 Topic 吞吐可降 50%），RocketMQ 基本不衰减；功能上 RocketMQ 原生支持延时消息（18 级）、事务消息（Half Message + 本地事务 + 二阶段提交）、广播、Tag/SQL92 过滤、消息轨迹、DLQ、重试，Kafka 大多需额外开发或变通；架构上 Kafka 依赖 ZooKeeper（新版本转 KRaft），RocketMQ 用无状态对等的 NameServer；零拷贝上 Kafka 走 sendfile（绕过用户态、原封不动传输），RocketMQ 走 mmap（用户态直接读 Page Cache、可做过滤解析）。关键判断：大数据流式处理（日志/埋点/ETL）选 Kafka，需要延时/事务/过滤/轨迹/多 Topic 的在线业务选 RocketMQ。

底层深入（5-10min）

先说结论

选 Kafka：大数据流式处理（TB 级日志、埋点、链路追踪）
选 RocketMQ：在线业务消息（订单、通知、分布式事务、延时消息）

两个都是顶级的消息中间件，但设计目标从一开始就不同。Kafka 源于 LinkedIn 的日志聚合需求，为高吞吐流式数据而生；RocketMQ 源于阿里的交易链路，为在线业务消息的可靠性而生。

性能对比

吞吐量

Kafka 在吞吐上略胜一筹，但有一个致命限制：Topic 数量增加会导致性能急剧下降。

为什么 Kafka 怕多 Topic？

Kafka 的存储模型：

Kafka：每个 Topic 的每个 Partition 是一个独立的目录，里面有多个 Segment 文件
  /data/kafka/TopicA-0/000000000000000.log
                       000000000000001.log
  /data/kafka/TopicA-1/...
  /data/kafka/TopicB-0/...

如果有 1000 个 Topic，每个 4 个 Partition：
  = 4000 个目录
  = 4000 个文件句柄（每个 Segment 文件一个 fd）
  = 4000 个 Page Cache 区域竞争

问题：每个 Partition 随机分布在磁盘上，读取时磁头需要来回寻道。Topic 少时顺序 IO 优势明显，Topic 多后退化为随机 IO。

RocketMQ 为什么不怕？

RocketMQ：所有 Topic 共用一个 CommitLog
  /store/commitlog/0000000000000000  ← 所有消息顺序写入这一个文件
  /store/consumequeue/TopicA/0/...    ← 消费时才定位到具体文件

1000 个 Topic → 仍然只有 1 个 CommitLog 文件在写！

RocketMQ 的 CommitLog 统一顺序写，Topic 数量不影响写入性能。读取时通过 ConsumeQueue 索引定位，每个 Queue 一个文件，但是只有活跃的 Queue 会被频繁访问。

实测结果：Kafka 从 10 个 Topic 到 1000 个 Topic，吞吐可能下降 50%；RocketMQ 基本不降。

🤔 思考穿插：为什么 RocketMQ 用一个 CommitLog 写所有 Topic，却还能在消费时精准找到每条消息？—— 因为 CommitLog 只负责顺序落盘、不区分 Topic，把「写多 Topic」和「读单 Topic」解耦了；消费时靠 ConsumeQueue 索引按 Topic/Queue 定位到对应 offset。所以 Topic 增多只增加索引数量，不影响写盘顺序性，吞吐自然不衰减。

零拷贝的实现差异

两者都利用零拷贝技术，但方式不同：

Kafka：sendfile()

传统方式：
  磁盘 → 内核 Page Cache → 用户态 Buffer → 内核 Socket Buffer → 网卡
  （4 次拷贝，4 次上下文切换）

sendfile() 零拷贝：
  磁盘 → 内核 Page Cache → 内核 Socket Buffer → 网卡
  （2 次拷贝，2 次上下文切换，绕过了用户态）

// Kafka 使用 FileChannel.transferTo() → 底层调用 sendfile()
fileChannel.transferTo(position, count, socketChannel);

RocketMQ：mmap()

mmap 零拷贝：
  磁盘 → 内核 Page Cache（用户态和内核态共享这片内存）
  用户态直接读取 Page Cache 中的数据，无需从内核态拷贝到用户态

RocketMQ 用 mmap 映射 CommitLog 和 ConsumeQueue 文件，消费者直接从 Page Cache 读取，不需要 read() 系统调用。对于消费场景（需要做 Tag 过滤、消息解析），mmap 比 sendfile 更灵活——sendfile 是”原封不动传输”，无法在传输过程中进行处理。

结论：Kafka 的 sendfile 在大批量消息传输场景下效率更高；RocketMQ 的 mmap 在需要消息过滤、事务等复杂逻辑时更灵活。

🤔 思考穿插：同样是零拷贝，为什么不能一种实现打天下？—— 因为 sendfile 全程在内核态、数据「原封不动」过境，适合日志这类无需加工的纯搬运；而 RocketMQ 要在传输前做 Tag 过滤、事务检查，必须让用户态能「看见并解析」消息，mmap 共享 Page Cache 恰好满足这一点。所以两者的取舍不是谁快谁慢，而是「要不要在传输途中加工消息」。

功能对比矩阵

关键差异解读

延时消息

Kafka 没有延时消息，需要通过外部状态机或定时任务模拟。RocketMQ 原生支持，内部使用 SCHEDULE_TOPIC_XXXX 临时存储延时消息，定时线程扫描到期后投递到原始队列。这个功能在电商场景（下单 30 分钟未支付取消订单）中极其常见。

🤔 思考穿插：为什么「延时消息」能成为选型分水岭，而不是可有可无的小功能？—— 因为「下单未支付取消」「超时关闭」这类需求高频且强依赖可靠触发，Kafka 原生没有、只能靠外部定时任务模拟，容错差、开发量大；RocketMQ 把延时做成 Broker 内置能力。所以对业务可靠性敏感的系统，会优先选 RocketMQ。

事务消息

两者都支持事务，但实现方式不同：

Kafka 事务：依赖幂等性 Producer + 事务协调器（Transaction Coordinator）
  场景：跨 Partition 的原子写入
  限制：主要用于 Kafka Streams 的 exactly-once 语义

RocketMQ 事务：Half Message + 本地事务检查 + 二阶段提交
  场景：本地数据库操作 + 发送消息的原子性
  典型：下单 → 扣库存（DB）→ 发订单消息（MQ），两者必须原子

💭 思考：为什么 Kafka 和 RocketMQ 的事务方案长得完全不一样，一个靠「幂等 Producer + 事务协调器」、一个靠「Half Message 两阶段」？—— 因为它们要解决的原子性边界不同：Kafka 事务主要解决「跨 Partition 的流式写入要么全成要么全不成」，协调器能统一控制多个分区的提交；RocketMQ 要解决「本地 DB 事务 + 发消息」两个异构资源的原子性，协调器管不到数据库，只能先把消息「占坑」成 half、等本地事务结果再决定可见。方案差异的根子，是「原子性到底横跨哪些资源」。

广播消费

Kafka 不支持广播——一个 Partition 只能被 Consumer Group 中一个 Consumer 消费。如果需要广播，只能创建多个 Consumer Group。RocketMQ 原生支持 BROADCASTING 模式，同一条消息被所有 Consumer 收到。

Tag / SQL 过滤

这是 RocketMQ 的杀手锏功能：

生产者：msg.setTags("PAID")
消费者：consumer.subscribe("OrderTopic", "PAID || SHIPPED")

Broker 端过滤 → 只推送 Tag 匹配的消息 → 节省网络带宽和消费者资源

Kafka 不支持 Broker 端过滤——所有消息都发给消费者，消费者自己过滤。这在消息量大的场景下浪费大量网络带宽。

💭 思考：为什么「过滤放在 Broker 端还是消费端」能成为关键差异，而不是无关痛痒的实现细节？—— 因为过滤越靠近源头越省资源：Broker 端过滤能在投递前就把不匹配的消息拦下，省掉「Broker→Consumer」的网络带宽和消费端反序列化成本；消费端过滤则是先把全量消息搬过去再挑。消息量一大，两者在网络和 CPU 上的差距就是数量级。所以 Tag/SQL 过滤本质是「把选择下推到数据源」的优化思想。

架构对比

NameServer vs ZooKeeper

Kafka 依赖 ZooKeeper 做元数据管理和 Leader 选举。虽然新版本在逐步去 ZK（KRaft 模式），但大多数生产环境仍在使用 ZK。

RocketMQ 的 NameServer 是无状态的对等节点，任意节点拥有全量路由信息。NameServer 挂了不影响已建立连接的 Client，只影响新连接。

Kafka 依赖 ZooKeeper → 维护成本高（需要额外的 ZK 集群）
RocketMQ NameServer → 轻量，但功能少（无选主，无分布式锁）

消费模型

Kafka 的消费者与 Partition 一一对应，消费者数量不能超过 Partition 数。RocketMQ 的消费者与 Queue 也类似，但通过 MessageListenerOrderly 可以灵活切换并发/顺序消费。

运维与生态

Kafka 的生态优势集中在大数据领域——Kafka Connect、KSQL、Schema Registry 构成了完整的数据流平台。RocketMQ 的生态更聚焦于业务消息场景，在金融、电商、物流领域积累深厚。

决策树：该选哪个？

你的主要场景是什么？
├── 大数据流式处理（日志、埋点、ETL、点击流）
│   └── 选 Kafka
│       理由：生态完善（Connector 直连 HDFS/ES/S3）、
│            超大批次传输（sendfile 零拷贝）、
│            社区大规模验证（LinkedIn 日处理数万亿消息）
│
├── 在线业务消息（订单、支付、通知、IM）
│   └── 先看你的要求
│       ├── 需要延时消息 / 事务消息 / Tag 过滤 / 消息轨迹？
│       │   └── 选 RocketMQ（这些是原生功能，Kafka 需要大量额外开发）
│       ├── 需要多 Topic（> 100）但总体量不大？
│       │   └── 选 RocketMQ（CommitLog 统一存储，Topic 增多不降吞吐）
│       └── 需要强一致（消息不丢、不重复）？
│           └── 选 RocketMQ（同步刷盘 + 同步主从复制，阿里双十一验证）
│
└── 不需要特殊功能，简单可靠即可
    └── 看你团队技术栈
        ├── Java 为主，阿里云上有 RocketMQ 服务 → RocketMQ
        └── 多语言，已有 Kafka 经验 → Kafka

总结

Kafka 和 RocketMQ 不是”谁更好”的问题，而是”谁更合适”的问题：

• Kafka 的基因是日志聚合：大量数据、批量传输、流处理。它的设计假设是消息量极大、允许批量延迟、消费端消费能力强劲。
• RocketMQ 的基因是在线交易：事务消息、延时消息、死信队列、消息轨迹。它的设计假设是消息可靠性第一、功能完备、运维友好。

一个实用的判断标准：如果一条消息丢了，你会不会打电话叫醒 tech lead？会 → 选 RocketMQ（消息可靠性优先）。不会（日志少一条无所谓）→ Kafka 更高效。

章末提问

追问 1：为什么 Kafka 在多 Topic 场景下吞吐会明显下降，而 RocketMQ 几乎不降？

结论先行：因为 Kafka 每个 Topic 每个 Partition 独立成目录，Topic 一多就退化成随机 IO；RocketMQ 所有 Topic 共用一个 CommitLog 顺序写。

因为：Kafka 的存储单元是「分区目录」，1000 个 Topic × 4 分区 = 4000 个目录、4000 个文件句柄和 Page Cache 区域，写入分散导致磁头随机寻道；RocketMQ 的写盘只追加到一个 CommitLog 文件，Topic 只是 ConsumeQueue 索引里的路径前缀，所以 Topic 增多只增加索引数量、不破坏写盘顺序性。

追问 2：sendfile 和 mmap 都号称零拷贝，为什么不统一都用 sendfile？

结论先行：因为 sendfile 全程在内核态「原封不动」传输、无法在途中解析消息，只适合纯搬运；mmap 让用户态直接读写 Page Cache，能做过滤和事务处理。

因为：Kafka 的定位是日志聚合，消息无需加工、批量直传即可，sendfile 两次拷贝、两次上下文切换成本最低；RocketMQ 要在投递前做 Tag 过滤、事务消息检查，必须让进程「看见」消息内容，mmap 共享内存恰好支持这一点，代价是保留了用户态参与。

追问 3：用「丢了一条消息会不会叫醒 tech lead」来选型，本质上在问什么？

结论先行：它在问你业务对「消息丢失」的容忍度，也就是可靠性与吞吐量之间的权衡。

因为：会叫醒说明消息不可丢，选 RocketMQ（同步刷盘 + 同步主从复制 + 事务/延时原生能力）；不会说明丢一条无所谓，选 Kafka（更高吞吐、更丰富的大数据生态）。选型本质是先认清消息的重要性，再反向匹配中间件的设计基因，而不是笼统地比「谁更强」。