Cloud-Drive

项目介绍

Cloud-Drive是一个私人文件存储系统，实现了主流文件存储系统的全部核心业务。

项目主要包括以下几个模块：

• 用户模块：处理用户的注册、登录、信息管理等功能。
• 文件模块：负责文件的分片上传、下载、文件秒传、文件夹树查询、面包屑查询等功能。
• 回收站模块：处理文件的删除和恢复、彻底删除、废弃文件清理。
• 分享模块：实现文件的分享与取消分享、分享码校验。
• 日志模块：记录和管理系统的操作日志。

关键业务设计

存储引擎设计

对应的代码架构设计如下:

文件分片上传

分片上传业务可以拆分为三步:

1. 分片检查
2. 分片上传
3. 分片合并

具体流程图如下：

项目优化方案

服务拆分方案

Dropbox创始人12年前在Youtube上的一场分享：「How We've Scaled Dropbox」

将服务宏观角度拆分为：

• metaserver
• blockserver

可以这么理解，metaserver用于与DB打交道，blockserver存储真正的物理文件。

如果后续进行服务拓展和拆分，可以首先对服务拆分成metaserver和blockserver。之后根据需要对服务进行水平拓展，例如如果存储服务用本地存储，就要考虑安全性（文件备份）、存储容量的限制。如果存储服务用第三方存储例如阿里OSS，则只需要考虑对metaserver进行水平拓展，主要是保证高可用。

相同的文件只存储一份

解决问题：如何保证同一个文件只存储一次，同时对用户隔离文件合并的实际操作。

设计理念：

1. 在下游（文件合并）进行加锁处理，而非上游进行加锁。 因为用户网速不可控，不同用户网速差别大，而服务端性能对所有用户都是一致的。
2. 在上游（文件秒传）正常秒传。 即使是同时上传相同的文件，互相隔离，并按照用户隔离原则进行。

操作过程：

1. 锁定:

   • 当一个用户准备合并文件时，对文件的identifier进行锁定。
   • 这确保同一时间只有一个用户能合并文件，避免重复存储。

2. 合并与校验:

   • 用户获得锁后开始合并文件。

   • 合并完成并更新数据库后，释放锁。

   • 后续获取锁的用户需再次检查文件表（double-check）判断文件是否已存在。

3. 去重：

   • 如果文件存在，无需重复存储。
   • 当前文件的real_path更新为已存在文件的路径即可。

之所以不再上游加锁主要考虑以下原因：

业务角度：对于用户2的体验非常不好，我正常上传一个文件为啥不让我上传呢？

技术角度：客户端上传速度非常不可控，如果出现客户端1网速极慢的情况下，而客户端2速度较快，仍然会出现用户体验问题。