系统设计笔记实战指南：从核心范式到面试速查

先说个实在话：system design是很多后端工程师和架构师绕不开的坎，面试要考、晋升要讲、做新项目要出方案。但网上资料多到爆炸，今天收藏一份《设计一个秒杀系统》，明天存一篇《分布式缓存详解》，真到开口讲的时候，脑子里还是一团乱麻。

我花了大半年时间整理了一套自己的system-design-notes，从零散的收藏夹变成了一套有目录、有范式、有案例的知识库。这套笔记不是给别人看的漂亮文档，是我自己反复查、反复改、用来查漏补缺的私有沉淀。这篇文章把整个搭建思路、核心内容框架和实操方法一次说透，给正在啃系统设计的人一条可以直接照搬的路径。内容适合准备架构师面试的工程师、需要独立做技术方案的开发同学，也适合刚接触后端设计、想建立全局视野的初学者。

1. 笔记项目概述与整体架构思路

1.1 系统设计笔记和收藏夹不是一回事

很多人对“笔记”有误解，觉得把文章存到收藏夹、加到书签里就算记笔记了。但收藏夹是一个纯输入型的东西，只进不出，时间一长连自己都懒得翻。真正的系统设计笔记，核心价值在于输出：你用自己的话把复杂概念重新表达一遍，把不同系统的共性抽出来，把踩过的坑和想过的取舍写下来，这个过程才是学习真正发生的时刻。

我建的这套 system-design-notes，定位是一份“能回答问题的笔记”。每篇内容都围绕一个具体问题展开，比如“如何支撑 10 万 QPS 的商品详情页”“如何保证订单系统不丢数据”“如何做平滑扩容”。拿到这个题目，我要能讲清楚这套系统的核心链路、核心数据结构和关键瓶颈。如果不能，说明这个知识点还没吃透，需要继续补充。

1.2 笔记的三条主线：可扩展性、可靠性、性能

翻开任何一本系统设计教材，或者任何一家大厂的架构师面经，你都会发现核心关注点逃不出三个大词：可扩展性、可靠性、性能。我搭笔记框架时，直接把这三条作为主线，所有案例和笔记都归到这三个维度下，保证知识不会一盘散沙。

可扩展性关注的是“系统能不能扛住增长”。用户量翻倍、数据量翻倍、请求量翻倍，你的系统是加机器就完事，还是要推翻重建？涉及的核心概念包括水平扩展、垂直扩展、分片、无状态设计等。可靠性关注的是“系统能不能不出错”。宕机了怎么办、数据丢了怎么办、部分服务不可用了怎么办？涉及冗余设计、故障转移、备份恢复、幂等重试等。性能关注的是“系统能不能跑得快”。延迟能不能降下来、吞吐能不能提上去，缓存、索引、连接池、异步化都是这里的常客。

三条主线之下，再往下细分就是各种具体场景。我建议你也用这种树状结构组织笔记，而不是按时间线平铺。好处是复习的时候脑子里有地图，遇到新的知识点可以直接挂到对应的分枝上，知识越攒越有体系，而不是越攒越乱。

1.3 从一百篇散装资料到一套核心笔记的整理流程

我说一下实际整理的步骤，真的很粗暴，但有效。

第一步，把所有收藏的资料导出来，统一放到一个目录里，全格式转成 Markdown 或 PDF。第二步，通读一遍，用标签给每篇归类，标签就按上面的三条主线加场景类型来定，比如“缓存”“消息队列”“分布式事务”“秒杀”“feed流”。第三步，把多篇讲同一主题的文章合并，提炼出共同点和你个人觉得有启发的内容，写成一份自己的笔记，不要复制粘贴大段原话，理解为前提。第四步，每次做完一个真实项目、每次面完试、每次看到有价值的新文章，回来更新对应笔记，该改的改，该删的删。

这套流程走完，你留下的不是几百篇吃灰文章，而是几十篇言之有物、结构清晰、自己真正理解的笔记。这就是 system-design-notes 的精髓：从做加法变成做减法，从堆量变成提纯。

2. 核心范式拆解：系统设计里反复出现的十个模型

2.1 高并发读取：缓存与读多写少的解法

绝大多数系统第一个遇到的问题是读多写少。我笔记里统计过，很多互联网产品读写比例是 10:1 甚至 100:1。如果所有读请求都打到数据库上，数据库扛不住，加机器又很贵。这时候缓存是最直接的手段。

