想象你要在写字楼下面开一家网红奶茶店。开业前，你绝不会一拍脑袋就租门面、买设备，而是会先盘算：这栋楼每天有多少人进出？午休高峰那一小时能涌进多少顾客？冰箱要多大才够存一个星期的牛奶？要请几个店员才能不让队伍排到电梯口？容量估算，就是给软件系统做同一件事——在写一行业务代码之前，先算清楚系统每天要服务多少用户、每秒要处理多少请求、要囤多少数据、需要几台服务器。这套“算术”做对了，系统上线才稳如老店；做错了，就会像备错货的奶茶店一样，开业第一天就乱成一锅粥。这篇文章就沿着“开奶茶店”这条主线，带你把 DAU、QPS、存储、带宽、服务器这些词，一个个落成看得懂、算得出的数。

岗位关联

容量估算是系统设计面试的第一道门槛，也是 AI 工程师把模型从 Notebook 搬上生产环境前必须做的功课。学会它，你就能用数字说服老板该买多少机器、说服面试官你懂架构，而不是凭感觉拍脑袋。

目录
  1. 可视化演示
  2. 1. 需求澄清：先想清楚开一家什么店
  3. 2. 核心指标：开店要记的四本账
  4. 3. QPS 估算：算准高峰期的点单速度
  5. 4. 存储估算：仓库要租多大
  6. 5. 带宽估算：外卖通道要多宽
  7. 6. 服务器估算：要请多少店员
  8. 7. 方案复盘：开业前再盘一遍账
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

\u5C55\u793A\u8BF7\u6C42\u6D41\u7ECF\u670D\u52A1\u5668\u5230\u6570\u636E\u5E93\u7684\u5B8C\u6574\u94FE\u8DEF\uFF0C\u5E95\u90E8\u4EEA\u8868\u76D8\u663E\u793AQPS\u3001\u5E26\u5BBD\u3001\u5B58\u50A8\u4E09\u9879\u5BB9\u91CF\u6307\u6807\u3002

本节配有交互动效（进入视口后自动加载，约 3KB）。

\u7CFB\u7EDF\u5BB9\u91CF\u4F30\u7B97\u4E0E\u76D1\u63A7 \u8BF7\u6C42\u7ECF\u670D\u52A1\u5668\u5904\u7406\u540E\u8BBF\u95EE\u6570\u636E\u5E93\uFF0C\u6BCF\u4E2A\u73AF\u8282\u90FD\u9700\u5BB9\u91CF\u89C4\u5212 QPS\u4F30\u7B97\uFF1ADAU\u00D7\u65E5\u5747\u8BF7\u6C42/\u79D2\u6570\uFF0C\u5E26\u5BBD\u4F30\u7B97\uFF1AQPS\u00D7\u5E73\u5747\u54CD\u5E94\u5927\u5C0F \u7EA2\u8272\u865A\u7EBF\u4E3A\u5BB9\u91CF\u9608\u503C(80%)\uFF0C\u8D85\u8FC7\u9700\u6269\u5BB9\u6216\u4F18\u5316 C = DAU \u00D7 req/s \u00D7 peak_factor \u5B58\u50A8\u4F30\u7B97\u9700\u8003\u8651\u6570\u636E\u589E\u957F\u7387\u3001\u5907\u4EFD\u548C\u5197\u4F59\u7B56\u7565

1. 需求澄清：先想清楚开一家什么店

开奶茶店之前，聪明的老板不会急着租门面、买机器，而是先想清楚三个问题：这家店开给谁喝？主打什么产品？堂食多还是外卖多？这三个答案直接决定备货量——主打写字楼午餐档，晚上八点后就没人了；开在夜市，白天备再多原料也是浪费。系统设计也一样，容量估算的第一步永远不是打开计算器，而是先“问问题”。

面试官让你“设计一个系统”，如果你张口就报数字，十有八九要凉。正确的开场是澄清需求：目标用户规模多大（几万还是几亿）？核心功能有哪些（发帖、刷信息流还是支付）？读写比例如何（读多还是写多）？这些参数是容量估算的“食材”，食材没定，菜谱就是空中楼阁。需要量化的输入主要有三类：用户规模，用注册数和 DAU 描述；功能与调用频率，梳理每个核心接口被调用的场景，估算人均每日请求次数；读写比例 $R_{rw}$，即读请求与写请求的比值。微博类系统读远多于写，$R_{rw}$ 可达 10:1 甚至 100:1，订单系统则读写接近。有了这个比例，后续就能把总 QPS 拆成读和写两份账单。

