服务器容量规划，说白了就是回答三个问题：现在需要几台机器、将来增长到多少要扩、扩到什么程度算够。很多团队的做法是"上线先买两台，扛不住再加"，结果要么高峰期被打挂，要么长期闲置浪费钱。容量规划不是算命，而是一套可以算的流程：从用户数和请求量出发，换算成资源需求，再叠加峰值和冗余。
这篇文章给一条可执行的容量规划路径：用户增长 → 请求量（PV/QPS）→ 资源换算 → 单机能力评估 → 冗余系数 → 扩容阈值 → 成本测算，最后用一个完整示例把数字算一遍。文中所有倍数和阈值都是经验值，不同业务差异很大，务必用你自己的压测数据替换。
一、容量规划解决什么问题
- 别把机器买少了：高峰被打挂，损失的是业务和口碑。
- 别把机器买多了：长期闲置，白花预算。
- 让扩容有依据：不是"感觉卡了加一台"，而是"监控到了阈值，按预案加几台"。
- 让成本可控：知道每 QPS 花多少钱，才能做性价比决策。
它的本质是把"业务增长"翻译成"机器数量"，并且留出合理的缓冲。
二、核心换算链路：用户 → 请求量 → 资源
这是容量规划的主线，一环扣一环：
日活用户（DAU）
× 人均请求次数/天
= 日请求量（PV）
÷ 86400 秒
= 平均 QPS
× 峰值系数
= 峰值 QPS
÷ 单机承载 QPS
= 所需机器数
× 冗余系数
= 最终建议机器数
每一步都有经验参数：
| 环节 | 经验取值 | 说明 |
|---|---|---|
| 人均请求/天 | 几十到几百 | 看业务形态，社交类低、API 类高 |
| 峰值系数 | 3~5 倍（大促可 >10） | 日均换算峰值 |
| 单机承载 QPS | 压测得出 | 必须以实测为准 |
| 安全水位 | 单机跑 50%~70% | 留余量应对突发 |
| 冗余系数 | 1.5~2 倍起 | 含 N+1 与增长预留 |
一个容易忽略的点：QPS 和请求类型强相关。纯内存接口可能单机几万 QPS，涉及数据库复杂查询的可能只剩几百。所以"单机承载多少"必须对具体接口压测，不能笼统说。
三、评估单机承载能力
单机承载能力只能靠压测得到，方法：
- 选代表接口：挑业务占比最高、最耗资源的接口（通常是核心业务接口）。
- 阶梯加压：用 wrk、ab 等工具从小到大加并发，记录每个并发下的 QPS、响应时间、错误率和资源使用。
- 找拐点：QPS 达到平台、响应时间开始明显上升、错误率抬头，那个点就是单机上限。
- 留安全水位：不要按上限规划，按上限的 50%~70% 作为"可承载能力"。
# 阶梯加压示例：并发从 50 加到 400，各跑 30 秒
for c in 50 100 200 400; do
echo "=== 并发 $c ==="
wrk -t4 -c$c -d30s --latency http://127.0.0.1:8080/api/hot
done
同时盯服务端资源：
# CPU、内存、负载
vmstat 1 5
top -bn1 | head -20
# 实时看关键指标（若安装了 sysstat）
sar -u 1 5
记录下"QPS 还能涨、响应还稳"的最大并发对应的 QPS，作为单机能力参考。
四、峰值与冗余系数
峰值系数怎么定
业务不可能全天均匀。经验上：
- 一般业务：峰值约为日均的 3~5 倍。
- 有明显高峰的业务（新闻、票务、外卖）：5~10 倍。
- 大促/秒杀：可能几十倍，需要专门预案，不能按常规容量规划。
拿不到峰值数据时，先看历史监控里的峰值/均值比，比经验值更可靠。
冗余系数怎么定
冗余不只是"防波动"，还包括：
- 高可用冗余（N+1）：少一台不影响服务，至少多备一台。
- 增长预留：按未来 3~6 个月的增长预留空间。
- 故障与维护：滚动发布、机器故障时仍能扛住。
经验上，生产环境最终机器数至少是"刚好够用"的 1.5~2 倍。可用性要求高的业务还要更高。常见做法是把单机水位控制在 50%~70%，等效于 1.4~2 倍冗余。
五、扩容触发阈值
有了容量，还要有"什么时候该扩"的判断，通常靠监控告警：
| 指标 | 建议阈值 | 说明 |
|---|---|---|
| CPU 利用率 | 持续 > 60%~70% | 峰值时段持续高就要警惕 |
| 内存利用率 | 持续 > 70%~80% | 注意是否还有缓存增长空间 |
| 磁盘利用率 | > 70%~80% | 留写空间，也防日志写满 |
| 磁盘 IO 等待 | await 明显升高 | 数据库尤其关注 |
| 带宽利用率 | 持续 > 70% | 靠近购买带宽上限 |
| P95/P99 响应时间 | 超过 SLO | 最贴近用户感受 |
| 错误率 | 抬头即告警 | 5xx、超时率上升 |
原则：阈值要"持续一段时间"才触发，避免毛刺误报；同时阈值设在"还能扛但已经不宽松"的位置，留出扩容的操作时间。响应时间超 SLO 往往是最该扩的信号，因为它是用户直接感知的。
六、成本测算
成本测算的核心是"每 QPS 成本"，用它比较不同方案：
每 QPS 月成本 ≈ 单机月成本 ÷ 单机可支撑 QPS
比如一台机器月成本 500 元、可支撑 500 QPS，那每 QPS 约 1 元/月。这个数字可以用来：
- 比较纵向扩容（换更强单机）和横向扩容（多台普通机）。
- 评估某接口 QPS 增长带来的成本增量。
- 判断优化（降低单请求资源消耗）和加机器哪个更划算。
别忘了把这些成本也算进去：带宽费、存储费、负载均衡、备份、监控、人力运维。只算机器不算配套，测算会偏低。
另外提醒一点：成本测算要按"可承载 QPS"而不是"标称 QPS"来算。标称参数好看但不一定跑得出来，用压测得到的稳定承载能力做分母，才不会被虚高的数字误导。
七、一个完整的容量估算示例
假设一个业务，用经验参数走一遍（数字为演示用，需用你自己的数据替换）：
- 用户：注册用户 100 万，日活 10 万。
- 请求量：人均每天 80 次请求 → 每天 800 万 PV。
- 平均 QPS：800 万 ÷ 86400 ≈ 92.6 QPS。
- 峰值系数：取 3 → 峰值约 278 QPS。
- 单机能力：压测得出该接口单机稳定 400 QPS（水位 60%）可支撑 240 QPS 左右。
更保守：把单机可承载定在 300 QPS。 - 所需机器数：278 ÷ 300 ≈ 0.93，即 1 台勉强够。
- 叠加冗余：按 1.5~2 倍，且要 N+1 高可用 → 至少 2 台，建议 3 台。
- 增长预留：按半年内日活翻倍预估，峰值 QPS 变约 556，需 556 ÷ 300 ≈ 1.9 台 → 2 台起步，加冗余 → 3~4 台。
- 成本：若单机月成本 500 元，3 台每月 1500 元，每 QPS 成本约 1500 ÷ 278 ≈ 5.4 元/月（按当前峰值算，加入增长后更优）。
结论：现在上线 2 台、预留 1 台扩展位，或直接上 3 台保证高可用，按月复核增长数据再调。
常见问题
Q1：没有压测数据能做容量规划吗？
可以先按经验值粗估，但强烈建议补压测。没有单机能力的实测数字，规划全是拍脑袋，误差可能好几倍。
Q2：峰值系数到底取多少？
优先看历史监控里的峰值/均值比。没有历史数据就取 3~5，有明显高峰特征或多做活动就取更大，并做压测验证。
Q3：纵向扩容和横向扩容怎么选？
单机还没到上限、想快速见效，选纵向；流量增长快、要高可用和弹性，选横向。多数互联网业务最终走横向，靠负载均衡分摊。
Q4：冗余系数是不是越大越安全？
冗余越大越安全，但也越贵。关键是可接受的风险和成本平衡。一般生产按 1.5~2 倍，核心业务更高，非核心可低一些。
Q5：容量规划多久做一次？
至少每季度复核一次，有重大活动、重大版本、用户快速增长时随时复核。容量规划是持续过程，不是一次性任务。
总结
- 容量规划的主线：DAU → 日 PV → 平均 QPS → 峰值 QPS → 单机能力 → 机器数 → 冗余系数。
- 单机承载能力必须靠压测得到，按上限的 50%~70% 作为水位，别按极限规划。
- 峰值系数一般取 3~5 倍，冗余系数（含 N+1 与增长预留）一般 1.5~2 倍起，都属经验值。
- 扩容靠监控阈值触发：CPU/内存/磁盘/带宽利用率持续偏高、P95/P99 超 SLO、错误率抬头。
- 用"每 QPS 月成本"做决策，记得把带宽、存储、备份、运维等配套成本一起算。所有倍数与阈值以自身业务实测为准。
企业QQ咨询
