面试知识

2.1.0 MQ(消息队列)知识图谱与复习路线

20-MQ消息队列 面试知识整理。

2.1.0 MQ(消息队列)知识图谱与复习路线

本页只登记学习顺序、边界、验收和恢复信息;机制、数据演绎与口述答案以 0108 分册为唯一正文。本次受限交付只创建本页,模块总入口 20-MQ消息队列.md 及其余分册均保持待创建。

1. 入口判定与旧题基线

1.1 原始核对摘要

核对项执行结果结论
test ! -e '面试知识整理/20-MQ消息队列.md'成功(退出码 0旧主文档不存在。
git log --all --oneline -- '面试知识整理/20-MQ消息队列.md'无输出所有可见历史中没有该路径的提交。
git ls-tree -r --name-only HEAD -- '面试知识整理/20-MQ消息队列.md'无输出当前 HEAD(当前提交)不含该路径。

因此,本次实测基线为:旧知识型 ### 小节 0、旧章节题组/六字段题 0/0、旧综合题 0、旧 Mermaid(图表语法)图 0、可迁移旧题总数 0。后续若恢复出旧主文档,必须重新执行上表三条命令;只要发现旧题,以下账本和迁移去向必须按实测改写,不能沿用 0

1.2 零迁移账本

来源稳定标识数量目标文件目标小节处理方式链接状态
不存在的旧主文档legacy-20-mq=missing0不适用不适用建立新体系;无正文、题目或图形可搬迁不适用

下列仅是交叉引用候选,不得计入旧 MQ(消息队列)题迁移数:21-分布式系统与微服务.md 的最终一致性背景、22-Spring生态与后端工程.md 的 Outbox(发件箱)本地事务边界、52-架构案例与项目方案库.md94-系统设计题训练.md 的项目量级和系统设计情境。MQ(消息队列)机制与口述答案以本模块分册为唯一权威正文。

2. 先建立的四个认识

2.1 为什么吞吐会提高:等待转为并行工作

flowchart LR
    A[请求进入] --> B[同步调用下游]
    B --> C[调用方等待]
    C --> D[响应时间受最慢下游约束]

    E[请求进入] --> F[写入MQ(消息队列)]
    F --> G[快速返回受理结果]
    F --> H[多个消费者并行处理]
    H --> I[整体吞吐随可并行工作增长]

图意:MQ(消息队列)不缩短一条库存通知、导出或告警处理本身的耗时;它把调用方等待改为缓冲后的并行处理,提升的是系统整体吞吐与前台响应稳定性。

2.2 为什么能削峰:用时间换容量

flowchart LR
    A[高峰生产速率]
    A --> B[有界MQ(消息队列)缓冲]
    B --> C[按安全速率消费]
    C --> D[下游数据库或外部接口]
    B --> E[达到容量上限]
    E --> F[限流、降级或拒绝]

图意:缓冲吸收的是短时速度差,积压不是被消灭。必须同时计算容量、恢复时间和下游承受能力;缓冲满后要主动背压,不能无限堆积。

2.3 为什么能解耦:事件替代点对点等待

flowchart LR
    A[订单或任务状态变更] --> B[业务事件]
    B --> C[MQ(消息队列)主题]
    C --> D[库存通知]
    C --> E[物流同步]
    C --> F[报表或告警]
    D --> G[独立失败与补偿]
    E --> H[独立限速与重试]
    F --> I[独立聚合与降级]

图意:生产方只承诺发布已定义的事件,不等待每个下游完成;消费者仍须维护自己的幂等、状态机、监控和补偿闭环,不能把解耦误解为不需要一致性设计。

2.4 三种收益的共同边界

收益直接获得的能力没有被替代的正确性责任对应分册
异步前台可先返回“已受理”权威状态仍由数据库事务或状态机决定0107
削峰以时间吸收短时流量差容量上限、背压、降级和恢复时间仍须设计0106
解耦下游可独立演进、失败隔离事件契约、幂等、补偿和可观测性仍须落实0507

3. 三产品知识树与版本边界

flowchart TB
    A[MQ(消息队列)] --> B[Kafka(分布式日志消息系统)]
    A --> C[RocketMQ(分布式消息队列)]
    A --> D[RabbitMQ(消息队列)]
    B --> B1[日志、分区、副本与消费组]
    B --> B2[位移、重平衡与消费者延迟]
    C --> C1[存储、顺序、延迟与事务消息]
    C --> C2[名称服务与消费模型]
    D --> D1[交换机、路由、队列与确认]
    D --> D2[仲裁队列、流控与死信]
    A --> E[跨产品可靠性]
    A --> F[容量与线上排障]

图意:产品篇只讲各自不可互换的实现与版本边界;幂等、顺序、重试、死信、补偿与容量结论集中在后续通用分册,避免三份相互矛盾的“可靠性正文”。

产品与学习基线旧版本/存量边界主学习边界本入口已核对的官方依据
Kafka(分布式日志消息系统)3.9 与 4.x3.9 是最后保留 ZooKeeper(分布式协调服务)模式的 3.x 主线,可作为迁移桥接;3.9.1+ 的迁移步骤必须按该版本手册执行。4.x 新部署只按 KRaft(Kafka Raft 元数据模式)建模;不得把 ZooKeeper(分布式协调服务)配置或管理命令写成 4.x 新部署方案。2026-07-14:Kafka(分布式日志消息系统)3.9 KRaft(Kafka Raft 元数据模式)迁移手册与 4.0 发布说明。
RocketMQ(分布式消息队列)4.9.x 与 5.x4.x 延迟消息采用 18 个固定延迟级别,存量客户端与该模型隔离说明。5.x 按消息类型与主题类型建模;延迟、FIFO(先进先出)和事务消息的主题约束、任意时间延迟与 POP(长轮询消费)都必须精确到实际小版本。2026-07-14:4.x 延迟消息手册、5.x 主题与延迟消息手册。
RabbitMQ(消息队列)3.13 与 4.x3.13 说明存量 AMQP(高级消息队列协议)应用的交换机、确认、预取和死信语义;镜像经典队列属于迁移历史。4.x 以仲裁队列与 Stream(流)说明复制;经典镜像队列已移除。仲裁队列默认投递上限为 20,死信与优先级行为需按实际小版本复核。2026-07-14:4.0 更新、仲裁队列与 3.13 镜像迁移手册。

版本事实的使用规则:后续每篇在文末登记“核对日期、产品小版本、官方章节、命令或配置验证”。本页只锁定教材分层,不把任一小版本行为泛化为所有版本。

4. 分册职责、迁移去向与最低交付量

编号目标文件唯一职责依赖旧题迁移去向图 / 表 / 数据演绎 / 综合长答案下限
2.1.101-MQ价值排队论与分治.md异步、缓冲、排队、背压、分治与选型边界本页无旧题;新建正文9 / 8 / 7 / 18
2.1.202-Kafka架构日志副本与消费组.mdKafka(分布式日志消息系统)的日志、复制、消费组与位移01无旧题;新建正文11 / 10 / 8 / 22
2.1.303-RocketMQ架构存储事务顺序与延迟.mdRocketMQ(分布式消息队列)的存储、事务、顺序与延迟01无旧题;新建正文11 / 10 / 8 / 22
2.1.404-RabbitMQ交换机队列与确认.mdRabbitMQ(消息队列)的路由、队列与确认01无旧题;新建正文9 / 9 / 7 / 18
2.1.505-可靠性语义幂等顺序重试死信与事务消息.md跨产品可靠性、幂等、顺序、重试、死信与事务消息020304无旧题;新建唯一通用正文12 / 11 / 10 / 25
2.1.606-容量性能堆积与线上排障.md容量、性能、堆积、扩缩容与事故证据链0102030405无旧题;新建正文10 / 10 / 8 / 25
2.1.707-项目案例异步导出库存支付与IoT.md异步导出、库存、支付、物流、Runner(执行器)与 IoT(物联网)案例010506无旧题;新建项目口述正文10 / 10 / 8 / 25
2.1.808-综合面试题库.md跨章节口述题库与追问树0107无旧题;新建题库10 / 10 / 8 / 35

说明:上表中文件名是待创建目标,不在本页建立相对链接,以避免在分册尚未创建时形成坏链接。每一篇完成后才可把该行替换为真实相对链接。

5. 学习依赖、可靠性与排障路线

5.1 阅读与实施依赖

flowchart LR
    A[01 价值、排队与分治]
    A --> B[02 Kafka(分布式日志消息系统)]
    A --> C[03 RocketMQ(分布式消息队列)]
    A --> D[04 RabbitMQ(消息队列)]
    B --> E[05 通用可靠性]
    C --> E
    D --> E
    A --> F[06 容量与排障]
    E --> F
    E --> G[07 项目案例]
    F --> G
    G --> H[08 综合题库]

图意:020304 可在 01 完成后并行,但 05 必须等待三种产品确认语义齐备;08 只压缩已验收内容,不反向发明产品事实。

5.2 端到端可靠性路径

flowchart LR
    A[业务状态变更] --> B[本地事务或发件箱记录]
    B --> C[生产确认]
    C --> D[Broker(代理节点)持久化或复制]
    D --> E[消费者处理]
    E --> F[业务幂等与状态机]
    F --> G[消费确认]
    C --> H[发送超时或不确定]
    E --> I[处理后确认丢失]
    H --> J[查询、重试或补偿]
    I --> K[重复投递]
    K --> F
    J --> L[对账与人工介入]

图意:生产确认、Broker(代理节点)落盘或复制、消费确认都不是业务副作用完成的同义词;可靠性必须由幂等、状态机、观测、补偿与对账共同闭合。完整结论只在 05 展开。

5.3 堆积与故障排障路线

flowchart TD
    A[发现延迟、堆积或失败] --> B[确认影响范围与业务优先级]
    B --> C[先止血:限流、隔离、降级]
    C --> D[采集生产、Broker(代理节点)、消费与下游证据]
    D --> E{生产速率是否大于有效消费速率}
    E -->|是| F[检查热点、并发、外部依赖、重试放大与顺序约束]
    E -->|否| G[检查消费掉线、确认、路由、磁盘与副本或队列状态]
    F --> H[安全扩容或恢复下游]
    G --> H
    H --> I[验证积压下降、错误率与业务收敛]
    I --> J[复盘容量、告警、幂等与补偿缺口]

图意:排障先确认影响与止血,再建立证据链;“加消费者”只在分区/队列、顺序和下游容量均允许时才是候选动作。各产品指标、命令和事故话术由 06 统一维护。

6. 图形资产、术语与交叉边界

6.1 必画图清单

所属分册必画图目的资产边界
00吞吐并行、削峰、解耦、产品树、依赖、可靠性、排障路线建立学习框架与边界本页内嵌 Mermaid(图表语法)图;不替代后续细节图。
01同步与异步、积压变化、背压、分治路由、容量恢复推导为什么使用 MQ(消息队列)只画通用模型。
02Kafka(分布式日志消息系统)副本与消费、故障恢复固化日志、复制和位移边界另有 PlantUML(开源建模工具)正式资产。
03RocketMQ(分布式消息队列)事务消息与延迟可见性固化半消息、回查与顺序边界另有 PlantUML(开源建模工具)正式资产。
04RabbitMQ(消息队列)路由、发布确认与消费确认区分路由成功、持久化确认和业务成功另有 PlantUML(开源建模工具)正式资产。
05重复投递、重试、死信、顺序破坏与补偿建立跨产品可靠性结论只在本篇给通用答案。
06容量模型、堆积增长、故障决策树指导事故响应与恢复验证必须包含证据到行动链。
07六个项目的事件与补偿闭环支撑可复述项目话术绑定 WMS(仓储管理系统)、支付、物流、Runner(执行器)和 IoT(物联网)。
08五条追问树压缩复习与临场追问只链接已验收正文。

6.2 术语增量清单

本页所用高频术语已在现有术语规范中登记的包括 MQ(消息队列)、Kafka(分布式日志消息系统)、RocketMQ(分布式消息队列)、RabbitMQ(消息队列)、Broker(代理节点)、Outbox(发件箱)、WMS(仓储管理系统)、Runner(执行器)、IoT(物联网)、Mermaid(图表语法)和 PlantUML(开源建模工具)。本受限任务不修改术语表。

后续若在正式分册首次引入且术语表尚无条目的 KRaft(Kafka Raft 元数据模式)、POP(长轮询消费)、仲裁队列对应英文名或其他稳定术语,必须在模块收口阶段统一追加到术语表;在此之前,正文每次出现仍须按 English(中文意思) 标注。

6.3 交叉引用的单向边界

外部模块可复用内容禁止复用为本模块正文
21-分布式系统与微服务.md最终一致性背景具体投递、确认、重试、死信与产品实现。
22-Spring生态与后端工程.mdOutbox(发件箱)的本地事务边界消息可靠性、消费者幂等与排障答案。
52-架构案例与项目方案库.md项目规模、约束与架构情境MQ(消息队列)项目案例的完整方案。
94-系统设计题训练.md容量题的业务输入消息容量公式、事故证据与恢复路径。

7. 完成判定与恢复说明

7.1 2.1.0 完成判定

  • 当前文件只承担入口职责,不设置知识型章节标记与章节题,也不复制后续机制正文。
  • 零迁移账本总数保持 0,且原始核对摘要可复跑、可证伪。
  • 0108 均有唯一职责、依赖、目标去向与最低交付量;待创建文件不以失效链接伪装为已完成导航。
  • 三种产品的版本矩阵明确区分存量/迁移基线与主学习基线,且写明重新核对的要求。
  • 本页至少包含“提速、削峰、解耦、三产品树、可靠性、排障、依赖”七张 Mermaid(图表语法)图;每张图都有一句边界说明。
  • 定向知识库审计为 0、全部 Mermaid(图表语法)图可真实渲染、相对链接检查通过,且 git diff --check 无输出。
  • 2.1.0 完成不代表 MQ(消息队列)模块完成;在 0108、总入口与两级看板收口前,模块状态仍是“未开始/进行中”。本任务不修改两级进度看板。

7.2 恢复步骤

  1. 先检查工作树,保留其他协作者的修改;只编辑当前调度项声明的文件与专属资产。
  2. 重读本页、08-精通级扩展执行看板.md、模块计划的 2.1.0 至下一待办项;以最小编号的未完成项决定下一步。
  3. 若补写 01,先用本页的吞吐、积压和背压边界,不在其中写产品专属确认语义;待 01 通过后,020304 才可并行。
  4. 每次创建分册后,先运行定向审计、相对链接检查、全部 Mermaid(图表语法)图真实渲染和 git diff --check;不要回退或覆盖同期修改。
  5. 只有 0108 全部验收后,才由模块收口任务创建/更新总入口、术语表和两级看板,并将待创建文件名替换为真实相对链接。

7.3 本页验收命令

python3 tools/interview_kb_audit.py --module '20-MQ消息队列' --root '面试知识整理'
git diff --check -- '面试知识整理/20-MQ消息队列/00-知识图谱与复习路线.md'

Mermaid(图表语法)真实渲染时,将每个围栏提取到临时目录,再使用固定版本的渲染器生成非空结果;临时产物不得写入工作区。