消息队列选型：RabbitMQ vs Kafka vs RocketMQ 实际对比
Message Queue Comparison: RabbitMQ vs Kafka vs RocketMQ in Practice
| Kevin | 2026-08-27T11:55:38
最近要给新项目选消息队列，对比了三种主流方案的实际使用体验。不谈参数不背书，只说真实感受。
Comparing three mainstream message queue solutions for a new project. No benchmarks, just real-world experience and practical insights.
消息队列选型的文章网上一搜一大堆，但大多数都是抄来抄去的参数对比。这篇文章说说我实际用过这三种消息队列之后的真实感受。 RabbitMQ 适合场景：业务消息、任务队列、RPC RabbitMQ 是最"传统"的消息队列，AMQP 协议实现得很完整。几个印象深刻的点： Exchange + Queue + Binding 的路由模型非常灵活，topic、fanout、headers 各种模式都有 消息确认机制很完善，ack/nack/reject 粒度很细 管理界面超好用，队列状态一目了然 单机吞吐量大概在万级 QPS，对于大多数业务场景够用 坑：消息堆积到百万级的时候性能断崖式下降，队列越长越慢。所以 RabbitMQ 不适合当数据管道用。 Kafka 适合场景：日志采集、数据管道、事件流 Kafka 的设计理念跟 RabbitMQ 完全不同，它本质上是一个分布式日志系统： 吞吐量恐怖，单节点轻松 10 万+ QPS 消息持久化到磁盘，支持重新消费历史消息 Consumer Group 的概念设计得很优雅 生态丰富，Kafka Streams、Kafka Connect 做流处理很方便 坑：运维复杂度高，依赖 ZooKeeper（虽然新版在去 ZK），partition 数太多会影响性能。另外消息延迟比 RabbitMQ 高，不适合对延迟敏感的场景。 RocketMQ 适合场景：电商交易、金融场景、需要事务消息 阿里出品，在电商交易场景验证过的： 支持事务消息，这个在电商场景非常刚需 延迟消息原生支持 吞吐量在 Kafka 和 RabbitMQ 之间 消息堆积能力强，不会像 RabbitMQ 那样堆积后性能下降 坑：社区版和商业版功能差距大，文档质量参差不齐，英文资料少。 我的选择 最终我们新项目选了 RabbitMQ，原因很简单：团队规模小，业务量不大，需要的是"好用"而不是"能扛"。等哪天业务量真上来了，再考虑切换也不迟。
Real-world comparison of three mainstream message queues after actually using them in production. RabbitMQ Best for business messaging, task queues, RPC. Excellent routing model and management UI. ~10K QPS per node. Watch out for performance degradation with millions of queued messages. Kafka Best for log collection, data pipelines, event streaming. 100K+ QPS per node. Higher operational complexity and message latency. RocketMQ Best for e-commerce transactions requiring transactional messaging. Strong backlog handling. Community vs commercial feature gap is significant. Our Choice Went with RabbitMQ for its ease of use at our scale.