【网盘系统】设计核心

学习核心

• 如何设计一个【网盘】系统？（系统的核心功能）
• 沟通对齐
  • ① 需求分析：核心功能（文件上传/下载、文件同步）
  • ② 性能指标分析
  • ③ 要点分析：例如可以从下述角度切入
    • 大数据量存储：10亿注册用户，1000亿个文件，约1亿TB的存储空间
    • 高并发访问：平均1万QPS，高峰期2万QPS
    • 大流量负载：平均网络带宽负载80Gb/S，高峰期带宽负载160Gb/s
    • 高可靠存储：文件不丢失，持久存储可靠性达到99.9999% ，即100万个文件最多丢失（或损坏）1个文件
    • 高可用服务：用户正常上传、下载服务可用性在99.99%以上，即一年最多53分钟不可用
    • 数据安全性：文件需要加密存储，用户本人及共享文件外，其他人不能查看文件内容
    • 不重复上传：相同文件内容不重复上传，也就是说，如果用户上传的文件内容已经被其他用户上传过了，该用户不需要再上传一次文件内容，进而实现“秒传”功能。从用户视角来看，不到一秒就可以完成一个大文件的上传
• 整体设计
  • ① 服务设计（分层设计）：单服务器架构、进阶优化架构（版本升级）
  • ② 存储设计（存储选型）：此处存储涉及两部分内容，元数据存储 + 文件存储
    • 元数据存储：例如MySQL数据库
    • 文件存储：借助第三方云存储辅助（例如Amazon S3）
  • ③ 业务设计（业务流程）：从文件上传/下载、文件同步等核心流程切入
    • 文件上传：上传新文件时客户端请求出发两个操作（添加元数据信息、上传文件）
      • 添加元数据信息，并设置文件状态为pending，NS服务通知客户端文件正在上传
      • 上传文件，通过Block Servers分块、压缩、加密上传文件到云存储，当文件上传完成后回调API告知文件已上传完成。随后API Servers会更新文件状态为uploaded，随后通知NS服务
      • NS服务接收请求后会通知相关客户端文件已更新
    • 文件下载：当文件变更，会通过NS通知到相关的客户端，客户端接收到通知后选择下载文件，其会先请求文件的元数据信息，随后根据元数据信息向Block Servers发出请求下载块并重建文件
• 要点分析（或难点分析）
  • 网盘系统的要点在于如何支撑大数据量存储和高并发访问，从网盘的核心功能切入，可能还涉及到限速、秒传等一些特性功能的扩展，还可结合架构中涉及的各个组件进行故障分析（组件出现故障的场景和应对方案）
• 总结陈述

学习资料

• 【系统设计：内幕指南】15 设计Google Drive
• 【高并发架构实战课】05 网盘系统设计：万亿 GB 网盘如何实现秒传与限速？

🟢【网盘系统】场景核心

​ 近年来，Google Drive、Dropbox、Microsoft OneDrive、Apple iCloud 等云存储服务非常流行。

​ Google Drive 是一种文件存储和同步服务，可帮助您在云端存储文档、照片、视频和其他文件。用户可以从任何计算机、智能手机和平板电脑访问文件。还可以轻松地与朋友、家人和同事共享这些文件

🚀【网盘系统】场景实战

1.沟通对齐

​ 此处的沟通对齐方向，主核心方向是需求分析、请求量分析、精准度分析、难点/要点分析，可能还有涉及到其他的一些容量、设计等方面的对齐

① 需求分析

【网盘】系统核心功能

• 关注【网盘系统】核心功能，可从下述方向切入
  • 网盘系统最重要的特征？=》上传下载文件、文件同步（或者共享文件）、通知
  • 是否支持多端设备？=》支持移动端（移动应用程序）、网页端（网络应用程序）
  • 支持的文件格式？=》支持任意文件类型
  • 文件特点？=》例如存储中的文件需要加密，限制文件大小（10GB以下）
  • 系统量级？=》10M DAU

