Kafka vs RocketMQ vs RabbitMQ：完整选型决策矩阵
Kafka vs RocketMQ vs RabbitMQ：完整选型决策矩阵
适读人群：需要为新项目选择消息队列，或评估现有MQ迁移方案的架构师和高级工程师 | 阅读时长：约18分钟
开篇故事
我在不同公司用过三种主流MQ，每次技术选型会议上都会碰到同一个问题：我们到底用Kafka、RocketMQ还是RabbitMQ？
印象最深的是2022年加入一家创业公司时，技术负责人问我建议用哪个MQ。当时公司规模不大，日消息量大约500万，但有明确的事务消息需求（电商下单流程）和延迟消息需求（订单超时取消）。
我花了一周时间做了一份详细的选型报告，从吞吐量、延迟、可靠性、运维复杂度、生态支持等维度全面对比。最终选择了RocketMQ。
事后证明这个选择是对的：事务消息和延迟消息的原生支持省去了大量自研工作，运维也不复杂（只有Broker和NameServer两个组件，不需要ZooKeeper）。
今天把这份选型框架整理出来分享给大家。
一、三者的设计哲学差异
在做技术比较之前，先理解三个系统的设计出发点，这决定了它们各自的强项和弱项。
Kafka：为大规模日志流处理而生。LinkedIn开发时的核心需求是：高吞吐量的日志收集和实时流处理。设计上追求极致吞吐，牺牲了一些功能的灵活性（比如消费后消息不删除，必须等过期）。
RocketMQ：为金融级可靠消息而生。阿里双十一场景孵化出来，核心需求是：高可靠、低延迟、支持事务消息。在Kafka基础上做了大量针对金融场景的优化。
RabbitMQ：为灵活消息路由而生。基于AMQP协议，核心理念是Exchange+Queue的路由机制，功能最丰富，适合需要复杂消息路由的场景。
二、核心维度全面对比
2.1 性能对比
实测数据（我们内部测试，仅供参考）：
| 场景 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 单机写入TPS（异步，无压缩） | 85万 | 18万 | 8万 |
| 单机写入TPS（同步，lz4压缩） | 35万 | 12万 | 4万 |
| P50延迟（ms） | 2 | 1 | 1 |
| P99延迟（ms） | 8 | 3 | 5 |
| P999延迟（ms） | 45 | 12 | 25 |
| 10TB数据读取速度 | 极快（零拷贝） | 快 | 慢（消费后删除，无批量读） |
结论：纯吞吐量Kafka碾压，但RocketMQ的P99延迟更稳定，RabbitMQ适合中小流量。
2.2 功能特性对比
| 功能 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 消息持久化 | 文件顺序写，性能极高 | CommitLog顺序写 | 内存+磁盘，可配置 |
| 消息顺序 | 分区内有序 | 全局顺序/分区顺序 | 队列内有序 |
| 消息过滤 | 消费端过滤（Consumer.poll后） | Broker端Tag过滤，SQL过滤 | 路由键+Header过滤 |
| 延迟消息 | 不原生支持 | 原生支持（18个延迟级别） | TTL+死信队列模拟 |
| 事务消息 | 支持（0.11+），Exactly-Once | 原生支持（Half消息） | 不支持 |
| 死信队列 | 不原生支持，需自建 | 支持 | 原生支持 |
| 消息回溯 | 支持（按offset/时间戳） | 支持 | 不支持（消费即删） |
| 消息轨迹 | 需自建 | 原生支持 | 需插件 |
| 多租户 | 需自行隔离 | 支持命名空间 | 支持VHost |
| 消息大小 | 默认1MB（可调） | 默认4MB | 默认128MB |
2.3 运维复杂度
| 维度 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 依赖组件 | ZooKeeper（或KRaft） | NameServer | Erlang运行时 |
| 集群最小节点 | 3（含ZK） | 2（NameServer+Broker） | 1（单节点） |
| 运维难度 | 较高（需懂ZK） | 中等 | 中等（需懂AMQP） |
| 云原生支持 | 一般（Confluent商业版好） | 好（阿里云原生） | 好（各云都有） |
| 社区活跃度 | 极高 | 高 | 高 |
| 文档质量 | 极好 | 好（中文文档好） | 好 |
三、选型决策框架
3.1 决策树
3.2 具体场景推荐
用Kafka的场景：
- 日志收集：每天千亿级日志，Kafka的吞吐和磁盘顺序写无可替代
- 实时数仓：与Flink/Spark Streaming深度集成，生态最完善
- 事件溯源：消息可以无限期保留，支持时间旅行式回溯
- 流式处理：Kafka Streams原生流处理，无需额外框架
用RocketMQ的场景：
- 电商订单流程：事务消息（下单与库存原子）、延迟消息（订单超时取消）
- 金融转账：顺序消息保证账务操作顺序，消息轨迹方便对账
- 秒杀系统：高可靠+Broker端消息过滤+延迟消息综合需求
- 国内互联网公司（特别是阿里技术栈）：中文文档好，阿里云MSE原生支持
用RabbitMQ的场景：
- 微服务间通信：Exchange路由机制天然适合发布-订阅模式
- 工作流系统：复杂的消息路由逻辑（基于Header、路由键）
- 小团队/创业公司：部署简单，单节点就能用，运维成本低
- 需要AMQP协议的场景：和其他AMQP客户端互通
四、Java配置代码对比
4.1 Spring Kafka基础配置
/**
* Kafka生产者配置（Spring Boot方式）
*/
@Configuration
public class KafkaConfig {
@Bean
public KafkaTemplate<String, String> kafkaTemplate() {
Map<String, Object> props = new HashMap<>();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka1:9092,kafka2:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
props.put(ProducerConfig.ACKS_CONFIG, "all");
props.put(ProducerConfig.RETRIES_CONFIG, 3);
props.put(ProducerConfig.LINGER_MS_CONFIG, 5);
props.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
return new KafkaTemplate<>(new DefaultKafkaProducerFactory<>(props));
}
}4.2 RocketMQ Spring Boot配置
/**
* RocketMQ配置（Spring Boot Starter方式）
* pom: rocketmq-spring-boot-starter 2.2.x
*/
// application.yml配置
/*
rocketmq:
name-server: rocketmq-namesrv:9876
producer:
group: order-producer-group
send-message-timeout: 3000
retry-times-when-send-failed: 3
max-message-size: 4194304 # 4MB
compress-message-body-threshold: 4096 # 4KB以上压缩
consumer:
group: order-consumer-group
topic: order-events
*/
@Service
@Slf4j
public class RocketMQSender {
@Autowired
private RocketMQTemplate rocketMQTemplate;
/**
* 发送普通消息
*/
public void sendNormal(String topic, OrderEvent event) {
SendResult result = rocketMQTemplate.syncSend(topic,
MessageBuilder.withPayload(event).build());
log.info("发送成功: msgId={}, status={}",
result.getMsgId(), result.getSendStatus());
}
/**
* 发送延迟消息（RocketMQ特有）
* 延迟级别：1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
*/
public void sendDelay(String topic, OrderEvent event, int delayLevel) {
// delayLevel=4 表示延迟30秒
SendResult result = rocketMQTemplate.syncSend(topic,
MessageBuilder.withPayload(event).build(),
3000, // 超时时间
delayLevel // 延迟级别
);
log.info("延迟消息发送成功: msgId={}, delayLevel={}",
result.getMsgId(), delayLevel);
}
/**
* 发送顺序消息
*/
public void sendOrdered(String topic, OrderEvent event, String orderId) {
// 同一orderId的消息路由到同一队列，保证顺序
rocketMQTemplate.syncSendOrderly(topic,
MessageBuilder.withPayload(event).build(),
orderId // hashKey，相同hashKey的消息路由到同一队列
);
}
}4.3 RabbitMQ Spring Boot配置
/**
* RabbitMQ配置（Spring Boot Starter方式）
* 展示Exchange + Queue + RoutingKey的灵活路由
*/
@Configuration
public class RabbitMQConfig {
public static final String EXCHANGE_NAME = "order.exchange";
public static final String QUEUE_CREATED = "order.created.queue";
public static final String QUEUE_PAID = "order.paid.queue";
public static final String ROUTING_CREATED = "order.created";
public static final String ROUTING_PAID = "order.paid";
/**
* 声明Topic类型Exchange（支持通配符路由）
* Topic Exchange：路由键支持 * 和 # 通配符
* * 匹配一个单词，# 匹配零个或多个单词
*/
@Bean
public TopicExchange orderExchange() {
return new TopicExchange(EXCHANGE_NAME, true, false);
}
@Bean
public Queue orderCreatedQueue() {
return QueueBuilder.durable(QUEUE_CREATED)
// 死信Exchange配置
.withArgument("x-dead-letter-exchange", "order.dlx.exchange")
.withArgument("x-dead-letter-routing-key", "order.dead")
// 消息TTL（毫秒）
.withArgument("x-message-ttl", 300000) // 5分钟
.build();
}
@Bean
public Queue orderPaidQueue() {
return QueueBuilder.durable(QUEUE_PAID).build();
}
/**
* 绑定：order.created.* 路由到 orderCreatedQueue
* 即所有以"order.created."开头的路由键都会到这个队列
*/
@Bean
public Binding bindingCreated() {
return BindingBuilder
.bind(orderCreatedQueue())
.to(orderExchange())
.with(ROUTING_CREATED + ".*");
}
@Bean
public Binding bindingPaid() {
return BindingBuilder
.bind(orderPaidQueue())
.to(orderExchange())
.with(ROUTING_PAID + ".*");
}
}
/**
* RabbitMQ消息发送和消费
*/
@Service
@Slf4j
public class RabbitOrderService {
private final RabbitTemplate rabbitTemplate;
public RabbitOrderService(RabbitTemplate rabbitTemplate) {
this.rabbitTemplate = rabbitTemplate;
}
/**
* 发送订单创建消息
* 路由键：order.created.domestic（国内订单）
* 或 order.created.overseas（海外订单）
* 都会路由到 orderCreatedQueue（因为绑定了 order.created.*）
*/
public void sendOrderCreated(OrderEvent event, String orderType) {
String routingKey = "order.created." + orderType;
rabbitTemplate.convertAndSend(
RabbitMQConfig.EXCHANGE_NAME,
routingKey,
event,
message -> {
message.getMessageProperties().setDeliveryMode(
MessageDeliveryMode.PERSISTENT); // 持久化消息
message.getMessageProperties().setMessageId(event.getOrderNo());
return message;
}
);
log.info("订单消息已发送: routingKey={}, orderNo={}",
routingKey, event.getOrderNo());
}
/**
* 消费订单创建消息
*/
@RabbitListener(queues = RabbitMQConfig.QUEUE_CREATED)
public void consumeOrderCreated(OrderEvent event,
Channel channel,
@Header(AmqpHeaders.DELIVERY_TAG) long deliveryTag) {
try {
log.info("处理订单创建: orderNo={}", event.getOrderNo());
// 业务处理...
// 手动确认（需配置 acknowledge-mode: manual）
channel.basicAck(deliveryTag, false);
} catch (Exception e) {
log.error("处理失败: orderNo={}", event.getOrderNo(), e);
try {
// requeue=false：不重新入队，发到死信队列
channel.basicNack(deliveryTag, false, false);
} catch (IOException ioException) {
log.error("Nack失败", ioException);
}
}
}
}五、踩坑实录
坑1：选了Kafka但需要延迟消息，自研方案踩了很多坑
某个项目选了Kafka做消息队列，但后来需要实现"订单30分钟超时取消"功能。Kafka不支持延迟消息，我们用Redis ZSet自研了一套延迟消息，代码量超过2000行，维护了两年后发现有若干并发Bug，最终还是切换到了RocketMQ。
教训：选型时要考虑3年内的需求变化，而不只看当下。事务消息、延迟消息是电商系统的刚需，如果有这类需求，RocketMQ是更好的选择。
坑2：RabbitMQ消息积压后性能急剧下降
RabbitMQ将消息存储在内存中（持久化时写磁盘），当消息积压超过内存水位（默认40%），触发内存告警，Broker开始暂停接收新消息（Flow Control），整个系统卡住。
教训：RabbitMQ不适合大量消息积压的场景，如果预期会有积压，必须配置vm_memory_high_watermark和磁盘告警，并提前扩容消费者。
坑3：三个MQ同时存在于同一个项目
某公司历史遗留问题，三个MQ都在用：老项目用RabbitMQ，新项目用Kafka，有些微服务因为需要事务消息用了RocketMQ。运维同学需要维护三套集群，开发同学需要记住三套API，监控也要接三套告警。
教训：同一个技术栈尽量统一MQ选型，不同场景可以用同一个MQ的不同Topic来区分，不要轻易引入第三个MQ。
坑4：Kafka在小消息场景的延迟抖动
Kafka的linger.ms默认为0，理论上消息会立即发送，延迟很低。但批量优化机制（batch.size）在流量不均匀时会导致延迟不稳定：流量高时批量快速凑满，P99延迟低；流量低时批次凑不满，等到linger.ms超时才发送，P99延迟上升。
解决：对延迟敏感的消息，用RocketMQ替代。Kafka更适合"高吞吐但对延迟要求不苛刻"的场景。
五、总结与选型建议
一句话总结：
- Kafka：大数据、日志流、实时计算，追求极致吞吐
- RocketMQ：电商金融核心链路，需要事务消息/延迟消息/消息追踪
- RabbitMQ：微服务间解耦、复杂路由、小规模场景，部署简单
对于大多数互联网公司，我的建议是：如果团队有Kafka经验，优先用Kafka；如果有电商/金融复杂消息需求，用RocketMQ；如果是小团队快速起步，用RabbitMQ。不要为了技术而技术，选最适合团队和业务场景的。
下一篇（第437期）深入RabbitMQ死信队列，消息过期、拒绝、队列满三种场景怎么配置，实际项目中的最佳实践。