这是《RocketMQ 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Kafka 和 RocketMQ 都是高吞吐分布式消息系统，但默认设计取向不同。Kafka 早期围绕流式日志和批量传输发展，RocketMQ 更强调业务消息能力，例如事务消息、重试队列、延迟消息和丰富的队列治理。选型要结合业务语义、团队经验和运维能力。
26.1 定位差异
| 维度 | Kafka 常见定位 | RocketMQ 常见定位 |
|---|---|---|
| 核心场景 | 流处理日志管道、事件流 | 业务事件、交易事件、任务消息 |
| 消费模型 | 拉取分区日志 | 拉取队列，Push 封装 |
| 典型生态 | Kafka Connect、Streams、Flink | 业务解耦、事务、延迟、重试 |
| 数据形态 | 高吞吐追加日志 | 业务消息和索引查询 |
这不是绝对边界。Kafka 可以承载业务事件，RocketMQ 也能承载流处理，但生态和默认优化会使成本不同。
26.2 存储模型
Kafka 常见模型：
partition log
segment files
consumer offset
RocketMQ 模型：
CommitLog
all topics appended together
ConsumeQueue
logical queue index
IndexFile
key/time query index
对比：
| 项目 | Kafka | RocketMQ |
|---|---|---|
| 写入组织 | 每个 partition 追加 | Broker 内所有 Topic 汇入 CommitLog |
| 队列数量多时 | 文件和 IO 更分散 | 顺序写更集中 |
| 按消息 Key 查询 | 不是核心能力 | IndexFile 原生支持 |
| 存储层复杂度 | partition 模型直观 | 多层索引需要理解 |
不同版本和云实现都有优化，以上是通用架构差异，不代表所有部署形态。
26.3 消息语义
| 能力 | Kafka | RocketMQ |
|---|---|---|
| 至少一次 | 支持 | 支持 |
| 消费重试 | 应用或生态处理 | 消费组重试队列 |
| 死信 | 依赖生态或自建 | 系统死信 Topic |
| 延迟消息 | 通常应用或生态实现 | 4.x 固定级别，5.x 增强定时能力 |
| 事务消息 | Kafka 事务面向流处理原子写读 | RocketMQ 面向本地事务与消息提交 |
| 消息轨迹 | 生态实现 | 客户端和平台能力 |
两者的事务语义目标不同，不能简单说谁更强。Kafka 事务偏流处理多条记录的原子性，RocketMQ 事务消息偏业务库与消息发送的一致性。
26.4 消费与位点
Kafka：
- 消费者组管理 partition 分配；
- offset 可提交到内部 Topic；
- rebalance 生态成熟；
- 常配合 Streams 或 Flink 管理状态。
RocketMQ：
- 消费者组管理 queue 分配；
- 位点保存在 Broker；
- 提供重试和死信模型；
- Push 客户端封装长轮询；
- 队列数决定最大并行度。
两者都有重复可能，业务都必须幂等。
26.5 性能与延迟
影响性能的因素：
- 消息大小；
- 批量大小；
- 刷盘策略；
- 副本同步；
- 分区 / 队列数；
- 客户端语言；
- 消费逻辑；
- 磁盘和网络；
- 是否冷读；
- 是否开启轨迹和复杂过滤。
粗略结论：
| 场景 | 常见倾向 |
|---|---|
| 大吞吐流日志 | Kafka 常有优势 |
| 大量 Topic 队列写入 | RocketMQ CommitLog 聚合写入有优势 |
| 低延迟小包业务消息 | 需实测 |
| 按业务 Key 查消息 | RocketMQ 更直接 |
不要根据网上单点压测做最终决策，必须用自己的消息大小、副本、延迟目标和磁盘模型压测。
26.6 运维对比
| 维度 | Kafka | RocketMQ |
|---|---|---|
| 元数据 | KRaft 或历史 ZooKeeper | NameServer / Controller 演进 |
| 分区迁移 | 常用重分配工具 | 队列与 Broker 治理 |
| 多租户 | 配额、ACL、生态治理 | ACL、Topic 配额、平台治理 |
| 云托管 | 成熟 | 逐渐增强 |
| 排障生态 | 非常丰富 | 国内实践和社区资料较多 |
团队熟悉度经常比架构差异更影响总成本。
26.7 选型建议
优先考虑 RocketMQ：
- 业务事件需要事务消息、延迟消息、重试死信；
- Topic 和队列数量多；
- 常按消息 Key 查询轨迹；
- 团队已有 RocketMQ 运维经验；
- 需要 Java 客户端深度集成。
优先考虑 Kafka：
- 大规模流式日志管道；
- 以 Flink / Kafka Streams 为核心的数据平台；
- 生态连接器要求高；
- 主要做 append-only 事件流和回放；
- 团队已有 Kafka 平台能力。
26.8 混合架构
常见分层：
business service
-> RocketMQ business events
-> data integration
-> Kafka stream platform
边界：
- 业务动作与事务一致性放 RocketMQ；
- 分析、实时计算、日志汇聚放 Kafka；
- 两边通过 CDC 或事件桥接；
- 统一事件 ID 和 schema 治理；
- 避免双写核心状态。
本章小结
Kafka 和 RocketMQ 的差异来自设计目标：流日志管道与业务消息治理。RocketMQ 的优势在业务消息功能完整、队列治理和消息轨迹；Kafka 的优势在流生态、连接器和高吞吐管道。选型应以业务语义、团队能力和压测结果为准，而不是纸面参数。
思考题
- 为什么不能简单比较两者 TPS？
- RocketMQ CommitLog 聚合写入带来什么收益？
- 两者事务语义有什么不同目标？
- 什么场景适合 RocketMQ 与 Kafka 混用？
- 选型时团队经验为什么重要？