​ 基于上述需求分析，重点关注下述功能：

• ① 添加/上传文件：添加文件的最简单方法是将文件拖放到 Google Drive 中
• ② 下载文件
• ③ 扩设备同步：跨多个设备同步文件，将文件添加到一台设备后，它会自动同步到其他设备
• ④ 查看：查看文件修订内容
• ⑤ 共享：与朋友、家人和同事共享文件
• ⑥ 通知：当文件被编辑、删除或与您共享时发送通知

​ 待扩展功能讨论方向：

• 可靠性：可靠性对于存储系统来说极其重要，数据丢失是不可接受的
• 同步速度快：如果文件同步花费太多时间，用户将变得不耐烦并放弃该产品
• 带宽使用：如果产品占用大量不必要的网络带宽，用户会不高兴，尤其是当他们使用移动数据时
• 可扩展性：该系统应该能够处理大量的流量
• 高可用性：当某些服务器离线、速度变慢或出现意外网络错误时，用户应该仍然可以使用该系统

​

非功能需求

• 大数据量存储：10亿注册用户，1000亿个文件，约1亿TB的存储空间
• 高并发访问：平均1万QPS，高峰期2万QPS
• 大流量负载：平均网络带宽负载80Gb/S，高峰期带宽负载160Gb/s
• 高可靠存储：文件不丢失，持久存储可靠性达到99.9999% ，即100万个文件最多丢失（或损坏）1个文件
• 高可用服务：用户正常上传、下载服务可用性在99.99%以上，即一年最多53分钟不可用
• 数据安全性：文件需要加密存储，用户本人及共享文件外，其他人不能查看文件内容
• 不重复上传：相同文件内容不重复上传，也就是说，如果用户上传的文件内容已经被其他用户上传过了，该用户不需要再上传一次文件内容，进而实现“秒传”功能。从用户视角来看，不到一秒就可以完成一个大文件的上传

业务流程分析

② 性能指标分析（估算）

• 假设该应用程序有 5000 万注册用户和 1000 万 DAU
• 用户获得10 GB 的可用空间。
• 假设用户每天上传2 个文件。平均文件大小为 500 KB
• 1:1 的读写比。
• 分配的总空间： 5000万×10GB=500PB5000万×10GB=500PB
• 上传 API 的 QPS： 1000万×2次上传/24小时/3600秒≈2401000万×2次上传/24小时/3600秒≈240
• 峰值 QPS : QPS×2=480QPS×2=480

④ 难点/要点分析

​ 网盘的主要技术挑战是海量数据的高并发读写访问 =》用户上传的海量数据如何存储？如何避免部分用户频繁读写文件，消耗太多资源，而导致其他的用户体验不佳？

2.整体设计（架构设计）

① 服务设计（分层设计）

（1）单个服务器构建

⚽ 单机服务组件设置

​ 由浅入深，先在单个服务器中构建所有内容，然后逐步扩大系统设计规模以支撑百万用户。

• 单个服务器设计（组件分析）
  • ① Web服务：用于上传和下载文件的Web服务
  • ② 数据库：用于跟踪元数据（例如用户数据、登录信息、文件信息等）
  • ③ 存储系统：用于存储文件（例如分配了1TB的存储空间来存储文件）

​ 例如在单个服务器中配置上述内容，需要设置1个Apache网络服务器、1个MySQL数据库、1个文件存储路径（在服务器中腾出一块空间作为根目录存储上传的文件）

• 1个Apache网络服务器：Web 服务部署

• 1个MySQL数据库：元数据存储

• 1个文件存储路径：例如定义一个名为drive/的目录作为根目录存储上传的文件，其下的每个目录列表表示一个命名空间，每个命名空间存储该用户上传的所有文件（服务器上的文件名与原始文件名保持一致。通过加入命名空间和相对路径，可以唯一标识每个文件或文件夹）

  

