Volume是大文件流处理首选持久化方案，因其由Docker统一管理、支持预填充、允许多容器共享，配合tmpfs处理中间态、优化挂载选项及应用层断点快照，可兼顾高性能、可靠性与状态恢复。
大文件流处理对 Docker 持久化方案提出明确要求：既要保证高吞吐 I/O 性能，又要避免内存溢出或数据丢失，同时需兼顾容器重启后状态可恢复。关键不在于“能不能存”，而在于“怎么存得稳、读得快、切得准”。
选 Volume 而非 Bind Mount 做主存储路径
大文件（如视频分片、日志归档包、模型权重文件）写入频繁、体积大、生命周期长，必须用命名卷（Volume）而非绑定挂载（Bind Mount）：
- Volume 由 Docker 管理，底层路径统一在 /var/lib/docker/volumes/，规避宿主机路径权限混乱（比如 Ubuntu 下 MySQL 容器因 UID 不匹配无法写入 /data 目录）
- Volume 支持预填充：首次挂载空卷到容器内目录（如 /app/uploads），原目录下已有的模板文件或结构会自动复制进卷中，适合流处理前的初始化校验
- 多个 worker 容器可共享同一卷，实现分块读取、并行转码、结果归集等典型流式协作场景
用 tmpfs + Volume 组合应对临时中间态
流处理常含“解压→解析→转换→暂存→合并”链路，其中中间产物（如解压后的原始帧、临时索引表）无需落盘，但又不能全塞内存——此时应分层设计：
- 用 --tmpfs /app/tmp:rw,size=2g,mode=1777 挂载内存文件系统，供应用快速写入/读取中间缓冲区
- 将最终输出（如 MP4 成品、JSON 分析报告）写入 Volume 挂载的持久路径（如 /app/output），确保容器崩溃或重启后成果不丢
- 避免把 tmpfs 当主力：它只适用于 Linux，且容器停止即清空；不可用于保存 checkpoint 或 offset 位点信息
配置挂载选项提升大文件 I/O 效率
默认挂载方式在处理 GB 级文件时易成瓶颈，需显式优化：
- 添加 :z 或 :Z SELinux 标签（仅限 RHEL/CentOS），允许容器进程访问卷内容
- 使用 --mount 替代 -v，支持更细粒度控制，例如：
--mount type=volume,source=media_vol,destination=/app/media,consistency=cached
其中 consistency=cached 在 macOS 和 Windows Docker Desktop 上启用客户端缓存，显著加速顺序读写 - 对高频随机访问场景（如数据库 WAL 日志+流式特征提取共存），建议在宿主机侧使用 XFS 文件系统并开启 inode64 选项，避免单目录下海量小文件性能衰减
配合应用层做断点续传与状态快照
持久化只是基础，流处理真正可靠依赖容器内外协同：
- 在 Volume 中固定位置（如 /app/.checkpoint/）保存处理进度（文件偏移量、批次 ID、时间戳），应用启动时优先读取该状态决定从哪继续
- 用 docker exec -it my-streamer ls -lh /app/.checkpoint/ 可人工验证断点有效性
- 避免依赖容器内 PID 或临时路径做状态记录——这些随重启失效；所有关键状态必须落进 Volume 挂载的路径
