系统设计

概览

面试权重：★★★ | 适用级别：P7/P8+ | 预计复习时间：2-3周

大厂高级后端的系统设计题，不只是“会不会画图”，更重要的是能否在有限时间内说清楚需求、约束、架构主线、关键 trade-off 和演进路径。

建议用法

把这一章当成“系统设计答题脚手架”来复习。先熟悉方法论和答题顺序，再把典型题按“需求澄清 -> 高层方案 -> 核心链路 -> trade-off -> 演进”反复口述。

一、知识体系

1. 系统设计方法论 ★★★

1.1 面试中的系统设计流程

核心结论
- 系统设计题考的不是你能否一次讲完所有组件，而是能否在有限时间里把问题逐步收敛，并持续做有依据的取舍。

需求澄清（3-5 分钟）
- 功能需求：核心用例
- 非功能需求：QPS、延迟、可用性、数据量
- 边界确认：哪些不需要设计
估算（2-3 分钟）
- 用户量、QPS、存储量、带宽
- 数量级估算即可，不需要精确
高层设计（5-10 分钟）
- 画出核心组件和交互
- API 设计
- 数据模型设计
详细设计（15-20 分钟）
- 核心模块深入
- 数据存储选型
- 缓存策略
- 消息队列使用
扩展与优化（5-10 分钟）
- 瓶颈分析
- 扩展方案
- 容错处理

原理展开
- 这个流程的价值在于先定边界，再做设计。没有澄清的架构图通常会越画越散，面试官一追问就暴露假设不成立。
面试怎么答
- “我会先确认需求和约束，再做量级估算，然后给高层架构，接着下钻核心链路，最后讲扩展、容错和演进。这样能保证回答是收敛的。”

1.2 需求澄清 checklist ★★★

典型澄清问题
- 核心用户路径是什么
- 峰值 QPS、日请求量、峰值持续时间
- 读多写少还是写多读少
- 允许的响应时间、错误率、延迟范围
- 是否需要强一致、顺序性、幂等
- 数据保留多久，是否有冷热分层
- 是否有成本、人力、交付周期约束
核心结论
- 高级岗要体现的不是“问得多”，而是“问得准”。好的澄清问题能直接决定后续方案空间。
什么叫问得准
原理展开
- 如果题目是 Feed 流系统，优先问读写比例和活跃用户规模；如果题目是支付系统，优先问一致性、幂等和对账要求；如果题目是日志系统，优先问吞吐、保留周期和查询模式。
面试怎么答
- “我会优先问那些直接影响架构选型的问题，比如流量峰值、一致性要求、保留周期和预算，而不是把通用 checklist 机械背一遍。”
易错点
- 问了一堆问题，但没有把答案转化成后面的技术取舍。

1.3 非功能需求拆解 ★★★

性能
- QPS、RT、TP99、吞吐量、并发数
可用性
- SLA 目标、容灾级别、单点容忍度
一致性
- 强一致、最终一致、可接受的数据延迟
扩展性
- 水平扩展能力、分片能力、异步扩展能力
安全与合规
- 鉴权、审计、数据脱敏、权限边界
成本
- 机器成本、研发复杂度、值班和运维成本
核心结论
- 系统设计题真正拉开差距的地方，往往就在非功能需求。因为组件可以背，权衡不能靠背。
面试怎么答
- “我会把非功能需求拆成性能、可用性、一致性、安全和成本五类，然后明确哪几个是主约束，因为技术方案一定是围绕主约束展开的。”

1.4 核心设计原则 ★★★

无状态设计：服务层无状态，便于水平扩展
分层架构：接入层 → 服务层 → 数据层
读写分离：读多写少场景优化
CQRS：命令查询职责分离
最终一致性：在一致性和可用性之间取舍
分治思想：分库分表、分片、分区
原理展开
- 这些原则不是教条，而是常见系统设计的压缩表达。高级岗回答时，最好把原则和场景绑定，比如“为什么这里适合无状态”“为什么这里要读写分离而不是强行扩库”。
面试怎么答
- “我会优先用无状态和分层设计保证可扩展，再根据读写比例决定是否引入读写分离、CQRS 或最终一致性方案。”

