QPS 过万与亿级消息系统设计学习总纲：零基础到资深架构师的完整教学大纲
亿级规模系统系列 · 总纲第 0 篇
本文的目标只有一个：让一个没设计过高并发系统的学生，沿这条线走完，成为能独立设计 QPS 过万、消息规模过亿的系统，并讲清每一步取舍的资深架构师。本篇是「路线」——先看清整张地图，再决定每一步往哪走；具体知识点的「教材」按本大纲逐篇展开。
开头：为什么学「高并发」之前，要先写一份大纲？
因为这个领域是所有后端技术的压力测试场，知识点不是一张网，而是一张互相压着的网：
- 你想学「秒杀怎么抗住百万 QPS」→ 资料说「前提是懂缓存、限流、削峰」→ 削峰又牵出 MQ 的堆积治理 → 堆积治理又牵出分区与消费扩容……
- 你想学「亿级消息怎么存」→ 资料说「CommitLog 顺序写 + 零拷贝」→ 又牵出操作系统页缓存、mmap、磁盘 IO 模型……
- 你想直接背「高并发架构图」应付面试 → 画完发现每个组件都答不上「为什么是它」——不知道为什么用缓存就答不出什么时候不用缓存，不知道为什么分库就答不出分片的代价。
没有路线图的学习是这样的：今天看一篇「Redis 缓存三大问题」，明天看一篇「Kafka 为什么快」，后天看一篇「雪花算法」——每篇都懂了，合起来还是设计不出一个系统。因为高并发的知识价值不在单点，而在「什么量级、什么位置、用什么组件、付出什么代价」的组装判断力。
这份大纲要做的事就一件：沿着「流量增长」这条真实的时间线，把整个领域压平成一条单向的线——流量每涨十倍，架构长出一件新器官；你每次只学一件新器官，学完一个，就解锁下一个量级。这是西蒙学习法在系统设计领域的落地方式。
前置要求（都是软前置，用到时回看即可）：
- Linux 基础 6 篇 与 Docker 学习总纲——全程实验场是 WSL2 + Docker；
- Java 与 Spring Boot 基础——示例代码栈为 Spring Boot 3.x / JDK 17；
- 并发编程系列——阶段 1 讲线程模型时是硬前置；
- 数据库 SQL 基础——阶段 2、4 大量使用 MySQL。
一、这个领域在解决什么问题：一张演进底图
先回答「这套技术为什么存在」。一句话本质：流量每涨十倍，原来的架构就会在某个位置断裂，高并发架构设计就是不断找到断裂点、用合适的组件补上、并说清代价的过程。
把它画成一张演进表，这也是整个大纲的骨架：
| 量级 | 断裂点 | 长出的器官 | 对应阶段 |
|---|---|---|---|
| ~1 千 QPS | 单机 CPU / 连接数到顶 | 垂直扩容 → 横向扩展 + 负载均衡 | 阶段 0~1 |
| ~1 万 QPS | 数据库读扛不住 | 读写分离 + 缓存体系 | 阶段 2 |
| 峰值洪峰（秒杀） | 同步链路被瞬时流量打穿 | 异步削峰 + 消息队列 | 阶段 3 |
| ~10 万 QPS | 单库写到了极限 | 分库分表 + 全局 ID | 阶段 4 |
| 任何时候 | 依赖一挂全链路雪崩 | 限流 / 熔断 / 降级 / 隔离 | 阶段 5 |
| 任何时候 | 机器总会坏、机房总会断 | 冗余 + 故障转移 + 多活 | 阶段 6 |
| 亿级消息 | 存储、堆积、投递规模爆炸 | 顺序写存储模型 + 推拉投递 | 阶段 3、7 |
| 上线前 | 「设计扛 10 万」是猜的 | 全链路压测 + 容量治理 | 阶段 8 |
注意两个贯穿全程的事实：
- 量级感比组件名重要。这个领域的第一个门槛不是「会用 Redis」，而是知道「单机 Spring Boot 接口大概几千 QPS、Redis 单实例大概十万 QPS、MySQL 单库写大概几千 TPS」这些数量级直觉——没有它，一切设计都是玄学，一切面试回答都是背诵。这就是为什么本大纲把「度量与估算」放在阶段 0，先立标尺再谈架构。
- 每个器官都有代价。缓存引入一致性难题，MQ 引入堆积与重复，分库分表杀死跨库 join 与事务，多活引入数据同步——不存在免费的扩展。资深与入门的分水岭，就是能否在引入每个组件时同时说出它的代价清单。
与已有系列的关系（本板块的独特定位）
本博客已有多个单点深挖系列，它们是器官专科，本板块是总装车间——学的是把器官组装成系统的判断力，不重复展开器官内部：
| 已有系列 | 在本大纲中的角色 |
|---|---|
| Redis 学习总纲 | 阶段 2 缓存深挖旁支（数据结构、持久化、Cluster 细节去那里学） |
| RocketMQ 学习总纲 | 阶段 3 消息深挖旁支（架构、源码、事务消息细节去那里学） |
| 分布式事务学习总纲 | 阶段 4 跨库事务深挖旁支 |
| 微服务 Sentinel 系列 | 阶段 5 流量防护深挖旁支 |
| K8s 学习总纲 | 部署与弹性伸缩的环境底座 |
| 性能调优系列 | 阶段 1 单机榨干时的 JVM / Tomcat 深挖 |
版本现状（2026-08-24 核验）
- RocketMQ 5.3.4 为当前稳定线（5.5.0 已引入 LiteTopic 等新特性）——消息主线基准，本博客 RocketMQ 总纲同基准；
- Kafka 4.3.1（2026-06 发布）——注意 4.0 起 ZooKeeper 被完全移除，KRaft 是唯一模式，旧教程里的 ZK 部署法已失效；
- Redis 8.x（当前 8.10.x）——许可证已切换 AGPLv3；本博客 Redis 总纲同基准；
- ShardingSphere 5.5.3（2026-03 发布）——分库分表实战基准；
- MySQL 8.0 / 8.4 LTS；Spring Boot 3.x + Spring Cloud Alibaba 2023.x（Sentinel 接入口径）；
- 涉及版本敏感结论时，正文会标注出处与时间。
二、学成什么样，才算「资深架构师」？
先立靶子。「资深」不是「背得出所有组件的参数」，它有五档验收，逐级递进：
| # | 档位 | 具体表现 |
|---|---|---|
| 1 | 算得出 | 给定业务目标（DAU、消息量），30 分钟内推出峰值 QPS、存储量、带宽、机器数——先算账，再画图 |
| 2 | 画得出 | 白板画出完整架构图，每个组件都能回答「为什么是它、换成别的会怎样、它的代价是什么」 |
| 3 | 扛得住 | 限流、熔断、降级、隔离四板斧会配会用会验证；洪峰来时系统有损服务而不是全军覆没 |
| 4 | 修得了 | 缓存击穿、消息堆积、热点 key、慢 SQL、级联雪崩——能从监控定位到根因，能写出应急预案 |
| 5 | 讲得清 | 每个选型都能用「量级—瓶颈—方案—代价」四段式讲给同事听，包括否决了哪些方案、为什么 |
注意「资深」的定义里没有：背中间件全部配置项（有官方文档）、读所有中间件源码（已有系列负责深挖）、追求极致单机性能（性能调优系列负责）。量级直觉 + 组装判断力 + 代价意识才是本领域的分水岭——这三样都要靠动手实验和亲手计算喂出来。
三、西蒙学习法在本领域的四个落法
西蒙学习法的核心：把领域拆碎成小单元，连续地、单点聚焦地逐个吃掉，每个单元立刻获得反馈。对应到本大纲：
- 拆碎：每个知识单元控制在 0.5 ~ 2 天内可完成。绝不出现「学缓存」这种大块头，只有「压一个刚过期的热 key，复现击穿，再加互斥锁对比」这种小块。
- 单点聚焦：一次只学一个单元。学缓存一致性时不要顺手去翻 canal 源码——忍住，本大纲只用到「订阅 binlog 刷缓存」这个能力面，深挖是旁支的事。
- 及时反馈：每个单元都配动手实验和吃透的标准，且本领域的实验几乎都能在一台笔记本 + WSL2 + Docker上完成：单机压测出真数据、Docker 编排小集群、亲手制造故障再亲手恢复。实验跑不通 = 没学会，不进下一单元。
- 连续推进：每天 1.5 ~ 2 小时，每周 5 ~ 6 天，连续推进约 25 周。可以慢，顺序不要乱：每个阶段的验收没过，不进下一阶段——尤其阶段 0 的「算得出」和阶段 3 的「消息三笔账」，是后面一切的地基。
学习环境清单（开工前一次备齐）
| 工具 | 版本建议 | 用途 |
|---|---|---|
| WSL2（Ubuntu）或 Linux 虚机 | 内存 8G+ | 全程主实验场（与本博客其他系列同一环境） |
| Docker / Docker Compose | 最新稳定版 | 编排 MySQL 主从、Redis、MQ、Nginx 等小集群 |
| JDK + Spring Boot | 17 / 3.x | 示例代码栈 |
| MySQL | 8.0（或 8.4 LTS） | 阶段 2、4、7、8 主体 |
| Redis | 8.x | 阶段 2 缓存体系 |
| RocketMQ | 5.3.x | 阶段 3 消息主线（与 RocketMQ 总纲同基准） |
| Kafka | 4.3.x（KRaft 模式） | 阶段 3 MQ 选型对比 |
| ShardingSphere-JDBC | 5.5.3 | 阶段 4 分库分表实战 |
| Sentinel + Nacos | SCA 2023.x 配套 | 阶段 5 流量防护 |
| 压测工具 | wrk（必学）+ JMeter（辅） | 阶段 0 起全程使用，每个单元的「尺子」 |
| 基础工具 | curl / jq / tcpdump / mysql客户端 | 验证与排障 |
提示：wrk 在 WSL 内
apt install wrk即可；本博客 Linux 基础篇有 tcpdump 教程，抓包验证长轮询时回看。
一条贯穿全程的实验载体
零散实验容易「学完就忘」。本大纲全程围绕一个可生长的示例系统推进：一个「电商 + 站内信」小系统，阶段 1 从单体起步，每个阶段给它长一件新器官，阶段 7 解剖四大场景，阶段 9 毕业设计完成总装。做完 25 周，你手里会有一个亲手演化出来的、被压测验证过的完整系统。
四、知识全景图
先看地图全貌（自底向上，每层只依赖下层；右侧是「亿级消息」主线与 QPS 主线的交汇）：
┌────────────────────────────────────────────────────┐
阶段 9 毕业 │ 方法论 · 毕业设计（交易+消息平台）· 自检 30 问 │
（第 25 周） ├────────────────────────────────────────────────────┤
阶段 8 验证 │ 全链路压测 · 影子体系 · 可观测 · 容量与成本 │
（第 23~24 周） ├────────────────────────────────────────────────────┤
阶段 7 场景 │ IM · Feed 流 · 千万长连接推送 · 秒杀（总装）★ │
（第 20~22 周） ├────────────────────────────────────────────────────┤
阶段 6 高可用 │ 9 的代价 · 冗余与转移 · 中间件 HA · 双活多活 · 演练 │
（第 17~19 周） ├────────────────────────────────────────────────────┤
阶段 5 防护 │ 雪崩机理 · 限流四算法 · 集群限流 · 熔断降级 │
（第 15~17 周前半） │ 隔离舱 · Sentinel 实战 │
├────────────────────────────────────────────────────┤
阶段 4 分片 │ 拆前穷尽五件事 · 垂直拆 · 分片键与基因法 │
（第 11~14 周） │ 全局 ID · 跨分片难题 · ShardingSphere 与扩容 │
├────────────────────────────────────────────────────┤
阶段 3 异步 ★交汇 │ 同步天花板 · 削峰填谷 · 亿级存储模型 │
（第 8~11 周前半） │ 顺序/重复/事务 · 堆积治理 · 推拉投递 · MQ 选型 │
├────────────────────────────────────────────────────┤
阶段 2 缓存 │ DB 为什么先死 · 读写分离 · 缓存模式与三兄弟 │
（第 5~7 周） │ 一致性 · 热点 key 与多级缓存 │
├────────────────────────────────────────────────────┤
阶段 1 接入 │ 垂直到水平 · 负载均衡 · 网关 · 线程模型 · 压测入门 │
（第 2~4 周） │ │
├────────────────────────────────────────────────────┤
阶段 0 度量 │ 流量语言（Little 定律）· 容量估算 · 亿级消息三笔账 │
（第 1~2 周前半） │ │
└────────────────────────────────────────────────────┘顺序设计的三个关键决定，先说透，免得学到一半怀疑路线：
- 度量先于一切（阶段 0 排第一）：不知道「QPS 过万」是多大压力、不知道单机极限在哪，后面的「加缓存」「上 MQ」就都是跟风。先会算账，再学花钱。
- 缓存先于分库分表（阶段 2 在阶段 4 前）：真实世界里 90% 的「数据库慢了」靠索引 + 读写分离 + 缓存就解决了，分库分表是最后的大招——先把便宜的招学完，才知道大招什么时候才值得出。
- 场景实战放在防护与高可用之后（阶段 7 排在阶段 5、6 后）：IM、Feed、推送、秒杀都是「总装题」，需要前面所有零件齐备。先造零件，再总装，顺序反过来就只能在阶段 7 里黑洞式补课。
五、阶段 0：度量——学会流量的语言（第 1 ~ 2 周前半）
为什么有这个阶段：「QPS 过万」「亿级消息」到底是多大的压力？不建立量化直觉，后面每个组件「能扛多少、缺多少」都无从谈起。这个阶段结束时，任何流量指标在你眼里都会变成可计算的账。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 0.1 流量的语言 | QPS、RT、并发数是什么关系？P99 为什么比平均值重要？ | 用 wrk 压一个空 Spring Boot 接口，记录不同并发下的三组数据，验证 Little 定律 | 给定并发数与平均 RT，能手算 QPS；说清「平均 RT 50ms 但 P99 2s」意味着什么 |
| 0.2 从日活到机器数 | 产品说日活翻十倍，要加多少机器多少存储？ | 给「5000 万 DAU 的 IM」算一笔账：消息量、存储、带宽、QPS、机器数，逐项写出公式 | 对任一业务场景 30 分钟内产出容量估算表 |
| 0.3 亿级消息三笔账 | 「亿级消息」指日量还是峰值？堆积十亿条占多少盘？ | 本地 RocketMQ 压 10 万条 1KB 消息，实测生产 TPS、落盘大小、消费 TPS，对比理论值 | 给定「日活 5000 万、人均 50 条」，推出峰值 TPS、日存储量、7 天堆积上限 |
阶段验收：拿一个你熟悉的 App（如微博或淘宝），公开数据 + 合理假设，估算它的日请求量、峰值 QPS、日消息量、核心链路机器规模——数字允许差一个数量级以内，但每一步的公式必须写得出。
六、阶段 1：接入——从一台机器到一群机器（第 2 周后半 ~ 第 4 周）
为什么有这个阶段：流量到顶的第一反应不该是「加机器」。先学会把单机榨干、认识无状态与线程模型——这是横向扩展与百万长连接共同的地基，也是后面一切集群化的前提。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 1.1 扩容两条路 | 什么时候垂直扩容性价比更高？水平扩展的前提是什么？ | 同一接口调线程池/连接池参数前后各压一轮，看单机 QPS 变化 | 说清无状态改造的三件事（session 外置、本地缓存、定时任务） |
| 1.2 负载均衡 | 四层和七层差在哪？为什么一致性哈希对缓存友好？ | Docker 起 3 后端 + Nginx 加权轮询，压测看每台 QPS 分布；杀一台看健康摘除 | 能配一套带健康检查的负载均衡，并解释四种调度算法的适用面 |
| 1.3 API 网关 | 鉴权限流日志每个服务写一遍？哪些能力该收敛到入口层？ | 起 Spring Cloud Gateway（或 APISIX），配路由+限流，压测网关自身 QPS 上限 | 能列出「该放网关 / 必须下沉服务」的能力清单及理由 |
| 1.4 线程模型 | 一台机器怎么同时服务 1 万个连接？ | 分别用 BIO 与 Netty 写 echo server，各 hold 1 万连接，对比线程数与内存 | 能画出主从 Reactor 线程分工图，说清 acceptor / worker / eventLoop 各干什么 |
| 1.5 压测入门 | 不压测，怎么知道优化有没有用？ | wrk 对带 MySQL 查询的接口阶梯加压，画「QPS-并发数」曲线找拐点 | 能独立完成一次规范压测并输出报告（QPS / RT 分位 / 错误率 / 饱和点） |
阶段验收：把示例系统从单机改造为「Nginx + 3 实例」集群并压测，集群 QPS 不低于单机 ×2.5；说清为什么达不到线性 ×3。
七、阶段 2：缓存——挡住 80% 的读（第 5 ~ 7 周）
为什么有这个阶段：流量一大，先死的一定是数据库。缓存是读扩展的第一刀，也是面试与线上事故的最高频区——命中率、三大问题、一致性，每一项都要能落到时序图级别。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 2.1 DB 为什么先死 | 流量大为什么总是数据库先挂？它的极限在哪？ | 压一个查询接口到数据库崩溃边缘，观察连接数、buffer pool 命中率、慢查询日志 | 列出 MySQL 单机读/写的典型极限量级，说出压垮它的三种常见姿势 |
| 2.2 读写分离 | 读是写的十倍，怎么让从库分担？复制延迟怎么办？ | Docker 搭一主两从，压读观察分担；人为制造延迟复现「刚写完读不到」 | 说清复制延迟三个对策（强制走主/延迟判断/半同步）各自的适用场景 |
| 2.3 缓存模式 | 缓存这么快，为什么不全量走？谁来维护一致性？ | 给接口加 Cache-Aside，压测前后 QPS 对比并统计命中率 | 解释为什么「先更新 DB 再删缓存」是主流姿势 |
| 2.4 缓存三兄弟 | 命中率 99% 为什么还是被打挂？ | JMeter 压「不存在的 id」复现穿透；压刚过期热 key 复现击穿；加空值缓存与互斥锁对比 | 穿透/击穿/雪崩各画出时序图，各说出至少两种对策 |
| 2.5 缓存一致性 | 数据改了缓存什么时候改？顺序错了会怎样？ | 并发读写复现不一致窗口；接入 canal 观察订阅 binlog 异步刷缓存 | 画出四种更新顺序各自的不一致窗口，说清为什么放弃强一致 |
| 2.6 热点 key | 一个 key 被百万 QPS 打，单分片扛不住怎么办？ | Caffeine + Redis 两级缓存改造，压测对比纯 Redis 与 L1 命中的 QPS 差距 | 设计「扛百万 QPS 读热 key」方案，说出每层过期策略与主动刷新时机 |
阶段验收：示例系统商品详情页改造完成——两级缓存 + 空值防穿透 + 互斥重建，压测 QPS 达到无缓存版本的 10 倍以上，且能现场复现并修复击穿。
深挖旁支：Redis 学习总纲——数据结构选型、持久化、Cluster 细节。
八、阶段 3：异步——亿级消息的骨干（第 8 ~ 11 周前半）★双主线交汇
为什么有这个阶段：同步链路扛不住洪峰，也撑不起亿级消息。这个阶段是 QPS 主线与消息主线的交汇点——削峰填谷解决「扛住」，存储模型解决「存下」，堆积治理解决「追上」，推拉投递解决「送到」。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 3.1 同步链路的天花板 | 下单同步调 8 个下游，一个慢为什么全链路慢？ | 搭 A→B→C 链路，C 加 2s 延迟，压 A 观察 B 线程池被打满的传播过程 | 能对真实链路画出「延迟叠加表」，指出哪些环节该异步化 |
| 3.2 削峰填谷 | 秒杀 10 万 QPS 洪峰，DB 只能接 5000，谁来缓冲？ | 秒杀下单 demo：直接打库 vs 入队匀速消费，压测对比 DB 的 QPS 曲线 | 算出「洪峰 10 万/秒持续 5 秒、消费 5000/秒」的排队深度与最长等待 |
| 3.3 亿级存储模型 | 消息写磁盘为什么还这么快？ | dd 对比顺序写与随机写吞吐；RocketMQ 不同刷盘配置压测 TPS 差异 | 画出一條消息从 producer 到盘的完整路径，说清每步为什么快 |
| 3.4 顺序、重复与事务 | 消息会乱序吗？会重复吗？发消息和写库能一致吗？ | 复现「重试导致重复」；消费端去重表实现幂等；跑通 RocketMQ 事务消息回查 | 说清「至少一次 + 幂等 = 恰好一次效果」的实现细节 |
| 3.5 堆积治理 | 消费者挂了一小时堆了 10 亿条，怎么追？ | 制造 100 万条堆积，对比「1 消费者 / 8 消费者 / 批量消费」的追赶速度 | 写出一套堆积应急预案（告警水位 / 扩容边界 / 跳过与转储时机） |
| 3.6 推与拉 | IM 消息怎么送到手机上？服务端推还是客户端拉？ | 抓包观察 RocketMQ push 消费者的长轮询；Netty 写最小推送 demo | 设计「在线推、离线拉、seq 补齐」的投递方案 |
| 3.7 MQ 选型 | 亿级场景选 RocketMQ 还是 Kafka？ | 同一压测脚本分别打 RocketMQ 5.x 与 Kafka 4.x，对比 TPS 与 RT | 对给定场景写出选型报告，含否决理由 |
阶段验收：示例系统「下单→发券→通知」链路全部异步化：洪峰 1 万 QPS 打进来，DB 匀速落库、消息零丢失、消费幂等，并能现场制造堆积再现场治理恢复。
深挖旁支：RocketMQ 学习总纲——架构、源码、事务消息细节。
九、阶段 4：分片——写扩展的最后王牌（第 11 周后半 ~ 第 14 周）
为什么有这个阶段：读有缓存挡着，写却只能靠数据库自己。当单库写入到极限、单表行数到亿级，分库分表是最后的大招——也是代价最大的一招，所以本阶段从「拆前穷尽」开始学。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 4.1 拆前穷尽 | 数据库慢就是该分库分表了？ | 造 5000 万行大表，对比「无索引→加索引→冷热归档」的查询耗时变化 | 列出「拆之前必须穷尽的五件事」及各自的判断阈值 |
| 4.2 垂直拆分 | 一个大库装所有业务，互相拖累怎么办？ | 把订单库从单库拆成订单/用户/商品三库，应用层接口聚合替代 join | 说清垂直拆分后一致性从数据库层转移到了哪一层 |
| 4.3 水平拆分与分片键 | 单表 5 亿行拆 64 张表，按什么拆？ | 设计「user_id hash 16 库 64 表」方案，1000 万条数据验证分布均匀度 | 解释基因法怎么实现「按用户查走 A 分片、按订单号查也走 A 分片」 |
| 4.4 全局 ID | 分库后自增 ID 冲突，ID 怎么发？ | 实现简化雪花算法，模拟时钟回拨复现重复 ID，加对策 | 画出雪花 64 位分配图，说清每位为什么这么分、为什么不用 UUID |
| 4.5 跨分片难题 | 拆完后「按时间第 3 页」「总 GMV」怎么算？ | 跨 4 分片做全局分页，对比归并查询与「禁跳页+游标」；跨库下单用可靠消息保最终一致 | 每个跨分片问题说出至少两种方案与取舍 |
| 4.6 落地与扩容 | 分片方案怎么不停机上线？16 库不够怎么扩 32 库？ | ShardingSphere-JDBC 接「2 库 4 表」跑通；模拟 2→4 库的扩容全过程 | 写出不停机扩容 runbook，含每步验证点与回滚点 |
阶段验收：示例系统订单库完成分片改造（2 库 4 表 + 雪花 ID + 非分片键查询走异构表），压测写入能力达到单库 3 倍以上，跨库下单链路最终一致。
深挖旁支：分布式事务学习总纲——跨库一致性的完整方案谱系。
十、阶段 5：防护——让系统过载时不死（第 15 ~ 17 周前半）
为什么有这个阶段：前面四个阶段让系统「跑得快」，这个阶段让它「摔不死」。洪峰与故障不是概率问题而是时间问题——限流、熔断、降级、隔离四板斧，是「有损服务」的艺术。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 5.1 雪崩机理 | 一个下游慢 2 秒，为什么整站 502？ | C 慢 3s，观察 A 的 Tomcat 线程被打满到拒绝服务；加超时+降级后恢复 | 画出雪崩传播图，说清每一步的止血手段与超时怎么定 |
| 5.2 限流四算法 | 「每秒最多 1000 次」怎么实现才既准又稳？ | Guava RateLimiter 压测被拒曲线；手写固定窗口与滑动窗口对比临界突刺 | 说清漏桶与令牌桶谁适合对外卖票、谁适合内部调用 |
| 5.3 集群限流 | 单机 1000 × 10 台 = 10000？DB 只能接 6000 | Redis + Lua 实现集群滑动窗口限流器，10 实例压测验证总通过量收敛 | 说出集中式限流的单点风险与容灾方案 |
| 5.4 熔断与降级 | 下游已挂，还每次都调它一遍吗？ | Sentinel 配慢调用比例熔断，压测触发熔断观察快速失败与半开恢复 | 给核心链路设计三级降级预案（正常/降级/保底） |
| 5.5 隔离舱与自适应 | 非核心接口占满共享线程池，核心交易陪葬？ | 线程池分组隔离改造：压非核心接口，验证核心接口不受影响 | 说清隔离与限流的互补关系，及系统自适应保护看什么指标 |
| 5.6 Sentinel 实战 | 防护规则怎么统一管理、动态下发？ | 应用接入 Sentinel + Nacos 规则持久化，动态调 QPS 阈值热生效 | 搭出「控制台改规则→Nacos 持久化→应用秒级生效」闭环 |
阶段验收：给示例系统配置完整防护体系——网关限流 + 服务熔断 + 热点参数限流 + 非核心隔离；制造「下游故障 + 洪峰」双重打击，核心交易成功率保持在 99% 以上。
十一、阶段 6：高可用——从三个 9 到五个 9（第 17 周后半 ~ 第 19 周）
为什么有这个阶段：规模越大，故障的爆炸半径越大。这个阶段回答「机器总会坏、机房总会断，怎么让用户无感」——从前面的「扛住流量」升级到「扛住故障」。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 6.1 可用性度量 | 老板要 5 个 9，那意味着什么代价？ | 给 demo 系统定义 SLI（成功率/P99），算出当前可用性等级 | 背出 9 的停机预算表，说清「提升一个 9」主要靠什么 |
| 6.2 冗余与故障转移 | 机器坏了怎么让用户无感？ | 3 副本编排，kill -9 一台观察摘除期错误；接入优雅停机再测 | 列出有状态组件故障切换必须回答的三个问题（脑裂/fencing/数据） |
| 6.3 中间件高可用盘点 | MySQL、Redis、MQ 的高可用姿势为什么不能混着背？ | kill 掉 Redis Cluster 一个主节点，观察自动故障转移时间线 | 填出「中间件 × HA 方案 × 切换时间 × 丢数据风险」对照表 |
| 6.4 双活与多活 | 整个机房断了怎么办？ | 纸面推演：秒杀系统按用户归属地单元化，画双机房部署与切换剧本 | 说清同城双活与异地多活在数据一致性上的本质差异 |
| 6.5 故障演练 | 高可用是不是真的，只有故障知道 | 对 demo 系统注入三次故障（kill DB 主 / Redis 加延迟 / 打满线程池），验证防护如期工作 | 产出一份演练报告（注入/预期/实际/差距/改进项） |
阶段验收：演练报告合格——三次注入中限流、熔断、主从切换全部按预案生效；找出至少一处「预案说了但实际没生效」的差距并修复。
深挖旁支：Redis / RocketMQ / K8s 各总纲的高可用章节。
十二、阶段 7：场景——四大亿级系统解剖（第 20 ~ 22 周）★总装
为什么有这个阶段：单点知识只有装进真实场景才成体系。四个场景各代表一种极致形态——IM 的扇出、Feed 的扩散、推送的长连接、秒杀的洪峰——它们是前六个阶段的总复习，也是面试与实战的最高频题。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 7.1 IM 消息系统 | 万人群一条消息变 1 万次投递，怎么扛？ | 实现最小 IM（单聊+小群）：Netty 接入 + 落库 + seq 补齐，压测千级扇出 | 画全链路架构图，说清投递成功率怎么保证（seq + ack + 补拉） |
| 7.2 Feed 流 | 明星官宣，千万粉丝的收件箱怎么更新？ | 实现简化 Feed，对比推与拉的读写延迟；模拟大 V 万级粉丝写扩散耗时 | 说清推/拉/推拉结合的切换阈值与收件箱裁剪策略 |
| 7.3 千万长连接推送 | 怎么把公告 10 秒内送到 1 亿台手机？ | Netty 实现接入层 + 路由表，1 万连接全量推送，测内存与 GC | 设计千万在线的容量模型（多少台机器、怎么分区、怎么限速分批） |
| 7.4 秒杀系统 | 10 万库存、100 万请求、1 秒抢完，怎么活？ | 实现完整秒杀并全链路压测：验证不超卖、不雪崩、扛 1 万+ QPS | 逐层漏斗每环节能答「为什么这么设计、不用会怎样」 |
阶段验收：秒杀 demo 全链路压测通过——不超卖（库存三层防线）、不雪崩（限流削峰生效）、核心指标达标；其余三个场景的架构图与容量推导可脱稿讲解。
十三、阶段 8：验证——压测与容量治理（第 23 ~ 24 周）
为什么有这个阶段：「设计能扛 10 万 QPS」在压测之前只是假设。这个阶段让前面的所有设计拿到真实数据背书，并回答老板最终会问的问题：要花多少钱。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 8.1 全链路压测 | 每个服务单测都过万，拼起来 3000 就挂？ | 对「网关→服务→Redis→MySQL」全链路阶梯压测，找第一个瓶颈并优化后复测 | 输出压测报告：容量结论、瓶颈清单、优化前后对比 |
| 8.2 影子体系 | 在生产压测，数据污染了怎么办？ | demo 系统加染色标记：压测流量写影子表、发影子 topic，验证生产零污染 | 设计影子体系并列出每个中间件的路由规则 |
| 8.3 可观测体系 | 怎么知道系统「还剩多少余量」？ | Micrometer + Prometheus + Grafana 画「QPS/RT/错误率/线程池/连接池」面板并配告警 | 从一张监控图判断当前瓶颈在应用、缓存还是数据库 |
| 8.4 容量与成本 | 1000 台机器 30% 利用率，能砍一半吗？ | 基于压测结论，算出「支撑 5 万 QPS」的最小机器数与成本表 | 写出容量规划报告（假设、计算、水位目标、风险） |
阶段验收：示例系统产出完整容量报告——当前水位、最大容量、瓶颈排序、扩容方案、成本估算，数据全部来自自己压测。
十四、阶段 9：毕业——方法论与完整设计（第 25 周）
为什么有这个阶段：把 24 周的零件组装成「拿到任何新系统都能开工」的方法论，并用一次完整设计证明它。
| 单元 | 回答的核心问题 | 动手实验 | 吃透的标准 |
|---|---|---|---|
| 9.1 架构设计方法论 | 给你一个新系统，从哪里开始设计？ | 拿「亿级推送平台」需求做完整推演：估算→架构→选型→风险 | 独立主持一次架构评审，产出四份图纸（部署/数据流/依赖/演进） |
| 9.2 毕业设计 | 能否综合全部知识交出可落地的设计？ | 设计「日活 3000 万的电商+IM 客服」平台并实现最小核心，压测达设计值 50% | 8 份交付物齐全，每个选型讲出否决了什么 |
| 9.3 资深自检 30 问 | 怎么知道自己出师了？ | 闭卷自测，记录盲区回补后再测 | 25/30 达标，30/30 出师带人 |
阶段验收（毕业设计）：交付容量估算、总体架构、分片方案、缓存方案、消息方案、防护预案、HA 方案、压测报告八份文档 + 可运行核心代码。
十五、资深自检 10 问（节选）
走完全程后，合上资料回答——每题都要能「讲给同事听」：
- 日活 1000 万的 App，核心接口的峰值 QPS 大概是多少？推导过程是什么？
- 单机 Spring Boot 接口、Redis 单实例、MySQL 单库写入，各自的典型极限量级是多少？
- 缓存与数据库的一致性，为什么主流选择「先更新 DB 再删缓存」？它的不一致窗口在哪？
- 一个热 key 百万 QPS，从单 Redis 到扛住它，方案分几层？每层挡多少？
- 秒杀洪峰 10 万 QPS、消费能力 5000/s，排队深度和用户最长等待是多少？怎么算？
- RocketMQ 单机十万 TPS，快在哪三步？为什么 Kafka 分区模型在大topic数下会吃亏？
- 分片键选错了会怎样？基因法怎么让两个维度都路由到同一分片？
- 一个下游慢 2 秒，全链路雪崩的传播路径是什么？四板斧各在哪一步拦它？
- 同城双活和异地多活，在数据一致性和成本上的本质差异是什么？
- 全链路压测为什么必须做影子体系？每个中间件的路由规则分别是什么？
十问能答出八问，你已经超过市面上大多数「背过架构图」的工程师；十问全清，去做毕业设计。
十六、总时间线
| 周次 | 阶段 | 里程碑 |
|---|---|---|
| 1 ~ 2 前半 | 0 度量 | 任一业务 30 分钟产出容量估算表 |
| 2 后半 ~ 4 | 1 接入 | 单机榨干 + 3 实例集群压测达标 |
| 5 ~ 7 | 2 缓存 | 详情页 10 倍 QPS + 现场修复击穿 |
| 8 ~ 11 前半 | 3 异步 ★ | 全链路异步化 + 堆积治理演练 |
| 11 后半 ~ 14 | 4 分片 | 订单分片改造 + 不停机扩容 runbook |
| 15 ~ 17 前半 | 5 防护 | 双重打击下核心成功率 99%+ |
| 17 后半 ~ 19 | 6 高可用 | 三次故障注入全部按预案生效 |
| 20 ~ 22 | 7 场景 ★ | 四大场景脱稿讲解 + 秒杀压测通过 |
| 23 ~ 24 | 8 验证 | 完整容量报告（实测数据背书） |
| 25 | 9 毕业 | 八份交付物 + 自检 30 问 25+ |
按每天 1.5 ~ 2 小时、每周 5 ~ 6 天推进。可以慢，不要乱序——每个阶段的验收没过，不进下一阶段，这是 25 周能真正走完的唯一保证。
十七、参考资料（均已核验为当前状态，核验时间 2026-08-24）
官方一手资料
- RocketMQ 官方文档——消息主线基准 5.3.x（与RocketMQ 学习总纲同基准）
- Kafka 官方文档——4.3.1（2026-06）；4.0 起 ZooKeeper 已移除，KRaft 唯一模式，旧教程注意甄别
- Redis 官方文档——8.x（当前 8.10.x，AGPLv3）
- ShardingSphere 官方文档——5.5.3（2026-03）
- Sentinel 官网与 Spring Cloud Alibaba Wiki——阶段 5 基准
- MySQL 8.0 Reference Manual——复制、InnoDB 章节
书（理论印证）
- 《数据密集型应用系统设计》（DDIA）：第 5 章（复制）、第 6 章（分区）——与阶段 2、4 互为印证
- 《大型网站技术架构》（李智慧）：演进叙事的中文经典，读序言与架构演进部分即可，正文与本大纲实验互补
衔接资料（本博客内）
- 深挖旁支：Redis 总纲、RocketMQ 总纲、分布式事务总纲、K8s 总纲
- 环境底座：Linux 基础 6 篇、Docker 总纲
结语：一条线，走到底
这个领域看似组件繁多，拆碎之后只是在重复同一件事：流量涨了十倍 → 找到断裂点 → 用带代价的方案补上 → 用压测验证 → 等下一次涨十倍。单体到集群是这样，缓存是这样，分库分表是这样，你将来遇到的每一个「新架构」也是这样——阶段 9 的方法论会把这件事变成你的肌肉记忆。
25 周，从第一个 wrk 命令到亲手设计一个亿级消息平台。地图已画好，从阶段 0 的第一笔容量账开始。
本篇是路线图，不是教材——每一步的「怎么做到」与「为什么是这样」，在对应的 49 篇正文中展开。发现路线有问题，随时回来改地图。