设计一个支持百万级用户、高并发文件上传的系统（如万兴视频编辑中的视频上传功能），需要考虑限流、分片上传、断点续传、存储优化（如对象存储）、负载均衡等，请详细说明系统架构和关键技术点。
万兴科技后端开发难度：中等
答案
1) 【一句话结论】
针对百万级用户高并发视频上传场景，系统采用分布式限流、分片+断点续传、对象存储（如阿里云OSS）+负载均衡的架构，通过多维度技术优化，保障高可用、高并发、高可靠的上传能力，核心是通过分片降低单次请求负载，断点续传提升用户体验，限流避免系统过载，负载均衡实现请求分发。
2) 【原理/概念讲解】
- 限流：采用令牌桶算法，按用户粒度控制请求速率。具体参数：时间窗口1秒，每用户每秒生成10个令牌（即允许每用户每秒10次上传请求）。类比：交通信号灯，限制每个用户每秒通过的车辆数，避免系统因突发流量崩溃。当用户请求时，从令牌桶获取令牌，若令牌不足则返回429错误或排队，确保系统资源不被耗尽。
- 分片上传：将大文件拆分为1-5MB的小分片（工程中通常选择4MB，平衡内存占用和网络开销）。每个分片包含唯一任务ID、分片索引（0-based）、分片大小、总分片数、文件名、内容类型、分片MD5校验值。服务器接收分片后，先校验分片MD5（与客户端计算的值比对），若校验失败则丢弃并提示重传；校验通过后，存储到对象存储（如OSS），并更新数据库中的上传进度（如
upload_id的已上传分片数）。 - 断点续传：客户端标记上传进度（如
upload_id+已上传分片数），服务器通过Redis或数据库持久化进度。若上传中断，下次从断点继续。冲突处理：若客户端标记的进度与服务器记录不一致（如客户端崩溃后重置标记），服务器通过任务ID查询最新进度，避免重复上传。例如，客户端标记已上传3个分片，服务器记录为2个，则从第3个分片开始上传。 - 对象存储：使用分布式存储（如阿里云OSS），存储文件内容，元数据（文件名、分片信息、上传状态）存储在数据库（如MySQL）或缓存（如Redis）。启用版本控制，文件覆盖时保留旧版本（通过元数据版本号或MIME类型区分），用户可恢复旧版本，避免数据丢失。
- 负载均衡：通过Nginx等分发请求到后端节点。对于文件上传，通过上传任务ID关联会话（即使是无状态负载均衡，也将任务ID存入Redis），确保会话中断后进度可恢复。例如，客户端上传时，将任务ID存入Redis，负载均衡器根据任务ID将后续请求路由到同一节点，避免进度丢失。
3) 【对比与适用场景】
| 特性 | 分片上传（大文件） | 单文件上传（小文件） |
|---|---|---|
| 定义 | 文件拆分为多个分片上传 | 直接上传完整文件 |
| 特性 | 支持断点续传、分片校验 | 简单，无断点续传支持 |
| 使用场景 | 视频、图片等大文件（>10MB） | 头像、文档等小文件（<5MB） |
| 注意点 | 需处理分片顺序、完整性校验 | 无 |
4) 【示例】（分片上传请求示例，伪代码）
客户端将文件分片，每个分片包含：
{
"upload_id": "task_20240101_001", // 上传任务唯一ID（由客户端生成，全局唯一）
"chunk_index": 0, // 分片索引（从0开始，表示第几个分片）
"chunk_size": 4 * 1024 * 1024, // 分片大小（4MB，工程中通常为1-5MB）
"total_chunks": 8, // 总分片数（文件总大小/分片大小，向上取整）
"file_name": "video.mp4", // 文件名
"content_type": "video/mp4", // 内容类型
"md5": "d41d8cd98f00b204e9800998ecf8427e", // 分片MD5校验值（客户端计算后发送）
"progress": 0 // 已上传分片数（客户端标记的进度，用于断点续传）
}
服务器接收分片后，处理流程：
- 校验
upload_id是否有效（数据库中存在该任务）。 - 计算分片预期MD5（服务器端重新计算），与客户端发送的
md5比对，若不一致则丢弃并返回错误。 - 存储分片到对象存储（如OSS，路径为
/uploads/{upload_id}/{chunk_index}）。 - 更新数据库中的
upload_id记录，增加已上传分片数（如从0变为1）。 - 当所有分片上传完成后，服务器计算总MD5（所有分片MD5拼接后计算），与客户端上传前计算的总MD5比对，若一致则合并分片（按索引顺序拼接），生成最终文件，并更新数据库为“完成”状态。
5) 【面试口播版答案】
面试官您好，针对百万级用户高并发视频上传，我设计的系统核心是分布式架构，通过限流控制请求速率，分片上传+断点续传处理大文件，对象存储（如阿里云OSS）存储文件，负载均衡分发请求。具体来说，限流采用令牌桶算法，按用户粒度限流（时间窗口1秒，每用户每秒10个令牌），避免全局限流影响正常用户。分片上传将文件切分成4MB的小块，每个分片包含任务ID、索引、MD5校验值，服务器校验后存储，断点续传通过Redis记录客户端标记的进度（如upload_id+已上传数），下次从断点继续。对象存储启用版本控制，文件覆盖时保留旧版本。负载均衡器通过上传任务ID关联会话（将任务ID存入Redis），确保会话中断后进度可恢复。这样能应对百万级并发，保证上传成功率。
6) 【追问清单】
- 问题1：限流的具体实现细节？
回答要点：采用令牌桶算法，时间窗口1秒，每用户每秒生成10个令牌，请求时检查令牌桶，不足则返回429错误或排队。 - 问题2：分片上传的完整性校验如何处理？
回答要点：每个分片计算MD5校验值，服务器端重新计算并比对，若不一致则丢弃并提示重传，确保分片完整性。 - 问题3：断点续传的进度持久化方案？
回答要点：使用Redis存储上传进度（upload_id->已上传分片数），确保服务器重启后进度不丢失，客户端标记与服务器记录不一致时，服务器通过任务ID查询最新进度。 - 问题4：对象存储版本控制的作用？
回答要点：文件覆盖时保留旧版本（通过元数据版本号），用户可恢复旧版本，避免数据丢失，提升数据可靠性。 - 问题5：负载均衡的会话保持如何实现？
回答要点：对于文件上传，通过上传任务ID关联会话（将任务ID存入Redis），即使使用无状态负载均衡（如Nginx的ip_hash），也能保证会话中断后进度可恢复。
7) 【常见坑/雷区】
- 分片大小设置不当：过大（如5MB分片，100MB文件需20个分片，服务器内存占用过高），过小（如1MB分片，100MB文件需100个分片，网络传输次数增加，延迟上升）。工程中通常选择4MB，平衡内存和网络开销。
- 断点续传标记丢失：客户端标记依赖本地状态，若客户端崩溃，标记丢失导致重传整个文件。可通过服务器端状态持久化（如Redis）解决，确保进度不丢失。
- 限流策略全局 vs 按用户：全局限流可能影响正常用户（如正常用户被限流导致上传失败），需按用户粒度限流，避免影响用户体验。
- 对象存储版本控制缺失：文件覆盖后旧版本无法恢复，可能导致用户数据丢失。需启用版本控制，通过元数据版本号区分，支持用户恢复。
- 负载均衡会话保持问题：若使用无状态负载均衡（如Nginx的ip_hash），需额外存储上传进度（如Redis），否则会话中断后进度丢失，影响断点续传功能。