系统设计·免费版
红线
- 不堆砌组件名词：每引入一个组件（缓存/队列/分库分表等）必须说明「解决什么问题、代价是什么」。
- 不跳过需求澄清：规模、读写比、延迟要求、一致性要求不知道就先问。
- 不编造业务数据：QPS、数据量、增长预期由用户给；缺失时标注"待确认"并给出估算假设。
- 不引用任何付费端点/专有服务：只用通用开源组件与公开方法。
何时使用
- 要设计一个新系统/服务，需要产出可评审的方案。
- 现有系统扛不住了，要找瓶颈和扩展路径。
- 准备系统设计面试，需要结构化思路。
- 要在几个架构方案间做选择。
反触发（不要用）：
- 只是写几行代码的小功能 → 不需要架构设计。
- 已有明确架构、只需实现细节 → 直接实现。
职责边界
- 做：结构化设计流程、容量估算、组件选型权衡、瓶颈分析。
- 不做：替用户拍板业务决策、保证性能达标（需实测验证）。
主流程
第 1 步：澄清需求与非功能目标（质检闸 A）
功能需求（一句话）：系统做什么？
非功能目标（必须问清，决定架构走向）：
| 维度 | 典型问题 | 影响 |
|---|---|---|
| 规模 | 日活多少？QPS 峰值？ | 是否要分布式 |
| 读写比 | 读多写少还是反过来？ | 是否加缓存、主从 |
| 延迟 | P99 要求多少 ms？ | 是否要 CDN、异步 |
| 一致性 | 能接受最终一致吗？ | 是否要分布式事务 |
| 数据量 | 总量、年增长 | 是否分库分表 |
| 可用性 | 几个 9？ | 是否多活、容灾 |
| 成本 | 预算约束 | 技术选型上限 |
> 质检闸 A：规模 + 读写比 + 一致性 三项若全缺 → 先提问，
> 或明确标注"以下基于假设：日活 10 万、读多写少、接受最终一致"。
第 2 步：容量估算（量级即可，别精确到个位数）
速算基准（记住这些）：
1 天 = 86,400 秒 ≈ 10^5 秒
1 QPS ≈ 每天 10^5 次请求
1 亿次/天 ≈ 1,200 QPS（峰值按 2–5 倍算，约 2,400–6,000）
存储：
一条记录 1 KB，1 亿条 ≈ 100 GB
文字：1 个汉字 ≈ 2–3 字节
图片：一张压缩图 ≈ 200 KB–2 MB
带宽：
1 QPS × 10 KB 响应 ≈ 80 Kbps
1,000 QPS × 10 KB ≈ 80 Mbps
算三件事：
- QPS（含峰值系数）
- 存储（总量 + 年增长）
- 带宽
> 目的不是精确，是判断"单机够不够""要不要上分布式"。
> 若单机扛得住，就别上分布式——复杂度是成本。
第 3 步：顶层架构
画出组件与数据流（文字版即可）：
用户 → CDN → 负载均衡 → [应用服务集群] → 缓存 → 数据库
↓
消息队列 → 异步任务
每个组件都要回答：
- 为什么需要它？（不加会怎样）
- 它带来什么新问题？（缓存一致性、队列延迟、运维复杂度）
第 4 步：数据模型
- 核心实体与关系（ER 要点）
- 存储选型：关系型 / 文档 / KV / 时序 / 对象存储，说明理由
- 索引设计：按查询模式建索引，不是按字段建
- 分库分表：只在单表数据量/写入量确实撑不住时才做，并说明分片键选择
第 5 步：关键流程
挑 1–2 个最核心/最难的流程，写清楚：
场景：<如 用户下单>
1. <步骤> → 涉及组件
2. <步骤>
3. <步骤>
一致性怎么保证：<事务 / 补偿 / 最终一致>
失败怎么回滚：<...>
第 6 步：瓶颈与扩展路径（质检闸 B）
常见瓶颈与对策：
| 瓶颈 | 表现 | 对策 | 代价 |
|---|---|---|---|
| 数据库读压力大 | 慢查询、CPU 高 | 加缓存、读写分离、加索引 | 一致性、缓存维护 |
| 数据库写压力大 | 写入延迟、锁等待 | 队列削峰、分库分表、批量写 | 复杂度 |
| 单机 CPU 到顶 | 响应变慢 | 水平扩容（需无状态） | 会话/状态外置 |
| 热点 Key | 单节点被打爆 | 本地缓存、Key 拆分、限流 | 一致性 |
| 网络带宽 | 吞吐上不去 | CDN、压缩、协议优化 | 成本 |
| 慢依赖（第三方） | 整体被拖慢 | 超时、熔断、降级、异步 | 复杂度 |
演进路径（别一步到位）：
阶段 1（0→1 万用户）：单机 + 单库，够用
阶段 2（1 万→100 万）：加缓存、读写分离、服务拆分
阶段 3（100 万+）：分库分表、多活、专项优化
> 质检闸 B：每个关键选择都必须有「为什么不选另一个」的一句话。
> 只说"用 Redis"不说"为什么不用本地缓存" → 打回。
常见错误
- 过早优化：日活 1000 就上微服务 + K8s + 分库分表。
- 组件堆砌：架构图画了 15 个框，说不清每个解决什么问题。
- 忽略一致性代价：加了缓存却不提缓存一致性方案。
- 只画架构不算容量：说"能扛千万级"但没算过 QPS 和存储。
- 不考虑失败：只画正常流程，没写超时/重试/降级。
输出模板
# <系统名> 设计方案
## 1. 需求与非功能目标
## 2. 容量估算（QPS / 存储 / 带宽）
## 3. 顶层架构
## 4. 数据模型与存储选型
## 5. 关键流程（1–2 个）
## 6. 瓶颈分析与演进路径
## 7. 权衡记录（选了什么 / 放弃了什么 / 为什么）
## 8. 待确认项
失败降级
- 信息严重不足 → 输出「基于假设的设计」并列出假设清单 + 待确认项。
- 用户只要快速思路 → 压缩为「架构一句话 + 三个关键选择 + 最大风险」。
- 规模很小 → 明确说"单机单体就够，别上分布式"，并说明什么情况下才需要改。
依赖
- 无外部依赖，纯方法论技能。
- 需要用户补关键数据时用
AskUserQuestion。
致谢
- 原创免费技能，基于公开通用的系统设计方法与容量估算实践，
由本技能作者重新组织与本地化撰写。 - 灵感参考 GitHub 社区系统设计笔记与架构设计类公开资料，内容全部原创重写。
- 采用 MIT 许可，不依赖任何专有实现或付费服务。
