大流量活动前端容量预估：从 PV 到 QPS 的换算与压测策略（续篇）

大流量活动前端容量预估：从 PV 到 QPS 的换算与压测策略（续篇）

场景痛点

双十一秒杀活动。预估峰值PV 500万。前端团队问：500万PV对应多少QPS？需要多少台服务器？CDN能不能扛住？

运营给的数据是"活动期间总PV 500万"。但PV是10小时的总和。峰值可能在活动开始的第1分钟——那1分钟的PV可能是总PV的30%。150万PV/分钟 = 25000 QPS。这个推算链每个环节都有假设，假设错了容量预估就错了。

更常见的问题：压测环境测出Nginx单机QPS 5000。上生产后实际QPS只有2000。因为压测用的静态文件，生产有API请求、SSR渲染、CDN回源。压测数据与生产数据的偏差让容量预估失去意义。

核心矛盾：容量预估需要从宏观指标（PV）推算到微观指标（QPS、CPU、内存），每个推算步骤都有不确定性。压测验证需要贴近生产环境，但压测环境永远无法100%还原生产。

底层机制与原理剖析

从PV到QPS到容量的推算链：

关键推算步骤：

1. PV→峰值PV。总PV是活动期间的总和。峰值PV取决于流量分布模型。典型大促活动的流量分布：

   • 活动开始5分钟：占总PV的30%（秒杀抢购）
   • 活动持续期：占总PV的50%
   • 活动尾声：占总PV的20%

   保守策略：峰值PV = 总PV × 0.3 / 峰值持续时间(分钟)。如果峰值持续5分钟：500万×0.3/5分钟=30万PV/分钟。

2. PV→QPS。一个PV不等于一个请求。一个页面加载包含：1个HTML请求 + 1个API请求 + 10个静态资源请求（JS/CSS/图片）。但静态资源90%走CDN，不压源站。源站只处理HTML+API = 2请求/PV。

   源站QPS = 峰值PV/min × 2请求/PV / 60秒 = 30万×2/60 = 10000 QPS。

   但如果SSR渲染每个HTML需要50ms CPU时间，单机QPS约200（受CPU瓶颈而非连接数瓶颈）。10000/200 = 50台SSR服务器。

3. QPS→容量。需要压测实测单机QPS基线。压测数据需要贴近生产——不能只测静态文件，要测SSR渲染+API调用+数据库查询的真实链路。

生产级代码实现

CapacityEstimator：容量预估引擎