就像奶茶店老板先定下“外卖占八成”，才知道要请多少骑手、备多少打包盒——需求澄清锁定的读写比例，决定了后面所有资源分配的方向。方向错了，后面算得再精细也是白算。

QPSwrite=QPStotalRrw+1,QPSread=RrwRrw+1×QPStotalQPS_{write} = \frac{QPS_{total}}{R_{rw}+1}, \qquad QPS_{read} = \frac{R_{rw}}{R_{rw}+1}\times QPS_{total}
这个公式回答的是“总请求里，读和写各占多少份额”。读写比 $R_{rw}$ 是 9 时，每 10 次请求里 9 次是读、1 次是写。
  1. 读写比例 $R_{rw}$表示读请求是写请求的几倍，来自需求澄清阶段的业务判断。
    Rrw=NreadNwriteR_{rw} = \frac{N_{read}}{N_{write}}
  2. 总请求 $QPS_{total}$读写请求之和，是后续所有分配的基础，由下面第 3 节算出。
    QPStotal=QPSread+QPSwriteQPS_{total} = QPS_{read} + QPS_{write}
  3. 写占比 $\frac{1}{R_{rw}+1}$把“写 = 1 份”放入“读写总份数”，得出写请求的份额。
    Pwrite=1Rrw+1P_{write} = \frac{1}{R_{rw}+1}
  4. 读占比 $\frac{R_{rw}}{R_{rw}+1}$总份额减掉写份额，剩下的就是读份额。
    Pread=RrwRrw+1P_{read} = \frac{R_{rw}}{R_{rw}+1}

2. 核心指标：开店要记的四本账

奶茶店老板每天盯四样东西：进店人数、点单速度、冰箱库存、外卖通道的承接力。这四样一一对应系统设计的四个核心指标：DAU、QPS、存储量和带宽。它们就是容量估算的“四本账”，后面所有计算都围着它们转。

先认识这四个词。DAU（Daily Active Users，日活跃用户）指一天内实际使用产品的去重人数，是规模的地基；QPS（Queries Per Second，每秒查询数）指系统每秒能处理的请求数量，是速度的标尺；存储量回答“数据要占多大仓库”；带宽回答“数据流动要多宽的路”。特别提醒：QPS 是“每秒”的量，DAU 是“每天”的量，两者之间隔着一天 86400 秒，绝不能直接画等号——这就好比“一天进店 1 万人”和“一秒进店 1 万人”是两回事。

四本账之间有一条主线：DAU 乘以人均请求数，得到一天的请求总量；把请求总量按时间摊开，得到 QPS；请求经过网络，产生带宽；请求落库，产生存储。所以 DAU 是所有估算的共同起点。

老板记四本账，不是为了记账而记账，而是为了回答一个问题：明天的货够不够？系统的四本账同样服务于一个目标——在用户涌来时，系统不会说“对不起，爆了”。

Rday=NDAU×ruserR_{day} = N_{DAU} \times r_{user}
日请求总量 = 日活跃用户数 × 人均每日请求次数。它是一切的“总盘子”。
  1. $N_{DAU}$ 日活跃用户数一天内真实使用产品的去重人数，开店的“进店总人数”。
    NDAU=一天内使用产品的去重用户数N_{DAU} = 一天内使用产品的去重用户数
  2. $r_{user}$ 人均请求数每个用户平均每天发起多少次请求，由需求澄清阶段对用户行为的估算得出。
    ruser=所有用户一天的总请求次数NDAUr_{user} = \frac{所有用户一天的总请求次数}{N_{DAU}}
  3. $R_{day}$ 日请求总量两者相乘得到系统每天要处理的请求总数，是 QPS 和带宽计算的共同起点。
    Rday=NDAU×ruserR_{day} = N_{DAU} \times r_{user}

3. QPS 估算：算准高峰期的点单速度

