如何在香港机房上搭建一个能够支撑百万级观看并发的短视频平台？客户是一家跨境电商公司，主营业务是通过短视频和直播带货，吸引全球用户。因此，对平台的观看并发能力、流量突增应对能力以及跨境访问的稳定性，客户有着极高的要求。这个挑战不仅仅是技术上的测试，更是对我们团队的极大考验。

选择香港作为部署地，是因为它既能保证对大陆用户的低延迟访问，又能够有效覆盖到海外用户。但面对这个庞大的并发量——高达百万级的同时在线用户——我们知道，这个项目将会是一次技术大考。我和我的团队从最初的方案设计，到硬件选型，再到部署和验收，每一步都充满了细节和挑战。上线后的每一场直播、每一秒钟的流畅播放，背后都离不开我们不懈的努力和调整。今天，我将这一路的故事和经验整理出来，希望能够为遇到类似问题的朋友提供些许帮助。

一、硬件选型（香港服务器）

在香港数据中心租用或者托管服务器，目的是做直播／短视频流媒体分发+后台服务。因此，硬件选型比一般 Web／电商系统还要严。以下是我们当时的选型清单＋理由＋参数建议。

硬件选型清单

我们把系统按角色分为几类服务器：

• 转码／直播推流节点
• 流媒体分发节点（播放端服务）
• 后台服务节点（API、用户系统、数据分析、短视频点播）
• 缓存／存储节点（视频片段、CDN接入前缓存等）
• 负载均衡／入口节点

下面按类别依次给出推荐配置以及我们当时选型。

1. 转码／推流服务器（直播源头）

• CPU：Intel Xeon Gold / AMD EPYC 系列，至少 24 核 48 线程。因为直播源可能做编码、转码、推流。
• 内存：64 GB 或以上。转码算法占用内存＋缓冲。
• 存储：SSD NVMe 1TB（用于临时缓存、切片输出）+ HDD 4TB（归档用途）
• 网络：至少 10 Gbps 网卡（双路冗余）
• 机房要求：香港 Tier‑3+ 或 Tier‑4 数据中心，机柜冗余电源、BGP 多回程。
• 操作系统：Ubuntu 20.04 LTS 或 CentOS 7/8。
• GPU（可选）：如果要做实时 AI 分析或画面识别，可以加装一块 NVIDIA A10 / RTX 6000 显卡。
• 备用：采取热备一台同等规格服务器，当转码节点故障可以秒切。

我们当时实际选型是：24 核 Intel Xeon Gold 6248R（24C/48T, 3.0GHz）+ 64 GB DDR4 + 1TB NVMe + 4TB SATA HDD + 双 10Gbps 网卡。

2. 流媒体分发服务器（播放端服务节点）

这些服务器主要是向用户输出 HLS/DASH/RTMP 等视频流。对并发连接数、网络吞吐量、缓存能力要求极高。

推荐配置如下：

• CPU：16 核 32 线程即可（因为主要是网络＋IO为主）
• 内存：32 GB
• 存储：500GB NVMe （用于缓存热片段）
• 网络：至少 40–100 Gbps 总出网能力（按峰值估算见下文）
• 机房：香港机房，电信／联通／移动回程优化线路。
• 系统优化：网络栈优化（epoll 模型、减少 context‑switch、TCP 参数调优）

3. 后台服务节点（API、用户系统、短视频点播控制）

这些是常规 Web 服务类型，但并发可能很高。配置建议：

• CPU：8 核 16 线程
• 内存：32 GB
• 存储：256 GB SSD用于系统＋日志
• 网络：1–10 Gbps（视乎流量控制面规模）
• 技术：容器化部署（Docker/Kubernetes）＋微服务架构

4. 缓存／存储节点

用于视频切片缓存、点播存储、热片缓存。我们当时采用混合方案：SSD 缓存 + 对象存储 + CDN 后备。

建议：

• CPU：4‑8 核
• 内存：16‑32 GB
• 存储：SSD RAID 10（如 2×1TB）+ 后端对象存储（NAS/分布式存储如 Ceph）
• 网络：10Gbps
• 硬件选型表格