缓存可以分好几层。客户端缓存（比如浏览器本地缓存）、CDN 缓存（静态资源加速）、应用本地缓存（如 Guava Cache、Caffeine）、分布式缓存（如 Redis）。每一层解决不同距离的读请求，命中率越高，后端压力越小。

我在笔记里画过一条查询链路，这是最基本的套路：请求先到 CDN，没命中到 Nginx，再到应用本地缓存，再到 Redis，最后落数据库，逐层回源。缓存的关键参数是过期时间、缓存穿透、缓存击穿和缓存雪崩，这几个坑非常经典。

• 缓存穿透：查一个不存在的数据，缓存和数据库都没有，每次请求都打到 DB。解决方法是缓存空值或布隆过滤器。
• 缓存击穿：某个热点 key 过期瞬间有大量请求打到 DB。解决方法是互斥锁重建缓存或者逻辑过期。
• 缓存雪崩：大量 key 同时过期或 Redis 宕机，请求全部压向 DB。解决方法是过期时间加随机值、集群高可用、多级缓存兜底。

这些内容纸上谈兵很容易，真到上线跑流量的时候才会发现自己漏配置了多少细节。我看过太多缓存方案里只写了“加一层 Redis”，但完全没有想过热点 key 的分布策略和过期策略，最后线上出问题再临时补救。

2.2 写入扩展：消息队列、异步化与最终一致性

读路径用缓存挡住之后，写路径又成了瓶颈。用户点一下按钮，后台可能要写好几种数据，这单要落订单库、扣库存、发优惠券、通知物流、记录日志，如果全部同步执行，接口延迟直接爆炸。

消息队列在这里承担的职责是削峰填谷和异步解耦。同步调用的方式就像是食堂里只有一个打菜窗口，所有人都挤在窗口前等着。引入消息队列之后，用户请求只需要把消息丢进队列，后端消费者根据自己的能力慢慢处理，高峰期先积压，低谷期再消费，系统整体吞吐反而是提升的。

选型上主流的是 Kafka、RocketMQ、RabbitMQ。Kafka 吞吐高、适合日志和流处理场景；RocketMQ 功能更丰富、事务消息和延迟消息做得更顺手；RabbitMQ 老牌稳定、但吞吐吞吐不是它的强项。我记得当时给自己笔记里建过一个对比表，把几个队列的延迟、吞吐、消息可靠性、社区活跃度都列出来，面试被问到的时候直接讲一张表，比临时组织语言好得多。

但异步化也带来了一个必须处理的问题：最终一致性。不同系统之间数据不再实时同步，如果 A 系统成功了 B 系统失败，账就对不上。业界常见方案是本地消息表加定时任务扫描、事务消息、或者是基于 Binlog 的同步方案。哪个方案都有代价，没有万能的银弹。

2.3 海量存储：分库分表与存储引擎选型

读和写都优化之后，我们还会面临数据量的问题。单表过千万、过亿之后，再怎么加索引，MySQL 的 B+ 树深了、磁盘 IO 多了，查询性能也会退化。这时候必须分库分表。

分库分表最常用的是水平拆分，把一个表按某个字段的哈希值或范围分布到多个库多张表。ShardingKey 怎么选是关键，因为它是所有查询的入口。我踩过的亲身教训是：一开始选错了分片键，业务发展起来之后迁移代价巨大，真的是牵一发动全身。

存储引擎选型这块，很多初学者只知道 MySQL、Redis，但对 HBase、Cassandra、ClickHouse、Elasticsearch 这些各擅胜场的系统完全没有概念。我的笔记里给它们分了类：OLTP 强事务选 MySQL、PG；高并发 KV 场景选 Redis；海量写多读少、按 rowkey 查的选 HBase；海量日志分析选 ClickHouse；全文检索场景选 Elasticsearch。素材來源可以看官方文档、对比博客和自己上线后的监控数据，没事多记两笔。

2.4 高可用设计：冗余、故障转移与容灾

系统设计如果只讲“怎么把性能做上去”，不讲“挂了之后怎么办”，那这个设计是不完备的。高可用设计有自己的经典套路，核心思路就是冗余加故障转移。

应用服务器挂了怎么办？前面加负载均衡，多部署几台无状态节点，挂了一个流量分给其他节点。数据库挂了怎么办？做主从复制加自动故障切换，主库出问题从库顶上。多机房之间呢？做多活架构，至少保证同城双活或异地多活。