奶茶店最怕的不是一天卖出 1000 杯，而是午休 20 分钟涌进 300 人。如果按全天平均每分钟 0.7 杯去雇人，队伍会从柜台排到电梯口。容量估算里，这个“午休瞬间”就是峰值 QPS，它决定系统的生死。

QPS 估算分两步：先算平均，再算峰值。平均 QPS 用第 2 节的日请求总量 $R_{day}$ 除以活跃时长——注意不是除以 24 小时，因为深夜几乎没有流量，要把流量集中的那段时间（比如 16 小时）当作分母。然后把平均值乘以峰值系数 $\alpha$，得到系统真正要扛住的峰值。

峰值系数 $\alpha$ 是经验值，一般取 3 到 10。日常业务取 3 左右；有营销活动、秒杀、直播带货等突发流量场景，取 5 到 10。为什么不能取 1？因为用户行为天然聚集：午饭时间、晚上八点、周末晚上，请求量往往是低谷的五倍以上。按平均值设计，高峰期就会排起请求的“长队”。

回头看奶茶店：老板绝不会按“平均一分钟 0.7 杯”雇人，而是按“午休高峰一分钟 15 杯”备人。容量估算的核心心法就一句话：平均值用来算总量，峰值用来定规格。

QPSavg=RdayTon×3600,QPSpeak=α×QPSavgQPS_{avg} = \frac{R_{day}}{T_{on}\times 3600}, \qquad QPS_{peak} = \alpha \times QPS_{avg}
平均 QPS 把一天的请求均匀摊到活跃秒数上；峰值 QPS 乘上经验系数 $\alpha$，回答“最忙的那几秒要扛多少”。200 万 DAU、人均 20 次、16 小时活跃，平均约 694 QPS，$\alpha=3$ 时峰值约 2083 QPS。
  1. 分子 $R_{day}$一天的请求总量，来自第 2 节。
    Rday=NDAU×ruserR_{day} = N_{DAU} \times r_{user}
  2. 分母 $T_{on}\times 3600$把有流量的活跃时长从小时换算成秒，深夜时段不算。
    Ton×3600=活跃小时数×3600秒T_{on}\times 3600 = 活跃小时数 \times 3600 秒
  3. 平均 QPS $QPS_{avg}$请求总量摊到每秒，是“全天的平均点单速度”。
    QPSavg=RdayTon×3600QPS_{avg} = \frac{R_{day}}{T_{on}\times 3600}
  4. 峰值系数 $\alpha$经验值 3 到 10，把平均值放大到能扛住的峰值规格。
    QPSpeak=α×QPSavgQPS_{peak} = \alpha \times QPS_{avg}

4. 存储估算：仓库要租多大

奶茶店每天进货：一箱牛奶、一袋珍珠、一叠杯子，每样都占仓库位置。老板要算三笔账：单件货物占多大？每天进几件？要囤几天？三者相乘，就是仓库面积。系统存储估算就是一个道理。

存储估算的公式是“三数相乘再放大”：单条记录大小 $S_{row}$（一条动态、一笔订单序列化后的字节数，含元数据和索引）、每日新增记录数 $N_{day}$（DAU 乘以人均发布或写入量）、保留天数 $D_{keep}$（业务规定数据存多久，日志 30 天，用户内容 3 年）。三者相乘是裸数据量。

裸数据量还要乘一个副本系数 $K_{replica}$。为了保证一台机器宕机不丢数据，工业界通常存 2 到 3 个副本，所以真实占用往往是裸数据的 2 到 3 倍。举例：每日新增 2 亿条记录、单条 500 字节、保留 3 年（约 1095 天）、3 副本：

奶茶店囤货会算“周转天数”，系统囤数据也要算“保留天数”。只算今天、不算留存，就像只买明天一杯的牛奶——开业第三天，冰箱就空了。

