EP16：如何应对突发性高并发场景

在 YouTube 打开

上集回顾	EP15《横向扩容和低延迟的关系》
下集预告	EP17《从零部署：15 分钟跑起你自己的 CDN》

0. 本集目标

看完这一集，观众应该能做到四件事：

1. 分清"高并发"考验的是谁：是观众拉流（下行分发）的压力，不是主播推流（上行）的压力——这个区分决定了后面所有容量规划的方向。
2. 理解 Edge 节点的两级容量：工程上限"满容量"与线上实际运行的"配置容量"，为什么线上基准要留出弹性余量，并发逼近配置容量时该做什么。
3. 搞清楚扩容来不及时的兜底手段：超管开启"业务降级许可"后，容量告警自动联动触发的 1080P→720P 降级，它怎么在秒级突发和分钟级扩容之间抢出一段缓冲时间。
4. 用 AWS 上的真实规格数字算一遍账：单节点、单 Region 到底能扛多少观众，这套余量应付一般的游戏直播峰值是不是问题。

---

1. 先定位：高并发考验的是"观众"，不是"主播"

一场直播里有两条完全不同的负载路径：

flowchart LR
    OBS["主播 OBS 推流"] -->|"上行：1 条流，码率基本恒定<br/>simulcast 三层打包，不随观众数变化"| Origin["Origin 源站"]
    Origin --> Edge1["Edge 节点 1"]
    Origin --> Edge2["Edge 节点 2"]
    Origin --> EdgeN["Edge 节点 N"]
    Edge1 -->|"下行"| V1["观众 × 若干"]
    Edge2 -->|"下行"| V2["观众 × 若干"]
    EdgeN -->|"下行：每个观众一份出站流量<br/>随观众数线性增长"| VN["观众 × 若干"]

• 上行（推流）：主播到 Origin 只有一条链路，码率由 simulcast 层级和 HEVC/H264 多轨共同决定，不会因为观众从 10 个涨到 10 万个而变化。这条上行用的是主播自己的带宽，PPCDN 不对上行计费，也不需要云端转码。
• 下行（拉流）：每个观众都要从某台 Edge 拉到一份媒体流，Edge 的出站带宽、连接数、CPU/内存占用都随观众数线性增长——这才是真正会被"突发"压垮的地方。

一句话：讨论"突发高并发"时，第一步永远是把视线放到观众规模的下行分发上；上行推流链路的负载模型完全是另一套，不随观众暴涨而变化。

---

2. Edge 节点容量：满容量与配置容量

每台 Edge 节点有两个容量概念,不要混在一起说：

概念	含义	数值（2vCPU/4GB 节点）
满容量	工程上限——继续往上加并发，节点会先于其它环节撑不住	250 并发拉流
配置容量	线上实际运行时设定的准入门槛，调度器按这个数字做准入判断	100 并发拉流
弹性余量	满容量与配置容量之间留出来的缓冲	150 并发拉流

250 不是拍脑袋的数字：这是 EP14 在 2vCPU/2GB 机型上做阶梯压测时干净通过、0 断连的实测上限（再加一档的 300 路是内存耗尽的故障点，不能算容量）。生产部署用的是内存更宽裕的 2vCPU/4GB，拿这个在更紧张的硬件上验证过的数字做满容量，本身就带着安全余量，不需要再单独为 4GB 机型重新压测一轮。

单节点并发容量（2vCPU / 4GB）
满容量（工程上限）   ██████████████████████████████  250
配置容量（线上基准） ████████████                      100   ← 日常运行在这条线下
弹性余量                     ██████████████████         150   ← 留给突发峰值

为什么配置容量要留出余量，不直接顶到满容量 250？

• 观众是脉冲式涌入的：开播瞬间、热门内容被转发出去,涌入速度比扩容流程快得多。
• 如果日常就跑在满容量附近，一来峰值，立刻就要等新节点上线——这段等待期无法被跳过。
• 把日常基准设在 100，相当于提前给每台节点预留出 150 的应急空间，突发发生时节点本身就能多扛一段，不必立刻等机器。

配置容量只是"舒适区"的上限，不是硬顶：

flowchart TD
    A["观众并发持续上涨"] --> B{"是否逼近配置容量（100/台）？"}
    B -- "未逼近" --> A
    B -- "逼近/达到" --> C["触发容量告警（80% 预警 / 95% 严重）"]
    C --> D["开始增加 Edge 节点分摊<br/>新节点同样按配置容量标准接入"]
    D --> E["整体配置容量跟着节点数线性扩大"]

