波仔
🎬 第七章 流媒体开源库简介
📄 一句话概括

云平台把成本拆成接入、转发、存储三层。 存储是唯一只增不减的那一层。

📝 本节和前面几节的关系

7.4.2 算的是单机容量，这一节算整个云平台的账。 7.5 转向 SRS，那是另一套开源方案。

一、三层各算什么

① 接入层：按路数与码率算带宽，通常按峰值买。 加一路就多一份，没有规模效应。 ② 转发层：按「路数 × 观看人数」算，这是最容易估错的一层。 因为观看人数会突然涨，而且每路都要转发一份。 ③ 存储层：按时长与码率算，只要有录像就一直涨。

实测这一组假设下的数字： 100 路 2048 kbps、每路 20 人，转发出口就是 3.9 Gbps。 同样 100 路录 30 天，每天 2109 GB，一个月就是 61.8 TB。

注意转发数字里没有「观众总数」这个量： 100 路各 20 人，与 1 路 2000 人，转发出口是一样的。 云平台按「路数 × 人数」计价，就是这个原因。

二、哪一层能砍、哪一层砍不动

转发层能砍：降码率、降分辨率、少看几路，都能省。 还能用 P2P 或边缘缓存把一部分流量从源站挪走。 存储层能砍：只录关键时段、只录低码率子码流、 或者设一个保留期（比如只留 7 天）。 接入层砍不动：摄像头推上来的码率是固定的， 要看就得按这个码率收：最多在服务端转成低码率再存。

所以云平台的定价通常把「录制」单列： 它是唯一只增不减的成本。 而带宽部分反而常有阶梯优惠，因为规模大了能谈价。

三、一个常见的估错

很多人按「观众总数」估带宽，结果严重偏低。 正确的算法是「每一路都要单独转发给每个看这一路的人」。

举例：100 路、每路 20 人，看起来「总共才 2000 人次」， 但转发出口是 100 × 20 × 2048 kbps = 3.9 Gbps， 而不是「2000 × 2048 kbps 再除以 100」。

差别在于「同一个人看两路要占两份带宽」。 所以估容量时应该按「路数 × 平均观看数」算， 那个乘积才是真正的并发流数。

四、动手 Demo：云平台——三层成本，存储最容易失控

按 100 路、每路 20 人、30 天录像算一遍三层成本。 再指出最容易估错的那个地方。

n, kbps, viewers, days = 100, 2048, 20, 30

live = n * kbps * viewers / 1024.0 / 1024.0
print("%d 路 x %d kbps x %d 人 = %.1f Gbps" % (n, kbps, viewers, live))

gb_day = n * kbps * 86400 / 8.0 / 1024.0 / 1024.0
print("每天录像 %.1f GB，%d 天共 %.2f TB" % (gb_day, days, gb_day * days / 1024))

print()
# 如果把每路观看数减半
half = n * kbps * (viewers // 2) / 1024.0 / 1024.0
print("观看数减半 -> %.1f Gbps（省 %.0f%%）" % (half, (1 - half / live) * 100))
# 如果把码率减半
half2 = n * (kbps // 2) * viewers / 1024.0 / 1024.0
print("码率减半   -> %.1f Gbps（省 %.0f%%）" % (half2, (1 - half2 / live) * 100))

实跑输出：

--------------------------------------------------------------------
云平台——三层成本，存储最容易失控
--------------------------------------------------------------------
**① 三层各算什么**

  **接入层**：**按路数与码率算带宽，通常按峰值买。**
  **转发层**：**按「路数 × 观看人数」算，这是最容易估错的一层。**
  **存储层**：**按时长与码率算，只要有录像就一直涨。**

**② 真算一遍**

  **100 路 × 2048 kbps × 每路 20 人 = 3.9 Gbps 转发出口。**
  **100 路录 30 天：每天 2109.4 GB，共 61.80 TB。**

  层       量级                增长方式
  -------------------------------------------------
  接入     100 路              加路数线性涨
  转发     3.9 Gbps            加观看人数线性涨
  存储     61.80 TB／30 天     只增不减

  **结论：转发与存储都能靠策略砍，接入只能靠加线路。**
  **所以云平台的定价通常把「录制」单列——它是唯一只增不减的成本。**

3.9 Gbps 这个数字很吓人，但它就是「100 路各 20 人」的真实出口量。 存储 61.8 TB 是一个月的量，年化就 740 TB，这才叫失控。 观看数减半与码率减半效果相同，因为公式里两者是乘法关系。

30 秒实验

  1. 把观看数从 20 改成 100，看转发出口——涨到 19.5 Gbps，这就是热门事件时的真实压力。
  2. 把保留期从 30 天改成 7 天，看存储——降到 14.4 TB，这就是「设保留期」的价值。
  3. 只录低码率子码流（512 kbps），看存储——降到四分之一，画质差但能看。

常见误区

  1. 「按观众总数估带宽」——要按「路数 × 每路人数」算。
  2. 「存储能靠压缩省下来」——只能靠降码率或缩短保留期。
  3. 「接入层也能优化」——摄像头推多少就得收多少。
自测三问（点开对答案） 1. 云平台的三层成本是什么？ —— **接入（路数×码率）、转发（路数×观看数）、存储（时长×码率）。** 2. 哪一层只增不减？ —— **存储层**，只要有录像就一直涨，所以要设保留期。 3. 估容量最容易错在哪？ —— **按观众总数估**，正确算法是「路数 × 每路观看数」。

相关笔记