# 断点续传与内存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（配置持久化）
- ✅ 效果：页面刷新和服务器重启都可以恢复

---

## 📚 相关文档

- [详细架构说明](./resume-upload-architecture.md)
- [流程图说明](./resume-upload-flowchart.md)
- [内存Map vs Redis说明](./upload-sessions-redis-explanation.md)