不同的消息队列有什么区别？Kafka、RabbitMQ、RocketMQ、Pulsar、ActiveMQ 选型对比

在后端开发中，只要系统规模稍微大一些，就很容易遇到消息队列（Message Queue，简称 MQ）。

例如：

用户下单后异步发送短信
支付成功后通知积分、库存、物流系统
将日志发送到大数据平台
秒杀流量削峰
服务之间异步解耦
延迟关闭未支付订单

很多刚接触消息队列的人会有一个疑问：

Kafka、RabbitMQ、RocketMQ、Pulsar、ActiveMQ 都是消息队列，它们到底有什么区别？

它们都能完成"发送消息、存储消息、消费消息"这件事，但设计目标并不完全相同。

有的更偏向高吞吐事件流 ，有的更偏向业务消息和复杂路由 ，有的专门强化了顺序消息、延迟消息、事务消息 ，还有的更偏向云原生和多租户场景。

这篇文章就把这些常见 MQ 一次讲清楚。

一、消息队列到底解决什么问题？

在比较不同 MQ 之前，先理解为什么需要消息队列。

假设现在有一个订单服务，用户支付成功后需要执行：

扣减库存
增加积分
发送短信
通知物流
写入数据分析系统

如果订单服务同步调用所有系统，那么其中任何一个服务变慢，都可能拖慢整个支付流程。

加入消息队列以后，可以变成：

text 复制代码

订单服务 -> 消息队列 -> 库存服务
                    -> 积分服务
                    -> 短信服务
                    -> 物流服务

订单服务只需要把"订单支付成功"这个事件发送出去，后面的服务自己消费消息。

这就是消息队列最常见的几个作用。

1. 异步

原本需要同步等待的操作，可以交给消费者异步完成。

例如发送短信并不是支付接口必须立即完成的事情，因此可以异步执行。

2. 解耦

订单服务不需要知道积分服务、短信服务和物流服务的具体实现。

只要发布一条消息即可。

以后增加新的消费者，也不一定需要修改订单服务。

3. 削峰

假设秒杀活动瞬间产生大量请求，数据库无法同时处理。

可以先把请求放入消息队列，再让消费者按照系统能够承受的速度逐步处理。

二、常见消息队列有哪些？

目前后端开发中经常会遇到：

Kafka
RabbitMQ
RocketMQ
Pulsar
ActiveMQ

先看一张整体定位图。

可以先记一个非常粗略的结论：

消息队列	更擅长的方向
Kafka	高吞吐事件流、日志、数据管道
RabbitMQ	业务消息、任务队列、复杂路由
RocketMQ	电商交易、顺序消息、延迟消息、事务消息
Pulsar	云原生、大规模、多租户、跨地域消息平台
ActiveMQ	传统 Java / JMS 企业系统

注意，这张表不是说某个 MQ 只能做某一种事情，而是它们各自最典型的设计方向不同。

三、Kafka

Kafka 与传统"消息队列"的思路有一点不同。

它更准确地说是一套分布式事件流平台。

Kafka 中最重要的几个概念是：

Producer
Topic
Partition
Broker
Consumer
Consumer Group
Offset

消息发送到 Topic 后，会落到不同的 Partition 中。

例如：

text 复制代码

Topic: order-events

Partition 0: M1 M4 M7 ...
Partition 1: M2 M5 M8 ...
Partition 2: M3 M6 M9 ...

消费者通过 Consumer Group 并行消费不同 Partition。

Kafka 最大的特点：吞吐能力强

Kafka 的架构非常适合持续写入大量事件，因此经常被用于：

日志采集
用户行为埋点
CDC 数据同步
数据管道
实时流处理
大数据平台
事件驱动架构

例如：

text 复制代码

业务系统
   ↓
Kafka
   ↓
Flink / Spark / Elasticsearch / 数据仓库

Kafka 的顺序性

Kafka 并不是整个 Topic 全局有序。

Kafka 能够保证的是：

同一个 Partition 内的消息保持顺序。

因此，如果订单事件必须按照顺序处理，通常需要让同一个订单 ID 的消息进入同一个 Partition。

例如：

