并发上涨时，先加带宽，后加存储。 这个顺序适用于绝大多数点播站场景，因为带宽瓶颈会在几分钟内压垮服务，而存储容量通常有数小时到数天的缓冲期。
为什么带宽是生死线，存储是慢性病
点播站的流量模型不同于下载站,用户点击播放的瞬间，流量就开始消耗，而且是持续性的消耗，一个1080P视频码率按4Mbps计算，50个并发用户就需要200Mbps带宽，如果是4K内容，码率翻倍，同样并发数需要的带宽直接翻倍。
业内专家指出,点播站并发上涨时，最先触顶的资源九成是带宽，而非存储容量。
存储问题通常表现为两类：容量告急和IOPS瓶颈，容量告急是慢性的，你有时间去加盘、迁移冷数据；IOPS瓶颈虽然会直接影响播放启动速度，但它的触发通常滞后于带宽打满。
- 带宽一旦打满：用户立即卡顿、转圈、加载失败，体验断崖式下跌
- 存储接近上限：用户感知不强烈，只是后台报警在响
- IOPS不够时：表现为拖拽播放变慢，但线性播放不受影响
- 存储故障：影响范围小，可以快速切换备用节点
先加存储的代价：带宽依然会堵住你
如果你先扩了存储,把并发用户接进来了，结果带宽瞬间被击穿，所有用户都会卡在缓冲界面，此时用户已经建立了播放连接，实际上同时占用了大量TCP连接资源，服务器要处理这些半死不活的连接，CPU和内存还会跟着遭殃。
一个典型的翻车场景是：业务方看到磁盘使用率达到85%，赶紧扩了存储，调高了并发上限，结果新接入的几十个用户立刻把带宽打到了上限，老用户开始骂娘，新用户也看不了，最后你花了钱，挨了骂，还得回头去加带宽。
并发上涨时先判断哪个指标先到顶
在实际运维中,你不能拍脑袋决定先加哪个，登录服务器，一键查看带宽和存储状态：
- 执行
iftop查看实时带宽占用率 - 执行
df -h查看存储剩余空间 - 执行
iostat -x 1查看磁盘IOPS和await时间 - 用
sar -n DEV 1监控历史流量趋势
判断标准：谁先打满，谁先扩
如果带宽使用率超过85%，磁盘剩余空间高于30%，毫无悬念，直接联系运营商临时升带宽，用云服务器的直接控制台调整带宽上限，分钟级生效。
如果带宽剩余充裕,存储剩余低于20%，且IOPS持续报警，那加存储是正确的。
但实际场景中,更多情况是两者同时报警，这个时候，观察播放成功率这个指标：
- 播放成功率低于95%，先加带宽、做CDN分流
- 播放成功率正常,只是卡在拖拽进度条阶段，那优先处理存储IOPS
点播站带宽和存储哪个贵：账要算清
价格因素也决定了顺序,国内主流云厂商的带宽费用，按固定带宽计费，10Mbps一年成本数千元；按流量计费，1TB流量包数百元，而存储方面，一块16TB的企业级SATA硬盘只要一千多元。
结论是：带宽贵在持续性，存储贵在一次性。 带宽的费用是持续烧钱的，但它是刚需，省不掉的，存储是一次性投入，买完就是你的，但容量规划一定要留出30%以上的余量。
先加带宽的具体操作路径
如果你的服务器是物理机托管,联系机房临时提升带宽上限，通常需要1-2小时生效，如果用的是云服务器，直接在控制台调整带宽或者购买共享流量包。
CDN分流：比加带宽更优先的选择
其实在加带宽之前,还有一个操作比调大带宽上限更有效：打开CDN的缓存命中率优化，点播站90%以上的重复请求都是同一批热门视频，CDN边缘节点命中率只要到80%以上，回源带宽需求骤降。
操作路径：
- 登录CDN控制台,将热门视频的缓存时长从1天调整到7天
- 开启分片缓存,让拖拽请求也能命中边缘节点
- 将低码率转码版本设置为默认下发格式
- 删除冷门视频的缓存预热,把资源留给核心内容
做完这些,再看实时带宽监控，你会发现原本打满的带宽可能降到了70%左右。
带宽加多少够用
按峰值并发的1.5倍去规划带宽，假设你的系统设计能支撑500并发，平均码率3Mbps，峰值瞬间需要的带宽是1500Mbps，加上转码延迟和协议开销，建议按2Gbps起步规划。
如果预算有限,优先保证总带宽能覆盖峰值并发的80%，剩下的用限流策略挡住超载部分，保护已连接用户的体验。
存储扩容的正确姿势
存储扩容不是简单加一块盘的事,点播站的存储要考虑读取性能的均匀分布。
千万别在系统盘上堆视频
把视频文件放在数据盘,用独立的SSD做热数据缓存，机械盘组RAID存冷数据，这个架构在并发上涨时要先检查：
- 热数据盘的剩余空间是否低于20%，若是，把超过30天未访问的文件迁移到冷数据目录
- 冷数据盘的IOPS是否被打满,若是，检查是否有人恶意刷老资源
- 不要让存储水位超过85%，一旦超过，删除速度会急剧下降
存储扩展的两种路径
- 云盘扩容：在控制台直接升级云盘容量，支持在线扩容，不需要重启服务器
- 挂载新盘：购买新磁盘，格式化后用软链接方式将视频目录指到新盘上
路径二有个坑：你要确保旧的视频请求还能被你配置文件里的路径访问到，用symlink解决：
ln -s /data/disk2/videos/old /data/videos/old
点播站并发上涨的核心矛盾：带宽、存储、CPU的三方博弈
并发上涨时,不只带宽和存储有压力，CPU转码、数据库连接数、内存缓存命中率都会出问题，但带宽和存储是最容易被看到、也最容易被误解的两个指标。
行业共识认为,点播站的最佳扩容序列是：CDN分流 → 网络带宽 → 存储IOPS → 存储容量。
- 带宽承接的是用户的实时连接,缺了它一切免谈
- 存储容量最不紧急,因为你可以用删除旧片源来应急
- IOPS决定拖拽体验,介于两者之间
- 如果是HLS协议点播,每5秒一个切片，请求量是线性播放的几十倍，这种场景下IOPS的重要性甚至会超过带宽
一个典型的扩容实操序列
假设你的点播站突然涌进来一批新用户,服务器报警如下：
- 带宽使用率95%
- 磁盘使用率75%
- IOPS使用率60%
执行顺序应当是：
- 立即在CDN控制台开启所有热门视频的全网缓存预热,把动态回源流量压到最低
- 同时联系云厂商临时提升带宽上限到2倍
- 观察IOPS指标,如果磁盘读写等待超过20ms，立即将热数据目录迁移到SSD
- 最后才去规划冷数据的清理和容量扩容
这套流程走完,多数并发冲击都能在30分钟内稳住。
不同点播站类型的扩容侧重
不是所有点播站的扩容顺序都一样,不同类型的站侧重点有区别。
- 动漫点播站（文件体积小、数量大）：IOPS压力大，文件系统inode容易耗尽，存储性能比带宽更敏感
- 电影点播站（文件体积大、码率高）：带宽是第一瓶颈，存储吃的是顺序读，机械盘就够用
- 付费点播平台（用户量小但稳定）：带宽和存储都相对可控，优先关注鉴权服务器的响应能力
- 短视频点播（碎片化请求极多）：CDN命中率决定生死，回源带宽压力最大
这些场景的共性结论是：并发突然上涨时，带宽的弹性最差它不能在几秒内加出来，而存储却可以通过删除冷数据、迁移热数据来临时腾挪，先把带宽压力泄掉，存储问题后面慢慢处理。
Q&A：关于点播站并发上涨扩容的常见疑问
并发上涨时先加带宽还是存储，具体怎么看指标
先用 sar -n DEV 1 看带宽使用率，再用 df -h 看磁盘空间，带宽占用率超过80%且持续上升，立即升带宽，磁盘剩余空间低于25%，先清理日志、临时文件、备份压缩包，再决定是否扩容存储，磁盘IOPS等待时间（await值）超过30ms，优先优化存储架构，而不是加容量。
点播站带宽和存储哪个贵，长期成本怎么控制
带宽是按峰值计费的,一年下来费用远超存储，存储是一次性买断或云盘按容量包月，长期均摊成本远低于带宽，控制成本的核心是提高CDN缓存命中率，把每GB的带宽成本降到最低，而不是在存储材质上省钱。
加带宽后发现存储告警，还能撑多久
取决于视频平均码率和用户平均观看时长,假设你有10TB剩余空间，视频平均码率3Mbps，每GB空间能存放约10小时的视频内容，10TB空间对应的播放时长大约为10万小时，按平均每用户每天观看1小时计算，即使并发全满，存储也可以继续支撑相当一段时间，期间足够完成存储扩容或冷数据迁移。