Yilena
境界の備忘録
这里是一处被时间遗忘的避难所。
浮空之岛上，堆叠着理性构筑的文字、应对命运审判的答卷，还有那些在午夜寂静时、从指缝间溜走的虚幻灵感。
终究是要展翅远航的吧。在你的羽翼尚未丰满前，愿这些微弱的火光，能稍微温暖你疲惫的旅程。
文章标签
4206 字
11 分钟
带你对比三大主流消息队列RabbitMQ、RocketMQ以及Kafka
目录
三大队列的详细讲解： 带你轻松学习RabbitMQ-CSDN博客https://blog.csdn.net/2401_88959292/article/details/149294023?spm=1001.2014.3001.5502带你轻松学习RocketMQ-CSDN博客https://blog.csdn.net/2401_88959292/article/details/149296505?spm=1001.2014.3001.5502 带你轻松学习Kafka-CSDN博客https://blog.csdn.net/2401_88959292/article/details/149309549?spm=1001.2014.3001.5502
一、三大MQ该如何进行选型？
在详细讲述每个MQ的博客里我都有总结其适用场景与不适用场景，故在此处我只提供选型树，若想更加详细地了解请翻阅上面三篇博客。
- RabbitMQ的特性决定了其适合中小规模、实时性要求高、需要灵活路由、消息丢失零容忍的场景，不适合大规模高吞吐量、流处理场景。
- RocketMQ的特性决定了其适合大规模高并发、强可靠、需要复杂业务处理的场景，不适合小规模低延迟、简单通信或资源受限的场景。
- Kafka作为分布式流处理平台，其核心特性决定了其适合大规模数据流式传输、实时分析、日志收集等场景，同时在低延迟、强事务、小规模应用等场景下存在局限性。
这么来看，其实使用场景更加广泛一些，这也是为什么我在RocketMQ篇的博客里只能提取出其一个缺点。
二、三大MQ的吞吐量对比？
| MQ | 吞吐量 | 实现原理 |
|---|---|---|
| Kafka | 百万级 | 顺序写：每个分区的日志文件采用Append-Only（追加）模式，磁盘IO为顺序写。sendfile零拷贝技术批量压缩：减少网络I/O 分区并行：一个Topic拥有多个分区 |
| RocketMQ | 十万级 | 顺序写：所有逻辑队列共享一份CommitLog文件，因此磁盘IO就是顺序读写的形式，大大加快了磁盘IO效率mmap零拷贝技术PageCache内存映射：CommitLog和ConsumeQueue均映射到操作系统PageCache，读取消息时直接从内存获取，避免磁盘IO |
| RabbitMQ | 万级 | 存储机制限制：RabbitMQ的队列采用每个队列单独存储的模式，高吞吐量下，多个队列的磁盘IO会相互竞争，导致IO瓶颈（随机写）。Erlang虚拟机：RabbitMQ基于Erlang开发，Erlang的BEAM虚拟机虽然适合高并发小任务，但对于大流量数据传输），其性能不如JVM高效。镜像队列同步开销：镜像队列需要将消息异步同步到多个从节点，高吞吐量下会占用大量网络带宽和磁盘IO。灵活性换取高吞吐：消息会在发送到队列之前由交换机进行路由，可能会造成消息堆积。 |
三、三大MQ的对比？
1. RabbitMQ：微秒级低延迟
- 延迟表现：
- 低负载下可达微秒级，高吞吐量时升至毫秒级。
- 核心优势：
- 轻量级Erlang进程模型，内存操作优先。
- 支持实时消息确认。
2. Kafka：高吞吐下的毫秒级延迟
- 延迟表现：
- 平均2–5毫秒，百万级TPS下保持稳定。
- 核心优势：
- 批量压缩 + 顺序磁盘I/O。
- 零拷贝技术减少数据复制。
- 局限： 小消息批次累积可能增加延迟。
3. RocketMQ：均衡型毫秒级延迟
- 延迟表现：
- 平均3–10毫秒，十万级TPS稳定。
- 核心优势：
- 顺序写入 + 内存映射优化。
- 原生支持延时消息。
因此如果要最求延迟低的话，低并发优先；高并发且消息大优先Kafka；高并发且消息小优先RocketMQ。
四、三大MQ的消息对比？
RabbitMQ：
- 持久化：交换机和队列、以及被标记为持久化的消息数据会存储到磁盘。
- 生产者确认：开启confirm模式后，当消息到达交换机后Broker会发送ack消息给生产者，生产者可根据确认结果重发消息。
- 消费者确认：消费者可选择自动和手动向Broker发送ack消息的方式，从而确保消息是否被消费掉。
- 高可用集群：通过多个Broker节点以及镜像队列、Quorum Queue来实现任意节点宕机的情况下也不会影响消息的正常传递。
RockeMQ：
- 持久化：
- CommitLog：所有消息都写入磁盘（顺序写），确保Broker宕机后消息不丢失；
- ConsumeQueue：Topic-Queue的索引文件，存储在磁盘，确保索引不丢失；
- offset：写入磁盘，确保消费者宕机或重启可以正常拉取后续消息；
- 生产者确认： 生产者支持同步发送、异步发送，确保消息到达Broker。
- 消费者确认： 消费者采用Offset确认机制，处理完消息后发送ACK，Broker更新Offset；若消费者宕机，下次从上次的Offset继续消费，确保至少一次交付；
- 高可用集群： 采用Master-Slave主从副本机制，Master处理读写请求，Slave异步同步Master的数据；Master宕机后，Slave自动晋升为新Master。
Kafka：
- 副本同步：每个分区有多个副本（默认1个Leader+2个Follower），Leader处理读写请求，Follower同步Leader的日志数据。ISR动态维护，确保副本的一致性。
- Leader选举：若Leader节点宕机，Kafka会从ISR中选举新的Leader，整个过程秒级完成，不影响服务。
- 数据可靠性：生产者可配置acks=all（或-1），要求Leader确认消息写入本地日志且多数Follower同步完成后返回成功，保证数据不丢失（适合金融等核心业务）。
可靠性排序（模式且默认配置下）：RocketMQ > RabbitMQ >
五、三大MQ都是如何保障消息有序性的？
- 全局有序（牺牲并发）
- 三个MQ一致：单队列+单消费者（吞吐骤降）。
- 分区有序（高并发方案）
- RabbitMQ：无原生分区，需业务层路由相同ID到同一队列。
- RocketMQ：逻辑队列分区，相同订单ID哈希到同一Queue，消费时锁定该Queue。
- Kafka：Topic切片分区，相同Key的消息写入同一Partition，单线程消费该分区。
六、三大MQ都是如何保障事务一致性的？
- RabbitMQ原生是没有事务支持的，只能通过业务进行事务一致性的绑定，但无法保证本地事务与消息发送的原子性。
- RocketMQ支持半事务消息：
- Kafka支持生产者端的事务，支持原子性发送多个消息到多个Topic/分区，但无法处理事务失败的场景。
所以三大MQ中就只有RocketMQ对事务一致性是有强保障的。
七、三大MQ都是如何保障消费幂等性的？
| MQ | 实现原理 | 缺陷 |
|---|---|---|
| RabbitMQ | 业务层唯一ID+ Redis去重/数据库唯一索引 | 需额外存储，增加延迟 |
| RocketMQ | Message ID + Message Key + 消费位点持久化（避免重复投递） | 网络重试仍可能重复 |
| Kafka | 配置生产者幂等+ 消费者commit_sync手动提交位点 | 分区重平衡时可能重复消费 |
八、三大MQ都是如何处理消息积压问题的？
其实消息积压问题要不就是生产者发送太快，要不就是消费者消费太慢，所以可以拓宽消息传递容器或者增加消费者的方式来处理。
- RabbitMQ
- 使用镜像队列增加消费者节点
- 将大队列拆为多个小队列
- RockeMQ
- 增加Broker节点，拓宽Topic逻辑队列数
- 增加消费者组中的消费者数量
- Kafka
- 增加Topic分区数量
- 增加消费者组中的消费者数量
九、三大MQ都是如何保障高可用的？
- RabbitMQ：
- 镜像队列：将Queue复制到主节点+从节点（如1主2从），主节点处理读写请求，从节点同步消息；主节点宕机后，从节点自动接管（最终一致）。
- Quorum Queue：基于Raft协议的强一致队列，每个Queue有多个副本，消息需被多数节点确认后才会被消费者接收；主节点宕机后，从节点自动选举为新主节点（强一致）。
- RocketMQ：
- NameServer、Broker均采用无状态设计，使得一台宕机也不会给其他节点造成任何影响。
- NameServer定期检查Broker心跳，及时剔除宕机Broker路由，避免消息的无效传递。
- Broker分为主从模式，可自由搭建多主多从的同步或异步模式，且主从都拥有读写权，使得即使主节点宕机了从节点也可以立即接替其职责。
- 定期刷盘使消息数据持久化。
- Kafka：
- 副本同步：每个分区有多个副本（默认1个Leader+2个Follower），Leader处理读写请求，Follower同步Leader的日志数据。ISR动态维护，确保副本的一致性。
- Leader选举：若Leader节点宕机，Kafka会从ISR中选举新的Leader，整个过程秒级完成，不影响服务。
- 数据可靠性：生产者可配置acks=all（或-1），要求Leader确认消息写入本地日志且多数Follower同步完成后返回成功，保证数据不丢失（适合金融等核心业务）。
十、为什么RabbitMQ不适合分布式？
- 队列与节点强耦合
- 队列创建后绑定在特定节点，跨节点访问需代理转发（性能瓶颈）
- 扩容需手动迁移队列（第三方插件支持有限）
- 扩展性缺陷
- 镜像队列扩容后：
- 写入性能不提升（所有节点同步写）
- 网络开销随节点数指数增长
- 对比Kafka/RocketMQ：
| 维度 | RabbitMQ | Kafka/RocketMQ |
|---|---|---|
| 水平扩展 | ❌ 队列绑定节点 | ✅ 分区自动负载均衡 |
| 吞吐提升 | ❌ 单队列受限 | ✅ 分区并行读写 |
总结一下就是RabbitMQ水平扩展性很差，是按垂直扩展来设计的。
十一、三大MQ都是如何操作死信的？
- RabbitMQ
- 触发条件：
- 消息被拒绝且配置requeue=false
- 消息TTL过期
- 队列达到最大长度
- 处理流程：
- 通过
x-dead-letter-exchange声明死信交换机 - 通过
x-dead-letter-routing-key指定路由键 - 死信消息自动路由到指定的DLX（死信交换机）
- 最终进入绑定的死信队列等待处理
- 通过
- RocketMQ
- 触发条件：消息重试消费超过最大次数（默认16次）
- 处理流程：
- 自动转移到死信队列
- 死信队列独立存储，需人工干预处理
- 支持通过控制台重新投递死信消息
- Kafka
- 无原生死信机制：
- 消费失败时需手动提交offset跳过消息
- 常见方案：
- 将异常消息写入专用”死信Topic”
- 使用拦截器捕获异常消息存入数据库
- 配合外部系统（如es）存储死信
十二、三大MQ的消息存储机制与效率对比？
| 维度 | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|
| 存储结构 | 单队列独立文件 | CommitLog+ ConsumeQueue | Partition分段日志 |
| 写入方式 | 内存缓存+随机磁盘写入 | 顺序追加CommitLog+异步刷盘 | 顺序追加日志+PageCache批量落盘 |
| 磁盘效率 | 低（随机IO瓶颈） | 高（mmap零拷贝+顺序IO） | 极高（sendfile零拷贝+顺序IO） |
| 消息查找 | 全队列扫描 | 通过ConsumeQueue二分查找 | 稀疏索引+时间戳定位 |
| 堆积能力 | 万级（内存瓶颈） | 亿级（磁盘优化） | 百亿级（分布式存储） |
十三、三大MQ的的延迟消息的实现方式对比？
- RabbitMQ
- 实现方案：
- TTL+死信队列：设置消息TTL放入无消费者订阅的队列，过期后成为死信来间接达成延迟消息
- 使用插件：
rabbitmq-delayed-message-exchange
- 缺陷：
- 固定TTL需预设多队列
- 高精度延迟支持差
- RocketMQ
- 原生方案：
- 内置18个延迟级别
- 消息存入SCHEDULE_TOPIC_XXXX定时队列
- TimerService线程扫描到期消息
- 优势：毫秒级精度，亿级延迟消息支持
- Kafka（不支持）
十四、三大MQ的消息过滤机制对比？
- RabbitMQ
- 路由过滤：
- Direct Exchange：精确匹配Routing Key
- Topic Exchange：通配符匹配（*/#）
- RocketMQ
- Tag过滤：
- 消费时指定Tag表达式（如”TAG_A || TAG_B”）
- Broker端过滤，减少网络传输
- SQL过滤：
- 基于消息属性过滤（
a>5 AND b='test'）
- 基于消息属性过滤（
- Kafka
- 分区级过滤：Key哈希到特定分区
- 客户端过滤：消费者拉取后本地过滤
- 流处理过滤：Kafka Streams实时过滤
十五、三大MQ的资源消耗模型对比？
| 资源类型 | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|
| CPU | 中（Erlang轻量线程） | 高（Java序列化/压缩） | 低（零拷贝优化） |
| 内存 | 高（消息缓存依赖内存） | 中（堆外内存+PageCache） | 低（PageCache机制） |
| 磁盘IO | 高（随机写） | 中（顺序写） | 极低（批量顺序写） |
| 网络IO | 高（AMQP协议头大） | 中（二进制协议） | 低（批量压缩传输） |
| GC影响 | 无（Erlang） | 明显（Java Full GC） | 可控（堆外内存） |
什么是GC？ GC（Garbage Collection） 是自动回收无用内存的机制。代替程序员手动管理内存，防止内存泄漏和野指针错误。 但其运行过程会对系统性能产生多维度影响，称为 “GC影响”。
GC 在回收内存时，会争夺系统资源并干扰程序运行，导致三大问题： 服务卡顿（STW） 现象：垃圾回收时所有业务线程暂停 后果：消息处理延迟飙升，实时系统违反 SLA 资源争抢 CPU 占用：GC 线程扫描对象消耗计算资源，挤占业务线程 内存碎片：频繁回收后内存零散，可用连续空间减少 系统崩溃风险 Full GC 卡顿过长会导致服务无响应 堆外内存泄漏会导致物理内存耗尽触发OOM
十六、三大MQ的消息优先级支持对比？
- RabbitMQ
- 原生支持：
- 队列声明时设置
x-max-priority（0-255） - 高优先级消息优先出队
- 队列声明时设置
- 限制：仅对未消费的堆积消息有效
- RocketMQ
- 间接实现：
- 创建多级优先级队列（如P0/P1/P2）
- 消费者优先消费高优先级队列
- 缺陷：无法实现动态优先级调整
- Kafka（不支持）
码文不易，留个赞再走吧
原文链接: 带你对比三大主流消息队列RabbitMQ、RocketMQ以及Kafka 作者: Yilena
分享
如果这篇文章对你有帮助，欢迎分享给更多人！
带你对比三大主流消息队列RabbitMQ、RocketMQ以及Kafka
https://blog.csdn.net/2401_88959292/article/details/149312700?spm=1001.2014.3001.5501 部分信息可能已经过时
相关文章 智能推荐
1
带你轻松学习Kafka
技术笔记 本文系统讲解了分布式流处理平台Kafka的核心知识。从Topic、Partition、Broker等基础组件入手，详细剖析了消息从生产者发送、Leader处理与ACK确认，到消费者拉取及Offset维护的完整流程。文章客观分析了Kafka在极致高吞吐、高扩展性及持久化方面的优势，同时也指出了其在全局顺序消息、强事务支持及低延迟场景下的局限性。最后，结合最佳实践，明确了Kafka在大规模数据流传输与日志收集等场景的适用性，为开发者提供了清晰的技术选型与应用指南。
2
带你轻松学习RabbitMQ
技术笔记 本文系统讲解了消息队列RabbitMQ的核心组件与工作流程。从交换机、队列及绑定键的概念入手，详细剖析了消息从生产者发送、交换机路由、队列存储到消费者订阅及ACK确认的完整生命周期。文章客观分析了RabbitMQ在消息零丢失保障、灵活路由、资源隔离及高可用集群设计方面的显著优势，同时也指出了其在高吞吐量场景下的性能瓶颈、资源占用较大及不适合分布式架构等局限性，为开发者在中小规模、高实时性场景下的技术选型提供了清晰指南。
3
带你轻松学习RocketMQ
技术笔记 本文系统讲解了分布式消息中间件RocketMQ的核心组件与工作流程。从NameServer、Broker、Topic等基础概念入手，详细剖析了消息发送、接收、逻辑队列构建、消费者拉取及ACK确认的全过程。文章客观分析了RocketMQ在高吞吐量、分布式事务支持、高可用机制及消息高可靠性等方面的显著优势，同时也指出了其在高并发顺序消息场景下的性能瓶颈。最后，结合最佳实践，明确了RocketMQ在大规模高并发、金融级强可靠及分布式服务解耦等场景的适用性。
4
360s→15s：近25倍的性能优化重构十万Excel券码批量导入方案
业务拆解 本文针对十万级Excel券码批量导入场景，将原逐行解析导致的20万次网络IO，通过Redis管道与MQ批处理优化至182次。方案兼顾了宕机恢复与库存扣减，最终将耗时从360秒大幅缩减至15秒左右。
5
116秒→6秒：Redis管道+批处理优化用户好友关系校验的方案
业务拆解 本文针对社交平台中用户好友关系数据一致性问题，提出了一种高效的定时任务解决方案。通过分析初版方案的性能瓶颈（单线程串行处理导致116秒耗时），逐步优化为多线程并行处理（70秒）和最终版批量预加载策略（6秒）。终版方案的核心改进包括：1）预加载所有关注关系并建立内存映射；2）批量处理好友数据更新；3）使用Redis管道技术减少网络请求。最终将请求次数从35万次降至常数级，同时提供了完整的Java实现代码，包含分片处理、批量数据库操作和Redis管道更新等关键优化技术。