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

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

一、"双十一零点页面打不开了"——不是带宽不够，是没算对

前端容量预估最常见的错误：拿 PV（Page View）去估算服务器承载需求。PV 是日累计量，QPS（Queries Per Second）是瞬时并发。电商秒杀场景下，零点前 10 分钟的 QPS 可能是日均的 50-100 倍。

具体数据：某电商平台日均 PV 500 万，日均 QPS 约 50（500 万 ÷ 86400 秒 ≈ 58）。但零点秒杀启动后的 10 分钟内，QPS 飙升到 5000——是日均的 100 倍。如果按日均 QPS 50 去部署服务器（比如 2 台 Nginx + 3 台 Node.js），零点瞬间全部打满——页面加载超时、接口 502、CDN 缓存穿透到源站、源站崩溃。

更常见的预估错误是忽略了"峰值并发因子"。即使算出了峰时 PV，也不是简单除以 3600 秒得到 QPS。因为流量在高峰时段内也不是均匀分布的——零点整的一秒可能有 1000 个请求，而零点后第 10 分钟只有 200 个。峰值并发因子通常在 3-5 倍之间，即峰值 QPS = 峰时平均 QPS × 3~5。

正确的估算链路：

预期 UV（日活）→ 高峰时段 PV → 峰值 QPS → 单机 QPS → 所需实例数

每一步都有换算系数和经验参数，少了哪一步都会导致预估偏差。

flowchart LR A[预期 UV: 100 万] --> B[PV = UV × 人均 PV] B --> C[时峰值 PV = PV × 峰时占比] C --> D[峰值 QPS = 峰值 PV / 3600] D --> E{压测} E --> F[单实例 QPS] F --> G[实例数 = 峰值 QPS / 单实例 QPS × 1.5] G --> H[加 CDN 缓存层] H --> I[最终部署方案] A --> |人均 5 次| B B --> |20% 在高峰 1 小时| C C --> C_calc[峰值 PV: 100 万 × 5 × 0.2 = 100 万] D --> D_calc[QPS: 100 万 / 3600 ≈ 278] F --> |压测得 200 QPS| F_calc G --> G_calc[实例数: 278/200 × 1.5 ≈ 3]

二、PV → QPS 换算的关键参数

参数一：峰时占比

不是所有 PV 均匀分布在全天。大促活动的 80% 流量高度集中在开抢前后 30 分钟。峰时 PV = 总 PV × 60-80%。日常场景的峰时占比约 20%（午休和晚间高峰），但秒杀场景可能高达 60-80%。

经验值参考：

• 日常电商：峰时占比 15-20%（午休 12-13 点 + 晚间 20-22 点）
• 促销活动：峰时占比 40-60%（活动前后 2 小时）
• 秒杀抢购：峰时占比 60-80%（开抢前后 30 分钟）

参数二：峰值并发因子

即使在高峰小时内，流量也不是均匀的。最峰值（如准点抢购）的 QPS 可能是平均的 3-5 倍。这个因子取决于活动的"瞬间性"——如果用户可以分散在几分钟内下单，因子较低（2-3）；如果必须在零点整下单，因子极高（5-10）。

实际数据：某秒杀活动的零点整秒 QPS 达到 8000，而零点到零点 10 分的平均 QPS 只有 2000——并发因子 = 4。这意味着你需要为峰值 8000 QPS 做准备，而非平均 2000 QPS。

参数三：静态资源 vs 动态接口

页面的 PV 不等于服务器 QPS。静态资源（JS/CSS/图片）走 CDN，对源站没有压力。真正产生 QPS 的是：

• API 接口（商品查询、库存、下单）——这些请求必须到达源站
• SSR 渲染（如果用了 SSR）——每个页面请求都需要 Node.js 计算
• WebSocket 连接（实时推送）——连接数而非 QPS 是瓶颈

一个典型的商品页 PV 产生约 3-5 个 API 请求（商品详情、推荐列表、库存状态）。但 CDN 命中率约 85-90%——静态资源请求不会到达源站。

换算公式

有效 QPS = 峰值 PV × (1 - CDN 命中率) / 3600 × 峰值并发因子

例：100 万峰时 PV，CDN 命中率 85%，峰值并发因子 3。

有效 QPS = 1,000,000 × 0.15 / 3600 × 3 ≈ 125 QPS

