乐闻世界logo
5月27日 22:23

Kafka 和 RabbitMQ、RocketMQ 怎么选？

核心区别一图看懂

维度KafkaRabbitMQRocketMQ
定位分布式流处理平台传统消息代理分布式消息中间件
吞吐量百万级 TPS万级 TPS十万级 TPS
延迟毫秒级微秒级毫秒级
消息留存按时间/容量保留，消费后不删消费确认后删除可配置保留策略
消费模型Pull 拉取Push 推送为主Push + Pull 均支持
路由能力基于 Topic 和分区Exchange 多种路由模式Topic + Tag 两级过滤
顺序保证分区内有序队列内有序全局顺序消息
事务消息支持（0.11+）不支持原生支持，最完善
适用场景日志流、事件流、大数据管道任务队列、微服务通信、复杂路由电商订单、金融交易、事务消息

为什么 Kafka 吞吐量远超另外两个？

Kafka 的核心设计围绕"顺序写磁盘 + 零拷贝 + 分区并行"三个点。磁盘顺序写速度可达 600MB/s，远超随机写的 100KB/s。零拷贝（sendfile 系统调用）让数据直接从页缓存到网卡，跳过用户态拷贝。分区机制则将负载分散到多个 Broker 并行处理。

RabbitMQ 的优势不在于吞吐，而在于路由灵活性——四种 Exchange 类型（direct、topic、fanout、headers）能实现复杂的消息分发逻辑，延迟也在微秒级别，适合对实时性要求高但吞吐不大的场景。

RocketMQ 在事务消息上做得最完善：半消息 + 本地事务 + 回查机制，保证分布式事务的最终一致性，这是 Kafka 和 RabbitMQ都不具备的。

选型怎么决策？

三个问题就能定：

  1. 消息量大吗？ 日均亿级以上选 Kafka，百万级以下 RabbitMQ 够用
  2. 需要消息回溯吗？ Kafka 天然支持，RabbitMQ 消费完就删
  3. 涉及钱吗？ 金融、订单场景选 RocketMQ，事务消息是刚需

很多团队的做法是 Kafka 做事件流 + RabbitMQ 做任务队列，各取所长。

面试追问方向

  • Kafka 为什么用 Pull 不用 Push？ Push 模式下消费者处理能力不一，慢消费者会拖垮 Broker；Pull 让消费者按自己节奏消费，还方便回溯和批量拉取
  • RocketMQ 的 NameServer 和 Kafka 的 ZooKeeper 有什么区别？ NameServer 无状态、无主从，部署简单但功能弱于 ZK；Kafka 新版 KRaft 模式已去 ZK 依赖
  • 消息积压怎么处理？ Kafka 扩分区 + 增 Consumer；RabbitMQ 临时加消费者队列；RocketMQ 调大消费线程池
标签：Kafka