第3章　消息队列核心概念与选型对比

🎯 面试官考察点
能否跳出API层面，从吞吐、可靠性、延迟、事务等本质差异思考；是否有真实选型经验。

📐 回答框架
场景归类 → 性能指标对比 → 关键功能差异 → 给出推荐并说明理由。

💡 简短示例回答
“如果业务是海量日志采集（日均百亿条），选Kafka，因为分区顺序写+页缓存能支撑超高吞吐；如果核心交易需要强一致事务消息，选RocketMQ，支持半消息和事务反查；如果团队规模小、要求快速接入且延迟<5ms，选RabbitMQ，社区插件丰富。”
（共98字）

🔍 可能追问

• Kafka 的 Exactly Once 语义如何实现？
• RocketMQ 事务消息与 RabbitMQ 的 publisher confirm 有何本质不同？
• 如果要求消息严格顺序，三者的实现代价分别是多少？

🎯 面试官考察点
是否理解零拷贝、顺序写、批量处理等底层机制，以及这些设计在不同场景下的适用边界。

📐 回答框架
Kafka 核心设计 → RocketMQ 对应实现 → 优劣对比（吞吐 vs 可靠性）→ 总结适用边界。

💡 简短示例回答
“Kafka 高吞吐靠三个机制：零拷贝（sendfile）、顺序写（分区追加）、批量压缩。RocketMQ 虽然也采用顺序写，但为了支持事务和低延迟，刷盘策略更保守，吞吐约降20%-30%，但在万级TPS场景下可靠性更高。因此Kafka适合大数据管道，RocketMQ适合金融级消息。”
（共99字）

🔍 可能追问

• 零拷贝在 Kafka 中具体从哪一步到哪一步？
• RocketMQ 的“同步刷盘”与 Kafka 的“异步刷盘”对性能影响有多大？

🎯 面试官考察点
是否理解 Exchange 模型与 Topic 模型的区别，以及如何利用路由模式解耦微服务。

📐 回答框架
RabbitMQ 路由模型 → Kafka 消费模型 → 路由灵活性对比 → 给出模式建议。

💡 简短示例回答
“RabbitMQ 提供 direct/topic/headers 等 Exchange，支持多级路由绑定，适合复杂事件分发（如订单状态变更通知多个微服务）；Kafka 只基于 Topic 和分区，消费者需手动匹配 key，路由能力弱，但配合 Stream API 可做事件溯源。因此实时路由选 RabbitMQ，流式处理选 Kafka。”
（共98字）

🔍 可能追问

• RabbitMQ 的“死信队列”与 Kafka 的“DLQ”实现有何不同？
• 如果要在 Kafka 上实现类似 routing key 的功能，你会怎么设计？