本文最后更新于:2026年2月11日 晚上
Kafka、RocketMQ、RabbitMQ 选哪个?
消息中间件是分布式系统的基础设施,解耦生产者和消费者,实现异步通信、削峰填谷。市面上主流的就这三款。
先说说消息队列能干啥
场景 1:系统解耦
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| 不用消息队列: 订单系统 ──► 库存系统 ──► 物流系统 ──► 积分系统 ──► 营销系统 坑:新增一个系统,订单系统得改代码
用消息队列: 订单系统 ──► 消息队列 ◄── 库存系统 ◄── 物流系统 ◄── 积分系统 ◄── 营销系统 爽:新增系统只管订阅消息,订单系统无感知
|
场景 2:异步处理
1 2 3 4 5 6 7 8 9 10
| 同步处理: 用户下单 ──► 扣库存 ──► 发通知 ──► 加积分 总耗时:400ms
异步处理: 用户下单 ──► 发消息 ──► 立即响应 └────► 扣库存 └────► 发通知 └────► 加积分 总耗时:10ms
|
场景 3:流量削峰
1 2 3 4
| 秒杀场景: 瞬时 10万 QPS ──► 消息队列 ──► 系统以 1万 QPS 匀速处理 避免系统被突发流量冲垮
|
三款消息队列对比
| 特性 |
Kafka |
RocketMQ |
RabbitMQ |
| 开发语言 |
Scala/Java |
Java |
Erlang |
| 吞吐量 |
百万级/秒 |
十万级/秒 |
万级/秒 |
| 延迟 |
毫秒级 |
毫秒级 |
微秒级 |
| 消息可靠性 |
高 |
极高 |
高 |
| 消息顺序 |
分区内有序 |
队列内有序 |
单队列有序 |
| 消息回溯 |
支持 |
支持 |
不支持 |
| 延迟消息 |
需自己实现 |
原生支持 |
原生支持(插件) |
| 事务消息 |
支持 |
支持 |
支持 |
| 死信队列 |
需自己实现 |
原生支持 |
原生支持 |
| 社区生态 |
极丰富 |
较丰富 |
丰富 |
| 云服务 |
成熟 |
阿里云商业版 |
成熟 |
Kafka:大数据领域的扛把子
核心特点
- 吞吐极高:单机每秒百万级消息
- 持久化存储:消息落盘,能保留很久
- 高可扩展:天然分布式,水平扩容简单
- 流处理生态:跟 Kafka Streams、Flink 玩得很好
架构长啥样
1 2 3 4 5 6 7 8 9 10 11 12 13
| ┌─────────────────────────────────────────────────┐ │ Kafka Cluster │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Broker 1│ │ Broker 2│ │ Broker 3│ │ │ │ Topic A │ │ Topic A │ │ Topic A │ │ │ │ P0 P1 │ │ P2 P3 │ │ P4 P5 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ Topic A: 6 个分区,3 个副本 │ └─────────────────────────────────────────────────┘
Producer ──► 分区策略 ──► 写入对应分区 Consumer Group ◄── 分区分配 ◄── 消费消息
|
关键概念:
- Topic:消息主题,逻辑上的分类
- Partition:分区,Topic 的物理分片,并行处理靠它
- Offset:消息在分区里的位置
- Consumer Group:消费者组,组内消费者共同消费一个 Topic
适合干啥
- 日志采集:ELK 栈标配
- 流式处理:实时数据处理管道
- 事件溯源:系统事件持久化
- 高吞吐场景:大数据量传输
坑在哪
- 消息无序:只保分区内有序,不保 Topic 全局有序
- 延迟消息:没有原生支持,得自己搭组件
- 运维复杂:3.0 版本前依赖 ZooKeeper
RocketMQ:阿里出品,企业级选择
核心特点
- 功能齐全:延迟消息、事务消息、顺序消息都原生支持
- 金融级可靠:消息零丢失,支持同步刷盘
- 水平扩展:NameServer 架构,没有单点
- 云原生:阿里云 MQ 的商业基础
架构设计
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
| ┌─────────────────────────────────────────────────┐ │ RocketMQ │ │ │ │ NameServer NameServer NameServer │ │ │ │ │ │ │ └────────────┼────────────┘ │ │ │ │ │ ┌───────────────┼───────────────┐ │ │ ▼ ▼ ▼ │ │ ┌───────┐ ┌───────┐ ┌───────┐ │ │ │Broker │ │Broker │ │Broker │ │ │ │Master │────►│Slave │ │Master │────►... │ │ └───────┘ └───────┘ └───────┘ │ │ │ └─────────────────────────────────────────────────┘
Producer ──► NameServer 路由发现 ──► 发到 Master Broker Consumer ──► NameServer 路由发现 ──► 从 Master/Slave 消费
|
关键概念:
- NameServer:轻量级路由服务,无状态可横向扩展
- Broker:消息存储服务器,Master-Slave 架构
- MessageQueue:类似 Kafka 的分区
高级特性
1. 延迟消息
1 2 3 4
| Message msg = new Message("TopicTest", "TagA", "OrderID188", "Hello".getBytes());
msg.setDelayTimeLevel(3); producer.send(msg);
|
2. 事务消息
1 2 3 4 5 6 7 8 9 10 11 12 13
| TransactionSendResult result = producer.sendMessageInTransaction(msg, localTransactionExecuter, null);
public LocalTransactionState executeLocalTransactionBranch(Message msg, Object arg) { try { boolean success = executeDBTransaction(); return success ? LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE; } catch (Exception e) { return LocalTransactionState.UNKNOW; } }
|
适合干啥
- 电商系统:订单处理、库存扣减
- 金融交易:支付、转账
- 定时任务:延迟消息触发
- 分布式事务:最终一致性保障
RabbitMQ:传统消息队列的标杆
核心特点
- 成熟稳定:Erlang 开发,多年生产验证
- 功能丰富:多种消息模式、插件扩展
- 低延迟:微秒级消息投递
- 易用性好:管理界面友好,文档齐全
核心概念
1 2 3 4 5 6 7 8 9 10 11 12 13 14
| ┌─────────────────────────────────────────┐ │ RabbitMQ │ │ │ │ Exchange ──► Binding ──► Queue │ │ │ │ │ │ ▼ ▼ │ │ Producer Consumer │ │ │ │ Exchange 类型: │ │ - direct:精确匹配 routing key │ │ - topic:模式匹配(*.order.*) │ │ - fanout:广播到所有队列 │ │ - headers:根据 headers 匹配 │ └─────────────────────────────────────────┘
|
关键概念:
- Exchange:消息交换机,决定消息路由到哪
- Queue:消息队列,存消息的地方
- Binding:Exchange 和 Queue 的绑定关系
- Routing Key:消息路由标识
消息确认机制
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
| channel.confirmSelect(); channel.basicPublish("exchange", "routingKey", null, message.getBytes()); if (channel.waitForConfirms()) { System.out.println("消息发送成功"); }
channel.basicConsume("queue", false, (consumerTag, delivery) -> { try { processMessage(delivery.getBody()); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); } catch (Exception e) { channel.basicNack(delivery.getEnvelope().getDeliveryTag(), false, true); } }, consumerTag -> {});
|
适合干啥
- 传统企业应用:稳定可靠的消息传输
- 复杂路由需求:基于规则的灵活路由
- 实时性要求高:低延迟场景
- 中小规模系统:运维简单
怎么选?
按业务场景选
1 2 3 4 5 6 7 8 9 10 11 12 13
| 大数据/日志处理 ──────► Kafka │ 金融/电商/订单 ───────► RocketMQ │ 传统企业应用/路由 ────► RabbitMQ │ 需要延迟消息 ─────────► RocketMQ/RabbitMQ │ 极高吞吐 ─────────────► Kafka │ 强一致性 ─────────────► RocketMQ │ 简单快速部署 ─────────► RabbitMQ
|
详细对比
| 场景 |
推荐 |
理由 |
| 日志收集/大数据分析 |
Kafka |
吞吐高,生态好 |
| 订单/支付系统 |
RocketMQ |
事务消息、延迟消息 |
| 定时任务调度 |
RocketMQ |
原生延迟消息 |
| 实时通知推送 |
RabbitMQ |
低延迟,路由灵活 |
| 微服务异步通信 |
均可 |
看团队熟悉哪个 |
| 事件溯源 |
Kafka |
消息长期存储 |
| 跨语言集成 |
RabbitMQ |
协议支持最好 |
tips
没有”最好”的消息队列,只有”最合适”的:
- Kafka:大数据场景首选,吞吐无敌
- RocketMQ:功能最全,适合复杂业务
- RabbitMQ:稳定成熟,适合传统应用