1.5 技术选型与 trade-off 表达模板 ★★★

推荐表达顺序
1. 先说约束
2. 再说主方案
3. 明确收益
4. 明确代价
5. 给出演进方向
例子
- “当前峰值流量高、写链路短、可接受秒级延迟，因此我会先用 Redis + MQ 做削峰和最终一致，而不是一开始上强一致分布式事务。”
常见 trade-off
- Redis 缓存 vs 直接查库
- MQ 异步 vs 同步调用
- 最终一致 vs 强一致
- 分库分表 vs 单库优化
- 微服务拆分 vs 保持单体
核心结论
- 面试官一般不怕你做取舍，怕的是你不知道自己放弃了什么。
面试怎么答
- “我会先说当前场景最重要的目标是什么，再解释为什么主方案最匹配，以及它带来的复杂度和未来的升级路径。”
易错点
- 只说优点，不说成本；或者把备选方案直接否定掉，而不是说明当前为何不选。

1.6 估算速查表 ★★

指标	参考值
QPS（单机 Web）	~1000
QPS（单机 Redis）	~100,000
QPS（单机 MySQL）	~5,000（简单查询）
1 天秒数	~86,400 ≈ 10^5
1 亿	10^8
1GB	10^9 bytes

面试怎么答
- “估算表不是标准答案，而是帮助我快速判断量级是否离谱。高级岗不追求精确到个位，重点是估算逻辑是否自洽。”

1.7 面试作答模板 ★★★

明确需求与约束
给出容量估算
画高层架构图
深入核心链路
讲数据模型与存储
讲一致性、可用性、稳定性
讲扩展和演进
主动补充风险与回滚方案

面试怎么答
- “如果时间紧，我也至少会保证前四步完整，再补一致性和演进。比起讲得多，更重要的是有主线。”

1.8 图怎么画：高层图、时序图、部署图 ★★

高层架构图
- 最常用，适合开场阶段
- 关注模块边界、主链路、核心依赖和同步/异步关系
时序图（Sequence Diagram）
- 适合解释下单、支付、消息投递、补偿、幂等等有明显交互顺序的题
- 面试里不用画标准 UML 全语法，关键是把参与方、调用方向、关键状态写清楚
部署图 / 拓扑图
- 适合讲多机房、多副本、缓存层、MQ、数据库主从、容灾拓扑
- 尤其适合高可用、异地多活、日志系统等题
实战建议
- 开场先高层图
- 被追问核心流程时再补时序图
- 被追问高可用和容灾时再补部署图
- 目标是帮助表达，不是为了画 UML 而画 UML
面试怎么答
- “我会先用高层图定边界，再按追问补时序图或部署图。画图是为了提升表达效率，不是展示制图能力。”

2. 典型系统设计题 ★★★

2.1 短链接服务（URL Shortener） ★★★

核心设计
- 生成策略：Hash（MD5 / MurmurHash 取前 N 位）/ 自增 ID + Base62 编码
- 存储：MySQL（长链 → 短码映射）+ Redis 缓存
- 302 重定向（可统计）vs 301 重定向（浏览器缓存）
关键问题
- Hash 冲突处理
- 自定义短链
- 过期清理策略
- 防刷 / 安全
扩展
- 数据量大：分库分表（短码取模）
- 高 QPS：多级缓存 + CDN
核心结论
- 这类题重点不在“能不能缩短链接”，而在唯一性、跳转性能、统计能力和扩展策略。
面试怎么答
- “如果优先要唯一且简单，我会选自增 ID + Base62；如果更看重无中心生成能力，可以选 Hash，但要处理冲突。再结合 Redis 和 CDN 保证高跳转性能。”

2.2 秒杀系统 ★★★

