我给你整理一份面试必背、条理清晰、直接能说出口 的版本，把 RabbitMQ / RocketMQ / Kafka 在可靠性、顺序性、应用场景三块讲透，不绕弯子。
一、可靠性（消息不丢、不重复、不积压）
1. RabbitMQ 如何保证可靠
核心思路：生产者确认 + 持久化 + 手动ACK + 死信队列
- 生产者：开启
publisher confirm确认机制，确保消息到交换机、到队列。 - 存储：队列、消息都设置 durable 持久化，重启不丢。
- 消费者：手动 ACK，处理完业务再确认，异常则重回队列或死信。
- 兜底：死信队列（DLX）处理失败消息，避免丢失。
适用：对事务一致性、可靠性要求高，但并发一般的场景。
2. RocketMQ 如何保证可靠
核心思路：同步刷盘 + 主从同步 + 重试队列 + 死信队列
- 生产者：同步发送，等待 Broker 确认。
- 存储：同步刷盘，消息落盘才算成功。
- 高可用：主从同步复制，主挂了从顶上。
- 消费：失败自动进入 %RETRY% 重试队列，多次失败进入死信。
- 事务消息：支持分布式事务最终一致性。
适用：金融、电商订单、支付等高可靠业务。
3. Kafka 如何保证可靠
核心思路：多副本 + ACK=-1 + ISR + 手动提交偏移量
- 生产者：
acks=all（等所有 ISR 副本确认）。 - 存储：多副本机制，副本同步到 ISR 才算安全。
- 消费：手动提交 offset，业务成功再提交，避免丢消息。
- 幂等性 + 事务：开启
enable.idempotence防重复，事务保证精准一次。
适用：高吞吐、日志、流计算、大数据场景，可靠性靠副本保证。
二、顺序性（消息严格按发送顺序消费）
1. RabbitMQ 顺序性
- 单队列 + 单消费者：天然全局有序。
- 问题：并发消费就乱序。
- 方案：
- 一个队列只开一个消费者（最简单）
- 或按业务 ID 哈希路由到固定队列
- 缺点：吞吐量极低。
适用：少量但必须严格有序的场景，如状态更新。
2. RocketMQ 顺序性
分为全局有序 和分区有序：
- 全局有序：Topic 只有 1 个队列 + 1 个消费者（性能差）。
- 分区有序（推荐）：
- 同一订单 ID 哈希到同一个 MessageQueue
- 一个队列只被一个消费者线程处理
- 实现：使用
MessageQueueSelector。
适用：订单流程、物流状态、交易流等需要局部有序的业务。
3. Kafka 顺序性
Kafka 只能保证 分区内有序，分区间无序。
- 同一 key → 哈希到同一个 partition
- 消费者：一个分区只用一个线程
- 配合
max.in.flight.requests.per.connection=1保证发送有序。
适用：大数据同步、用户行为日志、事件流。
三、核心对比（面试直接背）
| 可靠性机制 | 顺序性 | 吞吐量 | |
|---|---|---|---|
| RabbitMQ | confirm、持久化、手动ACK | 单队列单消费者有序 | 低～中 |
| RocketMQ | 同步刷盘、主从、重试队列 | 分区有序（常用） | 高 |
| Kafka | 多副本、acks=-1、ISR | 分区内有序 | 极高 |
四、应用场景（最常考）
1. RabbitMQ 适用场景
- 传统企业系统、微服务解耦
- 对延迟消息、死信、优先级队列有需求
- 并发不高，但可靠性要求高
- 电商：秒杀、异步通知、邮件推送
- 典型：Erlang 构建，管理友好，社区成熟
2. RocketMQ 适用场景
- 阿里电商生态：订单、支付、物流、交易链路
- 高并发、海量消息、需要分布式事务
- 金融、支付类要求强可靠、可追溯
- 需要严格顺序消息、海量堆积能力
3. Kafka 适用场景
- 大数据、日志收集、用户行为埋点
- 流计算（Flink/Spark 集成）
- 高吞吐、高堆积、异步同步数据
- 不追求极低延迟，追求高并发+高持久
- 监控链路、数仓同步、CDC 日志
五、面试高频总结句（你直接背）
- RabbitMQ：可靠灵活，支持高级特性，但吞吐量一般，适合传统微服务异步解耦。
- RocketMQ：高可靠、高并发、支持事务与顺序消息，适合电商金融核心链路。
- Kafka：极高吞吐、分区有序、多副本可靠，适合大数据日志与流处理场景。