Storage=Srow×Nday×Dkeep×KreplicaStorage = S_{row} \times N_{day} \times D_{keep} \times K_{replica}
存储量 = 单条体积 × 日增量 × 留存天数 × 副本系数。代入 500 字节 × 2 亿 × 1095 天 × 3，得到约 300 TB，一座“仓库”的规模就出来了。
  1. 单条体积 $S_{row}$一条记录在存储介质中占的字节数，包含元数据与索引开销。
    Srow=单条记录的裸数据字节数+索引与元数据S_{row} = 单条记录的裸数据字节数 + 索引与元数据
  2. 日增量 $N_{day}$每天新增多少条记录，由 DAU 与人均写入行为推出。
    Nday=NDAU×人均每日写入条数N_{day} = N_{DAU} \times 人均每日写入条数
  3. 留存天数 $D_{keep}$数据保留多久，直接决定空间是线性增长还是爆炸式增长。
    Dkeep=业务要求的数据保留天数D_{keep} = 业务要求的数据保留天数
  4. 副本系数 $K_{replica}$为容灾存多份，通常取 2 到 3。
    Storage=Srow×Nday×Dkeep×KreplicaStorage = S_{row} \times N_{day} \times D_{keep} \times K_{replica}

5. 带宽估算：外卖通道要多宽

外卖奶茶靠骑手取送。晚高峰 200 单同时要出，如果店面通道只够同时走 50 单，骑手就会堵成一团。带宽就是系统的“外卖通道宽度”，单位是 bps（每秒比特数），它决定数据能不能按时送到用户手里。

带宽估算的关键输入是“包体积”：一次接口调用的上行（请求）和下行（响应）各有多少字节。读多写少的系统，绝大部分流量是下行——服务器把内容发给用户，用户的请求本身很小。所以下行带宽是一等公民。实际还要考虑响应压缩、CDN 分流，这些手段的本质都是“让骑手少跑路”。

下行带宽的算法是：峰值 QPS × 读占比 × 平均响应字节数 × 8。乘 8 是因为 1 字节 = 8 比特，而带宽以比特计。举例：峰值 2083 QPS、读占比 90%、平均响应 100 KB：

带宽和 QPS 是“宽度与速度”的关系：QPS 决定一秒有多少请求，带宽决定每个请求的数据在多大的管子里流。通道修窄了，即使店员再多，外卖照样出不去。

BWdown=QPSpeak×Pread×Sresp×8BW_{down} = QPS_{peak} \times P_{read} \times S_{resp} \times 8
下行带宽 = 峰值请求数 × 读请求占比 × 单次响应体积 × 8。代入 2083 × 0.9 × 100 KB × 8，约等于 1.5 Gbps，这就是机房出口带宽的下限。
  1. 峰值 QPS $QPS_{peak}$一秒内最多来多少请求，沿用第 3 节的结果。
    QPSpeak=α×QPSavgQPS_{peak} = \alpha \times QPS_{avg}
  2. 读占比 $P_{read}$读请求占总请求的比例，来自需求澄清的读写比。
    Pread=RrwRrw+1P_{read} = \frac{R_{rw}}{R_{rw}+1}
  3. 响应体积 $S_{resp}$单次响应平均字节数，如 100 KB 的图文内容。
    Sresp=平均每次响应的字节数S_{resp} = 平均每次响应的字节数
  4. 乘 8 换算比特字节转比特，得到以 bps 为单位的带宽。
    BWdown=QPSpeak×Pread×Sresp×8BW_{down} = QPS_{peak} \times P_{read} \times S_{resp} \times 8

6. 服务器估算：要请多少店员

假设一个店员 1 分钟能做 3 杯奶茶，午休高峰 1 分钟要出 300 杯，理论上需要 100 个店员。但你真的会雇正好 100 个吗？不会——有人会请假（机器宕机），有人动作慢（性能波动），所以至少要 110 个。系统里的“店员”就是服务器，“请假”就是故障，“多雇 10%”就是冗余系数。

服务器数量等于峰值 QPS 除以单机 QPS，向上取整，再乘冗余系数。单机 QPS 是压测出来的“一个店员的真实产能”：一个普通后端服务实例，配缓存处理读请求能到几千 QPS，处理写请求可能只有几百。注意必须向上取整——机器是整数，只能多不能少。

冗余系数 $\gamma$ 通常取 1.5 到 2，对应 N+1 或 N+2 高可用：每 N 台工作机多备 1 到 2 台，一台挂了流量立刻切走。需要提醒的是，这里只算了无状态的应用服务器；数据库、缓存、消息队列这些“有状态的店员”（记得住每位顾客口味的那种），也要分别按自己的单机吞吐做同样的估算。

