如果你希望在香港机房部署一套视频点播平台，面向中国大陆、东南亚市场用户。主要的目标：“上线首月并发请求冲上 50 K+”。我带着团队从零选型、采购、部署、调优、故障排查直到稳定上线。

一、硬件选型（CPU、内存、硬盘）

在香港机房部署，虽然我们多数是租用裸金属服务器（Dedicated），但硬件规格的选型仍然至关重要。基于我们预估并发用户量、缓存、转码、IO 压力、存储量，最终选型如下（实际机型可按预算、机房型号略有差异）。

1.1 需求评估

在项目初期，我和团队一起做了预估表格：

从上面的估算可见，硬件选型必需往「高并发、高IO、高带宽」方向倾斜。

1.2 服务器规格建议

基于上述估算，并结合香港服务器硬件选型参考（如文章提到：高并发环境下，多核 CPU＋高频主频＋大缓存是关键），我们选定如下配置（以单台服务器为例，然后可能做集群）：

选型参考机型：

• Lenovo ThinkSystem SR650 V3
• 双 5th Gen Intel Xeon Scalable 处理器：每颗最多28–32核，主频约2.5–3.2GHz
• 内存支持最多 32 条 TruDDR5 5600 MHz（可达 2 TB 级别）
• 存储方面支持最高 36 个 NVMe 驱动器／40 SAS 驱动器

基于该机型，我建议部署规格如下（参考）：

• CPU: 双 Xeon 5th Gen, 共 32 核 × 2 = 64 核（或依据预算可选 48 核）
• 内存: 初期 512 GB (可扩展至 1 TB)
• 主存储: NVMe RAID10 (前期热视频缓存) 2 × 8 TB NVMe
• 冷存存储: SAS HDD 2 × 24 TB RAID6，用于存放海量视频库
• 网络: 每台服务器内置 2× 100 Gbps NIC（10 GbE 是起步，但考虑到 250Gbps出带需求，100Gbps可聚合）
• 机箱冗余电源、冷却系统、监控板卡必须配齐

1.3 为什么这样选？

• CPU：高并发环境下，每个请求可能涉及用户认证、视频地址查询、CDN接入、缓存判断、分段请求统计等逻辑。 多核＋高主频可同时处理大量线程，减少任务排队。
• 内存：大量并发访问意味着缓存压力大（文件元数据、索引、热视频片段缓存等）。内存太少的话，频繁到磁盘读写，IO瓶颈提前出现。
• 存储：热数据（近期热门视频）建议用 NVMe，以极低延迟响应；冷库则用大容量 SAS/HDD 以节省成本。
• 网络接口：考虑到我们出带量巨大（250Gbps级别），单个10Gbps接口不够，必须考虑100Gbps或聚合多个10/25Gbps口。
• 机房地理：选在香港数据中心，有利于面向中国、东南亚用户低延迟访问。香港机房在带宽、网络路由、跨境延迟方面有优势。

二、网络带宽选型

网络带宽对视频点播平台几乎是第一关键，因为即使服务器硬件再好、但网络带宽不够、或者带宽共享、网络尾瓶严重，用户体验也会崩盘。

2.1 出带需求与预留

• 从前面并发50k × 5 Mbps = 250 Gbps出带需求出发，我们还加上以下预留：
• 预估峰值并发 +20%：60,000 并发 → 300 Gbps
• 留出20%余量给突发流量／营销活动 → 360 Gbps
• 冗余链路考虑双路 BGP + 不同上游以防断链

2.2 香港机房线路注意事项

在香港租服务器，我们注意以下几点：

• 专用带宽 vs 共享带宽：共享带宽在高峰常被“抢占”，建议选用专用带宽／保证 SLA 型。
• 出口国际带宽：针对面向大陆 + 亚太用户非常重要，选择机房需查看其国际出口线、对大陆联通／电信的直连或 CN2 线路。
• 低延迟、少 跳数：香港到中国大陆、东南亚平均延迟较低，是优势。
• 冗余和抗 DDoS 保护：视频平台很容易遭流量攻击，线路需有 DDoS 防护能力。
• 出带单位／计费：如果按流量计费，视频点播流量巨大，建议选择“固定带宽 + 不限流量”方案。

