波仔
📹 第五章 FFmpeg二次开发IPC视频监控
📄 一句话概括

标称 4 TB 的盘，系统里只显示 3.64 TiB——这是十进制和二进制之争，不是偷工减料。 再加上 RAID 和循环覆盖，「能存多少天」和「买了多少 TB」是两个数。

📝 本节和前面几节的关系

上一节算的是「需要多少容量」，这一节算「买来的容量实际能用多少」。 转封装与时间戳的关系在 04.06，这一节只关心「存得下、查得到」。

一、第一件事：TB 和 TiB

硬盘厂按十进制标：1 TB = 1000⁴ 字节。 操作系统按二进制算：1 TiB = 1024⁴ 字节。

标称 系统显示 差
2 TB 1.82 TiB 9.1%
4 TB 3.64 TiB 9.1%
8 TB 7.28 TiB 9.1%
16 TB 14.55 TiB 9.1%

每块盘都少 9.1%，而且是固定比例——两套单位的历史遗留问题。 报容量时一定要问清「你说的是 TB 还是 TiB」：差 9%，在 64 块盘的项目上就是 50 TB。

二、第二件事：RAID 让容量打折

方案 有效容量（8 TB 盘） 能坏几块
3 块 RAID5 16 TB（2×8） 1 块
4 块 RAID5 24 TB（3×8） 1 块
8 块 RAID5 56 TB（7×8） 1 块
8 块 RAID6 48 TB（6×8） 2 块
8 块 JBOD 64 TB 0 块

RAID5 的代价是「一块盘的容量」：8 块盘只能用 7 块。 RAID6 是两块，换来「重建时再坏一块也不丢数据」。 监控普遍用 RAID5 而不是 RAID6：盘多、写入连续、监控数据丢一段通常可接受， 不值得为它多付一块盘。 但 RAID5 有个著名的坑：盘越大，重建时间越长， 重建期间再坏一块就全丢——所以大容量盘反而更推荐 RAID6。

三、第三件事：循环覆盖

监控不是「写满就停」，是「写满就覆盖最老的」。 所以「能存多少天」= 有效容量 ÷ 每天写入量。

有效容量 每天写入 实际能存
24 TB 0.69 TB 35 天
48 TB 0.69 TB 69 天
120 TB 0.69 TB 174 天

第二列是 16 路 4 Mbps 一天的写入量：16 × 0.5 MB/s × 86400 秒 = 0.69 TB。 所以 24 TB 正好能存 35 天，够「存 30 天」；要卡住 30 天，21 TB 就够。

四、存储结构选型

方案 优点 缺点
NVR 本地盘 简单、便宜、延迟低 单点，坏了要拆盘
IPSAN 集中管理、可扩容 要组网，成本高
云端存储 不怕本地损坏 带宽成本高，长期更贵

监控的主流是第一种：NVR 本地盘占绝对多数，因为视频流是「写完基本不看」的数据， 不值得为它上昂贵的集中存储。 云端那行的成本要算清：存储费只是小头，上行带宽费才是大头——视频流是连续上传。

五、动手 Demo：标称 4 TB 的硬盘，实际能存多少

Demo 三段全是算术：TB→TiB、RAID 有效容量、循环覆盖能存几天。 每个数都会在报方案时用上，一个都不能算错。

# 1) TB -> TiB
print(4 * 1e12 / (1024.0 ** 4))          # 3.64
# 2) RAID5 有效容量
def raid5(n, tb=8.0):
    return tb * (n - 1)
# 3) 循环覆盖
day = 16 * (4.0 / 8.0) * 86400 / 1e6     # 0.69 TB/天
print(24 / day)                          # 35 天

实跑输出：

--------------------------------------------------------------------
标称 4 TB 的硬盘，实际能存多少
--------------------------------------------------------------------
**这一节全是算术，但每个数都会让你在报方案时少翻一次车。**