笔记里关于高可用有一页我反复翻：健康检查与摘流。负载均衡定期探测后端节点的健康状态，不健康的节点自动摘出，这个逻辑看着简单，但真正实施时有很多细节。比如健康检查发起频率太低，后端 5 分钟前就挂了，这个期间用户请求已经有一堆报错；频率太高，后端压力反而增加了。探活接口返回的是应用状态还是服务器整体状态，也值得你专门写一页笔记。

2.5 性能优化：连接池、索引与热点优化

系统设计的很多调优，本质是在“资源有限”这个前提下，想办法榨干每个资源的性能。数据库连接池就是典型：每个数据库连接都是有代价的，建连、认证、销毁都很贵，直接用连接池复用连接，可以显著降低开销。连接池大小也不是越大越好，很多新手以为连接越多越快，结果连接数设置过高，数据库上下文切换压力剧增，延迟不降反升。

索引优化也是老生常谈。我自己的笔记里专门记了一页“索引失效场景速查表”，把最常踩的坑挑出来：前导模糊查询用了导致索引不可用、函数用在索引列上、隐式类型转换导致失效、OR 条件有一侧没有索引。每一行我都配了实际 SQL 和 explain 输出，这样比看一百篇理论文章有效得多。

热点优化更偏实战一点。比如某个秒杀商品在同一时刻被几万人请求，单 Redis key 也会成为瓶颈。常规做法是把这个 key 拆成多个副本，分散到不同节点上，请求随机访问任意副本。这个方案有数据一致性的代价，需要在笔记里把 trade-off 写清楚。

2.6 搜索与推荐：倒排索引、召回排序与向量检索

很多系统到了后期会接入搜索和推荐，这也是 system design 的一个常考模块。搜索引擎的核心数据结构是倒排索引——从词到文档的映射，让“包含某词”的查询变得极其高效。ES 内部就是维护了这样的索引结构。

搜索的过程是：用户输入 query，先做分词和意图识别，再到倒排索引中召回候选文章，最后经过相关度排序把结果返回给用户。召回和排序是两步，很多人混着说，其实它们在技术栈上完全不一样。召回讲的是“快和全”，宁可多也不要漏；排序讲的是“准”，要综合 BM25、点击率、业务规则等做精排。

现在很多系统还加了向量检索，把文字、图片、商品转化成 embedding 向量，再通过 ANN 算法做近似最近邻查找。这块涉及的内容越来越深，我目前只在笔记里留了框架层面的内容，等有更多实战再补充细枝末节。做笔记的方式就是允许自己有空白区域，不要一上来就想万事俱备。

2.7 数据分析链路：离线数仓与实时流计算

现代系统不只是在线服务，还有大量数据分析需求：报表、大屏、用户行为分析、异常监控。这就要讲到离线链路和实时链路。

离线链路通常是业务数据库通过同步工具（比如 Canal）把 binlog 打到 Kafka，再由 ETL 任务写入数仓的 ODS、DWD、ADS 分层，任务跑批生成报表。实时链路则直接用 Flink 消费 Kafka 数据流，做窗口计算，把结果写进 OLAP 引擎或 Redis，供实时大屏查询。

这块的系统设计笔记，我特别关注两件事。第一，数据口径一致性，离线报表和实时报表数字差多少？对不上账怎么跟业务方解释？第二，链路延迟指标，离线的容忍度高，实时要求秒级，中间的资源成本和方案取舍完全不同。写笔记时把这些场景和原因说清楚，比背一堆工具名有用。

2.8 消息通信与 RPC 框架：服务间通信的骨架

微服务化之后，服务与服务之间的通信就是系统的骨架。同步 RPC 和异步消息是两条主线。RPC 框架上，Java 生态最常用的 Dubbo、Spring Cloud 微服务全家桶，跨语言的又大多是 gRPC，底层 HTTP/2 加 Protobuf 序列化。

笔记里我拆过一次 RPC 调用的完整链路，自己的服务里往往都会遇到：服务发现、负载均衡、序列化、网络传输、超时控制、熔断降级。服务发现是从注册中心拿提供方节点列表；路由规则是选哪个节点，权重怎么算；超时如果处理不好，一次慢调用把线程池占满，整个服务就雪崩了，所以需要熔断器和线程池隔离。我把这套链路当成一个固定剧本，每次面试讲通信模块都按这个顺序讲，逻辑特别完整。