text 复制代码

orderId = 10001

创建订单
   ↓
支付成功
   ↓
订单发货
   ↓
订单完成

只要这些事件始终进入同一个 Partition，就可以利用 Partition 内的顺序性。

Kafka 的缺点

Kafka 虽然吞吐能力很强，但并不是所有业务都适合它。

例如业务只需要非常灵活的消息路由时，RabbitMQ 的 Exchange 模型通常更加直观。

Kafka 的 Partition、Consumer Group、Offset、Rebalance 等概念也会带来一定学习和运维成本。

四、RabbitMQ

RabbitMQ 是非常经典的消息代理（Message Broker）。

RabbitMQ 的核心模型通常是：

text 复制代码

Producer
   ↓
Exchange
   ↓
Queue
   ↓
Consumer

这里最重要的一个组件就是 Exchange。

Producer 通常不是简单地把消息直接交给某个消费者，而是发送给 Exchange，再由 Exchange 根据路由规则把消息投递到一个或多个 Queue。

RabbitMQ 最大的特点：路由能力强

RabbitMQ 常见的 Exchange 类型包括：

Direct
Fanout
Topic
Headers

例如一个订单事件：

text 复制代码

order.created

可以通过不同的 routing key，把消息发送给不同的队列。

这种模型非常适合：

订单通知
邮件发送
短信发送
异步任务
工作队列
复杂业务路由

RabbitMQ 的确认机制

RabbitMQ 对业务消息的确认、重新投递、死信等机制支持非常成熟。

因此很多传统业务系统会选择 RabbitMQ 处理：

一条消息代表一个需要被可靠处理的业务任务。

例如：

text 复制代码

发送优惠券
发送短信
生成报表
执行异步任务

RabbitMQ 的缺点

如果业务目标是处理持续的大规模事件流、日志流或数据管道，Kafka 往往更符合这种架构思路。

RabbitMQ 更像一个"消息路由和任务分发中心"，Kafka 更像一条可持续保存和回放的"事件日志"。

五、RocketMQ

RocketMQ 是 Apache 下的分布式消息和流平台，在 Java 后端、电商、交易系统中非常常见。

如果学习的是 Spring Boot、微服务、电商系统，RocketMQ 非常值得重点了解。

RocketMQ 的一个重要特点是：

它针对业务消息提供了很多直接可用的能力。

例如：

普通消息
顺序消息
延迟消息
事务消息

1. 顺序消息

例如一个订单必须按照下面的顺序处理：

text 复制代码

创建订单
   ↓
支付订单
   ↓
发货
   ↓
确认收货

RocketMQ 提供 FIFO / 顺序消息相关机制，可以让属于同一消息组的消息按照发送顺序进行存储和消费。

2. 延迟消息

电商中非常经典的场景就是：

用户下单后 30 分钟仍未支付，自动关闭订单。

可以把关闭订单的消息设置为延迟消息。

text 复制代码

创建订单
   ↓
发送延迟消息
   ↓
等待指定时间
   ↓
检查订单是否支付
   ↓
未支付 -> 关闭订单

3. 事务消息

例如：

text 复制代码

数据库订单状态更新成功
        +
订单支付成功消息发送成功

如果数据库更新成功，但是 MQ 消息没有发送出去，就可能产生数据不一致。

RocketMQ 的事务消息就是为这种场景设计的重要能力之一。

因此 RocketMQ 特别常见于：

电商
订单系统
支付系统
金融业务
分布式业务事件

六、Pulsar

Pulsar 与 Kafka 有一些相似之处：

它不仅仅是传统队列，也定位于分布式消息和流处理场景。

Pulsar 比较有代表性的特点包括：

多租户
存储与服务层分离的架构思路
跨地域复制
Topic 数量规模扩展
消息队列与事件流统一
分层存储

因此 Pulsar 经常更适合平台型系统。

例如公司内部有多个业务团队：

text 复制代码

租户 A
  ├─ 订单 Topic
  ├─ 支付 Topic
  └─ 库存 Topic

租户 B
  ├─ 日志 Topic
  ├─ 用户 Topic
  └─ 推荐 Topic