⚽ API 设计

​ 基于网盘系统核心功能分析，此处关注3个核心API：上传文件、下载文件、获取文件修订，基于此分析API接口设计，所有 API 都需要用户身份验证并使用 HTTPS。安全套接字层 (SSL) 保护客户端和后端服务器之间的数据传输

① 上传文件到 Google Drive

支持两种类型的上传：

• 简单上传（当文件较小时使用此上传类型）

• 可恢复上传（当文件很大并且网络中断的可能性很高时，请使用此上传类型）

  • 可恢复上传 API 的示例： https://api.example.com/files/upload?uploadType=resumable（uploadType=resumable、data: 待上传的本地文件）

  • 可恢复上传通过以下 3 个步骤 实现：

    • 发送初始请求以检索可恢复 URL

    • 上传数据并监控上传状态

    • 如果上传受到干扰，请继续上传

② 从Google Drive下载文件

示例 API：https://api.example.com/files/download

参数：

• path：下载文件路径

请求示例：例如{ "path": "/recipes/soup/best_soup.txt" }

③ 获取文件修订

示例 API：https://api.example.com/files/list_revisions

参数：

• path：要获取修订历史记录的文件的路径
• 要返回的最大修订数

请求示例：例如{ "path": "/recipes/soup/best_soup.txt", "limit": 20 }

（2）摆脱单一服务器

⚽ 文件存储问题（单服务器存储容量有限）

​ 问题切入：随着更多文件的上传，单一服务器存储容量始终有限，无限制存储最终会撑爆内存，用户无法再上传文件，甚至导致整个应用的不可用。

解决方案1：数据分片（分布式数据库）

​ 基于此想到的第1个解决方案是将数据分片，将其分布存储在多个存储服务器上

解决方案2：第三方存储

​ 借助第三方存储进行辅助，许多领先的公司如Netflix和Airbnb都使用Amazon S3进行存储。亚马逊简单存储服务（Amazon S3）是一种对象存储服务，提供行业领先的可扩展性、数据可用性、安全性和性能

​ Amazon S3 支持同区域和跨区域复制。一个地区是指亚马逊网络服务（AWS）拥有数据中心的地理区域。如图所示，数据可以在同区域（左侧）和跨区域（右侧）复制。冗余文件存储在多个区域，以防止数据丢失并确保可用性。存储桶就像文件系统中的文件夹

⚽ 高性能架构设计

​ 上述通过将文件放到S3存储以解决数据丢失问题（解决文件存储问题），基于高可用、高性能架构优化方向思考，还可对基础架构进行进一步优化设计（切入点方向和架构演进思路技术栈分析类似）：

• ① 负载均衡：添加负载均衡器来分配网络流量（负载均衡器确保流量均匀分布，如果 Web 服务器出现故障，它将重新分配流量）
• ② 多机部署（多个Web服务器）：添加负载均衡器后，可以根据流量负载轻松添加/删除更多Web 服务器节点
• ③ 避免单点故障问题：不将所有组件挤到一个数据库中，将元数据数据库和文件存储给单独拎出来，形成各自的存储架构
  • 元数据数据库：将数据库移到另外的服务器移以避免单点故障，并设置数据复制和分片以满足可用性和可扩展性
  • 文件存储：借助Amazon S3构建文件存储，并将文件复制到不同的地理区域以确保可用性和持久性

​ 基于上述架构优化思路，可以更新架构设计版本如下：

​

⚽ 同步冲突问题

​ 对于像 Google Drive 这样的大型存储系统，同步冲突时有发生。当两个用户同时修改同一个文件或文件夹时，就会发生冲突。那么该如何解决冲突？参考策略：先处理的版本获胜，后处理的版本接收冲突（结合图示理解）

