第3章 消息队列基础原理与常见故障类型
故障治理的前提是深刻理解原理。本章从架构组件、核心概念出发，建立故障分类体系，并给出标准排查路径。面试中 80% 的故障题都能归入本章框架，掌握后可迁移应对绝大多数MQ场景题。
| 维度 | 核心概念 | 常见故障 |
|---|---|---|
| 生产端 | Producer、发送确认（ACK）、重试机制 | 发送超时、消息丢失、分区无可用Leader |
| Broker端 | Topic、Partition、副本（Leader/Follower）、日志段 | 磁盘写满、内存溢出、主从切换脑裂、分区副本不同步 |
| 消费端 | Consumer、消费组、位移（Offset）、Rebalance | 消息堆积、重复消费、位移提交失败、消费组卡住 |
| 注册中心 | Zookeeper / Nameserver、元数据管理、故障探测 | 注册中心不可用、元数据不一致、选主异常 |
面试问题：请画出消息队列的核心架构图，并说明各组件的作用。
考察基础原理是否扎实，是否具备架构视角，能否把组件关系讲清楚，以及是否了解不同产品的实现差异。
- 从整体架构图切入（生产者 → Broker → 消费者）
- 分述四大组件核心职责
- 说明关键机制：Topic/Partition、副本、消费模型
- 结合具体产品（Kafka / RocketMQ）举例
消息队列核心包括生产者、Broker、消费者和注册中心。生产者发送消息到指定Topic，Broker负责持久化存储和副本同步，消费者通过Pull模式拉取消费。Topic下分Partition实现水平扩展，每个Partition有主从副本保证高可用。以Kafka为例，依赖Zookeeper管理元数据和Leader选举。
如何保证消息不丢失？Partition数量如何设定？Pull模型与Push模型各自的优缺点？
不要只讲抽象概念，要结合具体产品说明。避免忽略注册中心选型差异（Zookeeper vs Nameserver），这是面试官关注的分水岭。
面试问题：消息队列常见的故障类型有哪些？请分类说明。
考察故障知识体系的完整度，能否按层次分类，是否了解每种故障的典型表现和根因，以及是否有实际治理经验。
- 按生产端、Broker端、消费端三层分类
- 每层列举 2–3 种典型故障并说明表现
- 简要描述根因和排查方向
- 总结故障治理的共性思路
故障分三类：生产端包括发送超时、消息丢失，通常由网络抖动或ACK配置不当引起；Broker端包括磁盘写满、主从切换脑裂、内存溢出，多与资源规划和副本策略相关；消费端包括消息堆积、重复消费、位移提交失败，常由消费耗时过长或异常未捕获导致。每类故障都有明确的排查路径。
Broker端脑裂如何产生？消费位移丢失怎么恢复？消息丢失如何通过参数层面预防？
不要只罗列故障名称，要结合具体场景说明根因。避免遗漏注册中心故障（如Zookeeper不可用导致元数据异常），这是高级岗位的必考点。
面试问题：消息队列出现消息堆积时，排查思路是什么？
考察故障排查方法论是否体系化，能否从现象快速收敛到根因，以及是否具备监控和应急处理的实战意识。
- 通过监控确认堆积的Topic和Partition
- 查看消费组状态，判断消费者是否在线
- 检查消费端日志，是否有异常报错或耗时突增
- 对比生产速度和消费速度，定位瓶颈环节
- 制定应急方案（扩容、降级、跳过）
排查堆积遵循四步法：一看监控确认堆积Topic和Partition；二查消费组确认消费者在线状态；三检消费日志是否有异常报错或处理耗时增加；四对比生产和消费速度，定位是生产洪峰还是消费端故障。找到根因后，针对性扩容或降级处理。
堆积消息如何快速回溯重放？消费端扩容有哪些策略？如何通过参数配置预防堆积？
不要跳过监控直接猜原因，面试官看重体系化排查思维。避免只说"扩容"不谈具体扩容方式（增加Partition vs 增加消费者线程），方案落地细节才是加分项。