跳转至

经典案例：网盘与海量文件存储系统 (Google Drive / Dropbox)

网盘（如 Google Drive, Dropbox, 百度网盘）是系统设计面试中针对大文件处理、海量数据吞吐、存储与网络优化的经典题目。

初学者往往最感好奇的是：为什么一个 10GB 的高清电影文件，在百度网盘里点击上传后，1 秒钟就显示“上传完成”（秒传）？家里网络突然断开重连后，为什么可以接着之前的进度继续上传（断点续传）？

1. 初学者视角：传统文件上传方案的致命瓶颈

在最朴素的 Web 开发中，文件上传通常是这样的：

graph LR
    A[客户端浏览器] -->|HTTP POST 整个 10GB 文件流| B[业务应用服务器]
    B -->|代存文件到磁盘| C[(本地硬盘 / NAS)]

这种朴素设计在网盘规模下有三个致命问题： 1. 应用服务器内存与网卡瞬间爆满：1000 个用户同时上传大文件，应用服务器的入站带宽（Inbound Bandwidth）和内存会瞬间被消耗殆尽，导致整个网站所有 API 瘫痪； 2. 容错能力极差：如果上传到 99% 时网络抖动断开，整个 10GB 文件必须从 0% 完全重新上传； 3. 存储成本极其高昂：如果 1 万个用户各自上传了同一部热门电影，服务器就要重复保存 1 万份相同的 10GB 文件，白白浪费 100TB 的高昂存储空间！

2. 需求分析与系统范围 (Requirements & Scope)

2.1 功能性需求

  1. 文件上传与下载：支持各种大小的文件（从几 KB 的文档到几十 GB 的视频）；
  2. 秒传与去重 (Instant Upload & Deduplication)：若云端已有相同文件，用户无需耗费流量重复上传；
  3. 断点续传 (Resumable Upload)：网络中断后，重新连接能从上次中断的位置继续传输；
  4. 增量同步 (Delta Sync)：修改已有文件时，只传输修改的部分数据块，而非整个文件；
  5. 文件目录树与元数据管理：支持文件夹层级、重命名、移动、删除与回收站。

2.2 非功能性需求

  1. 极致的数据可靠性 (Data Durability - 11 个 9: 99.999999999%)：用户存入的文件绝对不能丢失或损坏；
  2. 高并发与低传输延迟：充分利用用户端本地带宽，上传与下载速度达到极限；
  3. 强一致性 (Strong Consistency for Metadata)：用户在一台设备修改了文件，其他设备看到的目录状态必须保持一致。

3. 容量估算 (Back-of-the-Envelope Estimation)

  • 总注册用户数：设为 1 亿，日活跃用户 (DAU) 约为 1000 万；
  • 平均每人每天上传文件数：平均每人每天上传 2 个新文件，平均文件大小为 \(20\text{ MB}\)；
  • 每日新增原始数据量：
\[ 10^7 \times 2 \times 20\text{ MB} = 400\text{ TB} \]

若考虑去重技术（工业界网盘去重率通常高达 30%~50%），实际每日新增物理存储约为 200 ~ 280 TB/天。 - 上传网络带宽估算：

\[ \text{Bandwidth} = \frac{400\text{ TB} \times 8\text{ bits}}{86,400\text{ s}} \approx \frac{3.2 \times 10^{15}\text{ bits}}{8.64 \times 10^4\text{ s}} \approx 37\text{ Gbps} \]

高峰期网络带宽可达 70 ~ 100 Gbps。

4. 核心架构设计：元数据与文件数据彻底分离

面对如此庞大的流量和存储，现代云存储架构的最核心秘诀是：元数据（Metadata）与二进制数据块（Block Data）物理彻底分离，应用服务器绝不代传文件字节流！

graph TD
    Client[客户端 App / 浏览器]

    subgraph "控制面 (元数据层 - 轻量高效)"
    APIGW[API 网关]
    MetaService[元数据服务]
    MetaDB[(元数据库: MySQL / TiDB)]
    end

    subgraph "数据面 (海量对象存储 - 高吞吐)"
    S3[(分布式对象存储: Amazon S3 / MinIO / Ceph)]
    end

    Client -->|1. 查询文件指纹/申请上传| APIGW
    APIGW --> MetaService
    MetaService --> MetaDB
    MetaService -->|"2. 返回预签名上传 URL (Presigned URL)"| Client

    Client ==>|"3. 客户端直接向对象存储上传数据块 (绕过应用服务器)"| S3
    Client -->|4. 上传完毕, 通知元数据服务合成分块| MetaService