// capacity/capacity-estimator.ts interface ActivityConfig { totalPV: number; // 活动期间总PV activityDurationHours: number; // 活动总时长(小时) peakRatio: number; // 峰值占比(0~1)，默认0.3 peakDurationMinutes: number; // 峰值持续时间(分钟)，默认5 requestsPerPV: number; // 每PV的源站请求数，默认2(HTML+API) cdnHitRate: number; // CDN命中率，默认0.9 ssrCpuTimeMs: number; // SSR渲染CPU时间(ms)，默认50 apiCpuTimeMs: number; // API处理CPU时间(ms)，默认20 machineQpsBaseline: number; // 单机QPS基线(压测实测)，默认200 redundancyFactor: number; // 冗余系数，默认1.5 } interface CapacityResult { peakPVPerMinute: number; sourceQPS: number; // 源站峰值QPS ssrQPS: number; // SSR渲染QPS apiQPS: number; // API处理QPS cdnQPS: number; // CDN处理QPS（静态资源） ssrMachineCount: number; // SSR服务器数 apiMachineCount: number; // API服务器数 totalMachineCount: number; // 总服务器数 cdnBandwidthMbps: number; // CDN带宽需求 ssrCpuUtilization: number; // SSR CPU利用率预估 riskAssessment: RiskLevel; assumptions: string[]; // 所有假设列表 } type RiskLevel = 'low' | 'medium' | 'high' | 'critical'; class CapacityEstimator { // 活动流量分布模型（典型大促） // 为什么需要流量分布模型而非简单线性分配： // 真实活动的流量不是均匀分布的，峰值集中在前几分钟， // 如果按均匀分布预估，容量严重不足 private static TRAFFIC_DISTRIBUTION = { 'flash_sale': { // 秒杀：峰值极端集中 peakRatio: 0.4, peakDurationMinutes: 2, description: '秒杀活动：40%流量集中在2分钟内' }, 'promotion': { // 促销：峰值较集中 peakRatio: 0.3, peakDurationMinutes: 5, description: '促销活动：30%流量集中在5分钟内' }, 'normal_peak': { // 日常高峰：峰值分散 peakRatio: 0.15, peakDurationMinutes: 30, description: '日常高峰：15%流量分散在30分钟内' } }; estimate(config: ActivityConfig): CapacityResult { const assumptions: string[] = []; // 步骤1：PV → 峰值PV const peakPVPerMinute = config.totalPV * config.peakRatio / config.peakDurationMinutes; assumptions.push(`峰值占比${config.peakRatio*100}%，持续${config.peakDurationMinutes}分钟`); assumptions.push(`峰值PV/min = ${config.totalPV}×${config.peakRatio}/${config.peakDurationMinutes} = ${peakPVPerMinute.toFixed(0)}`); // 步骤2：峰值PV → QPS分解 // 总请求/PV = HTML(1) + API(1) + 静态资源(10) = 12请求/PV // 为什么区分SSR和API的QPS：SSR和API的计算瓶颈不同（SSR是CPU密集，API是IO密集）， // 需要独立计算机器数 const totalRequestsPerPV = 12; // HTML + API + 10个静态资源 const sourceRequestsPerPV = config.requestsPerPV; // HTML + API（源站处理） const cdnRequestsPerPV = totalRequestsPerPV - sourceRequestsPerPV; // 静态资源走CDN const peakQPSPerMinute = peakPVPerMinute * totalRequestsPerPV / 60; const sourceQPS = peakPVPerMinute * sourceRequestsPerPV / 60; const cdnQPS = peakPVPerMinute * cdnRequestsPerPV / 60; // 分解源站QPS为SSR和API // 为什么按请求类型分解而非统一处理： // SSR请求和API请求的CPU时间差异大（50ms vs 20ms）， // 统一处理会低估SSR的CPU瓶颈 const ssrQPS = peakPVPerMinute / 60; // 每PV 1个HTML请求 const apiQPS = peakPVPerMinute / 60; // 每PV 1个API请求 // 步骤3：QPS → 机器数 // SSR单机QPS：受CPU瓶颈限制 // 单核CPU每秒处理1000ms/50ms = 20个SSR请求。 // 8核机器：20×8 = 160 QPS（理论值） // 实际QPS = 理论值×0.8（GC、调度等开销） // 为什么乘0.8而非1.0：理论计算忽略了GC暂停、线程调度、 // 网络IO等待等开销，这些在实际运行中约占20%CPU时间 const ssrQpsPerMachine = Math.floor(8 * 1000 / config.ssrCpuTimeMs * 0.8); assumptions.push(`SSR单机QPS = 8核×1000ms/${config.ssrCpuTimeMs}ms×0.8 = ${ssrQpsPerMachine}`); // API单机QPS：受IO瓶颈限制（数据库查询+网络延迟） const apiQpsPerMachine = config.machineQpsBaseline; assumptions.push(`API单机QPS = 压测实测值 ${apiQpsPerMachine}`); // 机器数 = QPS / 单机QPS × 冗余系数 // 为什么冗余系数1.5而非2.0：1.5倍保证1/3机器故障时仍能服务。 // 2.0倍意味着一半机器故障仍能服务——过度的冗余浪费成本 const ssrMachineCount = Math.ceil(ssrQPS / ssrQpsPerMachine * config.redundancyFactor); const apiMachineCount = Math.ceil(apiQPS / apiQpsPerMachine * config.redundancyFactor); const totalMachineCount = ssrMachineCount + apiMachineCount; // 步骤4：CDN带宽预估 // 静态资源平均大小：JS 200KB + CSS 50KB + 图片 100KB × 8 = 1050KB/PV // CDN QPS × 平均资源大小 = 带宽需求 const avgStaticResourceSizeKB = 1050; const cdnBandwidthMbps = cdnQPS * avgStaticResourceSizeKB * 8 / 1000; // KB×8bits/1000=Mbps assumptions.push(`静态资源平均${avgStaticResourceSizeKB}KB/PV`); // 步骤5：风险评估 const risk = this.assessRisk(config, { sourceQPS, ssrMachineCount, apiMachineCount, ssrQpsPerMachine, apiQpsPerMachine }); // SSR CPU利用率预估（峰值时） const ssrCpuUtilization = ssrQPS / (ssrMachineCount * ssrQpsPerMachine); return { peakPVPerMinute, sourceQPS, ssrQPS, apiQPS, cdnQPS, ssrMachineCount, apiMachineCount, totalMachineCount, cdnBandwidthMbps, ssrCpuUtilization, riskAssessment: risk, assumptions }; } private assessRisk( config: ActivityConfig, metrics: { sourceQPS: number; ssrMachineCount: number; apiMachineCount: number; ssrQpsPerMachine: number; apiQpsPerMachine: number } ): RiskLevel { // 风险因素检查 const risks: string[] = []; // 1. 单机QPS超过压测基线的80%：容量紧张 // 为什么80%而非100%：100%利用率意味着没有缓冲， // 任何波动（突发流量、GC暂停）都会导致排队延迟飙升 if (metrics.ssrMachineCount < 5) { risks.push('SSR机器数<5：单机故障影响大'); } if (metrics.apiMachineCount < 3) { risks.push('API机器数<3：单机故障影响大'); } // 2. CDN带宽超过当前配置的70% if (config.cdnHitRate < 0.85) { risks.push(`CDN命中率${config.cdnHitRate}<85%：回源压力超预期`); } // 3. 峰值持续时间极短（<2分钟）：压测难以精确模拟 if (config.peakDurationMinutes < 2) { risks.push('峰值持续<2分钟：压测模拟精度不足'); } // 风险等级判定 if (risks.length >= 3) return 'critical'; if (risks.length >= 2) return 'high'; if (risks.length >= 1) return 'medium'; return 'low'; } // 生成预估值与压测值的对比报告 // 为什么需要对比：预估基于公式，压测基于实测。 // 两者偏差>30%说明预估模型有问题，需要修正假设 generateComparisonReport(estimated: CapacityResult, actual: StressTestResult): string { const lines: string[] = [ '=== 容量预估 vs 压测实测对比 ===', '', 'QPS对比:', ` 预估源站QPS: ${estimated.sourceQPS}`, ` 压测实测QPS: ${actual.maxQPS}`, ` 偏差: ${((actual.maxQPS - estimated.sourceQPS) / estimated.sourceQPS * 100).toFixed(1)}%`, '', '单机QPS对比:', ` 预估SSR单机QPS: ${estimated.ssrQPS / estimated.ssrMachineCount}`, ` 压测实测单机QPS: ${actual.ssrSingleMachineQPS}`, ` 偏差: ${((actual.ssrSingleMachineQPS - estimated.ssrQPS / estimated.ssrMachineCount) / (estimated.ssrQPS / estimated.ssrMachineCount) * 100).toFixed(1)}%`, '', 'CPU利用率对比:', ` 预估SSR CPU利用率: ${estimated.ssrCpuUtilization.toFixed(2)}`, ` 压测实测CPU利用率: ${actual.ssrCpuUtilization.toFixed(2)}`, ]; // 偏差分析 const qpsDeviation = Math.abs(actual.maxQPS - estimated.sourceQPS) / estimated.sourceQPS; if (qpsDeviation > 0.3) { lines.push(''); lines.push('⚠️ 偏差超过30%，可能原因：'); lines.push(' - 预估的峰值占比假设不准确'); lines.push(' - 预估的每PV请求数不准确'); lines.push(' - 压测环境与生产环境差异过大'); lines.push(' 建议：修正预估模型参数，重新压测验证'); } return lines.join('\n'); } } interface StressTestResult { maxQPS: number; // 压测实测的最大QPS ssrSingleMachineQPS: number; // 单机SSR QPS实测值 apiSingleMachineQPS: number; ssrCpuUtilization: number; apiCpuUtilization: number; p99LatencyMs: number; errorRate: number; }

