视频网站需要什么服务器配置？转码、存储与视频分发架构分析

做视频网站的人最容易踩的一个坑，是拿"普通网站服务器"的思路来选配置。普通网站一台 4 核 8G 的机器能扛住几万访问，但视频业务完全是另一回事：一个用户上传的 1080P 素材可能好几个 G，转码时能把 CPU 吃满，播放时又要持续占用带宽。配置选错，不是慢一点的问题，而是转码队列排到第二天、播放卡成 PPT。

这篇文章把视频网站的服务器需求拆开讲。先讲清楚一条视频从上传到播放到底经过了哪些环节，然后重点讲最容易选错的两块——转码和存储，再讲到分发端的带宽与 CDN 规划，最后给一份按业务规模分档的配置建议。文中会给出真实可用的 FFmpeg 命令，涉及数字的地方都会说明是经验值。

读完你应该能判断：自己这套业务到底是转码吃紧还是带宽吃紧，软转码和 GPU 转码该怎么选，存储要用多大，以及从个人站到中型平台各需要什么样的机器。

一、先看清一条视频的完整链路

视频网站的服务器不是一台机器，而是一条流水线。用户上传一个视频，到别人能点开播放，中间至少经过四步：

1. 上传：客户端把源文件传上来。这一步吃的是上行带宽和接收端的磁盘写入。
2. 转码：把源文件（可能是任意格式、任意分辨率、码率很高）统一转换成多种分辨率、多种码率的版本，并切成适合流式播放的分片。
3. 存储：原始文件和转码后的产物都要长期保存。这一步吃的是磁盘容量，而播放时读取又需要高吞吐。
4. 分发：用户点播时，把对应的视频分片快速送到用户手里。这一步吃的是出口带宽，通常靠 CDN 承担。

这四步里，上传和分发是带宽问题，转码是CPU/GPU 问题，存储是容量和吞吐问题。选配置之前先想明白你的瓶颈在哪一步——是每天上传量大、转码排不过来，还是播放量大、带宽费爆炸，优化方向完全不同。

一个小团队常见的分工是：源站只负责上传接收、转码调度和存储回源，真正的播放流量全部压给 CDN。这样源站的压力小了，成本也集中在真正需要的地方。

二、转码：视频业务最吃 CPU 的一环

转码是视频网站里最考验服务器的环节。一个上传的视频，通常要转成 480P、720P、1080P 甚至 4K 好几档，每档还可能有不同的码率档位，供不同网络状况的播放器自适应切换（这就是 HLS/DASH 的自适应码率基础）。

软转码（CPU）和硬转码（GPU）的选择，是最关键的决定。

经验上，一台 16 核 CPU 做 1080P H.264 软转码，大约能跑到 1–3 倍速（即转码耗时是视频时长的 1/3 到 1 倍，用 -preset 控制，越快画质越差），并发路数通常个位数。而一张主流转码显卡可以同时跑十几路甚至更多 1080P 转码。如果你的日上传量在几十个视频以内，CPU 软转码就够了；如果每天要处理成百上千个视频或做直播，GPU 硬转码几乎是必然选择。

一个典型的 FFmpeg 转码命令（把源视频转成 720P 的 H.264，并切成 HLS 分片）：

# 基础安装：RHEL/CentOS/Rocky 用 dnf，Debian/Ubuntu 用 apt
dnf install -y ffmpeg          # 部分发行版需先启用 EPEL 或 RPM Fusion
apt-get update && apt-get install -y ffmpeg   # Debian/Ubuntu

# 软转码：转 720P、限定码率、生成 HLS 分片
ffmpeg -i input.mp4 \
  -vf "scale=-2:720" \
  -c:v libx264 -preset medium -crf 23 -maxrate 2500k -bufsize 5000k \
  -c:a aac -b:a 128k \
  -f hls -hls_time 6 -hls_playlist_type vod \
  -hls_segment_filename "720p_%03d.ts" \
  720p.m3u8

参数说明：-crf 23 是 H.264 常用的画质档，数值越小画质越好体积越大，18–28 是常见区间；-preset medium 在速度和质量之间取平衡，追求快可以用 veryfast；-hls_time 6 表示每个分片 6 秒，这是兼顾延迟和请求数量的经验值。

同样的转码交给 GPU（以常见的 NVENC 为例，需先装好对应驱动和 SDK）：

# GPU 硬转码：-hwaccel cuda 用于解码加速，h264_nvenc 用于编码
ffmpeg -hwaccel cuda -i input.mp4 \
  -vf "scale=-2:720" \
  -c:v h264_nvenc -preset p4 -b:v 2500k -maxrate 2500k -bufsize 5000k \
  -c:a aac -b:a 128k \
  -f hls -hls_time 6 -hls_playlist_type vod \
  720p.m3u8

GPU 转码的参数体系和软转码不完全一样（比如 -preset p1 到 p7 表示速度优先到质量优先），不要直接把软转码的参数照搬过来。

转码调度的经验建议：不要把转码和 Web 服务放在同一台机器上，转码会瞬间吃满 CPU，网页响应会跟着卡。更好的做法是把转码拆成独立的转码机/转码集群，用任务队列（比如 Redis 队列 + 多个 worker）串起来，上传完成后丢一个任务进队列，worker 有空就取。这样即使流量高峰，前台也稳如老狗。

三、存储：容量只是最表面的问题

视频存储的需求和普通文件存储差别很大，主要体现在三点：单文件大、总容量增长快、读取时要求高吞吐。

