消息队列对比与选型
问题
Kafka、RocketMQ、RabbitMQ 各有什么特点？项目中如何选择合适的消息队列？
答案
三大 MQ 核心对比
| 维度 | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|
| 开发语言 | Scala + Java | Java | Erlang |
| 协议 | 自定义协议 | 自定义协议 | AMQP |
| 吞吐量 | 百万级 TPS | 十万级 TPS | 万级 TPS |
| 延迟 | ms 级 | ms 级 | μs 级 |
| 消息堆积 | 非常强（磁盘顺序写） | 强（CommitLog） | 弱（堆积后性能骤降） |
| Topic 数量 | 多 Topic 性能下降 | 支持数千 Topic | 支持大量 Queue |
| 消息路由 | Topic + Partition | Topic + Tag | Exchange + Routing Key（灵活） |
| 消息回溯 | 支持（按 offset/时间戳） | 支持（按时间戳） | 不支持（消费即删除） |
| 事务消息 | 支持（Transactional） | 原生支持（半消息） | 不支持 |
| 延迟消息 | 不原生支持 | 支持（固定级别/任意时间） | 通过 TTL + DLX 或插件 |
| 消费模式 | Pull（拉） | Pull（默认长轮询） | Push + Pull |
| 社区生态 | 极活跃（Apache） | 活跃（Apache） | 活跃 |
| 运维难度 | 中等（依赖 ZK/KRaft） | 中等 | 低（管理界面友好） |
架构差异
适用场景分析
Kafka 最适合
- 日志采集：高吞吐、持久化、支持大数据生态（Flink、Spark）
- 事件流处理：用户行为、指标收集、CDC
- 大数据管道：数据从各系统汇聚到数据仓库
- 流计算：Kafka Streams 原生流处理
RocketMQ 最适合
- 业务消息：订单、支付、库存等核心业务
- 分布式事务：事务消息实现最终一致性
- 延迟/定时任务：延迟消息、定时消息
- 大量 Topic：电商等业务 Topic 多的场景
RabbitMQ 最适合
- 低延迟场景：对延迟敏感的业务通知
- 复杂路由：灵活的 Exchange 路由规则
- 中小规模系统：吞吐量需求不高、运维简单
- 异构系统集成：AMQP 标准协议，跨语言友好
选型决策流程
消息队列的通用使用场景
| 场景 | 说明 | 推荐 MQ |
|---|---|---|
| 异步解耦 | 上游不等待下游处理完 | 任意 |
| 流量削峰 | 秒杀等突发流量缓冲 | Kafka / RocketMQ |
| 日志收集 | 应用日志 → 大数据平台 | Kafka |
| 分布式事务 | 最终一致性 | RocketMQ |
| 延迟任务 | 订单超时取消等 | RocketMQ |
| 广播通知 | 配置变更通知所有实例 | 任意 |
实际选型建议
- 金融/电商核心业务：RocketMQ（事务消息、延迟消息、高可靠）
- 大数据/日志/流计算：Kafka（高吞吐、生态完善）
- 中小项目/快速开发：RabbitMQ（简单、灵活、社区资源丰富）
- 已有技术栈：优先选择团队熟悉的 MQ，降低学习和运维成本
常见面试问题
Q1: 你们项目中为什么选择 Kafka/RocketMQ/RabbitMQ？
答案（以 RocketMQ 为例）：
我们是电商项目，选择 RocketMQ 主要基于以下考虑：
- 事务消息：订单创建和库存扣减需要分布式事务的最终一致性
- 延迟消息：订单超时自动取消需要延迟队列
- 高可靠：支持同步刷盘和同步复制，保证消息不丢失
- Topic 数量：业务线多，Topic 上千，RocketMQ 性能不受影响
- Java 技术栈：团队主要使用 Java，RocketMQ 源码可读性好
Q2: Kafka 为什么吞吐量比 RabbitMQ 高？
答案：
关键技术差异：
- 存储模型：Kafka 顺序写磁盘 + Page Cache + 零拷贝，磁盘当内存用；RabbitMQ 消息存在内存+磁盘持久化
- 批量处理：Kafka Producer 攒批发送，Consumer 批量拉取；RabbitMQ 单条 Push
- 消息确认：Kafka 可以配置 acks=0/1 减少确认开销；RabbitMQ 的 AMQP 协议确认更重
- 网络模型：Kafka 6.0+ 多线程 IO；RabbitMQ 基于 Erlang 轻量级进程
- 分区并行：Kafka 天然支持 Partition 并行消费
Q3: 消息队列如何处理消息堆积？
答案：
消息堆积的原因通常是 消费速度 < 生产速度。
应急处理：
- 扩容 Consumer：增加消费者实例（需要同时增加分区数）
- 临时 Topic：创建新 Topic（更多分区），将堆积消息转发过去，用大量临时 Consumer 快速消费
- 降级非核心消费：暂时关闭非核心消费者，将资源让给核心业务
长期优化：
- 提升单个消费者处理速度（批量处理、异步化）
- 合理设置分区数（Partition ≥ Consumer 数）
- 监控消费延迟（Consumer Lag），设置告警
Q4: 消息队列在分布式系统中的作用是什么？
答案：
三大核心作用：
- 异步解耦：上下游服务通过 MQ 通信，互不依赖，独立部署和扩展
- 流量削峰：将突发流量缓冲到 MQ 中，下游按自己的能力匀速消费
- 数据分发：一条消息多个消费者组消费，实现数据的广播分发
次要作用：分布式事务（最终一致性）、延迟任务、日志收集、系统监控等。