一、核心定位底层设计不同

1. RabbitMQ 定位是企业级通用消息队列，基于 AMQP 协议；核心设计目标是灵活可靠的业务消息投递，交换机 + 队列模型，面向业务解耦、复杂路由、消息重试场景。 存储模型：消息投递到队列，消费确认后可删除；采用推送模式，Broker 主动推消息给消费者。
2. Kafka 定位是分布式流式日志系统，自研 TCP 协议；最初为日志采集设计，核心追求高吞吐、海量消息持久化；架构是 Topic + 分区 + 副本，消息以日志段形式顺序写入磁盘；消费者主动拉取数据。

二、核心维度详细对比

1. 吞吐量

• Kafka：极高，顺序写磁盘、零拷贝、批量压缩，单机支持百万级 QPS，海量数据流无压力；
• RabbitMQ：中等，单节点万～十万级，镜像 / 仲裁队列同步、复杂路由都会损耗性能，高并发海量消息场景短板明显。

2. 路由分发能力（RabbitMQ 核心优势）

RabbitMQ 提供直连、扇形、主题、死信交换机、绑定过滤，一条消息可以分发到多个不同队列，灵活做分流、过滤、广播；原生支持延迟队列、TTL 死信重试。 Kafka 只有 Topic 分区，路由能力极弱，只能按 key 哈希分区，没有内置过滤、延迟、重试能力，复杂分发需要上层代码自己封装。

3. 消息堆积能力

• Kafka：天生支持海量堆积，消息长期持久在磁盘，保存数天甚至几周，堆积不影响读写性能；
• RabbitMQ：大量堆积会占用大量内存，触发流控阻塞生产者，堆积量大时性能暴跌。

4. 可靠性与异常处理

1. RabbitMQ 仲裁队列基于 Raft 多数派写入，生产者 confirm、手动 ACK、死信队列全套能力；消费失败可自动延迟重试，异常消息隔离简单，金融、交易业务友好。
2. Kafka 依靠 ISR 副本机制保证数据不丢，支持事务；但无原生死信、延迟重试，消费失败重试、异常消息隔离需要额外搭建重试 Topic，开发成本高。

5. 消费模式

• RabbitMQ：Push 推送模式，可通过 prefetch 控制预取数量，实时性更好；
• Kafka：Pull 拉取模式，消费者自主控制拉取速率，消费者慢不会压垮 Broker。

6. 数据留存机制

RabbitMQ：消息消费 ack 后即可删除，只临时存储待消费数据； Kafka：消息不会消费完立刻删除，根据配置保留固定时长，支持回溯历史数据，适合大数据回放分析。

7. 集群高可用

• RabbitMQ：旧版镜像队列（异步复制有丢数风险），新版仲裁队列 Raft 强一致；
• Kafka：分区多副本 ISR 机制，自动 leader 切换，横向扩容分区即可提升吞吐，扩容更简单。

三、什么场景优先选 RabbitMQ

满足以下任意一点，推荐 RabbitMQ：

1. 核心交易业务：订单、支付、退款、账务、商户通知，对消息可靠性、异常容错要求高；
2. 需要复杂消息路由、一对多广播、消息过滤，一条消息分发多个下游业务；
3. 业务需要定时消息、失败自动延迟重试、死信隔离，不想自己封装重试逻辑；
4. 业务 QPS 中等（几万以内），不产生长期海量消息堆积；
5. 金融、审批、工单等流程化业务，需要精细管控每一条消息的生命周期。

四、什么场景优先选 Kafka

满足以下任意一点，推荐 Kafka：

1. 超高吞吐海量数据流：用户行为埋点、系统日志采集、监控指标上报；
2. 实时大数据处理：对接 Flink/Spark 做实时统计、数据大屏、ETL 数据同步；
3. 消息需要长期保存、支持回溯历史数据，做离线数据分析；
4. 简单分发场景，不需要延迟、复杂重试，追求极致性能与扩容能力；
5. 数据同步场景：数据库 binlog 同步、MySQL 同步 ES 等数据流同步。

五、企业通用混合使用方案

多数中大型项目两者搭配使用，职责完全分开：

1. Kafka 负责：日志、埋点、实时大数据计算、海量数据流；
2. RabbitMQ 负责：订单、支付、短信通知、业务流程解耦、消息重试场景。

六、精简总结

RabbitMQ 是通用业务消息队列，路由灵活、原生支持延迟死信重试，适合订单支付等核心交易业务；Kafka 是高吞吐流式日志系统，擅长海量堆积与大数据实时计算，适合埋点、日志采集场景。选型核心判断：业务流程复杂、需要重试隔离选 RabbitMQ；海量数据流、实时流式计算选 Kafka。