对象存储 vs 自建磁盘。 对绝大多数视频站来说，视频文件应该放进对象存储，而不是直接挂一块大盘在服务器上。原因是对象存储天然支持海量容量、天然可通过 URL 直读、天然能对接 CDN 回源，还不用自己操心磁盘满了扩容。自建大容量存储适合有明确成本控制诉求或数据合规要求的团队，但要自己处理 RAID、扩容、备份，运维成本不低。

容量估算。 这是很多新手忽略的。假设每个视频转出 480P/720P/1080P 三档，经验上三档加起来的转码产物大约是原始文件大小的 1 到 2 倍（取决于源文件码率和转码档位），再加上原始文件要保留，所以实际占用大约是源文件的 2.5 到 3 倍。如果每天上传 100 个平均 500MB 的视频，光一天的存储就要 100 × 500MB × 3 ≈ 150GB，一个月就是 4.5TB 左右。容量规划要按这个量级留冗余，并提前设计好冷数据归档策略（老视频转到低频存储或归档存储）。

吞吐要求。 如果是自建存储给 CDN 回源，磁盘的吞吐能力很关键。一块普通机械盘顺序读大约 100–200MB/s（经验值），而一块 SSD 或 NVMe 能到几百 MB/s 甚至 GB/s 级。回源并发高的时候，机械盘很容易成为瓶颈，建议回源层用 SSD，冷数据用大容量机械盘或对象存储。用 RAID 提升吞吐和冗余也是常规做法，但要注意 RAID 5 的写入惩罚在高并发写场景下可能反而不如 RAID 10。

四、带宽与 CDN：钱花得最多的地方

视频网站的成本大头通常是带宽。播放一个视频，用户把整个文件的数据都下载了一遍，所以带宽消耗 = 视频码率 × 播放次数（实际还要算上播放时长占比）。

举个估算例子：720P 码率约 2.5Mbps，如果有 1000 人在线同时观看，那么稳定出口带宽需求大约是：

1000 人 × 2.5Mbps = 2500Mbps ≈ 2.5Gbps

再算上峰值波动和冗余，实际带宽要按 1.3 到 2 倍准备，也就是 3–5Gbps。这个数字很直观地说明了为什么视频站必须上 CDN——单靠源站出口带宽根本扛不住，而且成本极高。

CDN 是视频分发的标准答案。 通过 CDN，视频分片被缓存在离用户最近的边缘节点，用户不直接访问源站，源站带宽压力大幅降低。回源则用对象存储或源站，只有 CDN 边缘没有缓存时才会回源一次。选 CDN 时要关注几个点：是否支持视频分片格式（HLS/DASH）、回源是否高效、有没有防盗链能力（比如签名 URL、Referer 白名单、Token 鉴权，防止别人盗刷你的流量）、以及计费方式是按带宽峰值还是按流量。

上传带宽同样要规划。 视频上传占上行带宽，如果开放用户上传，高峰期并发上传几十个几百 MB 的文件，上行很容易打满，导致上传失败。上传端建议做限速和分片上传，并考虑直传对象存储，避免经过源站中转。

五、按规模分档的配置建议

下面这份配置建议是按常见业务规模给的经验参考，实际要结合并发播放数、上传量、是否自己做转码来调整。配置只给量级，不涉及具体厂商型号。

不管哪个规模，都有个共同的建议：Web 服务、转码、存储、分发尽量分层解耦。把它们塞进一台机器，短期省钱，长期一定是运维噩梦——转码一跑满，网站就打不开，用户体验和排查效率都会崩。

常见问题

Q：视频网站的硬盘一定要用 SSD 吗？
系统盘和应用盘用 SSD，是必须的。视频文件本身用普通机械盘或对象存储都可以，但如果是给 CDN 高频回源的存储层，建议用 SSD 或高吞吐的存储方案，否则回源会拖慢首帧加载。

Q：可以直接把原始视频给用户播放，不做转码吗？
技术上可以，但体验很差。原始文件可能码率极高（比如手机拍的 4K 源），用户网络扛不住会一直缓冲，格式也不一定被浏览器支持。转码的意义就在于适配不同的网络和终端，这是视频站的标配。

Q：转码慢，是不是加机器就行？
要看瓶颈。如果是 CPU 吃满，加机器或用 GPU 有效；如果是磁盘读写入队慢，那瓶颈在存储；如果是任务排队但 worker 很闲，说明是队列或调度的问题。盲目加机器可能解决不了根本问题。

Q：CDN 用了但还是卡，可能是什么原因？
常见原因有几种：CDN 边缘没缓存到、频繁回源；分片太小导致请求数过多、连接开销大；或者用户本地网络差。可以先用 CDN 提供的日志看回源率和各节点的命中情况，再定位。

Q：对象存储和自建存储，什么时候选自建？
数据量非常大、且对单位存储成本极度敏感，或者有数据不出机房的合规要求时，可以考虑自建。否则优先对象存储，运维省心、扩容弹性好，综合成本往往更优。

总结

• 视频网站的服务器要按上传、转码、存储、分发四段拆开看，先定位瓶颈在带宽、CPU 还是磁盘，再谈选配置。
• 转码是 CPU/GPU 大户：日上传量小用 CPU 软转码，量大或做直播上 GPU 硬转码；转码务必和 Web 服务解耦，用任务队列调度。
• 存储优先对象存储，容量按源文件的 2.5–3 倍规划，冷数据及时归档，回源层重视吞吐。
• 带宽是成本大头，必须用 CDN 分发，并做好防盗链；带宽按并发观看数乘以码率估算，再留 1.3–2 倍冗余。
• 分层解耦是视频架构的核心原则，前台、转码、存储、分发各司其职，才能扛住增长。