并发到了配置容量附近,动作是加节点，不是让单台节点硬扛到满容量——满容量留出来的这部分余量，是留给"加节点来不及"的那一小段窗口期的，接下来这一节就讲它。

---

3. 扩容来不及时的兜底：业务降级许可 + 容量告警自动联动

扩容是分钟级的（申请机器、注册、接入节点池），但观众涌入可能是秒级的。中间这段时间差，靠的是一个由超管预先开启的授权位——业务降级许可。

ppcenter 后台的这个开关，不是直接执行降级的按钮，而是是否允许容量告警自动联动触发降级的许可位。超管打开"业务降级许可"后，扩容来不及时，容量告警会自动把全平台播放画质上限降到 720P；如果许可是关闭的，容量告警就只走普通的人工扩容流程，不会自动降画质。

stateDiagram-v2
    state "正常：1080P 可用，并发 ≤ 配置容量（100/台）" as Normal
    state "告警：容量告警触发（80%/95% 阈值）" as Alert
    state "自动降级：业务降级许可=true → 全平台播放上限锁定 720P" as Degrade
    state "仅人工扩容：业务降级许可=false，不自动降级" as ManualOnly
    state "恢复：新节点上线、并发回落，解除上限" as Recover
    [*] --> Normal
    Normal --> Alert: 并发逼近/超过配置容量
    Alert --> Degrade: 业务降级许可 = true
    Alert --> ManualOnly: 业务降级许可 = false
    Degrade --> Recover: 扩容到位 + 并发回落
    ManualOnly --> Recover: 扩容到位 + 并发回落
    Recover --> Normal: 逐步解除上限，恢复 1080P

为什么降到 720P 能救命：同样一份带宽、同样数量的连接槽位，承载 720P 观众比承载 1080P 观众更轻；把播放画质的上限临时压一档,相当于把节点的"有效可承载观众数"从配置容量 100 往满容量 250 的方向推。业务降级许可打开之后，这一步不需要等一台新机器、也不需要人去点——capacity 告警一出，这个开关就能把节点的余量立刻腾出来。

降级和扩容是并行赛跑的两条线，不是先后关系：

sequenceDiagram
    participant V as 观众涌入
    participant M as 容量告警
    participant A as 业务降级许可（超管预设）
    participant P as ppcenter 自动降级（秒级）
    participant O as 节点扩容（分钟级）
    V->>M: 并发冲高，触达配置容量
    M->>M: capacity_high 告警（80%/95%）
    M->>A: 检查业务降级许可
    A-->>M: 许可 = true
    M->>P: 自动下发 disable1080p
    P->>P: 经既有节点心跳通道广播到所有 Edge
    Note over P: 秒级生效，播放上限锁定 720P，腾出余量
    M->>O: 同步触发扩容流程
    Note over O: 分钟级：申请机器 → 注册 → 接入节点池
    O->>M: 新 Edge 节点上线，整体配置容量扩大
    M->>P: 并发回落到配置容量以下，逐步解除 720P 上限

降级负责"撑住这几分钟"，扩容负责"把容量基准线真正抬高"——两者配合，才能让配置容量加弹性余量的设计真正兑现；而这一切自动联动的前提，是超管已经把"业务降级许可"打开。

---

4. AWS 部署规格与余量：应对一般游戏直播容量够不够

单节点（2vCPU/4GB）的满容量/配置容量不变：

规模	满容量	配置容量	弹性余量
单节点（2vCPU/4GB）	250 并发拉流	100 并发拉流	150 并发拉流

但把这组单节点数字按 Edge 台数直接相乘、折算到单 Region，是本集早先版本（以及 EP15）都用过的算法——"250×30=7500"。这个算法是错的，需要先纠正。

纠正：单 Region 容量不能按"单节点容量 × Edge 台数"线性折算。 docs/deployment/ppcdn-production-deployment-plan.md §4.8 后来补充的真实测算推翻了这个算法：Origin 用 forwardMmx 把每一路直播流全量广播给每一台 Edge，Origin 自己的出站带宽 = 同播路数 × Edge 台数 × 单路码率——这个数字和观众数量完全无关，却会在 Edge 台数还远没涨到 30 台之前，就先把 Origin 自己的网卡挤爆。真正的扩容瓶颈根本不在 Edge 这一侧，在 Origin。