2.9 分布式事务：BASE 理论与最终一致性的落地

传统单体应用里的事务靠数据库的 ACID 保证，但在微服务架构下，一个业务跨越多个服务和多个数据库，怎么保证一致性就成了大难题。强一致的方案有 2PC、3PC、TCC，但性能代价大、工程复杂度高，大多数业务场景用不到，因为业务并没有那么高的严格一致性要求。

业界更普遍的是 BASE 理论的思路：允许系统处于短暂的不一致状态，但通过补偿和重试达到最终一致。具体落地手段包括本地消息表、事务消息、定时对账、状态机补偿等。我在笔记里把“本地消息表”这个方案画过好几次：业务操作和写消息放同一个本地事务里，然后再异步投递消息、消费消息，失败就重试。尽管理论陈旧，但它非常实用，我现在很多生产项目里仍在用这个模式，因为稳。

2.10 多区域部署与全球化：异地多活与数据同步

最后聊一下多区域，业务做大之后可能会部署在多个地域，这时候要面对的挑战是：用户离机房远延迟高、不同地域的数据同步不实时、整体系统的容灾能力要求更上一层。

异地多活常用两种模式。一种是同城双活，两台机房在一个城市，距离近，网络延迟低，数据库同步可以用较为接近同步的方式，适合大多数要求高可用的企业。一种是异地多活，两个机房可能隔了几百上千公里，网络延迟决定了两地数据同步做不到强一致，只能做最终一致，所以设计上尽量按用户维度分片路由，让用户请求固定在同一个地域处理，避免跨地域的实时数据依赖。

这部分笔记是我参考了一些公开的技术分享和书籍后整理的，虽然自己没亲手搭过跨洲际的异地多活，但把思路、难点、代价整理成册，还是让眼界开阔了不少。

3. 笔记积累方法：让知识越用越多、越用越顺

3.1 如何从架构文章、源码和线上故障里采集素材

系统设计笔记最大的问题不是内容太少，而是素材太多，不知道怎么选、怎么留。我现在的采集方法遵循“价值密度”原则。一篇资料必须满足下面至少一条，才值得留存：有明确的架构图和链路图；有具体的数字，比如量级、延迟、成本；有踩坑和回滚经历；有性能对比或选型依据。

架构文章我一般从 InfoQ、美团技术团队、腾讯云开发者社区这些平台找，质量相对高。源码素材方面，我更推荐直接看开源项目的 issue 和 pull request，很多讨论非常接地气，比看注释学得多。线上故障是最宝贵的素材，每次复盘都要写清现象、定位过程、根因、修复方案和后续预防。我在笔记里把“故障复盘”单独建了个目录，里面的知识都是真金白银换来的。

3.2 不求一次成稿：笔记的迭代与复盘节奏

我在整理笔记时给自己定了一个规则：第一版永远是烂的。第一次写出来的笔记往往只有骨架，前后逻辑不顺，例子也不完整。这没关系，关键是先建起来，然后再迭代。

每周花一两个小时专门复盘本周新增或修改过的笔记，肯定会发现一些可以补充的地方：这篇文章又有新案例了、这个方案上线后暴露了新的性能问题、有人留言指出了我理解错的点。把这些内容逐步更新进去，笔记才会越用越厚。

这里有个小技巧，我每篇笔记顶部都维护三个字段：最近更新时间、适用场景、一句话结论。这样一眼扫过去就知道这篇笔记大概讲什么、适不适合当前问题。

3.3 个人认为最有价值的几个笔记板块

整套 system-design-notes 里，我觉得沉淀价值最大的是这些板块，如果你现在开始建，建议优先做起来：

• 架构模式速查：一页纸讲清楚一种模式，比如读写分离、CQRS、事件溯源、Strangler Fig。每页固定模板：定义、适用场景、不适用场景、核心组件、典型开源实现。
• 容量估算模板：用 QPS、存储量、带宽三个维度套公式，快速给出一套设计目标数字。面试和实际设计都能用。
• 真实案例复盘：记录你在工作中实际做过的系统改造、性能优化、故障排查，这是别人拿不走的东西。
• 常用面试题清单：把遇到的、看到的高频系统设计题整理成清单，每道题标注考察点和解法关键词，方便快速过知识点。

4. 实操过程：如何把我这套笔记体系落地到自己身上