2.3 网络架构建议

在实际部署，我们采用如下架构：

• 双 100Gbps 电路，上游接两个不同运营商（如 HKBN、PCCW）。
• 在机柜内部署 LACP 绑定 2 × 100Gbps 到服务器园区交换机。
• 再由园区交换机到服务器做 10/25/100Gbps 分层连接。热缓存服务器使用 25 Gbps 接口，冷库服务器使用 10/25Gbps。
• 在平台入口部署 NGINX (或 HAProxy) + TLS 卸载 GW，并做负载均衡 + Rate‑Limit 保护。
• 我们还预留了边缘 CDN 节点（若业务增长）做分发减压。

2.4 带宽监控与告警

• 使用 Prometheus/Grafana 监控出口带宽使用率、丢包率、延迟。
• 设置告警：当带宽使用率 > 70% 且丢包率 > 0.5% 时自动触发扩容流程。
• 日志保存周期至少 90 天，以便回溯流量异常。

三、部署教程（我从现场写给你的 “故事化” 过程）

下面以“从零开始在香港数据中心部署”的视角，用第一人称叙述。

3.1 采购 &交付

当时我们在香港某 IDC （拥有香港机房）签约了 5 台 裸金属服务器，规格参照上一节（64 核、512GB 内存、2×8TB NVMe＋2×24TB HDD、2×100Gbps 网口）。机房交付后，我第一时间进行了验收：检查硬盘健康状态（SMART）、内存自检、网卡 SR‑IOV 是否支持、机柜供电和空调温度。
验收过程中发现：有一台机箱左侧风扇运转有异响，我立即提交维修工单，机房在两小时内更换了风扇并复验，避免产生噪音影响冷却效率。

3.2 基础软件安装

操作系统：Ubuntu 22.04 LTS（考虑到社区支持及稳定性）

我在每台服务器上执行如下脚本（部分简化版）：

# 更新系统
sudo apt update && sudo apt upgrade -y
# 安装必备包
sudo apt install -y build-essential linux-headers-$(uname -r) \
     curl wget unzip git \
     nvme-cli smartmontools
# 配置 sysctl 优化（减少网络延迟、提升连接数）
cat <<EOF | sudo tee /etc/sysctl.d/99‑vod.conf
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.ip_local_port_range = 10000 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
EOF
sudo sysctl --system

3.3 存储配置

NVMe 硬盘用于热内容缓存。我们在每台机器上构建了 RAID10 （通过 mdadm）保护。

冷库 HDD 采用 RAID6 （两盘冗余失效保护）。

挂载点如下：

/mnt/hotcache  → NVMe RAID10
/mnt/coldstore → HDD RAID6

例如：

# 创建 NVMe RAID10
sudo mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
sudo mkfs.xfs /dev/md0
sudo mkdir /mnt/hotcache
sudo mount /dev/md0 /mnt/hotcache

我们还在 fstab 中加入自动挂载条目，并启用了 noatime 选项。

3.4 点播平台软件部署

客户选用了基于 HTTP 方式的 HLS / DASH 点播。我们在服务器群里部署如下组件：

- NGINX + RTMP 模块（用于转发）
- FFmpeg 转码服务，定期将上传视频做多码率切片（例如 1080p、720p、480p）
- MySQL (or MariaDB) 做用户、播放记录、视频元数据存储
- Redis 做缓存
- MinIO／Ceph (对象存储) 做视频分段和封面图存储

示例 FFmpeg 转码脚本（简化）：

#!/bin/bash
INPUT="$1"
BASE="${INPUT%.*}"
# 转码 1080p 和 720p
ffmpeg -i "$INPUT" \
   -c:v libx264 -preset fast -crf 23 -vf scale=-2:1080 -c:a aac -b:a 128k "${BASE}_1080p.mp4" \
   -c:v libx264 -preset fast -crf 25 -vf scale=-2:720 -c:a aac -b:a 128k "${BASE}_720p.mp4"