为什么客户端直接直传对象存储（Presigned URL）？

  • 预签名 URL（Presigned URL）：应用服务器通过自己的私钥生成一个带有临时签名和有效期的专属上传链接，交给客户端；
  • 客户端拿着这个链接直接与 Amazon S3 / 阿里云 OSS 建立长连接传输数据；
  • 巨大收益：
  • 应用服务器只负责轻量的权限检查和元数据记录（每秒几十字节），CPU 和网络极其轻松；
  • 充分释放了云对象存储极高的并行带宽（单桶支持数十 Gbps 吞吐）。

5. 核心难点深度剖析 (Deep Dive)

5.1 文件分块 (Chunking) 与内容哈希 (Content-Defined Hash)

系统绝对不会把一个 10GB 的大文件当作一个单一整体来处理，而是会将其切分为若干个固定大小的数据块（Block / Chunk）（工业界常用大小为 4MB）。

+-----------------------------------------------------------------------------+
|                               10 GB 原始大文件                               |
+-----------------------------------------------------------------------------+
   |                  |                  |                  |             |
+----------+       +----------+       +----------+       +----------+    ...
| Block 1  |       | Block 2  |       | Block 3  |       | Block 4  |
|  (4 MB)  |       |  (4 MB)  |       |  (4 MB)  |       |  (4 MB)  |
+----------+       +----------+       +----------+       +----------+
   |                  |                  |                  |
SHA256: 3a9f...    SHA256: 7b01...    SHA256: e8d4...    SHA256: 11c9...
  1. 分块计算指纹：客户端在本地将文件按 4MB 切割，并计算每一个数据块的 SHA-256 哈希值；
  2. 块级寻址（Content-Addressable Storage）：数据块存入对象存储时的文件名，就是它的 SHA-256 哈希值！只要内容相同，哈希值就绝对相同。

5.2 “秒传”与“去重”的底层原理 (Deduplication)

所谓的“秒传”，本质上是利用内容哈希进行查重，直接复用已有数据块。

sequenceDiagram
    participant C as 客户端
    participant S as 元数据服务
    participant DB as 元数据库 (MySQL)
    participant S3 as 对象存储 (S3)

    C->>C: 本地计算文件整体 SHA-256: "abc...123"
    C->>S: 1. 发起上传请求: FileHash = "abc...123", Name = "movie.mp4"
    S->>DB: 2. 查询: 数据库中是否存在 hash = "abc...123" 的记录?
    alt 数据库已存在该文件 (触发秒传!)
        DB-->>S: 存在! 该文件已有物理存储引用
        S->>DB: 3. 在用户文件表新增一条记录 (指向同一个物理文件 ID)
        S-->>C: 4. 秒传成功! (客户端界面瞬间显示 100%)
    else 数据库不存在 (首传文件)
        DB-->>S: 不存在
        S-->>C: 5. 允许上传, 返回各分块的 Presigned URL
        C->>S3: 6. 客户端逐块上传数据 (耗费真实带宽)
    end

[!TIP] 多层哈希优化：为了避免计算 10GB 文件的完整 SHA-256 导致客户端卡顿，通常采用前 256KB 预哈希 + 完整哈希两级校验。若前 256KB 的哈希都不匹配，直接判定为全新文件，无需等待全量计算完成。

5.3 断点续传的实现机制 (Resumable Upload)

网络传输中发生断网或用户主动暂停时，如何实现从断点继续？

  1. 初始化上传会话 (Upload Session)：
  2. 客户端向服务端发起初始化，服务端生成一个唯一的 upload_id，并在元数据库中创建上传会话；
  3. 并行上传分块：
  4. 客户端同时并发上传多个 4MB 数据块（例如同时上传 Block 1, Block 2, Block 3）；
  5. 客户端本地记录上传成功的分块编号；
  6. 断网重连与状态同步：
  7. 网络恢复后，客户端发送 upload_id 向服务端发起心跳询问：GET /upload/status?upload_id=xxx；
  8. 服务端返回当前已经成功接收并校验落盘的分块列表（例如：[1, 2, 4]）；
  9. 客户端比对后发现仅缺少 Block 3 和后续块，只重新上传未完成的块，无缝恢复进度。

5.4 增量更新与版本控制 (Delta Sync)

如果用户编辑了一份 500MB 的文档，仅仅修改了其中 2 行文字： - 如果没有分块，需要重新上传整个 500MB 文件； - 引入分块机制后：只有包含这 2 行文字的那一个 4MB 数据块的哈希值发生了改变，其他 124 个数据块的哈希值完全未变！ - 客户端仅上传那 1 个发生改变的 4MB 数据块，元数据服务更新该文件新版本的“分块索引映射表”。上传流量直接节省了 \(99\%\)！