先定基线再谈扩容
大促容量预测的核心不是算出一个精确数字，而是根据历史流量曲线、业务增长系数和营销节奏，圈定一个弹性伸缩的合理区间，让扩容动作提前于流量峰值完成。太多团队把容量预测做成了一次性估算，促销前拍脑袋定个上限，结果要么超买浪费预算，要么低估导致宕机,真正靠谱的做法是把预测当成一个动态校准的过程。
为什么要做容量预测：大促宕机的代价远超想象
电商大促的流量特征和日常完全不同，日常流量是平缓的曲线，大促流量是陡峭的尖峰，以618、双11这类大促为例，流量往往在开场前10分钟就冲到日常峰值的数倍，之后缓慢回落，这个尖峰窗口期一旦扛不住，用户看到的不是加载缓慢,而是直接的白屏和连接失败。
业内专家指出，大促期间的系统不可用，直接损失不仅是订单流失，还有品牌信任度的长期损伤，用户在大促场景下耐心极低，页面打开超过3秒，相当一部分用户会直接退出，容量预测的意义就在于把这个风险前置,用提前规划来替代临场救火。
容量预测本质上是在回答三个问题：峰值流量有多高、需要多少资源扛住、这些资源什么时候到位，回答不了这三个问题,扩容就是在赌博。
容量预测的核心步骤：从历史数据到峰值估算
第一步：拉取近三年的历史流量数据
这里的流量数据不只是PV/UV，要细化到核心接口的QPS（每秒请求数）、数据库的TPS（每秒事务数）、带宽使用率、CDN回源率，按小时粒度拉取最近三次大促的完整数据,以及大促前后一周的日常数据作对比。
数据要按业务线拆分，首页、搜索、商品详情、下单、支付、购物车，每个模块的流量曲线差异很大，支付模块的峰值往往滞后于浏览模块，购物车接口的波动幅度比首页更剧烈，混在一起看,容易低估高压力模块的容量需求。
第二步：计算业务增长系数
历年大促的流量自然增长曲线要纳入考量，如果店铺近一年GMV增长了30%，那么今年大促的流量预测就需要在去年基础上乘以1.3左右的系数，这个系数不是拍出来的,要用近三个月的日均流量对比去年同期增幅来校准。
另外要留意大促节奏的变化，预售期变长、活动预热提前、直播带货分流，这些都会改变流量集中度，行业共识认为，直播电商的兴起让流量峰值从单一尖峰变成了多波次脉冲,每一波直播活动都可能产生一个次级别峰值。
第三步：把业务目标换算成技术指标
这一步是容量预测的落地关键，假设今年大促目标GMV是5000万，客单价300元，转化率5%，可以倒推出需要多少访问量，访问量换算成QPS，QPS再结合单次请求的平均资源消耗，就能得出需要多少台应用服务器、多大的数据库集群。
单次请求的资源消耗需要压测数据支撑，没有压测数据,一切换算都是空中楼阁。
容量预测工具怎么选：自建模型还是云厂商方案
工具选型的核心看团队规模和运维能力，中小团队直接使用云厂商的弹性伸缩组加负载均衡监控,大团队则建议自建压测平台加容量预测模型。
市面上主流云厂商都提供了容量预测相关的服务，比如简米云的弹性伸缩ESS、酷番云的弹性伸缩AS，以及AWS的Auto Scaling，这些工具的共同逻辑都是基于监控指标触发扩容，但触发存在延迟，对突发尖峰的响应能力有限，真正的大促场景，需要的是提前预热的定时扩容,而不是事后的被动触发。
自建容量模型的路径相对复杂，但可控性更强，基本思路是将历史流量数据、活动日历、营销预算投入产出比作为特征，利用时间序列预测算法或简单的线性回归模型，输出未来24至48小时的流量曲线预测，已经有不少开源方案可以参考，比如Facebook的Prophet库,处理电商这种带强周期性和节假日效应的数据表现不错。
自建模型的核心配置参考
| 配置项 | 推荐方案 | 说明 |
|---|---|---|
| 数据源 | MySQL + Redis 监控数据 | 存储历史QPS、RT、CPU使用率 |
| 预测算法 | Prophet 或 ARIMA | 支持周期性和节假日效应 |
| 触发方式 | 定时任务 + 手动校准 | 大促前3天每天跑一次 |
| 输出口径 | 小时级粒度 | 精确到每小时的峰值预估 |
云厂商方案的优点是部署快、运维成本低，缺点是预测逻辑黑盒，无法根据业务节奏精细调整，行业内的主流做法是大促前用云厂商工具做基础保障,再利用自建模型做精细化扩容排期。
扩容资源怎么规划：容器、数据库、带宽一个都不能少
应用层扩容：无状态服务优先
应用层扩容是成本最低、速度最快的，无状态服务可以直接横向扩展，在大促前一周把副本数从10个扩展到50个，都是常规操作，但要注意，扩容本身不是免费的，每个新副本都需要时间拉取镜像、注册到服务发现、通过健康检查，一个Spring Boot应用从启动到接受流量，大约需要1至3分钟,所以要预留启动时间窗口。
数据库层扩容：只读副本和连接池双管齐下
数据库是整个链路里最脆弱的一环，行业常用的方案是提前升级规格，并用只读副本承担读流量，MySQL在高峰期最容易出现的问题不是磁盘不足，而是连接数耗尽，连接池的最大连接数要从日常的100调整到500左右，同时把慢查询阈值调低,防止单个慢SQL拖垮整个实例。
更进一步的方案是分库分表，但分库分表不是大促前能临时做的事情，需要在系统设计阶段就做好，大促前能做的主要是增加缓冲层，比如Redis缓存热点商品信息,降低数据库的直接压力。
带宽和CDN：容易被忽视的容量瓶颈
带宽也是大促期间常出问题的点，图片、视频、商品详情页的静态资源，尽量全部走CDN，源站带宽要预留20%至30%的余量，大促前用工具测一下全国各地CDN节点的命中率，如果某个区域的命中率低于90%,需要检查该区域的节点覆盖情况。
WebSocket长连接占用的带宽容易被低估，秒杀场景下，大量用户保持长连接等待状态,每个连接即使不传数据也会占用一定带宽资源。
容量预测的常见误区：为什么预测总是不够准
只预测峰值，忽略流量爬坡过程
多数系统的崩溃并不是发生在峰值瞬间，而是发生在流量快速爬坡的过程里，扩容操作需要时间，如果预测只给一个峰值数字，没有给时间轴上的流量曲线，就无法确定扩容操作应该在哪个时间点开始，正确的做法是预测时分段输出结果,列出每小时预计的QPS区间。
忽略突发流量对慢SQL的连锁反应
容量预测通常只关注流量和硬件的匹配关系，忽略了软件层面的故障放大效应，当流量升高，数据库压力增大，SQL查询变慢，应用层线程池被占满，响应时间进一步恶化，用户不断重试，导致更多请求涌入，这种雪崩效应，会让实际需要的资源量超出预测值的两倍以上，所以容量预测的结果需要乘上一个安全系数，业内一般取1.5至2倍作为扩容上限。
静态扩容后不做实时调整
很多团队的容量预测是一次性的，大促开始后就不再调整，但流量曲线受实时营销效果影响很大，某个主播的直播间突然爆了，流量可能瞬间翻倍，所以大促当天必须安排专人盯着监控大盘，每小时校准一次容量数据,根据实际流量走势动态调整扩容计划。
容量预测多少钱：成本预算怎么定
容量预测本身的成本不高，主要支出在于弹性扩容后的资源费用增加，一次大型大促的系统扩容成本大致是平时月费用的两到三倍,具体取决于扩容的规模和持续时间。
成本可以从以下三个维度来拆分：
- 扩容时长：提前一天扩容还是提前一周扩容，费用差异很大，建议精确到小时级扩容,流量回落就及时缩容。
- 扩容规格：先从低规格开始扩容，观察负载情况再逐步升配,避免一上来就上最高规格。
- 预留实例和按量付费的搭配：长期稳定使用的部分用预留实例，大促临时增量用按量付费，混合模式比全部按量付费节省约20%成本。
Q&A
大促容量预测一般提前多久开始做？
建议提前一个月启动，第一周完成历史数据拉取和清洗，第二周建立预测模型并和历史数据交叉验证，第三周进行压测和扩容演练，第四周根据活动报名情况和营销节奏做最终校准，预留时间不足两周的预测，基本只能靠经验估算,准确性很难保证。
没有历史数据的新业务，怎么做容量预测？
新业务没有历史大促数据，可以参照日常峰值和业务增长速度做初步估算，具体做法是拿近30天日均QPS乘以5倍作为第一版峰值预估，再通过两轮压测验证上限，如果系统在预设压力下表现稳定，就逐步加压，直到找到瓶颈点，这个方法没有理论基础支撑,但能在缺乏数据的情况下给出一个相对可靠的起点。
容量预测不是一次性工作，而是贯穿大促筹备全周期的动态过程，先建立起流量数据的采集和记录习惯，把每次大促的资源使用情况沉淀下来，预测的准确率会随着数据积累逐步提升，下一次大促前,你会感谢上一次大促时认真记录数据的自己。