消息队列选型指南：Kafka、RocketMQ、RabbitMQ、Pulsar 架构对比与场景选择

公司要上消息队列，群里开始吵：用 Kafka、RocketMQ 还是 RabbitMQ？领导甩来一句"你定"，结果你看了三份文档更懵了。本文把四款主流 MQ 的架构模型、吞吐量级、功能特性和适用场景一次讲清楚，最后给一张可以直接抄的选型对照表。

为什么需要消息队列

先想清楚 MQ 解决什么问题，才不会选错。核心就三件事：

异步：下单接口要扣库存、发短信、送积分、写日志，全同步做接口要 800ms，塞进 MQ 立刻返回 50ms，其余慢慢消费。

解耦：A 系统产生订单事件，下游库存、搜索、风控都要接。不用 MQ 时 A 要同时调三套接口，新增一个下游就要改 A 的代码；用了 MQ，A 只往 Topic 发一条消息，下游自己订阅，互不感知。

削峰：双十一瞬时 10 万请求打向数据库必挂。MQ 在前面挡一刀，数据库按自己能力匀速消费，峰值被削平。

四款主流 MQ 的架构模型

选型第一步是理解各自的模型，模型决定能干什么。

Kafka：分布式流平台，日志式追加模型。数据按 Topic 分成多个 Partition，每个 Partition 内严格有序、追加写。写入靠顺序 IO + 页缓存 + 批量，吞吐是四者中最高的，天然适合大数据管道、日志采集、监控数据。

RocketMQ：队列模型 + 完善的事务与延迟。阿里开源，Java 写的，基本思路和 Kafka 类似（CommitLog 顺序写 + 逻辑队列 ConsumeQueue），但把"业务消息"场景做得很透：事务消息（本地消息表 + 半消息回查）、任意精度延迟消息、消息轨迹、死信队列都是内置能力，和 Java 生态结合最舒服。

RabbitMQ：AMQP 协议，交换机路由模型。Erlang 写的，性能不如前两者，但胜在功能全、路由灵活：Producer 不直接发到队列，而是发到 Exchange，由 Binding 规则路由到队列。适合对路由规则有要求、消息量万级到十万级每秒的中小型系统，社区和文档对新手最友好。

Pulsar：存算分离的新一代。Broker 无状态，数据落到 BookKeeper，支持分层存储和原生多租户，扩容时不用搬历史分区。强一致性、延迟低，是后起之秀，适合云原生大规模场景，但生态和社区规模目前仍不及前三者。

吞吐量级对比

网上说"百万 TPS"多是压测单机峰值，生产环境要打折看。量级关系大致如下：

四个真实场景的选型答案

场景一：日志采集、埋点、大数据管道——选 Kafka。吞吐第一、可回溯、生态完整（对接 Flink/Spark/ELK 全家桶），为"海量数据流"而生。

场景二：电商订单、交易、金融业务消息——选 RocketMQ。Java 团队维护成本低，事务消息解决"本地事务 + 发消息"一致性难题，延迟消息直接做超时关单，消息轨迹方便排障，还有同城双活能力。

场景三：中小项目、路由规则复杂、要快速上手——选 RabbitMQ。自带管理后台 Web UI，死信交换机、优先级、TTL 开箱即用，团队没有专职中间件运维也能跑。

场景四：云原生、多租户、消息量爆发式增长——选 Pulsar。Broker 无状态随意扩，分层存储把历史消息存到对象存储，省钱又省心，但需要团队有较强中间件能力。

结合你们团队实际判断

除了业务，还要看三件事：团队会什么（全 Java 优先 RocketMQ，会 Scala/大数据直接 Kafka）、运维扛不扛得住（RabbitMQ 单机就能跑，Kafka/RocketMQ 集群要 3 台起步）、云厂商现成产品（云上 RocketMQ/Kafka 基本都有托管版，省掉自建运维）。

如果就是要在项目里先用起来，Java + Spring Boot 生态下 RocketMQ 起步成本最低；如果你司数据平台已经有 Kafka，业务消息直接复用一套也别有负担，毕竟"能落地的架构才是好架构"。

面试速答：Kafka、RocketMQ、RabbitMQ 区别

一句话版本：Kafka 追求吞吐适合数据管道，RocketMQ 在吞吐之上补全了事务与业务消息能力，RabbitMQ 功能均衡、路由灵活但吞吐量级低一档。按业务选，不按名气选。

追问"为什么 Kafka 吞吐最高"：顺序写磁盘 + 页缓存 + 零拷贝（sendfile）+ 批量攒批 + 分区并行，把 IO 路径做到极致；消费端主动 pull，Broker 不维护消费状态，天然适合高吞吐。