消息队列选型：Kafka、RocketMQ、RabbitMQ 对比与实战

📅 创建于 2026-06-02 🔄 更新于 2026-06-02 📝 323 字

architecture database messaging java troubleshooting

来源：北哥 | 发布日期：2026-05-22

选型原则：需求先行

选型最大的坑是「先看产品特性，再往自己业务上套」。正确顺序：先把业务场景和核心诉求写下来，再对照产品。

典型的业务需求维度：

成熟最早（2007），用户群体最广。

大数据领域事实标准。

阿里 2012 年开源，专为电商业务消息设计。

特性	RabbitMQ	Kafka	RocketMQ
吞吐量	万级/秒	百万级/秒	十万级/秒
消息延迟	微秒级	毫秒级	毫秒级
延迟消息	需插件模拟	❌ 不支持	✅ 原生 18 级
事务消息	❌	❌（方案复杂）	✅ 原生支持
消费重试	需自行实现	需自行实现	✅ 默认 16 次
死信队列	需配置	❌	✅ 自动进入
运维难度	低	高	中
开源语言	Erlang	Scala/Java	Java
适用场景	复杂路由/低延迟	大数据/日志	业务消息/电商

有延迟消息需求（下单30分钟未支付自动取消），Kafka 原生不支持，自行实现维护成本高，直接排除。

三个核心需求对比：

延迟消息：RocketMQ 原生 18 个延迟级别（1s/5s/10s/30s/1m/2m...2h），一行配置搞定。RabbitMQ 需 TTL Queue + 死信队列，绕三层且不灵活。
事务消息：RocketMQ 直接支持。RabbitMQ 需本地消息表 + 重试，代码量大。
消费重试：RocketMQ 内置阶梯式重试（1s→5s→...→16次后进死信队列），零代码。RabbitMQ 需自行处理。

团队全是 Java 栈，RocketMQ 是 Java 实现，遇问题可直接读源码。国内大厂广泛使用，中文资料丰富。

只配了一个 NameServer，该节点重启期间生产者偶尔连不上。解决：配全所有节点地址。

rocketmq.name-server=192.168.1.1:9876;192.168.1.2:9876

默认消费者线程数 20，Topic 消息量上来后开始堆积。增加到 64 后恢复正常。

consumer.setConsumeThreadMin(20);
consumer.setConsumeThreadMax(64);

RocketMQ 只有预设 18 个延迟级别，不支持任意秒级延迟。如果业务需要精确到秒的延迟（如 37 秒），需改用 Redis ZSet 或商业版。30 分钟未支付场景用第 14 级（20 分钟）加兜底查询可解决。