压测与容量规划

Category

server / capacity 子树。节点定位：容量是推演链不是拍脑袋——业务指标→系统负载→单机实测反推，拐点与安全水位、余量给故障、弹性给增长。capacity 子树总纲。

Definition

容量规划常被当成“拍一个开服机器数”的资源问题，实际上它是一条推演链：从业务指标出发，换算成系统负载，再用实测的单机能力反推资源规模。链条上任何一环靠猜，最后一环就会以事故的方式把误差还回来。开服洪峰打挂登录、活动当晚数据库先倒、扩容后瓶颈悄悄挪到别处，追根溯源往往都是推演链断在了中间某一节。

压测是这条链里唯一提供实测数据的环节，但它容易被做成果效表演：跑出一个好看的峰值数字，然后写进汇报。压测真正该回答的是三个朴素的问题——单机到底能扛多少、瓶颈在哪个组件、余量应该留多大。回答不了这三问的压测，数字再漂亮也支撑不了容量决策。

Problem

把容量当「拍开服机器数」的资源问题会断链：业务量换算、压测失真、拐点判断任何一环靠猜，误差都会以事故方式在最后一环还回来——洪峰打挂登录、活动当晚库先倒、扩容后瓶颈挪到别处。

从业务指标出发，而不是从机器出发

容量问题最终都能追溯到一组业务侧的数字，先有这组数字，才有后面的一切换算：

• 用户规模：注册量、日活、峰值同时在线，其中峰值在线是容量计算的主输入。
• 时间分布：晚高峰的形状、周末与节假日的放大系数、开服首日的集中涌入。
• 行为构成：玩家上线后做什么，各行为的频率差异决定了负载的形状。
• 运营事件：预约开服、版本更新、大型活动，哪些时点会出现倍增流量。

这些数字往往不在技术团队手里，而在发行和运营的预期里。容量规划的第一步因此是一场对齐：把运营预期翻译成技术侧能消化的输入。跳过这一步，后面所有的压测和估算都建立在自设的假设上，压得再准也压错了对象。

从业务量到系统负载的换算

拿到业务指标后，下一步是把“多少人玩”换算成“系统承受什么”。这层换算通常按基本单位展开：

• 每玩家会话：登录后保持的连接数、心跳频率，决定网关的连接与包量压力。
• 每玩家请求频率：各系统操作的调用频率，汇总成各服务的每秒请求量。
• 每玩家常驻内存：会话上下文、缓存数据、视野列表的占用，乘以峰值在线就是内存需求。
• 每玩家带宽：状态同步的下行流量，决定出口带宽与广播成本。
• 每玩家持久化写入：落盘频率乘以在线数，得到数据库的写入压力。

这几个“每玩家”参数是整条推演链的基本单位，它们的取值应该来自压测实测或同类产品经验，而不是拍脑袋。尤其是每玩家常驻内存，很多服务先撞的是内存墙而不是计算墙，这个参数估错，单机在线上限就整体估错。

压测的目的不是刷峰值

压测容易滑向“冲一个最大并发数字”的方向，但容量决策需要的其实是不一样的信息：

• 单机承载：在延迟和错误率可接受的前提下，单进程稳定服务多少玩家。
• 瓶颈定位：先到顶的是计算、内存、带宽、存储还是下游依赖，决定了扩容该扩什么。
• 行为差异：哪些操作特别昂贵，值得专门优化或者做频率限制。
• 参数校准：实测出来的每玩家指标，替换估算值，修正容量模型。

一个值得养成的习惯是给每个压测结论标注条件：什么行为分布、什么数据规模、什么硬件规格、什么判定标准。不带条件的容量数字，换一个场景就不成立，却常常被当成普适结论引用到下一款产品。

压测失真的常见来源

压测结果和线上表现不符，是容量事故里最常见的剧情。失真的来源相当集中：

