先说个实在话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 表格搞定。主题状态最近修改关键知识点备注缓存已成型2025-11-02穿透、击穿、雪崩、一致性参考美团技术博客消息队列草稿2025-10-20Kafka 和 RocketMQ 对比还差延迟测试数据秒杀系统已复盘2025-11-09Redis Lua、限流、队列削峰面试挂了三次才吃透每次打开笔记库先看这个表心里有数之后学新内容也有目标感。5. 常见问题排查与避坑技巧5.1 目标感缺失什么都想学什么都记不住系统设计领域特别大今天学消息队列、明天学大数据、后天学分布式数据库如果没有主线学到最后只是泛泛了解任何一个都深入不下去。我的解决方法是以场景带动学习而不是以知识点带动学习。选定一个目标系统比如“我要彻底搞懂秒杀系统的设计”然后把这套系统涉及的所有知识点学一遍学完马上在笔记里产出成果。这样每次学习都能落在一个具体的整体方案上知识之间也有了联系。5.2 只收集案例而不咀嚼导致笔记变成搬运工这是最普遍的问题。看到一篇好文就直接全文复制进笔记里看着很厚一叠其实根本没有消化。我有段时间也是这样的后来逼自己每个主题最多只能摘录三到五句话剩下的必须用自己的语言写。写不出来的地方就是还没理解的地方需要再回去读原文或查资料。这个“逼自己”的过程很难受但确实是提升理解力的唯一路径。5.3 只会一种方案不会讲 trade-off面试或做方案的时候猛然被问到“你觉得这个方案有什么缺点”“如果数据量再大十倍怎么办”如果笔记里只记录了单一方案的优点就会立刻卡壳。为了避免这种情况我的笔记模板里强制要求写“权衡与风险”一节每种方案至少列出两个缺点、一个适用边界。比如 Redis 缓存大大提速但缓存与数据库双写会有一致性问题Caffeine 本地缓存性能极佳但在多实例部署下缓存漂移难以管理消息队列削峰好用但链路变长、问题定位难度增加。只有把这些都写出来才是系统设计的正确姿势。5.4 记了但不会应用面试时暴露原形笔记是输入说起来是输出两者差距很大。更糟的是很多人在面试前只做输入不做输出看了无数资料一到设计题就说不清楚。解决办法就一个多说多练。先对着笔记说再找朋友模拟面试最后去真实环境中检验。5.5 常见的效率陷阱和分心源建造这个笔记期间最大的阻力其实是“学习的诱惑”。今天看到一个讲解 Kafka 性能优化的文章明天看到一个讲 Kubernetes 部署的视频都非常精彩、非常有启发但如果你想学的是系统设计就很容易被卷走注意力。我的对策是在笔记库根目录放一个“稍后再说”文件遇到感兴趣但不是当前主线的素材先记到里面攒够一批再决定要不要处理。很多文章放了两周之后你回头再看会觉得已经没有当初那么心动了直接删掉省下大量时间。5.6 我踩过最深的坑试图在笔记里复刻整套业务系统刚建笔记时我曾经雄心壮志想把笔记做成一份完整的“企业架构白皮书”每个模块都做深每个系统都做透。后来发现这个想法完全不可持续因为系统设计的知识点是无穷的而个人精力有限。笔记的目的是“够用就好”解决当前这些问题所需的知识闭环再多就是边际收益递减。我现在只保留高复用、高频率的核心内容冷门细节宁缺毋滥。5.7 系统设计常见问题速查表这里把我在学习和面试中碰到的高频问题整理成一个速查表方便大家按图索骥高频问题核心解法关键词我的笔记位置数据库扛不住读压力缓存、读写分离、CDN02-核心技术范式/缓存.md数据库扛不住写压力分库分表、消息队列异步化02-核心技术范式/消息队列.md扣减库存不超卖Redis Lua 脚本、乐观锁03-典型场景设计/秒杀系统.md接口偶发超时超时重试、熔断降级、线程池隔离02-核心技术范式/高可用.md分布式环境生成唯一 IDSnowflake、号段模式02-核心技术范式/分布式ID.md服务间数据不一致本地消息表、事务消息、对账02-核心技术范式/分布式事务.md热 key 打爆缓存节点key 分片、多级缓存、热点识别02-核心技术范式/缓存.md这套速查表不是一次性做出来的是随着笔记迭代慢慢长出来的每次遇到新题就在里面挂一个新行。以后只要有类似问题翻表就能找到对应的笔记和思路。最后再分享一个小技巧给自己的笔记加上“下一步计划”字段。每篇笔记写完时我都写上接下来还想补充哪些点比如“下次补充 Redis 集群扩容对缓存命中率的影响的具体案例”。这个字段让笔记变成了有生命力的待办清单而不是一锤子买卖。真正的成长不是资料越来越多而是每一份资料都化成了你脑子里的思维模型。希望这套 system-design-notes 的方法能让你在系统设计的路上少走一些弯路。