跳转到内容
AI 速通系统设计

Module 0：系统设计方法论入门

📖 深度参考手册 — 本模块属于理论参考，非主线必读。 主线学习路径见 README.md。 当你在项目实战中遇到相关问题时，回来查阅。

在动手设计任何系统之前，先建立正确的思考框架。本模块解决一个核心问题：拿到一个系统设计题，从哪里开始想？

知识点 1：系统设计面试框架

Section titled “知识点 1：系统设计面试框架”

定义：系统设计的 4 步法——需求澄清 → 高层设计 → 详细设计 → 瓶颈分析。同时对应我们课程中的 5 层框架：用户层 → 用户故事 → 功能层 → 数据层 → 流程层。4 步法是面试节奏，5 层框架是思考维度，两者相互映射。

为什么重要：没有框架，设计就会变成”想到哪画到哪”。框架帮你在有限时间内结构化地覆盖关键决策点，避免遗漏，也让你的思考过程可被他人理解和评估。

案例：以 URL Shortener 完整走一遍——

  1. 需求澄清（用户层 + 用户故事）：谁在用？日活多少？短链接需要自定义吗？过期策略？
  2. 高层设计（功能层）：写入服务（长→短）、读取服务（短→长，302重定向）、分析服务
  3. 详细设计（数据层）：哈希算法选择、数据库schema、缓存策略
  4. 瓶颈分析（流程层）：读写比 100:1，如何扩展读取？哈希冲突怎么处理？

先想一想：如果让你设计一个 URL Shortener，你的第一个问题会问什么？为什么这个问题很重要？

参考思路

一个好的第一问是：“系统的规模是多少？每天需要生成多少条短链接？”

这个问题重要是因为它直接决定了技术选型的方向。如果每天 100 条，一个单机 SQLite 就够了；如果每天 1 亿条，你需要考虑分布式 ID 生成、数据库分片、缓存层等一系列架构决策。规模不同，设计完全不同。

知识点 2：功能性需求 vs 非功能性需求

Section titled “知识点 2：功能性需求 vs 非功能性需求”

定义：功能性需求描述系统”做什么”——用户能执行的操作、系统提供的功能。非功能性需求描述系统”做得怎么样”——性能、可用性、一致性、安全性等质量属性。大部分 CS 基础知识（数据结构、操作系统、网络、数据库）都是为了满足非功能性需求而存在的。

为什么重要：初学者往往只关注”功能能跑通”，但真实系统的复杂性 90% 来自非功能性需求。同样是”下单”这个功能，加上”不能超卖”（一致性）、“高峰期不能挂”（可用性）、“3秒内响应”（性能）这些非功能性需求后，架构复杂度会指数级上升。

案例：Hotel Reservation 系统——

  • 功能性需求：搜索酒店、查看房型、预订房间、取消预订
  • 非功能性需求中最关键的一条：不超卖（一致性）。同一间房在同一天不能被两个人同时预订成功。这个看似简单的需求，背后涉及并发控制、分布式锁、事务隔离级别等一系列 CS 基础知识。

先想一想：微信聊天系统最重要的非功能性需求是什么？是”消息绝对不丢”还是”消息实时送达”？如果两者冲突，你会怎么选？

参考思路

对聊天系统来说，“消息不丢”（持久性/一致性）比”实时送达”（低延迟）更重要。用户可以接受消息晚到 1-2 秒，但不能接受消息丢失。

实际设计中，微信的策略是：先保证消息持久化到服务端，再尽力实时推送。如果推送失败，客户端下次上线时会主动拉取。这就是用”最终一致性”来平衡一致性和可用性——消息一定会到，但可能不是立刻到。

知识点 3：CAP 定理

Section titled “知识点 3：CAP 定理”

定义：在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者最多同时满足两个。由于网络分区在分布式系统中不可避免，实际选择往往是在 CP（一致性优先）和 AP（可用性优先）之间权衡。

