3.8 KiB
3.8 KiB
断点续传与内存Map/Redis的关系 - 简明总结
🎯 核心关系
断点续传 = 前端IndexedDB + 后端uploadSessions（内存Map/Redis）
📊 两者对比
| 项目 | 前端（IndexedDB） | 后端（内存Map/Redis） |
|---|---|---|
| 存储内容 | 上传进度（哪些块已上传） | 上传会话（哪些块已存储，存储在哪里） |
| 作用 | 客户端恢复、跳过已上传块 | 服务器验证、文件管理、权限控制 |
| 数据来源 | 网络请求成功 | 实际文件写入 |
| 持久化 | ✅ 浏览器持久化 | 内存Map: ❌ / Redis: ✅ |
| 恢复能力 | ✅ 页面刷新可恢复 | 内存Map: ❌ 重启丢失 / Redis: ✅ 重启可恢复 |
🔄 工作流程
正常上传
1. 前端：初始化上传 → 后端：创建会话（内存Map/Redis）
2. 前端：上传块1 → 后端：保存块文件，更新会话
3. 前端：更新IndexedDB（记录块1已上传）
4. 前端：上传块2 → 后端：保存块文件，更新会话
5. 前端：更新IndexedDB（记录块1,2已上传）
6. ... 继续上传
7. 完成：前端删除IndexedDB，后端合并文件
页面刷新恢复
1. 前端：检查IndexedDB → 找到记录（块1,2已上传）
2. 前端：跳过块1,2，从块3开始上传
3. 后端：检查会话（内存Map/Redis）→ 找到会话
4. 后端：保存块3，更新会话
5. ✅ 成功恢复，继续上传
服务器重启（内存Map）
1. 服务器重启 → 内存Map数据丢失 ❌
2. 前端：尝试上传块3
3. 后端：检查会话 → 找不到会话 ❌
4. 前端：重新初始化上传
5. ❌ 无法恢复，需要重新上传
服务器重启（Redis）
1. 服务器重启 → Redis数据保留 ✅
2. 前端：尝试上传块3
3. 后端：从Redis读取会话 → 找到会话 ✅
4. 后端：保存块3，更新Redis
5. ✅ 完美恢复，继续上传
💡 关键理解
1. 前端IndexedDB
- 作用：记录上传进度，页面刷新后可恢复
- 内容：哪些块已上传（基于网络请求成功）
- 持久化：浏览器本地存储，不会丢失
2. 后端uploadSessions
- 作用：验证上传会话，管理文件，权限控制
- 内容：哪些块已存储，存储在哪里（基于实际文件写入）
- 持久化：
- 内存Map：进程重启丢失 ❌
- Redis：可配置持久化 ✅
3. 两者配合
- 前端记录进度 → 客户端知道上传进度
- 后端记录会话 → 服务器知道上传状态
- 双重保障 → 前端和后端都有记录
- 断点续传 → 两者配合实现完整功能
4. 内存Map vs Redis的影响
-
内存Map：
- 服务器重启 → 数据丢失 → ❌ 无法恢复
- 前端可以恢复，但后端无法验证
- 适合单实例部署、开发测试环境
-
Redis：
- 服务器重启 → 数据保留 → ✅ 可以恢复
- 前端和后端都可以恢复
- 适合生产环境、多实例部署
🎯 总结
关系
断点续传功能 = 前端IndexedDB（客户端恢复） + 后端uploadSessions（服务器验证）
当前实现
- ✅ 前端：IndexedDB（浏览器持久化）
- ✅ 后端：内存Map（进程内存，重启丢失）
效果
- ✅ 页面刷新可以恢复（前端IndexedDB）
- ❌ 服务器重启无法恢复（后端内存Map丢失）
生产环境建议
- ✅ 前端：继续使用IndexedDB
- ✅ 后端：迁移到Redis（配置持久化）
- ✅ 效果：页面刷新和服务器重启都可以恢复