Reference · 002 · 打印友好
四步框架速查表
四步总览
| 步骤 | 时间占比* | 关键动作 | 产出 |
|---|---|---|---|
| ① 澄清需求 Clarify Requirements |
10–15% | 定功能边界（做什么/不做什么）；定非功能约束：用户量、读写比、延迟、可用性、一致性要求 | 一张约束清单 |
| ② 容量估算 Back-of-Envelope |
10–15% | QPS（均值/峰值）、读写比、存储量与增长率、带宽、缓存内存；判断「数字」如何影响架构 | 几个关键数字 + 架构暗示 |
| ③ 高层设计 High-Level Design |
30–40% | 画端到端数据流（Client→LB→Service→Cache→DB）；定义核心 API；定义数据模型 | 一张架构图 + API/数据模型草案 |
| ④ 深入与权衡 Deep Dive |
30–40% | 针对瓶颈深挖：数据库、缓存、单点、长尾；每个决策说清「代价是什么、为什么可接受」 | 权衡决策清单 + 理由 |
* 按一场 45 分钟面试的参考占比；工作评审中同样适用，只是不被计时。
估算速查公式
- QPS = DAU × 人均日操作次数 ÷ 86400；峰值 = 均值 × 2–3
- 读写比：读多写少（常见 10:1 ~ 1000:1）→ 优先上缓存；写多 → 优先考虑异步/队列
- 存储/年 = 每条记录大小 × 每月新增 × 12 × 保留年限；线上存储要再乘副本/冗余系数（约 ×2）
- 缓存内存：按 80/20 法则，缓存约 20% 的热数据即可挡住大部分读流量
- 单机参考：一台普通 DB 扛 ~1 万 QPS 简单查询是安全线，超过就先想读写分离/缓存
第 4 步深挖瓶颈清单
- 数据库：慢查询、连接数上限、主库写入热点、大表 → 读写分离 / 分片
- 缓存：穿透（查不存在的 key）、击穿（热 key 过期）、雪崩（批量同时过期）→ 过期时间加抖动
- 单点故障：LB、主库、注册中心 → 都要有冗余或备用方案
- 长尾延迟：超时 + 重试 + 熔断；重试要带退避（exponential backoff）防雪上加霜
- 数据增长：什么数字翻倍后架构会先垮？把它找出来就是面试官想聊的点
权衡句式（面试与评审通用）
「如果选 A，代价是 __；选 B 的代价是 __；在我们的场景下 __ 更重要，所以选 __。」
「这个方案在数据量达到 __ 之前够用，之后需要 __。」（诚实标注方案的失效边界）
「一致性、可用性、分区容忍三者不可兼得，本场景我优先保 __。」