如果需要统一构建企业内部的消息平台，多租户和资源隔离能力就非常有价值。

Pulsar 的问题

Pulsar 的架构能力很强，但相应地系统组件、部署和运维理解成本也可能更高。

如果只是一个规模不大的普通业务系统，没有必要因为"功能多"就优先选择 Pulsar。

七、ActiveMQ

ActiveMQ 是一个历史比较悠久的 Java 消息中间件，在传统 Java 企业项目中非常常见。

它支持多种协议和 Java 消息生态，尤其经常与 JMS 联系在一起。

典型场景包括：

传统 Java EE 系统
JMS 项目
企业应用集成
已经存在大量 ActiveMQ 基础设施的老项目

如果维护的是比较早的 Java 企业系统，很可能会看到 ActiveMQ。

对于新项目来说，则通常还会同时评估 RabbitMQ、RocketMQ、Kafka、Pulsar，以及 ActiveMQ 项目下更现代的 Artemis 等方案，再根据具体需求决定。

八、Kafka 和 RabbitMQ 最大的区别是什么？

这是面试和学习中最常见的问题之一。

可以先这样理解：

RabbitMQ 更强调"把一条业务消息正确地路由、投递给消费者"。
Kafka 更强调"持续记录一条事件流，并让消费者按照自己的进度读取"。

因此二者核心模型也不同。

RabbitMQ

text 复制代码

Producer
   ↓
Exchange
   ↓
Queue
   ↓
Consumer

重点在：

Exchange
Routing Key
Queue
ACK
Dead Letter

Kafka

text 复制代码

Producer
   ↓
Topic
   ↓
Partition
   ↓
Consumer Group
   ↓
Offset

重点在：

Topic
Partition
Consumer Group
Offset
Event Log

如果一定要用一句话记：

RabbitMQ 更像任务分发系统，Kafka 更像分布式事件日志。

这个理解虽然不是完整定义，但非常适合快速建立直觉。

九、Kafka 和 RocketMQ 怎么选？

这两个也是 Java 后端中非常容易被比较的 MQ。

如果业务主要是：

日志
埋点
大数据
实时计算
流式数据处理
CDC

一般优先考虑 Kafka。

如果业务主要是：

订单
支付
电商
延迟消息
顺序业务消息
事务消息

RocketMQ 往往更贴近业务模型。

例如：

text 复制代码

日志采集 -> Kafka

订单支付事件 -> RocketMQ

当然，这并不意味着 Kafka 不能处理订单，也不意味着 RocketMQ 不能做高吞吐场景。

这里只是在讨论更典型的使用方向。

十、RabbitMQ 和 RocketMQ 怎么选？

如果系统更加看重：

灵活路由
Exchange
工作队列
多种消息协议
中小型业务异步任务

可以重点考虑 RabbitMQ。

如果更加看重：

顺序消息
延迟业务
事务消息
大型 Java / 电商业务

可以重点考虑 RocketMQ。

十一、五种 MQ 核心区别总结

对比项	Kafka	RabbitMQ	RocketMQ	Pulsar	ActiveMQ
核心定位	事件流平台	消息代理	分布式业务消息 / 流	云原生消息与流	传统企业消息中间件
典型模型	Topic + Partition	Exchange + Queue	Topic + MessageQueue	Topic + Subscription	Queue / Topic
吞吐倾向	很高	中高	高	很高	中等
路由灵活度	相对简单	很强	较强	较强	较强
顺序处理	Partition 内有序	Queue 场景下可维持顺序，但需考虑并发等因素	支持顺序消息	支持 Key_Shared 等模式处理有序需求	支持传统队列顺序语义
延迟消息	通常需要业务设计或相关机制实现	可通过 TTL / DLX 等方式实现常见延迟场景	原生支持延迟消息	支持延迟投递能力	可实现调度 / 延迟能力
事务相关能力	Kafka Transaction	AMQP 事务 / Publisher Confirm 等	事务消息是重要特色	支持事务能力	JMS Transaction
典型场景	日志、数据流、实时计算	任务、通知、业务路由	电商、订单、交易	云原生消息平台	传统 Java 企业系统

