消息队列选型：Kafka、RabbitMQ、RocketMQ 怎么选？

消息队列选型：Kafka、RabbitMQ、RocketMQ 怎么选？

消息队列是分布式系统里绕不开的基础设施，解耦、削峰、异步这三大作用几乎每个中大型项目都会用到。但市面上主流 MQ 各有侧重，选型时很容易纠结。今天就来横向对比一下 Kafka、RabbitMQ 和 RocketMQ 的核心差异。

先想清楚自己的需求

选型之前先问自己几个问题：

• 吞吐量要求：每秒几万还是几百万消息？
• 可靠性要求：消息能不能丢？是否需要事务消息？
• 延迟要求：毫秒级还是秒级可接受？
• 功能需求：需要延迟消息、死信队列、消息回溯、顺序消息吗？
• 运维成本：团队有没有足够的运维能力？

Kafka：高吞吐的日志流平台

定位：最初由 LinkedIn 开发，定位为分布式流处理平台，更适合日志采集、数据管道、实时计算等场景。

优点：

• 吞吐量极高：单机可达几十万甚至上百万 TPS，得益于顺序写磁盘 + 零拷贝 + 批量发送。
• 生态强大：与 Spark、Flink、Hadoop 等大数据生态无缝集成。
• 持久化能力强：消息持久化到磁盘，支持长时间回溯。

缺点：

• 延迟较高：默认批量发送，毫秒级延迟不如 RabbitMQ。
• 功能相对简单：早期版本不支持事务消息、延迟消息等，需要自己实现。
• 依赖 ZooKeeper：3.0 之前强依赖 ZK，运维复杂度较高（3.0+ 开始支持 KRaft 模式去 ZK）。

适用场景：日志收集、用户行为分析、实时数据管道、流式计算。

RabbitMQ：低延迟的"老牌选手"

定位：基于 AMQP 协议的经典消息队列，以低延迟和丰富的路由功能著称。

优点：

• 延迟极低：微秒级延迟，适合对实时性要求高的场景。
• 路由灵活：Exchange + Binding + Queue 的路由模型非常灵活，支持直连、扇出、主题等多种模式。
• 管理界面友好：自带 Web 管理控制台，监控和运维比较方便。
• 多语言客户端成熟：几乎所有主流语言都有官方客户端。

缺点：

• 吞吐量有限：单机万级到十万级 TPS，数据量上来后性能下降明显。
• Erlang 开发：二次开发和排查问题门槛较高。
• 集群扩展性一般：原生集群不支持分区容错，大规模集群需要借助 Federation 或 Shovel 插件。

适用场景：订单处理、即时通讯、任务分发、对延迟敏感的业务。

RocketMQ：为业务而生的"全能选手"

定位：阿里巴巴开源，最初为双 11 设计，兼顾高吞吐和丰富的业务功能。

优点：

• 功能丰富：原生支持事务消息、延迟消息、顺序消息、死信队列、消息回溯等。
• 高可用：基于 NameServer 的集群架构，支持主从切换，无单点故障。
• 吞吐量较高：单机十万级 TPS，虽然不如 Kafka，但足以应对绝大多数业务场景。
• Java 开发：国内团队上手容易，社区活跃，文档齐全。

缺点：

• 社区国际化程度不如 Kafka：英文资料和海外用户相对少。
• 运维复杂度中等：需要管理 NameServer 和 Broker，比 RabbitMQ 稍复杂。

适用场景：电商交易链路、订单流转、分布式事务、对可靠性要求高的业务系统。

横向对比

一句话选型建议

• 大数据 / 日志流 / 实时计算 → Kafka
• 低延迟 / 复杂路由 / 中小规模 → RabbitMQ
• 电商交易 / 分布式事务 / 业务消息 → RocketMQ

如果团队技术栈以 Java 为主，且业务场景复杂（需要事务消息、延迟消息等），RocketMQ 通常是综合最优解；如果主要是做数据管道和流处理，Kafka 生态无可替代；如果系统规模不大但对延迟极其敏感，RabbitMQ 仍然是不错的选择。