这 6 台不是哪个神仙算法变出来的，而是“顾客量 × 人均点单 ÷ 单店员产出 × 保险系数”——和老板决定请几个店员，用的是同一套逻辑。

M=⌈QPSpeakqsingle⌉×γM = \left\lceil \frac{QPS_{peak}}{q_{single}} \right\rceil \times \gamma
服务器台数 = 峰值 QPS ÷ 单机 QPS，向上取整，再乘冗余系数。代入 2083 ÷ 1000 ≈ 2.08，取整为 3，乘 2 得 6 台。
  1. 单机吞吐 $q_{single}$一台服务器能扛的 QPS，来自压测或同行业参考。
    qsingle=单台服务器实测可处理的QPSq_{single} = 单台服务器实测可处理的 QPS
  2. 理论台数 $\frac{QPS_{peak}}{q_{single}}$峰值需求除以单机产能，得到理论上的最少台数。
    QPSpeakqsingle=需要的理论服务器数\frac{QPS_{peak}}{q_{single}} = 需要的理论服务器数
  3. 向上取整 $\lceil \cdot \rceil$机器是整数，算出来 2.08 台也必须买 3 台。
    ⌈QPSpeakqsingle⌉=向上取整后的最少台数\left\lceil \frac{QPS_{peak}}{q_{single}} \right\rceil = 向上取整后的最少台数
  4. 冗余系数 $\gamma$多备的机器数，通常 1.5 到 2，对应 N+1 高可用。
    M=⌈QPSpeakqsingle⌉×γM = \left\lceil \frac{QPS_{peak}}{q_{single}} \right\rceil \times \gamma

7. 方案复盘：开业前再盘一遍账

开业前夜，老板会把整本账从头验算：客流预估是不是太乐观？留的原料够不够撑过开业优惠？账算下来钱够不够？容量估算的最后一步，也是这种“盘账”：对数字做合理性校验、留出余量、展望增长、权衡成本。

合理性校验最快的方法是数量级反推。算出某系统 QPS 只有 5，但 DAU 有 1000 万，那一定哪里错了：人均请求数记少了，或活跃时长算错了。把计算结果和同类产品的公开数据对照，是最快的体检方式。另一个准则是“用比例说话”：服务器、存储、带宽之间应相互自洽，比如 300 TB 存储对应每天几亿写入，读写比例应大体吻合。

还要为增长留余量。数据量按月复合增长：月增 6%，一年后就是 1.06 的 12 次方约 2 倍，三年约 8 倍。所以容量规划必须带升级路径，存储最好按 60% 到 70% 水位报警，留出 30% 到 40% 的缓冲。买多了是浪费，买少了是事故，估算的价值就是把方案钉在一个“够用且不浪费”的可解释区间。

开业前盘账的老板，和上线前评审的系统架构师，心态一模一样：宁可把账算宽一点，不可把风险想少了。容量估算不是一次性的填空题，而是一本可以反复校验、随数据更新的“活账本”。

Sn=S0×(1+g)nS_{n} = S_{0}\times(1+g)^{n}
规模推演 = 当前规模 ×（1 + 月增长率）的 n 次方。月增 6%，12 个月后翻倍，36 个月后接近 8 倍——这就是“今天够用”不等于“明年够用”的数学解释。
  1. 当前规模 $S_{0}$今天的存储量或流量，作为推演的起点。
    S0=当前的存储或流量规模S_{0} = 当前的存储或流量规模
  2. 月增长率 $g$每月新增的百分比，比如 0.06 表示月增 6%。
    g=月度复合增长率g = 月度复合增长率
  3. 月数 $n$往后推演几个月，一年取 12，三年取 36。
    n=经过的月数n = 经过的月数
  4. 指数增长 $(1+g)^{n}$幂运算让规模随时间加速放大，是容量规划必须留出升级路径的根本原因。
    Sn=S0×(1+g)nS_{n} = S_{0}\times(1+g)^{n}

AI 应用场景

大促前的云资源扩容

阶段：系统架构设计 / 容量规划

解决的问题：电商平台每逢大促都要临时扩容，传统靠“去年买了多少今年多加 30%”的经验法，要么浪费预算，要么扛不住流量。用容量估算从 DAU、人均加购次数、转化率出发，算出峰值 QPS，再除以单机压测值得到服务器数量，扩容从“感觉”变成“计算”。