下面是我们选型整理成表格，方便对比／估算。

硬件选型细节说明／现场经验

在香港机房租用服务器，一定要确认“独享带宽”而不是“共享带宽”。因为我们做短视频／直播，带宽是瓶颈之一。 

多回程线路／BGP优化线路很关键。我们一次测试，发现中国大陆某省访问香港节点延迟 + 丢包率明显高，后来更换机房线路后改善明显。参考 “香港服务器访问速度”那篇文章。 

存储方面，我们选择 SSD 缓存 + 对象存储分层。因为点播短视频会有热片、冷片差异；而直播更多是流处理。

扩展性考虑：建议服务器留有扩展插槽（内存、网卡、SSD）以便后续升级。我们当时就选择了支持双 10Gbps 或四 10Gbps 网卡的机型。

成本考量：香港机房成本一般比内地或亚太其他机房略高，但为了低延迟＋跨境访问优势，我们认为值得。

二、网络带宽与线路选型

硬件选好只是基础，网络与带宽设计才是“百万级并发观看”能否成立的关键。这里我结合我们项目中的数据、估算过程、优化经验，以及香港机房特有的线路/跨境问题。

带宽估算

假设我们目标同时在线观看用户数 = 1 000 000（百万级）。短视频平台一般观看画质不会全部用 4K，假设主流是 1080p／720p。为简化，假设平均每用户使用 2 Mbps 的带宽（对于 720p 或 1080p 较为保守）。

则理论出流带宽 = 1 000 000 × 2 Mbps = 2 000 000 Mbps = 2 000 Gbps = 2 Tbps。

这是一个非常巨大数字。显然，单一香港机房单台服务器或单一区域难以承载这么高出流，所以必须分布式、使用多节点＋CDN＋负载均衡。

在初期部署阶段，我们拆分为多个分发节点，每个分发节点假设可支持例如 40 Gbps 出流（视服务器/网卡/机房而定）。若每台分发节点支持 40 Gbps，则需要大约 50 台节点（2000 / 40 = 50）。但这只是理想估算，还有冗余、安全、CDN缓存、回源流量等。

我们在现场初期规划是：部署 6 个香港分发节点，每个节点带宽 100 Gbps（取整后预留冗余），合计 600 Gbps，再加上若干国外/大陆边缘点＋CDN缓存节点，将用户访问压力分散。通过 CDN（或自建“边缘缓存＋香港骨干”）把实时流量迅速分散。

带宽与线路选型细节

必须选 独享带宽，共享带宽在高峰期可能被抢用，导致抖动。 

机房应支持 多回程路径／BGP 多线路，尤其面向中国大陆用户。我们在选香港服务器时候重点询问是否与中国电信、联通、移动有直连优化。参考资料也指出香港直连优化型服务器可实现“短路径、低损耗”。 

延迟和丢包监测：现场我们进行了 MTR/traceroute 测试，对几个主要省份的访问进行延迟/丢包基线测量。例如广州→香港平均延迟 10ms，丢包率 < 0.5% 为可接受。若发现某线路跳数多、跳数 >20 或丢包率 >2%，就要联系服务商优化。 

网络冗余：建议分两条网络出口（例如两个运营商回程），并在服务器机柜配置冗余网卡、双链路。

带宽监控与预警：我们上线前预设带宽利用率警戒线（如≥70%），并和机房方协商“超出时可临时拉升带宽”机制。

CDN 或边缘缓存接入：虽然机房带宽大，但仍需用 CDN 分发边缘节点减少回源压力。参考 “内容传递网络” 的优势。 

现场经验／坑

我们初期只采购 300 Gbps 总带宽，测试阶段没问题。但上线首场直播后用户数猛增，出流瞬时达 350 Gbps，就出现部分延迟和卡顿。现场紧急与机房协商临时升带到 500 Gbps，并加开一个备用分发节点。

一次发现凌晨 2 点测试时看似正常，但早上高峰（大陆工作日上午）访问跳数突然增加，经查是联通回程线路带宽被切片给其他业务。后来我们更换机房并与服务商签订“专用回程”协议。

