Kafka、RocketMQ、RabbitMQ 选哪个?

本文最后更新于: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
同步处理:
用户下单 ──► 扣库存(100ms) ──► 发通知(200ms) ──► 加积分(100ms)
总耗时:400ms

异步处理:
用户下单 ──► 发消息(10ms) ──► 立即响应
└────► 扣库存
└────► 发通知
└────► 加积分
总耗时: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());
// 设置延迟级别(1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h)
msg.setDelayTimeLevel(3); // 延迟 10 秒
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("消息发送成功");
}

// 消费者确认(手动 ack)
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:稳定成熟,适合传统应用

Kafka、RocketMQ、RabbitMQ 选哪个?
http://bestkele.com/2023/02/02/concept/message-middleware/
作者
kele
发布于
2023年2月2日
许可协议