具体案例：某电商 5000 万 DAU，人均浏览 30 次，16 小时活跃，大促峰值系数取 8，平均 QPS 约 2.6 万，峰值约 20.8 万；单机 5000 QPS、冗余 2 倍，应用服务器约 84 台。运维团队据此在下单页扩容，大促当天 SLO 稳如平日。

AI 推理服务的 GPU 规划

阶段：模型部署上线

解决的问题：推荐、翻译等 AI 服务每个请求都要跑一次模型推理，GPU 单价高，买多了闲置浪费，买少了请求超时。容量估算把 DAU × 人均触发次数折算成推理 QPS，再除以单卡吞吐，得出 GPU 卡数——这本质上是“服务器估算”一节在硬件加速器上的复刻。

具体案例：某资讯 App 日活 500 万，人均触发推荐 40 次，8 小时活跃，峰值系数 4：平均推理 QPS 约 694，峰值约 2778；单卡吞吐 300 QPS、冗余 1.5，得出 14 张 GPU 卡，预算报告一次通过。

初创产品的云预算估算

阶段：产品上线规划

解决的问题：创业公司预算有限，云资源按量计费也要算账。容量估算输出“一年后存储多少 TB、带宽多少 Mbps”的增长曲线，直接决定买按量付费还是预留实例，避免月底账单超支。

具体案例：一款笔记 App 日活 50 万，人均每天新增 5 KB 数据，留存 100 天：第一年存储约 0.25 TB；按月复合增长 6% 推演，三年后约 1.8 TB。技术负责人据此把冷数据自动转归档存储，账单下降 40%。

Python 演示

python41 行
"""容量估算工具箱: 从 DAU 出发推算 QPS 存储带宽与服务器数量"""from math import ceil  def calc_qps(dau, req_per_user, active_hours, peak_factor):    daily_reqs = dau * req_per_user          # 一天的请求总量    avg_qps = daily_reqs / (active_hours * 3600)   # 摊到每秒    peak_qps = avg_qps * peak_factor          # 乘峰值系数    return avg_qps, peak_qps  def calc_storage(record_bytes, daily_records, retain_days, replica=3):    return record_bytes * daily_records * retain_days * replica  def calc_bandwidth(peak_qps, read_ratio, resp_kb):    # 峰值 QPS 乘读占比再乘单次响应体积 转 Mbps    return peak_qps * read_ratio * resp_kb * 8 / 1000  def calc_servers(peak_qps, single_qps, redundancy=2):    base = ceil(peak_qps / single_qps)        # 理论台数向上取整    return base * redundancy  def main():    dau = 2_000_000    avg_qps, peak_qps = calc_qps(dau, 20, 16, 3)    storage_tb = calc_storage(500, 200_000_000, 365, 3) / 1024 ** 4    down_mbps = calc_bandwidth(peak_qps, 0.9, 100)    servers = calc_servers(peak_qps, 1000, 2)     print("平均 QPS:", round(avg_qps))    print("峰值 QPS:", round(peak_qps))    print("一年存储(约):", round(storage_tb, 1), "TB")    print("下行带宽(约):", round(down_mbps), "Mbps")    print("应用服务器(约):", servers, "台")  if __name__ == "__main__":    main()
目的：把正文讲的一套容量估算流程固化成可复用的函数，喂入 DAU、人均请求、活跃时长等参数，一键输出 QPS、存储、带宽和服务器数量的完整估算报告。
  1. daily_reqs = dau * req_per_user一天的请求总量 = 进店人数 × 人均点单数，一切的开端。
  2. avg_qps = daily_reqs / (active_hours * 3600)把总请求按活跃时长摊到每秒，得到平均 QPS。
  3. peak_qps = avg_qps * peak_factor峰值系数放大平均值，得到系统真正要扛的规格。
  4. record_bytes * daily_records * retain_days * replica存储三数相乘再乘副本，仓库面积就这么来的。
  5. ceil(peak_qps / single_qps)向上取整是铁律，机器数只能多不能少。
  6. return base * redundancy冗余系数兜底，一台宕机流量能切走。

常见误区