跨境访问的问题：虽然香港机房好，但仍有部分东南亚地区用户延迟较大。我们于是在新加坡／马来西亚设立缓存节点，用做“边缘出”缓解。

三、部署教程（架构 + 实现方法 +代码示例）

下面我以“在香港机房部署百万级观看并发短视频平台”为背景，分步骤写部署流程。因为篇幅所限，部分细节简化，但关键点真实且可执行。

架构简介

先给出我们最终采用的简化架构：

• 推流端：主播／短视频上传端 → 转码／推流服务器（香港机房）
• 主干分发：香港多个流媒体分发节点（负载均衡） → 用户端
• CDN/边缘缓存：香港 + 海外（东南亚）缓存点用于分流
• API/后台服务：用户鉴权、视频管理、数据统计、运营系统
• 监控报警系统：带宽监控、节点健康监控、用户体验监控
• 负载均衡层：前置负载均衡器 + 智能 DNS + GSLB

步骤一：服务器准备

在香港机房租用硬件（如前文硬件清单所示）

系统安装：我们选择 Ubuntu 20.04 LTS，因为兼容性好、社区支持强。

# 示例配置
sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx docker.io docker-compose

系统网络调优（关键）：

# 关闭 swap
sudo swapoff -a
# 增加文件描述符
echo "fs.file-max = 1000000" | sudo tee -a /etc/sysctl.conf
echo "net.core.somaxconn = 1024" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_tw_reuse = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_fastopen = 3" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

安装流媒体服务端软件。我们用了开源 SRS（Simple RTMP Server）作为流媒体核心。选它是因为社区活跃、功能丰富。 

# 拉取 SRS Docker 镜像
docker pull ossrs/srs:3
# 创建 srs.conf 配置文件（简化版）
cat > srs.conf <<EOF
listen              1935;
max_connections     1000000;
http_server {
  enabled         on;
  listen          8080;
  dir             ./objs/nginx/html;
}
vhost __defaultVhost__ {
  hls {
    enabled       on;
    hls_path      /data/hls;
    hls_fragment  4;
  }
  dvr {
    enabled       off;
  }
}
EOF
# 启动
docker run -d --name srs -v /data/hls:/data/hls -p 1935:1935 -p 8080:8080 ossrs/srs:3

存储节点部署：挂载高速 NVMe，配置 RAID（如果多盘），并安装对象存储或分布式存储（如 Ceph、MinIO）。

分发节点部署：安装 Nginx 打流 +缓存 +负载均衡插件，并开启 HTTP/2、TLS 优化。

sudo apt install -y nginx
# nginx.conf 关键片段
# upstream backend {
#   server 10.0.1.1 weight=5;
#   server 10.0.1.2 weight=5;
# }
# server {
#   listen 443 ssl http2;
#   location / {
#     proxy_pass http://backend;
#     proxy_buffer_size 64k;
#     proxy_buffers 32 64k;
#     proxy_busy_buffers_size 128k;
#   }
# }

步骤二：负载均衡层与智能 DNS

前置负载均衡：建议使用一台或多台 F5／NGINX Plus／HAProxy 做全球入口。

智能 DNS (GSLB)：根据用户地理位置、网络延迟、节点负载动态选择最近／最快节点。3. 自动化脚本检测节点健康并向 DNS 服务更新。伪代码示例：

import requests, dns.resolver, subprocess
nodes = ["hk-node1.example.com","hk-node2.example.com"]
for node in nodes:
  r = subprocess.run(["mtr","-r","-c","10",node], capture_output=True, text=True)
  # 解析延迟、丢包 …
  if r.returncode==0 and "loss = 0%" in r.stdout:
    # 更新 DNS 记录逻辑
    requests.post("https://dns.api/update", json={"host": node, "weight": 100})

步骤三：监控与自动扩容

使用 Prometheus + Grafana 监控 CPU、内存、网络带宽、连接数、丢包率、延迟。

设置报警规则，如 “带宽利用率 > 80% 且 丢包率 > 1% → 自动拉新节点或通知运维”

