「多买几台机器，单路播放会不会更快？」这是自建 CDN 最常见、也最容易答错的问题。更极端的情况是：流量不是缓慢上涨，而是某场活动一开场，几秒钟内几百上千人同时涌进来------**突发高并发**。
这一篇讲两件事：横向扩容和低延迟的真实关系，以及突发来临时系统靠什么顶住、又在哪些地方顶不住。
一、先破一个误解：加机器买的是容量，不是延迟下限
端到端时延由采集与编码、网络传播、协议缓冲、排队、解码和渲染共同组成。横向扩容**只直接处理资源竞争与排队**，它不会自动缩短传播距离，也不会改小既有的 jitter buffer 或 GOP。
所以结论要说得完整一点：
-
**健康空载、路径和媒体参数不变时**，加 Edge、加 Origin 不会让既定缓冲自动变小，单条管线的串行开销不会因为并行铺了更多节点而缩短。
-
**已有过载或路由不佳时**，扩容并重新调度可以减少排队、丢包和重传，或者把用户放到更近的节点，因此**观测时延可能下降**------这里改善的是拥塞或路径，不是「节点数量本身」。
一句话：**横向扩容解决的是「能不能扛住更多人」，不是「能不能更快」。** 这两件事经常被混为一谈。
需要提醒的是，不要把某个「约 70ms」这类数字当成扩容的效果------那通常是换了媒体路径（比如 P2P 直连）的案例，不是加机器的功劳，也不能外推成全网的 SLA。
二、容量是怎么度量的：`capacity` 与 `pipelines`
节点侧的容量模型通常很简单，两个数：
-
**`capacity`**：这个节点配置的并发槽上限（比如某台 Edge 配 12）；
-
**`pipelines`**：当前占用的媒体管线数。它是实现定义的**调度计数，不等于 viewer 数**------一条共享回源管线可服务多个 viewer，不同协议、编码轨或转发目标也可能各占管线；
-
**剩余容量 `free = capacity − pipelines`**：调度器按这个值在池内降序选点。
这里有两个必须讲清楚的现实：
**第一，`capacity` 是调度准入门槛，不是硬件能力保证。** 调度器可以在 `pipelines >= capacity` 时把节点排除出新请求候选，但这只说明「不再接新管线」，**不证明节点在门槛以内一定健康**。配置过高、已有会话瞬时膨胀或 CPU/网卡先到瓶颈，仍会丢包；配置过低则浪费资源。所以它必须由**压测校准**，并与 CPU、内存、带宽和丢包监控一起使用。
**第二，容量告警是给人看的，不是给机器看的。** 所以系统常用三级软阈值提前提示扩容：
| 阈值 | 示例值 | 含义 |
| --- | --- | --- |
| warning | 80% | 「开始准备加节点」 |
| critical | 95% | 「很危险了」 |
| resolve | 70% | 回落到该值以下自动清除告警 |
管线数是整数，阈值也应落实为整数比较，取整规则必须在实现和监控查询里保持一致。**调度器会把新请求引向其它有余量的节点，但它不会替你加机器。**
三、最反直觉的一课：Edge 越加，Origin 越忙
到这里，「加机器 = 加容量」看起来已经很直白了。但这套架构里有一个非常容易踩的坑：**给 Edge 扩容，会顺手把负载推给 Origin。**
原因取决于分发模式，不能只按已部署 Edge 总数机械相乘：
```
Origin 出站带宽 = Σ（每条流实际发往每个下游目标的码率）
```
-
在 **push fanout（预推）** 模式下，每个配置的下游都持续收流，新增 Edge 会立即增加 Origin 出站；
-
在 **on-demand pull（按需拉流）** 模式下，只有真正承载该流观众的 Edge 才回源，新增但空闲的 Edge 不产生这一路媒体出站；
-
同一 Edge 上的多个 viewer 若共享回源，也不能按 viewer 重复计算。
所以当新增 Edge 实际开始回源时，Origin 会增加一条新的转发链路（出口带宽）和一路新的媒体转发会话（会话数、内存）。这些成本随**实际回源的下游目标**逐项叠加，而不是随部署清单里的 Edge 总数必然增长。
> 工程教训：不能把 `capacity` 当成「这台机器保证能跑的路数」，更不能用「流数 × 固定目标数」代替流量测量。应按每条流的实际码率和实际下游连接求和，在压测中同时找出 CPU、内存、网卡和丢包的拐点，再给准入门槛留余量。
**结论：横向扩容不是「哪里不够加哪里」，而要顺着数据流看清------你加的每一台机器，会不会把压力转移到它的上游。** 在这套架构里，Edge 的上游就是 Origin。
四、让边缘扩容变便宜的机制：按需回源
既然 Origin 是瓶颈，那「每加一台 Edge 都必然给它加压」吗？不一定------关键看 Edge 是否**预先回源**。
**按需回源（source on demand）** 的流程是：
-
观众发起播放请求；
-
**这台 Edge 才去 Origin 拉这一路流**；
-
同一台 Edge 上、同一路流的多个观众共享同一条回源链路。
两个直接好处：
-
**一台没有观众的 Edge，对 Origin 的额外负载接近 0。** 你可以提前铺很多台边缘机器「待命」，它们不占 Origin 带宽，直到真的有观众落上来；
-
**边缘扩容不需要动推流侧。** 加 Edge 只是加了一个潜在的回源点，推流端完全无感。
代价也要讲诚实：按需回源意味着冷启动会增加建链和首帧等待。可以用「直连优先尝试、失败顺序回退边缘」配合合理超时来降低影响，具体时长应由真实网络分布校准。
五、突发高并发的真正难点：不是「总量大」，是「来得快」
先区分两种负载：
-
**均匀高负载**：用户数缓慢爬升，你看到容量告警，有时间按部就班加机器；
-
**突发高并发**：流量在很短时间内冲到峰值，峰值远高于均值。典型来源是活动开场瞬间、热门内容被分享出去、开播那一刻观众涌入。
后者的难点在**时间尺度**：
-
**预判不了**：不知道这次会涌进多少人；
-
**来不及手动扩容**：扩容通常是分钟级起步的人工流程，而突发是秒级的；
-
**放大所有单点**：平时能扛住的单台 Origin / 单台 Edge，在峰值下会先于其它环节饱和。**突发本质上是把系统里最薄的那一环照出来。**
所以应对突发，靠的不是「准备得足够大」，而是**有没有能在载荷变化的瞬间自动伸缩的东西**。
六、三层弹性防线
自建系统常见的弹性机制可以归成三层：
第一层：P2P 辅助卸载（固定上限）
P2P 直连可以减少一部分边缘出站，但必须先看供给端是谁：媒体由推流端直接服务少量观众，观众本身不成为新的分发节点。
-
推流端把上行富余带宽用于直连观众；
-
**每个推流端同时最多服务固定的 N 路直连**（常见默认 3，可由管理员调整，但**不会因为单场观众暴涨而自动变大**）；
-
因此单路直播无论从 10 个还是 10 万个观众增长，P2P 卸载的都是这**固定的 N 路**边缘观看。
对大量推流端同时开播的业务，总卸载量可以随推流端数量增加；但这仍不是单个热门流突发容量的防线。**突发容量规划不能把 P2P 算作会自动扩张的资源。**
第二层：按需回源 + 预置空闲 Edge
思路是**让空闲机器的成本接近于零，于是可以提前铺很多台待命**：
-
按需回源：没有观众的 Edge，对 Origin 的额外负载接近 0；
-
预置空闲 Edge 是划算的：提前在多个区域起一批边缘机器，闲时几乎不消耗 Origin 带宽；
-
突发来临时，这些 Edge 各自按需回源、开始分发，**容量按观众的实际落点动态启用**。
代价仍是冷启动建链和首帧等待；同一 Edge 上同路流的观众共享回源链路，由第一个观众触发回源。
第三层：发布链路降级（保护推流端，不是观众容量）
发布端自适应降级的目标，是在推流端上行或入口链路拥塞时**保护主发布链路**。机制是分层的、有顺序的：
-
**先压码率**：只降编码器码率，实时生效、不中断推流；
-
**码率压到底仍不达标，才砍最高同播层**：这一步有短暂中断；
-
**恢复要慢、要稳**：质量指标回落到恢复区间并持续一个观察窗口后才逐级恢复，避免震荡。
边界必须说清楚：**发布降级是针对推流端主链路质量的保护，不是观众突发容量防线。** 它治不了 Edge 连接数或机器数量不足，也不应等到观众洪峰才触发。
七、三层兜不住时：告警 + 人
如果峰值突破了弹性能扛住的上限，剩下的就是监控 + 人。常见信号有三类：
| 信号 | 触发 | 含义 |
| --- | --- | --- |
| 容量偏高 | 单节点已用/容量达到 warning / critical | 「这台快满了，该准备加机器」 |
| 池耗尽 | 主池无可用候选且禁止回退 | 调度直接失败 |
| 池回退 | 主池无可用候选、允许回退且共享池有候选 | 落到共享池（通常只记日志） |
这套信号的**设计意图就是「扩容触发器」**：容量到 80% 就该行动。但放在突发场景里，它有几个必须讲清楚的局限：
-
**没有自动扩容执行器**：告警只是通知人，人再走人工流程。对秒级突发来说，这个反应链太慢------扩容是追着洪峰跑，而且是事后追。
-
**告警通道的冷却与去重**：如果告警通道用「同一通道在 N 秒内只发一条」的冷却策略，突发时多个节点同时到阈值，可能只有最先到达的一条发得出去。这是一个需要在设计阶段就权衡的点------最需要密集告警的时刻，恰恰可能是告警被吞得最厉害的时刻。
-
**部分告警不落库**：未配置 webhook 时可能只在服务端日志里可见，后台看不到。
还有一个在突发场景里绕不开的取舍：**隔离（fail-closed）和可用性（fallback）是冲突的。** 主池没有可用候选且配置为不回退，调度会直接失败；要不要临时借用共享池，是业务优先级问题。
八、云厂商出站流量配额：是计费阈值，不是断流线
还有一个指标值得单独讲：**云厂商的月度出站流量额度。**
-
套餐内出站流量通常是一个**计费阈值**。突发会快速消耗额度；**超出后通常产生额外费用，而不是自动断流。** 是否限速或停服，必须以具体云产品、区域和账户策略为准。这首先是**预算问题**，不应被描述成必然的可用性中断。
-
可以做一个自动预警：每小时汇总每个节点本月的下行字节数，和一个配置里的配额常量比较，到 70% 触发提醒、回落到 60% 自动清除。
-
但要清醒：这个配额常量往往**写在配置里，不是对接云厂商账单 API**。云厂商套餐、区域或计费策略一旦变化，它不会自动更新，需要人工同步。真正精确的月度账单仍然只能登录云控制台核对。
九、诚实的现状与策略
把结论收一下：
-
**今天应对观众突发的主要能力 = 预置 Edge + 按需回源 + 调度/准入 + 人工扩容。** 它通常没有自动弹性伸缩。
-
P2P 每个推流端默认只卸载固定几路，不会随观众数自动变大；发布降级保护推流端链路，两者都不能替代热门流的边缘容量。
-
对突发的现实策略：
-
**提前把空闲 Edge 铺出去**（闲时几乎不吃上游带宽），让突发有地方落；
-
**把 P2P 的固定上限当作固定卸载收益**，不要计入随观众增长的容量；
-
**把扩容流程脚本化**，把人工步骤压到分钟以内；
-
**把容量实测校准**，别让软阈值保护一个虚高的分母；
-
**让流量配额常量跟着云账单走**，否则这层告警会悄悄失真。
- 最后一条立场：**突发会放大所有单点。** 单区域部署、单台 Origin、单台 Edge，在均匀负载下也许够用，但在突发下就是最先断的地方。**冗余（N+1）在低负载阶段的价值，往往比「再多一点容量」更高。**
小结
-
横向扩容买到的是**容量**和「在高负载下守住延迟」，不是健康空载路径上的延迟下限。
-
`capacity`/`pipelines` 是**软准入**，必须用压测校准，不能当硬件保证。
-
**Edge 越加，Origin 越忙**：Origin 出站要按实际回源目标逐项求和，区分预推 fanout 和按需 pull。
-
应对突发靠三层弹性 + 人工兜底，但**没有自动扩容器**；P2P 卸载有固定上限，发布降级不解决观众容量。
-
云厂商月度额度是**计费阈值**，不是断流线；配额常量需要人工跟账单同步。
下一篇进入实战：**从零部署一套自建 CDN，并给直播加上录像与回放。**
**系列导航**
- 上一篇：07 · P2P 直连与节点池调度(07-P2P直连与节点池调度.md)