视频来源：B站 IT老齐
本文为视频学习笔记 + 扩展整理，结合京东大促、电商系统等实际场景。
一、什么是容量评估
容量评估是在系统上线或大促前，预估系统需要多少资源（服务器、带宽、数据库等）才能扛住业务流量的过程。
说白了就是回答一个问题：大促来了，我需要几台机器？
1. 为什么要做容量评估
| 场景 | 不做容量评估的后果 |
|---|---|
| 新系统上线 | 机器配少了扛不住，配多了浪费钱 |
| 电商大促（618/双11） | 流量暴增导致系统崩溃，直接损失营收 |
| 业务增长 | 用户量翻倍后系统响应变慢，用户流失 |
| 架构升级 | 无法评估新架构能否满足业务需求 |
2. 核心指标
| 指标 | 含义 | 说明 |
|---|---|---|
| QPS | Queries Per Second | 每秒查询数，衡量读取能力 |
| TPS | Transactions Per Second | 每秒事务数，衡量写入/处理能力 |
| RT | Response Time | 平均响应时间 |
| 并发数 | Concurrency | 同时处理的请求数 |
核心关系公式：
QPS = 并发数 ÷ 平均响应时间（秒）例如：100 个并发，平均响应 0.1 秒 → QPS = 100 ÷ 0.1 = 1000
二、容量评估五步法
第一步：预估总流量
从产品/运营获取业务数据：
- 日活用户数（DAU）
- 日均 PV（页面访问量）
- 日均订单量
- 活动期间预计增长倍数
这些数据"不能全信也不可不信"，通常参考历史数据 + 业务增长预期。
第二步：计算平均 QPS
平均 QPS = 总请求数 ÷ 总时长（秒）示例： 日均 300 万 PV，每个页面平均产生 30 次接口调用：
总请求数 = 300万 × 30 = 9000万
平均 QPS = 9000万 ÷ 86400秒 ≈ 1042 QPS第三步：计算峰值 QPS
平均值不代表真实压力，需要估算峰值。有两种常用方法：
方法一：二八原则
80% 的访问集中在 20% 的时间内
峰值 QPS =（总 PV × 80%）÷（86400秒 × 20%）示例： 300 万 PV
峰值 QPS =（300万 × 0.8）÷（86400 × 0.2）= 240万 ÷ 17280 ≈ 139 QPS方法二：峰值倍数法（更常用）
峰值 QPS = 平均 QPS × 峰值系数（一般 3~5 倍）示例： 平均 QPS 为 1000
峰值 QPS = 1000 × 5 = 5000 QPS大促场景（618/双11）峰值可达日常的 10~20 倍，需要单独评估。
第四步：压测单机性能
通过压力测试得出单台服务器的极限 QPS：
| 组件 | 经验参考值 |
|---|---|
| Nginx（静态） | 5万~10万 QPS |
| Java 应用（Spring Boot） | 1000~5000 QPS |
| MySQL（简单查询） | 6000~10000 QPS |
| Redis | 8万~10万 QPS |
| RPC 调用（Dubbo） | ~10万 QPS |
这只是经验参考值，实际以压测结果为准。生产环境不要跑满，建议按极限的 80% 计算。
第五步：计算服务器数量
所需服务器数 = 峰值 QPS ÷ 单机 QPS（按 80% 计算）示例： 峰值 5000 QPS，单机压测极限 1000 QPS
单机安全 QPS = 1000 × 0.8 = 800
所需服务器 = 5000 ÷ 800 = 6.25 → 取整 7 台再加上容量冗余（通常 1.5~3 倍）：
最终服务器 = 7 × 2 = 14 台三、京东大促容量评估实践
1. 流量预估
京东 618 容量规划的核心思路：
历史峰值 × 业务增长系数 × 安全冗余系数 = 目标容量| 维度 | 评估方法 |
|---|---|
| 流量预估 | 去年同期峰值 × 增长倍数 |
| 接口级预估 | 核心接口单独评估 QPS |
| 链路级预估 | 从入口到 DB 全链路分析瓶颈 |
2. 全链路容量分析
一次用户请求可能经过多个环节，木桶原理------最短板决定整体容量：
用户请求
→ 网关（10万 QPS）
→ 应用服务（3000 QPS × N 台）
→ 缓存（Redis 10万 QPS）
→ 数据库（MySQL 8000 QPS）
→ 消息队列（Kafka 10万 QPS）瓶颈分析： 假设应用层单机 3000 QPS，要支撑 3 万峰值 QPS：
应用层：30000 ÷ 3000 = 10 台
数据库：30000 ÷ 8000 = 3.75 → 4 台（读写分离）
Redis：30000 ÷ 100000 = 1 台（单机足够）3. 大促容量公式
目标容量 = max(去年峰值, 运营预估) × 增长系数 × 冗余系数| 参数 | 取值建议 |
|---|---|
| 增长系数 | 1.2~2.0（根据业务增长率） |
| 冗余系数 | 1.5~3.0（核心系统取高值） |
四、各层资源评估
1. 带宽评估
所需带宽 = 峰值 QPS × 平均响应大小示例： 峰值 5000 QPS，平均响应体 50KB
带宽 = 5000 × 50KB = 250MB/s ≈ 2Gbps2. 数据库容量评估
| 维度 | 评估方式 |
|---|---|
| 连接数 | 应用服务器数 × 单机连接池大小 |
| 磁盘 | 日增数据量 × 保留天数 × 1.3（索引开销） |
| QPS | 核心 SQL 压测 + 慢 SQL 治理 |
3. 缓存容量评估
Redis 内存 = 热点数据量 × 平均 Value 大小 × 副本数示例： 1000 万用户信息缓存，每条 1KB，3 副本
内存 = 1000万 × 1KB × 3 = 30GB五、容量评估的保障措施
1. 压测验证
容量评估只是"纸上谈兵"，必须通过压测验证：
| 压测类型 | 说明 |
|---|---|
| 单机压测 | 确定单台服务器极限 |
| 集群压测 | 验证整体架构承载能力 |
| 全链路压测 | 模拟真实大促流量（京东/阿里都在用） |
2. 降级预案
容量评估再精准，也要有兜底方案：
| 降级手段 | 适用场景 |
|---|---|
| 限流 | 流量超出预期 |
| 熔断 | 下游服务不可用 |
| 降级 | 非核心功能关闭 |
| 异步化 | 将同步操作改为异步 |
3. 弹性扩容
云原生架构下，可通过自动扩容应对突发流量：
监控指标（CPU/QPS）超阈值 → 触发扩容 → 新节点上线 → 流量分摊六、总结
容量评估速查表
| 步骤 | 关键动作 | 产出 |
|---|---|---|
| 1. 预估总流量 | 获取 DAU、PV、订单量 | 业务基准数据 |
| 2. 算平均 QPS | 总请求 ÷ 总时长 | 日常负载水位 |
| 3. 算峰值 QPS | 平均值 × 3~5 倍 | 峰值目标 |
| 4. 压测单机 | 单台服务器跑满 × 0.8 | 单机安全容量 |
| 5. 算服务器数 | 峰值 ÷ 单机容量 × 冗余系数 | 最终资源需求 |
核心公式汇总
QPS = 并发数 ÷ 平均响应时间
峰值 QPS = 平均 QPS × 3~5
所需服务器 = 峰值 QPS ÷（单机极限 QPS × 0.8）× 冗余系数
所需带宽 = 峰值 QPS × 平均响应大小面试回答要点
| 面试问题 | 关键回答 |
|---|---|
| 怎么做容量评估？ | 五步法：预估流量 → 算平均 → 算峰值 → 压测单机 → 算服务器 |
| 峰值怎么算？ | 二八原则或均值 × 3~5 倍，大促可达 10~20 倍 |
| 怎么确定单机性能？ | 压测，生产按极限的 80% 跑 |
| 冗余怎么留？ | 1.5~3 倍，核心系统取高值 |
| 容量评估之后呢？ | 压测验证 + 降级预案 + 弹性扩容 |
参考资料：