自动扩容脚本（伪码）：

if (bandwidth_usage > 80%) && (node_count < max_nodes):
  # 启动新节点流程
  terraform apply -var="node_count=$(node_count+1)"
  # 更新负载均衡配置
  curl -X POST https://lb.api/add_node -d node=newnode

步骤四：上线前压力测试

我们在上线前做了阶段性压力测试。流程如下：

使用工具比如 Locust / JMeter 模拟用户连接观看行为：每个虚拟用户通过 HTTP 请求 HLS 片段；

模拟推流：主播端推 RTMP 到香港转码服务器，然后向分发节点输出；

逐步提升并发用户数，从 10 K → 100 K → 300 K → 500 K → 达到预期 1 000 K。每个阶段监控系统指标；

观察瓶颈：例如某台分发节点 CPU 上升至 90%、带宽利用率 95%、延迟增大、丢包上升。发现瓶颈后调整：加缓存、优化网络栈、增加节点。

制定上线 “降级兜底”方案：如果系统检测到严重瓶颈，可切换为低清分流（720p 限制）或使用备用机房。

步骤五：上线与灰度跳板

上线当天选择 “预演”时间段：先以小规模真实用户上线（例如 10 万并发）观察一小时；

若无异常，再逐步开启剩余流量；

实施 “跳板监控” – 借助实时仪表盘监控关键指标（带宽、延迟、丢包、连接数、CPU、内存）并安排运维值守。

设定 “应急关停按钮”：若出现严重问题，如整体延迟 > 5 秒 或 卡顿率 > 2%，立即启用备用线路/CDN切流。

上线后继续观测 24 小时高峰，特别是大陆早晨／欧洲晚间两时段。

四、负载均衡与扩展设计

百万级并发观看，负载均衡架构必须严谨。以下是我们在香港服务器部署中采用的设计思路与细节。

架构要素

入口负载均衡（Global）

• 智能 DNS (GSLB) 根据用户地理、延迟、节点负载返回最近节点
• 第一级流量入口：部署在香港机房 + 备用海外节点
• 区域负载均衡（香港机房内部）
• 多台分发节点通过 Nginx/HAProxy 负载均衡
• 转码节点、分发节点、缓存节点分层架构

缓存分层

• 热片缓存：在分发节点本地 SSD
• 边缘缓存：海外缓存节点、CDN

自动扩容机制

• 监控带宽／连接数触发自动新增节点（如 Kubernetes auto‑scale）

故障切换机制

• 若某节点负载过高或故障，负载均衡快速剔除＋替换
• 备用机房（可选）做灾备切流

关键技术细节

连接数优化：使用 modern Linux 虚拟连接堆栈（epoll、SO_REUSEPORT）、调整 ulimit、net.core 参数。

缓存优化：对于 HLS/DASH 切片，启用 Nginx 缓存 +缓存头设置，减少回源压力。

HTTP/2 + TLS：界面／短视频点播使用 HTTP/2 多路复用，减少新建连接开销。

防 DDOS：使用机房提供的 Anti‑DDoS 服务，或部署 WAF/流量清洗。

日志与追踪：每台节点日志集中到 ELK 或 Loki，实时监控异常。

回源控制：分发节点缓存命中率低时，回源压力大。我们加装 Redis 缓存／元数据缓存以减少请求数据库或对象存储次数。

扩展方案（根据负载增加）

从单机房→多机房：当香港机房出流压力接近饱和，可考虑在新加坡／东京／洛杉矶设立分发节点＋智能 DNS GSLB跨区域。

混合 CDN：除了机房自建分发节点外，引入商业 CDN（如 Akamai、Cloudflare）做边缘分发。

P2P 辅助技术（可选）：对于点播短视频，考虑 P2P 模式以减轻服务器带宽负担。相关研究指出 P2P‑VoD 系统可显著减轻服务器负载。 

五、技术难点、常见问题与现场坑＋解决过程

这是我最想分享的“有温度”的部分：现场遇到的坑、失误、解决过程。

技术难点