4.1 开始之前必看的三个自问

在动手建笔记前，我建议你先回答三个问题，想不清楚大概率坚持不下来。

第一，你为什么需要系统设计笔记？是为了面试突击、为了做技术方案时有参考，还是为了带团队时能讲清楚架构演进路线？不同的目标导向会决定笔记的侧重点。第二，你目前的技术栈偏向哪些方向？后端、前端还是数据？笔记不可能覆盖所有领域，聚焦在自己相关或者想转型的领域才有效率。第三，你能投入多少时间？每天 30 分钟和每周五个小时，笔记的深度和节奏完全不一样。

我自己最初的初心很简单：每次准备系统设计题都要从零开始搜资料，太累了，想把知识变成复用资产。这个驱动力支撑我坚持到了现在。

4.2 目录结构和工具选型建议

笔记工具的选择其实没有标准答案，我用过很多款，最后确定了支持本地 Markdown 的方式。我的 system-design-notes 目录结构大致是这样的：

system-design-notes/ ├── 01-基础概念/ │ ├── 水平扩展与垂直扩展.md │ ├── CAP与BASE.md │ └── 一致性哈希.md ├── 02-核心技术范式/ │ ├── 缓存.md │ ├── 消息队列.md │ ├── 分布式事务.md │ ├── 分布式锁.md │ └── 幂等设计.md ├── 03-典型场景设计/ │ ├── 短链接系统.md │ ├── 秒杀系统.md │ ├── 消息推送平台.md │ └── 订单系统.md ├── 04-真实案例复盘/ │ └── 2025年某次缓存穿透事故复盘.md └── 05-面试准备/ ├── 高频题速查.md └── 自我介绍与项目讲述模板.md

工具层面，我推荐 Obsidian 或 VS Code 加 Markdown 插件，本地方便搜、方便版本管理。数据上的安全感对笔记项目来说极其重要，能让人坚持下来。

4.3 从第一个笔记开始：完整展示一篇笔记的诞生过程

光讲思路不落地是耍流氓，我拆解一篇笔记的诞生过程。就以“秒杀系统设计”为例。

第一步，确定笔记模板：核心问题、系统规模假设、整体架构图、核心模块拆解、关键难点与解法、风险与权衡、参考链接。写标题的时候我用的是“设计一个支撑 10 万人同时在线的秒杀系统”，这比“秒杀系统设计”更具体，也更容易让对方（以及未来翻看的自己）明确边界。

第二步，写系统规模假设。预估每秒请求量、商品数量、库存量、数据量级。比如商品 SKU 数 1000 个，单 SKU 库存 100 件，瞬间峰值 QPS 可能达到 50 万。这个数字后面所有技术决策都由它驱动，不是为了炫技。

第三步，画架构草图并写模块说明。秒杀系统的特点是瞬时峰值极高、写冲突集中、读多写少但写是热点中的热点。常规流程是前端静态化 + CDN 承接大部分读请求；服务层做限流和风控；库存扣减用 Redis 的 Lua 脚本保证原子性；订单生成走消息队列异步落库。每个环节选的方案，都要在“为什么”这一栏写清楚理由。

第四步，把可能遇到的难点逐条列出来，比如超卖如何避免、库存扣减和订单创建不一致怎么办、消息积压后怎么快速扩容、刷单机器请求怎么识别。每条下面写解法并标注参考来源。

这个过程全面走下来，一篇笔记大概要两到三个小时。写完之后你会发现，一个系统设计问题的复杂度远比你想象的高，但结构也远比想象中清晰。

4.4 面试前如何用笔记快速过一轮系统设计

当你用笔记复习到一定程度，可以考虑用“刷题”的方式练输出。我自己常用的方法是一个问题按 40 分钟计时练：前 5 分钟确认需求和数据规模，10 分钟画高层架构，15 分钟深入一个核心模块，5 分钟总结权衡和风险点。

在正式面试前，可以专门拿出一两天把笔记里高频场景对着镜子自我讲解。讲到卡壳的地方，就是笔记没记透的地方，回来补充接着讲。反复几轮下来，内容会烂熟于心。你想啊，CV 里写“熟悉分布式系统设计”，如果连“设计一个短链接系统”的流量预估都说不出来，印象分就直接清零了。但你有体系化的笔记在手，讲任何一种场景都能结构分明、进退有据，这个差距面试官一眼就能看出。

