HLS存储瓶颈分析

当单台服务器存储超过50万TS文件时，EXT4文件系统的inode使用率可达95%以上（实测数据）。某CDN边缘节点曾因inode耗尽导致服务中断12分钟，此时df -i显示利用率达100%，但磁盘空间剩余70%。

目录结构优化对比

传统扁平化结构

/videos
  ├── video1_000.ts
  ├── video1_001.ts
  └── ...(50万+文件)

分片目录结构（2级哈希）

/videos
  ├── a1
  │   ├── b2
  │   │   └── video1_000.ts 
  │   └── b3
  │       └── video1_001.ts
  └── a2
      └── b4
          └── video1_002.ts

测试环境（内核5.4.0-91）：

1. find /videos -name "*.ts"执行时间
2. 扁平结构：4.7秒
3. 分片结构：0.3秒
4. iostat -x 1显示平均await值
5. 扁平结构：12.3ms
6. 分片结构：3.1ms

分片算法实现

def get_storage_path(video_id: str, seq: int, depth=2, width=16):
    """
    生成分片存储路径
    :param video_id: 视频唯一标识
    :param seq: TS文件序号
    :param depth: 目录层级深度
    :param width: 每层目录数量
    :return: 物理存储路径
    """
    hash_str = hashlib.md5(f"{video_id}_{seq}".encode()).hexdigest()
    path_parts = []

    for i in range(depth):
        start = i * 2
        end = start + 2
        path_parts.append(hash_str[start:end])

    return os.path.join(*path_parts, f"{video_id}_{seq:05d}.ts")

内存优化计算模型

内存占用公式：

总内存 ≈ (目录项大小 × 分片数) + (缓存条目 × 元数据大小)

推荐配置： - 每层目录不超过256个子项（EXT4性能拐点） - 元数据缓存TTL设置为30秒 - 采用LRU策略缓存最近1万条记录

Nginx配置优化

location ~ ^/videos/([a-f0-9]{2})/([a-f0-9]{2})/(.*\.ts)$ {
    root /data/hls;
    access_log off;
    expires 30d;

    # 内核4.19+推荐配置
    sendfile_max_chunk 512k;
    directio 4k;
}

生产环境避坑指南

1. 文件系统选型
2. XFS：适合超百万文件，但需要mkfs.xfs -n ftype=1

3. EXT4：常规场景，需调大inode数量mkfs.ext4 -N 5000000

4. 监控指标

   # 监控inode使用率（适用于所有Linux版本）
   watch -n 60 "df -i | grep hls"
   
   # 监控目录项缓存（内核4.15+）
   grep dentry /proc/slabinfo

5. 性能调优参数

   # /etc/sysctl.conf
   vm.vfs_cache_pressure = 50
   fs.file-max = 1000000

延伸思考

当使用S3等对象存储时： 1. 如何将哈希分片策略映射为虚拟路径？ 2. 目录结构对ListObjects API调用成本的影响？ 3. 预热策略与CDN边缘节点缓存的关系？