直播时移与回看业务的存储设计，最实用的方案是冷热分层热数据放SSD保证并发吞吐，冷数据迁移到HDD或对象存储降低成本。这个思路不是新东西，但放在“时移和回看”这个场景下，很多人容易走偏：要么图省事全上SSD，预算爆炸；要么一刀切全塞HDD，用户一拖进度条就转圈，下面从访问特征、分层策略、迁移机制到实际部署，把这件事说透。
直播时移回看存储方案：为什么必须做冷热分层？
时移和回看的访问特征完全不同
直播时移是“向后看”，比如你看球赛正在直播，想回看刚才那个进球，拖回去30秒，这种请求集中发生在直播进行时和结束后1小时内，数据量不大，但并发极高，且要求毫秒级出画面。
回看则是“点播过去”，用户主动选择某场节目、某期综艺，它的热度曲线衰减得极快：当天访问量占大头，过了一周基本只剩零星请求，但问题是，回看的周期很长，很多平台要求保留30天甚至90天。
把这两种数据混在一起存,是最常见的错误，时移数据需要低延迟，回看数据更看重容量，如果都用同样的存储介质，要么性能过剩，要么容量不足。
全热存扛不住成本，全冷存又卡顿
业内专家指出,在多数IPTV和网络直播平台里，最近24小时产生的数据只占全部存储量的10%左右，却承担了超过80%的访问压力，如果把这10%的数据放在高性能SSD上，剩下的历史冷数据放到大容量机械硬盘或对象存储里，成本和体验就能同时兼顾。
反之,如果全用SSD，一个百万用户的回看平台，存储成本会高得让项目直接亏损，如果全用HDD，时移秒级响应根本做不到机械硬盘的随机读性能摆在那里，并发一高，磁盘队列就塞满了，画面必然卡顿。
行业共识认为,冷热分层的核心价值就是把有限的预算花在刀刃上，用不到20%的存储成本换来80%以上的热请求体验。
时移回看冷热分层怎么做？分级标准与迁移策略
数据分级：按“时间窗口+访问频率”双重判定
不能只看文件大小或时间戳,要结合业务规则，推荐三级分层：
- 热数据：当前直播频道最近1-2小时的时移切片，以及近24小时内新增的回看节目，这个区间内的数据会被频繁拉取，必须放在NVMe SSD或高性能SATA SSD上。
- 温数据：过去3-7天的回看内容，用户还会偶尔点播，但并发压力明显下降，可以放到企业级HDD上。
- 冷数据：超过7天的历史回看，以及超过24小时的时移切片，这些数据基本只有长尾访问，直接归档到对象存储或蓝光库，保留90天甚至更久。
| 层级 | 存储介质 | 生命周期 | 典型用途 |
|---|---|---|---|
| 热层 | NVMe SSD / SATA SSD | 0-24小时 | 时移、当日回看 |
| 温层 | 企业级HDD | 3-7天 | 近期回看 |
| 冷层 | 对象存储（Ceph/MinIO） | 7-90天 | 历史归档 |
文件切片命名与冷热识别
时移回看普遍用HLS或DASH协议,文件是分片的，命名时习惯带上频道ID、日期、时间戳，
/live/{channel_id}/{yyyyMMdd}/{HHmm}_{seq}.ts
/record/{channel_id}/{yyyyMMdd}/{program_id}.ts这样做的好处是,定时扫描时只需要解析路径中的日期字段，就能直接判断数据属于哪个层，路径里的日期是3天前，但最后访问时间还在今天，说明这本文件可能被“救回来”了比如某个突发热点事件导致旧回看爆火，这种情况就要动态升级到热层。
迁移机制：从SSD到HDD再到对象存储
具体的执行流程,业内主流做法是：
- 写入阶段：直播流录制进程直接写入热区SSD，同时更新一张内存索引表，记录每个切片的“最后访问时间”。
- 扫描阶段：每隔5分钟启动一个定时任务，遍历索引表，筛选出满足迁移条件的文件，条件可以是“存放超过N小时”或“最后访问时间超过N小时”。
- 迁移动作：将文件从热区拷贝到温区，拷贝完成后删除热区原文件，再更新元数据，为了保证不丢数据，先用硬链接或引用计数，等确认新位置可读再删旧文件。
- 回源流程：用户请求时先查元数据，如果目标在冷层，直接从对象存储拉取，这个过程中可以用“异步提升”策略：首次从冷层读取后，把该文件复制一份到热层缓存，后续请求直接命中热层。
这里有一个容易被忽略的细节：迁移不能占用业务IO资源，建议在凌晨低峰期跑批量迁移，或者用独立的迁移任务队列，限制迁移带宽，避免和用户播放抢磁盘。
两层架构还是三层架构？
如果你的平台规模不大,也可以只做“热+冷”两层：热层用SSD，冷层用大容量HDD，小于50万用户的平台，两层就够了，没必要为了“看起来先进”硬上对象存储，三层架构更适合需要长期保留回看，且数据量达到PB级的场景。
冷层不一定非要用对象存储,对于纯本地部署的小型平台，直接用一台装了多块16TB HDD的服务器，配合按时间分目录的方式做冷区，成本也很低，对象存储的优势在于扩展性和跨机房容灾，但单机场景没有这个必要。
实际部署场景：从IPTV到网络电视台的降本套路
运营商IPTV平台的回看存储设计
IPTV最常见的业务形态是“直播+时移+回看”，用户量在百万级，并发回看请求往往集中在晚间黄金时段，很多运营商早期的做法是把所有直播和回看都放在同一个SAN存储池里，结果直播业务的高吞吐会拖累回看的随机读，反之亦然。
采用冷热分层后,比较合理的划分是：
- 直播录制缓冲区：独立出内存盘或NVMe盘，做最近10分钟的时移切片，通过DRAM缓存加速，这部分很小，占用几十GB就够。
- 当日回看热区：SATA SSD或NVMe SSD，存放当天所有频道的回看文件，供晚间高峰并发读取。
- 历史回看温区：企业级12TB HDD组成的存储节点，保留3-7天内容。
- 冷区对象存储：对接现有的云存储或自建Ceph集群，保留完整90天。
这样调整后,热区SSD的容量可以控制在总容量的5%左右，却能满足90%以上的播放请求，温区HDD虽然慢一点，但访问频率低，完全够用，冷区对象存储的每GB成本大概是SSD的十分之一。
直播平台的长尾回放管理
像一些泛娱乐直播平台,主播下播后的回放视频，用户会在深夜或第二天补看，刚下播的前6小时是访问高峰，之后迅速跌落，针对这个特点，可以在主播断流后把刚才的直播文件标记为“热”，优先放在SSD上；过了24小时自动降到HDD；如果超过7天没被访问，就迁移到对象存储，整个过程用脚本自动化，运维只负责监控迁移队列的长度。
小网站的轻量方案：rsync + crontab
如果你的平台只有几TB数据,没必要买商业存储软件，Linux服务器上就能做：用SSD挂载/data/hot目录，HDD挂载/data/cold目录，写一个crontab脚本，每小时的整点执行：
find /data/hot -type f -mtime +1 -exec rsync -av {} /data/cold/ ; -delete
这个命令会把热区中修改时间超过1天的文件同步到冷区,然后删除原文件，再写一个反向脚本，当用户访问冷区文件时，自动复制到热区作为缓存，这种“差不多够用”的方案，很多初创公司都在用。
冷热分层性能平衡：回看存储用什么硬盘最合适？
不同存储介质怎么选？
这里需要明确一点：冷热分层不是简单地把硬盘分两类，而是要匹配业务对延迟的容忍度。
- 时移请求,延迟要求低于500毫秒，必须用SSD，推荐NVMe盘，因为时移碎片多，需要随机读。
- 回看请求,首屏出画时间允许2秒左右，HDD完全可以胜任，但要注意HDD的转速和缓存，建议选7200转的企业级盘。
- 对象存储,本质上是“上传后不经常读”的档案室，用普通的SATA盘做成分布式集群即可。
避免踩坑：迁移时机的窗口选择
冷热迁移如果做得太频繁,会让磁盘一直在拷贝数据，反而拖累正常播放，建议：
- 热→温迁移只扫“最后访问时间”超过6小时的文件，且每个批次不超过总文件数的5%。
- 温→冷迁移放在每天凌晨3点到5点之间执行，错开晚高峰。
- 迁移过程中,要检查目标节点的剩余容量，如果温区满了，先做温区内部的临时扩容，不要强行把新文件塞进去。
关于直播时移回看存储冷热分层的常见问题
直播时移和回看数据能共用一套存储池吗？
可以,但必须分成两个独立的“逻辑卷”，时移数据的特点是“写多读少”，直播流会持续写入，而回看是“读多写少”，如果混在一个卷里，写入时移的IO会干扰回看读盘，建议给时移单独划分一块SSD和高速内存缓存，回看走独立的冷热分层池。
冷热分层会不会导致用户回看时卡顿？
正常设计下不会,因为迁移不是“把文件删掉”，而是“把文件移走”，用户请求时依然通过元数据定位到新位置，关键在于元数据服务要稳，建议用Redis或MySQL存储文件映射，查询耗时控制在1毫秒以内，从冷层回源对象存储时，首次访问会稍慢，但可以通过“边缘缓存预取”来解决热点节目提前推到最近的CDN节点。
小规模平台有必要做三层冷热分层吗？
没必要,三层分层会增加运维复杂度，你得维护对象存储节点、迁移任务、元数据同步，如果总数据量不到20TB，用“SSD热区+HDD冷区”两层就够了，甚至可以把整个热区压缩到几十GB，只缓存最近1小时的时移和当天的回看列表，过度设计才是真正的成本杀手。
最后说回结论：直播时移与回看存储的冷热分层，不是做不做的选择题，而是怎么做好的必答题，记住那个核心比例用少量的高性能盘承接绝大多数的活跃请求，剩下的大容量慢速盘负责历史沉淀，这个思路能让你在成本和体验之间找到最佳平衡点。