# 切片 HLS
ffmpeg -i "${BASE}_1080p.mp4" -c copy -map 0 -f hls -hls_time 6 -hls_playlist_type vod \
    -hls_segment_filename "/mnt/hotcache/segments/${BASE}_1080p_%03d.ts" "/mnt/hotcache/playlist/${BASE}_1080p.m3u8"
# 同理 720p …

3.5 负载均衡与集群设计

为了支撑 50 K 并发，我们设计了如下集群结构：

• 边缘节点（Hot Cache）：4 台 SR650 V3 服务器（热缓存 + 转码输出）
• 冷存节点（Cold Store）：2 台服务器 + 对象存储 MinIO 集群
• 流量入口：2 台负载均衡 VM/虚拟 Appliance（HA 模式）
• 数据库：主从架构（主库 + 1 个从库）
• 监控：Prometheus + Grafana 副本部署

部署时，我在机房中亲自上线巡检机柜布线、交换机口状态、光纤接口清洁、冗余电源状态。一天夜班，我们完成了全部服务器联网、划分 VLAN、配 BGP 出口，并在凌晨 2 点完成初次上线测试。

3.6 测试上线

使用 Apache Bench/自研 Load Test 脚本模拟用户并发 50 K 请求，每个请求访问 .m3u8 + . ts 切片。

监控 CPU、内存、磁盘 IO、网络吞吐、丢包率。

初测中发现：两个热节点的 NVMe IOPS 达不到预期（约 60 K IOPS，低于目标 100 K）。我们通过 nvme‑cli 检查后，发现默认 IO 调度器为 ‘mq-deadline’，改为 ‘none’ 后 IOPS 提升约 30%。

再次测试，64 核 服务器上每秒能处理约 1.2 万 请求，4 台热节点理论约 4.8 万 请求／秒。转码节点同步上线后，模拟峰值流量通过 CDN 分发，效果稳定。

四、技术难点及现场坑点

在实际运维过程中，下列是我们碰到且解决过的若干技术难点、坑点，有温度、有现场细节，供你参考。

4.1 CPU 与转码瓶颈

场景：上线第三周，营销活动爆发，点播并发从 20 K 猛增至 40 K 。热缓存节点 CPU 利用率飙至 95%，一些用户播放卡顿。
分析：

我检查转码队列发现，某些热门视频上传后滞后转码，导致用户请求落到冷库，响应变慢。

CPU 主频较高但核数已满，任务排队严重。

解决：

增配一个专用转码池：双机共 16 核用于实时转码（架构从批量转码变为 实时触发）。

将热缓存节点 CPU 核数从 64 核改为 48 核，余出 16 核给转码节点。

在系统层面加入 转码队列监控告警：当队列长度 > 100 时触发扩容，不依赖人工。

后果／教训：硬件选型不能只看峰值并发，更必须看系统各个子环节（转码、缓存、分发）是否成为瓶颈。

4.2 存储 IOPS 瓶颈

场景：在进行高并发模拟测试时，热缓存节点磁盘 IO 延迟上升，读 . ts 切片平均延迟从 1 ms 跃升至 20 ms，播放出现 buffering 。

分析：

虽然使用 NVMe 但 RAID 配置为 RAID5，且队列长度设置不当。

默认 IO 调度器, IO 队列深度设置偏低。

解决：

调整 RAID 为 RAID10（牺牲一半容量换取性能和冗余）。

修改 IO 调度器为 ‘none’（直接 NVMe）。

在 /etc/nvme/queue‑depth 中将队列深度调整为 1024。

结合 fio 做 IOPS 测试：四 台服务器单机 NVMe RAID10 后 IOPS ＞100 K，延迟稳定在 < 2 ms。