​ 当多个用户同时编辑同一个文档时，保持文档同步是一项挑战。此处User1和User2试图对同一个文件进行更新，但是User1的文件先被系统处理（User1的更新操作通过），但此时User2就会产生同步冲突问题，因此需思考如何解决User2的冲突。此处系统策略提供同一个文件的两个副本：【User2的本地副本】和【来自服务器的最新版本】，User2可以选择合并两个文件或者用另一个版本覆盖一个版本

⚽ 架构组件细化

​ 基于上述架构分析，进一步对高性能架构进行细化分析，优化架构版本

• ① 引入Block Servers 块服务器，辅助构建块级存储
• ② 引入Metadata Cache 元数据缓存，缓解数据库访问压力
• ③ 引入NS（Notification Servers）通知服务，提供消息通知能力

• ① Block Servers （块服务器）：块服务器将块上传到云存储

  • 块存储（块级存储）是一种在基于云的环境中存储数据文件的技术。一个文件可以分成几个块，每个块都有一个唯一的哈希值（存储在元数据数据库中）。每个块都被视为一个独立的对象并存储在存储系统 (S3) 中。为了重建文件，块以特定顺序连接。块大小设计可以参考Dropbox：把一个块的最大大小设置为4MB

• ② Cloud storage（云存储）：文件被分割成更小的块并存储在云存储中

• ③ Cold storage（冷存储）：冷存储是一种为存储非活动数据而设计的计算机系统，意味着文件在很长一段时间内不会被访问

• ④ Load balancer（负载均衡器）：负载均衡器在 API 服务器之间平均分配请求

• ⑤ API servers：这些服务器负责除上传流程以外的几乎所有工作。API服务器用于用户认证、管理用户资料、更新文件元数据等

• ⑥ 元数据存储

  • Metadata database：它存储用户、文件、块、版本等元数据。请注意，文件存储在云端，元数据数据库仅包含元数据
  • Metadata cache：一些元数据被缓存以便快速检索

• Notification service：它是一个发布者/订阅者系统，允许在某些事件发生时将数据从通知服务传输到客户端

  • 例如通知服务会在其他地方添加/编辑/删除文件时通知相关客户，以便他们可以提取最新的更改
  • 除此之外，此处还可以将在线/离线逻辑单独迁到一个服务中，通过将在线服务从通知服务器中移出，在线/离线功能可以很容易地被其他服务集成

• Offline backup queue：如果客户端离线并且无法拉取最新的文件更改，离线备份队列会存储信息，以便在客户端在线时同步更改

② 存储设计（存储选型）

​ 基于上述分析，数据存储主要划分为两大块：元数据存储、文件存储，对于元数据存储可以选用MySQL关系型数据库，对于文件存储则是借助第三方云存储组件（例如Amazon S3）进行辅助

③ 业务设计（业务流程）

3.要点分析

​ 基于上述【架构组件细化】相关图示，对架构中涉及到的组件进一步剖析

① 块服务器

对于定期更新的大文件，在每次更新时发送整个文件会消耗大量带宽。提出了两种优化来最小化传输的网络流量：

• 增量同步：修改文件时，使用同步算法，即仅同步修改的块而不是整个文件
• 压缩：对块进行压缩可以显著减少数据大小。因此，根据文件类型，使用压缩算法对块进行压缩（例如，gzip和bzip2是用来压缩文本文件的。压缩图像和视频则需要不同的压缩算法）

​ 在系统中，块服务器负责上传文件的繁重工作，它允许我们通过提供增量同步和压缩机制来节省网络流量。块服务器通过将文件分成块、压缩每个块并加密它们来处理从客户端传递的文件。不是将整个文件上传到存储系统，而是只传输修改过的块

• ① 上传新文件：一个文件被划分为更小的块，每个块都采用压缩算法进行压缩（节省网络流量），并经过加密（保证信息安全）后上传到云存储
• ② 增量同步：只有修改过的块才会被上传到云存储进行更新

