简介《System Design Interview》是面向求职者的系统设计面试经典读物作者Alex Xu曾任职Twitter、Apple等公司全书旨在帮读者系统应对模糊且宏大的架构设计题。资源为PDF格式1个文件、约9.97MB便于离线阅读与检索。内容覆盖从零扩展到百万用户的完整路径以及背封估算、系统设计面试框架、限流器、一致性哈希、键值存储、唯一ID生成器、URL短链接、网络爬虫、通知系统、新闻推送、聊天系统、搜索自动补全等核心专题并深入剖析YouTube与Google Drive两大综合案例。每个专题均从需求分析、容量估算到高可用架构逐步展开配有大量示意图与对比表帮助读者理解不同方案取舍。已有2226人学习适合希望建立系统设计方法论、备战技术面试的中高级程序员与架构师。1. 系统设计面试一道没有标准答案的“白板选择题”如果你是后端、客户端或全栈工程师准备跳槽时多半绕不开系统设计面试。它不像算法题那样有唯一解也不像八股文那样背熟就能过。面试官只给你一个模糊需求比如“设计一个短链系统”或“设计一个信息流”然后让你在白板上从零开始谈方案。这时候系统设计面试.pdf这类资料的价值就显现出来了它不是在教你背某个系统而是帮你建立一套“遇到任何系统都能现场拆解”的思考框架。我见过很多候选人算法题刷了几百道但一进系统设计环节就翻车。原因不是技术底子差而是思路没理顺——拿到题目不知道从哪开口要么一上来就画架构图要么纠缠在某个细节里出不来。这类资料通常会把整个回答过程拆成步骤需求澄清、容量估算、数据模型设计、核心接口定义、架构演进最后才落回到具体组件选型。你照着这套节奏走哪怕最终方案和面试官的预期不完全一致他也能看到你的分析过程这比“直接给出正确答案”要重要得多。这篇文章不假设你有特定的高并发项目经验。我会把这类面试最常见的解题框架、容量估算的算式、存储选型和一致性决策的权衡以及最容易让人当场懵掉的考点逐个拆开讲清楚。新手可以把它当作一份可执行的练习清单熟手也能在中间章里对照自己过去的方案看看哪些参数拍脑袋了、哪些坑又踩了一遍。2. 六步解题框架从“题目一句话”到“方案一张图”系统设计面试没有标准答案但有一套被反复验证过的答题节奏。把面试官当产品经理先追问需求把白板当设计文档先写数字再画框。这套框架不是我发明的几乎所有系统设计资料都会提到它。整套流程走完大概三十分钟时间分配大约是需求澄清五分钟容量估算五分钟数据模型与接口十分钟架构与演进十分钟。2.1 需求澄清别急着画图先把这四个问题问完我见过太多候选人题目刚念完就开始画负载均衡和缓存。这不是不对而是太急了。一个“设计短链系统”的题目背后可能藏着完全不同的方案如果业务是内部工具日请求量万级那用一张数据库表加唯一索引就够了如果业务是面向公众的营销短信短链日请求量可能上亿这时候才需要引入发号器、缓存、分库分表。需求澄清阶段我一般会固定问四类问题。第一类是功能范围这个系统要给谁用核心动作有哪些比如短链系统就是“生成短链”和“跳转还原”两个动作。第二类是量级预期峰值 QPS 是多少数据总量大概多少读多还是写多。第三类是延迟要求比如短链跳转的 P99 延迟能否接受 100ms信息流的刷新能不能等两秒。第四类是边界条件需不需要过期删除数据能不能丢失要不要做统计分析。面试官不会不耐烦。相反你问得越细他越能看出你有真实系统设计经验。我通常会把澄清出来的关键约束直接写在白板角落后面每一步设计都回头对着这些约束核对。如果面试官说“你就自己假设吧”那就主动定一套合理的数字比如“我假设日活 100 万每条用户记录 1KB据此往下估算”。2.2 容量估算白板上的算术决定方案形态容量估算的目的不是让你算出精确的存储量和 QPS而是验证你的方案经得起量级推敲。常见做法是先定日活用户数DAU或日请求量再算平均 QPS 和峰值 QPS接着算每条数据的大小最后得出存储总量和带宽需求。我们拿短链系统举例。假设日活用户 100 万每人每天生成 2 条短链那每天新增短链 200 万条。写 QPS 大约是 200 万除以 86400 秒约 23。读 QPS 假设每条短链被访问 10 次就是 2000 万次每天约 231。真实业务里读操作会有突发营销短信发出后的头一个小时访问量集中所以峰值 QPS 通常按平均值的 5 到 10 倍估算也就是读峰值在 1100 到 2300 左右。存储量也可以用同样的方式推。每条短链记录包括短码、原始 URL、创建时间、过期时间大约 512 字节到 1KB。一天新增 200 万条日增存储约 1 到 2GB。如果要求保留一年总数据量就是 365 到 730GB。这个量级意味着单台数据库已经吃力必须考虑分库分表或者冷热数据分离。你把这些算式一步步写在白板上面试官立刻就能看出你的方案是为什么长成这个样子的。2.3 数据模型与核心接口先钉住 Schema 和 API容量估算完成后我习惯先把核心数据模型画出来再定义接口。数据模型决定了后续所有组件的选型。比如短链系统的主表就是短码和原始 URL 的映射短码选什么算法生成主键怎么设计这就是全部的数据设计。信息流系统则复杂得多有用户表、关注关系表、内容表还要考虑时间线是拉取还是推送。画数据模型时注意给出字段类型和索引设计。比如短码字段用 62 进制编码长度 6 位原始 URL 用 VARCHAR 存加上创建时间和过期时间过期时间建索引方便定时任务扫描清理。核心接口跟着数据模型走短链系统就两个接口一个是 POST /api/shorten 生成短链入参是原始 URL 和过期策略出参是短码另一个是 GET /{short_code} 跳转返回 302 和 Location 头。接口定义不用太细但要把关键语义说清楚。生成接口要回答“同一个 URL 要不要返回不同短码”跳转接口要回答“短码不存在时返回 404 还是跳首页”。这些问题本质上是在和面试官对齐业务规则你的方案边界就是靠这些细节撑起来的。2.4 架构演进从单体到分层的三条基本路径架构设计不要一上来就画一堆组件。我习惯先画一个最简单的版本——一台应用服务器加一台数据库然后沿着三个方向演进读写分离、加缓存、水平拆分。这样面试官能清楚看到你每一步决策对应的量级压力。短链系统的演进路径就很典型。初始阶段一台应用加一台 MySQLQPS 到几百时没问题。读 QPS 涨到一千以上就给数据库加只读副本写走主库读走从库。再往上把短码到 URL 的映射缓存到 Redis设置 TTL缓存击穿时回源数据库。最后如果单表数据量超过千万级别按短码哈希分库分表。每一步演进的触发条件都是前面算出来的数字这就是一个渐进的、站得住脚的设计过程。3. 容量估算的实战推演面试官想听到的不是“大概”而是“算出来的”容量估算是系统设计面试里最容易被低估的环节。很多候选人觉得“量级差不多就行”但面试官恰恰在这里分辨你到底有没有真实扛过流量。一套完整的估算应该包括平均 QPS、峰值 QPS、存储增长、网络带宽以及这些数字对架构选型的直接影响。这一章我们全部用数字说话。3.1 QPS 与带宽从日活到每秒请求的完整换算链路先定基准参数再逐层换算。假设我们要设计一个类似短链的服务日活用户 100 万日活用户人均触发 2 条写请求和 20 条读请求。那么日写总量是 200 万日读总量是 2000 万。平均写 QPS 是 200 万除以 86400 秒约 23平均读 QPS 是 2000 万除以 86400 秒约 231。峰值不用拍脑袋我习惯取平均值的 5 到 10 倍理由是白天流量集中且存在突发营销活动所以读峰值 QPS 取约 2000。带宽换算经常被忽略。如果一次短链跳转响应体很小一个 302 响应加 Location 头大约 200 到 400 字节。按峰值读 QPS 2000、每个响应 400 字节计算出口带宽约 800KB/s也就是 6.4Mbps。这个数字对单台服务器来说毫无压力但它可以支撑“不需要在边缘节点部署 CDN”的结论。CDN 是否引入不应该因为“高大上”就加而应该因为带宽或延迟不达标才加。把这些数字写在白板上时最好把单位换算过程也写出来。比如“2000 QPS × 400 字节 800KB/s 6.4Mbps”面试官能清晰看到你的每一步计算。这一步做完后续的组件选型就有了量化的依据——能用一台机器扛住就不用引入一堆中间件这就是经验。3.2 存储估算为什么“每天几 GB”会改变整个架构存储量的推演会直接影响分库分表、冷热分离、归档策略这几项决策。还是用短链系统每条记录按 1KB 估算短码、原始 URL、时间戳、扩展字段加索引空间。日均新增 200 万条就是 2GB 每天。保留一年的话总数据量约 730GB但这个数字不值得直接拿来设计分库分表——因为 2GB 每天的量一年后单表其实也未必撑不住真正的瓶颈往往是索引深度和写入并发。我更倾向于把存储拆成“热数据”和“冷数据”两个池子。短链系统的热数据是最近 30 天创建的短码冷数据是更早的记录。如果 30 天内的数据量约 60GB这个量级单库已经可以承载但查询模式是高频随机读所以直接进缓存。冷数据可以迁移到归档表或者对象存储查询频率极低。分库分表的触发条件我一般看单表数据量超过 2000 万行且持续增长或者写入 QPS 超过单库承受能力而不是单纯看总容量。3.3 数字推演的三个常见误区容量估算最容易犯的错是把所有请求都当成均匀分布。真实系统有昼夜波动有热点事件有促销流量。所以我给峰值系数取 5 到 10 倍同时会加一句“这个系数来自同类业务线上监控的经验值如果面试官要求更精确可以用二八法则估算”。这样既展示了经验又留了讨论空间。第二个误区是低估响应体大小。很多方案只在 QPS 上做文章忘了算带宽。高 QPS 低响应体还好如果系统返回的是 JSON 大对象或者图片列表带宽就会迅速成为瓶颈。遇到这类系统我会在估算阶段就明确写出“单响应平均 50KB峰值 2000 QPS出口带宽 800Mbps必须走 CDN 或者压缩”。这也是面试官判断你有没有带宽敏感度的地方。第三个误区是只算平均存储不估算增长率和保留期。同样是短链系统不设置过期时间两年后数据量翻倍设置 30 天过期数据量就收敛在一个稳定池子里。这一点要在估算阶段就和面试官确认清楚因为它们直接决定要不要做定时清理任务、要不要区分冷热存储。4. 存储选型与一致性决策把“用 Redis”升级为“为什么是 Redis”到了这一步候选人之间的差异开始拉开。初级回答会把 MySQL、Redis、Kafka 这些组件堆上去说“高并发所以用缓存”有经验的回答则会针对每个组件讲清楚它解决的是哪个数量级下的什么具体问题。存储选型没有标准答案但有标准的思考路径先看数据模型是结构化还是半结构化再看访问模式是读多写少还是写多读少最后评估一致性要求。4.1 选型对照什么场景该上什么存储一张表说清楚存储类型典型代表适用场景核心代价关系型数据库MySQL / PostgreSQL强事务、结构化数据、需要 SQL 查询水平扩展成本高单表有瓶颈KV 缓存Redis / Memcached高频读、热点数据、简单键值访问数据持久化弱不适合复杂查询文档数据库MongoDB字段不固定的半结构化数据事务边界弱关联查询受限列式存储HBase / ClickHouse海量写入、宽表、分析型查询不适合低延迟单行查询搜索引擎Elasticsearch全文检索、倒排查询索引延迟存储冗余大真实系统很少只用一种存储关键是“为什么”。短链系统的核心查询是“按短码查原始 URL”这是典型的 KV 访问模式所以主存储选关系型数据库或 KV 都能说通。区别在于如果业务还需要“按用户查所有短链”“按创建时间查列表”KV 就扛不住这类查询需要额外的索引表或冗余关系型存储。我会在白板上同时画两张表一张短链映射表服务于跳转一张用户短链表服务于后台管理这个问题就迎刃而解了。4.2 数据建模主键怎么定决定了你将来的分库分表数据模型设计中主键选择往往被轻视但它直接决定了后续的扩展方案。短码生成常见有哈希截断、发号器、自增 ID 转 62 进制这三种。哈希截断的做法是对原始 URL 做 MD5取前 6 位或 8 位作为短码优点是去重容易、不需要状态管理缺点是碰撞概率随数据量增长明显上升且不同 URL 可能映射到同一个短码。发号器和自增 ID 转 62 进制能保证短码唯一但需要维护一个全局发号器或依赖数据库自增主键。从后续分库分表的角度考虑我更推荐发号器。因为短码由全局序号生成天然顺序递增分片时按短码哈希取模就能均匀分布而哈希截断生成的短码本身就是随机的作为分片键也能均匀分布但存在碰撞问题。表结构也很简单短码字段设置唯一索引原始 URL 建普通索引过期时间建索引。唯一索引保证同一短码不重复但这里要确认业务规则——同一个原始 URL 是否允许生成多条短链如果允许就要在生成接口里放开这个约束不能靠数据库兜底。4.3 一致性权衡CAP 不是背概念是现场做选择题在系统设计面试中一致性讨论通常集中在缓存和数据库之间。最典型的问题是“更新短链过期时间后缓存里的旧值怎么处理”。这里有两种策略一种是先更新数据库再删除缓存下一次读请求回源并重建缓存另一种是先更新缓存再异步写数据库。我一般倾向第一种因为缓存删除失败导致的问题远小于缓存写脏导致的问题。删除失败的兜底也很简单给缓存设置短过期时间比如 5 到 10 分钟即使删除失败最终也会过期重建。如果业务升级为“同一短码的访问次数需要实时统计”也涉及一致性。常见方案是写操作落库计数操作走 Redis 原子自增定期把计数批量刷回数据库。这里的一致性模型是最终一致性Redis 可能瞬时比数据库多几个计数。面试官如果追问“这台 Redis 挂了怎么办”你就要答出持久化策略和降级方案AOF 每秒刷盘加上主从复制挂掉一台从节点顶上。CAP 在这个场景里不需要复杂论证讲清楚选了什么、放弃什么、挂了怎么恢复就已经及格了。5. 系统设计面试避坑五个让候选人当场翻车的细节系统设计面试的翻车点往往不是大方向而是细节。很多候选人框架背得熟但现场一被追问就露馅。下面这五条是我从模拟面试和真实面试中总结出来的高频踩坑记录每一条都按“现象、原因、解决”拆开讲。现象一需求澄清阶段把面试官问烦了。有些候选人一口气问了十几个问题从“是否支持多语言”到“是否需要暗黑模式”但都是无效问题。原因是候选人把需求澄清当成了任务清单没有围绕核心场景提问。解决方法是把问题收敛到三件事上功能边界、量级预期、一致性要求。超出这三个维度的细节直接说“按常规处理后续设计需要时再确认”。现象二容量估算被追问时每个数字都没有推导过程。候选人说“我估计峰值 QPS 是 5000”面试官问“怎么来的”答不上来。原因是用“感觉”代替“演算”。解决方法是任何数字都要能从日活和人均行为推导出来哪怕估算粗糙推导链路不能断。哪怕说“日活 100 万人均 10 次访问集中时段占 80%”也比拍脑袋强得多。现象三存储选型只看名气不看场景。候选人给信息流系统直接上 Elasticsearch原因是“搜索快”。但面试官追问“你的查询模式是关注关系下的时间线过滤不是文本搜索”候选人就卡住了。原因是没从查询模式推导存储选型。解决方法是先画出核心查询语句再顺着访问模式选存储。查短码用 KV查列表用关系型查文本才用搜索引擎。现象四画架构图时组件之间没有数据流向标注。候选人画了 Nginx、应用层、Redis、MySQL、消息队列但每个组件之间的箭头只是“连线”说不清数据经过每个环节时发生了什么。原因是没有把“请求生命周期”和架构图绑定。解决方法是在架构图上直接标出每一步的数据变化比如“请求到达应用层、查缓存未命中、回源数据库、写回缓存、返回响应”让面试官能顺着箭头走一遍。现象五面对不会的场景直接沉默或谎报经验。候选人被问到从没做过的“直播弹幕系统”第一反应是沉默或者硬说自己做过。原因是把“知道怎么做”当成“必须做过”。解决方法是坦诚说“这个场景我没在线上扛过但我按我的理解推演”然后按框架拆解弹幕的核心是低延迟广播量级取决于在线人数和发送频率存储用 Redis 的列表或消息队列做缓冲。面试官看重的是现场推演能力早就超出了具体的业务背景。6. 最后的进阶把模拟面试变成你的磨刀石理论框架看完了下一步是把知识变成肌肉记忆。系统设计面试是口头表达加白板演算的现场技术只有通过反复模拟才能熟练。建议你找一起准备的同事或朋友每周抽两个晚上每次四十五分钟严格按照真实流程走一遍一个人当面试官出题另一个人在白板或纸上完整答题。题目从短链、计数器、信息流、附近的人、限流器这个序列里轮换每个都足够练到。模拟面试的产出不是“我们把方案聊完了”而是这两样东西一份自己写下的答题笔记一张问题清单。答题笔记记录你在每个环节用了几步、哪些数字是自己推的、哪些是蒙的问题清单记录面试官追问了哪些点、你哪个环节卡了十秒以上。第二次模拟同一道题时先看笔记专攻上次卡住的地方其他环节不自觉就会变快。如果找不到队友也可以用录音自测。对着题目自己答一遍把录音转成文字你会发现自己很多表述是模糊的比如“这里加个缓存就行了”这种话在纸上根本站不住脚。重写一遍把所有“这样搞就行”替换成“因为量级到了这里不加缓存的话数据库 QPS 会超所以必须加”你会发现方案的说服力完全不一样。我第一次准备系统设计面试时老想着把各种中间件都塞进方案里觉得组件越多显得越专业。直到某次模拟面试对方一句话点醒了我“你的方案里每个组件都能说出解决什么问题吗说不出来就是噪音。”从那以后我养成了一个习惯画完架构图挨个问自己删掉这个组件系统会不会挂会不会变慢会不会体验下降如果三个答案都是不会那它就不该出现在白板上。真正的系统设计能力是去掉多余组件之后方案反而更完整。希望这点经验对你有帮助也祝你在下一次面试里不只答对问题还能让面试官看出你扛过真实的流量。本文还有配套的精品资源点击获取