生产级压测脚本

# scripts/stress-test-realistic.sh #!/bin/bash # 真实链路压测：SSR + API + CDN回源 # 为什么不用wrk压静态文件：静态文件压测的QPS（5000+）与 # 真实SSR渲染的QPS（200）差异10倍以上，静态压测数据没有参考价值 set -euo pipefd # 压测参数 TARGET_HOST="https://staging.example.com" DURATION="300s" # 压测5分钟 CONNECTIONS="500" # 500并发连接 THREADS="4" # 4线程 echo "=== 真实链路压测开始 ===" # 阶段1：预热（低流量） # 为什么预热：SSR有冷启动（首次渲染缓存为空），预热确保缓存预热后再测峰值 echo "阶段1：预热（50并发，30秒）" wrk -t${THREADS} -c50 -d30s "${TARGET_HOST}/" > /dev/null 2>&1 # 阶段2：阶梯加压（逐步增加到目标QPS） # 为什么阶梯而非直接满载：直接满载可能导致服务雪崩， # 阶梯加压可以观察QPS与延迟的关系曲线，找到最优负载点 echo "阶段2：阶梯加压" for concurrency in 100 200 300 400 500; do echo " 并发${concurrency}..." wrk -t${THREADS} -c${concurrency} -d60s --latency \ "${TARGET_HOST}/" > "result_${concurrency}.txt" # 检查错误率 # 为什么每个阶梯都检查错误率：找到错误率飙升的拐点， # 拐点就是单机的安全QPS上限 ERROR_RATE=$(grep -oP 'Socket errors: connect \d+, read \d+, write \d+, timeout \d+' \ "result_${concurrency}.txt" | grep -oP 'timeout \d+' | grep -oP '\d+') if [ "$ERROR_RATE" -gt 50 ]; then echo " ⚠️ 错误率过高(${ERROR_RATE}超时)，停止加压" break fi done # 阶段3：混合场景压测（SSR + API + 静态资源） # 为什么混合场景而非单一场景：真实用户访问包含多种请求类型， # 单一场景压测的数据不能反映真实负载分布 echo "阶段3：混合场景压测" # 模拟真实用户行为：HTML→API→静态资源（按比例） # 为什么按比例而非等权重：真实访问中静态资源请求占90%， # 等权重压测会让静态资源QPS占比偏低，低估CDN压力 LOCUST_SCRIPT=" from locust import HttpUser, task, between class RealisticUser(HttpUser): wait_time = between(1, 3) @task(1) def visit_page(self): # 模拟真实页面加载：先HTML，再API，再静态资源 self.client.get('/') # SSR渲染HTML self.client.get('/api/products') # API请求 # 静态资源请求（SSR渲染的HTML中引用的资源） self.client.get('/static/app.js') self.client.get('/static/style.css') self.client.get('/static/logo.png') " echo "$LOCUST_SCRIPT" > locustfile.py locust -f locustfile.py --host="${TARGET_HOST}" \ --users=500 --spawn-rate=50 --run-time=5m \ --headless --csv=realistic_stress_test # 阶段4：极限压测（确认最大QPS） # 为什么需要极限压测：阶梯加压找到安全上限， # 极限压测确认真正的崩溃边界——两者的差距是冗余空间 echo "阶段4：极限压测（1000并发）" wrk -t${THREADS} -c1000 -d60s --latency \ "${TARGET_HOST}/" > "result_max.txt" echo "" echo "=== 压测完成 ===" echo "结果汇总：" echo " 阶梯加压结果: result_*.txt" echo " 混合场景结果: realistic_stress_test_*.csv" echo " 极限压测结果: result_max.txt" echo "" echo "关键指标提取：" for f in result_*.txt; do echo " ${f}:" grep 'Requests/sec' "$f" || true grep 'Latency' "$f" | head -1 || true done

