Step 1 - 明确需求
以下是一些可供参考的讨论点:
- 主要特性是什么?=> 支持上传和下载文件,文件同步,以及通知。
- 移动端 or web应用 or both ? => both。
- 支持哪些文件类型?=> 所有类型。
- 文件需要加密存储吗?=> 需要。
- 文件大小有限制吗?=> 不超过10GB。
- 日活多少?=>1000万。
这里以下列需求作为设计目标:
- 上传文件。
- 下载文件。
- 多端自动同步。
- 文件历史记录。
- 文件分享。
- 当文件被修改,删除,或被共享给你时,发送推送消息。
以下特性暂不支持:
- 文档在线协作。
除以上需求外,非功能性需求也要得到保证:
- 可靠性,绝不能导致数据丢失。
- 快速同步。
- 带宽友好,不能太占用带宽。
- 可扩展,能够支持大流量并发。
- 高可用性,即使服务器掉线,用户也需要能够使用部分功能,比如编辑本地文件。
规模预估:
- 假设应用有5000万注册用户以及1000万日活用户。
- 每位用户有10GB免费使用空间。
- 假设用户平均每天上传2个文件,文件平均大小为500KB。
- 读写比例为1:1。
- 总空间占用:5000万 * 10GB = 500PB。
- 上传QPS:1000万 * 2 / 24 / 3600 ~= 240
- 峰值上传QPS:QPS * 2 = 480
Step 2 - 高阶设计
从单服务器开始,逐渐将系统拓展到支持百万级用户。单服务器设计如下:
- 一台服务器用于上传和下载文件。
- 一个数据库用于保存元数据,比如用户配置,登录信息,文件信息等。
- 一个文件存储系统用于存储文件。
简单地使用一台Apache web服务器和MySql数据库,以及一个本地路径 drive/ 作为根目录即可实现上面的系统。在 drive/ 目录下,每个用户对应一个文件夹,每个文件夹存储对应用户的文件,文件名与用户上传的原始文件名相同。以下是这个系统的示例:
API设计
主要需要3个API:上传文件,下载文件,获取文件历史 。