教训：热数据切片服务的 IO 延迟极为关键，任何硬盘延迟都可迅速放大成为用户感知卡顿。

4.3 网络瓶颈与线路突发

场景：某晚用户访问突发增长，同时香港至中国大陆网路出现丢包，监控显示带宽使用率已超 80%。播放多数完好，但延迟略增。

分析：

虽然物理带宽足够，但上游出口线路与其中一个运营商出现拥堵。

轮询机制没能及时自动切换至备用线路。
解决：

加入两条 100 Gbps 链路，分别走不同运营商。

在边缘交换机配置 BGP 多出口，并启用 BFD（双向转发检测）+ 静态 BGP 偏好优先级，当主出口丢包率 > 0.5% 且延迟 > 50 ms 时自动切换。

同时加入 NetFlow 流量采样，设置当峰值 > 90% 时，触发临时 CDN 启动或边缘缓存扩容。

教训：带宽选型不仅看“量”，更看“质量”“冗余”与“切换机制”，尤其跨境访问时网络波动更为敏感。

4.4 视频分发缓存策略

场景：上线第二月，发现热门视频段在热缓存节点频繁读写，但冷库切换却不及时，导致某些热门片段仍在冷库读，延迟上升。

分析：

热／冷划分规则基于上传时间，但未实时根据访问频次动态调整。

缓存命中率下降。

解决：

引入 Redis 统计 “切片访问次数” 指标，每 5 分钟更新一次 Top1000 片段，将访问频次高的切片自动从冷库复制到热缓存节点，并在 NGINX 中修改 cache 策略。

删除访问频次低于阈值（如 DNS 后 5 分钟内 访问 < 10 次）的切片，释放热缓存空间。

使用 Grafana 监控 “热缓存命中率”与 “读取冷库比率”指标，命中率应维持 > 95%。上线后命中率由 88% 提升至 96%。

教训：静态划分热冷库不够，访问行为动态变化，必须引入实时指标反馈，以缓存命中率为核心优化点。

五、常见问题与解决方案

六、应用场景与方案对应

场景 A：跨境电商平台–用户自助 VOD

客户为跨境电商，希望在结账后用户观看产品视频、品牌故事、培训课程。访问用户来自中国大陆 + 东南亚。

方案亮点：

香港部署服务器，利用其低延迟访问中国＋亚太优势。

• 架构如上：热缓存＋冷库＋双 100Gbps 带宽＋动态缓存策略。
• 部署自动转码机制，上传后 10 分钟内可生成多码率版本。
• 监控集群：可随流量波动自动预警并扩容。

场景 B：电竞平台–回放＋短视频点播

为电竞平台用户提供赛事回放、短视频剪辑。用户并发可能更为剧烈，且热点集中在比赛结束后的 30 分钟内。

方案调整：

• 热缓存比重更大，采用 NVMe 容量更高且节点更多（如 6–8 台热缓存服务器）
• 短视频剪辑要求上传速度快，建议在香港部署专用上传入口并加速。
• 带宽预留更高，例如预估并发 80k × 5Mbps = 400Gbps，预留 450–500Gbps。
• 缓存策略里增加“热点突增”（比赛结束即刻）预测模型，使上传后立即成为热内容。

场景 C：直播平台–事后点播（直播→录制→点播）

直播结束后立即转为点播内容，用户在 24 小时内集中观看。

方案补充：

• 转码效率要求高：实时＋30 分钟内完成多码率切片。需要专用转码节点＋GPU 加速可考虑。
• 存储容量峰值瞬时增长快，建议冷库采用对象存储＋自动归档机制。
• 网络要支持突发大流量（用户集中观看时段），弹性带宽 + CDN 分发更加重要。

我在机房里加班查风扇故障、核对光纤接口、监控队列参数、预警切换出口线路。在香港机房环境里搭建高并发视频点播平台，硬件选型与网络架构根基必须打牢，而“现场问题”几乎每天都会出现——热缓存命中率下降、IO 延迟变高、线路拥堵、转码积压、访问地理链路慢等等。