压测数据与预估对比自动化

# capacity/stress_test_analyzer.py import json import re from typing import Dict class StressTestAnalyzer: """解析压测结果并与预估对比""" def parse_wrk_result(self, result_file: str) -> Dict: """解析wrk压测结果文件""" with open(result_file) as f: content = f.read() # 提取关键指标 qps_match = re.search(r'Requests/sec:\s+(\d+\.?\d*)', content) latency_match = re.search(r'Latency\s+(\d+\.?\d*)\s*(\w+)', content) p99_match = re.search(r'99%\s+(\d+\.?\d*)\s*(\w+)', content) timeout_match = re.search(r'timeout\s+(\d+)', content) qps = float(qps_match.group(1)) if qps_match else 0 latency_unit = latency_match.group(2) if latency_match else 'ms' latency = float(latency_match.group(1)) if latency_match else 0 # 统一延迟单位到ms if latency_unit == 'us': latency /= 1000 elif latency_unit == 's': latency *= 1000 p99 = float(p99_match.group(1)) if p99_match else 0 p99_unit = p99_match.group(2) if p99_match else 'ms' if p99_unit == 'us': p99 /= 1000 elif p99_unit == 's': p99 *= 1000 timeouts = int(timeout_match.group(1)) if timeout_match else 0 return { 'qps': qps, 'avg_latency_ms': latency, 'p99_latency_ms': p99, 'timeout_count': timeouts, 'error_rate': timeouts / max(1, qps * 300) # 假设5分钟=300秒 } def find_optimal_qps(self, results: Dict[int, Dict]) -> Dict: """从阶梯压测结果中找到最优QPS（延迟<200ms且错误率<1%）""" # 为什么最优QPS的条件是延迟<200ms+错误率<1%： # 延迟>200ms时用户感知明显卡顿，错误率>1%时每100个请求有1个失败—— # 两者都不可接受。最优QPS是两者同时满足的最大值 optimal = 0 optimal_concurrency = 0 for concurrency, result in sorted(results.items()): if result['p99_latency_ms'] < 200 and result['error_rate'] < 0.01: optimal = result['qps'] optimal_concurrency = concurrency return { 'optimal_qps': optimal, 'optimal_concurrency': optimal_concurrency, 'p99_at_optimal': results.get(optimal_concurrency, {}).get('p99_latency_ms', 0), } def compare_with_estimate( self, stress_result: Dict, estimated: Dict ) -> ComparisonReport: """压测结果与预估对比""" deviations = { 'qps': (stress_result['qps'] - estimated['sourceQPS']) / estimated['sourceQPS'], 'latency': (stress_result['p99_latency_ms'] - estimated.get('targetP99Ms', 200)) / 200, } # 判断预估是否可信 # 为什么偏差>30%不可信：30%偏差意味着预估的容量可能有50%的误差， # 50%误差在峰值时可能导致一半的机器不够用 reliable = all(abs(d) < 0.3 for d in deviations.values()) return { 'stress_result': stress_result, 'estimated': estimated, 'deviations': deviations, 'reliable': reliable, 'recommendation': self._generate_recommendation(deviations, reliable) } def _generate_recommendation(self, deviations: Dict, reliable: bool) -> str: if reliable: return "预估与压测偏差<30%，预估模型可信。按预估部署+冗余系数1.5。" else: lines = ["预估与压测偏差>30%，预估模型需要修正："] if deviations['qps'] < -0.3: lines.append(" - 实测QPS远低于预估：压测环境可能有问题，或预估的请求/PV不准确") if deviations['qps'] > 0.3: lines.append(" - 实测QPS远高于预估：预估过于保守，可以减少机器数降低成本") if deviations['latency'] > 0.3: lines.append(" - 实测延迟远高于预估：CPU瓶颈比预期严重，增加机器数") return "\n".join(lines)

