系统设计这块我做了将近四年的笔记从最开始只知道背几个高频题的标准答案到后来能独立从零设计一套支撑千万级流量的业务系统中间踩过无数坑。市面上关于 system design 的资料其实不少但大多零散要么只讲单个组件要么就是一堆面试题堆砌。我今天把整理成体系的这套system-design-notes分享出来不是给你一份可以直接背的答案而是把我这几年的思考框架、做选择时的取舍逻辑、以及真正动手设计时容易忽略的细节全部掰开揉碎。这套笔记适合正在准备高级工程师面试的人、刚转岗架构方向的开发者以及想把自己手头项目升级到分布式架构、却不知道从哪里下手的后端同学。如果你只是想要一份“面经”那可以直接关掉这个页面了。但如果你想知道为什么高并发系统要这样拆、缓存和数据库的一致性问题到底怎么解、以及从单机到微服务这条路上每个环节的取舍是什么那这份笔记应该能给你足够多的启发。1. 先聊清楚一件事系统设计到底在考察什么很多人一听到系统设计脑子里立刻浮现出画架构图、堆中间件一顿操作猛如虎面试官却不买账。我最初也有这个误区以为设计一个系统就是把能想到的高端组件全部用上比如消息队列、缓存集群、分布式事务全都往架构图里塞。实际上系统设计考核的本质是决策能力。面试官想看的是你在一个信息不充分、约束条件模糊的场景下能不能通过有效的提问澄清需求做出合理的技术选型并且清晰地表达出取舍的代价。换句话说设计出一个完美的系统不重要重要的是你能不能在半小时内把一个可用、可演进、成本可控的方案讲明白。另一个容易被忽略的点是系统设计和平时写业务代码是两码事。写代码时你需要关心实现细节但做系统设计时你更像一个城市规划师你要考虑的是路网怎么分布、哪些区域功能定位是什么、人流量峰值时段怎么办而不是某一栋楼里面水管怎么走。这就意味着你需要不断在宏观视角和微观细节之间切换而多数人偏偏栽在这个切换过程上。我见过不少候选人上来就画了一堆框和线问他这个组件解决什么问题、为什么选这个数据库完全答不上来。这种人往往基本功不差但缺一个系统的思维框架导致表达出来的内容像一团浆糊。这套笔记第一个价值就是帮你把这团浆糊理顺成一条线。还有一个非常实际的作用系统设计面试几乎是高级岗位的必考项。你需要提前建立一个属于自己的答题节奏而不是临场靠灵感发挥。也就是说你需要把设计流程练成肌肉记忆达到什么程度呢听到题目后下意识就知道第一步该问什么问题、第二步该做什么估算、什么时候开始画图。2. 我整理这套笔记时的核心框架这套笔记的主干其实就一句话任何系统设计问题都可以拆成六步走。这六步不是我发明的而是我和团队里几位资深架构师反复讨论、再结合多年实际项目经验压缩出来的通用路径。它不一定适用于所有场景但至少在你没有头绪的时候能给你一个明确的方向。第一步是明确需求也就是搞清楚我们要解决什么问题、面向什么用户、体量大概是多少。这一步看起来简单实际操作时是最容易出问题的。因为很多面试官出题时故意模糊比如只说“设计一个短链接服务”剩下全靠你主动追问你问得越细致方案就越贴合场景。第二步是估算规模包括用户量、数据量、读写比例、峰值 QPS、存储空间这些数字是你后续做技术选型的重要依据。如果你连读写比都没搞明白后边设计的缓存策略大概率是拍脑袋。第三步是定义核心 API 和数据结构这决定了系统与外部交互的方式。很多人做系统设计时忽略 API 的细粒度结果画了一堆内部组件却说不清楚请求从进来到返回结果到底经过了哪些环节。第四步是设计数据存储层包括选择 SQL 还是 NoSQL、需不需要分库分表、数据一致性要求有多高、怎么做备份和容灾。存储层往往是一个系统最脆弱也最难替换的部分所以这块需要花费最多的时间来权衡。第五步是设计核心链路和组件包括负载均衡、缓存、消息队列、搜索等中间件如何接入以及它们之间如何协作。到这一步架构图开始成型你需要考虑的不只是功能还有链路延迟、单点故障、横向扩展等实际问题。第六步是识别瓶颈和优化空间也就是说要站在演进的角度看待你的设计。系统设计永远不会一步到位第一步能跑通、能满足未来半年的预期就已经足够了最怕的是你设计了一个半年根本用不上的完美系统浪费大量人力物力。这套框架我自己用了很久几乎所有类型的系统设计问题都能套进去无论是设计一个聊天系统、一个电商订单系统还是一个数据管道平台。笔记里我也把这六步各自展开配了对应案例方便你按图索骥。3. 核心组件部分每一个高频组件我都拆开写了系统设计离不开大大小小的组件这套笔记的另一个核心板块是把常用组件拿出来单独讲包括缓存、消息队列、负载均衡、分布式 ID 生成、对象存储、CDN 等。每个组件我都从三个角度去写分别是它解决什么问题、核心原理是什么、以及选型时的注意点。3.1 缓存不是把所有数据都往 Redis 里塞缓存可能是系统设计里被提到最多的组件但也是被误解最深的组件。很多人一想到性能优化就是加缓存结果数据不一致、缓存穿透、雪崩问题一股脑全来了。缓存的核心价值是加速热点数据的读取而不是兜底整个存储层。我常用的一个判断标准是如果一个请求路径上每一次都要访问数据库才能拿到结果而结果本身又不常变化那这个数据就值得缓存。反过来如果数据实时性要求极高、更新频率极快缓存带来的复杂度可能超过收益。具体到选型Redis 是目前绝对的主流但它也不是银弹。比如你需要处理超大规模的数据而且读多写少、对持久化要求不高可能会考虑更轻量的缓存方案或者干脆用本地内存缓存来减少网络开销。我踩过一个特别典型的坑就是缓存过期时间设置不合理。之前有一个业务热点数据每分钟更新一次我设了 10 分钟的缓存结果用户看到的报表数据总是滞后很多最后被业务方投诉。后来我改成缓存过期时间错开让请求尽量均匀地回源到数据库同时引入多级缓存才彻底解决这个问题。笔记里我详细写了缓存穿透、缓存击穿、缓存雪崩这三种经典问题并且每种都配了业务场景案例和标准解法你可以直接拿去用。3.2 消息队列削峰填谷但别为了用而用消息队列这个组件在系统设计里出镜率极高。它最核心的价值是解耦和削峰比如秒杀场景下瞬时流量巨大如果所有请求都直接打到订单服务上服务肯定被打挂这时候需要一个消息队列把请求暂存下来下游服务按照自己的节奏慢慢消费。但消息队列的引入也是有代价的。首先是链路变长了一个请求从发出到最终完成中间经过了队列延迟会增加。其次是数据一致性问题变得棘手比如消息丢失了怎么办、重复消费了怎么办、消费顺序不一致怎么办。笔记里我把这些问题的解法都整理了一遍。比如为了保证消息不丢生产端要确认 Broker 已接收Broker 要持久化消费端要手动 ack还要处理消费失败后的重试逻辑。为了保证消息不重复消费消费端要做好幂等设计比如用唯一业务号去重。还有一个经常被忽略的坑是消息积压处理。之前我们一个系统出过消息堆积几千万条的事故原因很简单下游服务的一个数据库连接池配置有问题处理能力骤降。最后只能临时扩容消费者实例同时把积压的消息捞出来重放折腾了半个晚上才恢复。这个经历让我认识到引入消息队列之前一定要评估好下游的消费能力并且针对积压场景提前做好应急预案。3.3 负载均衡与网关流量入口要把控制做细负载均衡是系统设计的入门组件基本每个系统都会有。它解决的是流量分发的问题把请求均匀地打到多台后端服务器上避免单台压力过大。但它的细节非常多比如四层负载和七层负载的区别是什么、会话保持怎么做、健康检查的机制是怎样的这些都必须掌握。实际设计中我经常把负载均衡和一个更上层的组件一起考虑就是 API 网关。很多人会把 Nginx 和网关混为一谈其实它们在职责上有很大差异。Nginx 更多是承接流量入口的转发和负载均衡而网关通常还承担鉴权、限流、灰度发布、请求日志等治理功能。比如限流这块我之前有个项目在网关层做了一层分布式限流用的是令牌桶算法配合 Redis 做集中式计数。这样即使某一台网关实例挂了其他实例也能共享限流数据不会导致流量失控。笔记里我写了几种常见限流算法的区别和适用场景包括固定窗口、滑动窗口、漏桶、令牌桶并结合业务给出了选择建议。3.4 存储选型SQL、NoSQL、搜索引擎各司其职存储是系统设计的灵魂也是取舍最多的地方。关系型数据库比如 MySQL 依然是业务系统的默认选项因为事务和强一致性是很多场景的刚需金融交易、订单系统、库存扣减这些都不能接受数据不一致。但关系型数据库在数据量大了以后会遇到明显的瓶颈最直接的解决办法是分库分表。这里面的坑非常多比如分片键怎么选、查询时绕过主键怎么办、跨分片的事务怎么做每一步都需要仔细权衡。我见过一个典型的反面案例有人把订单表按照订单 ID 做了分片结果后台管理页面需要按用户 ID 查订单每次查询都要遍历所有分片性能极差。后来在订单表里冗余了用户维度用另一套索引表来支撑这个问题才得到缓解。这个案例在笔记里我有详细记录主要是想说清楚分片方案一定要带着查询场景一起设计。NoSQL 方面Redis 适合做缓存和计数器MongoDB 适合文档型数据ClickHouse 适合分析型大数据场景。很多人在做技术选型时喜欢追逐新东西但我不建议这么干。选型的原则应该是我能不能 hold 住、在这个团队里有没有人熟悉、出了问题能不能快速定位而不是因为它新、它快、它流行。搜索引擎也是一种特殊存储引擎当业务出现大量模糊搜索、条件组合查询时关系型数据库往往很吃力这时候引入 Elasticsearch 能解决很大问题。但它也有自己的麻烦比如索引更新延迟、集群运维成本高、数据同步链路的可靠性问题。笔记里我记录了基于 Canal 同步 MySQL 数据到 Elasticsearch 的标准方案以及如何处理全量同步和增量同步的衔接。4. 容量估算别小看数学也别被数学吓住容量估算在系统设计里占据了特殊位置。一方面它非常基础很多时候就是简单的乘除法计算另一方面它又很劝退因为不少同学的数学敏感度已经退化到看到数字就头疼的程度。我可以负责任地说系统设计中的容量估算只需要小学数学水平。核心就三个公式QPS 估算、存储量估算、带宽估算。先拿 QPS 来说假设一个日活 1000 万的资讯类 App平均每个用户每天打开 10 次那日总请求量是 1 亿每天的秒数是 86400 秒平均 QPS 大约是 1157。当然这是平均值真实业务会有明显的高峰低谷通常我们认为峰值是平均值的 5 到 10 倍也就是说你这套系统要能扛住大约 1 万左右的 QPS。有了这个数你再去判断单台服务器的承载能力就非常有意义了。一台普通的应用服务器在合理优化下扛个几千 QPS 问题不大但如果是 1 万以上就得考虑集群和负载均衡了。存储量估算也是类似。假设每篇资讯正文加元数据大概是 50KB每天新增 1 万篇内容那一年的新增存储量是 50KB 乘 1 万乘 365大概是 182GB。三年下来不到 600GB这个量级单库 MySQL 完全够用根本不需要分库分表。但如果你的业务是物联网设备上报数据每台设备每 10 秒上报一次数据一天就是 8640 条一万台设备一天就是 8640 万条三年下来就是接近 100 亿条这种量级就必须开始考虑时序数据库或者大规模分片了。带宽估算也常被忽视。比如一个视频类网站每秒要传输多少数据直接决定了你的带宽成本。如果一个视频流的码率是 2Mbps在线并发观看人数是 1 万那峰值需要的带宽是 20Gbps这个数靠着普通服务器网卡是完全扛不住的必须上 CDN 和边缘节点。笔记里我专门写了一节带宽计算把所有单位换算关系都列清楚了包括 bit、byte、bps、MB/s 之间的换算防止你被面试官追问时突然卡壳。容量估算的目的不是让你精准预测未来而是给你一个判断依据在什么量级下单机能扛住在什么量级下需要上集群在什么量级下必须引入分布式架构。没有这个判断你的整个设计方案就像浮在空中的楼阁好看但立不住。5. 案例实战从零设计一个短链接服务理论部分讲再多最后都要落到具体案例上。我笔记里收录了十几个经典案例包括短链接系统、聊天系统、电商秒杀系统、新闻 Feed 流、外卖配送调度、网约车匹配等每个案例都完整走了一遍六步框架。这里我拿短链接系统做例子让你感受一下完整的推导过程。需求阶段假设产品希望用户输入一个长链接系统生成一个短链接用户访问短链接时可以跳转到原始地址。那么需要追问的点包括每天新增多少短链接短链接的生命周期是多久需不需要统计访问数据需不需要自定义短码综合下来我们假设每天新增 100 万条短链接短链接永久有效需要记录点击次数。那一年下来就是 3.65 亿条记录在数据量上 MySQL 单表其实还能扛但为了更好的查询性能我们可以提前规划分表或者引入一些归档策略。数据量确定后短链接生成的方案是重点。一般来说有几种常见思路用哈希算法把原始长链接映射成固定长度的字符串比如 MD5 后截取前 6 位或者使用发号器借助数据库自增主键或者 Redis 的 INCR 命令生成一个自增 ID再通过进制转换把它变成短字符串。这两种方案我倾向于发号器方案。原因是纯哈希方案存在碰撞风险一旦两个不同长链接生成了同一个短码会造成非常隐蔽的跳转错误。而发号器方案天然不重复配合 62 进制转换6 位字符最多可以表示 568 亿个不同链接远远够用。存储设计上核心表一般只需要短码、原始链接、创建时间、过期时间等字段。短码做唯一索引原始链接为了支持反查可以加一个索引但要注意长链接作为索引存储空间比较大所以一般都先对长链接做一个定长哈希值存索引列。这里有个容易踩的坑长链接本身可能非常长如果是 4KB 的 URL直接存储一亿条是非常恐怖的磁盘占用更合理的方式是做压缩或者截断存储。核心链路方面用户访问短链接时DNS 解析到我们的服务经过负载均衡分发到具体的 Web 服务器Web 服务器拿到短码后去缓存查如果没有则查数据库最终把原始链接拼成 302 重定向响应返回给浏览器。这里缓存很重要因为短链接热点明显可能几个爆款内容会带来大量访问加一层 Redis 缓存可以把数据库 QPS 降一个数量级。这个案例完整推导下来你会发现每个环节都有理有据没有哪一个组件是炫技塞进去的每一个都能说出它存在的必要性。这就是一套好的系统设计应该有的样子。6. 除了写代码系统设计的软技能同样重要系统设计到了高阶阶段拼的其实是沟通能力、结构化表达能力和需求挖掘能力。很多工程师技术功底很扎实但一到面试场景就发挥不出来核心原因是不会把脑子里的思路顺畅地表达给面试官。我见过太多的面试者拿到一个设计题后埋头就画图一句话不说。半小时过去了图画了一大堆但面试官完全跟不上他的思路。这种表达方式非常吃亏因为面试官既看不到你的思考过程也没有办法和你互动纠偏。正确的方式应该是边想边说把每一步的思考结论用一两句话同步给面试官。比如面试官问完题目你可以先说“我先确认几个需求问题”然后逐条提问确定完需求后再说“根据这个需求我做了如下估算”在纸上写下关键数字然后再说“基于这个量级我倾向于用 MySQL 作为主存储同时引入 Redis 作为缓存”。这种同步式表达不会让面试官觉得你好为人师反而会觉得你逻辑清晰、有掌控力。另外面对不确定的信息不要不好意思提问。系统设计面试里的需求永远是模糊的面试官留了很多口子等你来挖掘。你问的问题越精准说明你的工程经验越丰富。比如“这类读操作和写操作的比例大概是多少”是一个好问题而“数据库用 MySQL 行不行”是一个意义不大的问题。还有一个小技巧是善用“优先级排序”。一个完整的设计往往包含很多可以讨论的点但时间有限你需要主动决定重点在哪里。比如你可以在介绍方案的时候说“我先讲核心链路的设计缓存一致性和扩展性方面我们最后讨论”。这样既控制了节奏也避免了在某个细节上过早纠缠导致整体内容来不及展示。反过来在实际项目评审中这种能力同样重要。我见过很多有想法的工程师因为表达不清楚方案被反复打回最终自己都失去信心了。学会把复杂问题结构化、把决策过程透明化不仅是面试的武器更是职场晋升的加速器。7. 学习路径和进阶方向盘点这套笔记最后一部分是我自己实践出来的学习路径。如果你想把系统设计这个能力真正吃透而不是临时抱佛脚可以参考我这个路线。第一阶段是补齐基础知识。系统设计需要你对主流中间件有一定的理解不要求能写源码但至少要知道它们的定位和核心原理。比如你得知道消息队列怎么保证可靠性Redis 持久化有哪几种方式Nginx 的反向代理是怎么回事。这一阶段可以去看官方文档和经典书籍不用贪多把高频的几个组件吃透就够起步了。第二阶段是跟着案例做设计练习。有了基础概念之后就可以开始刷 case work。笔记里每个案例都建议你先自己画一遍思路再对照我写的推导过程找差距。不要只看不练人的大脑很容易产生“看懂了就是会了”的错觉实际上让你独立从头到尾推导一遍你会发现自己遗漏掉很多关键细节。第三阶段是自己动手做项目改造。纯粹靠脑内推演是不够的最好的成长方式是在真实项目里练手。你可以挑一个自己负责的业务模块尝试给它加缓存、接消息队列、做分库分表把笔记里的理论真正落到生产环境。这里要特别小心生产环境的每一处改动都要做好灰度、监控和回滚方案不要拿线上稳定性当练习场。第四阶段是参与设计评审和复盘。当你对自己的方案有信心后可以主动向团队申请做技术方案评审。给别人讲方案比自己闷头想更能暴露盲点因为你要面对各种刁钻提问和不同视角的挑战这个过程非常锤炼人。每次评审结束把别人提的问题记录下来补充进你的笔记里这就是一套不断生长的知识体系。走到这一步你已经不再需要依赖别人的面经了因为你自己就是一本活的系统设计参考书。8. 踩坑记录与心得建议写到最后我想把自己这几年在系统设计上踩过的记忆深刻的坑分享出来希望能帮大家少走一些弯路。第一个坑是过度设计。刚学会分布式那会儿我做任何架构评审都恨不得上全套中间件注册中心、配置中心、消息队列、分布式事务全部拉满。结果被团队里一个老架构师问住你的用户量有多少单机能不能扛住从此我记住了设计的第一原则是保持简单只有当简单方案被证明不够用的时候才引入复杂度。第二个坑是忽视运维成本。曾经有一个方案我选了一个很新的存储引擎性能确实远超 MySQL但因为团队里没人熟悉它上线后出了问题没人能快速排查最后只能提工单等官方技术支持。这个经历让我意识到技术选型要综合评估整个团队的学习成本和运维能力不能只看技术指标。第三个坑是不会说“我不知道”。系统设计面试或者方案评审中总有人担心说不知道会显得自己水平差于是硬着头皮胡编乱造。其实完全不必如此诚实地承认某个领域不熟悉反而比乱给答案更让人信任。面试官更看重你面对未知领域的反应你可以说“这个方向我了解不深但基于我现有的经验我会先去看 X 和 Y用来验证 Z”。把不知道转化为下一步学习计划这本身就是一种成熟的工程能力。第四个坑是忽略数据一致性。很多设计者把所有精力放在并发容量上结果一深问“如果消息丢失怎么办”“如果两个请求同时更新同一条记录怎么办”立刻卡壳。系统设计里一致性是绕不过去的核心挑战建议你动手设计之前先把 CAP 理论、BASE 理论、幂等设计这些东西内化于心否则后面的方案都是豆腐渣工程。根据我个人的经验系统设计这个能力没有速成的捷径它需要你在项目里反复打磨需要你不断回头看自己画过的每一张架构图问自己每一个组件是不是都不可替代。这套笔记只是给你搭了一个骨架真正的血肉需要你在实践中一点点填充。希望它能帮你少走一些弯路也期待你在这个过程中形成属于自己的架构判断力。