• 机器人行为不真实：只发登录和心跳的机器人，测出的上限可能比真实混合负载高数倍。
• 数据规模不足：空库和上亿行数据的库，查询表现完全不同，最慢的路径往往要靠数据量才能暴露。
• 环境规格不一致：测试环境硬件更好、网络更近、依赖更空，测出来的数字直接搬到生产就是高估。
• 只压单点：单服务压得很满，链路上其他组件的真实表现没有验证过。
• 峰形不对：匀速加压测不出开服瞬间那种陡峭洪峰，而洪峰恰恰是开服场景的主要威胁。

对付失真的思路不是把压测做得无限逼近现实，而是在关键假设上做交叉验证：对存疑的部分，用影子流量或灰度期的真实数据回填模型。压测给出的初始值和线上实测之间的偏差，本身就是下一轮规划的校准材料。

拐点与安全水位

压测数据最有价值的部分往往不是最大值，而是拐点：负载继续上升时，延迟从线性增长转为非线性飙升的位置。拐点之后，系统进入吞吐不增、延迟暴涨的区间，这时候堆多少流量都只是堆积排队。

生产负载的水位通常参考拐点来定：

• 常态负载控制在拐点以下相当的距离，给突发留出吸收空间。
• 峰值时段允许逼近拐点，但要有明确的告警水位。
• 任何长期运行在拐点附近的服务，都是下一个容量事故的候选。

安全水位定得太满，等于把容错余量花光；定得太空，成本又压不下来。这个平衡没有通用答案，通常按业务对延迟的敏感度和故障的恢复成本来定，越难快速扩容的组件，水位越要保守。

余量给故障，弹性给增长

容量规划里两种“多备的资源”经常被混为一谈，实际上用途和来源都不同：

• 故障余量：为了坏一台机器、断一个可用区时流量接得住。它是静态冗余，随部署规模等比存在。
• 增长预留：为了用户量上行时的扩容窗口。它更该由弹性扩容能力承担，而不是靠常备机器。

把增长需求折算成常备余量，是最常见的成本浪费方式之一；反过来，把故障余量当成弹性空间，则是开服事故里常见的死因——流量一来，连坏一台机器的资格都没有。两条账分开算，预算和风险才会都落在明处。

容量模型需要上线后校准

上线前的容量模型，本质是一组待验证的假设。真实用户的行为分布几乎一定和压测模型有偏差：有人挂机有人氪金，有人半夜爬榜有人开服冲级。所以上线只是容量工作的换挡点，不是终点：

• 对比预估与实测：各服务的真实负载形状、每玩家参数的实际值，和模型差多少。
• 盯住最快逼近水位的组件：它往往是模型里最被低估的那一项。
• 记录大事件的实测数据：开服、大版本、大型活动是天然的高质量压测，数据应当沉淀下来。

持续校准的容量模型，会在下一次大事件前给出更准的预案；从不校准的模型，第一次重大偏差就会把欠账一次性讨回去。

什么时候需要重新做容量规划

容量模型有明确的失效信号，出现时通常值得推翻重算而不是修补：

• 玩法结构大改：新增重度玩法或改变核心循环，行为分布随之重排。
• 架构调整：服务拆分、存储迁移、协议重构，单机能力和瓶颈位置都会移动。
• 用户结构变化：版本迁移带来的新用户群体、跨端发行后的行为差异。
• 连续出现的性能意外：同类问题反复，说明模型和现实已经脱节。

重新规划不等于推倒一切，多数时候是重测关键参数、重算瓶颈项。但要警惕用旧模型外推新场景：玩法变了还沿用旧的行为分布，是容量估计失手的高发姿势。

常见误区

• 从机器出发而不是从业务出发，先定了预算再倒推动辄几十万在线的结论。
• 用登录压测代替全行为压测，登录扛住了，进服之后的第一个高峰没扛住。
• 空库压测，查询路径在数据量上来后全面变慢，上线才暴露。
• 把压测峰值当成安全容量，不给拐点以下留水位。
• 故障余量和增长预留混在一本账上，成本和风险双双失控。
• 模型上线后从不校准，第二次开服还在用第一次的错参数。

容量规划做得好坏，平时看不出来，只在几个瞬间显形：开服那一刻、活动开闸那一刻、用户量翻倍那一刻。这些瞬间都来不及临时补课，能靠的只有之前那条推演链的扎实程度。

