系统设计面试是我见过刷题软件里最难准备的一类题。LeetCode 刷两百题手写二叉树反转至少有标准答案但系统设计面试没有标准答案你在面试官面前画出的那张架构图本质上是两个人对一个开放问题的探讨过程。这篇文章我想把“从场景分析到微服务拆分”这条主线的完整方法论串一遍结合我这几年做面试官和被面试的经历给正在准备系统设计面试的朋友一套可以直接照做的思路框架。先说清楚这套方法适合谁。如果你还有一两年才面试或者刚接触分布式系统读这篇文章能帮你建立系统设计的全局观如果你最近就在面试那文中的追问清单、容量估算技巧、服务拆分判断标准都可以当作考前冲刺的 checklist 来用。不管你在哪个阶段系统设计面试考察的核心从来不是“你背过多少组件”而是“面对一个模糊的开放问题时你能不能像资深工程师一样拆解、澄清、落地”。1. 系统设计面试的本质一场有套路的合作式对话很多候选人把系统设计面试理解成“在有限时间内画一张很牛的架构图”这个理解从一开始就跑偏了。面试官真正想看的是你的思考路径、取舍逻辑和沟通方式而不是最终那张图有多花哨。说白了系统设计面试是一场模拟的团队协作面试官扮演的是你的业务方兼同事他要看你怎么从一个模糊需求一路走到可落地的技术方案。1.1 面试官到底在考察什么我把系统设计面试的考察点拆成四个维度你在准备时也照着这几个维度自查。第一个维度是需求澄清能力。大部分题目开头就只有一句话比如“设计一个短链服务”或者“设计一个 feed 流系统”信息量几乎为零。这时候能不能快速把“用户量大概多少”“读写比例如何”“数据规模多大”“可用性要求多高”这些关键变量问清楚直接决定了后续方案的质量。很多候选人上来就画图结果画到一半发现吞吐量假设不对整个架构推倒重来这就是需求没澄清的代价。第二个维度是架构决策能力。面对同样的需求存储选 MySQL 还是 Cassandra要不要引入消息队列服务颗粒度切到多细这些问题没有标准答案只有基于约束条件的合理性判断。面试官会通过追问来测试你到底是真的理解还是在背网上那几套著名架构。比如你说了用 Redis 做缓存他会接着问“缓存穿透怎么办”“缓存和数据库的一致性怎么保证”这时候能不能接住才见真功夫。第三个维度是知识广度与深度。系统设计会自然地涉及网络协议、操作系统、数据库索引原理、分布式一致性等底层知识。比如估算 QPS 时要不要考虑 TCP 连接数上限设计消息队列时要不要聊分区机制这些细节都是加分项但前提是你说得准确不能为了显得厉害而胡编参数。第四个维度也是最容易被忽略的是沟通和协作能力。面试官中途打断你、质疑你的决策这时候你怎么反应是固执己见还是思考后合理修正你解释方案时逻辑清不清楚能不能让对方跟上你的思路这其实就是未来团队协作的预演。我做过很多场系统设计面试凡是让我感觉“这个人以后合作起来应该挺顺畅”的候选人技术可能不是最强的但得分通常都不低。1.2 四步法框架澄清、估算、设计、迭代既然知道了考察点就可以把系统设计面试的过程抽象成一个四步法框架让你的思考过程在面试中始终有迹可循。第一步是澄清需求用时 5 到 10 分钟。把功能性需求和非功能性需求都问清楚我后面会展开讲怎么问。第二步是容量估算用时 3 到 5 分钟。根据需求推导出 QPS、存储量、带宽这些核心指标这一步决定了后续所有选型。第三步是核心设计用时 20 到 25 分钟。先定接口和数据模型再画核心架构最后逐步补充缓存、消息队列、存储选型等细节。第四步是迭代深化用时 5 到 10 分钟。面试官会在这个阶段追问瓶颈、异常情况和扩展性你要根据反馈不断优化方案。我强烈建议你在平时练习时也用这个时间分配来卡自己。很多候选人前面聊得太high需求澄清花了二十分钟结果核心设计只剩五分钟那基本就凉了。记住这个框架的目的不是限制你而是帮你在有压力的环境下保持节奏感。2. 场景分析把一句模糊的话翻译成可计算的需求场景分析是整个系统设计面试的地基。我见过太多候选人死在这一步——不是因为他们笨而是因为他们在没有拿到足够信息的情况下就急着展示技术。你要记住系统设计面试的题目本质上是一道开放题你手里只有一句话的业务描述想要让方案落地必须先做需求和场景的翻译工作。2.1 功能性需求澄清的核心追问清单拿到题目后不要沉默也不要马上画图你需要的是一系列高质量的追问。我整理了一份自己常用的澄清清单你可以直接背下来再根据题目灵活调整。第一组问题是关于核心链路的。你要问这个系统最核心的功能是什么以短链服务为例核心功能就两个把长链接生成短链接以及访问短链接时能跳转到原始长链接。除了核心链路还有哪些非核心但必须支持的功能比如短链的有效期管理、访问统计分析、自定义短链之类。第二组问题是关于用户画像的。用户是什么样的角色C 端还是 B 端这决定了流量的洪峰特征和可用性要求。比如面向 C 端的秒杀系统流量是瞬时脉冲式的面向 B 端的后台管理系统并发量可能只有几百但对数据一致性的要求极高。第三组问题是关于规模和增长预期的。目标用户量大概是百万级还是亿级预计未来一年的增长是多少这个问题很关键因为你不需要为一个只有几千人用的内部系统设计一套能支撑双十一的架构那是过度设计面试官反而会认为你缺乏工程判断力。第四组问题是关于技术约束的。团队现有技术栈是什么有没有必须要用的基础设施有些题目会限定必须在某些云服务或框架之上做设计这时候要主动确认清楚。这一套追问走完你对题目的理解已经从“一句话描述”变成了“有边界、有约束的工程问题”。面试官会在这个过程中默默地给你加分因为你展示出了一个资深工程师面对模糊问题时的职业本能。2.2 非功能性需求QPS、延迟和可用性的量化技巧如果说功能性需求定义了系统做什么非功能性需求就定义了系统的好与坏而“好与坏”在系统设计里必须被量化。最重要的指标是 QPS每秒查询数。拿到日活用户数DAU之后你可以用一个经验模型来估算假设系统每天的活跃时间集中在 4 到 5 个小时那么核心接口的峰值 QPS 大约是“日活用户数 × 平均每个用户每天触发次数 ÷ 7200 秒 × 扩放系数”。以短链服务举例假设 DAU 是 1 亿平均每个用户每天访问短链 5 次那么平均 QPS 大概就是 5 亿 ÷ 86400约等于 5800峰值再乘以 3 到 5 倍就是 2 万到 3 万左右。这个数量级下单机是完全扛不住的必须要上负载均衡加水平扩展但如果 DAU 只有 10 万那可能一台好点的机器加个缓存就搞定了架构复杂度完全不是一个量级。其次是可接受的读写延迟。C 端产品一般要求 p99 延迟低于 200 毫秒因为用户能感知到的卡顿阈值大概就在这个水平。B 端后台则可以放宽到 1 到 2 秒。然后是可用性目标。金融交易类系统可能要求 99.99% 的高可用对应全年停机时间不超过 53 分钟而大多数互联网业务系统 99.9% 就够用了对应全年停机 8.7 个小时。切记不要拍脑袋定指标所有指标必须与业务强相关。还有两个容易被忽略但面试官很爱问的指标数据一致性级别和容量预估。对一致性要求是多高强一致、最终一致还是允许一定的脏读数据量总规模是多少存储和带宽够不够这些都要在这个阶段明确下来。2.3 容量估算手把手教你从 DAU 推导出存储和带宽估算能力是面试官判断你有没有工程经验的重要标尺。因为你在生产环境做架构设计时第一件事就是做容量规划。我举一个完整的例子假设我们现在要设计一个短链服务日活用户DAU是 1 亿。第一步估算 QPS。短链的主要操作是重定向用户一天平均访问 5 次那每天的总访问次数是 5 亿。如果访问集中在 8 小时的日间窗口平均 QPS 就是 5 亿 ÷ 8 小时 ÷ 3600 秒约等于 17000。按照互联网业务通常的系数估算峰值 QPS 大概是平均值的 3 到 4 倍也就是 5 万到 7 万。这还只是读请求写请求相对较小比如生成短链的 QPS 可能在 1000 左右因为并不是每个访问都是新生成的。第二步估算存储。假设每天新增短链 1000 万条每条记录的核心字段包括短链 ID8 字节、原始 URL平均 200 字节、用户 ID8 字节、创建时间8 字节再加上索引和冗余一条记录大约 500 字节。那么每天的存储增量就是 1000 万 × 500 字节约等于 5GB。一年的存储量就是 5GB × 365约等于 1.8TB。如果设置短链有效期是 30 天活跃数据量就是 150GB 左右这个量级用 MySQL 分库分表或者 TiDB 完全没问题但如果你的设计里没有有效期清理机制1.8TB 的冷数据会拖垮所有查询性能。第三步估算带宽。一次短链访问的重定向响应体很小大约 200KB 左右但请求是走 HTTPS 的有额外的 TLS 握手开销我们按每个响应实际消耗 300 字节计算。峰值 QPS 5 万那么带宽就是 5 万 × 300 字节× 8约等于 120Mbps这个量级一台高配服务器就能扛住。但如果你的架构绕过了 CDN所有请求都打到源站那源站带宽必须要单独预留。估算做完你的架构选型就有了数据支撑。QPS 在几千以下单机加缓存通常就够了QPS 上万就需要负载均衡和水平扩展QPS 十万以上那必须要有完善的缓存策略、消息队列削峰和分布式存储方案。这就是为什么我一直强调容量估算不是走形式它是你后续所有设计决策的输入条件。3. 从场景到微服务拆分核心架构设计的实战思路做完场景分析和容量估算就进入了整个面试最核心的环节——架构设计。我见过很多候选人到这里就开始堆组件前面一套什么 Kafka、Redis、Kubernetes把流行的东西全部列一遍但面试官一问“为什么”就卡住了。真正的高手是从容量的约束条件出发推导出自己需要什么形态的架构再决定服务怎么拆、存储怎么选、中间件要不要引。3.1 DDD 视角下的服务边界识别谈到微服务拆分就绕不开领域驱动设计DDD。我不打算在这里讲完整的 DDD 理论但你必须掌握它最核心的思想服务边界应该跟业务领域的边界保持一致而不是跟技术分层保持一致。什么意思举个例子一个电商系统里“订单”和“库存”虽然是两个紧密相关的业务模块但它们各自的职责不同订单关注“哪笔交易需要履约”库存关注“哪个商品还有多少可售量”。把它们拆成独立的服务是因为它们在业务上承担着不同的职责拥有各自独立的数据变更节奏未来也会由不同团队独立演进。相反如果把“创建订单”“查询订单”“订单状态流转”拆成 3 个服务虽然它们是不同的技术接口但业务上完全属于同一个领域拆了只会增加不必要的网络开销和分布式事务复杂度。所以在面试中当别人问你怎么拆微服务你别急着说“按功能模块拆”。好一点的回答是先找业务边界再考虑技术实现。怎么找业务边界我给你一个实用方法把题目涉及的核心名词和动词全列出来然后看哪些名词总是出现在同一个业务流程里哪些动词会同时修改多个名词的状态。那些总是被一起修改的数据就应该被圈在同一个服务里。以 feed 流系统为例核心名词有用户、关注关系、帖子、评论、点赞核心动词有发布、刷新、评论、点赞。你会发现“发帖”只修改帖子表“评论”只在帖子下有追加字段“点赞”会修改帖子状态和用户行为记录。那按业务领域划分feed 发布、feed 读取、用户社交关系就可以拆成三个候选服务。接下来再结合独立扩展性需求判断哪些真的要拆如果用户量和帖子量都很大但增长的节奏不同那拆开就很有价值。3.2 服务拆分的四个判断标准面试时你一旦说出“微服务”三个字面试官就会微笑点头然后开始深挖你这个服务边界划得合理吗为什么不是更粗为什么不是更细你需要一套底气十足的标准来回应。我总结的判断标准有四个独立扩展性、独立部署性、业务独立性和团队归属。第一独立扩展性。如果某个功能的计算量或数据量增长速度远超其他模块它就有独立拆分和独立扩缩容的价值。比如一个系统里搜索请求是整个系统流量最高的那把搜索服务单独拆出来做水平扩展其他服务维持原样整体成本会低很多。第二独立部署性。如果某个业务模块的发布频率很高一周上线好几次而其他模块一个月才发一次把它们放一起部署意味着每次高频模块发布都要把低频模块一起拖下水出故障的概率和影响面都会变大。第三业务独立性。这个判断标准要从 DDD 的角度理解一个服务是否天然承担了一个清晰的业务能力是否能做到“内部高内聚、外部低耦合”比如“用户认证”和“订单管理”就是天然独立的业务能力但“订单查询”和“订单创建”就是同一个业务能力下的不同接口强行拆开没有收益。第四团队归属。在真实公司里服务边界通常也是团队边界。两个团队负责同一套代码带来的沟通和交付成本是巨大的这种情况就倾向于拆分。面试时提到这一条会显得你很有工程组织意识。判断标准听上去很简单但实操时有个很微妙的平衡。我见过不少候选人走向另一个极端——为了微服务而微服务什么功能都要拆一个服务。我面试时就喜欢追问一句“如果能用单体架构实现你会怎么设计”如果一个候选人能把单体架构的模块化方案讲得头头是道然后在此基础上说明在哪个节点、因为什么约束必须演进成微服务那他在我心里就是高分通过。因为这说明他理解微服务是演进的结果而不是设计的目标。3.3 先设计接口和数据模型再画物理架构很多候选人在画架构图时习惯先框出几台服务器、挂了什么中间件然后才想接口怎么定义。这其实是本末倒置。我自己的习惯是先定接口契约和数据模型再反推架构。为什么因为接口和数据模型是系统对外的最稳定的部分它们直接反映了业务需求。架构图里的组件随时可以替换比如把消息队列从 Kafka 换成 Pulsar外部调用方根本感知不到但接口一旦变了所有上游都要跟着动。所以面试中应该先把这部分钉死。设计接口时要先找核心场景再确定 endpoint、请求参数和返回结果。还是以短链服务为例核心接口至少有两个生成短链的接口POST /api/shorten入参是原始 URL、有效期出参是短码重定向接口GET /api/{short_code}返回 302 跳转到原始 URL。这两个接口一确定你后续存储设计、缓存设计就有了抓手数据怎么存、缓存 key 怎么设计都是顺理成章的事。数据模型是接口的支撑。短链服务最核心的表是短链映射表字段至少包括短码主键、原始 URL、创建时间、过期时间、用户 ID。如果你需要访问统计还需要一张点击日志表。然后你会发现这两个表一个走的是点查短码查原始 URL一个走的是批量写入它们的访问模式和存储需求完全不同所以设计上自然会把它们分开。接口和数据模型走完你的架构已经完成了大概百分之六十的工作。4. 核心组件选型与存储设计面试中的推理现场存储选型、缓存引入、消息队列使用这些是系统设计面试里最考验“内功”的部分。很多候选人对每个组件都能说出几句概念但到了具体场景里就不知道怎么选。真正好的选型逻辑是一个从需求到方案的推理过程面试官期待看到的是你如何一步步推论出结论而不是只能报出几个组件名字。4.1 SQL 还是 NoSQL以数据特征为依据而不是流行度存储选型的核心判断维度有三个数据结构、查询模式、扩展方式。如果数据具有强结构化和强关联性比如订单、用户、转账记录而且需要支持事务、多表 join 查询那关系型数据库 MySQL 或 PostgreSQL 是首选。如果数据结构灵活、字段经常变化比如用户行为日志、Feed 流帖子而且查询模式主要是单 key 或 range 查询不需要复杂 join那 NoSQL 如 MongoDB、Cassandra 可能更合适。很多候选人喜欢把 NoSQL 挂在嘴边显得自己架构很“现代”。但面试官深入一问他们往往说不出为什么不用 MySQL。所以我建议你反过来练习先假设用 MySQL然后思考什么情况下 MySQL 顶不住再决定是否换。比如短链服务数据规模在 1TB 左右点查为主其实用 MySQL 拆个分片就够了根本不需要上 NoSQL但如果短链数据规模上百亿写多读更多那 Cassandra 这种 LSM-tree 存储引擎的写入性能优势就很明显了。4.2 缓存策略穿透、击穿、雪崩必须主动讲几乎任何系统设计面试题里都会提到缓存因为缓存是提升读性能最有效的手段。但你要注意讲缓存不能只讲“用 Redis 做缓存”你需要展示你对缓存异常场景的预案。缓存穿透指的是查询一个不存在的数据请求直接打到数据库。解决方案有两个把空结果也缓存起来但设置较短的过期时间或者在缓存前加布隆过滤器拦截不存在的 key。最理想的是两个都用布隆过滤器挡大部分恶意请求空缓存兜底剩下的。缓存击穿指的是某个热点 key 过期瞬间大量并发请求直接打到数据库。解决方案是互斥锁只允许一个请求去重建缓存其他请求等待或者返回旧值。实现上可以用 Redis 的 SETNX 命令或者并发控制里用的单飞机制。缓存雪崩指的是大量 key 在同一时间集体过期导致数据库压力激增。预防方案是过期时间加随机值避免集中失效高可用方面可以做 Redis 主从和多副本保证即使 Cache 集群有节点挂掉整个缓存服务也不至于不可用。面试时如果能主动地把这三种异常讲明白并且结合你设计的方案说明怎么应对面试官对你的印象会明显提升。这属于知识点不难、但很少有人主动展开的加分项。4.3 消息队列什么时候必须引入什么时候是过度设计消息队列是面试中另一个高频话题。一定要记住引入消息队列是有代价的——它带来了最终一致性、消息丢失、重复消费、顺序性等一系列分布式问题。所以被问到时你的思路应该是先分析场景再决定要不要用。什么场景必须用消息队列第一是流量削峰。比如秒杀系统瞬时流量冲到 QPS 十万直接打到数据库肯定挂这时候用消息队列把写请求暂存起来让下游系统按照自己的处理能力慢慢消费。第二是系统解耦。比如下单后要通知库存系统扣库存、通知积分系统加积分、通知短信系统发消息如果都同步调接口下单接口的延迟会变得不可接受而且任何一个下游挂了都会影响核心下单流程。这时候通过消息队列异步通知核心链路和下游业务就解耦了。第三是数据同步。比如把数据库变更记录通过 binlog 同步到 Elasticsearch 或缓存消息队列是这类场景的好帮手。但我见过更多时候候选人喜欢不分青红皂白地给所有系统加消息队列。面试官一追问“这个系统 QPS 才几百你引入消息队列带来了什么收益”就答不上来了。记住一个原则当系统的流量和复杂度根本没达到引入队列的必要条件时加了就是过度设计面试官反而会给你减分。所以我在面试中如果遇到候选人提消息队列我必然会追问“什么场景下这个系统不加消息队列会出问题”——你先把这个逻辑想清楚再决定要不要拿出来说。5. 综合实战从零推导一个短链服务的完整设计为了把上面所有思路串起来我拿一个系统设计面试的经典题目——短链服务完整演示一遍从场景分析到微服务拆分的全过程。这个例子你能完全吃透其他题目不管你遇到的是 feed 流、秒杀还是聊天系统方法都是通用的。5.1 场景分析我把和面试官的对话给你演一遍好的题目是“请设计一个短链服务”。我第一轮要做的就是澄清需求。我会说“好的为了让方案更贴合实际我想先确认几个关键点。第一这个短链服务的主要使用场景是什么是营销短信、社交分发还是内部工具第二我们有大概多少用户量和 QPS 预期第三短链的有效期是永久的还是有期限第四需不需要额外的功能比如点击统计、自定义短链”假设面试官回答主要场景是社交分享日活 1 亿短链有效期一般是 30 天需要点击统计分析。那么我心里就开始盘算短链的重定向 QPS 在 5 万左右生成的 QPS 在 1000 左右30 天有效期内活跃数据量 150GB 左右。这个量级下系统可以设计成三个核心服务加一个外部依赖。澄清需求这一步我大概会花 5 分钟。有些朋友可能觉得这个环节很啰嗦但在面试官眼里一个能在需求不明确时不急于动手、先把边界理清楚的候选人通常才是以后好协作的人。5.2 架构设计三个服务加一个存储层在容量估算的基础上我给出了系统的最终架构设计三个核心服务分别是短链生成服务、短链重定向服务、统计分析服务。短链生成服务负责接收长 URL 生成短码。短码的生成算法是整个系统的关键点之一。我最常用的是发号器方案利用分布式 ID 生成器拿到全局自增 ID再将十进制的 ID 通过 Base62 编码转换成一个 6 到 8 位的短码。比如 ID 是 100000转换成 Base62 后可能是“qC4”示例这个短码可以直接当主键用。采用发号器而不是哈希取模是因为哈希生成短码会有很棘手的冲突问题可能出现两个长 URL 生成同一个短码导致数据错乱发号器天然全局唯一而且实现简单。短码生成后写入 MySQL。表结构就是我们前面设计过的短链映射表短码做主键原始 URL 和过期时间做辅助字段。为什么选 MySQL 不选 NoSQL因为这个数据模型的查询模式非常固定无非就是按短码点查不需要 joinMySQL 完全扛得住而且在事务和运维上比 NoSQL 更成熟。短链重定向服务处理的是用户点击短链的请求。这是整个系统里 QPS 最高的路径所以我设计了“CDN 加 Redis 缓存加 MySQL”三级架构。用户发起短链访问时请求先到 CDN如果 CDN 有缓存的原始 URL直接 302 跳转CDN 没有命中请求到后端 RedisRedis 缓存了短码到原始 URL 的映射这一步能拦住绝大多数请求只有 Redis 也没有命中时才去 MySQL 里查查到后再将结果写回 Redis。这一套下来MySQL 实际承受的压力只有总请求量的几个百分点。统计服务负责记录点击日志。因为点击日志是海量高吞吐写入我采用异步方式把点击事件先发送到 Kafka再由消费服务批量写入分析型数据库比如 ClickHouse 或 Elasticsearch。这样统计功能完全不会影响核心重定向链路的性能。讲完了服务拆分我还会补充说明为什么没有把“短链生成”和“短链重定向”合并成一个服务。因为这两个服务的负载特征差别很大生成短链 QPS 只有 1000重定向 QPS 却有 5 万生成短链是写场景重定向是读场景。把它们拆开可以分别做水平扩展也意味着未来可以把重定向服务做成 CDN 层面的边缘节点而生成服务留在中心节点。你看这样拆分的理由都是从容量估算和业务特征推导出来的工程判断不是拍脑袋。5.3 面试加分细节从短码算法到 301 还是 302基础架构画完了面试官大概率会在细节上继续深挖。这些小细节往往是拉开得分差距的地方。短码生成算法除了发号器方案我还会提一嘴另一个常见方案使用长 URL 做哈希然后截取前 8 位作为短码。这个方案的优势是不依赖发号器缺点是需要解决哈希冲突——一旦两个长 URL 哈希出同一个短码数据库插入就会报错需要重试加上随机盐。两种方案对比我倾向于发号器因为它生成效率高、天然有序、方便分库分表。但你把两种方案的优劣都讲清楚面试官会认为你是真的理解而不是只会一种写法。重定向的状态码选 301 还是 302这个问题很小但能区分出候选人有没有踩过生产环境的坑。301 是永久重定向用户的浏览器和 CDN 会把跳转结果缓存住后续访问直接跳到原始 URL不经过短链服务这样做的好处是短链服务的压力更小坏处是你没法统计点击量了因为你根本收不到后续的请求。302 是临时重定向浏览器和 CDN 每次访问都会经过短链服务会让服务压力更大但能实时统计点击。业务上如果对数据准确性要求高选 302如果要求清缓存降低负载选 301。在普通短链服务里为了统计数据通常选 302配合 CDN 的边缘节点能力压力其实也不大。再提一个容易被问的细节短码过期怎么处理。我的方案是启动一个定时任务或者用延迟队列定期扫描 MySQL 里的过期短码把 Redis 缓存里的旧数据删掉再把 MySQL 里的标记位改掉。为什么不能只靠 Redis 的 TTL因为 MySQL 里的数据还占着空间查询过期短码会返回一个不存在的提示但物理数据一直在增长。业务定义短链有效期是 30 天冷数据如果你不及时清理存储成本会不断膨胀。6. 常见翻车现场系统设计面试中最容易挂掉的几种死法作为面试官我见过太多候选人在系统设计面试里翻车。他们不是不努力LeetCode 刷了三百题分布式理论也能讲得头头是道但一到面试就暴露出一堆致命问题。这一节我把最常见的翻车点整理出来每条都是真实面试中遇到过的希望你能避开。6.1 需求没澄清就画图最标准的死法“好的那我们就设计一个秒杀系统。”候选人听完这句话直接在白板上写下“浏览器 → Nginx → Redis → Kafka → 商品服务”之后开始讲。我立刻打断问“日活和峰值流量是多少”他愣住了。这就是最经典的翻车现场。需求是系统设计的约束条件没有约束的设计就是空中楼阁。你画出的每一个组件都应该因为某个明确的需求指标才有存在的必要。秒杀系统如果只有 1 万日活和 1000 QPS那上面的架构完全就是表演。所以我对所有候选人的第一个建议都是拿到题目后哪怕设计思路已经涌上心头也先用 3 到 5 分钟问清楚需求这是最稳的走法。6.2 只会背架构模板经不起一个“为什么”我面试过一个做过三年 Java 开发的候选人简历上写着精通微服务和消息队列。我让他设计一个答题系统他张口就是“Spring Cloud 全家桶加 Kafka 加 Redis”。然后我问他“你的 Kafka 在这里承担什么职责”他愣了一下“做消息队列啊解耦用的。”这个回答等于什么都没说。你用了 Kafka你就要能说清楚哪个环节削峰哪个系统解耦消息丢失和重复消费怎么处理消费积压怎么监控答不出来面试官只会觉得你在贴标签而不是在做工程决策。记住在系统设计面试里你每说一个组件都要做好被连续追问三次的准备。第一次问用途第二次问为什么用它第三次问换一个行不行。6.3 容灾和过期策略只字不提很多候选人的架构图里只有“晴天路径”完全没有“下雨天怎么办”的预案。系统设计考察的不只是正常流程还包括异常流程。数据丢失了怎么办服务挂了怎么办缓存雪崩了怎么办消息积压了怎么办这些问题你在生产环境里早晚会遇到面试官其实就是在模拟生产环境做 design review。我建议你画完架构图后主动花几分钟把异常场景过一遍。不要等面试官追问主动说“这个方案我考虑了缓存雪崩的预案”“这里我做了消息队列的重试和告警机制”。这种主动性会让面试官觉得你是一个有系统级思考能力的人而不是只会画图的画师。6.4 容量估算时口算失误越算越慌容量估算在紧张时很容易算错我自己当年也翻过车。当时让我设计一个即时通讯系统我算了半天 QPS结果少乘了一个 8最后带宽估算差了一个数量级直接被纠正。这里有个经验技巧估算时把问题拆成一连串简单的乘法除法每一步都大声说出来而不是沉默地心算。比如“1 亿用户乘以 5 次访问等于 5 亿除以 86400 秒等于 5800 左右峰值按 3 倍算就是 1.7 万 QPS”。每一步都说出来对方能跟上你的逻辑即使算错面试官也能第一时间帮你纠偏不会让你一直在错误的方向上狂奔。7. 系统设计面试的终点是沟通能力做技术这些年不管是作为候选人还是面试官我越来越觉得系统设计面试其实是在考一件更本质的事你怎么跟人合作解决一个复杂问题。你有没有耐心把需求问清楚你能不能把复杂的概念讲得别人能听懂你能不能接受别人对你的方案提出质疑并给出有理有据的回应这些能力跟架构能力同样重要甚至更加重要。我的习惯是画完架构图主动跟面试官对齐思路说“这是我目前的大方向你看有没有哪些点需要调整”。这听起来像示弱但其实是高情商的做法。它把面试从“审判”变成“合作”面试官会不自觉地从挑刺模式切换到帮你完善方案的模式。我在面试中遇到这样的候选人哪怕他方案里有一些瑕疵我也更愿意给机会因为和一个能顺畅对话的人共事比和一台技术百科全书共事要舒服得多。在准备好的前提下把面试当成一次普通的技术方案讨论你的真实水平才能正常发挥出来。
系统设计面试核心框架：从场景分析到微服务拆分实战指南
系统设计面试是我见过刷题软件里最难准备的一类题。LeetCode 刷两百题手写二叉树反转至少有标准答案但系统设计面试没有标准答案你在面试官面前画出的那张架构图本质上是两个人对一个开放问题的探讨过程。这篇文章我想把“从场景分析到微服务拆分”这条主线的完整方法论串一遍结合我这几年做面试官和被面试的经历给正在准备系统设计面试的朋友一套可以直接照做的思路框架。先说清楚这套方法适合谁。如果你还有一两年才面试或者刚接触分布式系统读这篇文章能帮你建立系统设计的全局观如果你最近就在面试那文中的追问清单、容量估算技巧、服务拆分判断标准都可以当作考前冲刺的 checklist 来用。不管你在哪个阶段系统设计面试考察的核心从来不是“你背过多少组件”而是“面对一个模糊的开放问题时你能不能像资深工程师一样拆解、澄清、落地”。1. 系统设计面试的本质一场有套路的合作式对话很多候选人把系统设计面试理解成“在有限时间内画一张很牛的架构图”这个理解从一开始就跑偏了。面试官真正想看的是你的思考路径、取舍逻辑和沟通方式而不是最终那张图有多花哨。说白了系统设计面试是一场模拟的团队协作面试官扮演的是你的业务方兼同事他要看你怎么从一个模糊需求一路走到可落地的技术方案。1.1 面试官到底在考察什么我把系统设计面试的考察点拆成四个维度你在准备时也照着这几个维度自查。第一个维度是需求澄清能力。大部分题目开头就只有一句话比如“设计一个短链服务”或者“设计一个 feed 流系统”信息量几乎为零。这时候能不能快速把“用户量大概多少”“读写比例如何”“数据规模多大”“可用性要求多高”这些关键变量问清楚直接决定了后续方案的质量。很多候选人上来就画图结果画到一半发现吞吐量假设不对整个架构推倒重来这就是需求没澄清的代价。第二个维度是架构决策能力。面对同样的需求存储选 MySQL 还是 Cassandra要不要引入消息队列服务颗粒度切到多细这些问题没有标准答案只有基于约束条件的合理性判断。面试官会通过追问来测试你到底是真的理解还是在背网上那几套著名架构。比如你说了用 Redis 做缓存他会接着问“缓存穿透怎么办”“缓存和数据库的一致性怎么保证”这时候能不能接住才见真功夫。第三个维度是知识广度与深度。系统设计会自然地涉及网络协议、操作系统、数据库索引原理、分布式一致性等底层知识。比如估算 QPS 时要不要考虑 TCP 连接数上限设计消息队列时要不要聊分区机制这些细节都是加分项但前提是你说得准确不能为了显得厉害而胡编参数。第四个维度也是最容易被忽略的是沟通和协作能力。面试官中途打断你、质疑你的决策这时候你怎么反应是固执己见还是思考后合理修正你解释方案时逻辑清不清楚能不能让对方跟上你的思路这其实就是未来团队协作的预演。我做过很多场系统设计面试凡是让我感觉“这个人以后合作起来应该挺顺畅”的候选人技术可能不是最强的但得分通常都不低。1.2 四步法框架澄清、估算、设计、迭代既然知道了考察点就可以把系统设计面试的过程抽象成一个四步法框架让你的思考过程在面试中始终有迹可循。第一步是澄清需求用时 5 到 10 分钟。把功能性需求和非功能性需求都问清楚我后面会展开讲怎么问。第二步是容量估算用时 3 到 5 分钟。根据需求推导出 QPS、存储量、带宽这些核心指标这一步决定了后续所有选型。第三步是核心设计用时 20 到 25 分钟。先定接口和数据模型再画核心架构最后逐步补充缓存、消息队列、存储选型等细节。第四步是迭代深化用时 5 到 10 分钟。面试官会在这个阶段追问瓶颈、异常情况和扩展性你要根据反馈不断优化方案。我强烈建议你在平时练习时也用这个时间分配来卡自己。很多候选人前面聊得太high需求澄清花了二十分钟结果核心设计只剩五分钟那基本就凉了。记住这个框架的目的不是限制你而是帮你在有压力的环境下保持节奏感。2. 场景分析把一句模糊的话翻译成可计算的需求场景分析是整个系统设计面试的地基。我见过太多候选人死在这一步——不是因为他们笨而是因为他们在没有拿到足够信息的情况下就急着展示技术。你要记住系统设计面试的题目本质上是一道开放题你手里只有一句话的业务描述想要让方案落地必须先做需求和场景的翻译工作。2.1 功能性需求澄清的核心追问清单拿到题目后不要沉默也不要马上画图你需要的是一系列高质量的追问。我整理了一份自己常用的澄清清单你可以直接背下来再根据题目灵活调整。第一组问题是关于核心链路的。你要问这个系统最核心的功能是什么以短链服务为例核心功能就两个把长链接生成短链接以及访问短链接时能跳转到原始长链接。除了核心链路还有哪些非核心但必须支持的功能比如短链的有效期管理、访问统计分析、自定义短链之类。第二组问题是关于用户画像的。用户是什么样的角色C 端还是 B 端这决定了流量的洪峰特征和可用性要求。比如面向 C 端的秒杀系统流量是瞬时脉冲式的面向 B 端的后台管理系统并发量可能只有几百但对数据一致性的要求极高。第三组问题是关于规模和增长预期的。目标用户量大概是百万级还是亿级预计未来一年的增长是多少这个问题很关键因为你不需要为一个只有几千人用的内部系统设计一套能支撑双十一的架构那是过度设计面试官反而会认为你缺乏工程判断力。第四组问题是关于技术约束的。团队现有技术栈是什么有没有必须要用的基础设施有些题目会限定必须在某些云服务或框架之上做设计这时候要主动确认清楚。这一套追问走完你对题目的理解已经从“一句话描述”变成了“有边界、有约束的工程问题”。面试官会在这个过程中默默地给你加分因为你展示出了一个资深工程师面对模糊问题时的职业本能。2.2 非功能性需求QPS、延迟和可用性的量化技巧如果说功能性需求定义了系统做什么非功能性需求就定义了系统的好与坏而“好与坏”在系统设计里必须被量化。最重要的指标是 QPS每秒查询数。拿到日活用户数DAU之后你可以用一个经验模型来估算假设系统每天的活跃时间集中在 4 到 5 个小时那么核心接口的峰值 QPS 大约是“日活用户数 × 平均每个用户每天触发次数 ÷ 7200 秒 × 扩放系数”。以短链服务举例假设 DAU 是 1 亿平均每个用户每天访问短链 5 次那么平均 QPS 大概就是 5 亿 ÷ 86400约等于 5800峰值再乘以 3 到 5 倍就是 2 万到 3 万左右。这个数量级下单机是完全扛不住的必须要上负载均衡加水平扩展但如果 DAU 只有 10 万那可能一台好点的机器加个缓存就搞定了架构复杂度完全不是一个量级。其次是可接受的读写延迟。C 端产品一般要求 p99 延迟低于 200 毫秒因为用户能感知到的卡顿阈值大概就在这个水平。B 端后台则可以放宽到 1 到 2 秒。然后是可用性目标。金融交易类系统可能要求 99.99% 的高可用对应全年停机时间不超过 53 分钟而大多数互联网业务系统 99.9% 就够用了对应全年停机 8.7 个小时。切记不要拍脑袋定指标所有指标必须与业务强相关。还有两个容易被忽略但面试官很爱问的指标数据一致性级别和容量预估。对一致性要求是多高强一致、最终一致还是允许一定的脏读数据量总规模是多少存储和带宽够不够这些都要在这个阶段明确下来。2.3 容量估算手把手教你从 DAU 推导出存储和带宽估算能力是面试官判断你有没有工程经验的重要标尺。因为你在生产环境做架构设计时第一件事就是做容量规划。我举一个完整的例子假设我们现在要设计一个短链服务日活用户DAU是 1 亿。第一步估算 QPS。短链的主要操作是重定向用户一天平均访问 5 次那每天的总访问次数是 5 亿。如果访问集中在 8 小时的日间窗口平均 QPS 就是 5 亿 ÷ 8 小时 ÷ 3600 秒约等于 17000。按照互联网业务通常的系数估算峰值 QPS 大概是平均值的 3 到 4 倍也就是 5 万到 7 万。这还只是读请求写请求相对较小比如生成短链的 QPS 可能在 1000 左右因为并不是每个访问都是新生成的。第二步估算存储。假设每天新增短链 1000 万条每条记录的核心字段包括短链 ID8 字节、原始 URL平均 200 字节、用户 ID8 字节、创建时间8 字节再加上索引和冗余一条记录大约 500 字节。那么每天的存储增量就是 1000 万 × 500 字节约等于 5GB。一年的存储量就是 5GB × 365约等于 1.8TB。如果设置短链有效期是 30 天活跃数据量就是 150GB 左右这个量级用 MySQL 分库分表或者 TiDB 完全没问题但如果你的设计里没有有效期清理机制1.8TB 的冷数据会拖垮所有查询性能。第三步估算带宽。一次短链访问的重定向响应体很小大约 200KB 左右但请求是走 HTTPS 的有额外的 TLS 握手开销我们按每个响应实际消耗 300 字节计算。峰值 QPS 5 万那么带宽就是 5 万 × 300 字节× 8约等于 120Mbps这个量级一台高配服务器就能扛住。但如果你的架构绕过了 CDN所有请求都打到源站那源站带宽必须要单独预留。估算做完你的架构选型就有了数据支撑。QPS 在几千以下单机加缓存通常就够了QPS 上万就需要负载均衡和水平扩展QPS 十万以上那必须要有完善的缓存策略、消息队列削峰和分布式存储方案。这就是为什么我一直强调容量估算不是走形式它是你后续所有设计决策的输入条件。3. 从场景到微服务拆分核心架构设计的实战思路做完场景分析和容量估算就进入了整个面试最核心的环节——架构设计。我见过很多候选人到这里就开始堆组件前面一套什么 Kafka、Redis、Kubernetes把流行的东西全部列一遍但面试官一问“为什么”就卡住了。真正的高手是从容量的约束条件出发推导出自己需要什么形态的架构再决定服务怎么拆、存储怎么选、中间件要不要引。3.1 DDD 视角下的服务边界识别谈到微服务拆分就绕不开领域驱动设计DDD。我不打算在这里讲完整的 DDD 理论但你必须掌握它最核心的思想服务边界应该跟业务领域的边界保持一致而不是跟技术分层保持一致。什么意思举个例子一个电商系统里“订单”和“库存”虽然是两个紧密相关的业务模块但它们各自的职责不同订单关注“哪笔交易需要履约”库存关注“哪个商品还有多少可售量”。把它们拆成独立的服务是因为它们在业务上承担着不同的职责拥有各自独立的数据变更节奏未来也会由不同团队独立演进。相反如果把“创建订单”“查询订单”“订单状态流转”拆成 3 个服务虽然它们是不同的技术接口但业务上完全属于同一个领域拆了只会增加不必要的网络开销和分布式事务复杂度。所以在面试中当别人问你怎么拆微服务你别急着说“按功能模块拆”。好一点的回答是先找业务边界再考虑技术实现。怎么找业务边界我给你一个实用方法把题目涉及的核心名词和动词全列出来然后看哪些名词总是出现在同一个业务流程里哪些动词会同时修改多个名词的状态。那些总是被一起修改的数据就应该被圈在同一个服务里。以 feed 流系统为例核心名词有用户、关注关系、帖子、评论、点赞核心动词有发布、刷新、评论、点赞。你会发现“发帖”只修改帖子表“评论”只在帖子下有追加字段“点赞”会修改帖子状态和用户行为记录。那按业务领域划分feed 发布、feed 读取、用户社交关系就可以拆成三个候选服务。接下来再结合独立扩展性需求判断哪些真的要拆如果用户量和帖子量都很大但增长的节奏不同那拆开就很有价值。3.2 服务拆分的四个判断标准面试时你一旦说出“微服务”三个字面试官就会微笑点头然后开始深挖你这个服务边界划得合理吗为什么不是更粗为什么不是更细你需要一套底气十足的标准来回应。我总结的判断标准有四个独立扩展性、独立部署性、业务独立性和团队归属。第一独立扩展性。如果某个功能的计算量或数据量增长速度远超其他模块它就有独立拆分和独立扩缩容的价值。比如一个系统里搜索请求是整个系统流量最高的那把搜索服务单独拆出来做水平扩展其他服务维持原样整体成本会低很多。第二独立部署性。如果某个业务模块的发布频率很高一周上线好几次而其他模块一个月才发一次把它们放一起部署意味着每次高频模块发布都要把低频模块一起拖下水出故障的概率和影响面都会变大。第三业务独立性。这个判断标准要从 DDD 的角度理解一个服务是否天然承担了一个清晰的业务能力是否能做到“内部高内聚、外部低耦合”比如“用户认证”和“订单管理”就是天然独立的业务能力但“订单查询”和“订单创建”就是同一个业务能力下的不同接口强行拆开没有收益。第四团队归属。在真实公司里服务边界通常也是团队边界。两个团队负责同一套代码带来的沟通和交付成本是巨大的这种情况就倾向于拆分。面试时提到这一条会显得你很有工程组织意识。判断标准听上去很简单但实操时有个很微妙的平衡。我见过不少候选人走向另一个极端——为了微服务而微服务什么功能都要拆一个服务。我面试时就喜欢追问一句“如果能用单体架构实现你会怎么设计”如果一个候选人能把单体架构的模块化方案讲得头头是道然后在此基础上说明在哪个节点、因为什么约束必须演进成微服务那他在我心里就是高分通过。因为这说明他理解微服务是演进的结果而不是设计的目标。3.3 先设计接口和数据模型再画物理架构很多候选人在画架构图时习惯先框出几台服务器、挂了什么中间件然后才想接口怎么定义。这其实是本末倒置。我自己的习惯是先定接口契约和数据模型再反推架构。为什么因为接口和数据模型是系统对外的最稳定的部分它们直接反映了业务需求。架构图里的组件随时可以替换比如把消息队列从 Kafka 换成 Pulsar外部调用方根本感知不到但接口一旦变了所有上游都要跟着动。所以面试中应该先把这部分钉死。设计接口时要先找核心场景再确定 endpoint、请求参数和返回结果。还是以短链服务为例核心接口至少有两个生成短链的接口POST /api/shorten入参是原始 URL、有效期出参是短码重定向接口GET /api/{short_code}返回 302 跳转到原始 URL。这两个接口一确定你后续存储设计、缓存设计就有了抓手数据怎么存、缓存 key 怎么设计都是顺理成章的事。数据模型是接口的支撑。短链服务最核心的表是短链映射表字段至少包括短码主键、原始 URL、创建时间、过期时间、用户 ID。如果你需要访问统计还需要一张点击日志表。然后你会发现这两个表一个走的是点查短码查原始 URL一个走的是批量写入它们的访问模式和存储需求完全不同所以设计上自然会把它们分开。接口和数据模型走完你的架构已经完成了大概百分之六十的工作。4. 核心组件选型与存储设计面试中的推理现场存储选型、缓存引入、消息队列使用这些是系统设计面试里最考验“内功”的部分。很多候选人对每个组件都能说出几句概念但到了具体场景里就不知道怎么选。真正好的选型逻辑是一个从需求到方案的推理过程面试官期待看到的是你如何一步步推论出结论而不是只能报出几个组件名字。4.1 SQL 还是 NoSQL以数据特征为依据而不是流行度存储选型的核心判断维度有三个数据结构、查询模式、扩展方式。如果数据具有强结构化和强关联性比如订单、用户、转账记录而且需要支持事务、多表 join 查询那关系型数据库 MySQL 或 PostgreSQL 是首选。如果数据结构灵活、字段经常变化比如用户行为日志、Feed 流帖子而且查询模式主要是单 key 或 range 查询不需要复杂 join那 NoSQL 如 MongoDB、Cassandra 可能更合适。很多候选人喜欢把 NoSQL 挂在嘴边显得自己架构很“现代”。但面试官深入一问他们往往说不出为什么不用 MySQL。所以我建议你反过来练习先假设用 MySQL然后思考什么情况下 MySQL 顶不住再决定是否换。比如短链服务数据规模在 1TB 左右点查为主其实用 MySQL 拆个分片就够了根本不需要上 NoSQL但如果短链数据规模上百亿写多读更多那 Cassandra 这种 LSM-tree 存储引擎的写入性能优势就很明显了。4.2 缓存策略穿透、击穿、雪崩必须主动讲几乎任何系统设计面试题里都会提到缓存因为缓存是提升读性能最有效的手段。但你要注意讲缓存不能只讲“用 Redis 做缓存”你需要展示你对缓存异常场景的预案。缓存穿透指的是查询一个不存在的数据请求直接打到数据库。解决方案有两个把空结果也缓存起来但设置较短的过期时间或者在缓存前加布隆过滤器拦截不存在的 key。最理想的是两个都用布隆过滤器挡大部分恶意请求空缓存兜底剩下的。缓存击穿指的是某个热点 key 过期瞬间大量并发请求直接打到数据库。解决方案是互斥锁只允许一个请求去重建缓存其他请求等待或者返回旧值。实现上可以用 Redis 的 SETNX 命令或者并发控制里用的单飞机制。缓存雪崩指的是大量 key 在同一时间集体过期导致数据库压力激增。预防方案是过期时间加随机值避免集中失效高可用方面可以做 Redis 主从和多副本保证即使 Cache 集群有节点挂掉整个缓存服务也不至于不可用。面试时如果能主动地把这三种异常讲明白并且结合你设计的方案说明怎么应对面试官对你的印象会明显提升。这属于知识点不难、但很少有人主动展开的加分项。4.3 消息队列什么时候必须引入什么时候是过度设计消息队列是面试中另一个高频话题。一定要记住引入消息队列是有代价的——它带来了最终一致性、消息丢失、重复消费、顺序性等一系列分布式问题。所以被问到时你的思路应该是先分析场景再决定要不要用。什么场景必须用消息队列第一是流量削峰。比如秒杀系统瞬时流量冲到 QPS 十万直接打到数据库肯定挂这时候用消息队列把写请求暂存起来让下游系统按照自己的处理能力慢慢消费。第二是系统解耦。比如下单后要通知库存系统扣库存、通知积分系统加积分、通知短信系统发消息如果都同步调接口下单接口的延迟会变得不可接受而且任何一个下游挂了都会影响核心下单流程。这时候通过消息队列异步通知核心链路和下游业务就解耦了。第三是数据同步。比如把数据库变更记录通过 binlog 同步到 Elasticsearch 或缓存消息队列是这类场景的好帮手。但我见过更多时候候选人喜欢不分青红皂白地给所有系统加消息队列。面试官一追问“这个系统 QPS 才几百你引入消息队列带来了什么收益”就答不上来了。记住一个原则当系统的流量和复杂度根本没达到引入队列的必要条件时加了就是过度设计面试官反而会给你减分。所以我在面试中如果遇到候选人提消息队列我必然会追问“什么场景下这个系统不加消息队列会出问题”——你先把这个逻辑想清楚再决定要不要拿出来说。5. 综合实战从零推导一个短链服务的完整设计为了把上面所有思路串起来我拿一个系统设计面试的经典题目——短链服务完整演示一遍从场景分析到微服务拆分的全过程。这个例子你能完全吃透其他题目不管你遇到的是 feed 流、秒杀还是聊天系统方法都是通用的。5.1 场景分析我把和面试官的对话给你演一遍好的题目是“请设计一个短链服务”。我第一轮要做的就是澄清需求。我会说“好的为了让方案更贴合实际我想先确认几个关键点。第一这个短链服务的主要使用场景是什么是营销短信、社交分发还是内部工具第二我们有大概多少用户量和 QPS 预期第三短链的有效期是永久的还是有期限第四需不需要额外的功能比如点击统计、自定义短链”假设面试官回答主要场景是社交分享日活 1 亿短链有效期一般是 30 天需要点击统计分析。那么我心里就开始盘算短链的重定向 QPS 在 5 万左右生成的 QPS 在 1000 左右30 天有效期内活跃数据量 150GB 左右。这个量级下系统可以设计成三个核心服务加一个外部依赖。澄清需求这一步我大概会花 5 分钟。有些朋友可能觉得这个环节很啰嗦但在面试官眼里一个能在需求不明确时不急于动手、先把边界理清楚的候选人通常才是以后好协作的人。5.2 架构设计三个服务加一个存储层在容量估算的基础上我给出了系统的最终架构设计三个核心服务分别是短链生成服务、短链重定向服务、统计分析服务。短链生成服务负责接收长 URL 生成短码。短码的生成算法是整个系统的关键点之一。我最常用的是发号器方案利用分布式 ID 生成器拿到全局自增 ID再将十进制的 ID 通过 Base62 编码转换成一个 6 到 8 位的短码。比如 ID 是 100000转换成 Base62 后可能是“qC4”示例这个短码可以直接当主键用。采用发号器而不是哈希取模是因为哈希生成短码会有很棘手的冲突问题可能出现两个长 URL 生成同一个短码导致数据错乱发号器天然全局唯一而且实现简单。短码生成后写入 MySQL。表结构就是我们前面设计过的短链映射表短码做主键原始 URL 和过期时间做辅助字段。为什么选 MySQL 不选 NoSQL因为这个数据模型的查询模式非常固定无非就是按短码点查不需要 joinMySQL 完全扛得住而且在事务和运维上比 NoSQL 更成熟。短链重定向服务处理的是用户点击短链的请求。这是整个系统里 QPS 最高的路径所以我设计了“CDN 加 Redis 缓存加 MySQL”三级架构。用户发起短链访问时请求先到 CDN如果 CDN 有缓存的原始 URL直接 302 跳转CDN 没有命中请求到后端 RedisRedis 缓存了短码到原始 URL 的映射这一步能拦住绝大多数请求只有 Redis 也没有命中时才去 MySQL 里查查到后再将结果写回 Redis。这一套下来MySQL 实际承受的压力只有总请求量的几个百分点。统计服务负责记录点击日志。因为点击日志是海量高吞吐写入我采用异步方式把点击事件先发送到 Kafka再由消费服务批量写入分析型数据库比如 ClickHouse 或 Elasticsearch。这样统计功能完全不会影响核心重定向链路的性能。讲完了服务拆分我还会补充说明为什么没有把“短链生成”和“短链重定向”合并成一个服务。因为这两个服务的负载特征差别很大生成短链 QPS 只有 1000重定向 QPS 却有 5 万生成短链是写场景重定向是读场景。把它们拆开可以分别做水平扩展也意味着未来可以把重定向服务做成 CDN 层面的边缘节点而生成服务留在中心节点。你看这样拆分的理由都是从容量估算和业务特征推导出来的工程判断不是拍脑袋。5.3 面试加分细节从短码算法到 301 还是 302基础架构画完了面试官大概率会在细节上继续深挖。这些小细节往往是拉开得分差距的地方。短码生成算法除了发号器方案我还会提一嘴另一个常见方案使用长 URL 做哈希然后截取前 8 位作为短码。这个方案的优势是不依赖发号器缺点是需要解决哈希冲突——一旦两个长 URL 哈希出同一个短码数据库插入就会报错需要重试加上随机盐。两种方案对比我倾向于发号器因为它生成效率高、天然有序、方便分库分表。但你把两种方案的优劣都讲清楚面试官会认为你是真的理解而不是只会一种写法。重定向的状态码选 301 还是 302这个问题很小但能区分出候选人有没有踩过生产环境的坑。301 是永久重定向用户的浏览器和 CDN 会把跳转结果缓存住后续访问直接跳到原始 URL不经过短链服务这样做的好处是短链服务的压力更小坏处是你没法统计点击量了因为你根本收不到后续的请求。302 是临时重定向浏览器和 CDN 每次访问都会经过短链服务会让服务压力更大但能实时统计点击。业务上如果对数据准确性要求高选 302如果要求清缓存降低负载选 301。在普通短链服务里为了统计数据通常选 302配合 CDN 的边缘节点能力压力其实也不大。再提一个容易被问的细节短码过期怎么处理。我的方案是启动一个定时任务或者用延迟队列定期扫描 MySQL 里的过期短码把 Redis 缓存里的旧数据删掉再把 MySQL 里的标记位改掉。为什么不能只靠 Redis 的 TTL因为 MySQL 里的数据还占着空间查询过期短码会返回一个不存在的提示但物理数据一直在增长。业务定义短链有效期是 30 天冷数据如果你不及时清理存储成本会不断膨胀。6. 常见翻车现场系统设计面试中最容易挂掉的几种死法作为面试官我见过太多候选人在系统设计面试里翻车。他们不是不努力LeetCode 刷了三百题分布式理论也能讲得头头是道但一到面试就暴露出一堆致命问题。这一节我把最常见的翻车点整理出来每条都是真实面试中遇到过的希望你能避开。6.1 需求没澄清就画图最标准的死法“好的那我们就设计一个秒杀系统。”候选人听完这句话直接在白板上写下“浏览器 → Nginx → Redis → Kafka → 商品服务”之后开始讲。我立刻打断问“日活和峰值流量是多少”他愣住了。这就是最经典的翻车现场。需求是系统设计的约束条件没有约束的设计就是空中楼阁。你画出的每一个组件都应该因为某个明确的需求指标才有存在的必要。秒杀系统如果只有 1 万日活和 1000 QPS那上面的架构完全就是表演。所以我对所有候选人的第一个建议都是拿到题目后哪怕设计思路已经涌上心头也先用 3 到 5 分钟问清楚需求这是最稳的走法。6.2 只会背架构模板经不起一个“为什么”我面试过一个做过三年 Java 开发的候选人简历上写着精通微服务和消息队列。我让他设计一个答题系统他张口就是“Spring Cloud 全家桶加 Kafka 加 Redis”。然后我问他“你的 Kafka 在这里承担什么职责”他愣了一下“做消息队列啊解耦用的。”这个回答等于什么都没说。你用了 Kafka你就要能说清楚哪个环节削峰哪个系统解耦消息丢失和重复消费怎么处理消费积压怎么监控答不出来面试官只会觉得你在贴标签而不是在做工程决策。记住在系统设计面试里你每说一个组件都要做好被连续追问三次的准备。第一次问用途第二次问为什么用它第三次问换一个行不行。6.3 容灾和过期策略只字不提很多候选人的架构图里只有“晴天路径”完全没有“下雨天怎么办”的预案。系统设计考察的不只是正常流程还包括异常流程。数据丢失了怎么办服务挂了怎么办缓存雪崩了怎么办消息积压了怎么办这些问题你在生产环境里早晚会遇到面试官其实就是在模拟生产环境做 design review。我建议你画完架构图后主动花几分钟把异常场景过一遍。不要等面试官追问主动说“这个方案我考虑了缓存雪崩的预案”“这里我做了消息队列的重试和告警机制”。这种主动性会让面试官觉得你是一个有系统级思考能力的人而不是只会画图的画师。6.4 容量估算时口算失误越算越慌容量估算在紧张时很容易算错我自己当年也翻过车。当时让我设计一个即时通讯系统我算了半天 QPS结果少乘了一个 8最后带宽估算差了一个数量级直接被纠正。这里有个经验技巧估算时把问题拆成一连串简单的乘法除法每一步都大声说出来而不是沉默地心算。比如“1 亿用户乘以 5 次访问等于 5 亿除以 86400 秒等于 5800 左右峰值按 3 倍算就是 1.7 万 QPS”。每一步都说出来对方能跟上你的逻辑即使算错面试官也能第一时间帮你纠偏不会让你一直在错误的方向上狂奔。7. 系统设计面试的终点是沟通能力做技术这些年不管是作为候选人还是面试官我越来越觉得系统设计面试其实是在考一件更本质的事你怎么跟人合作解决一个复杂问题。你有没有耐心把需求问清楚你能不能把复杂的概念讲得别人能听懂你能不能接受别人对你的方案提出质疑并给出有理有据的回应这些能力跟架构能力同样重要甚至更加重要。我的习惯是画完架构图主动跟面试官对齐思路说“这是我目前的大方向你看有没有哪些点需要调整”。这听起来像示弱但其实是高情商的做法。它把面试从“审判”变成“合作”面试官会不自觉地从挑刺模式切换到帮你完善方案的模式。我在面试中遇到这样的候选人哪怕他方案里有一些瑕疵我也更愿意给机会因为和一个能顺畅对话的人共事比和一台技术百科全书共事要舒服得多。在准备好的前提下把面试当成一次普通的技术方案讨论你的真实水平才能正常发挥出来。