误区看到“系统要支持 1000 万用户”，就直接写“每秒要处理 1000 万请求”。单位从“天”到“秒”的区别被完全忽略，算出来的服务器数量夸张到老板直接劝退。

正解DAU 是“一天内来过的人”，QPS 是“一秒内同时在点单的人”。1000 万用户是散布在一天里的，每人一天也就十几次请求。要先算日请求总量，除以活跃秒数，再乘峰值系数，才能得到 QPS——就像奶茶店 1000 个顾客不是同时挤进门，而是一整天陆续来的。

为何常见：“用户数”和“请求数”都叫“量”，一天和一秒的差异太小、太容易被忽略，而恰恰是量纲决定了数量级。

误区算出平均 QPS 是 700，就按 700 的容量买服务器，觉得“数学上完全够用”。上线后一到大促或晚高峰，系统直接超时报错。

正解系统的生死时刻往往只在那 5% 的高峰。平均值只是算总量的分母，设计容量必须乘以峰值系数 3 到 10。用平均 QPS 设计，就像奶茶店只按全天平均客流雇人，午休高峰一定爆单。

为何常见：平均值好算、数字好看，而且日常压测通常在低峰时段做，观察不到真实的峰值形态。

误区按今天的数据量买硬盘，觉得 100 GB 用一年绰绰有余。三个月后收到存储告警，才发现数据是滚雪球的。

正解存储是典型的指数增长。要乘留存天数、副本系数，再按月度复合增长率推演 1 到 3 年。今天 100 GB，月增 6%，一年后约 200 GB，三年后约 800 GB。“今天够”不等于“明年够”，容量规划必须带时间维度。

为何常见：人脑天然用线性直觉想问题，低估了幂运算的加速效果，等到账单翻倍才反应过来。

误区算出要 3 台机器，冗余系数 2，于是把 3 台机器的 CPU 内存都加一倍，觉得这样一台顶两台，机器少钱还省。

正解冗余指的是“多备机器”，不是“把单机配置翻倍”。N+1 指每 N 台工作机多配 1 台备用机，机器宕机时流量能切过去；单机配置再高，机器挂了照样全挂。配置翻倍解决的是性能问题，冗余解决的是可用性问题，两者不能互换。

为何常见：把“冗余”和“高性能”混为一谈，忽略了高可用的本质是故障隔离，而不是单点变强。

误区算出 QPS 是 694.444，就写进方案说“需要 694.44 QPS 容量”，多一位都觉得不专业，少一位都觉得心虚。

正解容量估算的价值在数量级和量纲。694 还是 700 不影响架构决策，但“几百”和“几千”会。面试和工程实践中，给出“约 700 QPS、约 6 台机器”的合理区间，比假装精确到个位更专业。估算本身就是用粗粒度数字做决策。

为何常见：学生时代做题要求唯一精确答案，但工程估算输入就有误差，输出纠结到个位数只是自我安慰。

面试题

Q1. 系统容量估算的第一步通常是？

单选题 · easy

  • A.直接填写服务器购买数量
  • B.澄清需求并确认输入参数← 正确答案
  • C.画出功能完整的架构图
  • D.编写压测报告与监控脚本

答案：B。容量估算必须先澄清用户规模、核心功能和读写比例，这些输入决定后续所有计算。选 A 等于还没看菜谱就买菜；C 是设计阶段的事；D 是上线验证阶段的事，都不符合“第一步”的定位。

Q2. QPS 的中文含义是？

单选题 · easy

  • A.每秒处理的查询请求数量← 正确答案
  • B.每天处理的查询请求数量
  • C.每秒处理的用户登录数量
  • D.每天处理的用户登录数量

答案：A。QPS 全称 Queries Per Second，强调“每秒”。就像奶茶店“每秒能接几单”，而不是“一天接几单”。B 把每秒换成了每天，D 又换了对象，都是对时间维度和对象范围的混淆。

Q3. 某系统 100 万 DAU，人均每天 30 次请求，每天 12 小时有流量，平均 QPS 约为？

单选题 · mid

  • A.约 115 次每秒左右
  • B.约 231 次每秒左右
  • C.约 694 次每秒左右← 正确答案
  • D.约 2083 次每秒左右

