Kafka、RabbitMQ、RocketMQ 有什么区别？消息队列怎么选？

知识点详解：把产品名字换成消息的生命周期来看

先问消息消费后还要不要留着

假设一条用户行为事件要被统计、风控和推荐独立处理，明天还可能修复逻辑后重新读取。保留日志与独立消费位置，就比「抢到一个任务赶紧执行」更重要。

Kafka 的分区日志模型适合从这个角度评估。不同消费组可以独立推进，消息保留由策略管理，不因为某一个组读过就马上删除。

如果需求是给工作者分配任务、按条件路由、确认完成后从队列移除，则应优先比较对应队列模型。RabbitMQ 的交换机、绑定和传统队列常用于这类组织方式，但不能把 Streams 等能力也说成同一种删除语义。

顺序和可靠性不能只看功能名

Kafka 的顺序通常以分区为单位；RocketMQ 顺序消息需要按消息组等条件组织；RabbitMQ 队列的实际处理次序还会受消费者并发、优先级和重投影响。

「支持顺序」不意味着跨所有生产者、所有分区全局有序。「支持事务消息」也不意味着任意数据库修改和外部副作用被统一纳入分布式事务。

要顺着完整链路看：生产端是否确认写入，Broker 如何保存和复制，消费者何时确认，业务重试是否去重。某一段可靠，不能替其他段作保证。

把需求写成可测试的条件

假设队列要支撑报表任务。先约定消息体大小、任务时长、峰值、允许等待多久、是否需要取消，以及失败后保留多久。再检查路由、重试和延迟能力是否满足。

压测时使用相近的复制、持久化和确认条件，包含下游变慢、消费者重启与节点故障。否则拿一个异步不等待确认的结果，去比较另一个严格确认的结果，结论并不公平。

还要算团队成本：监控、容量规划、升级经验、故障恢复与客户端支持。产品性能上限很高，并不等于团队已经具备相应运维能力。

先满足模型，再决定要不要增加组件

一种系统可以有多种消息需求，但不必立刻引入三种中间件。现有组件满足主要约束，且成本可接受时，复用通常比追逐功能名更实际。

如果模型确实不同，例如可重放事件流与独立任务调度有明显差别，再考虑边界清晰地分工。不要让同一任务在多种队列间来回搬运，却说不清谁负责最终完成与故障恢复。

上线验收除了看发送成功，还要证明重启后的消费进度、失败重试和业务结果正确。

本题机制参考：Kafka 4.3 Design、RabbitMQ Queues、RabbitMQ Confirms、RocketMQ Ordered Message、RocketMQ Delay Message。

面试官继续追问

Kafka 只能做日志采集吗？

不是。它可承载很多事件与消息场景。分区日志是选型依据，不是限制用途的行业标签。

RabbitMQ 消息消费后一定删除吗？

要看使用的模型与确认行为。传统队列和 Streams 不能混为一个语义。

选择支持 exactly-once 的产品就不用幂等了吗？

不能这样推断。保证范围要看协议、事务和参与资源，外部数据库或接口副作用通常仍需单独设计。

面试速记卡

• 先比保存、路由、重放与失败语义。
• Kafka：分区日志与独立消费进度。
• RabbitMQ：传统队列路由，也有其他模型。
• RocketMQ：主题消费组及顺序、延迟等能力。
• 版本与配置限定能力；同等可靠性下再比性能。