系统设计四步框架
你的四个目标——面试、工作决策、晋升、理解大系统——都从同一块骨头开始长：面对一个模糊的大问题，先定框架再动手。面试官用 45 分钟看你的思考结构；你的团队看你的架构文档时，看的也是同一件事。这一课结束时，你会拥有一把能对任何系统设计问题启动的万能钥匙。
§1 · 为什么需要框架先看一个失败案例
面试官说：「设计一个 Instagram。」没有框架的人会脱口而出：「用 MySQL 存图片元数据，Redis 做缓存，再上个 CDN……」
这就像被问「规划一次环游世界」时回答「先买双鞋」。问题出在哪？——你根本不知道这个系统要服务多少人、读多还是写多、能容忍多少停机。在这些答案出来之前，任何技术选型都是猜测。
业界通行解法是一套四步框架，出自 Alex Xu 的《System Design Interview》[1]，开源社区 system-design-primer[2] 也采用同样结构。它同时回答了面试官评估的四件事[1]：界定问题的能力、量化分析的能力、架构能力、权衡取舍时的沟通。
§2 · 框架本体四个步骤，四个产出
澄清需求 Clarify Requirements
把模糊的题目变成明确的约束。问两类问题：
功能性（functional）：核心功能是什么？发帖、关注、刷 timeline——哪些进 MVP，哪些明确不做？
非功能性（non-functional）：多少用户（DAU）？读写比？延迟要求？可用性要求「几个 9」？一致性要多强？——系统设计的本质是满足非功能需求，DDIA 第 2 版干脆以此作为全书开篇[3]。
容量估算 Back-of-Envelope Estimation
用粗算回答「系统有多大」：QPS（均值和峰值）、读写比、存储总量与增速、带宽、缓存内存。常用换算：QPS ≈ DAU × 人均操作数 ÷ 86400，峰值再乘 2–3。
关键不是算得准，而是让数字替你做架构决策：读 1 万 QPS 而写 10 QPS？先想缓存。数据每天涨 100 GB？分片要提前设计。没算过就选型，资深评审一眼就能看穿。
高层设计 High-Level Design
画一张端到端数据流图：Client → 负载均衡器（LB）→ 服务层 → 缓存 → 数据库。先画大块再谈细节。然后补两样东西让图变具体：
API 草案：核心接口长什么样？POST /shorten 接收什么、返回什么？
数据模型：存什么、主键是什么、读写模式是什么？这一步决定后面选 SQL 还是 NoSQL。
深入与权衡 Deep Dive & Trade-offs
回到第 1 步的约束清单，找瓶颈：数据库扛不扛得住？缓存失效会怎样？哪个组件是单点？数据翻十倍后哪里先垮？把深挖的火力集中在 2–3 个最有意思的瓶颈上。
最重要的一件事：每个决策都说出代价。资深与平庸的分界线不是选得对不对，而是能否说出「选 A 的代价是 X，选 B 的代价是 Y，在本场景下 X 更可接受」[3]。
45 分钟面试的参考配比：① 5–10 分钟 → ② 5 分钟 → ③ 15 分钟 → ④ 15–20 分钟。切忌在前两步抢时间——第 1、2 步省下的每分钟，都会在第 4 步连本带利地还回去。
§3 · 微型实战用四步框架拆解 TinyURL
题目：「设计一个短链服务，如 bit.ly。」这是经典的入门题，我们只用四步走一遍骨架——第 8 课会把它做成完整版，你会看到「先骨架后血肉」的学习复利。
| 步骤 | 怎么做 |
|---|---|
| ① 澄清 | 功能：长链换短链、点击短链跳转。明确不做：自定义域名、访问统计（可留作扩展）。非功能：读远多于写（约 100:1）、跳转延迟要低（<100ms 体感）、服务必须高可用——短链挂了，挂的是别人的分享链接。 |
| ② 估算 | 假设每月新增 1 亿条：写 QPS = 10⁸ ÷ (30×86400) ≈ 40/s（峰值 ~120/s）；读 = 40 × 100 = 约 4000/s。存储：1 亿/月 × 12 月 × 5 年 = 60 亿条 × 500 B ≈ 3 TB（乘副本系数翻倍）。 数字的暗示：读压力 4000 QPS → 必须上缓存；3 TB 且持续增长 → 数据模型按分布式 KV 设计，而非单机库。 |
| ③ 高层 | Client → LB → 无状态 API 集群 → Redis 缓存（挡住热点读）→ 分布式 KV 存储。短码用自增 ID + base62 编码，避免随机码碰撞问题。核心 API：POST /shorten、GET /:code。 |
| ④ 深入 | 跳转返回 301 还是 302？——301 会被浏览器永久缓存（省流量，但丢失点击统计）；302 每次都回源（可统计，多一跳）。这就是典型的权衡：统计价值 vs 流量成本。其他瓶颈：缓存穿透（查不存在的码）、写热点、限流防滥用。 |
注意整个过程没有一个「聪明」的组件——框架的价值不在于亮出高深技术，而在于每个选择都能追溯到第 1 步的某个约束。
§4 · 随堂检测即时反馈
§5 · 检索练习合上课件，写出来
这是本课最重要的 3 分钟。直接回看答案会让记忆产生「我会了」的错觉（流畅度错觉）；先努力回忆再核对，才会真正写进长期记忆[2]。建议明天再做一次——间隔重复是留存的关键。
凭记忆写出：四步框架的每一步名称，以及每一步的产出物。
写完后再展开核对参考答案
① 澄清需求 → 约束清单：功能边界（MVP）+ 非功能约束（DAU、读写比、延迟、可用性、一致性）
② 容量估算 → 关键数字（QPS 均值/峰值、存储、带宽）+ 数字暗示的架构方向
③ 高层设计 → 端到端架构图 + API 草案 + 数据模型草案
④ 深入与权衡 → 针对 2–3 个瓶颈的权衡决策清单（每个决策附代价与理由）
漏了哪步的产出？那就是下次面试里你会含糊的地方——回读 §2 对应卡片。
§6 · 本周行动把框架带回真实世界
选一个你真正熟悉的系统——公司里你负责的服务，或你自己的项目（比如 MyTimer 的云同步后端）——写半页纸的四步分析：
1️⃣ 它的功能边界和非功能约束（真实数字！从监控里抓 DAU/QPS）
2️⃣ 一组关键估算
3️⃣ 画它的端到端架构图（哪层缓存？哪个库？）
4️⃣ 列出它当前的 2 个瓶颈，以及你打算怎么权衡
写完直接拿回来和老师（agent）讨论——真实系统的数字比任何教科书都有意思。
§7 · 延伸资源本课一手来源
- 首选精读：Alex Xu《System Design Interview – An Insider's Guide (Vol.1)》第 2 章「Back-of-the-Envelope Estimation」与第 1 章框架总览——本课的主要来源[1]
- 开源对照：System Design Primer 的「System design topics」一节，可用作快速复习[2]
- 随课速查表：四步框架 Cheat Sheet（打印贴墙版，含估算公式与瓶颈清单）
- 术语基准：系统设计词典（本课已收录：QPS、DAU、LB、可用性等）
Lesson 0002 · 数字感：估算不靠天赋，靠背熟十几个数量级。下一课训练你的「肌肉记忆」：内存比 SSD 快 1000 倍意味着什么？99.99% 可用性到底允许每年宕机几分钟？——有了数字感，第 2 步估算就不再是背诵，而是直觉。