突发流量翻倍时，带宽预留的核心思路是“按峰值预留，按实际付费”，别按日常均值去买带宽包，否则要么卡死，要么浪费钱。
这事的难点不在“买多少”，在于流量是突然来的，你没办法提前预知它什么时候翻倍，做过线上活动的人都清楚，平时带宽用个三成，一搞投放或者被头部平台带了一波流量，瞬间打满，用户端直接加载不出来，后台报警响成一片，这时候再去控制台点扩容，排队等生效，用户早就跑了。
下面这套思路,是我自己踩过不少坑之后总结出来的，按优先级从高到低排，适合预算有限、又怕突发流量打崩的中小团队参考。
突发流量场景下的带宽预留逻辑
很多人把带宽预留理解成“买一个很大的固定带宽包”，这是最常见的误区，固定带宽包只适合流量非常平稳的业务，比如企业官网、内部系统，对于可能突然翻倍的业务，核心逻辑应该是动态冗余，而不是静态买断。
为什么“买大带宽包”在突发场景下不划算
按固定带宽包的方式预留,假设你平时峰值是200M，预估突发能到400M，于是直接买400M，结果就是：平时这200M是纯浪费，一个月下来多花不少钱，而且如果流量翻倍到500M呢？你还是不够用，固定带宽包的伸缩性是靠“你预先付钱”换来的，对不可预测的突发流量来说，等于每次都押错宝。
行业共识是,突发流量场景下，预留策略应该分两层：底层保底带宽 + 上层弹性冗余，保底带宽覆盖日常峰值，弹性冗余应对突发，后者只在实际产生流量的时候计费，这就引出了下面要聊的计费模型。
按量计费和带宽包的核心区别
| 计费方式 | 适用场景 | 突发流量成本 | 操作成本 |
|---|---|---|---|
| 固定带宽包 | 流量平稳、可预测 | 成本高，容易预估过头 | 低，设置后基本不用管 |
| 按量计费 | 流量波动大、有突发可能 | 用多少付多少，突发了也不心疼 | 中，需要关注账单波动 |
| 按日峰值带宽 | 每天峰值明显的业务 | 取当天峰值计费，适合白天高、晚上低的业务 | 低，按天自动结算 |
如果你是做视频站、直播转播、或者经常被大V引流的工具站，建议直接用按量计费或者按日峰值带宽，这类业务的日访问曲线本来就是锯齿状，用固定包月带宽包属于给自己上刑。
带宽预留的核心：业务分级与流量预测
带宽预留本质是个资源分配题,把有限的预算花在刀刃上，做预留之前，先想清楚你的业务能承受什么程度的降级，静态图片加载慢一点可以忍，接口超时就不能忍；视频卡顿能忍，支付失败就不能忍，按这个逻辑，把业务分成几个优先级，再决定带宽往哪儿倾斜。
先判断你的业务属于哪一类
- 强交互型：接口、交易、实时通讯，带宽要保证，延迟敏感，预留优先级最高消费型：图片、视频、文件下载，带宽消耗大但可以容忍缓冲，适合走CDN分流
- 计算型：API调用、数据回传，流量不大但连接数高，带宽不是瓶颈，连接数和TCP参数才是
那么问题来了,服务器带宽不够用怎么办？很多人第一反应是加带宽，但如果你的瓶颈是连接数或者CPU，加带宽等于白花钱，用命令看一眼实际负载，确认是带宽打满还是其他资源打满，再做决定。
怎么估算突发时的带宽缺口
不用精确到小数,算个量级就够了，以一台出口带宽200M的服务器为例：
- 一个页面平均2MB（图片+脚本+样式），支撑每秒30个并发请求左右就会打满
- 突发流量翻倍相当于同时并发到60个请求/秒，带宽缺口直接翻到400M
- 如果你撑不住这个并发,用户看到的不是慢，是直接超时
这里的重点是,带宽预留不是让你去买400M的固定带宽，而是让你确保在流量翻倍的那一瞬间，后端能把请求扛住，缺口有多大，得靠监控数据说话，不是拍脑袋。
三套实操预留方案
按成本从低到高排,三套方案可以组合使用。
用CDN扛掉大头流量
适合静态资源多的业务,把图片、CSS、JS、视频全扔到CDN上，源站带宽只承担API请求和HTML文档。CDN回源带宽和源站带宽是两个概念，静态资源命中缓存后根本不回源，源站的带宽压力直接降一个量级。
操作路径：控制台 -> CDN -> 域名管理 -> 添加域名 -> 源站填服务器IP -> 缓存配置设成“全部缓存” -> 回源HOST改成你的域名。
这里有个注意点：CDN回源也会占源站带宽，如果CDN节点没缓存住内容，回源流量会瞬间把源站打穿，所以缓存策略要激进一点，缓存时间设长，回源鉴权做好。
按量计费 + 带宽上限保护
这是预算有限用户的核心解法,用按量计费承接突发流量，同时设置一个带宽上限，防止被刷流量导致天价账单。
以酷番云为例,服务器带宽计费模式选“按使用流量”，然后给自己设置一个带宽峰值（比如200M），这里的逻辑是：峰值是上限，实际费用按产生的流量计算，突发流量进来时自动跑到上限，超出上限的部分直接丢包或排队，不会让你破产。
这套设置适合怕被恶意刷流量的场景,如果是正经的突发流量，比如被首页推荐了，那200M跑满之后用户会卡，但不会崩，真崩了是因为后端服务扛不住，跟带宽没关系。
预留实例 + 弹性伸缩组
适合预算稍微宽裕、业务又对稳定性要求高的团队，做法是在云上买一个基础配置的按量付费实例作为“影子服务器”，平时不接流量，突发时通过负载均衡自动调度过去，带宽开销跟方案二一样按实际流量算，但多了一台机器的费用。
这种方案的好处是弹性不止覆盖带宽，还覆盖了计算资源，流量翻倍往往意味着请求量翻倍，光加带宽不加实例，服务器CPU也会先扛不住。
预留之后的持续监控与修正
带宽预留不是一锤子买卖,建议做一次之后，按下面的步骤持续修正：
- 记录每次突发的时间点和峰值带宽，用表格记，连续记三个月，你就能摸清业务有没有周期性规律（比如每周几流量高）
- 给监控设阈值告警，带宽使用率超过70%就通知，别等打满了才知道
- 每次活动前按预估并发调一次带宽上限，活动结束后降回来，别嫌麻烦
- 观察“用户等待时长”，带宽充足不等于体验好，如果带宽没满用户还是卡，问题在应用层不在网络层
带宽超了之后，数据库扛不住怎么办
这是一个经常被忽略的问题,带宽预留解决了用户到服务器的路，但服务器到数据库的路也是路，突发流量打过来，数据库连接数瞬间飙满，表现是接口超时、报错，这时你加带宽也没用。
解决思路是：连接池前置，在应用层限制数据库最大连接数；加一层Redis缓存，把高频查询缓存住；读写分离，把查询分流到从库，主库专心处理写操作，操作顺序别搞反，先上线Redis，再考虑加带宽，顺序反了等于先修路再修车，车还是跑不快。
被攻击导致的带宽打满，该怎么区分
突发访问量翻倍和恶意攻击打满带宽是两回事，真实用户带来的流量翻倍，行为特征是：来源地域分散、UA五花八门、请求间隔自然，攻击的特征是：来源集中在某个IP段、请求头缺失、频率极高，如果你的带宽是深夜突然满的，大概率不是好事。
区分方法很简单,登录服务器看实时连接数：
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20
发现单个IP连接数异常高,直接防火墙封掉，如果是大流量攻击（带宽直接被塞满），上高防IP是唯一出路，这不是预留能解决的问题。
用“按日峰值带宽”压平成本
如果你每天的高峰时段非常固定,比如晚上8点到11点是流量高峰，其他时段很闲，那按日峰值带宽比按量计费更省钱，它的逻辑是：取每天产生的最高带宽值，乘以单价，按天结算，不像按量计费那样按流量总量计费，对峰值稳定、总量大的视频类业务更友好。
但有个坑要注意：如果某天突然被刷流量，峰值被拉得很高，这一天的带宽成本会非常夸张，所以按日峰值带宽需要配合CDN和WAF一起用，别裸奔。
对于那种“白天量很大、晚上接近零”的业务（比如教育类、工作工具类），用按日峰值带宽比买固定带宽包划算得多，这也是为什么很多视频直播团队偏爱这个计费模式的原因。
常见问题
突发流量带崩了服务器，带宽没满是怎么回事？
大概率是后端应用层或数据库的问题,带宽满不满可以用iftop或nload查看，如果网卡吞吐还有剩余，而页面响应慢，说明瓶颈在CPU、数据库连接数或者队列堆积上，此时应优先排查应用日志和数据库慢查询。
带宽预留的预算应该按什么基准做？
按过去30天峰值带宽的5倍到2倍做冗余，如果历史峰值是100M，预留目标就是150M到200M，用按量付费承接超出的部分，少于1.5倍，突发来了扛不住；多于2倍，日常成本浪费太明显，不合算。
视频网站突发流量，带宽预留和缓存命中率哪个优先？
缓存命中率优先,视频文件一旦被CDN缓存，源站带宽几乎零消耗，回源带宽预留得再大，也扛不住每个请求都回源拉流，先把缓存命中率做到90%以上，再谈带宽预留，这是做视频站的基本功。