系统设计是什么

这一课你将能做到

1. 用「澄清 → 估算 → 高层设计 → 深挖」四步法，独立拆解一道系统设计题
2. 对「10 万日活的在线判题平台」完成 QPS、并发判题数、存储增长的数量级估算
3. 区分功能需求与非功能需求，写出可以直接放进设计文档的假设清单

为什么要学

面试从二面开始，几乎必有一轮系统设计：「设计一个短链接服务」「设计一个在线判题系统」「本站要扛 10 万日活，架构怎么演进」。答得好坏直接决定 offer 档位。

工作中它同样每天都在发生：技术方案评审、容量规划、故障复盘，本质都是系统设计——判断「这套架构撑不撑得住、坏了会怎样、下一步往哪扩」。

人话：算法题是练拧螺丝的手艺，系统设计是练画建筑图纸的能力——楼盖几层、电梯装几部、消防通道留在哪、预算多少，全是在约束下做取舍。没有标准答案，只有「能不能自圆其说 + 每个选择有没有代价分析」。

先建立图像

本站（Spring Boot + MySQL + Redis + Nginx + Kafka 的在线判题/学习平台）全景骨架长这样：

   浏览器 / App
        │
   CDN（静态资源、题目图片）
        │
   Nginx（负载均衡 + 限流）
        │
   Spring Boot × N（无状态 API）
     │        │        │
   Redis    Kafka    MySQL
   缓存     判题队列   持久化
              │
        判题机 × N（Docker 沙箱执行代码）

核心动作只有一条主路径：提交代码 → API 校验入库 → 发 Kafka → 判题机消费执行 → 结果写回 → 用户看到 AC/WA。其余（排行榜、统计、通知）都是旁路。

接着是估算。记住一个推演链条：日活 → 每日操作数 → 平均 QPS → 峰值 QPS（×3~5）→ 并发数（Little's Law）。

指标	假设	推导	结果
日活 DAU	10 万	—	—
浏览行为	人均 30 页/天	300 万/天 ÷ 86400s	平均 35 QPS，峰值 ~175 QPS
代码提交	人均 5 次/天	50 万/天 ÷ 86400s	平均 6 QPS，峰值 ~30 QPS
判题并发	每次判题占 CPU 10s	30 QPS × 10s	~300 个并发判题槽位
提交存储	2KB/条（代码+元数据）	50 万 × 2KB	~1GB/天，一年 ~365GB
读写比	看题远多于提交	—	约 9:1

两个关键公式：

峰值 QPS ≈ 日操作总量 ÷ 86400 × 峰值系数(3~5)
并发数 = QPS × 平均耗时      （Little's Law）

第三行的判题并发是最有价值的一步：判题是 CPU 密集型且单次要跑 10 秒，30 QPS 看着不大，但 300 个并发执行槽说明判题机必须独立成池，这是本站和普通 CRUD 平台最大的架构差异。

跟着做

步骤 1：澄清需求（面试前 5~10 分钟）

拿到题不要画图，先问。针对判题平台，合格的澄清问题长这样：

1. 支持哪些语言？——影响沙箱镜像数量
2. 判题耗时预期？——用户能接受排队 30 秒还是 3 秒
3. 有没有比赛场景？——流量瞬间放大 10~50 倍，决定削峰设计
4. 防作弊要求？——决定代码是否需要查重、沙箱隔离级别
5. 一致性底线？——比赛计分能延迟多久、能不能错