视频网站服务器

凌晨三点，视频你点开一个视频，网站进度条拖到中间，服务画面秒出。视频这背后不是网站魔法，是服务服务器在干活。视频网站服务器跟普通网站服务器完全是视频两码事——普通网站传个几十KB的HTML就完事了，视频站每秒钟要往外吐几百GB甚至TB级的网站数据流。

先说存储。服务一个中型视频平台，视频冷数据加热数据动辄几十PB。网站什么概念？服务一块4TB的机械硬盘，你得插满两万五千块。视频这些硬盘不可能全塞一台机器里，网站所以分布式存储是服务标配。B站早期用自研的bfs（Bilibili File System），后来转到了erasure coding方案，把文件切成碎片加校验块，分散到不同机架。坏一块盘？没事，校验块能还原。坏一个机架？只要副本策略到位，照样扛得住。

存储解决了，下一个问题是“怎么把数据送到你屏幕上”。这就要提到CDN——内容分发网络。你在北京看一个广州up主上传的视频，数据不可能每次都从广州机房拉。CDN厂商在全国甚至全球布了几百个边缘节点，视频文件提前缓存到离你最近的节点。你点播放，实际是从天津或廊坊的节点拉流。延迟能压到10毫秒以内。

但CDN不是万能的。直播场景下，尤其是游戏直播或带货直播，延迟要求更苛刻。传统HLS协议延迟动辄十几秒，主播喊“三二一上链接”，你这边还没听到。于是有了LL-HLS和WebRTC方案。Twitch用WebRTC做低延迟直播，延迟能压到1秒左右。代价是服务器要维护大量长连接，一台8核16G的机器撑不住几千人同时在线。所以直播服务器通常按房间分片，每个房间独立进程，互不干扰。

转码是另一个吃资源的环节。用户上传一个4K 60帧的H.265视频，你得转出360P、480P、720P、1080P多个版本，还要适配H.264以保证老设备能播。一个10分钟的视频，转码集群跑满CPU也得几分钟。Netflix的做法是提前把视频切成几秒的片段，每个片段单独转码，然后并行处理。这样一部两小时电影，转码时间从几小时压缩到十几分钟。

带宽成本是视频网站最头疼的事。YouTube每月带宽账单据说在千万美元级别。国内某二线视频平台的技术负责人跟我聊过，他们高峰期带宽跑满200Gbps，一个月光带宽费就烧掉几百万。所以视频网站拼命推P2P加速——你看着视频，顺便帮别人传一点数据。快播当年就是靠这招把带宽成本压到极低，可惜走偏了。

最后说故障。视频服务器最怕的不是宕机，是“雪崩”。一个热门视频突然爆火，CDN节点缓存被击穿，回源请求瞬间打满源站带宽。源站挂了，所有节点都回源，整个平台瘫痪。解决方法是多级缓存加限流。边缘节点缓存失效后，先问区域中心节点，区域中心再问源站。同时源站对回源请求做令牌桶限流，超出的直接返回503，宁可让部分用户卡顿，也不能让整个系统崩掉。

你看，每次拖动进度条那零点几秒的流畅，背后是存储、CDN、转码、带宽调度、故障隔离一整套系统在协同。视频网站服务器这行，拼的不是单机性能，是架构设计和对失败场景的预判。

本文地址：http://www.79wt.cn/news/1897f1899792.html