4.5 用表格追踪笔记进度，防止半途而废

建笔记最怕三分钟热度。我做了个简单的进度表，维度包括：主题、状态（草稿/已成型/已复盘）、最近修改时间、知识点数量、还有没有疑问。日常看板直接放在笔记库的 README 里，用 Markdown 表格搞定。

每次打开笔记库先看这个表，心里有数之后，学新内容也有目标感。

5. 常见问题排查与避坑技巧

5.1 目标感缺失：什么都想学，什么都记不住

系统设计领域特别大，今天学消息队列、明天学大数据、后天学分布式数据库，如果没有主线，学到最后只是泛泛了解，任何一个都深入不下去。

我的解决方法是：以场景带动学习，而不是以知识点带动学习。选定一个目标系统，比如“我要彻底搞懂秒杀系统的设计”，然后把这套系统涉及的所有知识点学一遍，学完马上在笔记里产出成果。这样每次学习都能落在一个具体的整体方案上，知识之间也有了联系。

5.2 只收集案例而不咀嚼，导致笔记变成搬运工

这是最普遍的问题。看到一篇好文就直接全文复制进笔记里，看着很厚一叠，其实根本没有消化。我有段时间也是这样的，后来逼自己每个主题最多只能摘录三到五句话，剩下的必须用自己的语言写。写不出来的地方，就是还没理解的地方，需要再回去读原文或查资料。这个“逼自己”的过程很难受，但确实是提升理解力的唯一路径。

5.3 只会一种方案，不会讲 trade-off

面试或做方案的时候，猛然被问到“你觉得这个方案有什么缺点”“如果数据量再大十倍怎么办”，如果笔记里只记录了单一方案的优点，就会立刻卡壳。

为了避免这种情况，我的笔记模板里强制要求写“权衡与风险”一节，每种方案至少列出两个缺点、一个适用边界。比如 Redis 缓存大大提速，但缓存与数据库双写会有一致性问题；Caffeine 本地缓存性能极佳，但在多实例部署下缓存漂移难以管理；消息队列削峰好用，但链路变长、问题定位难度增加。只有把这些都写出来，才是系统设计的正确姿势。

5.4 记了但不会应用，面试时暴露原形

笔记是输入，说起来是输出，两者差距很大。更糟的是很多人在面试前只做输入不做输出，看了无数资料，一到设计题就说不清楚。解决办法就一个：多说多练。先对着笔记说，再找朋友模拟面试，最后去真实环境中检验。

5.5 常见的效率陷阱和分心源

建造这个笔记期间，最大的阻力其实是“学习的诱惑”。今天看到一个讲解 Kafka 性能优化的文章，明天看到一个讲 Kubernetes 部署的视频，都非常精彩、非常有启发，但如果你想学的是系统设计，就很容易被卷走注意力。

我的对策是在笔记库根目录放一个“稍后再说”文件，遇到感兴趣但不是当前主线的素材，先记到里面，攒够一批再决定要不要处理。很多文章放了两周之后你回头再看，会觉得已经没有当初那么心动了，直接删掉，省下大量时间。

5.6 我踩过最深的坑：试图在笔记里复刻整套业务系统

刚建笔记时，我曾经雄心壮志想把笔记做成一份完整的“企业架构白皮书”，每个模块都做深，每个系统都做透。后来发现这个想法完全不可持续，因为系统设计的知识点是无穷的，而个人精力有限。笔记的目的是“够用就好”，解决当前这些问题所需的知识闭环，再多就是边际收益递减。我现在只保留高复用、高频率的核心内容，冷门细节宁缺毋滥。

5.7 系统设计常见问题速查表

这里把我在学习和面试中碰到的高频问题整理成一个速查表，方便大家按图索骥：

这套速查表不是一次性做出来的，是随着笔记迭代慢慢长出来的，每次遇到新题就在里面挂一个新行。以后只要有类似问题，翻表就能找到对应的笔记和思路。

最后再分享一个小技巧：给自己的笔记加上“下一步计划”字段。每篇笔记写完时我都写上接下来还想补充哪些点，比如“下次补充 Redis 集群扩容对缓存命中率的影响的具体案例”。这个字段让笔记变成了有生命力的待办清单，而不是一锤子买卖。真正的成长不是资料越来越多，而是每一份资料都化成了你脑子里的思维模型。希望这套 system-design-notes 的方法，能让你在系统设计的路上少走一些弯路。