上一篇把消息队列的三个价值（异步、解耦、削峰）和 RabbitMQ 的位置立了起来。但「RabbitMQ 适合复杂路由和高可靠」这种话，仍然太模糊——它没法回答一个真实的问题：我这个场景，到底用 RabbitMQ 还是 Kafka？
选型最忌讳的是「哪个名气大用哪个」。Kafka 吞吐高，但用它做订单核心链路，你会发现事务、路由、消息即删这些能力都得自己补；RabbitMQ 路由强，但拿它扛日志采集，吞吐和成本都吃不消。选错产品的代价不是性能差一点，而是整个架构都建在错误的地基上，后期迁移成本极高。
这一篇把三大主流 MQ 放在几根可量化的轴上对比，给出一个能落地的选型框架。核心不是记住「谁更好」，而是记住**「按什么维度去比、每个维度谁强」**。
先看它们根本不是一种东西
很多人把 RabbitMQ、Kafka、RocketMQ 当成「同类产品的三个品牌」，这是选型最大的认知误区。它们的设计哲学完全不同：
- RabbitMQ 脱胎于 AMQP 协议，核心模型是**「队列」**——消息从 Exchange 路由进 Queue，消费者从 Queue 里取，取走就删。它是为「在线业务的消息可靠投递」设计的。
- Kafka 的核心模型是**「日志」**——消息按顺序追加到一个不可变的 partition 日志里，消费者按 offset 读取，消息不会因消费而消失。它是为「海量数据的流式处理」设计的。
- RocketMQ 介于两者之间，模型上接近 Kafka（topic + 队列），但补齐了事务消息、定时消息、消息回溯这些在线业务需要的能力，是阿里为电商交易场景定制的。
这个模型差异决定了它们的能力天花板。RabbitMQ 的 Queue 是「消费即删」，天然适合任务分发；Kafka 的 Log 是「消费不删」，天然适合数据回放和流计算。把它们的根本模型搞反，就是选型灾难的起点。
五根轴上的量化对比
把三者放在五根可量化的轴上，差异立刻清晰。这里的数据是经验量级，不是精确基准（具体取决于硬件和配置），但足以支撑选型判断。
| 维度 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 单机吞吐（msg/s） | 万级（约 1–5 万） | 十万到百万级 | 十万级 |
| 单条延迟 | 低（亚毫秒到毫秒） | 中（毫秒级，批处理下更高） | 低（毫秒级） |
| 消息可靠性 | 强，原生 confirm + ack 闭环 | 中，依赖 acks 与副本 | 强，事务消息 + 同步刷盘 |
| 路由能力 | 极强，Exchange + Binding 四种模式 | 弱，基本只有 topic | 中，tag + SQL 过滤 |
| 消息模型 | 队列（消费即删） | 日志（消费不删，按 offset） | 日志 + 队列混合 |
| 顺序消费 | 单队列内有序 | partition 内有序 | 队列内有序 |
| 定时/延迟消息 | 插件或 TTL+死信实现 | 不原生支持 | 原生支持 |
| 事务消息 | 不原生（靠 confirm 保证投递） | 不原生 | 原生支持（半消息回查） |
| 协议支持 | AMQP/MQTT/STOMP 多协议 | 自有协议 | 自有协议 |
| 消息回溯 | 不支持（删了就是删了） | 支持（按 offset） | 支持（按时间） |
| 运维复杂度 | 中（Erlang，集群+插件） | 中高（依赖 KRaft/ZK） | 中（NameServer + Broker） |
读这张表的方法是：先确定你的场景在哪几根轴上有硬约束，再看谁同时满足这些约束。
按场景反推选型
抽象的对比不够，落到场景才有判断力。几个典型场景：
场景一：日志采集与大数据流处理。 日志的特点是量大、能丢一点、需要回放、消费方多。所有这些特征都指向 Kafka：吞吐要求极高（百万级），消息可靠性要求中等（丢几条日志可接受），需要按 offset 重放，多个下游各自消费同一份数据。RabbitMQ 在这里既扛不住吞吐，也无法回放。选 Kafka。
场景二：电商核心交易链路。 订单创建后要通知库存、支付、物流、积分多个下游，每条消息都不能丢，需要事务保证（下单和发消息要么都成功要么都失败），还要支持延迟消息（30 分钟未支付自动取消）。这个场景 RocketMQ 的事务消息和延迟消息是原生能力，最贴合。RabbitMQ 也能做（延迟靠插件，事务靠本地消息表），但要自己补。首选 RocketMQ，RabbitMQ 次选。
场景三：复杂任务分发与多级路由。 一个 SaaS 平台，同一个事件要按租户、按事件类型、按优先级分发到不同的处理队列，有些要广播，有些要按通配符匹配，还要支持死信重试。这是 RabbitMQ 的主场——Exchange + Binding 的路由模型几乎能表达任何分发拓扑，而 Kafka/RocketMQ 的 topic 模型做这种精细路由会很别扭。选 RabbitMQ。
场景四：低延迟的在线任务队列。 用户操作触发的异步任务（生成报表、转码、推送），要求任务进队列后几百毫秒内被消费，消费完即删，消息量不大但延迟敏感。RabbitMQ 的队列模型和低延迟特性最匹配。选 RabbitMQ。
一个可复用的选型决策树
把上面的场景逻辑收成一个决策树，遇到新场景可以套着判断：
- 吞吐是第一约束吗？（百万级、能容忍少量丢失、需要回放）→ 是，选 Kafka。
- 需要事务消息或延迟消息吗？（金融交易、订单超时取消）→ 是，首选 RocketMQ。
- 需要复杂路由或多协议吗？（多租户分发、广播、按规则分流、要 MQTT/STOMP）→ 是，选 RabbitMQ。
- 以上都不是，只是普通的异步解耦？ → 看团队技术栈和现有基建。Java 团队、阿里云生态选 RocketMQ；多语言、已有 RabbitMQ 运维经验选 RabbitMQ；大数据团队选 Kafka。
这个决策树的核心是先看硬约束，再看软偏好。硬约束（吞吐、事务、路由）会直接淘汰不满足的产品；软偏好（团队熟悉度、运维成本）才在多个候选里做最终取舍。
RabbitMQ 不适合的场景
选型不仅要看「适合什么」，更要诚实面对「不适合什么」。RabbitMQ 的短板同样清晰：
- 海量吞吐场景：RabbitMQ 的吞吐定位是「单队列/典型在线业务量级」（经典队列万级、Quorum 略低、4.0 AMQP 1.0 原生后吞吐翻倍），但扛日志采集、埋点上报这类百万级 msg/s 的场景仍会被打爆。海量吞吐是 Kafka 的主场，这是架构层面的定位差异，不是调参能补齐的。
- 需要消息回放的场景：RabbitMQ 的消息消费即删，没有 offset 概念。需要「重新消费三天前的消息」这种需求，它做不到，得用 Kafka。
- 超大消息体：RabbitMQ 不适合传大消息（默认单条上限有限，传几 MB 的消息会严重拖慢 broker）。大消息该走对象存储 + 传引用。
- 强依赖顺序的流处理：虽然单队列内有序，但跨队列、跨分区的全局顺序不是它的强项，复杂流计算交给 Kafka 更合适。
把这些不适合的场景排除掉，RabbitMQ 适合的边界反而更清晰了：中等吞吐、高可靠、强路由、低延迟的在线业务消息链路。
收束：选型是看场景，不是看产品
三大 MQ 没有绝对优劣，只有「是否匹配场景」。Kafka 把吞吐做到极致，代价是功能薄；RocketMQ 在吞吐和在线业务能力之间取平衡；RabbitMQ 牺牲了极致吞吐，换来了最强的路由和最完整的可靠性闭环。
选型的功夫不在「记住谁更好」，而在**「能准确描述自己的场景，再拿场景去套产品的能力轴」**。下一篇会从选型落到 RabbitMQ 内部，讲清楚它的核心模型——AMQP 的 Producer/Exchange/Queue/Consumer 四要素，那是理解 RabbitMQ 所有机制的基础。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。想跟完这套「图解 RabbitMQ」，欢迎关注公众号 「十三Tech」。