按 7.5Mbps 的 simulcast 整梯（观众实际只拉其中一层，按 1.5Mbps/观众评估）测算，一台 5Gbps 网络档的 Origin：

Edge 台数	性质	峰值观众（$12 档 Edge）	峰值观众（$24 档 Edge）
15	5 Gbps Origin 安全值	~2,700	~3,300
22	5 Gbps Origin 理论上限	~4,000	~4,800

单 Region 峰值观众（按 Origin 网卡口径，不是单节点容量线性折算）
15 台 Edge（$24 档） ████████████████████████████████          ~3,300
22 台 Edge（$24 档） ████████████████████████████████████████  ~4,800
                     （对照：旧算法 250×30 线性折算出的 7500 并不成立）

这组数字比旧版"250×30=7500"小得多，原因很直接：单路流就要 Origin 出 Edge 台数 × 7.5Mbps，Edge 从 15 台涨到 22 台，Origin 的出站压力同步上涨近 50%，先顶到天花板的是 Origin 自己的网卡，不是 Edge 的 CPU/内存。

机型选择上还有一层：1.5Mbps 的观众负载下，$12 档（2vCPU/2GB）单台先撞到的是内存瓶颈；$24 档（2vCPU/4GB）同价多一倍内存、多 33% 流量配额，单台能多扛不少观众——同样预算，$24 档更划算，这也是上表两列差距的来源。

想突破这个约 15～22 台 Edge 的规模，三条路：把 forwardMmx 从"全量广播"改成"按需转发"（只给确实有观众在看的 Edge 转发，最有效）、用多台 Origin 分层 fan-out、或者换更大网络档的 Origin 实例。

（以上容量估算按每观众 1.5Mbps 的 H264 拉流计，未计入 HEVC 与 P2P 对 Edge 出站的节省，两者的算法见 EP20。）

一般的游戏直播，单场峰值观众从几百到大几千不等，极少数头部赛事才会冲到万级。拿这个量级去对比：15 台 Edge（$24 档）约 3,300 的峰值已经能覆盖大多数场次；真正逼近或超过这个量级的头部赛事，第一反应不该是简单再加 Edge——过了这个规模，加 Edge 台数本身就不再是最有效的扩容手段，得先上按需转发或多 Origin 分层。

---

5. 三道防线串起来

flowchart TD
    A["观众并发开始上涨"] --> B["第一道：配置容量<br/>日常运行基准，留出弹性余量应对突发"]
    B -->|"逼近/达到配置容量"| C["容量告警（80% 预警 / 95% 严重）"]
    C --> D["第二道：自动降级（秒级）<br/>业务降级许可=true → 全平台播放上限 720P<br/>腾出余量，向满容量方向推"]
    C --> E["第三道：节点扩容（分钟级）<br/>新 Edge 同样按配置容量标准接入节点池"]
    D --> F["并发回落到配置容量以下"]
    E --> F
    F --> G["逐步解除 720P 上限，恢复 1080P"]

三道防线分工清楚：配置容量决定日常基准留多少余量，自动降级负责秒级抢时间（前提是业务降级许可已打开），节点扩容负责把容量基准线真正抬高。三者配合，才是"满容量 250 / 配置容量 100 / 弹性余量 150"这套设计真正要应对的场景。

---

6. 结尾与下集预告（逐字稿要点）

应对突发高并发,先把"观众"和"主播"这两条负载路径分开看——真正会被冲高的是观众拉流的下行链路。Edge 节点的配置容量留出弹性余量；并发逼近配置容量就增加节点；超管打开"业务降级许可"之后，如果扩容来不及，容量告警会自动把全平台播放画质上限降到 720P，用秒级的降级去换分钟级扩容需要的时间。落到 AWS 的真实规格上：单节点 2vCPU/4GB 满容量 250；但单 Region 的峰值不能拿这个数字直接乘以 Edge 台数——Origin 自己的网卡才是真正的扩容瓶颈，15 台 Edge（$24 档）约 3,300 峰值、22 台约 4,800——这套余量，应对一般的游戏直播容量不是问题，但头部赛事级别的流量得提前规划按需转发或多 Origin 分层。

下一集，我们把整套系统从零部署起来，15 分钟跑通今天讲的这些机制。

---