实战案例：一次「开服十分钟，登录先倒」的容量推演断链排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「压测失真的常见来源」「拐点与安全水位」「余量给故障，弹性给增长」用到深水区：压测数字很漂亮，开服十分钟就还账——这是推演链断在中间一节的排查，也是「怎样让压测支撑容量决策」的完整展开。

背景与现象：某手游预约 60 万，开服首日峰值在线 15 万。开服 10 分钟登录服务雪崩，紧急扩两批机器才稳住，洪峰持续 40 分钟——而压测报告写着单机登录承载 8 万连接，机器数是按这个数字乘安全系数算的。

第一步：现象与口径——先对齐压测数字和线上数字

压测口径：机器人只发登录和心跳，压出单机 8 万连接；真实玩家登录后 30 秒内连发拉角色、公告、好友、排行四类请求，同规格单机实测只能稳住 2.1 万在线——上限差了近 4 倍。

水位口径：常态负载跑在拐点附近，没定告警水位；开服洪峰按均值而不是按峰值准备，故障余量和增长预留混在一本账上。

第二步：分层归因——按本页失真来源清单比对

容量事故归因  占比
  机器人行为不真实，只压登录和心跳     54%
  空库压测，数据规模不足没暴露慢路径    27%
  环境规格不一致，测试数字直接搬生产    19%

逐项比对：上限差 4 倍的主因是机器人行为不真实——本页说只发登录和心跳的机器人，测出的上限可能比真实混合负载高数倍；角色查询在 3000 万行库上比空库慢 6 倍——命中数据规模不足；不带条件的 8 万被当成普适结论引用——命中本页说的换一个场景就不成立。

第三步：根因——推演链断在换算，压测做成了果效表演

从业务指标到系统负载的换算跳过了行为构成这一环：没有先问「玩家上线后做什么」，机器人直接按最便宜的行为压。压测回答了「峰值多少」，没回答「瓶颈在哪」「余量多大」——三问只答了一问，数字再漂亮也支撑不了容量决策。

第四步：处置与回填——把断掉的环节一节节接回去

1. 机器人行为真实化：按同类产品真实行为分布回放，登录后的四类请求按实测频率编排，数据规模灌到生产同级。
2. 拐点定水位：重测得单机真实拐点 3 万在线，常态负载控制在拐点 70% 以下，85% 设告警水位。
3. 余量弹性分账：故障余量按坏一台机器留，增长弹性交给动态加服，两本账分开算。
4. 上线后校准：把本次开服实测的每玩家参数回填容量模型，作为下一次大事件的预案输入。

复核账：单机承载 8 万（虚标）→ 2.1 万（实测口径）；资料片二次开服峰值 22 万在线，登录 P99 420 毫秒全程稳态，零紧急扩容。

回填清单：

回填项	动作	回填处
行为构成输入	容量计算先收集玩家上线后做什么，再定机器人行为分布	从业务指标出发，而不是从机器出发
压测标注条件	每个压测结论标行为分布、数据规模、硬件规格、判定标准	压测的目的不是刷峰值
拐点水位	常态 ≤ 拐点 70%，85% 告警，长期贴近拐点的服务列入整改	拐点与安全水位
余量弹性分账	故障余量静态冗余、增长预留走弹性，预算风险分开落账	余量给故障，弹性给增长

案例的三个教训

1. 压测上限是带条件的数字。只压登录的 8 万换到真实混合负载就是 2.1 万，不带条件的容量数字换一个场景就不成立。
2. 推演链断一节，最后一节用事故还账。行为构成没进模型，误差就由开服洪峰以掉线的方式还回来。
3. 峰值不是安全容量。跑在拐点附近又没告警水位，等于把容错余量提前花光。

Used By

容量模型建设；开服与活动的容量评审；压测方案设计。

Related

关系链：业务指标 → 负载换算 → 单机实测 → 压测校准 → 拐点水位 → 余量弹性 → 上线校准。上游：无（capacity 入口）。下游：server/capacity/02（扩缩容执行）、operation/observability/05（压测链路）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。