一篇读懂容量规划：从 QPS 到机器数的推算

容量规划的本质：一条推算链

「大促要准备多少台机器」这个问题的答案，是一条推算链的终点：业务目标 → 流量预估 → 服务指标 → 资源需求——每一环都要有依据：

业务目标：大促的目标 GMV 或 PV/UV（业务方给出——「业务目标」的准确性（业务目标本身是预估（按历史数据推——「预估的偏差」是容量风险的第一来源——预估偏低=宕机、偏高=浪费——「预估的区间化」（保守/中性/激进三档——「按档准备」的弹性（云的弹性资源——「弹性」是容量规划的现代答案（传统自建机房弹性差——「云的弹性」改变了容量规划的玩法（「弹性容量」：基准容量自建+弹性容量上云。流量预估的转换：PV → QPS 的转换——「PV 与 QPS」的关系（每 PV 的请求数（一个页面可能触发 10-30 个后端请求——「请求放大系数」——「峰值 QPS」的估算（日均 PV / 86400 秒 × 峰值系数——「峰值系数」（流量的时间分布——大促的峰值系数 5-20 倍——「二八原则」（80% 流量在 20% 时间——「峰值」的实测校准**（历史大促的数据。

单机容量：压测是唯一的真相

「单机容量」怎么定：压测是唯一的真相（理论推算（每请求 10ms → 单机 100 QPS——「理论推算的错误」（锁竞争、GC、上下文切换——「实际容量」常常低于理论——「压测」的方法（全链路压测（库内已有专文）vs 单服务压测——「单服务压测」的实操（基准环境、逐步加压、找拐点——「压测的拐点」（QPS 上不去、延迟陡增的点——「拐点」的判定标准（P99 延迟超阈值或 QPS 不再增长——「压测的指标记录」：拐点 QPS、对应资源水位（CPU/GC/IO——「容量基线」的建立。「容量水位」的余量设计：「余量」的哲学（满负荷=一压就崩——「余量的经验值」：日常水位 ≤ 40-50%（「余量的一半原则」——大促前水位 ≤ 60%（「余量」的两个场景：日常留故障冗余（一台挂了流量分到别的机器——「故障余量」；大促留峰值余量——「余量」是容灾的载体——「没有余量的容量规划」等于「没有容灾设计」。「容量水位」的监控与告警：「水位的实时监控」（CPU、内存、连接数、线程池——「水位的分级告警」（50% 提醒、70% 预警、85% 行动——「水位的行动预案」（告警触发的扩容动作——「水位-动作」的联动**。

资源推算：从 QPS 到机器数的完整链条

推算链的每一环：「链路分解」：入口流量 → 每个服务的流量 → 每个服务的资源——「链路的推算实例」：大促峰值 10 万 QPS 入口 → 网关（10 万 QPS——网关的转发能力（单机 2 万——5 台+冗余 → 订单服务（下单 2 万 QPS——单机压测 500——40 台+余量 → 库存服务（扣减 3 万——Redis 扛（「Redis 的容量」（库存扣减用 Redis——Redis 的 QPS 单机 10 万——「Redis 的分片」——「每个环节的推算」都遵循「目标 QPS ÷ 单机能力 × 冗余系数」——「冗余系数」：1.5-2 倍（故障余量+流量波动——「推算链的完整性」：漏掉一个环节=容量黑洞（下游依赖（DB 的容量（「DB 的容量」（写入的 QPS（订单写 2 万 QPS——单机 MySQL 写入极限（4000-8000——分库分表——「DB 的容量规划」是链条的终点也是最难的（「DB 的扩容」比应用难（有状态——「有状态组件」的容量要提前规划。「瓶颈的转移」：「木桶原理」（容量由最短的板决定——「瓶颈的识别」（压测找到木桶短板——「短板的加长」（优化或扩容短板——「瓶颈转移」的循环（加长一个短板、下一个短板出现——「容量规划是循环」不是一次计算——**「循环」的驱动是压测。

成本与弹性：容量规划的经济学

「成本优化」的方向：「过配」与「欠配」的成本（过配（机器闲置的成本——「闲置的成本」的量化（服务器费用——欠配（宕机的业务损失——「损失」的量化（停机损失——「成本平衡点」——「云弹性」改变平衡点（弹性扩容的成本（按秒计费——「弹性」让「过配」的闲置成本降低——「混部」的优化（在线与离线业务的混部（「混部」：白天在线业务、夜间离线计算——「资源的分时复用」——「混部」的干扰管理（离线任务对在线的影响——「混部」的隔离（cgroup 的资源限制——「混部」是大厂的成本武器。「容量规划」的组织实践：「容量评审」（大促前的容量评审会（「容量评审」的输入（业务预估、历史数据、压测结果——「评审的输出」：扩容清单、预案清单——「评审的参与者」（业务+架构+运维+DBA——「容量规划是跨团队的工程」——「容量基线的档案」：每次大促的容量数据归档——「历史档案」的价值（下次规划的输入——「容量规划的迭代」。