带宽瓶颈：在百万并发下，带宽不是单台服务器能解决的问题，需要分布式 + CDN。

跨境访问延迟、丢包问题：香港机房虽地理接近大陆，但仍有运营商线路跳数高、丢包率高的问题。我们测得某省访问香港某节点丢包率超过 3%。

流量突增（爆发式）：直播带货性质的短视频平台，用户数可能在短时间内激增数倍，需要快速弹性扩容。

缓存命中率低：初期短视频热度变化快，导致冷热片切换频繁，缓存命中率下降，回源压力大。

监控与告警滞后：初期我们监控偏向 CPU／内存，却忽略了网络层面的细节（丢包、延迟、跳数）。结果出现问题时才看到画面卡顿。

负载均衡时间延迟：智能 DNS 切换用户节点有时间延迟，在节点故障时用户仍可能连到故障节点几秒钟。

典型现场坑（真实案例）

坑一：带宽升不及时
在一次直播前，我们按估算只预拉了 300 Gbps 带宽。直播开场后，用户涌入，瞬时出流达 350 Gbps，导致部分用户播放缓冲、卡顿。我们赶紧拨机房紧急增至 500 Gbps，但期间损失了约 2 分钟画面质量。教训：预留冗余、按 1.5×峰值规划。

坑二：回程线路忽略
在某省份用户反映延迟高，经追踪发现是该省联通回程跳数多（>30跳），丢包率达 2%。我们联系服务商更换线路，并增设 “直连至联通”机房节点。后来延迟降至约 12ms、丢包 < 0.5%。

坑三：缓存命中率低
初期短视频平台片源更新快，热度集中在新片。我们缓存策略默认“7天未播放即淘汰”，结果导致热点片被频繁缓存/淘汰切换，缓存命中率低至 40%。后调整为“小时级更新+动态预热”，缓存命中率提升至 70%。

坑四：监控指标不全面
在一次突发中，分发节点 CPU／内存看起来正常，但出流延迟突然升高。原因是网络队列满，丢包率升高。此时我们才意识到必须监控 “网络队列长度”、“丢包率”、“MTR 跳数”指标，并在 Grafana 添加对应面板。

坑五：智能 DNS 切换延迟
当某香港节点出现故障（网络断链约 90秒）时，智能 DNS 切换生效时间约 20 秒，期间一些用户仍连到失败节点导致体验差。解决办法：缩短 DNS TTL，设立健康检查脚本提前剔节点，并启用备用机房立刻接管。

常见问题及解决方案

六、应用场景与解决方案总结

典型应用场景

• 跨境电商短视频平台：用户在中国大陆、香港及海外同时观看带货直播／短视频。
• 电竞／游戏直播平台：峰值并发高、用户互动强、延迟要求严格。
• 视频/直播平台：如活动直播、在线教育大型讲座、答题直播。有关“直播答题”“百万级并发”场景，可参考。 

解决方案回顾

• 选址香港机房：低延迟兼顾大陆与海外；但须注意回程线路、带宽独享。
• 硬件选型：推流节点高算力、分发节点高带宽、后台逻辑节点通用型。预留扩容空间。
• 网络／带宽设计：按估算并发×人均带宽计算总出流，采用分布式节点＋冗余带宽＋智能 DNS。
• 架构设计：分层（推流→分发→缓存→CDN）＋智能负载均衡＋监控＋自动扩容。
• 运维监控与优化：网络指标（丢包、延迟、跳数）不可忽视。缓存策略、负载均衡策略需动态调整。
• 测试及时演练：上线前必须做压力测试、演练故障切换场景。
• 应急方案：备用机房、低清模式（降低人均带宽）、CDN切流。

我们从最初选机房、硬件选型、带宽规划，到架构落地、压力测试、上线监控、故障应对，一路跌坑也一路成长。对我们团队而言，这不仅是一次技术挑战，更是一次运维“实战演习”。当那晚直播正式上线、用户数突破 80 万、系统稳定运行、弹幕不断、后台指标平稳时，我记得我们团队松了一口气：所有预案起作用了。