问题切入：为什么要引入块服务器？可否直接将文件上传到云存储？

​ 事实上可以考虑直接从客户端向云端存储上传文件，而不通过块服务器。这种思路有利有弊，分析如下：

• 优点：使文件上传速度更快（原有是先传输到块服务器在传输到云存储，中间多了一道处理）
• 缺点：耦合严重，存在安全问题
  • 同样的分块、压缩、加密逻辑需在所有的客户端平台（例如IOS、Android、Web）上实现，且客户端容易遭受黑客攻击/操纵，在客户端实现这些业务逻辑并不理想

​ Block Servers的引入则是提供了一个集中处理的中转站，所有的分块、压缩、加密逻辑都经由该服务提供的API处理，客户端不用单独实现一套文件上传的处理逻辑

② 元数据存储

（1）高一致性要求

​ 结合上述架构图示，针对元数据的存储设计了元数据缓存和元数据数据库两部分，因此要考虑解决数据一致性问题。结合业务场景来说，如果一个文件同时被不同的客户端显示不同是不可接受的，因此系统设计需要考虑为元数据缓存和数据库层提供强一致性。

​ 内存缓存默认采用最终一致性模型，这意味着不同的副本可能有不同的数据。要实现强一致性，必须确保以下几点：

• 缓存副本和主服务器中的数据是一致的
• 在数据库写入时使缓存无效，以确保缓存和数据库保持相同的值

​ 在关系数据库中实现强一致性很容易，因为它维护了 ACID（原子性、一致性、隔离性、持久性）属性。但是，NoSQL 数据库默认不支持 ACID 属性。 ACID 属性必须以编程方式合并到同步逻辑中。因此元数据数据库选择关系数据库，因为 ACID 是原生支持的

（2）元数据数据库设计

• ① user：用户表包含有关用户的基本信息，例如用户名、电子邮件、个人资料照片等
• ② device：设备表存储设备信息。一个用户可以拥有多个设备， push_id 用于发送和接收移动推送通知
• ③ namespace：命名空间是用户的根目录
• ④ file：文件表存储与最新文件相关的所有内容
• ⑤ file_version：它存储文件的版本历史。现有行是只读的，以保持文件修订历史的完整性
• ⑥ block：它存储与文件块相关的所有内容。任何版本的文件都可以通过以正确的顺序连接所有块来重建

③ 文件上传/下载

（1）上传流程

​ 上传流程时序图分析如下：客户端Client上传文件时会并行触发两个请求（添加文件元数据、将文件上传到云存储）编辑文件的流程类似，此处不做赘述

• 添加文件元数据
  • ① Client1 发送请求，要求添加文件元数据
  • ② API Servers 处理请求，将文件元数据存储在元数据数据库（此时文件上传状态更改为pending）
  • ③ 通知 NS（通知服务）目前正在添加一个新的文件
  • ④ NS 接收指令后通知相关客户端（例如此处的Client2）有文件正在上传
• 将文件上传到云存储
  • Client1 将文件内容上传到 Block Servers
  • Bolck Servers 接收并处理请求，将文件内容分块、压缩、加密后上传到云存储
  • 文件上传完成之后，因存储触发【上传完成回调】，请求被转发到API Servers
  • API Servers 收到请求将文件上传状态变更为uploaded
  • 随后通知NS某个文件状态已经被变更为uoloaded(此处表示文件上传成功)
  • NS 接收指令后通知相关客户端（例如此处的Client2）文件已经完全上传

（2）下载流程

当一个文件在其他地方被添加或编辑时，会触发下载流。客户端如何知道一个文件是由另一个客户端添加或编辑的？客户端有两种方法可以知道：

• 如果客户端 A 在线，而另一个客户端更改了文件，通知服务将通知客户端 A 某处发生了更改，因此需要拉取最新数据
• 如果客户端A在文件被另一个客户端修改时处于离线状态，数据将被保存到缓存中。当脱机的客户端再次上线时，它就会拉出最新的变化

