大概三年前我开始整理自己的 system design 笔记最初也只是把别人的文章转存、把面试题答案抄一遍结果合上笔记照样不会设计。后来我把这套笔记推倒重来从问题本身出发重新梳理慢慢形成了现在的 system-design-notes。这套笔记帮我顺利讲清了面试里的几道常见设计题也让我在日常架构评审时更有底。这篇博文就是把这套笔记的搭建思路、核心组件取舍、实操模板和踩坑记录整理出来适合正在准备系统设计面试的工程师也适合刚接触分布式系统的后端开发。看完你至少能搭起自己的笔记框架并且能用同一套模板处理八到九成的常见设计题。1. 光抄答案没用先理清 system design 到底在考什么1.1 面试官手里的评分表和你以为的不一样很多人准备系统设计时有个误区以为是在考“知识储备”知不知道 Redis、Kafka、ZooKeeper、一致性哈希。于是拼命背组件特性把热门系统的架构图一张张存进收藏夹。但我实际参加面试和后来帮同事模拟面试时发现系统设计面试真正考察的并不是某个组件的用法而是你在一个模糊问题面前能不能一步步把它拆成可讨论、可验证、可落地的方案。面试官通常拿着几项能力来打分需求澄清是否到位、容量估算是否有依据、技术选型能不能说清理由、模块拆分是否合理、有没有主动讨论瓶颈和取舍。很多人把方案画得天花乱坠但被问一句“为什么用消息队列而不是直接调接口”就卡住了。原因就是平时只记结论没记推演过程。我后来把笔记的方向从“这个系统长什么样”改成了“这个系统为什么长这样”每一篇笔记都逼自己回答几个问题不这么做会怎样换一种方案代价是什么当前场景下哪个因素是最关键的限制条件这样整理过几篇之后再看到新题就不会慌因为思考路径是通用的。1.2 为什么我用“笔记式学习”而不是“刷题式学习”刷题式学习的典型流程是看一道设计题背一份标准答案然后换下一道。短期内好像见了不少题实际到面试时题目稍微改一下需求比如“短链服务要求不能重复生成相同长链接”“消息队列必须保证严格有序”原来的答案就不成立了。笔记式学习不一样它追求的是把一道题吃透从需求到估算再到组件选型每一步都留下自己的推演记录。这样做的好处是第一你真正理解了每个组件在方案里的位置换个场景也能用第二面试时你能自然讲出“我为什么这么选”而不是背稿感很强地报菜名第三笔记会越攒越厚形成自己的方法论遇到新问题可以套用。我自己维护 system-design-notes 的过程中刻意让每篇笔记都保持一个固定节奏先讲问题背景再列功能需求与非功能需求然后是估算、API、数据模型、核心流程、演进方向。这个节奏本身后来就成了我面试时的叙述顺序练习多了以后甚至不需要看笔记张口就能按这个结构组织回答。1.3 我最终采用的笔记结构我的笔记没有按“公司名系统名”来组织而是按“组件场景方法论”三个维度分类。这样做的原因是市面上大多数资料按具体系统拆比如“设计 Twitter”“设计 Uber”但面试题永远是变化无穷的与其背具体系统不如把底层组件和通用场景吃透。我实际采用的目录大致是这样的system-design-notes/ ├── 01_fundamentals/ # 基础概念CAP、一致性模型、延迟数字 │ ├── cap-theorem.md │ ├── consistency-models.md │ ├── latency-numbers.md │ └── load-balancing.md ├── 02_components/ # 核心组件选型笔记 │ ├── cache.md │ ├── message-queue.md │ ├── database.md │ ├── id-generator.md │ └── object-storage.md ├── 03_cases/ # 经典系统设计案例 │ ├── url-shortener.md │ ├── news-feed.md │ ├── chat-system.md │ └── notification-system.md ├── 04_interview-templates/ # 可复用的方法论模板 │ ├── requirement-clarification.md │ ├── capacity-estimation.md │ ├── api-design.md │ └── bottleneck-analysis.md └── 05_retrospect/ # 复盘与错题集 ├── 2024-xx-xx-interview-feedback.md └── common-pitfalls.md01 和 02 是“积木”03 是“搭好的房子”04 是“搭房子的流程”05 是“装修翻车记录”。四个部分对应不同学习阶段刚开始可以多写 01 和 02有一定基础后重点练 03每次面试或练手之后都往 05 里补一条。这份结构我后来推荐给了不少同事普遍反馈是找资料比之前快很多复习时也不会漫无目的。2. 笔记里最常写的几个核心组件选型逻辑一次说透2.1 存储选型什么时候能用 MySQL什么时候必须上 NoSQL存储是所有系统设计的底座。我早期写笔记时习惯先选存储后来发现这是本末倒置正确做法是先看数据模型和访问模式再决定存储。关系型数据库的强项是强事务、ACID、SQL 灵活性适合数据之间有复杂关联、需要多行更新的场景比如订单、账务、用户资料。MySQL 在这个领域依然是无脑优先项大多数系统初期用 MySQL 完全没问题根本不需要为了“技术含量”硬上 NoSQL。需要迁移到 NoSQL 的信号通常有几个第一单表数据量到了千万级以上且按主键查询多、复杂 JOIN 少第二读写并发高热点数据集中需要更灵活的扩缩容第三数据结构本身偏“文档化”或者“键值化”比如用户画像、消息流、会话列表。这时候可以考虑 MongoDB、Cassandra、HBase 或者纯 Redis。我在笔记里专门做了一张对比表提醒自己不要凭感觉选型维度MySQLMongoDBCassandra数据模型表结构、强模式文档、灵活模式宽列、最终一致事务能力强事务单文档事务弱事务扩展方式主从、分库分表副本集、分片天然分布式一致性强一致可配置可配置最终一致适合场景订单、账户、后台管理内容、日志、画像时序、IoT、大规模写入这份表格的意义不在于说谁好谁坏而在于帮你在设计时快速判断系统最核心的诉求是“不能出错”还是“必须扛住”。如果是前者老老实实用 MySQL如果是后者考虑 NoSQL而且要接受它在一致性或事务上的妥协。2.2 缓存不是缓冲地带而是抗热点的第一道防线缓存大概是 system design 里出现频率最高的组件。但很多人对缓存的理解只停留在“把数据放内存里读得快”到了真正设计时回答永远是“加个 Redis”却说不清加在哪个位置、缓存什么数据、过期时间怎么设。我的笔记里把缓存拆成了几个层面CDN 缓存静态资源、DNS 层偶尔也算缓存、应用层用本地缓存或 Redis 缓存热点数据、数据库前面可能还有一层代理缓存。设计时先看请求链路数据在哪一层被反复读就在哪一层加缓存而不是所有场景都往 Redis 上堆。关于缓存穿透、击穿、雪崩我单独记了一篇因为这是面试必问也是线上最容易出问题的三个点。它们现象相似但成因完全不同穿透是查一个一定不存在的数据导致请求直接打到数据库击穿是某个热点 key 失效瞬间大量请求同时打到数据库雪崩是大批 key 同一时间失效数据库瞬间承受全部压力。对策也不一样穿透靠布隆过滤器或缓存空值击穿靠互斥锁或逻辑过期雪崩靠过期时间加随机值、多级缓存、熔断降级。我在文章里给这三个问题做了个速查表问题典型现象核心原因应急手段缓存穿透数据库 QPS 暴涨查不到目标数据请求绕过缓存直查 DB布隆过滤器、缓存空值缓存击穿单个热点 key 失效DB 压力瞬时升高key 过期 高并发访问互斥锁、逻辑过期、热点 key 不过期缓存雪崩大面积缓存失效DB 被压垮大批 key 同时过期过期时间加随机、多级缓存、限流降级笔记里我要求自己给每个技术点配一个“线上判断方法”比如怎么从监控图上区分击穿和雪崩。实践经验是击穿通常发生在某个热点 key 的失效节点表现为某个接口的耗时曲线出现尖刺雪崩则是所有接口同时变慢现象是系统整体性崩溃。能说清楚这个差异面试时明显更有说服力排查故障时也快很多。2.3 消息队列的本质是拿空间换时间很多人把消息队列当“解耦工具”用这没错但理解太浅。我在笔记里把它的价值拆成三块削峰填谷、异步化、解耦。削峰填谷是系统设计里最常用到的特性上游洪峰到来时消息队列先把请求暂存下游消费者按自己的速度处理这样下游不会被瞬时流量打垮。但消息队列不是银弹它引入的额外问题更值得记笔记消息可能丢失、可能重复、可能乱序。于是每次设计如果用到 MQ我都会主动提这三个问题。Kafka 通过 partition 内有序保证分区有序性RocketMQ 也支持队列级别的顺序消息但全局有序的代价是性能大幅下降。可靠性则需要从生产者、Broker、消费者三段分别确认生产者等 ackBroker 多副本持久化消费者处理完再提交 offset。我的笔记里专门记了一条心得引入消息队列之前先问自己能不能用最简单的同步调用解决如果并发不高、流量不大硬上 MQ 只会让系统更复杂。很多面试者一上来就画一堆 Kafka、Redis、ZooKeeper反而暴露出对场景缺乏判断力。系统设计追求的是复杂度和需求匹配不是组件堆砌。2.4 分布式 ID 和分库分表数据膨胀后的必然之路数据量一旦涨上去存储的拆分就绕不开。我的案例笔记里几乎每条都会涉及两个问题ID 怎么生成、表怎么拆。分布式 ID 的核心要求是全局唯一、趋势递增、高可用。常见方案有数据库自增、Redis INCR、UUID、雪花算法。数据库自增在分布式下扩展性差UUID 太浪费空间且无序雪花算法是很多系统的默认选择。我在笔记里对雪花算法做了个备注它由时间戳、机器 ID、序列号组成64 位刚好可以塞进 bigint但实际部署时要注意时钟回拨问题。分库分表则要重点考虑分片键。分片键选得好数据能均匀分布查询能路由到少数几个分片选得不好会出现热点分片或者扫全库的惨剧。我见过最典型的反面案例是按用户名的首字母分片结果“A”“Z”这种字母集中导致部分分片数据量暴涨。更推荐用用户 ID 或订单 ID 做 hash 取模或者按时间范围分表再定期归档。笔记里我会要求自己写清楚每个方案的回退路径因为分片一旦上线改分片键就是大工程。3. 用一套模板拆穿所有设计题短链接服务全流程3.1 需求澄清先问清楚再动手画图短链接服务是 system design 里最经典的入门题也是我的案例笔记里第一篇完整拆解的。很多人拿到题目就开始画生成短码的流程但我现在会先花五分钟把需求问清楚。我会问几个问题这个服务主要用于站内跳转还是外部分享需不需要自定义短链跳转要不要带统计链接有效期是长期还是临时规模大概多少读多写少的比例是多少这些问题直接影响后续方案比如如果允许自定义短链生成器就要预留一个独立字典如果做统计重定向就不能用 301 而是要用 302因为 301 会被浏览器缓存后续请求根本不会到达服务端。需求澄清阶段我的模板长这样直接复用就行功能需求长链接转短链接短链接访问时重定向到原长链接可选的自定义短码、过期时间。非功能需求高可用、低延迟、数据不丢失短码不可预测防止被遍历。预估规模写 QPS、读 QPS、存量数据量、短码长度。这个清单的底层逻辑是先锁定“系统必须做什么”再锁定“系统必须扛到什么程度”最后才谈“怎么做”。我在笔记里几乎每篇案例都用了同一套清单练到后期面试官提完题目我就能直接说出要问的问题对方明显会感受到你是一个有经验的人。3.2 容量估算纸上算清楚别等上线再后悔容量估算不是面试官在刁难你而是判断方案可行性的第一步。很多方案看着完美一算数据量就露馅了比如短码设计成 4 位存量 3 亿条就撞车。拿短链接服务来举例。假设 DAU 100 万平均每个用户每天生成 1 个短链那么日新增短链约 100 万。读写比通常很高我按 100:1 估算也就是每天有 1 亿次短链访问。平均写 QPS 大约 100 万除以 86400 秒约 12峰值按 5 倍估算约 60。平均读 QPS 是 12 乘 100约 1200峰值约 6000。这种量级数据库每秒 6000 次读必须依赖缓存才能扛住如果直接打到 MySQL 上即使主从也危险。存储量的计算同样简单。1 年新增短链约 3.65 亿条每行记录包括短码、长链接、创建时间、过期时间差不多 200 字节总数据量约 73 GB。这个量级其实单机 Redis 都放不下MySQL 也有压力所以需要给数据库加缓存并且考虑冷热数据分离。短码长度呢用 62 进制表示5 位能容纳约 9.16 亿个组合明显不够支撑多年6 位能到 568 亿更稳妥。这些计算是我在笔记里一笔一笔写下来的面试时能现场说出来会很有说服力。3.3 API 设计与数据模型先定契约再写代码短链接服务的 API 设计非常直接我会在笔记里给出两个核心接口并说明为什么这样设计POST /api/v1/shorten 请求体: { url: https://example.com/very/long/url, customCode: optional } 响应: { shortCode: abc123, shortUrl: https://short.cm/abc123 } GET /{shortCode} 响应: 302 重定向到原始长链接POST 接口负责生成短链GET 接口负责重定向。重定向用 302 而不用 301是为了让每次访问都请求短链服务便于做访问统计和数据上报。如果是纯跳转场景不在乎数据才考虑 301。数据模型我设计得尽量简单CREATE TABLE short_links ( id BIGINT AUTO_INCREMENT PRIMARY KEY, short_code VARCHAR(16) NOT NULL UNIQUE, original_url VARCHAR(2048) NOT NULL, expire_at DATETIME DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_expire_at (expire_at) ) ENGINE InnoDB;表结构隐含了几个设计决策short_code 有唯一索引保证一个短码只映射一个长链接expire_at 允许为空表示永久链接每天定期任务扫描过期数据并清理。字段不复杂但每一列都有存在的理由这也是我在笔记里强调的原则能说清每一行代码、每一个字段的用途才说明你真的在掌控这个设计。3.4 核心流程与高并发优化别让短码生成成为瓶颈短链接服务最容易被忽视的就是短码生成环节。最简单的方案是直接用原始长链接做哈希取一部分作为短码但哈希碰撞需要处理而且短码的不可预测性比较差。更可靠的方案是发号器模式。我实际推荐的流程是用一个 Redis INCR 或者数据库自增发号器拿到一个全局唯一的数字 ID然后把这个 ID 转成 62 进制得到短码。转出来的短码是唯一的而且不需要额外查重。用户请求量大时发号器会成为瓶颈我的解法是每次申请一批 ID 段比如一次拿 10000 个号发完再去取这样数据库或 Redis 的压力可以降低很多。高并发访问环节读路径要加缓存并在缓存失效时使用互斥锁保护数据库。更狠一点可以再加一个布隆过滤器拦截不存在的短码请求防止恶意的随机探测把数据库打穿。我在笔记里画过一个核心流程伪代码面试时我会直接默写这一段比单纯描述更清晰生成短码流程 1. 校验长链接格式过滤非法域名 2. 查布隆过滤器/缓存若短码已存在则直接返回 3. 从发号器批量获取数字 ID 4. ID 转 62 进制生成短码 5. 写数据库同步写缓存 6. 返回短链接 跳转短码流程 1. 解析路径拿到 shortCode 2. 查缓存命中则返回 302 3. 未命中查布隆过滤器不存在直接返回 404 4. 查数据库存在则回填缓存不存在则返回 404 5. 异步上报访问日志这套流程解决了并发创建、缓存穿透、恶意请求三个问题。关键是每一条都有明确的目的不是“为了复杂而复杂”。我在笔记里把这套模板标记为“通用高性能读写路径模板”后来在设计短链、分享口令、文件上传等场景时基本都能复用。3.5 瓶颈复盘没有完美的设计只有合适的取舍写完主流程后我还会强制自己在笔记末尾加一段“瓶颈与取舍”这是整个 system-design-notes 里最有价值的习惯。短链接服务的取舍点有很多发号器方案下短码不可预测性差容易被顺序遍历所以需要配合布隆过滤器或权限校验来防止数据泄漏数据库自增虽然有性能瓶颈但通过批量取号可以缓解过期链接的清理如果做太频繁会浪费资源做太少又浪费存储。这些取舍没有标准答案关键看场景。我通常用一张表格记录每个方案的优缺点和代价方案优点缺点我的结论哈希取短码实现简单、无需发号器碰撞处理麻烦、长度不固定不适合大规模场景发号器转进制全局唯一、性能高可预测需防遍历推荐主方案预生成短码并发无压力浪费存储、可预测适合特定场景备用这一段是复盘的核心也是面试中拉开差距的地方。很多人能画出一个完整的架构图但讲不出“哪里可能出问题、出了问题怎么降级”面试官自然不会给出高评价。我做笔记时要求自己每个案例至少写三条瓶颈和三条优化方向长期积累下来方案设计能力会明显比同龄人强。4. 笔记里记下的高频翻车现场与排查思路4.1 缓存穿透、击穿、雪崩看着像其实完全不一样这一节算是我踩坑的真实记录。我曾经维护过一个活动页服务某天晚上监控突然报警数据库连接数持续上涨看起来是缓存雪崩最后排查下来是典型的缓存穿透一大批恶意脚本在遍历不存在的商品 ID每个请求都绕过缓存直接打到数据库。区分这三个问题需要看监控和请求量特征穿透的请求经常集中在一批固定且不存在的 key 上用布隆过滤器拦截即可击穿则通常表现为某个热点 key 失效后单接口响应时间瞬间飙高可以用互斥锁或逻辑过期解决雪崩的影响面大整个系统的读写都在变慢多半需要从过期时间配置和降级逻辑上修复。我在笔记里给自己定了一条纪律线上排查缓存问题先看请求日志分布再看 DB QPS 曲线最后才动缓存配置绝对不要一上来就清缓存。清缓存是万不得已的手段因为对热点 key 来说清掉缓存等于亲手制造一次击穿。4.2 消息积压了别一上来就想扩容消息积压几乎是每个用 MQ 的系统都会遇到的问题。我的排查习惯是先把消费者指标拉出来看消费速率是否明显低于生产速率。如果是再细分是消费者实例太少、消费逻辑卡在外部 RPC还是死信重试导致消费卡死。很多时候消息积压的根因是某条消息的数据格式异常消费者反序列化失败后一直重试把整个队列卡住。我在笔记里记录过一个经典案例上游字段从 int 改成了 string消费者没来得及同步结果一条脏数据让消费线程反复崩溃消息越堆越多。解决办法也很简单重试超过一定次数就投递到死信队列人工或者单独脚本去处理。扩容虽然是标准操作但成本高、治标不治本。更优先的排查思路是先看消费者日志有没有反复报错再看有没有单条消息处理特别慢的情况最后才是增加并发或者批量消费。我在笔记的“消息队列排查清单”里把这些步骤列成了表格每次遇到类似问题直接照着排查效率比临时想高很多。4.3 数据不一致的定位与规避缓存更新顺序别写反缓存和数据库的一致性是分布式系统里永恒的痛。最经典的问题是更新顺序有人先更新数据库再删缓存有人先删缓存再更新数据库到底哪个对我的笔记里记录了两种方案各自的风险。先更新数据库再删缓存在极端情况下可能出现删除缓存前有其他线程读到旧缓存但时间窗口很短缓存更新后自然恢复这是业界用得最多的方案。先删缓存再更新数据库则有一个更明显的问题删掉缓存后、数据库更新前有请求把旧数据读回缓存就会长期存在脏数据。所以从概率角度我更愿意选先更新数据库再删缓存同时配合订阅数据库 binlog 来异步清理缓存实现最终一致。这只是系统设计面试中一个常见追问但它检验的是你对分布式系统里“一致性代价”的理解。我的笔记里给了自己一个提醒不要追求绝对的一致先想清楚业务能不能接受秒级延迟。能接受就用最终一致的方案不能接受就要考虑事务消息、分布式锁甚至本地消息表复杂度会呈指数上升。4.4 容量估算翻车案例估少了真的会出事最后记录一个容量估算翻车的教训。那次是给某个活动做方案预估并发 2 万实际开场半小时峰值冲到 8 万结果数据库连接池被打满活动页大面积超时。事后复盘发现预估时只按平均在线用户算忽略了分享裂变带来的指数级传播效应。从此我的笔记里多了一条规则估算时要区分均值、峰值和突发峰值并且在线业务要加入“放大系数”。通常我会用峰值 QPS 等于平均 QPS 乘上 5 到 10 倍的系数具体看业务类型。活动类、社交分享类都要按偏高的系数来算后台管理系统按偏低系数也可以接受。容量估算不是考试题而是系统设计的边界条件。算得保守一点方案设计时自动会把缓存、限流、消息队列都加进去系统弹性更强算得激进方案会过度设计投入产出比很差。把每一次估算和真实流量的对比记录下来不断修正自己的“系数直觉”这比背任何公式都有用。5. 让笔记活起来一个季度回看的迭代方法5.1 从“记录”到“复盘”的转变笔记系统最难的不是开始写而是坚持迭代。很多人维护技术笔记一段时间后文件夹变成死素材库自己都不想看。我的解决办法是给自己定一个季度复盘机制每个季度挑两个案例笔记拿着最新的理解重新读一遍删掉过时的结论补充新的思考。比如早期的短链接笔记最初我只写了 Redis 缓存和 62 进制短码后来经历了真实线上流量我会补充“布隆过滤器拦截恶意请求”的经验再后来遇到短码遍历攻击又加了一层脱敏策略。同一篇笔记一季度一个版本知识和经验是叠加的而不是每次从零开始。复盘的核心不是“把笔记改得更好看”而是逼自己回答三个问题这个方案里哪些决策是被证明有效的哪些环节出了本以为不会出的问题如果重新设计我会在哪里做不同的选择这三个问题回答下来哪怕笔记没有任何改动思考深度也会有明显提升。5.2 一套适合回看的笔记目录和标记法为了让回看更高效我用了一套简单的状态标记写在不同文件的顶部状态: 已实践 / 待验证 / 需复习 难度: ★★☆ 上次复盘: 2025-01-15状态分类能让我优先处理“需复习”的笔记而不是每次打开都从头到尾刷一遍。已经实践过的笔记是复习重点因为里面有很多真实踩坑记录待验证的笔记说明当时只是纸上谈兵后面如果遇到真实场景要特别小心需复习的笔记则是快遗忘或者理解还不透彻的部分。这套标记法的精神是笔记不是收藏夹不是“存了就安心”它是给自己的知识体系建立索引。面试前我不会从头到尾翻一遍而是只看标记为“需复习”和“已实践”的笔记效率比之前高好几倍。5.3 几个我后来觉得“早点知道就好了”的经验最后分享几条我自己整理 system-design-notes 过程中的体会希望能帮你少走弯路。第一笔记里一定要有图但不一定非要用复杂工具。我早期的笔记纯文字回看时经常忘记设计结构。后来在关键流程里补上简单的框图或者序列描述哪怕只是用纯文本画出数据流向记忆效率也高很多。面试时能现场在白板快速画图也是靠平时练习的。第二每条笔记至少写下一个“如果是我来设计我会怎么简化”。这条心得来自一次面试官的反问“如果这个系统只有你一个人维护你会砍掉哪些组件”当时我愣住了因为我一直在做加法从来没想过做减法。从那以后每篇笔记的末尾都会有一个“极简版本”小节逼自己想清楚哪些组件是核心哪些只是为极端场景服务的增强功能。第三定期用自己的话把同一种设计模式讲给不同的人听。我经常拿短链接服务给完全不懂技术的朋友讲讲通了说明理解到位了讲不通说明有些概念我还在背没有真正掌握。能给别人讲明白才是真懂这也是我把这套笔记命名为 system-design-notes 的初衷。6. 关于这套笔记的配套练习建议6.1 每天 30 分钟的刻意练习方式强度比时长重要有一段时间我坚持每天只练 30 分钟但效果很好。方法是从 02_components 里随机抽一个组件再随机抽一个场景逼自己在 30 分钟内给出设计方案。比如抽到“缓存”和“排行榜”或者“消息队列”和“订单超时关闭”看起来很简单但真到限时输出时就会暴露很多理解模糊的地方。我会打开手机录音边讲边录时间到了之后回听把自己卡壳的地方在笔记本上记下来。这种刻意练习的核心不是“重复”而是“在反馈中修正”。听自己的录音很尴尬但真的能发现自己哪里在背概念、哪里在堆术语、哪里逻辑不通顺。这个习惯我保持了三个月面试时的表达流畅度提升非常明显。6.2 经典题目练习顺序的前后逻辑市面上有大量系统设计题库但练习顺序很重要。我的笔记里给了一个从易到难的推荐顺序实际执行下来很稳短链接服务 - 新闻订阅 feed - 聊天系统 - 电商秒杀 - 地理位置服务短链服务帮你把基础流程、缓存、发号器练熟新闻订阅开始涉及推拉模式选择、延迟与实时性的权衡聊天系统要处理长连接、消息顺序、多端同步秒杀系统研究突发流量、限流、库存一致性地理位置服务要把空间索引、数据分片练到位。每做完一题要把新的经验和组件认知回填到 02_components 的对应文件里这样练到后面组件笔记也会跟着变厚。6.3 面试前三天只看这四页纸我现在面试前三天基本不刷题了只看四页纸需求澄清问题清单、容量估算公式和常用数字、组件选型速查表、上次面试的复盘记录。这四页纸都在我的 system-design-notes 里有对应文件。需求澄清清单让我拿到题目后能迅速进入状态容量估算公式复用性强面试中能快速给出可信的数字组件选型速查表帮我避免在压力下发散复盘记录则提醒我上次哪里讲砸了这次现场要特别留意。准备到这个程度面试时心态会稳很多因为你清楚自己不是裸考背后的一套体系不是临时突击能替代的。个人体会是系统设计能力的核心不在于你知道多少组件和方案而在于面对不确定问题时你能不能快速拆解、合理取舍、清晰表达。持续更新自己的 system design 笔记本质上是在训练这套思维习惯。时间花在笔记里面试时和实际项目里都会慢慢还回来。