--- name: system-design description: 系统设计怎么面：需求澄清、容量估算、选型、分片、一致性、容错。架构面与后端岗读。 keywords: [系统设计, 架构设计, 高并发, 容量估算, 分布式, 一致性, 缓存, 消息队列, 限流, 容错, system design, architecture, 后端, 基础架构, 全栈] layer: base --- ## 面试官在意什么 系统设计题在国内一线互联网公司通常出现在二面或三面，形式是给一个业务场景（短链、秒杀、feed、IM、点赞计数、订单超时关闭、分布式 ID），让候选人从零设计并接受连续追问；外企的 system design round 更强调候选人主导流程：澄清需求、估算规模、画出高层设计、深入一两个组件、讨论权衡与失败模式。面试官真正评估的不是画出的架构图有多完整，而是候选人能否把每一个组件的存在理由说清楚，能否在被追问"如果 X 变了"时调整方案而不是崩溃。 校招候选人的系统设计题会明显降低复杂度：问的是"为什么要有缓存、为什么要有队列、怎么保证不超卖"这种单点决策，以及能否用估算把"高并发"变成具体的数字；社招则要求完整的取舍能力：CAP 层面的选择、数据分片键的确定、跨服务一致性的处理、灰度与回滚、成本。 面试官最在意三件事：第一，先问清楚再设计——不问规模、读写比、一致性要求就直接上架构图的候选人几乎必然得低分；第二，数字感——能把"千万用户"翻译成 QPS、存储量、带宽，并据此判断需不需要分片、需不需要缓存；第三，失败模式——每一个组件挂了系统会怎样，数据会不会丢、会不会重、会不会不一致，候选人有没有想过。 怎么问才像这个方向的面试官： - 系统设计题必须从需求澄清开始，候选人不问规模就动手时先不打断，之后用"如果流量是你假设的十分之一/十倍"检验其设计是否过度或不足。 - 每个组件都追问"去掉它会怎样"和"它挂了会怎样"，考存在理由与失败模式，不考画图完整度。 - 校招把题目降到单点决策与估算，重点看数字感与因果推理；社招必须涉及跨服务一致性、分片、故障恢复与成本取舍。 - 不考中间件的名词版本与配置项，考选型理由与替代方案；候选人用了不熟悉的中间件时允许其用自己熟悉的替代来讨论。 ## 项目 / 实习怎么深挖 简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 project-deep-dive。 - 简历出现"高并发""秒杀""抢购" → 追每一层拦截的流量数字、防超卖手段、幂等设计。 - 简历出现 Redis 缓存 → 追一致性策略的失败窗口、热 key 处理、命中率。 - 简历出现消息队列 → 追投递语义、消费幂等、积压处理与监控。 - 简历出现分库分表 → 追分片键选择依据、跨分片查询方案、扩容迁移步骤。 - 简历出现微服务 → 追服务边界划分依据、跨服务一致性方案、超时与熔断配置。 - 简历出现"高可用""99.9%" → 追单点在哪、主从切换的数据窗口、真实故障经历。 - 简历出现自研中间件或框架 → 追为什么不用现成的、设计的失败模式、被谁用过。 ## 常见失守与危险信号 - 需求澄清与范围界定：不问任何问题直接画图；把所有需求都当成必须满足；说不出功能需求与非功能需求的区别。 - 容量估算：不会把日活转成 QPS；估算完不回到设计决策；数量级错误却没有察觉（比如算出单机需要 10TB 内存仍然不改方案）。 - 存储选型：所有场景都选 MySQL 或都选 MongoDB；说不出访问模式和存储结构的关系；把"NoSQL 快"当理由。 - 缓存策略：只会背"三个雪崩"名词；一致性策略只有"先删缓存再更新数据库"却说不出竞态；对热 key 没有任何思路。 - 数据分片与扩展性：分片键随手选主键 ID；对跨分片查询的回答只有"用 ES"；不知道扩容需要迁移数据。 - 一致性与幂等：所有跨服务写都答"用分布式事务框架"；幂等只说"加个唯一索引"不考虑乱序；不知道对账。 - 消息队列与异步化：把队列当万能解耦而不谈可靠性；不知道至少一次投递意味着必须幂等；积压只答"加消费者"。 - 限流、降级与容错：只会背限流算法名；不知道超时应该短于调用方超时；降级方案是"返回错误"。 - 高可用与故障处理：高可用只说"部署多台"；不知道主从切换会丢数据；把多活当默认选项。 - 分布式 ID 与延迟任务：延迟任务只答"定时扫表"不考虑压力；不知道 Redis 过期事件不可靠；雪花算法说不出时钟回拨。 - 可观测性与上线：监控只有"看日志"；说不出 SLO；上线方式是全量直接切。 - 完整场景推演：直接背出一张图但说不清每一层的存在理由；被注入故障后方案推倒重来；不知道自己设计的瓶颈在哪。 ## 常考主题清单 只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 JD 与这份简历定，不是配额。 ### 需求澄清与范围界定 - 阶梯：让候选人列出该问什么 → 功能需求与非功能需求（延迟、可用性、一致性）的区分 → 哪些需求互相冲突、怎么排优先级 → 面试官故意改一个约束，看方案怎么变 - 答实的标志：先问规模、读写比、延迟与一致性要求；能识别关键约束；主动声明假设并请面试官确认。 ### 容量估算 - 阶梯：日活转换成 QPS 的方法 → 峰值与均值的倍数、存储量的推算 → 用估算结果决定单机能否扛住、需不需要分片 → 估算偏差一个量级时设计是否仍然成立 - 答实的标志：估算过程有假设、有单位换算；能说出峰值倍数的依据；估算结果直接驱动分片、缓存、异步化的决策。 ### 存储选型 - 阶梯：关系型和 NoSQL 的适用场景 → 按访问模式选存储（点查、范围、全文、时序、图） → 一个业务里为什么会同时用多种存储、数据怎么同步 → 选错存储的代价与迁移路径 - 答实的标志：从访问模式和数据模型出发；能说出各存储的写放大、读放大或一致性代价；知道多存储共存时的同步方案。 ### 缓存策略 - 阶梯：为什么要缓存、放哪一层 → 缓存与数据库的一致性策略（cache-aside、write-through、延迟双删） → 穿透、击穿、雪崩各怎么防，热 key 怎么发现与处理 → 缓存命中率多少以下就不值得 - 答实的标志：能说出一致性策略的失败窗口；有本地缓存加多级缓存的热 key 方案；知道缓存监控指标；能评估缓存引入的复杂度。 ### 数据分片与扩展性 - 阶梯：单库单表的上限在哪 → 分片键怎么选、为什么 → 跨分片查询、跨分片事务、热点分片怎么办 → 扩容时数据怎么迁移、一致性哈希与范围分片的取舍 - 答实的标志：分片键从查询模式反推；有异构索引表或冗余写的方案；能说出扩容方案与双写迁移的步骤。 ### 一致性与幂等 - 阶梯：强一致、最终一致分别适用什么场景 → 幂等的实现手段（唯一键、状态机、去重表、token） → 跨服务写操作的一致性方案（本地消息表、事务消息、Saga、TCC）与各自失败点 → 什么时候该放弃分布式事务用对账兜底 - 答实的标志：能区分一致性等级并对应业务；幂等设计考虑并发与乱序；知道最终一致的补偿与人工介入路径。 ### 消息队列与异步化 - 阶梯：为什么要引入队列、削峰和解耦分别指什么 → 消息丢失、重复、乱序的成因与对策 → 消费积压怎么发现与处理、死信怎么办 → 同步改异步后用户体验与可观测性的代价 - 答实的标志：能说出投递语义与业务匹配；有积压监控与限流、扩容、丢弃策略；考虑了异步后的状态查询。 ### 限流、降级与容错 - 阶梯：限流算法（固定窗口、滑动窗口、令牌桶、漏桶）的差异 → 限流放在网关还是服务、按什么维度 → 依赖服务超时或宕机时的熔断、降级、兜底数据 → 降级开关谁来拨、怎么防误伤核心链路 - 答实的标志：超时、重试、熔断、隔离（线程池或信号量）成体系；有兜底数据方案；知道重试风暴与退避。 ### 高可用与故障处理 - 阶梯：单点在哪、怎么消除 → 主从切换的数据丢失窗口与脑裂 → 一次机房故障时哪些功能可用、哪些不可用 → 多活的成本与一致性代价，什么业务值得做 - 答实的标志：能说出每个组件的故障模式和恢复时间；有数据丢失的业务补偿方案；对多活有成本认知。 ### 分布式 ID 与延迟任务 - 阶梯：为什么不能用自增主键 → 雪花算法的位分配与时钟回拨、号段模式的双 buffer → 发号服务本身挂了怎么办 → 延迟任务（订单超时）用轮询、Redis ZSet、MQ 延迟消息的取舍 - 答实的标志：方案按量级与可靠性要求选择；考虑了任务丢失与重复执行；发号有降级路径。 ### 可观测性与上线 - 阶梯：新系统上线前要有什么监控 → 指标、日志、链路追踪各解决什么问题 → 一次"接口偶发超时"从哪些指标开始查 → 灰度发布怎么切流量、怎么定回滚标准 - 答实的标志：有 RED 或 USE 类指标体系；有告警阈值与 SLO；灰度有量化的推进与回滚标准。 ### 完整场景推演 - 阶梯：给一个常见系统（短链、点赞、IM、秒杀、feed）要求完整设计 → 深入其中一个组件的读写路径 → 面试官注入一个故障或十倍流量看方案调整 → 讨论这个设计最先需要重构的地方 - 答实的标志：分层漏斗有数字；每个组件有失败模式说明；能指出自己设计的下一个瓶颈与演进方向。