一句话答案

RocketMQ 事务消息：半消息→执行本地事务→提交/回滚，超时未确认则回查本地事务状态，实现最终一致。

核心要点

维度	Kafka	RocketMQ
定位	日志/流式数据处理，大数据场景	金融级消息中间件，业务消息
吞吐量	极高（百万TPS），适合日志收集	高（十万TPS），适合业务消息
消息可靠性	默认异步刷盘，可配置同步	支持同步刷盘（金融级可靠性）
延迟	毫秒到秒级（批量拉取有延迟）	毫秒级（近实时推送）
事务消息	不支持（0.11+ 支持事务但有限）	✅ 原生支持事务消息
延迟消息	不支持（需要自己实现）	✅ 原生支持延迟级别消息
顺序消费	Partition 内有序	✅ 同一队列内有序（更易用）
消息积压处理	强（磁盘存储，容量大）	中等
消费方式	Pull（主动拉取）	Push（Broker 推送）+ Pull
生态	与大数据生态深度集成（Flink/Spark）	阿里巴巴背书，国内广泛使用
社区	Apache，国际化强	Apache，国内中文资料丰富

选型建议：

• 日志收集、埋点分析、流式计算 → Kafka（高吞吐、与大数据生态集成）
• 订单、支付、库存等业务消息 → RocketMQ（事务消息、延迟消息、精确一次）
• 简单消息队列，团队熟悉 AMQP → RabbitMQ（功能全，协议标准）

追问与易错

追问方向：

• 这个概念在你的项目中是怎么应用的？
• 和相关技术/方案相比有什么优劣？
• 如果出了问题你会怎么排查？

易错点：

• ❌ 只知道概念不知道原理——面试官会追问底层实现
• ❌ 缺乏实际使用经验——结合项目场景回答更有说服力

💡 记忆锚点

事务消息 = 双保险快递：先发半消息(快递到中转站暂存)，本地事务成功就盖章放行(commit)，失败就退回(rollback)。万一盖章的人失联了，Broker会主动打电话回查"你到底寄不寄"——实现分布式最终一致性。