容量规划的进阶：压测的「黄金拐点」与「容量的预测模型」

容量规划的进阶：压测拐点的判定与容量预测模型的构建。「压测拐点」的判定：「拐点的信号」：延迟的陡增（P99 的突变——「P99 vs P50」的分歧（P50 还好 P99 陡增——「尾部的先兆」——吞吐的平台化（QPS 不再上升——「吞吐的平台」的原因定位（CPU/IO/锁/连接——「定位的工具」（perf、火焰图——「瓶颈的类型化」：CPU 型（火焰图的 CPU 峰、IO 型（磁盘 await、锁型（锁竞争的等待——「瓶颈的解决」顺序（先 IO 后锁再 CPU（「优化的性价比」排序。「压测的「全链路」实践：全链路压测篇的配合（「单机压测」与「全链路压测」的分工：单机找拐点、全链路找瓶颈——「全链路的影子」（影子库与流量标记——「压测数据」的隔离——「压测的脚本管理」（压测场景的版本化——「压测的常态化」（周期性压测——「容量基线」的持续更新——「常态压测」的流程化。「容量的预测模型」：「预测的方法」：线性外推（基于历史增长——「线性外推的失效」（业务非线性增长——业务驱动的预测（「业务目标」的翻译——「预测的输入」：用户增长、单用户行为、转化漏斗——「预测的模型化」（用户行为建模——「容量的函数」：QPS = f(用户数, 行为, 转化)——「函数的校准」（历史数据回归——「预测的区间」（悲观/中性/乐观——「区间的资源弹性」（乐观场景的弹性扩容。「容量规划的自动化」：「自动扩容」的实践：HPA 的策略（K8s 的水平自动扩容——「HPA 的指标」（CPU/QPS/自定义指标——「HPA 的局限」（反应式（事后扩容——「预测式扩容」（提前扩容（「预测式」的实践——基于流量预测的预扩容——「预测+反应」的组合。容量规划的进阶总结：压测拐点的判定（P99 先兆、瓶颈类型化）+全链路的常态化+容量预测模型（业务函数+区间弹性）+自动扩容（HPA+预测式）——「容量规划」的进化方向：从「大促前的手工作业」到「常态化压测+自动扩容+预测模型」的自动化体系——「容量」从「静态的资源」变成「动态的能力」——「动态容量」的管理，需要容量数据、预测模型、自动扩容三者的一体化。

容量规划高频问答

收尾前回答三个高频问题。「流量预估不准怎么办？」——三层防御：「预估不准的防御」：弹性容量（云的自动扩容——「弹性的速度」（扩容的时间（分钟级——「弹性」的触发（水位指标——「弹性的上限」（资源的配额——「弹性的预案」（配额的预申请——「弹性不够」的降级——「预估的偏差」被弹性吸收——「弹性」是容量规划的安全网。「压测环境和生产不一样怎么办？」——环境差异的处理：「压测环境的差异」：硬件的差异（「按比例推算」（压测环境小规格×倍数——「倍数推算」的误差（非线性（大规格的性能差异——「等规格压测」的准确性（生产同规格压测——「成本」的考量——「影子环境」的方案（生产的影子——「压测环境的校准」（差异的量化。「容量规划谁来负责？」——组织的归属：「容量规划的责任」：技术架构组主导（「主导者」的职责（推算、压测、评审——业务方提供目标（「业务输入」的质量——运维执行（「扩容的执行」——DBA 配合（「DB 容量」的规划——「容量规划是跨团队的工程」——「容量评审会」的机制——「评审的产出」：扩容清单与预案——「容量规划的责任分配」清晰才可持续。容量规划的问答收束：容量规划的三个心智模型——「预估是假设（三档假设）、压测是实验（唯一真相）、弹性是保险（误差吸收）」——「推算→压测→弹性」的三层防御——「容量规划的目的」不是「算得准」，是「错得少、错时不慌」——**「预案」比「预测」更可靠。

小结

容量规划的工程学：推算链（业务目标→流量预估（PV→QPS 转换、峰值系数）→单机容量（压测是唯一真相——拐点判定）→资源推算（目标 QPS ÷ 单机能力 × 冗余系数——链路的完整性——DB 的容量是最难的一环）；余量的哲学（日常 ≤50%、大促 ≤60%——「没有余量等于没有容灾」、水位监控的分级告警与行动联动）；经济学（过配与欠配的成本平衡、云弹性改变平衡点、混部的分时复用、容量评审的跨团队协作）。给架构师的方法论总结：容量规划是「循环」而非「计算」——业务预估→推算→压测验证→瓶颈加长→再压测——每一轮循环的驱动都是压测——「压测的数据」是容量规划唯一可信的输入——理论推算只是假设的起点——以及，云的弹性让容量规划从「买够」变成「够用+弹性」——弹性时代的容量规划，重点从「资源」转向「预案」（弹性的速度、降级的阶梯、水位的联动）。

容量规划的最高境界不是「精确预测流量」，是「无论流量多少都有预案」——预测会错，预案不会。