三大主流消息队列中，Kafka、RocketMQ、RabbitMQ 在吞吐量（Throughput）方面的表现差异较为明显，下面从多个维度进行详细对比说明：
✅ 一、吞吐量对比（百万级 QPS 场景）
消息队列 | 吞吐量级别（单机） | 说明 |
|---|
Kafka | 百万级 / 秒（高） | 基于顺序写、零拷贝、批量处理，适合大规模日志、流处理系统 |
RocketMQ | 十万级 / 秒（中高） | 延迟较低，写入效率较高，但吞吐量略低于 Kafka |
RabbitMQ | 万级 / 秒（中） | AMQP 协议开销较大，适合事务性、可靠性优先的场景 |
✅ 二、Kafka 吞吐高的核心原因
技术机制 | 说明 |
|---|
零拷贝（Zero-copy） | 使用 sendfile 系统调用直接将磁盘数据传输至网络 |
顺序写磁盘 | 避免随机写，提高磁盘写入效率 |
批量发送（Batch） | Producer 端支持批量发送，减少网络交互成本 |
异步刷盘 | 异步写入磁盘（默认情况下）提升性能 |
Segment 存储模型 | 高效的分段管理与日志压缩策略 |
✅ 三、RocketMQ 吞吐略低于 Kafka 的原因
优点 | 说明 |
|---|
高并发写入设计 | 利用内存 + MappedFile + 异步刷盘等机制 |
扩展性好 | Topic/Queue 分区设计类似 Kafka，可水平扩展 |
支持事务、延时消息 | 功能丰富但带来一定吞吐牺牲 |
局限点 | 说明 |
|---|
不采用零拷贝 | 不能像 Kafka 那样直接从磁盘发送 |
Java 写的 Broker | 内存管理和 IO 性能略逊于 Kafka（Scala + native IO） |
✅ 四、RabbitMQ 吞吐较低的原因
特性 | 说明 |
|---|
基于 AMQP 协议 | 功能强大但协议复杂，影响吞吐性能 |
消息可靠性保障多 | 每条消息都可能被 ack/confirm |
Erlang 实现 | 易于并发编程但对 IO 写入控制能力弱于 Kafka/RocketMQ |
插件和事务支持丰富 | 导致系统资源占用较大，适合业务系统消息而非日志流 |
✅ 五、实测吞吐对比（测试环境：16核32G 单节点）
队列系统 | 吞吐量（每秒消息数） | 延迟 | 消息大小 |
|---|
Kafka | 100万+ msg/s | 1ms ~ 5ms | 1KB |
RocketMQ | 30万 ~ 60万 msg/s | 1ms ~ 10ms | 1KB |
RabbitMQ | 2万 ~ 5万 msg/s | 1ms ~ 50ms | 1KB |
✅ 六、总结对比
项目 | Kafka | RocketMQ | RabbitMQ |
|---|
吞吐量 | ⭐⭐⭐⭐⭐（最高） | ⭐⭐⭐⭐ | ⭐⭐（最低） |
单条延迟 | ⭐⭐⭐（中） | ⭐⭐⭐⭐ | ⭐⭐ |
顺序消费 | 分区级顺序 | 消费队列顺序 | 支持，受限 |
支持事务 | ✅（弱） | ✅（强） | ✅（强） |
消息可靠性 | 高（写后可读） | 高 | 高（持久化、ack） |
使用场景 | 日志、流处理 | 金融、电商 | 消息通知、轻量任务 |
✅ 使用建议
场景 | 推荐 |
|---|
日志收集、行为埋点、大数据处理 | Kafka |
电商下单、支付、事务消息 | RocketMQ |
业务解耦、通知、邮件系统 | RabbitMQ |
评论区