容量规划仪表盘

# monitoring/capacity-grafana-dashboard.json # Grafana仪表盘：容量预估与实时指标对比 dashboard: title: "活动容量监控" panels: # 实时QPS vs 预估QPS - title: "实时QPS vs 预估" type: graph targets: - expr: sum(rate(http_requests_total{service="ssr"}[1m])) legend: "实时SSR QPS" - expr: 2500 # 预估值（硬编码或从变量读取） legend: "预估SSR QPS上限" # 为什么同时显示实时和预估：实时曲线超过预估线=容量不足， # 需要紧急扩容。低于预估线=容量充足 # CPU利用率 vs 容量上限 - title: "SSR CPU利用率" type: graph targets: - expr: avg(process_cpu_seconds_total{service="ssr"}) / rate(process_cpu_seconds_total{service="ssr"}[1m]) legend: "平均CPU利用率" alert: condition: value > 0.8 # CPU利用率>80% message: "SSR CPU利用率超过80%，考虑紧急扩容" # 为什么80%告警而非90%：80%时还有10%缓冲可以处理突发， # 90%时任何突发都会导致排队延迟飙升 # 峰值PV进度（活动期间累计PV vs 预估总PV） - title: "PV进度" type: singlestat targets: - expr: sum(http_requests_total{path="/", status="200"}) sparkline: true # 为什么跟踪PV进度而非只看QPS：PV进度反映活动整体流量趋势， # QPS只反映当前瞬时压力。PV进度超过预估=需要扩容 # 延迟分布 - title: "请求延迟分布" type: heatmap targets: - expr: sum(rate(http_request_duration_seconds_bucket{service="ssr"}[1m])) by (le)

边界分析与架构权衡

预估模型的准确性

预估基于6个假设：峰值占比、峰值持续时间、每PV请求数、CDN命中率、CPU时间、冗余系数。每个假设偏差10%，最终容量偏差可达50%。

降低不确定性的方法：

1. 历史数据校准：用上次活动的实际数据校准峰值占比和持续时间假设。
2. 压测实测校准：用压测数据校准单机QPS基线和CPU时间假设。
3. 实时监控校准：活动开始后用前5分钟的实时数据校准剩余时间的预估。

压测环境的保真度

压测环境与生产的差异：

