RocketMQ 和 Kafka 怎么选？
自测：先别看答案
试着用 1～2 分钟把这道题讲出来（说出声或写下要点），再展开对照。
面试怎么回答
Kafka 定位是高吞吐的日志和流数据管道，顺序写、批量发送、零拷贝，和 Flink、Spark 生态结合紧密，适合大数据链路；RocketMQ 定位是业务消息，所有主题顺序写同一个 CommitLog，主题多时性能更稳定，还原生支持事务消息、延时消息、重试和死信。我会让业务系统间的异步解耦用 RocketMQ，数据采集和实时数仓的数据总线用 Kafka，两者可以并存。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
业务系统常用 RocketMQ，大数据链路常用 Kafka。面试官会问：两者设计上有什么不同？各自适合什么场景？
设计目标不同
- Kafka：面向高吞吐的日志和流数据，强调顺序读写、批量发送、零拷贝，非常适合埋点、日志、CDC 这类海量数据传输，以及和 Flink、Spark 的流计算对接。
- RocketMQ：面向业务消息，提供了很多业务开发需要的功能：事务消息、延时消息、消息过滤、消息轨迹、失败重试和死信队列等。
存储结构的差异
Kafka 每个分区一组独立的日志文件。分区数很多时，大量文件的随机写会让性能下降。
RocketMQ 把一个 Broker 上所有主题的消息顺序写入同一个 CommitLog，再为每个队列建立轻量的消费索引（ConsumeQueue）。主题和队列很多时，写入依然是顺序的，更适合业务场景中主题多、单主题量不大的情况。
功能对比
- 事务消息：RocketMQ 支持「半消息 + 本地事务 + 回查」的模式，保证本地事务和发消息的一致性；Kafka 的事务主要用于跨分区原子写和 Exactly-Once 的读处理写。
- 延时消息：RocketMQ 原生支持，Kafka 需要自己实现。
- 消费失败重试和死信：RocketMQ 内置，Kafka 需要业务侧处理。
怎么选
- 大数据采集、日志、实时数仓的数据总线：Kafka。
- 订单、支付等业务系统之间的异步解耦，需要事务消息、延时消息、重试：RocketMQ。
很多公司两者并存：业务系统用 RocketMQ，数据链路用 Kafka，中间通过同步工具打通。