系统设计从零到英雄学习路线图
系统设计学习的目标不是记住所有中间件或云服务，而是能将模糊业务约束转化为可工作的最小方案，量化瓶颈，并清楚说明每次扩展带来的权衡。学习应沿着“基础度量 → 设计流程 → 扩展组件 → 分布式数据 → 负载模式 → 多场景迁移”逐层推进。
一、12 周递进路径
| 阶段 | 重点 | 可验证产出 |
|---|---|---|
| 第 1–2 周：基础度量 | 理解延迟、吞吐、可用性、一致性、QPS/存储估算、API 与数据建模。 | 能为一个简单 CRUD 服务说明需求、规模与数据模型。 |
| 第 3–4 周：设计流程 | 固化“澄清需求 → 容量估算 → API/Schema → 最小可行架构 → 深挖瓶颈 → 权衡迭代”的表达顺序。 | 在 30–40 分钟内完成短链服务的端到端设计。 |
| 第 5–6 周：扩展组件 | 缓存、负载均衡、CDN、读副本、消息队列、限流。 | 为读密集服务设计缓存与读扩展，并解释缓存失效和副本延迟。 |
| 第 7–8 周：分布式数据 | 分片、一致性哈希、复制、CAP、SQL/NoSQL、反范式化与热点治理。 | 能论证数据模型、路由和一致性选择。 |
| 第 9–10 周：负载模式 | 分辨读密集与写密集系统，并选择对应的缓存、队列、存储与一致性策略。 | 各完成一个读密集与写密集系统的设计。 |
| 第 11–12 周：题型迁移 | 将模式迁移至不同业务约束，并复盘故障模式。 | 建立“模式 → 条件 → 权衡 → 失效方式”笔记。 |
二、每道题的固定训练循环
需求 → 规模估算 → 最简单可用方案
→ 定位当前瓶颈 → 加入一个有理由的组件
→ 说明新增权衡与故障风险先建立完整、简单的数据流，再按已量化的瓶颈逐层增加缓存、复制、队列或分片；不要一开始就堆叠微服务和高可用组件。系统设计不存在脱离约束的唯一正确答案，设计者应把假设和取舍说清楚。
三、负载驱动的架构判断
- 读密集：优先降低读延迟并保护主库，可使用客户端/CDN/服务端多级缓存与读写分离；通常需要接受副本短暂滞后和最终一致性。
- 写密集：优先平抑峰值与减少随机写，可用消息队列异步削峰、批量处理、LSM-Tree 存储；在复杂场景中可将读写模型分离为 CQRS 或事件流。
- 分布式扩展：默认网络分区可能发生；应依据业务选择分区时偏向数据正确性（CP）或服务可用性（AP）。扩缩容的路由可通过一致性哈希与虚拟节点减少迁移和缓解倾斜。
四、建议的题型顺序
- 短链：唯一 ID、缓存、读扩展。
- 限流器：计数、并发控制、分布式状态。
- 信息流：写扩散、读扩散与混合策略。
- 即时通信：时序、长连接与高频写入。
- 云盘同步：文件分块、差异同步、冲突与元数据一致性。
- 抢票：事务、锁、排队与防超卖。
- 附近地点：地理空间索引与四叉树。
- 视频平台或搜索补全：元数据分片与边缘缓存，或 Trie 与离线重建。
Source: grokking-the-system-design
五、掌握标准
每次练习都应能回答四个问题：系统的核心约束是什么？当前瓶颈在哪里？新增组件解决了什么？它引入了哪种成本、延迟、一致性风险或运维复杂度？能稳定回答这些问题，就已从“背架构图”进入工程设计能力训练。