峰值通常不出现在流量最大的时刻，而是出现在整点秒杀后的第一波数据回传，真正烧钱的是峰值持续时长，不是瞬时高数值。
很多团队做过促销活动,活动结束后，云厂商账单上的带宽费用往往超出预期，复盘时盯着流量曲线看半天，总觉得哪里不对劲，明明在线人数没有翻倍，为什么带宽成本涨了这么多，问题就出在带宽峰值的特性上，它和访问量不是同一条曲线。
带宽峰值买多少才算不浪费
预算有限的情况下,带宽峰值买多少是运营和运维天天吵架的话题，买小了，活动当天卡成幻灯片；买大了，平时跑不满，钱白花，想搞清楚这个问题，先得把概念掰开。
先分清两种峰值：流量峰值和带宽峰值
流量峰值看的是每秒请求数（QPS），带宽峰值看的是每秒传输的字节数（Mbps），两者偶尔同步，更多时候各走各的，静态页面多的站点，就算QPS很高，带宽也可能只是温和爬升，反过来，页面里塞满高清图和视频，几十个人同时访问就能把带宽顶到上限。
促销场景下,这两者的差距会被放大，用户点开活动页，大量静态资源瞬间加载；用户提交订单，动态请求带着商品数据、库存状态、优惠信息回传，静态资源走CDN，动态请求走源站，带宽峰值往往由动态请求中的大响应体触发，比如带用户优惠券列表的接口，返回几百KB的JSON，比平时大好几倍。
实测场景：大促当天带宽曲线长什么样
以一次实际的秒杀活动为例,凌晨零点开始，流量在23:59开始爬坡，零点整点达到请求高峰，但带宽峰值的出现时间，往往比请求高峰晚15到30秒，原因是用户点击秒杀按钮后，前端要等后端返回结果，紧接着又有一批查询订单状态、优惠券计算、支付页跳转的请求，这些后续请求才是带宽的大头。
活动结束后别急着关监控,让曲线再跑分钟级视图，多数情况下，真正的带宽峰值出现在活动结束后的几分钟内，大量用户同时刷新页面查看是否中奖，或者晒单分享，这个现象在多次促销复盘里反复出现，已经成为行业共识认为的常见误解。
|
指标 |
请求高峰 | 带宽高峰 |
|---|---|---|
| 出现时间 | 整点或活动开始瞬间 | 高峰后15-30秒，或活动结束后 |
| 触发因素 | 用户点击、按钮提交 | 数据回传、页面刷新、资源加载 |
| 成本影响 | 消耗计算资源 | 直接决定带宽账单 |
促销流量复盘里带宽峰值的关键发现
复盘不是拉出账单看一眼就完事,得把带宽曲线和业务事件对齐，这样才能搞清楚每一笔钱花在哪个环节。
峰值出现时间与用户行为强相关
把压测计划里的虚拟用户换成真实用户,行为模式完全不同，压测时并发数平稳上升，真实促销是脉冲式的，用户不会均匀地访问，他们会在某个时间点突然一起动手，复盘时把带宽曲线和运营节奏叠在一起看，会发现几个规律。
第一波峰值是预热页开放时,第二波是正式开售瞬间，第三波是活动结束后的结果查询，这三波里，第二波和第三波的峰值高度接近，但持续时间差异明显，开售瞬间的峰值往往只有几十秒，结果查询能持续好几分钟。
静态资源与动态请求的占比突变
平时静态资源占比高,CDN分流了大部分压力，促销时动态请求会突然增多，因为秒杀、领券、下单这些操作都要实时校验，动态请求的响应体比平时更膨胀，因为要携带更多状态信息，结果就是源站带宽被快速拉高，CDN的命中率反而下降。
这里藏着带宽成本的大头,运营准备的促销素材、优惠券图片、商品详情页，会提前推送到CDN边缘节点，但用户的购物车状态、订单信息、个人优惠计算没法缓存，只能回源，回源带宽的价格通常比CDN带宽贵不少，复盘时看清回源比例，才知道钱主要花在哪。
回源带宽才是隐藏成本
很多团队只盯着入口带宽,忽略了回源带宽，促销页面的HTML可以缓存，但接口数据不能缓存，用户每次刷新购物车，源站就要响应一次，一旦并发上来，回源带宽瞬间飙高，云厂商的带宽计费里，回源流量往往另算。
排查回源问题有个笨办法：看CDN的日志，统计回源请求的URL和字节数，多数情况下，高回源的接口集中在几个核心业务模块上，找到它们，要么做接口的本地缓存，要么用Redis分担压力，能压掉多少回源，就能省下多少带宽费用。
带宽峰值定价与突发流量如何平衡
云厂商的带宽定价通常分两种：按固定带宽购买和按实际用量计费，固定带宽便宜但怕突发，按量计费灵活但单价高，促销场景下，大多数团队会临时提升固定带宽，活动结束后再降回去，这中间有个操作死角。
按固定带宽还是按95计费
业内常见的计费模式是95计费,去掉峰值最高的5%时间点，按剩下的最高值收费，这个模式对日常稳定业务友好，但对促销活动不友好，因为促销产生的突发流量会让95计费的标准变高，完了整个月的带宽成本都按这个被抬高的基准算，相比之下，临时升固定带宽的方案，只花一天的高价，活动结束就恢复，总成本往往更低。
实操建议：大促前一周，先看历史促销的带宽曲线，预估一个保守峰值，然后按这个值把固定带宽升高，活动当天实时盯监控，如果接近上限再临时提一次，别一上来就拉满配置，那是浪费钱。
CDN和对象存储怎么配合
把图片、视频、CSS、JS这些静态资源全部放到对象存储，然后用CDN加速，对象存储的流量费用比云服务器带宽便宜得多，更重要的是，CDN能扛住瞬时冲击，回源压力小。
具体操作路径：内容上传到对象存储，开启CDN加速，源站指向对象存储的域名，注意缓存规则，给不同的文件类型设置不同的过期时间，图片可以缓存一个月，带版本号的JS和CSS可以缓存一年，促销页面的HTML推荐动态生成，用CDN的缓存忽略规则，强制回源。
实操：用流量回放和监控工具定位峰值
复盘不能只看抽象曲线,要能回放当时的请求细节，有几个具体的工具和命令可以实现。
工具清单和操作步骤
- 简米云日志服务或酷番云CLS：把CDN和负载均衡的访问日志接入日志服务，按域名和URL聚合统计带宽，重点看TOP20的URL和它们的流量占比。
- Grafana + Prometheus
：监控源站的带宽和CPU，带出节点级别的明细，大促期间设置5分钟粒度的告警，峰值超阈值时自动截图留证。
- tcpdump抓包：在源站服务器上抓包，分析SYN包数量可以判断是否遭受攻击，分析数据包大小可以找到哪些响应体最大，命令示例：
tcpdump -i eth0 -w /tmp/peak.pcap port 80，然后配合Wireshark打开看。
操作路径：先用日志服务排查回源比例，再用Grafana定位峰值时间点，最后用tcpdump抓包分析响应体大小，三步走下来，基本能锁定最大的成本来源。
一个经常犯的错误是只关注峰值高度,忽略峰值持续时长，带宽计费按时间段累加，就算峰值只有1Gbps但持续了10分钟，比5Gbps但持续10秒的费用高得多，复盘时，对峰值持续时间做分段统计，看哪些时间段最长。
Q&A：促销流量复盘与带宽峰值常见问题
问题1：为什么促销结束后还有带宽峰值？
用户行为不是在活动结束瞬间归零,很多人习惯活动结束后再去页面逛逛，看看有没有漏掉的优惠，还有一些是预约了活动提醒，晚些时候才点进来，这类流量虽然比不上峰值时刻，但持续得久，算法上，带宽计费会累计时长，所以活动结束后的一小时也要纳入成本核算。
问题2：带宽峰值买多少合适？
没有固定的标准答案,但有评估方法，把过去三次促销的带宽曲线调出来，看最高5分钟的平均值和持续时间，新活动如果运营力度差不多，按历史值的80%起步，如果加了新的互动玩法，比如抽奖或拼团，建议先按历史值的1.2倍预购，活动开始后根据实时监控调整。
问题3：流量回放工具能用来做什么？
流量回放不是让真实用户重跑一遍,而是把当时的请求日志按时间戳重新发送到测试环境，这样可以验证代码改动是否影响性能，也可以测试新的限流策略，具体做法是把日志里的URL和请求体提取出来，用GoReplay或tcpcopy等工具回放，回放前记得把目标环境切到独立测试区，避免影响线上，回放结果能清晰展示带宽消耗集中在哪些接口，为下一次扩容提供依据。