RabbitMQ
1. RabbitMQ、Kafka、RocketMQ 对比#
查看答案
可直接说： RabbitMQ、Kafka、RocketMQ 都能做异步解耦、削峰填谷和事件传递，侧重点不同。RabbitMQ 基于 AMQP，Exchange 路由模型成熟，Direct、Topic、Fanout 等交换机适合复杂业务路由和任务队列；Kafka 是分布式事件流平台，分区、顺序追加写和消费位点让它适合日志、埋点、实时计算和数据管道；RocketMQ 面向业务消息能力更完整，顺序消息、事务消息、延时消息和消息轨迹适合订单、支付、交易链路。
| 消息队列 | 核心优势 | 适合场景 |
|---|---|---|
| RabbitMQ | AMQP 成熟，Exchange 路由灵活，确认、死信、延迟等业务能力常用 | 业务系统解耦、任务队列、后台异步、复杂路由、失败重试 |
| Kafka | 分区并行、顺序追加、高吞吐、位点管理清晰、生态偏流式处理 | 日志采集、埋点上报、实时计算、数据湖同步、事件流平台 |
| RocketMQ | 事务消息、顺序消息、延时消息、消息轨迹等业务特性集中 | 电商订单、金融支付、交易链路、分布式事务最终一致性 |
要答的点：
- RabbitMQ：强调路由灵活、可靠投递和传统业务消息。
- Kafka：强调高吞吐、可回放、分区并行和事件流生态。
- RocketMQ：强调业务消息特性，尤其事务、顺序、延迟。
- 顺序性：RabbitMQ 队列内顺序；Kafka 分区内顺序；RocketMQ 可按 MessageQueue 保序。
- 可靠性：都需要生产确认、持久化/副本、消费确认或位点提交。
- 选型：复杂路由选 RabbitMQ，大规模日志流选 Kafka，交易消息链路选 RocketMQ。
重点讲解摘录：
- RabbitMQ 文档把 Exchange 描述为接收生产者消息并路由到队列的组件。
- Kafka 官方把 Kafka 定位为 “distributed event streaming platform”。
- Kafka 文档说明 Topic 可分为 partitions，并支持消费者通过 offset 控制消费位置。
- RocketMQ 文档把事务消息、顺序消息、延迟消息列为常见消息类型能力。
- 面试对比要落到业务场景，避免只背吞吐量和名词。
原文链接：
2. 消息队列的作用和使用场景#
查看答案
可直接说： 消息队列主要解决异步解耦、削峰填谷、可靠通信和事件驱动。比如下单后发短信、发券、积分、物流通知都可以异步处理，让主链路更短；秒杀高峰可以把请求写入队列，消费者按能力平稳处理；跨系统通信可以用消息承载事件，减少服务之间强依赖。面试里要补一句：引入 MQ 也会带来重复消费、消息丢失、延迟、积压和一致性问题，需要配套治理。
要答的点：
- 异步：把非核心链路从同步请求里拆出去，降低接口延迟。
- 解耦：生产方只发事件，消费方独立扩展和演进。
- 削峰：高峰写入队列，下游按消费能力处理。
- 可靠通信：持久化、确认、重试、死信让消息可追踪。
- 事件驱动：订单创建、支付成功、库存变更等事件驱动多个订阅者。
- 代价：一致性、幂等、延迟、积压、运维复杂度都要回答到。
重点讲解摘录：
- RabbitMQ 教程用 Producer、Queue、Consumer 说明消息队列把生产和消费解耦。
- Kafka 官方介绍事件流平台可以发布、订阅、存储和处理事件流。
- RabbitMQ confirms 和 acknowledgements 文档说明可靠投递需要生产者确认和消费者确认。
- 死信队列用于处理被拒绝、过期或超过长度限制的消息。
- 面试场景例子可以围绕订单、通知、日志、异步任务和流量削峰展开。
原文链接：
3. 如何保证消息队列可靠性#
查看答案
可直接说： 消息可靠性要按链路拆成生产端、Broker、消费端三段。生产端开启发送确认，失败重试，关键业务用本地消息表或 Outbox 保证业务数据和消息发送最终一致；Broker 端开启队列、消息持久化和副本/镜像，保证消息落盘和节点故障可恢复；消费端使用手动 ACK，业务处理成功后再确认，失败进入重试或死信队列。重复消费通过幂等机制兜底，因为可靠投递通常意味着至少一次投递。
要答的点：
- 生产端：publisher confirm、重试、超时结果未知处理、本地消息表。
- Broker：durable queue、persistent message、镜像/仲裁队列、副本、落盘。
- 消费端：manual ack、失败重试、死信队列、消费超时和限流。
- 一致性：业务落库和发消息用 Outbox 或事务消息思想。
- 可观测：消息 ID、状态表、堆积监控、消费失败告警。
- 幂等：至少一次语义下，消费端必须能处理重复消息。
重点讲解摘录：
- RabbitMQ publisher confirms 文档说明 Broker 可以异步确认发布的消息。
- RabbitMQ consumer acknowledgements 文档说明消费者确认用于告诉 Broker 消息已经处理。
- RabbitMQ 持久化需要队列 durable 且消息 delivery mode 为 persistent。
- Kafka producer 的
acks=all和副本机制用于提高写入可靠性。 - RocketMQ 事务消息用于解决本地事务和消息发送的一致性问题。
原文链接：
4. 如何防止消息重复消费（幂等）#
查看答案
可直接说： 重复消费用消费端幂等解决。消息系统为了可靠性通常采用至少一次投递，网络超时、ACK 丢失、消费者重启、重平衡、失败重试都会导致同一消息被再次投递。业务上给每条消息带全局唯一 message_id 或业务唯一键，消费前写去重表或依赖唯一索引，写入成功再执行业务；插入冲突说明处理过，直接返回成功。状态机、乐观锁、Redis SETNX 和业务唯一约束也都可以做幂等。
要答的点：
- 重复来源：重试、ACK 丢失、消费者宕机、Broker 重新投递、消费组重平衡。
- 幂等定义：同一消息执行多次，业务最终结果一致。
- 唯一键：
message_id、订单号、支付流水号、业务事件 ID。 - 去重表：唯一索引拦截重复消息，成功后执行业务。
- 状态机：只允许合法状态流转，例如待支付 -> 已支付。
- 短期去重：Redis
SET key value NX EX适合时间窗口内去重。
重点讲解摘录：
- RabbitMQ 文档说明消费者取消或通道关闭时，未确认消息会重新入队。
- Kafka 消费位点提交和重平衡都可能让消费者重新处理已拉取消息。
- RocketMQ 文档也把消费幂等作为消费者需要处理的问题。
- 唯一索引是业务幂等最常用的强约束。
- 面试里要把“消息系统可靠投递”和“业务幂等”放在一起讲。
原文链接：
5. 消息积压会发生什么，如何解决#
查看答案
可直接说： 消息积压会让端到端延迟上升，业务状态滞后，队列磁盘和内存压力变大，重试消息和死信消息增多，严重时会拖垮 Broker 或下游服务。处理时先判断是生产突增、消费变慢、消费者故障还是下游依赖慢；短期可以扩容消费者、提高并发、暂停非核心生产、限流降级；长期要优化消费逻辑、拆分慢任务、增加分区或队列、做批量消费和背压治理。
要答的点：
- 现象：堆积量上升、消费延迟上升、Broker 资源升高、业务数据滞后。
- 定位：看生产速率、消费速率、消费者错误、下游耗时和重试量。
- 短期止血：扩容消费者、提高 prefetch/并发、限流生产、临时跳过低优先级消息。
- 长期优化：拆分 Topic/Queue、优化慢 SQL/RPC、批量处理、异步化、分区扩展。
- 风险控制：死信队列、重试上限、告警、积压恢复预案。
- 顺序消息：顺序消费场景扩容受限，要优先处理慢消息和异常分区。
重点讲解摘录：
- RabbitMQ 文档说明 prefetch 可以限制未确认消息数量，从而影响消费端吞吐和背压。
- Kafka consumer lag 是衡量积压的核心指标，表示生产进度和消费进度差距。
- RabbitMQ 队列过长会增加内存、磁盘和管理成本。
- Kafka 分区数量决定同一消费组内最大并行消费粒度。
- 面试要把“临时恢复”和“根因治理”分开说。
原文链接：
6. 消息队列算哪种设计模式#
查看答案
可直接说： 消息队列常体现两类模式：生产者-消费者模式和发布-订阅模式。生产者-消费者强调任务缓冲和异步处理，多个消费者从队列取任务并发执行；发布-订阅强调事件广播，一个事件可以被多个订阅方独立消费。RabbitMQ 里 Queue 更像任务缓冲，Exchange + Binding 可以实现发布订阅和路由；Kafka 里 Topic + Consumer Group 同时支持同组负载均衡和多组广播消费。
要答的点：
- 生产者-消费者：生产任务、队列缓冲、消费者并发处理。
- 发布-订阅：发布事件，多个订阅者各自接收。
- RabbitMQ：Exchange 决定路由，Queue 存储消息，Consumer 消费队列。
- Kafka：同一 consumer group 内分摊分区，不同 group 各自消费一份事件流。
- 架构价值：解耦、异步、削峰、事件驱动。
- 追问：观察者模式、事件总线、CQRS 也常和 MQ 一起出现。
重点讲解摘录：
- RabbitMQ 发布订阅教程使用 fanout exchange 把消息广播到多个队列。
- RabbitMQ work queues 教程展示多个 worker 共同消费任务队列。
- Kafka 文档说明 consumer group 可以让消费者分摊 topic 的 partitions。
- 不同 consumer group 订阅同一 topic 时，可形成发布订阅效果。
- 面试里把“同组竞争消费、不同组广播消费”说清楚会加分。
原文链接：
7. RabbitMQ 底层架构是什么样的#
查看答案
可直接说： RabbitMQ 的核心链路是 Producer 把消息发到 Exchange，Exchange 根据 type、routing key 和 binding 规则把消息路由到一个或多个 Queue，Consumer 从 Queue 消费消息并发送 ACK。连接层面，客户端和 Broker 建立 TCP connection，connection 内可以开多个 channel 复用；可靠性层面，生产者可以用 publisher confirm，消费者可以用 manual ack，队列和消息可以持久化，异常消息可以进入 dead-letter exchange。
要答的点：
- Producer：发送消息到 Exchange。
- Exchange：根据交换机类型和绑定规则路由消息。
- Queue：存储消息，等待 Consumer 消费。
- Binding：连接 Exchange 和 Queue，可带 routing key 或 headers 条件。
- Channel：建立在 TCP Connection 上的轻量逻辑通道。
- ACK：生产确认和消费确认共同保障可靠投递。
重点讲解摘录：
- RabbitMQ AMQP concepts 文档说明 producer 发布到 exchange，consumer 从 queue 接收。
- Exchange 不直接存储业务消息，它负责按规则路由到队列。
- Channel 是 AMQP 连接中的虚拟连接，用于复用 TCP connection。
- Queue 可声明 durable，消息可声明 persistent，以提高重启后的保留能力。
- Dead Letter Exchange 用于承接被拒绝、过期或超限的消息。
原文链接：
8. RabbitMQ 的交换机类型#
查看答案
可直接说： RabbitMQ 常见交换机有 Direct、Topic、Fanout、Headers。Direct 按 routing key 精确匹配绑定键，适合点对点路由；Topic 按通配符匹配 routing key，* 匹配一个单词，# 匹配零个或多个单词，适合日志分类和多维路由；Fanout 忽略 routing key，把消息广播到所有绑定队列，适合通知和广播；Headers 根据消息头匹配，使用频率相对低。
要答的点：
- Direct：精确匹配 routing key。
- Topic：通配符匹配，
*一个词，#多个词。 - Fanout：广播到所有绑定队列。
- Headers：根据消息 headers 和 x-match 规则匹配。
- 默认交换机：空字符串 direct exchange，routing key 等于队列名可直达队列。
- 选型：单路由 Direct，多维路由 Topic，广播 Fanout，复杂头匹配 Headers。
重点讲解摘录：
- RabbitMQ exchanges 文档列出 direct、topic、fanout、headers 这些内置类型。
- Direct exchange 根据 routing key 做精确路由。
- Topic exchange 支持以点分隔的词和通配符完成模式匹配。
- Fanout exchange 会把消息复制到所有绑定队列。
- Headers exchange 根据消息属性中的 headers 匹配，routing key 在该类型下不参与路由。
原文链接：