消息队列 Kafka 和 RabbitMQ 该怎么选

结论：需要超高吞吐、可重放、按时间保留的消息（日志采集、埋点、流式处理、事件溯源）选 Kafka；需要复杂路由、延迟任务、逐条确认和优先级（业务解耦、订单履约、定时通知）选 RabbitMQ。这不是二选一的题目——中大型系统同时跑一套 Kafka 加一套 RabbitMQ，是最常见的落地方式。

Kafka 和 RabbitMQ 的本质区别是什么？

结论：Kafka 是「可重放的分布式日志」，RabbitMQ 是「带路由能力的消息队列」，两者的数据模型根本不同。

Kafka 的消息写进分区（partition，日志的水平切分单元）后，只按时间或大小过期删除，默认保留 7 天（log.retention.hours=168），跟有没有人消费无关。消费者靠 offset（消费位点）记录读到哪，读慢了不影响消息存活，也能把 offset 重置到 earliest 重放历史数据。

RabbitMQ 走的是 AMQP（Advanced Message Queuing Protocol，高级消息队列协议）模型：生产者发到 Exchange，Exchange 按 Binding 规则路由到 Queue，消费者 ack（消费确认）后消息即被删除。所以 RabbitMQ 无法「回到过去重新消费」，这是它和 Kafka 最硬的差别。

吞吐量差多少？

结论：两者差一到两个数量级——Kafka 单集群可跑到百万条/秒量级，RabbitMQ 单节点在持久化+ack 场景下实测多在 2 万~5 万条/秒区间（具体取决于硬件、消息体大小和确认模式）。

Kafka 靠三个东西拉高吞吐：磁盘顺序写、零拷贝（sendfile 系统调用）、批量压缩。官方基准测试里，3 台普通服务器、每条 100 字节、三副本，能跑到约 100 万条/秒。

RabbitMQ 的瓶颈在单队列：队列元数据和索引在 Erlang 进程内，堆积几十万条以上时延迟明显上升。它的优势从来不是吞吐，而是路由灵活度。

什么场景必须选 RabbitMQ？

结论：只要你的需求里出现「按规则分发」「延迟执行」「每条消息单独确认」这三类词，优先 RabbitMQ。

具体表现在：

• 路由能力：Exchange 支持 direct / topic / fanout / headers 四种类型，一条消息能按通配符路由到多个队列，Kafka 只能用 topic + key 分区，粒度粗得多。
• 延迟队列：RabbitMQ 用 TTL（消息存活时间）+ DLX（死信交换机）或 rabbitmq_delayed_message_exchange 插件实现「30 分钟后关单」，Kafka 没有原生延迟消息，只能自己起时间轮或靠 Streams 窗口模拟。
• 可靠投递：publisher confirm + 手动 ack + 死信队列，能精确控制到单条消息的成败；还支持优先级队列。
• 按队列扩容：加消费者就能提升并发，运维心智简单。

什么场景必须选 Kafka？

结论：数据量到「亿级堆积」、需要重放、要接入流计算时，Kafka 没有替代品。

• 日志/埋点采集：日增 TB 级，Kafka 堆积上亿条仍能正常消费，RabbitMQ 到这个量级基本不可用。
• 事件溯源与重放：新上线一个下游服务，把 offset 重置到 7 天前重新消费一遍即可，RabbitMQ 做不到。
• 流处理：Flink、Spark Streaming、Kafka Streams 原生对接，Exactly-Once 语义由 0.11 版本引入的幂等 Producer + 事务保证。
• 顺序性：同一 key 落到同一分区，分区内严格有序；RabbitMQ 要保证顺序只能单队列单消费者，吞吐会被锁死。

运维成本上要注意什么？

结论：Kafka 的集群运维比 RabbitMQ 更重，但两者都在简化。

Kafka 传统上依赖 ZooKeeper，2.8 版本引入 KRaft 模式，3.3 起 KRaft 可用于生产，3.5 起 ZooKeeper 被标记弃用，新集群建议直接上 KRaft。RabbitMQ 依赖 Erlang 运行时，集群里传统镜像队列已被 Quorum Queue（基于 Raft 的复制队列）取代，3.8 之后新项目应优先用 Quorum Queue。

扩容方向上：Kafka 加 broker、加分区即可水平扩展，但分区数只能增不能减，规划时要留余量；RabbitMQ 的单个队列不能跨节点分片，热点队列只能靠拆队列解决。

到底该怎么选？

结论：按「数据量级 + 是否要重放 + 路由复杂度」三个问题做决策，多数团队最终是两套并用。

判断流程：日增消息在千万级以下、需要延迟和复杂路由、消息消费完即可丢弃——RabbitMQ；日增消息上亿、需要回放、下游是 Flink/数仓——Kafka。真实系统里典型分工是：核心业务链路（下单、支付回调、通知）走 RabbitMQ 保证可靠和灵活，全量日志、行为埋点、CDC 数据同步走 Kafka 喂给数据平台。

最后提醒一句：选型前先用自己真实的报文体大小压一遍，100 字节的消息和 10KB 的消息，两者的吞吐差距可能到 10 倍，别直接套用别人的 benchmark。