本文目录
容量结论必须同时写明请求结构、成功率和延迟条件
QPS 表示单位时间内的请求量，并发请求表示同一时刻尚未完成的请求，在线用户则不等于持续请求的用户。在边界一致且处于稳定状态时，可用平均在途请求数约等于平均到达率乘平均停留时间检查数量级；它不能预测活动瞬时峰值，也不能用 P99 直接代替平均值。容量规划应先拆分读写比例、热点和依赖调用，再通过逐级加压测出满足业务延迟与正确性要求的可持续负载，并加入故障、扩容等待和增长余量。
先决定容量评估的四个口径
| 判断项 | 应记录的条件 | 误判风险 |
|---|---|---|
| 业务流量 | 按登录、浏览、提交、查询结果分别记录峰值到达率和读写比例 | 把总日活或页面访问量当成某个接口的峰值 QPS |
| 处理容量 | 在约定数据量、错误率与延迟下测出稳定处理量 | 只写最高发送量，超时和失败也计入能力 |
| 依赖放大 | 每次业务操作对应数据库、缓存和外部调用次数 | 入口容量够用，下游先被重复查询或重试压垮 |
| 容量余量 | 考虑节点失效、发布替换、预热和实例就绪时间 | 正常峰值刚好跑满，故障后没有可用余地 |
适用边界：从关键交易或查询入口开始
这套方法适用于 API、企业业务系统、小程序后台和有明确请求路径的 Web 服务。视频传输、长连接、批量分析与在线推理还需要带宽、连接寿命或任务队列等专门模型，不能只按 QPS 报价。
容量评估首先是约定业务体验。比如列表打开、提交订单和后台导出可以有不同等待预算，支付完成还需看最终状态。将这些动作混成一个平均响应时间，会掩盖最需要保障的路径。没有生产历史时，应把估算标为假设，活动后用真实曲线修订。
一次业务动作和一次接口调用不是同一个计量单位。评估表应同时保留各路径的请求放大比例，并注明哪些动作会被浏览器、网关或客户端重试；如果一次操作跨越异步阶段，应分别评估受理能力与最终处理能力，让不同阶段的容量结论能够对应。
- 先列出会影响收入、履约或生产的三到五条路径。
- 为每条路径写明数据量、完成标准、可接受等待与失败边界。
区分 QPS、并发请求与在线人数
一个在线用户可能长时间阅读，也可能连续触发多个接口。前端一次动作还可能并行请求配置、库存和优惠，因此用户数与后端并发之间不存在通用固定倍数。
稳定系统中，请求在途数量会同时受到达率和停留时间影响。假设到达率不变而平均处理变慢，在途请求就会增加，这些请求又会占用内存、连接和工作槽位。用同一入口、同一时间窗、同一单位做数量级核对；不要把浏览器思考时间计入数据库连接占用时间，也不要用瞬时值验证平均关系。
- 分别记录在线用户、业务动作数、接口请求数与在途请求数。
- 时间统一成秒，注明统计窗口以及是否包含失败与重试。
把业务动作拆成负载组合与依赖预算
真实高峰不是每个接口流量相同。活动页读取可能集中在一个商品，提交写入可能争抢同一库存，后台报表可能与交易共享数据库；总 QPS 相同也会产生完全不同的资源压力。
先按业务动作估算接口比例，再展开每条路径对存储与外部依赖的访问次数。读缓存命中和未命中要分开建模，外部限额也要记录。一次提交若包含多条查询与一次重试，其数据库负载应单独计算；测试中的均匀随机数据不能替代真实热点。
- 保留常规、活动、冷缓存和后台任务叠加四类负载组合。
- 把单次动作的数据库查询数、外部调用数和大对象大小列入预算。
通过逐级负载寻找可持续容量和拐点
固定并发模型在系统变慢时可能自动减少新请求。若目标是验证持续到达的活动流量，应使用与到达率匹配的开放模型，并检查负载发生器是否真的发出了计划请求。
k6 官方区分开放模型与闭合模型，constant-arrival-rate 调度的是业务迭代而非天然等于 HTTP QPS：一轮含几个请求，就要结合脚本计算。逐级加压时同时看成功完成量、延迟、在途请求与依赖等待，出现吞吐趋平而排队持续增长时，继续增加入口流量通常只会恶化体验。
- 每级保持足够时间观察缓存、连接与队列进入稳定状态。
- 记录计划迭代、实际请求、未启动迭代和成功业务操作，避免错算容量。
实施步骤：建立基线后再提出扩容方案
第一步收集业务峰值和配置；第二步复现代表性数据与流量；第三步测出各负载组合的拐点；第四步验证一个优化假设；第五步在节点或依赖异常时重测容量，最后形成容量表。
余量应覆盖扩容生效前的增长、发布替换和故障损失，取多少由业务风险与实测结果决定。新实例不一定立即可用，它可能需要启动、连接建立和热点预热。应用多副本还会扩大数据库连接总数，所以扩容方案必须列出共享依赖的上限和相应费用。
- 容量表标明代码版本、数据规模、实例规格、负载结构与可持续时长。
- 同时给出优化、扩容和入口保护触发条件以及负责人。
验收重点：证明业务完成量与故障余量
验收报告应能回答在约定流量下用户是否及时完成操作，系统是否保持正确，以及失去部分容量后多久恢复。一个脱离环境和业务结构的“支持多少并发”不能作为交付结论。
比较优化前后时固定负载模型和数据，保留未达标阶段与发生器限制。除正常峰值外，再验收突增、持续高峰和单节点退出。计算能力时排除无效请求与失败，但保留这些流量用于解释资源消耗；最终把无法测试的第三方和生产差异写为条件。
容量表还应列出有效期：数据增长到什么范围、访问比例怎样改变、哪个依赖升级后需要重新测试。采购容量时把性能目标写成带条件的业务结果，避免供应商和使用方分别按不同请求口径验收；实测未达到目标的负载阶段也应保留，供后续优化判断。
- 检查高峰结束后排队是否清空，连接和内存是否回到稳定区间。
- 复核限流、重试和自动扩容不会相互抵消或放大压力。
需求讨论中的问题
十万用户同时在线需要多少台服务器？
不能只从在线人数决定。先确认每秒执行哪些动作、一次动作包含多少请求、真实数据与热点分布，以及目标延迟，再测每个资源组合的可持续业务完成量。
并发数等于 QPS 乘响应时间吗？
在统计边界一致的稳定系统中，平均在途请求数可用平均到达率乘平均停留时间做核对。瞬时峰值、非稳定积压、在线人数和 P99 延迟不能直接套这个关系。
容量测完可以一直使用吗？
增加业务步骤、扩大数据、变更依赖、调整实例规格或改变热点都会使结论过期。容量表应写明适用版本与复测触发条件，尤其在大活动前重新验证。
容量规划交付验收清单
可逐项勾选，辅助本次阅读；刷新页面后不保留。
参考资料
技术概念可进一步阅读以下资料；文中的业务场景与实施清单用于方案讨论。
- Grafana k6：Open and closed models
核验固定并发与开放到达率模型的区别，以及系统变慢对闭合模型实际到达率的影响。
- Grafana k6：Constant arrival rate
核验 rate 对应迭代启动速率；文中容量表与余量评估是需结合项目实测的实施建议。
- MIT OpenCourseWare：Elements from Queueing Theory
核验 Little 定律 L = λW 的平均数量与平均停留时间关系，并明确统计边界和稳定状态条件。
需要评估现有系统的性能瓶颈？
提供关键业务路径、真实峰值、服务器与数据库配置，以及现有压测或故障记录，月弦科技可据此梳理优化顺序、实施范围和可验证的验收条件。