系统设计题训练
1. 训练方法
系统设计题不要急着画图。建议按下面顺序：
需求澄清 -> 容量估算 -> 核心模型 -> 架构设计 -> 数据流 -> 异常流 -> 扩展与治理2. 题目一：设计库存防超卖系统
2.1 需求澄清
- 是否是单仓还是多仓。
- 是否有秒杀峰值。
- 是否允许预扣。
- 下单后多久未支付释放库存。
- 是否需要跨渠道共享库存。
2.2 参考答案结构
| 层级 | 设计 |
|---|---|
| 入口 | Gateway（网关）限流、用户幂等 |
| 缓存 | Redis（远程字典服务）热点库存预扣 |
| 核心 | 库存服务统一扣减 |
| 数据库 | MySQL（关系型数据库）条件更新兜底 |
| 异步 | MQ（消息队列）同步库存事件 |
| 补偿 | 超时释放、对账修复 |
2.3 必讲风险
- 重复下单。
- Redis（远程字典服务）和数据库不一致。
- 支付超时库存未释放。
- 热点 SKU（库存单位）打爆单点。
- MQ（消息队列）消息延迟。
3. 题目二：设计支付回调一致性系统
3.1 需求澄清
- 支付通道数量。
- 是否支持退款和部分退款。
- 回调是否可能重复、乱序。
- 是否需要每日对账。
3.2 参考答案结构
flowchart TD
A["支付通道 Webhook（回调通知）"] --> B["验签"]
B --> C["防重放"]
C --> D["幂等入库"]
D --> E["状态机流转"]
E --> F["MQ（消息队列）事件"]
F --> G["订单/库存/账务"]
E --> H["对账和补偿"]3.3 必讲风险
- 回调重复。
- 回调延迟。
- 主动查询和回调状态冲突。
- 下游消费失败。
- 对账差异。
4. 题目三：设计跨境物流轨迹系统
4.1 需求澄清
- 轨迹来源是推送还是拉取。
- 日轨迹量级。
- 是否需要实时展示。
- 轨迹是否乱序。
- 历史数据保留多久。
4.2 参考答案结构
| 能力 | 方案 |
|---|---|
| 接入 | API（应用程序接口）接收或定时拉取 |
| 削峰 | Kafka（分布式日志消息系统）或 RocketMQ（分布式消息队列） |
| 幂等 | 运单号 + 轨迹节点 + 时间 |
| 状态 | 状态机合并轨迹 |
| 查询 | MySQL（关系型数据库）主记录 + Elasticsearch（搜索引擎）搜索 |
| 归档 | 历史轨迹冷热分离 |
5. 题目四：设计 IoT（物联网）报警风暴治理系统
5.1 需求澄清
- 设备数量。
- 报警峰值。
- 报警等级。
- 是否允许丢弃低级报警。
- 通知渠道有哪些。
5.2 参考答案结构
接入限流 -> MQ（消息队列）削峰 -> 窗口聚合 -> 分级路由 -> 通知 -> 存储 -> 复盘5.3 必讲风险
- 低级报警刷屏。
- 高级报警被降噪误伤。
- MQ（消息队列）积压。
- 通知渠道限流。
- 设备重复上报。
6. 题目五：设计异步任务调度平台
6.1 需求澄清
- 任务类型和优先级。
- 是否需要定时任务。
- 是否允许重复执行。
- 失败是否自动重试。
- 是否多实例部署。
6.2 参考答案结构
| 模块 | 方案 |
|---|---|
| 任务存储 | MySQL（关系型数据库）记录任务状态 |
| 调度 | 分片扫描、乐观锁抢占 |
| 执行 | Runner（执行器）线程池隔离 |
| 重试 | 指数退避、最大次数 |
| 补偿 | 死信任务、人工重跑 |
| 观测 | 成功率、失败率、积压量、耗时 |
7. 题目六：设计高可用订单系统
7.1 参考答案结构
- Gateway（网关）限流。
- 订单服务无状态多实例。
- MySQL（关系型数据库）主从和备份。
- Redis（远程字典服务）缓存热点数据。
- MQ（消息队列）异步通知。
- Trace（链路追踪）贯穿全链路。
- 灰度发布和快速回滚。
8. 容量估算与压测检查点
系统设计题里，如果只讲服务拆分和组件选型，会像“画图题”。架构师面试要主动补一层容量口径：业务量、峰值、实例数、资源规格、压测方法、监控指标和扩容阈值。
8.1 通用容量估算模板
第一步：业务量
日订单量、日请求量、设备数、轨迹量、支付回调量、峰值时间窗口。
第二步：峰值换算
峰值 TPS（每秒事务数） = 日业务量 * 峰值占比 / 峰值秒数
内部 QPS（每秒查询率） = 峰值 TPS（每秒事务数） * 平均内部调用次数
第三步：资源估算
单实例能力来自压测，不凭经验拍数。
实例数 = 目标峰值 / 单实例稳定能力 * 冗余系数。
第四步：压测验证
看 QPS（每秒查询率）、TPS（每秒事务数）、P95（95 分位响应时间）、P99（99 分位响应时间）、错误率、CPU（中央处理器）、内存、GC（垃圾回收）、线程池、连接池、数据库慢 SQL（结构化查询语言）、Redis（远程字典服务）命中率和 MQ（消息队列）积压。8.2 库存防超卖容量检查点
| 检查点 | 面试要说清 |
|---|---|
| 峰值 TPS（每秒事务数） | 下单、库存预扣、支付成功扣减分别估算 |
| 热点 SKU（库存单位） | 是否存在单 SKU（库存单位）瞬时高并发 |
| Redis（远程字典服务）能力 | Lua（脚本语言）预扣耗时、hot key（热键）、内存和网络 |
| MySQL（关系型数据库）兜底 | 条件更新 TPS（每秒事务数）、锁等待、慢 SQL（结构化查询语言） |
| P99（99 分位响应时间） | 热点库存扣减时是否长尾升高 |
| 压测重点 | 重复下单、超卖、少卖、支付超时释放、MQ（消息队列）延迟 |
口述补充：
库存系统我会把性能和正确性分开看。Redis（远程字典服务）负责削峰和预扣，MySQL（关系型数据库）负责最终不超卖；容量上看热点 SKU（库存单位）的峰值 TPS（每秒事务数）和数据库条件更新能力，压测时不能只看 QPS（每秒查询率），还要校验库存结果是否正确。
8.3 支付回调一致性容量检查点
| 检查点 | 面试要说清 |
|---|---|
| 回调 TPS（每秒事务数） | 正常支付、活动峰值、通道重试峰值 |
| 幂等冲突数 | 重复 Webhook（回调通知）和主动查询冲突 |
| 状态机耗时 | 支付单、订单、账务状态流转耗时 |
| 下游 MQ（消息队列） | 消费成功率、dead letter（死信）数量、重试次数 |
| 可用性 | 支付核心链路优先级高于通知和报表 |
| 压测重点 | 重复、乱序、延迟、验签失败、通道超时 |
口述补充：
支付回调不能只压接口吞吐，还要压幂等和状态机。比如同一通道事件重复进来时，只允许一条成功流转；下游失败要靠 MQ（消息队列）重试和对账补偿，不能让资金状态悬空。
8.4 跨境物流轨迹容量检查点
| 检查点 | 面试要说清 |
|---|---|
| 轨迹 msg/s（每秒消息数） | 推送和拉取分别估算 |
| 第三方 API（应用程序接口） | RT（响应时间）、超时率、限流规则 |
| MQ（消息队列） | backlog（积压量）、consumer lag（消费者延迟）、Partition（分区）热点 |
| 数据库写入 | 批量写入、幂等索引、历史归档 |
| 查询体验 | 最新轨迹优先，历史轨迹冷热分离 |
| 压测重点 | 乱序、重复、延迟、外部接口慢、批量入库 |
口述补充：
跨境物流的稳定性重点不是单接口 QPS（每秒查询率），而是外部接口慢、轨迹乱序、MQ（消息队列）积压和批量写入能力。主链路要异步化，外部慢依赖要隔离。
8.5 IoT（物联网）报警风暴容量检查点
| 检查点 | 面试要说清 |
|---|---|
| 设备规模 | 在线设备数、单设备上报频率 |
| 峰值 msg/s（每秒消息数） | 故障风暴时的瞬时上报 |
| 聚合率 | 窗口聚合前后消息量变化 |
| 通知能力 | 短信、邮件、站内信、Webhook（回调通知）限流 |
| 队列保护 | 高级报警和普通报警分流 |
| 压测重点 | 突增流量、降噪误伤、通知限流、MQ（消息队列）积压 |
口述补充：
IoT（物联网）报警风暴的目标不是把报警全吞掉，而是降低噪声同时保护高级报警。容量设计上要看峰值 msg/s（每秒消息数）、聚合率、通知通道能力和 MQ（消息队列）积压。
8.6 异步任务调度平台容量检查点
| 检查点 | 面试要说清 |
|---|---|
| 任务进入速率 | 每分钟新增任务数、定时任务集中触发 |
| Runner（执行器）吞吐 | 单 Runner（执行器）并发、平均任务耗时 |
| 积压量 | backlog（积压量）、最老任务等待时间 |
| 重试风暴 | 失败率、重试次数、指数退避 |
| 资源隔离 | 不同任务类型独立线程池和队列 |
| 压测重点 | 扫描抢占、重复执行、任务超时、失败重试 |
口述补充：
调度平台不能只看“能不能执行”，还要看任务进入速率和 Runner（执行器）消费能力是否匹配。失败重试必须退避，否则下游故障时会把系统拖进重试风暴。
8.7 高可用订单系统容量检查点
| 检查点 | 面试要说清 |
|---|---|
| 读写比例 | 查询 QPS（每秒查询率）和下单 TPS（每秒事务数）分开估算 |
| 实例规格 | 2C4G（2 核 CPU，4GB 内存）或 4C8G（4 核 CPU，8GB 内存）起步，压测校准 |
| 数据库 | 订单主表写入、索引、归档、读写分离 |
| 缓存 | 热点订单、商品、库存缓存命中率 |
| 发布容量 | 滚动发布时仍保留足够实例 |
| 压测重点 | 下单链路、库存链路、支付链路、MQ（消息队列）异步通知 |
口述补充：
订单系统要把查询 QPS（每秒查询率）和写入 TPS（每秒事务数）分开。查询可以靠缓存和读模型扩展，写入要看订单状态机、库存扣减、支付状态和数据库事务能力。
9. 业务指标与埋点检查点
系统设计题如果能补充业务指标，会更像资深工程师或架构师的回答：不仅知道系统怎么扛住，还知道业务结果怎么衡量、数据是否可信、异常变化怎么排查。
9.1 通用业务指标模板
第一步：定义业务目标
这个系统是提升交易转化、履约效率、库存准确率、报警处理效率，还是任务执行可靠性。
第二步：定义核心指标
PV（页面浏览量）、UV（独立访客数）、DAU（每日活跃用户数）、MAU（月活跃用户数）、Conversion Rate（转化率）、Retention Rate（留存率）、成功率、异常率、处理时长。
第三步：定义埋点和事实来源
前端埋点看曝光点击路径，后端埋点看业务结果，订单、支付、库存、履约必须以后端事实表和对账为准。
第四步：定义数据质量
说明 User ID（用户标识）、Device ID（设备标识）、Session ID（会话标识）、Event ID（事件标识）、去重规则、测试账号过滤、爬虫过滤和对账规则。9.2 库存防超卖业务指标
| 检查点 | 面试要说清 |
|---|---|
| 下单 Conversion Rate（转化率） | 商品页、下单、库存预扣、支付成功分步看 |
| 超卖拦截数 | 系统拦截的风险订单 |
| 少卖率 | 有库存但用户无法购买的比例 |
| 库存调整次数 | 库存不一致风险 |
| 支付超时释放量 | 库存冻结和释放是否合理 |
| 后端事实 | 库存流水、订单状态、支付状态 |
口述补充：
库存防超卖不能只讲不超卖，还要看是否少卖、是否影响下单 Conversion Rate（转化率）、库存冻结是否及时释放，以及库存流水和订单支付状态能否对账。
9.3 支付回调业务指标
| 检查点 | 面试要说清 |
|---|---|
| 发起支付数 | 用户进入支付步骤的数量 |
| 支付成功率 | 支付成功 / 发起支付 |
| Webhook（回调通知）延迟 | 通道成功到系统更新的耗时 |
| 对账差异数 | 通道流水和内部流水不一致 |
| Refund Rate（退款率） | 退款订单 / 支付成功订单 |
| 后端事实 | 支付流水、订单状态机、账务记录 |
口述补充：
支付系统的业务指标必须和资金事实一致。前端支付成功页只能作为用户行为参考，真正成功要看通道回调、主动查询和对账。
9.4 跨境物流业务指标
| 检查点 | 面试要说清 |
|---|---|
| 面单成功率 | 面单获取成功 / 面单请求 |
| 轨迹完整率 | 关键节点完整的运单比例 |
| 轨迹延迟 | 节点发生到系统可见的耗时 |
| 异常件率 | 异常运单 / 总运单 |
| 妥投率 | 妥投运单 / 发运运单 |
| 后端事实 | 运单表、轨迹表、状态机 |
口述补充：
跨境物流的业务指标要能反映履约质量。比如轨迹延迟升高时，要同时看第三方 API（应用程序接口）、MQ（消息队列）积压、消费者能力和状态机合并逻辑。
9.5 IoT（物联网）报警和 Runner（执行器）任务业务指标
| 场景 | 检查点 | 面试要说清 |
|---|---|---|
| IoT（物联网）报警 | 报警确认率 | 报警是否被闭环 |
| IoT（物联网）报警 | 重复报警率 | 降噪是否有效 |
| IoT（物联网）报警 | 高级报警触达率 | 关键风险是否穿透 |
| Runner（执行器）任务 | 任务成功率 | 平台可靠性 |
| Runner（执行器）任务 | 重试率 | 是否依赖重试掩盖问题 |
| Runner（执行器）任务 | 平均等待时长 | 调度能力和积压 |
口述补充：
IoT（物联网）报警治理要看报警质量和闭环，不只是吞吐量。Runner（执行器）调度平台要看任务成功率、重试率和等待时长，才能说明异步任务是否真正可靠。
10. 自测评分标准
| 维度 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| 需求澄清 | 直接讲方案 | 问少量问题 | 主动澄清规模、约束、质量目标 |
| 架构完整性 | 只有组件 | 有主链路 | 有主链路、异常链路、补偿链路 |
| 技术取舍 | 只说用了什么 | 能说优缺点 | 能结合业务说明为什么选和为什么不选 |
| 失败处理 | 很少提 | 提部分异常 | 系统性覆盖超时、重复、乱序、宕机、回滚 |
| 可观测性 | 不提 | 提日志 | 提 Log（日志）、Metrics（指标）、Trace（链路追踪）、告警 |
| 容量数据 | 不提 | 提少量 QPS（每秒查询率） | 能讲 TPS（每秒事务数）、P95（95 分位响应时间）、P99（99 分位响应时间）、资源规格、压测和扩容阈值 |
| 业务指标 | 不提 | 提少量 PV（页面浏览量）或 DAU（每日活跃用户数） | 能讲指标口径、埋点来源、业务事实、数据质量和异常排查 |
11. 练习计划
第一天：
- 库存防超卖。
- 支付回调一致性。
第二天：
- 跨境物流轨迹。
- IoT（物联网）报警风暴。
第三天：
- 异步任务调度平台。
- 高可用订单系统。
12. 精通级系统设计训练册入口
旧根保留系统设计题的快速题单和评分框架，精通级训练册负责把每一道题扩展成完整的答题合同：需求澄清、量级估算、API（应用程序接口）和数据模型、架构、正常关键路径、一致性、容量、安全、观测、失败、成本、迁移与演进。后续继续训练时，优先按下面路径进入。
| 训练文档 | 主训练题 | 核心不变量 | 图形资产 |
|---|---|---|---|
| 00-旧题映射统一答题合同与评分路线 | 把旧根题单升级为统一系统设计答题合同 | 所有题都必须先有可验收的不变量和事实等级 | PlantUML（开源建模工具）系统设计闭环图 |
| 01-WMS库存防超卖系统设计训练 | WMS（仓储管理系统）库存防超卖 | 可售、冻结、已扣、实物数量守恒 | PlantUML（开源建模工具）系统设计闭环图 |
| 02-支付资金一致性系统设计训练 | 支付交易、回调、查单、退款、对账 | 同一支付意图不能重复扣款，资金最终可对平 | PlantUML（开源建模工具）系统设计闭环图 |
| 03-跨境履约海外仓面单轨迹系统设计训练 | 跨境履约、海外仓、面单、轨迹 | 外部事实可追溯，终态不能被迟到事件非法回退 | PlantUML（开源建模工具）系统设计闭环图 |
| 04-异步导出与Runner（执行器）调度系统设计训练 | 大数据导出和 Runner（执行器）调度 | 任务快照明确，旧代次不能覆盖新结果 | PlantUML（开源建模工具）系统设计闭环图 |
| 05-IoT报警风暴治理系统设计训练 | IoT（物联网）报警风暴削峰与降噪 | 严重告警必须可达，普通告警可解释聚合 | PlantUML（开源建模工具）系统设计闭环图 |
| 06-高可用订单与跨域演进系统设计训练 | 高可用订单、跨域事件与演进迁移 | 订单状态唯一、跨域事件可恢复、灰度可回滚 | PlantUML（开源建模工具）系统设计闭环图 |
12.1 系统设计题统一口述顺序
- 需求澄清：先问参与者、范围、业务目标、核心不变量、允许延迟、外部依赖和成功标准。
- 量级估算：用日量、峰值窗口、请求放大、突增系数和冗余系数推导目标吞吐。
- 模型设计：给稳定业务键、状态机、版本号、幂等键、流水表和事件表。
- 架构设计：沿入口、领域裁决、权威存储、事件传播、下游投影和查询路径讲正常链路。
- 一致性设计：区分本地事务、可靠消息、补偿、查证、对账和人工复核。
- 失败恢复：主动讲最高成本故障，按发现、止血、定位、修复、恢复验收和复盘回答。
- 安全观测成本：覆盖鉴权、验签、审计、Log（日志）、Metrics（指标）、Trace（链路追踪）、告警和预算护栏。
- 迁移演进：用影子流量、双读校验、分群灰度、回滚阈值和存量处理说明方案如何落地。