加上 50% 安全冗余 → 目标 188 QPS。为什么 50% 冗余？因为压测环境不可能完全模拟生产环境的所有变量——网络抖动、GC 暂停、数据库慢查询、缓存失效等都会让实际 QPS 承载能力低于压测结果。

三、压测方案与实践

// k6 压测脚本：模拟真实用户行为 import http from 'k6/http'; import { check, sleep, group } from 'k6'; import { Trend, Rate, Counter } from 'k6/metrics'; // 自定义指标 const pageLoadTime = new Trend('page_load_time'); const apiLatency = new Trend('api_latency'); const errorRate = new Rate('errors'); const concurrentUsers = new Counter('concurrent_users'); export const options = { // 阶梯加压：模拟流量渐进式增长 stages: [ // 预热阶段——让 CDN 预热缓存 { duration: '2m', target: 50 }, // 流量爬升 { duration: '5m', target: 200 }, // 日常峰值 { duration: '5m', target: 500 }, // 活动峰值——目标 QPS { duration: '5m', target: 1000 }, // 极限测试——1.5 倍峰值 { duration: '3m', target: 1500 }, // 冷却 { duration: '2m', target: 0 }, ], thresholds: { // 硬性指标——不达标就不通过 'page_load_time': ['p(95)<3000'], // P95 页面加载 < 3s 'api_latency': ['p(99)<1000'], // P99 API 延迟 < 1s 'errors': ['rate<0.01'], // 错误率 < 1% 'http_req_duration': ['p(95)<2000'], // P95 请求耗时 < 2s }, }; // 模拟真实用户行为分布 const SCENARIOS = { // 场景权重——大多数用户在浏览，少数在下单 browse_products: 0.45, view_product_detail: 0.30, search_products: 0.15, add_to_cart: 0.07, checkout: 0.03, }; export default function () { const scenario = weightedRandom(SCENARIOS); group(scenario, () => { switch (scenario) { case 'browse_products': browseProducts(); break; case 'view_product_detail': viewProductDetail(); break; case 'search_products': searchProducts(); break; case 'add_to_cart': addToCart(); break; case 'checkout': checkout(); break; } }); // 模拟用户阅读/思考时间 sleep(Math.random() * 5 + 1); } function browseProducts() { const page = Math.floor(Math.random() * 20) + 1; const category = randomCategory(); const start = Date.now(); const res = http.get(`/api/products?category=${category}&page=${page}`, { tags: { name: 'browse' }, }); pageLoadTime.add(Date.now() - start); check(res, { 'browse returns 200': (r) => r.status === 200, 'browse has products': (r) => r.json('data.products.length') > 0, }) || errorRate.add(1); } function checkout() { // 下单流程：检查库存 → 创建订单 → 确认支付 const productId = randomProductId(); // API 1: 检查库存 let res = http.get(`/api/inventory/${productId}`, { tags: { name: 'checkout_inventory' }, }); check(res, { 'inventory ok': (r) => r.status === 200 }) || errorRate.add(1); apiLatency.add(res.timings.duration); // API 2: 创建订单 const payload = JSON.stringify({ productId: productId, quantity: 1, couponCode: '', }); res = http.post('/api/orders', payload, { headers: { 'Content-Type': 'application/json' }, tags: { name: 'checkout_create_order' }, }); check(res, { 'order created': (r) => r.status === 201 }) || errorRate.add(1); apiLatency.add(res.timings.duration); } // 辅助函数 function weightedRandom(weights) { const entries = Object.entries(weights); const total = entries.reduce((sum, [, w]) => sum + w, 0); let r = Math.random() * total; for (const [key, weight] of entries) { r -= weight; if (r <= 0) return key; } return entries[0][0]; } function randomCategory() { const categories = ['electronics', 'fashion', 'home', 'beauty', 'sports']; return categories[Math.floor(Math.random() * categories.length)]; } function randomProductId() { return `prod_${Math.floor(Math.random() * 10000) + 1}`; } // 压测总结报告 export function handleSummary(data) { const metrics = data.metrics; const summary = { timestamp: new Date().toISOString(), results: { total_requests: metrics.http_reqs?.values?.count || 0, p95_page_load_ms: metrics.page_load_time?.values?.['p(95)']?.toFixed(1) || 'N/A', p99_api_latency_ms: metrics.api_latency?.values?.['p(99)']?.toFixed(1) || 'N/A', error_rate: ((metrics.errors?.values?.rate || 0) * 100).toFixed(2) + '%', max_vus: metrics.vus_max?.values?.value || 0, }, thresholds_passed: !data.metadata?.thresholds_breached, }; return { 'stdout': JSON.stringify(summary, null, 2), 'load-test-summary.json': JSON.stringify(summary), }; }

