Step 1 - 明确需求

以下是一些可供参考的讨论点:

  1. 主要特性是什么?=> 支持上传和下载文件,文件同步,以及通知。
  2. 移动端 or web应用 or both ? => both。
  3. 支持哪些文件类型?=> 所有类型。
  4. 文件需要加密存储吗?=> 需要。
  5. 文件大小有限制吗?=> 不超过10GB。
  6. 日活多少?=>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:上传文件,下载文件,获取文件历史 。

1. 上传文件

包含两种上传:

  • 简单上传,适合小文件
  • 断点重传,适合大文件

以下是一个断点重传的API示例:

https://api.example.com/files/upload?uploadType=resumable

包含上传类型和本地文件数据两个参数。

一次断点重传的流程如下:

  • 发送初始请求以获取重传URL。
  • 上传文件,监测上传进度。
  • 如果上传被打断,则恢复传输。

2.下载文件

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

参数:

  • path: 文件路径

示例参数:

{
    "path": "/recipes/soup/best_soup.txt"
}

3.获取文件历史记录

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

参数:

  • path: 文件路径
  • limit: 返回的最大历史记录数


以上所有的API都需要支持HTTPS,以保证数据是加密传输。

多服务器设计

与其自建服务器分片与复制,不如将数据存储交给现有的云服务商来实现,这样可以借助云服务商成熟的服务和多数据中心来保障数据安全。以Amazon S3为例,Amazon S3支持同数据中心内的数据库复制和跨数据中心的数据库复制,通过将数据在多地进行冗余备份,可以有效保证数据安全及服务可用。

除了多地备份外,以下措施也必不可少:

  • 负载均衡:增加负载均衡以平均分布网络流量,以及容错。
  • Web服务器集群:根据流量动态添加或删除服务器。
  • 元数据库:将数据库独立出来,以避免单点故障,同时,使用分片和数据库复制技术,以实现可用性和扩展需求。
  • 文件存储:使用Amazon S3来存储文件,为了保证可用性和可靠性,可以将文件在两地进行冗余备份存储。

经过以上措施的优化后,系统设计调整如下:


同步冲突

当两个用户同时修改了同一个文件时,冲突发生。这里我们以第一次修改提交为准,第二次提交被视为冲突,如下:

当用户2收到冲突通知时,服务器会一并返回服务器上最新的版本,由用户2自己来解决冲突。

总体设计

以下是各组件介绍:

用户:包括客户端,浏览器,移动APP。

块服务器:用于将存储块上传到云存储。块级存储是指在云环境下将数据文件分块进行存储,每个块都包含一个唯一的哈希值,这个哈希值存储在元数据库中。对于云存储来说,每个块都是独立的,为了重建文件,需要将所有的块按顺序联合起来。块的大小可参考Dropbox,它的块大小是4MB。

云存储:存储数据块。

负载均衡:平摊请求到API服务器上。

API服务器:负责除了上传文件之外的全部请求,比如认证,用户配置,更新文件元数据等。

元数据库:存储用户、文件、存储块、版本信息等的元数据,不存储具体文件。

元数据缓存:缓存部分元数据,用于快速读取。

通知推送服务:用于推送事件通知,比如文件添加、删除、修改等事件。

离线备份队列:如果客户离线,无法拉取服务端文件的最新修改,那么离线备份队列会将这些修改存入队列,以便于在客户重新上线时推送文件修改。

Step 3 - 深入设计

深入探讨块服务器,元数据库,上传流程,下载流程,通知推送,节省存储空间,以及错误处理。

块服务器

对于大文件,每次更新时都上传整个文件需要占用大量带宽,对此,可以从下面的两方面进行优化:

  • 增量同步,每次修改时只上传修改过的部分。
  • 数据压缩。使用数据压缩可显著缩小数据的大小,因此,数据块需要以一定的算法进行压缩之后再进行存储,比如使用gzip或者bzip2对文本文件进行压缩。对于音视频文件,可采用其他合适的压缩算法。

在当前系统中,块服务器承载了文件上传的全部压力。块服务器会把用户上传的文件分成合适的块,然后压缩并加密,块服务器还负责只上传那些被修改过的块。通过增量同步和数据压缩,可显著降低服务器的带宽占用。

高一致性要求

本系统天然需要强一致性,因为同一时间用户看到的文件必须是相同的,系统要求在元数据缓存和数据库层保证强一致性。

缓存一般使用最终一致性模型,意味着不同副本可能不一样,为了实现强一致性,必须保证以下两点:

  • 数据在缓存中和在主服务器中必须保持一致
  • 写数据库采用无缓存操作,以保证数据库中的值和元数据缓存一致。

在关系型数据库中实现强一致性相对简单,因为关系型数据性支持ACID属性。但是非关系型数据库一般不支持ACID属性,需要由软件来保证在同步时能保持强一致性。在本系统设计中,我们使用关系型数据库,以支持ACID。

元数据库

以下是一个简化的元数据库的表设计:

包含以下组件:

用户表:包含用户的基本信息,比如用户名,邮件地址,头像等。

设备表:存储设备信息,通过device_id来发送和接收推送消息。用户可能有多个设备。

工作空间:用户的根目录。

文件:存储文件的最新信息。

文件历史:存储文件的历史记录,现有行必须是只读的,以保证文件历史的完整性。

块:存储文件块的信息。任何版本的文件都可以通过块来组装。

上传流程
























  • 无标签