架构分层
- CDN + 静态页面
- 网关限流（令牌桶）
- 服务层：内存预判 + Redis 原子扣减
- MQ 异步下单
- 数据库：乐观锁扣库存
核心问题
- 超卖：Redis Lua 原子操作
- 恶意请求：风控 + 验证码
- 库存预热：提前加载到 Redis
- 订单超时：延迟队列自动取消
核心结论
- 秒杀题的高分点是“层层过滤 + 库存一致性 + 降级兜底”，而不是一上来只说 Redis Lua。
面试怎么答
- “我会从入口拦截、库存控制、异步下单和数据库兜底四层回答，重点说明如何防超卖、如何应对重复下单，以及失败后的补偿。”

2.3 即时通讯（IM）系统 ★★★

消息模型
- 单聊 / 群聊 / 系统通知
- 消息 ID 生成（有序）
- 消息存储：写扩散 vs 读扩散
长连接方案
- WebSocket / 长轮询
- 连接管理与心跳
- 消息推送网关
核心问题
- 消息可靠投递：ACK 机制
- 消息顺序性：序列号
- 离线消息同步
- 已读回执
- 消息搜索（ES）
核心结论
- IM 题真正考的是长连接管理、消息可靠性、顺序性和离线同步，而不是只会说 WebSocket。
面试怎么答
- “我会先定义消息模型和连接层，再说明存储、投递、ACK 和离线同步。群聊和单聊的扩散策略往往是面试官重点追问点。”

2.4 Feed 流系统（微博 / 朋友圈） ★★★

推拉模型
- Push（写扩散）：发布时写入所有粉丝 inbox，读快写慢
- Pull（读扩散）：读取时拉取关注人 Timeline，读慢写快
- 推拉结合：大 V 用 Pull、普通用户用 Push
关键设计
- Timeline 排序（时间线）
- 缓存预热
- 大 V 发文的扩散问题
核心结论
- Feed 流题核心是扩散模式 trade-off。大 V 问题、时间线合并和缓存策略是高频深挖点。
面试怎么答
- “普通用户适合 Push，大 V 适合 Pull，实践里通常混合使用。真正的设计重点是写扩散成本、读延迟和热点用户带来的资源压力。”

2.5 分布式文件存储 ★★

小文件合并存储
元数据管理
副本策略与一致性
参考：HDFS、FastDFS、MinIO
面试怎么答
- “这类题要先区分元数据和文件块数据，再讲副本、容灾和冷热分层。真正的难点通常不在上传，而在海量小文件和故障恢复。”

2.6 延迟任务系统 ★★

方案对比
- 数据库轮询
- Redis ZSet（score=执行时间）
- 时间轮（HashedWheelTimer）
- 延迟消息队列（RocketMQ 延迟消息）
精度与可靠性权衡
面试怎么答
- “选型要看任务量级、延迟精度和可靠性要求。小规模可以先用 ZSet，大规模高可靠通常更适合专业 MQ 或调度系统。”

2.7 限流计数系统（Rate Limiter） ★★

单机方案：令牌桶 / 滑动窗口
分布式方案：Redis + Lua
多维度限流：用户 + 接口 + IP
面试怎么答
- “我会区分单机与全局限流，再说明计数存储位置、限流精度和被限后的处理方式。”

2.8 搜索系统 ★★

索引构建：全量 + 增量
查询优化：分词、同义词、纠错
排序策略：相关性 + 业务权重
ES 集群架构
面试怎么答
- “搜索题重点不是只说 ES，而是讲清建索引、更新延迟、召回和排序链路，以及热查询缓存和索引生命周期。”

2.9 权限系统（RBAC） ★★

用户 → 角色 → 权限模型
RBAC0/1/2/3
数据权限 vs 功能权限
前后端权限一致性
面试怎么答
- “权限题要同时覆盖认证、授权和审计。高级岗最好补一句数据权限和功能权限不能混成一套粗粒度模型。”

2.10 通知 / 推送系统 ★