**第一件事：TB 和 TiB 不是一回事。**

  **硬盘厂按十进制标：1 TB = 1000⁴ 字节。操作系统按二进制算：1 TiB = 1024⁴ 字节。**

  标称        系统显示      差
  --------------------------------------
  2 TB        1.82 TiB      9.1%
  4 TB        3.64 TiB      9.1%
  8 TB        7.28 TiB      9.1%
  16 TB       14.55 TiB     9.1%

  **每块盘都少 9.1%**，而且**这个差是固定的比例**，
  **不是「厂商偷工减料」**——两套单位的历史遗留问题。
  **报容量时一定要问清「你说的是 TB 还是 TiB」**，**差 9% 在 64 块盘的项目上就是 50 TB。**

**第二件事：RAID 让容量打折，但换来的是「坏一块盘不停机」。**

  方案        有效容量        能坏几块  适用
  ----------------------------------------------------------
  3 块 RAID5  16 TB（2×8）    1 块      通用
  4 块 RAID5  24 TB（3×8）    1 块      通用
  8 块 RAID5  56 TB（7×8）    1 块      通用
  8 块 RAID6  48 TB（6×8）    2 块      大项目
  8 块 JBOD   64 TB           0 块      不推荐

  **RAID5 的代价是「一块盘的容量」**：8 块盘只能用 7 块。
  **RAID6 是两块**，换来的是「重建时再坏一块也不丢数据」。
  **监控为什么普遍用 RAID5 而不是 RAID6**：盘多、写入连续、**而且监控数据丢一段通常可接受**，
  不值得为它多付一块盘。

**第三件事：循环覆盖。**

  **监控存储不是「写满就停」，是「写满就把最老的覆盖掉」。**
  **所以「能存多少天」= 有效容量 ÷ 每天写入量，而不是「能存多久」。**

  有效容量      每天写入      实际能存
  --------------------------------------------
  24 TB         0.69 TB       35 天
  48 TB         0.69 TB       69 天
  120 TB        0.69 TB       174 天

  **第二列是 16 路 4 Mbps 一天的写入量**：16 × 0.5 MB/s × 86400 秒，**算出来 0.69 TB。**
  **所以 24 TB 能存 35 天**，刚好够「存 30 天」；**要正好卡住 30 天，得 21 TB。**
  **这就是为什么「存 30 天」的项目报价会吓人一跳**——**不是设备贵，是硬盘按天乘出来的。**

Python 的乘方是两个星号，不是 ^：1024^4 在 Python 里是异或，结果差得离谱，而且不报错。 每天写入量那个式子里 16 和 4 是路数和码率， 改成别的项目就要跟着改——这就是为什么该写成函数。

30 秒实验

  1. 把盘换成 16 TB，重算 RAID5 的有效容量，看块数能不能少一点。
  2. 把天数换成 90，算需要多少块 8 TB 盘（记得凑 RAID5 最小盘数）。
  3. 把码率换成 2 Mbps，重算 24 TB 能存几天。

常见误区

  1. 以为 4 TB 就是 4096 GB。 系统按 1024 算，实际显示 3.64 TiB。
  2. 以为 RAID5 两块盘就能做。 最少三块，两块盘没有冗余空间。
  3. 以为「能存 30 天」就是买够 30 天的容量。 还要打 RAID、格式化、余量三道折。
自测三问（点开对答案） 1. 为什么 4 TB 的盘在系统里显示 3.64 TiB？ —— 厂用十进制（1000⁴），系统用二进制（1024⁴），**比例固定差 9.1%**。 2. 8 块 8 TB 做 RAID5，有效容量多少？ —— 56 TB。**只能用 7 块，一块做校验**。 3. 能存多少天怎么算？ —— 有效容量 ÷ 每天写入量。**每天写入量 = 路数 × 码率 ÷ 8 × 86400。**

下一节回到代码：用 FFmpeg 连一台网络摄像头。

相关笔记