一、基础定位与核心架构
1. RabbitMQ
底层：Erlang 语言开发，基于 <b>AMQP 标准协议</b>，消息模型为交换机 + 队列
架构：生产者→Exchange（直连 / 主题 / 扇出 / 死信）→Queue→消费者，支持灵活路由
存储：内存 + 磁盘，持久化基于日志 + 索引，单条消息落地
集群：镜像队列集群、联邦集群，主从同步
2. ActiveMQ（含 ActiveMQ Artemis）
底层：Java，初代 JMS 标准实现，Artemis 是下一代重构版本
架构：完全兼容 JMS 1.1/2.0，支持 Queue（点对点）、Topic（发布订阅）
存储：KDB 持久化，支持游标、分页、消息分组
集群：主从、网络桥接集群，跨实例消息转发
3. RocketMQ（阿里开源，Java）
底层：Java，自研轻量消息队列，无标准协议绑定，自定义二进制协议
架构：NameServer（注册中心）+ Broker（消息存储）+ Producer/Consumer，分区（Queue）模型
存储：<b>CommitLog 顺序写文件</b>，海量消息高性能落地，索引单独映射
集群：多主多从、同步 / 异步刷盘，天然支持分布式水平扩容
二、核心功能差异对比
核心差异对比
1. 消息路由能力
RabbitMQ：极强，Exchange 多类型路由：direct、topic、fanout、headers，可复杂绑定、动态路由，适合业务解耦、多订阅分发
ActiveMQ：中等，JMS 标准点对点 / Topic，支持选择器（SQL 过滤消息），路由灵活性弱于 RabbitMQ
RocketMQ：基础，按 Topic + 队列分区分发，仅简单 tag 过滤，无复杂交换机路由，适合简单业务分发
2. 延时 / 定时消息
RabbitMQ：原生无定时，需插件（rabbitmq_delayed_message_exchange），性能差，大量延时消息会卡
ActiveMQ：支持定时、延时消息，精度一般，高并发场景不稳定
RocketMQ：<b>原生高性能定时消息</b>，支持 1s ~ 24h 多级延时，亿级延时消息稳定，业务首选
3. 事务消息
RabbitMQ：无原生事务消息，靠本地消息表 / 事务状态表实现，侵入业务
ActiveMQ：支持 JMS 本地事务、XA 分布式事务，性能损耗大
RocketMQ：<b>原生分布式事务消息</b>（半消息 + 确认 / 回查），低侵入，金融、订单场景标配
4. 消息重试、死信队列
RabbitMQ：自动重试次数可配置，死信交换机 DLX 灵活，可自定义转发路由
ActiveMQ：死信队列 DLQ，支持重发、消息过期丢弃
RocketMQ：消费失败自动重试，死信 Topic，支持手动重试、批量重置位点，运维更友好
5. 消息堆积能力（核心差距）
RabbitMQ：堆积量大后性能暴跌，内存溢出风险高，磁盘随机读，不适合海量堆积
ActiveMQ：中等堆积，大量消息持久化后查询缓慢
RocketMQ：<b>最强堆积能力</b>，CommitLog 顺序写磁盘，百万 / 亿级消息堆积无明显性能衰减，削峰填谷首选
6. 顺序消息
<b>RocketMQ</b>优势明显，能严格保证分区内的消息顺序，非常适合订单、交易等场景。<b>RabbitMQ</b>和<b>ActiveMQ</b>仅能保证单队列内的顺序。
RabbitMQ：单队列保证顺序，多队列无法全局有序
ActiveMQ：支持消息分组、单消费者顺序
RocketMQ：原生分区有序、全局顺序两种模式，生产级稳定，高并发有序场景优势明显
7. 广播、批量发送
RabbitMQ：批量发送支持弱，批量性能一般；fanout 实现广播
ActiveMQ：批量发送、批量消费支持一般
RocketMQ：原生批量生产 / 批量消费，吞吐量提升显著；广播消费模式开箱即用
8. 协议与客户端
RabbitMQ：AMQP、STOMP、MQTT，多语言客户端完善，适合物联网、跨语言异构系统
ActiveMQ：JMS、AMQP、STOMP、MQTT，Java 生态最友好，老系统兼容好
RocketMQ：自定义 TCP 协议，Java 生态完善，Go/Python/PHP 客户端成熟，跨语言弱于 RabbitMQ
三、性能核心区别（吞吐量、延迟、IO 模型）
1. 吞吐量（单机极限从高到低：RocketMQ > ActiveMQ Artemis > RabbitMQ）
<b>RocketMQ</b>
底层：顺序写 CommitLog，零拷贝、PageCache 利用极致
单机 TPS：十万级～几十万 TPS
刷盘策略可配：同步刷盘（金融可靠）、异步刷盘（高性能）
优势：高并发、大流量、电商大促削峰
<b>ActiveMQ Artemis（新版）</b>
新版重构后性能大幅提升，旧版 Classic ActiveMQ 性能很差
单机 TPS：几万～十万 TPS
短板：大量消息堆积后随机 IO 变多，吞吐量下滑
<b>RabbitMQ</b>
Erlang 协程模型并发强，但持久化为随机落盘
单机 TPS：一万～三万 TPS
短板：消息量大、堆积时磁盘随机读写，吞吐量断崖下跌
2. 消息延迟
RabbitMQ：低延迟（毫秒级），小流量场景响应最快
RocketMQ：异步刷盘毫秒级，同步刷盘几十毫秒
ActiveMQ：中等延迟，高并发下延迟波动大
3. 持久化机制本质差距
RabbitMQ：每条消息单独持久化，随机 IO，堆积后磁盘 IO 瓶颈
ActiveMQ：索引 + 消息分开存储，中间表现
RocketMQ：所有消息追加写入同一文件（CommitLog），<b>顺序写</b>，磁盘发挥最大性能，海量消息无压力
四、可靠性对比
<b>RabbitMQ</b>
生产者确认、队列持久化、消息持久化、镜像队列高可用
缺陷：镜像队列同步开销大，集群扩容复杂，堆积易丢性能
<b>ActiveMQ</b>
JMS 规范可靠性，事务、持久化、主从备份
缺陷：旧版内存管理差，宕机可能丢失未刷盘消息
<b>RocketMQ</b>
同步刷盘 + 同步主从双保障，金融级不丢消息；异步刷盘高性能
NameServer 无状态，Broker 多主多从，故障自动切换，运维稳定性最强
五、运维与生态
RabbitMQ
可视化管理面板完善，监控指标齐全
集群复杂，扩容、故障迁移成本高；大数据场景生态弱
ActiveMQ
老旧系统兼容强，JMS 体系老项目首选
社区更新放缓，Artemis 学习成本高，大厂新业务很少选用
RocketMQ
阿里电商打磨多年，运维工具完善，告警、轨迹、消息查询齐全
大数据生态（Flink、Spark）适配好，国内企业普及度极高
六、适用场景总结
RocketMQ 适合
互联网高并发、大促削峰填谷，海量消息堆积场景
订单、支付、金融业务：事务消息、定时延时消息
有序消息、批量收发、大数据实时计算对接
国内 Java 微服务、中大型分布式系统（主流选型）
RabbitMQ 适合
跨语言异构系统、物联网 MQTT 设备接入
需要复杂灵活路由、多订阅分发、多交换机业务
消息量不大、无海量堆积，追求低延迟、简单业务解耦
中小型系统、外企技术栈、遵循 AMQP 标准
ActiveMQ 适合
老旧 Java 遗留系统，强依赖 JMS 规范
传统企业内部低并发业务，不需要高吞吐堆积
需要 XA 分布式事务的传统 Java 项目
不推荐新项目使用，优先替换为 RocketMQ
