需求澄清与容量评估
同样一句"做一个订单系统"，日订单 1 万和日订单 1000 万对应的是两套完全不同的架构。真正开始设计之前，必须先把模糊需求翻译成可计算的数字：多少用户、多少请求、读写比例、允许多久不可用、数据要存多久。本文给出一份可直接照着问的澄清清单，以及 QPS、存储、带宽的估算方法。
需求澄清清单
接到需求先按类别提问，把答案写进设计文档。答不上来的项，就是设计中的风险点。
| 类别 | 要问的问题 | 示例答案 |
|---|---|---|
| 功能边界 | 核心功能是什么，哪些可以后置 | 先做下单与支付，评价后置 |
| 用户规模 | 日活、月活、注册总量 | 日活 100 万，累计用户 5000 万 |
| 请求量 | 人均几次请求，读多还是写多 | 人均 20 次，读写比 10:1 |
| 数据量 | 单条多大，一年增长多少 | 单订单 2KB，日增 50 万单 |
| SLA | 可用性、延迟要求 | 99.95%，接口 TP99 < 200ms |
| 一致性 | 能否接受短暂不一致 | 金额强一致，统计可延迟 |
| 生命周期 | 数据保留多久，是否可归档 | 在线 1 年，之后归档冷存 |
| 成本上限 | 预算多少台机器 | 不超过 20 台 8C16G |
从日活推导 QPS
最常用的估算公式，先把日请求量摊到秒，再乘峰值系数：
日均请求数 = 日活用户数 × 人均请求数
平均 QPS = 日均请求数 / 86400（一天的秒数）
峰值 QPS = 平均 QPS × 峰值系数
峰值系数取多少要看业务形态：全天流量比较平稳的业务取 23；有明显高峰的（午休、晚八点、秒杀）取 510，甚至更高。容量设计必须按峰值 QPS 算，按平均值算出来的机器数量一定不够。
算例一：订单系统 QPS
已知：日活 100 万，人均下单 2 次，人均查询订单 8 次
写入日均请求 = 100万 × 2 = 200 万
读取日均请求 = 100万 × 8 = 800 万
总日均请求 = 1000 万
平均 QPS = 1000万 / 86400 ≈ 116
业务在晚 20:00-21:00 集中，峰值系数取 8
峰值 QPS = 116 × 8 ≈ 928
再留 30% 余量 → 按 1200 QPS 做容量规划
对照这张表看结论：
| 指标 | 计算值 | 设计含义 |
|---|---|---|
| 平均 QPS | ≈116 | 单机轻松扛住 |
| 峰值 QPS | ≈928 | 需要缓存 + 多实例 |
| 峰值写 QPS | ≈186（写入占 20%） | 单主库尚可承受 |
| 峰值读 QPS | ≈742 | 加从库或缓存即可 |
一个看起来"日均千万请求"的系统，拆到秒级只有不到 1000 QPS，用两台应用服务器加一个主从数据库就够。很多架构被过度设计的根源，就是没做这一步除法。
算例二：存储容量估算
存储估算的通用公式：
单行字节数 ≈ 各字段长度之和 × 1.5（索引与行开销膨胀）
年数据量 = 单行字节数 × 日增行数 × 365
总占用 = 年数据量 × 副本数 × (1 + 余量系数)
以订单表为例：
单行原始字段约 300 字节，膨胀系数 1.5 → 单行约 450 字节
日增 50 万单 → 日增约 450 × 500000 ≈ 225 MB
一年 ≈ 225 MB × 365 ≈ 80 GB
主从 2 副本 + 30% 余量 → 80 × 2 × 1.3 ≈ 208 GB
结论：一年约 80 GB 数据、200 GB 左右存储需求。单表 1.8 亿行（50 万 × 365）已经偏大，B+ 树索引层级增加、DDL 变更困难，应当考虑按时间或按用户维度拆分，具体做法见第 07~09 章。
算例三：带宽估算
带宽常被忽略，但图片、音视频类业务往往先卡在这里：
出带宽 = 峰值 QPS × 平均响应体大小
例：峰值 1000 QPS × 平均响应 50KB = 50 MB/s
换算：50 MB/s × 8 = 400 Mbps
按 400 Mbps 规划公网带宽，并按 1.5 倍留余量，即约 600 Mbps。若响应体主要是一张 2MB 的图片而峰值 QPS 为 500，出带宽直接飙到 1 GB/s（8 Gbps），此时必须上 CDN，而不是继续加应用服务器。
读写比与一致性等级
读写比决定要不要加缓存和从库，一致性等级决定能不能加。
| 业务数据 | 读写比（估） | 一致性要求 | 可用手段 |
|---|---|---|---|
| 商品详情 | 100:1 | 最终一致可接受 | 多级缓存、从库 |
| 订单状态 | 10:1 | 强一致 | 主库读写 + 幂等 |
| 库存扣减 | 写多读少热点 | 强一致 | 主库 + 分布式锁/乐观锁 |
| 统计报表 | 读多写少 | 分钟级延迟 | 离线计算 + 独立存储 |
SLA 与可用性换算
SLA 用"几个 9"表示，换算成人能感知的停机时长更直观：
| 可用性 | 年停机时长（约） | 月停机时长（约） |
|---|---|---|
| 99% | 3.65 天 | 7.2 小时 |
| 99.9% | 8.76 小时 | 43.2 分钟 |
| 99.95% | 4.38 小时 | 21.6 分钟 |
| 99.99% | 52.6 分钟 | 4.32 分钟 |
注意两个细节：
- 可用性是按可用时间比例算的，不是按请求成功率，二者要分别定指标；
- 99.99% 意味着发布、扩容、机房切换都必须做到不停机，方案复杂度会明显上一个台阶。
澄清阶段的常见坑
- 只问功能不问规模：功能清单再全，没有量级也无法定架构；
- 忽略峰值形态：日均不高但集中在 10 分钟内，等效峰值会放大几十倍；
- 漏算衍生流量：一次下单可能触发风控、库存、消息、对账等多次内部调用，内部 QPS 常是外部 QPS 的几倍；
- 忘记预留余量：容量规划至少留 30% 余量，用于应对突发流量和单机故障后的流量转移；
- 不算成本：只给方案不算机器与费用，方案很难通过评审。
小结：设计前先按清单澄清功能边界、规模、读写比、SLA 与数据生命周期，再用"日请求量 ÷ 86400 × 峰值系数"估算 QPS、用"单行大小 × 行数 × 副本 × 余量"估算存储、用"峰值 QPS × 响应体大小"估算带宽。数字算清楚，很多架构问题会自然消失。