为什么重要：CAP 定理是分布式系统设计的第一性原理。每个系统设计决策的背后，都是在一致性和可用性之间做取舍。理解 CAP，就理解了为什么不同系统会做出截然不同的技术选型。

案例：对比两个系统——

  • Chat System（AP，可用性优先）：用户发消息时，即使部分节点之间暂时不同步，也应该让消息发出去。短暂的消息顺序不一致是可以接受的，但”发不出消息”是不可接受的。
  • Hotel Reservation（CP，一致性优先）：预订房间时，必须保证库存数据的强一致性。宁可让用户等一会儿（牺牲可用性），也不能出现超卖（违反一致性）。

先想一想：Gaming Leaderboard（游戏排行榜）应该偏向 CP 还是 AP？排行榜上的排名晚更新 5 秒钟，用户能接受吗？

参考思路

Gaming Leaderboard 适合偏向 AP（可用性优先）。排行榜晚更新几秒钟，用户几乎不会察觉，但如果排行榜页面打不开或加载超时，体验就很差。

实际设计中，排行榜通常采用”最终一致性”：分数更新先写入，排名计算异步进行。用 Redis 的 Sorted Set 可以做到近实时排名，但即使有短暂延迟也完全可以接受。只有在电竞决赛等极少数场景，才需要强一致性的实时排名。

知识点 4：系统设计的度量思维

Section titled “知识点 4：系统设计的度量思维”

定义：从”能用”到”好用”，需要量化思维。系统设计的四个核心度量维度：

  • 延迟（Latency）：一次请求的响应时间，通常关注 P99（99% 的请求在多少毫秒内完成）
  • 吞吐量（Throughput）：系统每秒能处理多少请求（QPS/TPS）
  • 可用性（Availability）：系统正常运行的时间比例，99.9% 意味着每年最多宕机 8.76 小时
  • 数据持久性（Durability）：数据不丢失的概率，S3 的持久性是 99.999999999%（11个9）

为什么重要：没有度量就没有优化方向。“系统要快”是一句废话，“P99 延迟要低于 200ms”才是可执行的目标。度量思维让你从”我觉得够了”进化到”数据证明够了”，这是工程师和业余爱好者的分水岭。

案例：用度量思维审视我们的 11 个系统——

  • URL Shortener：读 QPS >> 写 QPS，读延迟要求 < 10ms（用户等不了）
  • YouTube：可用性要求极高（99.99%），但上传延迟可以容忍（异步处理）
  • Hotel Reservation：数据持久性要求极高（订单不能丢），吞吐量要求相对不高

这些度量的量化分析就是 Module 1（规模估算）要解决的问题。

先想一想：一个 99.9% 可用性的系统和一个 99.99% 可用性的系统，每年的宕机时间差多少？为什么从 99.9% 提升到 99.99% 的成本远高于从 99% 到 99.9%？

参考思路
  • 99.9% 可用性：每年宕机约 8 小时 46 分钟
  • 99.99% 可用性：每年宕机约 52 分钟

差距是 8 小时 vs 52 分钟，看起来只多了一个 9，但实现难度天差地别。

99.9% 通常只需要主从备份 + 自动故障转移就能做到。但 99.99% 意味着几乎不能有任何单点故障，需要多区域部署、自动化运维、灰度发布、完善的监控告警体系等。每多一个 9，需要的基础设施投入和工程复杂度都是量级的提升。这就是为什么云厂商按”几个9”来定价——每个 9 都价值千金。

本模块练习

Section titled “本模块练习”

  1. 5 层框架实战：从以下 11 个系统中选一个你最感兴趣的，用 5 层框架（用户层 → 用户故事 → 功能层 → 数据层 → 流程层）进行分析。不需要完美，重点是练习结构化思考。

    URL Shortener / Web Crawler / News Feed / Chat System / Search Engine / YouTube / Google Drive / Proximity Service / Google Maps / Hotel Reservation / Gaming Leaderboard

  2. CAP 判断：判断你选的系统更偏向 CAP 中的哪两个（CP 或 AP），并说明理由。想一想：在什么场景下，它可能需要做出相反的选择？