这里的"吞吐倾向"只是架构层面的相对理解，并不是固定性能数据。

实际性能会受到：

硬件
消息大小
副本数量
持久化策略
ACK 策略
网络
消费方式
集群规模

等大量因素影响。

因此不能简单理解成"Kafka 一定比 RabbitMQ 快多少倍"。

十二、实际项目到底怎么选？

可以参考下面这张图。

场景一：日志、埋点、大数据

优先考虑：

Kafka

例如：

text 复制代码

Spring Boot
   ↓
Kafka
   ↓
Flink
   ↓
Elasticsearch

场景二：普通业务异步任务

优先考虑：

RabbitMQ

例如：

text 复制代码

用户注册
   ↓
RabbitMQ
   ↓
邮件服务
短信服务

场景三：电商订单、支付

优先考虑：

RocketMQ

尤其业务需要：

顺序消息
延迟消息
事务消息

时非常合适。

场景四：超大规模云原生消息平台

可以重点评估：

Pulsar

特别是存在：

多租户
跨地域
大量 Topic
平台化消息服务

等需求时。

场景五：老 Java / JMS 项目

可能继续使用：

ActiveMQ

如果是全新项目，则没有必要因为 ActiveMQ 历史悠久就直接选它，应该重新根据业务需求评估。

十三、不要只看"性能"选 MQ

很多人在选消息队列时喜欢问：

哪个 MQ 性能最高？

其实这不是最重要的问题。

真正需要考虑的是：

当前业务是什么类型？
是否要求消息严格可靠？
是否要求顺序？
是否需要延迟消息？
是否存在事务消息场景？
是否需要复杂路由？
消息量大概有多大？
是否需要保存并重复消费历史事件？
团队最熟悉哪一套技术？
运维是否能够支撑对应集群？

例如一个普通后台系统，每秒只有少量业务消息，却为了追求"高吞吐"搭建一套复杂的大规模消息平台，反而可能增加系统复杂度。

因此 MQ 选型永远应该是：

业务需求优先，而不是性能参数优先。

十四、最终怎么记？

如果只想快速记住五种 MQ，可以记下面这五句话。

Kafka

大数据、日志、事件流，优先想到 Kafka。

RabbitMQ

普通业务消息、异步任务、复杂路由，优先想到 RabbitMQ。

RocketMQ

Java 电商、订单、延迟、顺序、事务消息，优先想到 RocketMQ。

Pulsar

云原生、多租户、跨地域、大规模消息平台，重点考虑 Pulsar。

ActiveMQ

传统 Java / JMS 存量系统，经常能够看到 ActiveMQ。

十五、总结

Kafka、RabbitMQ、RocketMQ、Pulsar、ActiveMQ 都可以完成消息传递，但它们的设计重点并不相同。

MQ	一句话理解
Kafka	高吞吐分布式事件日志 / 事件流平台
RabbitMQ	灵活、成熟的业务消息路由代理
RocketMQ	面向交易和业务消息能力很完整的分布式 MQ
Pulsar	云原生、多租户的消息与流平台
ActiveMQ	传统 Java 企业消息中间件

对于大多数 Java 后端开发者来说，学习顺序可以是：

text 复制代码

RabbitMQ / RocketMQ
        ↓
理解业务消息队列
        ↓
Kafka
        ↓
理解事件流和大数据场景
        ↓
Pulsar
        ↓
理解云原生、大规模消息平台

真正掌握 MQ 的关键，并不是背诵谁的吞吐量最高，而是理解：

不同消息队列为什么会采用不同的架构，以及这种架构解决了什么业务问题。

当你能够根据业务场景判断应该使用 Kafka、RabbitMQ 还是 RocketMQ 时，才算真正理解了消息队列的选型。

参考资料

Apache Kafka 官方文档：https://kafka.apache.org/documentation/
RabbitMQ 官方文档：https://www.rabbitmq.com/docs
Apache RocketMQ 官方文档：https://rocketmq.apache.org/docs/
Apache Pulsar 官方文档：https://pulsar.apache.org/docs/
Apache ActiveMQ 官方网站：https://activemq.apache.org/