一旦客户端知道一个文件被改变，它首先通过API服务器请求元数据，然后下载块来构建文件。下图展示下载详细的流程（关注核心部分）

​ 上述流程说明了当某个文件发生更改时相关客户端如何同步，简述来说就是NS通知客户端某个文件发生变更，当某个客户端感知到之后会主动拉取元数据信息，随后根据最新的元数据信息向块服务器发送请求以下载块并重建文件

• ① NS通知服务通知客户端某个文件在其他地方发生了更改
• ② 一旦 Client2 知道有新的更新可用，它就会发送一个获取元数据的请求
• ③ API Servers 调用元数据数据库来获取更改的元数据
• ④ 元数据返回给API服务器
• ⑤ Client2 获取元数据
• ⑥ 一旦 Client2 收到元数据，它就会向块服务器发送请求以下载块
• ⑦ 区块服务器首先从云存储中下载区块
• ⑧ 云存储返回块给块服务器
• ⑨ Client2 下载所有新块重建文件

④ 通知服务

为了保持文件的一致性，本地执行的任何文件变更都需要通知其他客户端以减少冲突。通知服务就是为这个目的而构建的。在进阶版本架构设计中，通知服务允许在事件发生时将数据传输到客户端。这里有几个选项：

• 长轮询（ Dropbox 使用长轮询）
• WebSocket（WebSocket 在客户端和服务器之间提供持久连接，沟通是双向的）

尽管这两种选择都很好，但出于以下两个原因，选择了长轮询：

• 通知服务的通信不是双向的。服务器向客户端发送有关文件更改的信息，反之亦然
• WebSocket 适用于实时双向通信，例如聊天应用程序。对于 Google 云端硬盘，通知发送不频繁，没有突发数据

​ 使用长轮询，每个客户端都会建立到通知服务的长轮询连接。如果检测到对文件的更改，客户端将关闭长轮询连接。关闭连接意味着客户端必须连接到元数据服务器才能下载最新的更改。收到响应或达到连接超时后，客户端立即发送新请求以保持连接打开

⑤ 节省存储空间

为了支持文件版本历史并确保可靠性，同一文件的多个版本被存储在多个数据中心。如果频繁地备份所有文件的修订版，存储空间就会很快被填满。提出了三种技术来减少存储成本：

• 【方案1】去除重复的数据块
  • 在账户层面消除多余的块是节省空间的一个简单方法。如果两个块有相同的哈希值，那么它们就是相同的
• 【方案2】采用智能数据备份策略，可以应用两种优化策略：
  • 设置限制：可以为要存储的版本数量设置限制。如果达到限制，最旧的版本将被新版本替换。
  • 只保留有价值的版本。有些文件可能会被频繁地编辑。例如，为一个大量修改的文件保存每个编辑过的版本可能意味着该文件在短时间内被保存1000多次。为了避免不必要的复制，可以限制保存版本的数量。对最近的版本给予更多的权重。实验有助于找出保存的最佳版本数
• 【方案3】引入冷存储（冷特分区）
  • 将不常用的数据移动到冷存储，冷数据是数月或数年未活跃的数据（例如像 Amazon S3 冰川 这样的冷存储比 S3 便宜得多）

⑥ 故障处理

在一个大规模的系统中可能会出现故障，必须采取设计策略来解决这些故障：