答案：C。100 万 × 30 = 3000 万次请求，12 小时 = 43200 秒，3000 万 ÷ 43200 ≈ 694。就像 3 万杯奶茶分 12 小时卖，平均每秒约 0.7 杯。D 是误把峰值系数也乘了进去，那是下一步的事。

Q4. 峰值系数 α 在常规系统设计中通常取？

单选题 · mid

  • A.小于 0.5 的小数系数
  • B.恰好等于 1 的固定值
  • C.大约 3 到 10 倍的经验值← 正确答案
  • D.一百倍以上的保险值

答案：C。用户请求天然聚集，午休、晚高峰的流量是低谷的数倍，所以 α 取 3 到 10。取 1 等于按平均客流雇人，高峰必爆；取 100 则成本失控，属于过度设计。A 更是把方向搞反了。

Q5. 存储容量估算中，以下哪一项不是必要输入？

单选题 · easy

  • A.单条数据记录的平均字节数
  • B.每天新增的数据记录条数
  • C.数据需要保留的周期天数
  • D.用户移动设备的可用内存← 正确答案

答案：D。存储 = 单条体积 × 日增量 × 留存天数 × 副本系数。用户手机内存是客户端的事，与服务器存储规划无关，属于典型的干扰项，用来检验你是否真的理解公式的每个因子。

Q6. 进行 QPS 估算时，需要哪些输入参数？

多选题 · mid

  • A.日活跃用户的 DAU 数值← 正确答案
  • B.每位用户平均每天的请求次数← 正确答案
  • C.高峰流量系数的经验取值← 正确答案
  • D.服务器的操作系统版本号

答案：ABC。QPS = DAU × 人均请求 ÷ 活跃秒数 × 峰值系数，三个输入缺一不可。操作系统版本只影响单机压测的绝对值，不属于 QPS 估算公式本身的输入项。

Q7. 关于带宽估算，下列说法正确的是？

多选题 · mid

  • A.读多写少时下行流量占主导← 正确答案
  • B.需要通过 QPS 与包体积折算← 正确答案
  • C.带宽可以忽略不计直接省略
  • D.字节换算成比特需要乘以 8← 正确答案

答案：ABD。带宽 = QPS × 包体积 × 8，读多系统响应体积大，下行是主力。C 忽略带宽会导致响应超时，就像外卖通道修太窄，骑手全堵在门口。A、B、D 分别对应公式里的三项，缺一不可。

Q8. 200 万 DAU、人均 50 次请求、16 小时活跃、峰值系数 4，单机扛 4000 QPS、冗余 2 倍，约需多少台应用服务器？

单选题 · hard

  • A.约需 2 台服务器
  • B.约需 4 台服务器← 正确答案
  • C.约需 8 台服务器
  • D.约需 16 台服务器

答案：B。日请求 1 亿，16 小时活跃，平均 QPS ≈ 1736，峰值 ≈ 6944；6944 ÷ 4000 ≈ 1.74，向上取整为 2，再乘冗余 2 得 4 台。选 A 漏乘了冗余系数，选 C 则是取整前就乘了冗余，逻辑顺序错了。

Q9. 存储一年内从 10 TB 增长到 21 TB，约相当于月复合增长率多少？

单选题 · hard

  • A.约每月百分之零点五
  • B.约每月百分之一左右
  • C.约每月百分之六左右← 正确答案
  • D.约每月百分之二十左右

答案：C。(1+g) 的 12 次方 = 2.1，开 12 次方得 1+g ≈ 1.063，即月增约 6%。6% 看着小，一年翻倍、三年近 8 倍——这正是存储必须按指数规划、而不是线性加硬盘的根本原因。

Q10. 关于容量估算的整体认识，下列说法正确的是？

多选题 · extreme

  • A.数量级正确比精确到个位更重要← 正确答案
  • B.设计容量应该覆盖峰值而非平均值← 正确答案
  • C.估算一次即可无需考虑数据增长
  • D.存储计算要计入副本与索引开销← 正确答案

答案：ABD。估算的目标是数量级正确的决策区间（A）；容量取峰值不取均值，否则高峰必爆（B）；数据按月复合增长，方案必须动态推演而非一锤定音（C 错）；副本与索引是存储真实占用的大头（D）。这四点正是“方案复盘”一节的灵魂。