做后端架构的，早晚会被问到这个问题：咱们的消息队列用 Kafka 还是 RabbitMQ？这事儿没有标准答案，但选错了后果很实在——吞吐跟不上要重构，可靠性不够要背锅。这篇就把两者的核心差异和选型思路聊透，帮你少踩坑。
先说版本背景。截至 2026 年中，Kafka 最新稳定版是 4.3.1（2026 年 6 月发布），RabbitMQ 最新版是 4.3.4（2026 年 7 月发布）。两个项目都在活跃迭代，但设计哲学完全不同。Kafka 从 4.0 开始彻底移除了 ZooKeeper，全面转向 KRaft 共识协议，架构更轻了；RabbitMQ 4.3 则新增了 32 级消息优先级和延迟重试等特性，在消息控制上更精细了。
先搞清楚消息队列在解决什么问题
选型之前得想明白一件事：你到底拿消息队列干什么？不同场景对队列的要求天差地别。
最常见的三类场景：异步解耦、削峰填谷、事件通知。异步解耦就是服务之间不直接调用，通过消息中转，下游挂了不影响上游。削峰填谷是应对流量突增，比如秒杀场景一瞬间涌进来十万条请求，写进队列慢慢消费。事件通知就比较轻量了，比如用户注册完发个消息通知发短信、推推送。
这三类场景看起来都是"发消息收消息"，但对队列的要求完全不一样。削峰填谷要的是吞吐能力，每秒能吃下多少条消息是硬指标；事件通知要的是灵活路由，一条消息可能要根据类型分发到不同队列；异步解耦则对消息可靠性要求高，丢了消息就是丢了订单。
Kafka 的长板和短板
Kafka 的设计思路是"分布式提交日志"，不是传统意义上的消息队列。它的核心抽象是 Topic + Partition + Offset，消息以追加写的方式存在分区日志里，消费者按 offset 顺序读取。
这套设计带来的最大优势是吞吐量。Kafka 单机就能跑到每秒几十万条消息，集群层面百万级 TPS 不在话下。原因是顺序写磁盘比随机写内存还快，加上零拷贝技术（sendfile），数据从磁盘直接到网卡，不经过用户空间。如果你的场景是日志收集、行为埋点、流数据处理，Kafka 基本上是默认选择。
分区机制是 Kafka 水平扩展的基础。一个 Topic 拆成多个 Partition，分布在不同 broker 上，消费者组里的消费者各认领几个分区，并行消费。想提高吞吐就加分区、加消费者。但这也带来一个限制：分区数一旦定下来就不太好改，改了可能破坏消息顺序。
Kafka 的短板也很明显。首先是消息路由能力弱，基本只能按 key 做分区路由，没有 RabbitMQ 那种 exchange + binding 的灵活路由模型。其次是消费模型偏重，消费者需要管理 offset、处理重平衡（rebalance），4.2 版本虽然把 Kafka Streams 的服务端重平衡做到了 GA，但整体复杂度还是在。最后是运维成本，KRaft 模式虽然去掉了 ZooKeeper，但 broker 配置、分区迁移、副本同步这些操作仍然不简单。
RabbitMQ 的长板和短板
RabbitMQ 是传统 AMQP 消息代理的典型代表，设计思路是"智能路由 + 消息确认"。它的核心模型是 Exchange + Queue + Binding，消息先到 Exchange，再根据绑定规则路由到队列。
这套模型最大的优势是路由灵活性。Direct Exchange 做精准匹配，Topic Exchange 做模式匹配，Fanout Exchange 做广播，Headers Exchange 按消息头路由。一个电商场景里，订单消息可以根据类型路由到发货队列、积分队列、通知队列，配置一下 binding 就行，不用写代码。
消息可靠性是 RabbitMQ 的另一个强项。生产者确认（Publisher Confirm）确保消息到达到队列，消费者手动 ack 确保消息被正确处理后才从队列删除。4.3 版本新增的延迟重试（Delayed Retries）让失败消息的处理更优雅了，不用再死信队列套娃。消费超时（Consumer Timeout）也是个实用功能，消费者卡住了能自动超时重新入队。
RabbitMQ 的短板是吞吐量。单机吞吐通常在万级到十万级 TPS，跟 Kafka 的百万级差一个数量级。原因是每条消息都要经过路由匹配、持久化、ack 确认，开销不小。另外 RabbitMQ 的队列默认是单节点处理的，虽然 Quorum Queue 提供了多副本能力，但性能会进一步下降。如果你的场景需要每秒处理几十万条消息，RabbitMQ 跑起来会很吃力。
几个关键维度拉出来比一下
光说长短板可能还不够具体，下面把几个选型时最关心的维度拉出来对比。
吞吐量：Kafka 完胜，百万级 TPS vs RabbitMQ 的十万级。吞吐是硬指标，差一个数量级就是差一个数量级，优化补不回来。
延迟：RabbitMQ 更低。Kafka 的优化目标是吞吐而非延迟，消息从生产到消费的端到端延迟通常在几十毫秒级别。RabbitMQ 在非持久化模式下可以做到亚毫秒级延迟。对延迟敏感的实时通知场景，RabbitMQ 更合适。
消息可靠性：两者都能做到不丢消息，但机制不同。Kafka 靠副本同步和 ack 确认，RabbitMQ 靠持久化 + ack + 确认机制。RabbitMQ 的消息确认链路更完整，生产者确认、消费者 ack、死信队列、延迟重试一整套，适合对单条消息可靠性要求极高的场景。Kafka 的可靠性更偏重"整体不丢"，单条消息的精确控制不如 RabbitMQ。
消息顺序：Kafka 的分区保证分区内有序，RabbitMQ 的单队列保证队列内有序。但 Kafka 如果分区数变了或者消费者 rebalance，顺序可能短暂乱。RabbitMQ 的顺序保证更稳定。
运维复杂度：Kafka 4.x 用 KRaft 去掉了 ZooKeeper，运维比以前简单了，但分区管理、副本同步、监控指标仍然比 RabbitMQ 复杂。RabbitMQ 的管理界面开箱即用，队列状态可视化，运维门槛低很多。
生态：Kafka 的流处理生态（Kafka Streams、ksqlDB、Flink connector）非常成熟，适合做实时数据管道。RabbitMQ 的生态更偏应用层消息通信，跟各种语言和框架的集成更轻量。
到底怎么选
说了这么多，落到实际选型上，可以用一个简单的决策框架。
先问第一个问题：你的场景是流数据还是业务消息？流数据指的是日志、埋点、监控指标这类持续产生的大批量数据，选 Kafka。业务消息指的是订单、支付、通知这类跟业务逻辑强相关的消息，选 RabbitMQ。
再问第二个问题：你的吞吐需求是多少？日均百万条以下，两个都行，看其他维度。峰值百万 TPS 以上，只能 Kafka。介于两者之间，看消息路由需求——需要复杂路由选 RabbitMQ，不需要选 Kafka。
最后问一个问题：团队对哪个更熟？这个其实很关键。消息队列的运维和开发都需要经验积累，团队熟悉的那个往往是最优选择。一个对 RabbitMQ 很熟的团队硬上 Kafka，踩的坑可能比选型差异带来的收益还大。
还有一种常见做法是两个都用。Kafka 做数据管道层的流式传输，RabbitMQ 做应用层的业务消息通信。很多中大型公司的架构都是这样，各取所长。比如用户下单后，订单系统通过 RabbitMQ 通知发货和积分服务，同时把订单事件写到 Kafka 供数据团队做实时分析。
说白了，选型这件事没有银弹。把场景想清楚，把吞吐、延迟、可靠性、运维这几个维度排个优先级，答案自然就出来了。
