极高进阶

需求分析与容量估算#

一句话答案#

系统设计的第一步不是画架构图，而是量化需求：DAU → QPS → 带宽 → 存储 → 机器数，用数字驱动每一个设计决策。

核心要点

1. 需求澄清三问#

面试官说”设计一个 XXX 系统”，你的第一反应应该是问问题，而不是画图：

功能边界：核心 use case 是什么？哪些是 MVP，哪些可以后续迭代？
非功能约束：QPS 多少？延迟要求？可用性几个 9？一致性要求（强/最终）？
规模量级：用户量？数据量？读写比？增长趋势？

2. QPS 估算公式#

日活用户 (DAU) → 每日请求总量 → QPS

假设：80% 的请求集中在 20% 的时间（4.8 小时）

平均 QPS = DAU × 每用户日均操作数 / 86400
峰值 QPS = 平均 QPS × 峰值系数（通常 2~5 倍）

示例（短链接系统）：
  DAU = 1000 万
  每用户日均点击 = 2 次
  日请求总量 = 2000 万
  平均 QPS = 20,000,000 / 86,400 ≈ 231
  峰值 QPS = 231 × 3 ≈ 700
  如果是写（创建短链）：读写比 100:1 → 写 QPS ≈ 7

plaintext

3. 带宽估算#

带宽 = QPS × 平均响应大小

示例：
  峰值 QPS = 700
  平均响应 = 500 字节（重定向响应）
  带宽 = 700 × 500B = 350 KB/s ≈ 2.8 Mbps

plaintext

4. 存储估算#

每日新增 = 写 QPS × 86400 × 单条数据大小
年增量 = 每日新增 × 365
保留策略：数据保留多久？是否需要冷热分离？

示例（短链接）：
  写 QPS = 7
  每日新增 = 7 × 86400 ≈ 60 万条
  单条 = 200 字节（短码 + 原始 URL + 元数据）
  每日存储 = 60 万 × 200B = 120 MB
  5 年存储 = 120 MB × 365 × 5 ≈ 219 GB

plaintext

5. 机器数估算#

单机能力（经验值）：
  - Web 服务器：1000~5000 QPS（取决于逻辑复杂度）
  - MySQL 单机：1000~3000 QPS（简单查询）
  - Redis 单机：10 万+ QPS

机器数 = 峰值 QPS / 单机 QPS × 冗余系数（1.5~2 倍）

示例：
  峰值 700 QPS / 单机 2000 QPS = 0.35 台
  高可用至少 2 台（主备或双活）

plaintext

6. 可用性 SLA 量化#

SLA	年停机时间	适用场景
99%（两个 9）	3.65 天	内部工具
99.9%（三个 9）	8.76 小时	普通业务系统
99.99%（四个 9）	52.6 分钟	核心交易系统
99.999%（五个 9）	5.26 分钟	支付/金融系统

从三个 9 到四个 9，架构复杂度和成本可能翻倍。面试中要说清楚：你的系统需要几个 9，为什么？

7. 延迟指标#

指标	含义	典型目标
P50	50% 的请求在此时间内完成	核心接口 < 50ms
P99	99% 的请求在此时间内完成	核心接口 < 200ms
P999	99.9% 的请求	监控报警线

P99 比 P50 更重要——用户感知到的是”偶尔很慢”，而不是”平均很快”。

面试回答（2分钟版）

系统设计我会先花 2-3 分钟做需求澄清和容量估算。功能需求确定核心 use case 和边界，非功能需求量化 QPS、延迟、可用性目标。然后用 DAU 推导：DAU 乘以人均操作除以秒数得出平均 QPS，乘以峰值系数得到峰值 QPS。再根据 QPS 推算带宽（QPS × 响应大小）、存储（写 QPS × 时间 × 单条大小）、机器数（峰值 QPS / 单机能力 × 冗余系数）。这些数字会直接指导后面的架构选型——比如 QPS 只有几百，单机 MySQL 就够；QPS 上万，就需要考虑缓存层和读写分离。

追问与易错

追问方向：

“你这个估算里，单机 QPS 怎么来的？”→ 压测 + 经验值，不同业务逻辑差异大
“峰值系数为什么取 3？”→ 取决于业务特征，秒杀场景可能 10 倍以上
“读写比怎么估？”→ 大多数系统读多写少（10:1 ~ 100:1），社交 Feed 可能读写比更极端

易错点：

❌ 跳过估算直接画架构——面试官会认为你缺乏工程判断力
❌ 估算过于精确（算到小数点）——面试要的是量级判断，不是精确计算
❌ 只估算了 QPS 没估算存储——数据量级决定存储选型（MySQL vs 分库分表 vs NoSQL）