Kafka、RocketMQ、RabbitMQ 有什么区别？如何选型？

简化版

三者定位不同：Kafka 主打超高吞吐，为大数据、日志、流处理而生，功能相对精简、延迟稍高但吞吐第一；RocketMQ（阿里开源）是金融级业务消息首选，功能全面（事务消息、顺序消息、延迟消息、消息回溯都原生支持），吞吐高、可靠性强；RabbitMQ（Erlang，基于 AMQP）路由灵活、延迟低，适合中小规模、复杂路由的业务消息，但吞吐相对最低。选型看场景：大数据/日志选 Kafka，业务消息/金融交易选 RocketMQ，复杂路由/中小流量选 RabbitMQ。

详细版

核心对比：

维度	Kafka	RocketMQ	RabbitMQ
语言	Scala/Java	Java	Erlang
吞吐量	最高（百万级/秒）	高（十万级/秒）	较低（万级/秒）
延迟	毫秒级	毫秒级	微秒级（最低）
功能丰富度	精简	最全（事务/顺序/延迟/回溯）	灵活路由（Exchange）
消息可靠性	高	极高（金融级）	高
顺序消息	分区有序	支持严格顺序	支持有限
延迟消息	需额外实现	原生支持	需插件
事务消息	支持（较弱）	原生完善	不支持
典型场景	大数据、日志、流处理	电商、金融业务消息	复杂路由、中小业务

完整版教学

一、Kafka：为吞吐而生

Kafka 最大的标签是超高吞吐（百万级消息/秒），它是为大数据、日志采集、流处理场景设计的。

优势：

• 吞吐量第一：靠顺序写磁盘、零拷贝、批量压缩、分区并行（见「Kafka 高吞吐」专题）。
• 生态强大：与大数据生态（Flink、Spark、Hadoop）无缝集成，是流处理的事实标准。
• 持久化 + 可回溯：消息按 offset 持久化，可重复消费历史数据。

相对短板：

• 功能相对精简：早期不原生支持延迟消息、事务较弱、单条消息级别的特性少（更偏「流」而非「消息」）。
• 延迟略高：批量攒消息会引入一点延迟（毫秒级，对大数据场景无所谓）。
• 不适合大量 Topic：分区过多时性能下降。

适合：日志收集、用户行为埋点、监控数据、流式计算、大数据管道。

二、RocketMQ：金融级业务消息的全能选手

RocketMQ 是阿里巴巴开源、经过双十一海量考验的消息中间件，定位是业务消息（尤其金融、电商核心链路）。

优势：

• 功能最全：原生支持事务消息（保证本地事务与发消息的最终一致）、严格顺序消息、延迟消息（内置多个延迟级别）、消息回溯（按时间重新消费）、死信队列。这些都是业务场景高频需要的。
• 可靠性极高：金融级，主从同步复制、同步刷盘可选，几乎不丢消息。
• 吞吐高：十万级/秒，虽不及 Kafka，但对绝大多数业务足够。
• 运维友好：Java 编写，国内文档社区丰富，排障方便。

适合：电商订单、支付交易、金融业务、任何需要事务消息/顺序消息/延迟消息的核心业务链路。

三、RabbitMQ：路由灵活、延迟极低

RabbitMQ 基于 AMQP 协议、用 Erlang 编写（Erlang 天生擅长高并发、高可用），主打灵活的路由和极低延迟。

优势：

• 路由灵活强大：核心是 Exchange（交换机） 机制——支持 direct、topic、fanout、headers 多种路由方式，能实现非常复杂的消息分发规则。
• 延迟最低：微秒级，适合对实时性要求高的场景。
• 成熟稳定：老牌产品，社区成熟，管理界面友好。

相对短板：

• 吞吐量最低（万级/秒）：Erlang 和 AMQP 的设计让它不追求极致吞吐。
• 消息堆积能力弱：大量堆积时性能下降明显。
• 功能上：延迟消息要插件、不支持事务消息。

适合：中小规模、需要复杂路由、对延迟敏感、消息量不是特别巨大的业务系统。

四、选型的核心考量维度

选 MQ 时，从这几个维度权衡：

1. 吞吐量需求：海量数据（日志、埋点）→ Kafka；一般业务量 → RocketMQ/RabbitMQ 足够。
2. 功能需求：需要事务消息、严格顺序、延迟消息 → RocketMQ 原生支持最省心。
3. 延迟要求：微秒级极致低延迟 → RabbitMQ。
4. 可靠性要求：金融级不丢 → RocketMQ / Kafka（配置得当）。
5. 技术栈与生态：大数据生态 → Kafka；Java 业务栈 + 国内环境 → RocketMQ；已有 Erlang/AMQP 体系 → RabbitMQ。
6. 团队熟悉度与运维成本：选团队 hold 得住、社区活跃、文档全的。

五、简明区分：选型口诀

• 大数据、日志、流处理、极致吞吐 → Kafka
• 业务消息、金融电商、要事务/顺序/延迟消息 → RocketMQ
• 复杂路由、低延迟、中小流量 → RabbitMQ

没有绝对的好坏，只有是否匹配场景。现实中大厂常常混用：日志走 Kafka、核心业务走 RocketMQ。

六、常见误区与追问

考点	正确口径
Kafka	高吞吐日志流，适合大数据和事件流
RocketMQ	业务消息能力强，事务/延迟/顺序支持好
RabbitMQ	AMQP 生态成熟，路由灵活，吞吐相对较低

selection:
log/event stream, high throughput -> Kafka
transaction/order/delay business messages -> RocketMQ
complex routing, AMQP, moderate throughput -> RabbitMQ

MQ 选型不要只问谁性能最高，要看业务语义：吞吐、事务、顺序、延迟、路由和运维生态。

• 误区：Kafka 吞吐最高所以所有场景都选 Kafka。 业务消息的事务、延迟、重试语义可能 RocketMQ 更顺手。
• 误区：RabbitMQ 过时不能用。 RabbitMQ 在复杂路由、传统企业集成和 AMQP 场景仍有价值。
• 误区：MQ 选型只看单机 TPS。 还要看可靠性、延迟、功能语义、客户端生态、运维成本和团队经验。
• 追问：日志采集为什么常选 Kafka？ Kafka 分区日志、顺序写和批量消费适合高吞吐事件流。
• 追问：电商事务消息为什么常选 RocketMQ？ RocketMQ 原生事务消息、延迟消息和顺序消息能力贴合业务场景。
• 追问：如何做最终选型？ 先列硬需求，再用压测和故障演练验证，而不是只看宣传指标。

七、加强记忆

三大 MQ 定位：Kafka——超高吞吐（百万级/秒），为大数据/日志/流处理而生，功能精简、延迟稍高、生态强（Flink/Spark）；RocketMQ——金融级业务消息全能王，原生支持事务/顺序/延迟/回溯消息，可靠性极高、吞吐十万级、Java 系文档全；RabbitMQ——AMQP + Erlang，路由灵活（Exchange）、延迟最低（微秒级），但吞吐最低、堆积弱。选型口诀：大数据日志选 Kafka、业务/金融/要事务顺序延迟消息选 RocketMQ、复杂路由低延迟中小流量选 RabbitMQ。核心：匹配场景，非优劣。