多渠道：APP 推送 / 短信 / 邮件 / 站内信
模板管理
频率控制与用户偏好
推送到达率优化
面试怎么答
- “通知系统的关键是渠道编排、重试限频和用户偏好，而不是简单把多渠道堆在一起。”

2.11 AIGC 集成 ★（前沿加分）

LLM API 集成：OpenAI / Claude API 调用，生成摘要、文案、客服回复
架构要点：异步调用（响应慢）、流式输出（SSE）、Token 限制与分批处理
向量检索（RAG）：Embedding + 向量数据库（Milvus / Pinecone）+ 召回增强生成
成本控制：缓存相似查询结果、模型降级策略
安全：Prompt 注入防御、输出过滤、敏感信息屏蔽
面试怎么答
- “AIGC 集成题最好围绕延迟、成本、上下文管理和安全治理来回答，不要只停留在‘接个大模型 API’。”

2.12 面试表达辅助图 ★

白板或在线文档里优先画三类图
- 模块图：适合先讲整体结构
- 时序图：适合讲主链路、补偿、重试、ACK
- 数据流 / 部署图：适合讲日志、搜索、异地多活、灰度发布
画图顺序建议
1. 先框主流程
2. 再标关键组件
3. 最后补缓存、MQ、DB、监控等辅助设施
不要一开始就把所有组件堆满，面试官更关心你的抽象能力和取舍意识

3. 架构模式 ★★（P8+）

3.1 事件驱动架构（EDA） ★★

事件源（Event Sourcing）
CQRS 模式
事件溯源 + 快照
面试怎么答
- “EDA 适合高解耦、可审计、异步扩展明显的场景，但也会引入一致性、回放和排障复杂度。”

3.2 分层架构

传统三层：Controller → Service → DAO
六边形架构（Hexagonal）
洋葱架构（Onion）
整洁架构（Clean Architecture）
面试怎么答
- “这些架构模式的本质是依赖方向控制和边界隔离。高级岗回答时，最好结合团队规模和工程复杂度，而不是机械背定义。”

3.3 响应式架构 ★

反应式宣言
WebFlux / Project Reactor
背压（Backpressure）
面试怎么答
- “响应式适合 IO 密集和高并发连接场景，但前提是全链路都能接受异步模型，否则收益会被复杂度抵消。”

二、高频面试题

基础级（P7）

系统设计题你一般如何开场？为什么先做需求澄清？

30秒答法
- “我会先澄清核心功能、边界、峰值流量、延迟和一致性要求，再做量级估算，最后给高层架构。先澄清是为了避免设计跑偏，也能体现我是在做约束驱动的设计。”
关键词
- 需求澄清
- 约束驱动
- 量级估算
- 高层架构
追问提醒
- 常见追问：如果面试官不给明确数据，你会怎么做保守假设？

设计一个短链接服务，如何保证唯一性和高性能？

30秒答法
- “唯一性通常用自增 ID + Base62 最稳，或者用 Hash 方案但要处理冲突。高性能靠 Redis 缓存热点短链、必要时加 CDN，跳转一般用 302 便于统计。”
关键词
- Base62
- Hash 冲突
- Redis 缓存
- 302 跳转
追问提醒
- 可能继续追问：自定义短链、防刷和过期清理怎么做？

设计一个秒杀系统，如何防止超卖？

30秒答法
- “核心是层层过滤和双重校验。入口先限流和风控，库存先用 Redis Lua 做原子扣减，成功后再异步下单，数据库用乐观锁或唯一约束做最终兜底。”
关键词
- 限流
- Redis Lua
- MQ 异步下单
- 乐观锁
追问提醒
- 常见追问：Redis 扣减成功但下单失败，库存如何回补？

设计一个简单的 IM 系统，消息如何保证不丢？

30秒答法
- “我会先持久化消息，再推送给接收方，接收方 ACK 后再标记送达。客户端支持重发，服务端保留未 ACK 消息做离线同步，消息 ID 做幂等去重。”
关键词
- 持久化后推送
- ACK
- 离线同步
- 幂等去重
追问提醒
- 可能追问：群聊顺序性和多端同步怎么做？

