系统设计入门与学习方法
系统设计是把"功能能跑通"升级为"在目标规模下稳定跑通"的过程。它不只关心接口对不对，还要回答：流量涨十倍会不会崩、机器挂掉一半还能不能用、多花一倍机器换来多少收益。本文先讲清系统设计考什么、由哪些部分组成，再给出后续教程的学习路线。
什么是系统设计
写业务代码时，需求和边界通常已写在文档里；系统设计要回答的恰恰是文档之外的问题：
- 数据存在哪里，怎么切分，将来怎么扩容；
- 流量突增时先保谁、牺牲谁；
- 服务出错时怎么重试，怎么保证不重复处理；
- 上面这些选择要付出多少机器成本和维护成本。
一句话概括：系统设计 = 需求 + 约束 → 架构方案 → 权衡取舍。没有约束就没有设计，脱离约束谈"最优架构"都是空谈。
功能需求与非功能需求
功能需求描述"做什么"，非功能需求描述"做到什么程度"。后者常常不写进需求文档，却决定架构走向。
| 维度 | 典型指标 | 常见应对手段 |
|---|---|---|
| 性能 | QPS、TP99 延迟 | 缓存、异步化、连接池、分片 |
| 可用性 | SLA、故障恢复时间 | 多副本、限流熔断、降级预案 |
| 一致性 | 强一致 / 最终一致 | 分布式事务、幂等、对账补偿 |
| 成本 | 机器数、存储费用 | 副本数、数据保留周期、冷热分层 |
四个维度互相拉扯：强一致要同步等待，性能必然下降；多副本提高可用性，成本随之上升。系统设计的工作，就是在四角关系里找到当前业务能接受的平衡点。
一个小例子：短链服务
假设要设计"长链接转短链"服务，先别急着画图，先问几个问题：
日均新增短链：1000 万条
读写比：约 100 : 1（读远多于写）
短链有效期：永久 + 可手动失效
跳转延迟要求：TP99 < 50ms
短链长度：越短越好，但必须全局唯一
由此推导出的关键设计点：
| 观察 | 推出的设计点 |
|---|---|
| 读多写少 | 多级缓存 + 缓存穿透防护 |
| 短码必须全局唯一 | 需要分布式 ID 生成方案 |
| 跳转要求极快 | 按短码直接路由，避免复杂查询 |
| 数据量持续增长 | 需要能按短码分片的存储方案 |
同样一个"短链服务"，如果约束变成"只服务公司内部、日均 100 条"，那单库单表加本地缓存就足够了。规模决定复杂度，这是贯穿本教程的主线。
面试与实战的差别
| 对比项 | 面试场景 | 真实工程 |
|---|---|---|
| 目标 | 展示推导过程与取舍能力 | 让系统长期稳定、可维护 |
| 信息 | 需求要靠提问补全 | 需求、历史包袱都要自己摸清 |
| 手段 | 白板画架构图 | 必须给出可落地的改造步骤 |
| 结束 | 说清方案即可 | 上线后还要监控、扩容、回滚 |
| 风险 | 方案不完美不影响结果 | 一次事故可能损失真实营收 |
面试考"你怎么想"，实战考"你怎么做且不出事"。本教程两者都覆盖：概念章节讲清原理与取舍，实践章节给出可直接落地的表结构与流程。
学习方法：指标 → 瓶颈 → 方案 → 权衡
拿到任何一道系统设计题，按这四步推进即可，不要一上来就堆组件。
第一步 指标 ：把模糊需求翻译成数字（QPS、延迟、容量、SLA）
第二步 瓶颈 ：找最先扛不住的那一环（单库写入？带宽？锁竞争？）
第三步 方案 ：针对瓶颈给 2~3 个候选方案，而不是一个
第四步 权衡 ：对比复杂度、成本、一致性、运维难度，选一个并说明代价
举例：订单表写入扛不住时——
- 指标：单表 2 亿行，写入 5000 TPS，查询 TP99 已达 200ms；
- 瓶颈：B+ 树索引过深、单库磁盘 IOPS 打满；
- 方案：只加索引、垂直拆冷热表、按 user_id 水平分表；
- 权衡：加索引改动最小但只能续命；冷热拆分能省成本但查询要合并；水平分表彻底但引入跨库查询与扩容问题。
能说出"我选 B，代价是 X，当数据量超过 Y 时再升级到 C"，就算真正掌握了系统设计。
本教程路线图
后续章节按"从判断到落地"的顺序推进：
| 阶段 | 章节 | 解决的问题 |
|---|---|---|
| 判断 | 02 需求澄清与容量评估 | 动手前先把规模和 SLA 算清楚 |
| 正确性 | 03~04 幂等设计 | 重试、回调不产生重复数据 |
| 空间效率 | 05~06 布隆过滤器 | 海量数据去重与缓存穿透防护 |
| 容量扩展 | 07~09 分库分表与迁移 | 单表写不下时怎么拆、怎么迁 |
| 全局唯一 | 10 分布式 ID | 分片之后 ID 怎么生成 |
常见误区
- 上来就抄大厂架构：别人的约束和你不同，抄来的方案往往是负资产；
- 只谈组件不谈指标：没有数字支撑的"高并发"没有意义；
- 忽略运维成本：引入一个中间件，就要多一班人值守、多一套监控；
- 把 CAP 当口号：多数业务场景的实际选择是"可用 + 最终一致"，不必强上强一致方案。
小结：系统设计围绕性能、可用性、一致性、成本四要素做取舍，先澄清需求与规模，再定位瓶颈、给出多方案并说明代价。学习时牢记"指标 → 瓶颈 → 方案 → 权衡"四步法，比背组件名字有用得多。