点播站并发上涨时，先加存储再谈带宽，因为存储瓶颈会导致数据丢失和回源风暴，而带宽不足只是播放卡顿，两者优先级在多数场景下存储更致命。
先从一次真实故障说起：为什么我挨了老板的骂
去年夏天，我们运营的点播站突然涌进一批新用户，并发数从平时的几百冲到两千多，我第一反应是带宽不够了，赶紧联系机房临时扩了20G带宽，结果呢？带宽上去了，服务器磁盘IO直接打满，视频文件读取超时，用户看到的不是转圈，而是直接报错，更惨的是，回源请求暴增，源站被拖垮,整整宕机三个小时。
后来我们复盘，发现一个核心逻辑：带宽是租来的，存储是自己的，带宽不够，最多是用户多等几秒；存储跟不上，是数据直接读不出来，甚至写不进去，那场事故之后,我彻底改变了扩容策略。
判断瓶颈：先看这六项指标，别凭感觉拍脑袋
上图这种经验不是让你每次都靠猜，结合业内专家的分析，判断先加哪个，要看具体数据，打开你的监控面板,按下面顺序检查。
第一步，看磁盘队列长度和IO等待时间
- 用
iostat -x 1连续观察，如果%util长期超过80%，或者svctm大于await的一半,说明磁盘已经累趴了。 - 这时候存储是明确瓶颈，加带宽毫无意义，数据读不出来,带宽再宽也是空车道。
第二步，看回源比例和缓存命中率
- 在CDN控制台或Nginx日志里，统计
2xx和3xx回源请求，如果回源率高于30%，说明边缘节点存不住东西,根源在存储策略。 - 很多人误以为这是带宽问题，其实是你缓存层没做好,存储压力直接传导给源站。
第三步，对比带宽利用率和丢包率
- 用
iftop或机房提供的流量图，看带宽是否持续打满，如果带宽利用率超过90%且丢包率上升,才是真正的带宽瓶颈。 - 注意，这里丢包率要区分是TCP重传还是UDP丢包，视频点播通常是TCP，重传率高也可能是因为服务器响应慢,而不是链路拥堵。
第四步，看同时在线用户数和平均码率
- 算一下：带宽需求 ≈ 并发用户数 × 平均码率，如果你的视频平均码率是2Mbps,1000并发就需要约2Gbps带宽。
- 如果在线人数并不多，但带宽已经爆了，检查是不是有异常抓取或防盗链失效,这类问题加带宽是浪费钱。
第五步，看磁盘空间和inode使用率
df -h和df -i必须同时看，很多点播站文件都是几KB到几MB的小文件，inode耗尽比空间耗尽更隐蔽、更致命。- 当inode使用率达到90%以上，文件系统会报"No space left"，但实际硬盘还有空余，这时候你加再多带宽,用户照样看不了。
第六步，看视频转码和切片是否在存储节点进行
- 如果你的转码服务跑在存储节点上，并发上涨时CPU和磁盘会互相抢资源，这种情况，应该优先拆分存储与转码，而不是纠结加带宽。
先加存储的五个实用场景：什么时候存储是绝对老大
以高清和4K为主
存储成本在点播站总成本里通常占40%-60%，一部4K电影原盘动辄50GB以上，转码后也有10-20GB，用户点播时，如果存储用的是机械盘，寻道时间比传输时间还长，这时候加大存储、换SSD或NVMe盘，体验提升立竿见影，带宽加再多,机械盘的随机读速度也上不去。
大量长尾冷门内容占空间
热播剧就那几十部，但点播站往往有几万部老片、课程、纪录片。访问频率低，但必须长期在线，这类数据适合放在大容量冷存储层，但冷存储意味着读取速度慢，如果并发上来时用户恰好点播了冷门片，存储层扛不住，回源反复拉取,带宽再多也堵不住。
你的系统没有做多层缓存架构
现在正规点播站应该是：CDN边缘节点 → 内存缓存 → 本地SSD热数据层 → 大容量机械盘冷数据层 → 对象存储或HDFS，如果你直接让所有请求打到源站磁盘，那么存储就是唯一的瓶颈，这时候你要做的不是加带宽，而是加一层缓存服务器,或者提升热数据层的随机读能力。
防盗链和鉴权逻辑放在存储层
我见过不少点播站把token校验、防盗链逻辑写在文件读取的中间件里，当并发上涨时，这些逻辑会大量占用CPU和内存，导致存储进程响应变慢，此时加带宽只会让更多请求涌进这个半瘫的存储服务，适得其反。正确做法是先优化鉴权流程，再评估是否需要增加存储节点。
你在用NAS或SMB协议做共享存储
很多中小点播站图省事，用NAS挂载目录直接对外提供文件服务，这类方案在低并发时没问题，并发一旦过千，NAS的协议开销和锁竞争会让IO彻底锁死，这时候加带宽是拿消防栓浇厨房的火,不如先把存储架构改成SSD本地盘加同步复制。
先加带宽的三种例外：别把顺序反过来用
源站存储充裕，但出口线路被占满
比如你用的是电信单线，用户大多是联通和移动，跨网延迟和丢包严重，即便你的磁盘读得飞快，用户该卡还是卡。这种情况加带宽、加BGP线路、上CDN都是对路子的。
你是纯分发平台，不存源文件
有些点播站本身是个聚合站，视频文件都在第三方对象存储里，你的服务器只做转发，这时你的瓶颈纯粹在出口带宽和连接数上，存储方面的压力很小。加带宽或加节点是直接有效的。
突然遭遇恶意刷流量
半夜三点带宽被打满，但你看到磁盘IO只有5%，这种基本不是正常业务增长，而是攻击或盗链。
先加带宽应急，同时封IP、换鉴权，回头再考虑要不要加固存储。
扩容实操清单：先存储后带宽的具体步骤
如果你确认要先加存储,按这个顺序操作：
- 用
lsof | grep deleted找出被删除但仍占磁盘的文件，重启对应进程释放空间 - 将热数据迁移到SSD，
rsync或migrate到新挂载点，保留原路径软链接 - 调整文件系统参数，比如
mount -o noatime,nodiratime减少写请求 - 如果用了Nginx做文件服务，调大
open_file_cache、sendfile的相关参数 - 对点播文件做预读取策略，比如用
fadvise或readahead提前把热门文件的前几MB加载到内存 - 如果单机存储真的不够，加一台存储节点，用
lsyncd或unison做实时同步，然后用DNS轮询或LVS做分发
需要加带宽时，不要直接找机房拉一根万兆光纤,先做：
- 压缩视频流，H.264转H.265，码率降低30%-50%画质差异不大
- 检查源站响应头，确认
Accept-Ranges: bytes和Content-Length正确，让拖拽播放不回源整个文件 - 在Nginx层开启
gzip，对字幕、列表页等文本内容压缩 - 上CDN，把流量分散到边缘节点，而不是死磕一条主线
预算有限的中小站长，优先级怎么取舍
据统计，中小型点播站的月带宽费用通常在几千到几万元，而一块企业级硬盘只要几百到一千多。花同样的钱，升级存储的收益往往比扩容带宽更持久，带宽是按峰值计费的，你为了偶尔一次高峰买断大量带宽，平时就是在浪费钱，存储是一次性买断,能用好几年。
行业共识是：先解决能不能存，再解决能不能传，带宽不够最坏的结果是用户骂两句，存储不够最坏的结果是文件损坏、索引丢失，你的整个内容库都要重建，哪个更可怕,不用我说。
长期演进：别把顺序当成万能公式
只看开头结论，你会走入另一极端，点播站发展到一定规模，存储和带宽的瓶颈会交替出现,正确思路是分层部署：
- L1网关层：专门处理连接数、限速、防盗链，这里加带宽或者换更高效的反代
- L2缓存层：Redis或内存盘保存热门视频片段，这里是典型的存储问题，但不是扩容磁盘，而是加内存
- L3存储层：SSD做热数据，机械盘做冷数据，这里扩容要按文件访问频率调整分层比例
- L4回源层：对象存储或自建HDFS，这里考虑的是存储容错和吞吐，不能只看单机IO
如果你的并发在持续健康增长，每个月涨10%-20%，那么每个季度评估一次存储容量，每半年评估一次带宽需求。存储规划要提前三个月，带宽规划可以提前一周
，因为存储扩容需要迁移数据、做校验、改挂载，这些操作几乎不可能在线完成，而带宽调整直接和运营商下单,快的一天搞定。
如果你的点播站后端用了对象存储
很多云点播方案直接买云厂商的对象存储加CDN，这种情况下，存储扩容是云厂商的事情，你真正要操心的是CDN回源带宽和请求数，但注意，对象存储的请求数QPS也是有限制的，超出会返回503，并发上涨时，你应该优先在CDN节点上缓存更多内容，降低回源频率,而不是单纯加大CDN或对象存储带宽。
还有两类用户，你们的答案不一样
一种是你有大量UGC内容，用户上传为主，这种并发瓶颈通常在写入端，要先加存储和队列，带宽是次要的，上传带宽占用可能很大，但上传是异步的，可以限速排队；而下载观看卡顿会直接影响留存。
另一种是你做直播转点播回放，拉流和转码在同一套服务器。这时候带宽和存储必须同时扩，因为转码要吃CPU，输出要吃带宽，写文件要吃存储，三者在同一台机器上互相抢，你得先拆服务,再谈扩容。
点播站并发上涨时先加带宽还是先加存储最怕什么
最怕你只盯一个指标，我见过有人磁盘满了还在加带宽，也见过带宽严重超卖还拼命挂盘。好的做法是给两个维度都设阈值，任何阈值触发都告警，然后根据上面的场景矩阵去决策，没有一定之规，但大部分情况下，存储是地基，带宽是路，地基塌了,路修得再宽也没车敢跑。
常见疑问解答：你可能还在纠结的细节
点播站并发上涨时，内存算存储吗
内存属于缓存层，不算持久化存储，如果内存不足导致频繁swap，那是存储问题；如果是内存足够但磁盘慢，那是传统存储问题，先加内存往往比加硬盘见效更快，因为点播站的热点集中度非常高，头部10%的内容可能贡献90%的播放量，把这部分内容放进内存盘,存储和带宽压力都同时下降。
点播站并发上涨时，CDN能够替代存储扩容吗
不能，CDN本质是分发，不是存储，CDN缓存的只是副本，源站必须有完整的存储能力，如果你源站磁盘IO已经饱和，CDN回源拉取时会把故障放大给更多边缘节点，而且CDN是按流量计费的，源站越慢，回源次数越多，CDN账单越高，该扩存储时别犹豫,CDN不是免死金牌。
点播站并发上涨时，直接换更大带宽的服务器可行吗
可行，但成本效率极低，带宽是跟随服务器绑定的，换大带宽服务器等于把所有配置都提升了一遍，包括CPU、内存、磁盘，其中大部分可能是冗余，更聪明的做法是保持服务器配置不变，单独升级存储或挂载独立存储节点，如果机房不支持单独加带宽，那说明你该换服务商了,不要为用不到的计算资源买单。