压测脚本的设计原则

场景权重必须反映真实用户行为。浏览占比最高（45%），下单占比最低（3%）——这和实际电商数据一致。如果权重设置不对（比如下单占比 30%），压测结果会严重偏高——因为下单接口的 QPS 承载能力远低于浏览接口。

阶梯加压而非瞬间满载。从 50 VU 逐步加到 1500 VU——这给系统一个渐进加热的过程（CDN 缓存填充、连接池预热、JIT 编译）。如果瞬间打到 1500 VU，前几秒的延迟数据会偏高（因为系统还没预热），不能代表真实性能。

四、前端特有的压测注意事项

CDN 的坑

压测时要先预热 CDN——否则压测流量全部穿透到源站，结果完全不准。预热方法：先用小流量（100 QPS）跑 5 分钟，让 CDN 节点填充缓存。预热后再逐步加压，观察 CDN 命中率是否达到预期（85-90%）。

CDN 的另一个坑：压测脚本的请求 URL 如果带随机参数（如?timestamp=xxx），CDN 会把每个请求当作不同的资源——缓存命中率降到 0%。压测脚本应该使用固定的 URL 路径，而非随机化查询参数。

SSR 的雪崩效应

如果 SSR 页面压测时挂了，重启后流量再次涌入（因为 CDN 缓存被清空了）→ 再次挂。这是典型的雪崩。SSR 前端必须在压测时设置合理的 maxOldSpaceSize 并观察 GC 频率。如果 GC 频率 > 10 次/秒，说明内存压力已经到极限——需要减少 SSR 渲染的复杂度或增加实例数。

SSR 防雪崩的策略：SSR 页面设置短 TTL（如 5 秒），CDN 缓存过期后如果源站不可用，返回 stale 缓存而非重新请求源站。这叫 stale-while-revalidate——给源站一个恢复窗口。

连接数 vs QPS

前端服务（Nginx/Node.js）的瓶颈往往是连接数而不是 QPS。SSR + keep-alive + 长连接会导致单个进程的连接数超限。合理设置worker_connections和keepalive_timeout。

Nginx 的worker_connections默认值 1024——在高并发场景下远远不够。每个 worker 能同时处理的连接数上限就是这个值。如果 SSR 服务有 4 个 worker × 1024 connections = 4096 个最大并发连接。如果峰值并发连接需求是 8000，需要增加 worker 数量或 worker_connections。

Trade-off 讨论

• 压测环境 vs 生产环境：压测环境不可能完全模拟生产环境的所有变量。数据库数据量、缓存命中率、网络拓扑——这些在压测环境中都不同。压测结果应该打 30-50% 的折扣——压测 200 QPS 的实例，生产环境可能只能扛 130-140 QPS。
• CDN 命中率假设 vs 实际：预估中假设 CDN 命中率 85%，但实际可能只有 70%（某些 API 请求不可缓存）。命中率差异直接影响源站 QPS——85% 命中率下源站只扛 15% 流量，70% 命中率下源站扛 30% 流量——翻倍。
• 安全冗余 vs 成本：50% 冗余确保安全但多部署一半实例。30% 冗余省钱但更接近极限。推荐：核心业务（支付/下单）50% 冗余，边缘业务（营销页面）30% 冗余。

五、总结

前端容量预估的精髓不是计算公式，是理解PV 到 QPS 转换中每一步的衰减系数。峰时占比、CDN 命中率、峰值并发因子——这三个参数决定了最终结果。误差最大的是峰值并发因子——它取决于活动的"瞬间性"，经验值范围 2-10 倍，选错了就差了一个数量级。压测不是"丢一堆请求看看能扛多少"，而是模拟真实用户行为分布（浏览/搜索/下单的比例），并以阶梯式加压找到系统的拐点。最终部署方案需要加上安全冗余——因为压测环境和生产环境的差异意味着压测结果永远偏高。