RabbitMQ、Kafka、RocketMQ 怎么选：从业务消息到高吞吐日志流的粗粒度判断

这三个名字经常会一起出现，但它们本来就不是同一类主战场。

真正选型时，最怕的是先问“哪个最强”，而不是先问“我的消息到底要解决什么问题”。

先说结论

• 业务消息、路由灵活、上手直观，优先看 RabbitMQ
• Java 业务系统、消息能力更完整，优先看 RocketMQ
• 超高吞吐、日志流、事件流、数据管道，优先看 Kafka
• 如果团队完全没人维护过 MQ，优先选团队最容易驾驭的，不要只看纸面指标

一、RabbitMQ 更像什么

RabbitMQ 更像“传统业务消息总线”。

优点：

• 路由能力灵活
• 管理界面友好
• 学习和接入门槛相对低
• 队列、交换机、绑定关系很适合业务建模

比较适合：

• 订单通知
• 异步解耦
• 工作队列
• 延时、死信、重试等业务消息场景

二、RocketMQ 更像什么

RocketMQ 更像“偏业务交易系统的消息平台”。

比较适合：

• 订单、支付、库存类链路
• 需要重试、顺序、延迟等能力配合的业务
• 对事务消息、顺序消费、回查能力有要求的 Java 团队

它的典型优势在于：
不是只追求吞吐，而是更强调业务消息语义完整。

三、Kafka 更像什么

Kafka 的强项通常不在“复杂业务路由”，而在：

• 超高吞吐
• 分区模型
• 持久化日志
• 可回放事件流

更常见于：

• 日志采集
• 埋点链路
• 大数据流处理
• 事件驱动数据通道
• CDC、流式计算、数据同步

四、选型时最值得看的五个维度

1. 消息模型

你更需要：

• 交换机路由
• 顺序消息
• 广播 / 消费组
• 日志流回放

不同模型直接决定更适合哪一类 MQ。

2. 吞吐和时延

业务消息通常更关注稳定低时延和治理能力；日志流场景更关注吞吐和可回放。

3. 业务能力

比如：

• 延迟消息
• 死信
• 重试
• 事务消息
• 顺序消费

这些能力在不同 MQ 上的落地体验差异很大。

4. 运维复杂度

真正落地时，还要看：

• 团队是否熟悉
• 维护成本能不能接受
• 有没有现成生态
• 监控和排障是否成熟

5. 与你现有系统的贴合度

如果你本身是 Java 为主的业务系统，RocketMQ 常常会比 Kafka 更贴近业务消息治理；如果你本身是大数据或流处理体系，Kafka 往往顺手得多。

五、一个更贴地气的判断方式

如果你主要做普通后端业务系统

优先看：

• RabbitMQ
• RocketMQ

区别通常是：

• 要快速上手、路由灵活、业务模型直观，偏向 RabbitMQ
• 要更完整的业务消息能力，偏向 RocketMQ

如果你是高吞吐日志与数据流场景

优先看：

• Kafka

如果团队没人维护过 MQ

那比起理论最优，先选团队更容易驾驭的，通常更现实。

六、常见误区

1. 只按吞吐选

很多业务消息场景，吞吐根本不是第一矛盾，治理能力和维护成本反而更重要。

2. 用 Kafka 硬做复杂业务消息路由

不是不能做，而是心智和治理成本往往比想象中高。

3. 用 RabbitMQ 扛超大规模日志流

也不是绝对不行，但通常不是它最舒服的战场。

总结

RabbitMQ、RocketMQ、Kafka 不该按“谁更强”来选，而要按“你的消息模型更像哪一类问题”来选。业务消息更看治理和语义，高吞吐事件流更看吞吐和回放能力。场景分清了，选型往往就没那么纠结。