• 负载均衡器故障：如果负载均衡器出现故障，辅助节点将变为活动状态并接收流量。负载均衡器通常使用心跳相互监控，心跳是负载均衡器之间发送的周期性信号。如果负载均衡器在一段时间内没有发送心跳，则认为它失败了
• 块服务器故障：如果块服务器发生故障，其他服务器将接管未完成或挂起的作业
• 云存储故障：S3 bucket在不同地域多次复制。如果文件在一个区域不可用，可以从不同区域获取它们
• API服务器故障：是无状态服务。如果 API 服务器发生故障，流量将通过负载均衡器重定向到其他 API 服务器
• 元数据缓存故障：元数据缓存服务器被多次复制。如果一个节点宕机，仍然可以访问其他节点以获取数据。通过启动一个新的缓存服务器来替换发生故障的服务器
• 元数据数据库故障
  • Master down：如果master宕机，提升其中一个slave充当新的master，并拉起一个新的slave节点
  • Slave down：如果一个slave down了，可以用另一个slave进行读操作，带上另一台数据库服务器来代替失效的
• 通知服务失败：每个在线用户与通知服务器保持一个长轮询连接。因此，每个通知服务器都与许多用户相连。根据 2012 年的 Dropbox 谈话 [6]，每台机器打开超过 100 万个连接。如果服务器出现故障，所有长轮询连接都会丢失，因此客户端必须重新连接到不同的服务器。即使一台服务器可以保持许多打开的连接，它也无法立即重新连接所有丢失的连接。重新连接所有丢失的客户端是一个相对缓慢的过程。
• 离线备份队列故障：队列被多次复制。如果一个队列发生故障，该队列的消费者可能需要重新订阅备用队列

⑦ 扩展功能说明

（1）限速

​ 例如常见的网盘根据不同的用户等级限制用户的上传、下载速度。而要控制上传、下载速度则可通过限制并发Block服务器数目，以及限制Block服务器内的线程数来实现。

​ 具体过程是，客户端程序访问API服务器，请求上传、下载文件的时候，API服务器可以根据用户类型，决定分配的Block服务器数目和Block服务器内的服务线程数，以及每个线程的上传、下载速率。Block服务器会根据API服务器的返回值，来控制客户端能够同时上传、下载的Block数量以及传输速率，以此对不同用户进行限速。

（2）秒传

​ 秒传是用户快速上传文件的一种功能。其本质上是一种通过校验文件性质来快速绑定的手段。例如针对某个已上传的文件，如果用户上传同一个文件被系统检测到时，此时系统不会重复上传该文件，而是通过构建关联关系快速将用户和文件进行绑定，一方面避免了重复上传文件给系统带来的负载压力（存储/网络带宽），另一个方面用户从体验上会感受到"秒传"的微妙之处，但与此同时也带来了误判的可能，不完善的校验机制反而会给不法分子提供可乘之机

​ 事实上，网盘保存的很多文件，内容其实是重复的，比如电影、电子书等等。一方面，重复上传这些文件会加大网盘的存储负载压力；另一方面，每次都要重新上传重复的内容，会导致用户网络带宽的浪费和用户等待时间过长的问题。所以，在设计中，物理上相同的文件，系统只会保存一份。用户每次上传文件时，DBox都会先在客户端计算文件的MD5值，再根据MD5值判断该文件是否已经存在。对于已经存在的文件，只需要建立用户文件和该物理文件的关联即可，并不需要用户真正上传该文件，这样就可以实现秒传的功能。但是，计算MD5可能会发生Hash冲突，也就是不同文件算出来的MD5值是相同的，这样会导致系统误判，将本不相同的文件关联到一个物理文件上。不但会使上传者丢失自己的文件，还会被黑客利用（例如上传一个和目标文件MD5相同的文件，然后就可以下载目标文件了）

​ 所以，系统需要通过更多信息判断文件是否相同：只有文件长度、文件开头256KB的MD5值、文件的MD5值，三个值都相同，才会认为文件相同。当文件长度小于256KB，则直接上传文件，不启用秒传功能。

4.总结陈述

• 深刻总结
• 要点牵引
• 收尾请教

​ 针对网盘系统的设计，主要涉及两个核心流程：管理文件元数据（文件上传/下载）和文件同步，此外通知服务是系统的另一个重要组成部分，它使用长轮询来使客户端保持最新的文件更改。

🚀实战案例