关于91视频，我把缓存管理讲清楚后，很多问题都通了
很多用户和产品同事遇到的问题其实都是缓存出了状况：播放卡顿、占用存储爆表、离线包找不到或重复、清理后又慢……把缓存管理理顺，很多问题自然迎刃而解。下面把缓存从概念到实践、从前端到后台、从用户体验到运维监控，系统地讲清楚，供产品、开发和运维参考并直接落地。
一、先把概念说清楚：缓存是什么、为谁服务
- 临时缓存（Temp/Streaming Cache）：为了播放而缓存的视频片段或流式缓冲，短期保留，重启或长时间不访问可以删除。
- 离线缓存（Download/Offline Cache）：用户主动下载以便离线观看，通常有保留策略、管理界面和权限控制。
- 元数据/索引缓存：播放位置、清单、分段索引、用户观看进度等，体积小但访问频繁。
- CDN/边缘缓存：服务器侧缓存，减少源站压力，提升首屏和切片载入速度。
理解这些差别后，可以把不同策略分层设计：临时缓存偏快速、低持久性，离线缓存则需要明确生命周期、用户可控。
二、常见问题与本质原因（对症下药）
- 存储猛涨、用户抱怨手机空间被占：通常是离线下载不受限、分片重复、旧版本文件残留或日志级别过高。
- 播放中途卡顿但网络良好：可能是缓存分片过大、预取不足或ABR策略切换频繁造成缓存碎片。
- 清理缓存后首播慢且消耗流量：没有区分临时缓存与离线缓存，清理过度，导致必须重新下载高延迟请求。
- 更新后偶发播放失败：老缓存格式与新播放器不兼容、索引未版本化导致读取错误。
三、设计准则（易于落地的原则）
- 按类别分存：临时缓存和离线缓存存放位置不同、命名与元信息不同，便于管理和回收。
- 限额与清理策略并行：为不同缓存设置合理上限（见建议值），超过触发LRU或时间驱逐。
- 用户可见与可控：显示占用空间、提供一键清理和按内容删除，离线内容应有到期/管理界面。
- 差异化网络策略：Wi‑Fi允许更积极预取与离线下载，移动网络下限制自动下载与预取幅度。
- 兼容与版本化：在缓存文件里写入版本和元信息，升级时可平滑迁移或清理不兼容内容。
- 监控与告警：监控缓存增长速度、异常IO错误、清理失败、磁盘满等并告警。
四、具体实现建议（移动端/客户端）
- 缓存分区与命名
- /cache/streaming/：临时分段、自动清理
- /cache/offline/{userId}/：离线包，按用户或账户隔离
- /cache/meta/：小文件，JSON索引
- 容量上限（参考值，可根据产品调整）
- 临时缓存：100–300MB（手机端）——用于流媒体缓冲
- 离线缓存：按单片或单集限额，比如每个用户最大2–4GB，或按内容计费/订阅策略
- 元数据：10–50MB
- 驱逐策略
- 临时：基于LRU，优先删除最久未访问分片；在播放时优先保留当前播放窗口前后若干分段。
- 离线：默认不过期，支持用户设置“自动删除未播放X天的离线内容”或按订阅有效期。
- 技术栈建议（Android/iOS/Web）
- Android：使用ExoPlayer + SimpleCache（配合 LeastRecentlyUsedCacheEvictor）或OkHttp缓存；大文件用 DiskLruCache 做索引管理；后台清理用 WorkManager/JobScheduler。
- iOS：AVFoundation 自定义资源加载器，缓存文件采用沙箱目录分区，使用NSFileCoordinator和后台任务进行清理。
- Web/PWA：Service Worker + Cache Storage 做离线资源，IndexedDB 存小文件和索引；避免把大文件直接放入Cache Storage（会导致浏览器占用不可控）。
- 断点续传与分段下载
- 对离线下载使用分段并记录每段状态，出错可重试单段而不重下整片，提高效率。
- 对流式播放采用小分段（例如2–4s）的fragment，便于ABR切换与缓存复用。
- 验证与一致性
- 离线缓存加入校验码（hash）或etag，更新时对比选择替换/保留。
- 在播放器启动或版本变更时，校验缓存索引，出现不一致则安全回退或修复。
五、后台与CDN配合
- 使用合理的Cache-Control和ETag，客户端可快速判断是否需要刷新索引或分片。
- 将常用清单和热门分段推至边缘节点，减少首播延迟。
- 对热点内容做分层存储：热度高的缓存保留时间更长，冷内容自动淘汰。
- 为离线下载提供预签名URL与短期许可，便于安全与过期控制。
六、用户体验细节（减少投诉的关键）
- 在设置里显式展示缓存占用：临时缓存和离线缓存分开展示，并提供逐项删除。
- 提供“仅Wi‑Fi下载”开关、下载质量选择（低/中/高清）和单集大小预览。
- 在存储不足时弹出建议（例如清理临时缓存或删除旧离线内容），并给出一键清理选项。
- 对正在下载或播放的内容显示进度和剩余存储估算，避免用户误操作。
七、故障排查清单（开发与运维）
- 播放卡顿：检查缓存命中率、分段大小、ABR策略、磁盘IO和GC情况。
- 存储暴涨：列出文件目录按时间、大小排序，找出异常目录或文件类型（日志、大临时文件、重复分片）。
- 更新后播放异常：确认缓存版本号、索引格式是否兼容，回滚到旧版本测试。
- 用户报告无法下载：检查后台签名URL有效期、权限、服务器返回码和客户端超时设置。
八、落地Checklist（可直接交付给开发）
- [ ] 将缓存按类别分区并实现命名规范
- [ ] 实现基于LRU的临时缓存驱逐器，设置默认上限
- [ ] 离线下载支持分段、断点续传和元信息版本化
- [ ] UI 增加缓存管理页（显示占用、逐项删除、一键清理）
- [ ] 增加“仅Wi‑Fi下载”和下载质量控制
- [ ] 后台增加缓存监控：大小、增长速率、IO错误
- [ ] CDN 配置 Cache-Control/ETag 策略并推热内容到边缘
- [ ] 在版本升级时加入缓存迁移或清理逻辑
结语 对91视频这类以视频为核心的产品来说，缓存不是一个“可选项”，而是用户体验和产品稳定性的基石。把缓存按功能分层、按策略管理、把控制权交给用户，并配合后台/CDN 的合理设计，很多表面上的问题都会在根源处被解决。把上面的Checklist和实现建议交给开发和运维，短期内就能看到播放流畅度、存储使用和用户投诉率的明显改善。希望这套思路能帮你把那些“摸不着头脑”的问题都捋通。