Feed 流系统用推模型还是拉模型？为什么？

30秒答法
- “普通用户更适合 Push，读快但写扩散；大 V 更适合 Pull，写轻但读时合并成本更高。实践通常用推拉结合，根据粉丝规模和活跃度动态选择。”
关键词
- Push
- Pull
- 大 V
- 推拉结合
追问提醒
- 常见追问：时间线排序和热点用户缓存如何设计？

设计一个日志收集系统，如何处理 TB 级日志？

30秒答法
- “典型链路是 Filebeat 采集、Kafka 缓冲削峰、Logstash 或 Flink 解析、ES 存储检索、Kibana 展示。TB 级重点是按 topic 和索引生命周期做分层，配冷热分离和分片扩展。”
关键词
- Filebeat
- Kafka
- Elasticsearch
- 冷热分离
追问提醒
- 可能追问：写入吞吐、索引膨胀和日志脱敏怎么处理？

进阶级（P8+深挖）

设计一个日活千万的 IM 系统，如何做消息存储和同步？

30秒答法
- “我会先拆连接层、消息层和存储层。消息按用户或会话分片存储，服务端维护同步位点做增量拉取，长连接网关负责在线推送，离线消息和多端同步通过 ACK 与位点机制保证。”
关键词
- 分片存储
- sync_key
- 长连接网关
- 多端同步
追问提醒
- 常见追问：群聊写扩散、消息顺序和消息漫游怎么平衡？

设计一个支持 10 亿用户的 Feed 流系统，大 V 发文如何处理？

30秒答法
- “核心是推拉结合。普通用户走 Push 保证读性能，大 V 不做全量写扩散，而是在读取时 Pull 大 V 时间线再合并排序，活跃用户配合缓存预热和分层存储。”
关键词
- 推拉结合
- 大 V Pull
- 时间线合并
- 缓存预热
追问提醒
- 可能追问：排序、翻页一致性和粉丝关系变化怎么处理？

设计一个全局唯一 ID 生成服务，日均生成 100 亿个 ID

30秒答法
- “我会优先选 Snowflake 这类分布式本地生成方案，保证高吞吐和低延迟，再用机器 ID 分配和时钟回拨保护保证可用性。对于极端情况，可以用号段模式做兜底。”
关键词
- Snowflake
- 机器 ID
- 时钟回拨
- 号段模式
追问提醒
- 常见追问：时钟回拨、机器号分配冲突和趋势递增如何处理？

设计一个异地多活的电商系统，核心是什么？

30秒答法
- “核心不是多机房部署，而是业务单元化和数据归属。交易数据尽量在归属单元内强一致处理，共享数据跨机房异步同步，再配合全局路由、切流和冲突裁决策略。”
关键词
- 单元化
- 数据归属
- 异步同步
- 冲突裁决
追问提醒
- 可能继续追问：库存、优惠券和订单状态跨机房怎么保证不冲突？

设计一个多租户 SaaS 平台，如何做数据隔离和资源管控？

30秒答法
- “隔离方案通常分独立库、独立 Schema 和共享表三档，按租户等级和合规要求选择。资源上要做租户维度的限流、配额和审计，避免大租户拖垮公共资源池。”
关键词
- tenant_id
- Schema 隔离
- 配额
- 审计
追问提醒
- 常见追问：租户迁移、跨租户查询和大客户单独扩容怎么做？

面试官不断追问“为什么不用强一致 / 为什么不用分库分表”，你该如何回答？

30秒答法
- “我不会直接否定追问方案，而是回到当前约束：现阶段最重要的是哪些指标、追问方案能解决什么、它的复杂度和代价是什么，以及在什么触发条件下我会升级到那个方案。”
关键词
- trade-off
- 当前约束
- 复杂度成本
- 触发条件
追问提醒
- 面试官常继续看你能否量化成本，而不是只说‘太复杂’。