• 数据库数据量不同（压测10万条，生产1000万条）→API延迟偏差
• CDN配置不同（压测可能没有CDN）→回源比例偏差
• 网络拓扑不同（压测局域网，生产跨机房）→网络延迟偏差

保真度最高的压测方案：在生产的灰度环境压测。灰度环境与生产共享数据库、CDN、网络。代价是压测流量可能影响灰度用户——需要告知灰度用户压测时段。

SSR vs CSR的容量差异

SSR每个请求50ms CPU时间，单机QPS约160。CSR每个请求只返回静态HTML（1ms），静态资源走CDN，源站QPS可达5000+。

SSR的容量成本是CSR的30倍。如果活动期间用CSR+CDN策略（静态HTML+客户端渲染），源站容量需求降低到原来的1/30。代价是首屏渲染延迟增加1~2秒（客户端JS执行时间）。

生产策略：活动期间切换到CSR+CDN。活动结束后恢复SSR。这是容量与体验的权衡——活动期间延迟1秒比活动期间服务宕机好100倍。

CDN回源压力

CDN命中率90%意味着10%的请求回源。回源请求包括：

1. CDN缓存未命中的HTML请求（新URL）
2. CDN缓存过期的静态资源（SWR策略下5分钟过期）

活动开始瞬间所有请求都是新的→CDN命中率暂时降到0→全部回源。源站需要承受瞬间100%流量。

解决方案：CDN预热。活动前30分钟用爬虫脚本预热所有活动页面的CDN缓存：

# CDN预热脚本 for page in $(cat activity_pages.txt); do curl -s "https://cdn.example.com/${page}" > /dev/null echo "预热: ${page}" sleep 0.1 # 100ms间隔，避免压垮CDN done

预热后CDN命中率从0直接跳到90%+。源站瞬间流量从预估的10000 QPS降到1000 QPS（只有10%回源）。

自动扩容的触发条件

手动扩容反应慢（10分钟以上）。自动扩容需要明确的触发条件：

• SSR CPU利用率>80%持续3分钟→扩容1台SSR服务器
• API P99延迟>500ms持续2分钟→扩容1台API服务器
• 源站QPS超过预估值的80%→预警（不扩容，观察趋势）

为什么不同服务不同阈值：SSR受CPU瓶颈，CPU利用率是核心指标。API受IO瓶颈，延迟是核心指标。QPS预警是全局指标。

自动扩容上限：最多扩容到预估机器数的2倍。超过2倍意味着预估模型完全失效——此时应该降级（切CSR+CDN）而非继续扩容。

容量不足时的降级策略

容量达到极限时的降级方案（优先级从高到低）：

1. 切CSR+CDN：源站只返回静态HTML，计算负担转移到客户端。立即生效。
2. 关闭非核心API：商品推荐、用户画像等非核心API暂时返回空数据。核心交易API不受影响。
3. 限流排队：前端显示"系统繁忙，请稍后重试"。用户体验差但不宕机。

降级不是异常——是容量规划的一部分。提前设计降级策略，活动前演练一次，确保降级5分钟内生效。

总结

大流量活动前端容量预估是6步推算链+压测验证+实时校准的三层保障：

1. PV→峰值PV：总PV×峰值占比/峰值时间。秒杀峰值占比40%/2分钟，促销30%/5分钟。
2. PV→QPS分解：每PV的源站请求×峰值PV/min/60秒。区分SSR和API的QPS——CPU瓶颈和IO瓶颈不同。
3. QPS→机器数：QPS/单机QPS×冗余系数1.5。单机QPS必须用压测实测值而非理论计算。
4. 压测验证：阶梯加压找最优QPS，极限压测找崩溃边界，混合场景模拟真实负载。
5. CDN预热：活动前30分钟预热所有页面缓存，避免开局100%回源。
6. 自动扩容：CPU>80%或P99>500ms触发扩容，上限为预估的2倍。超过2倍切降级策略。
7. 降级优先级：CSR+CDN→关闭非核心API→限流排队。降级5分钟内生效，活动前演练一次。
8. 实时校准：活动开始后用前5分钟的实时数据修正剩余时间的预估。

预估偏差>30%不可信——需要压测校准或修正假设。压测偏差>30%不可信——需要提升压测保真度（灰度环境压测）。每一层偏差都要求下一层验证，直到预估和实测偏差<15%才算可靠。

资料说明

本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0731 资料来源索引，并在发布前将具体来源贴到对应断言之后。