版本比较
标识
- 该行被添加。
- 该行被删除。
- 格式已经改变。
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:上传文件,下载文件,获取文件历史 。
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来发送和接收推送消息。用户可能有多个设备。
工作空间:用户的根目录。
文件:存储文件的最新信息。
文件历史:存储文件的历史记录,现有行必须是只读的,以保证文件历史的完整性。
块:存储文件块的信息。任何版本的文件都可以通过块来组装。
上传流程
这里有两个请求并行:上传元数据及上传文件到云存储,两个请求都从用户1中发出,用户2只用于接收推送消息。
- 上传元数据。
- 用户1发送上传新文件元数据请求。
- API服务器将元数据存储到元数据库中,并设置文件的上传状态为pending。
- 通知推送服务有一个新文件正在上传。
- 推送服务将文件正在上传的消息推送给另一个用户2。
- 上传文件到云存储
- 用户1上传文件到块服务器。
- 块服务器将文件分块,压缩,加密,然后存储到云存储。
- 一旦文件完成上传,云存储触发任务完成回调,相关请求被发送到API服务器。
- API服务器将元数据库中的文件状态改为 uploaded。
- 通知推送服务文件已上传成功。
- 推送服务将文件已上传成功的消息推送给另一个用户2。
下载流程
当文件被新增或修改时,会触发下载流程。首先是一个客户端如何知道文件被修改另一个客户端修改的问题,这里有两种方式:
- 如果用户A在线且文件被另一个用户修改,那么推送服务可以通知用户A文件已被修改,需要发起下载流程。
- 如果用户A不在线且文件被另一个用户修改,那么数据会被保存在缓存中,当离线用户上线时,会主动拉起最新修改。
一旦用户知道文件已被修改,首先会通过API服务器向元数据库发起请求,然后下载相应的块以在本地重组文件,以下是下载流程:
- 推送服务器通知用户2文件在别处被修改。
- 一旦用户2知道有可用更新,会首先向API服务器请求元数据。
- API服务器查询元数据库。
- 元数据库返回文件元数据修改。
- API服务器将元数据修改返回给用户。
- 一旦用户获取到元数据,会向块服务器发起下载请求。
- 块服务器从云存储中下载块。
- 云存储返回块。
- 用户下载全部的块并在本地重组文件。
通知推送
为了保证强一致性,任何的修改都必须通知其他用户,以降低冲突风险,通知推送服务可以用于实现该目的。从高层次来说,推送服务可以在事件发生时将数据发送给用户,以下是一些可选项:
- 长轮徇,Dropbox使用这种方式
- WebSocket。WebSocket可以在客户端与服务器之音建立持久的双向连接。
这里我们倾向于选择长轮徇,原因如下:
- 通知推送并不是双向的,只从服务器发向客户端,但反过来不会。
- SebSocket适用于实时双向应用,比如聊天应用。对于Google Drive来说,通知并不会频繁发送,也不存在数据突发问题。
通知长轮徇,每个用户都和推送服务器维持一个长轮徇链接。当文件修改被客户端检测到时,客户端会首先关闭长轮徇链接,并下载最新的文件,然后重新建立长连接。
节省存储空间
为支持文件历史版本以及保证可靠性,相同文件的多个历史版本会被保存在不同的数据中心,这会占用大量的存储空间。以下三点可以节约存储:
- 数据块去重。在用户层去掉重复的数据块,使用哈希值作为判断标准。
- 使用更加智能的备份策略,以下两项优化可用:
- 限制历史版本的数量,超出限制时,旧的历史版本文件会被删除。
- 只保存重要的历史版本,适用于频繁修改的文件。
- 将不常用的数据移动到冷存储上,这可以降低云存储的费用。
错误处理
以下错误处理可供讨论:
- 负载均匀服务器错误:将流量转移到备用的负载均匀服务器上。一般使用保活来维持在线,当主服务器保活超时时,启用备用服务器。
- 块服务器错误:将剩余块的存储转移到其他块服务器上。
- 云存储错误:S3云存储会将块存储在多个数据中心,如果其中一个不可用,可以从另一个获取。
- API服务器错误:使用API层无状态设计,将请求转移到另一个可用的API服务器上。
- 元数据缓存错误:元数据缓存服务器使用复制技术,将请求转移到另一个服务器 。
- 元数据库错误:
- 主数据库掉线:将一台从数据库临时提升为主数据库。
- 从数据库掉线:将请求转移到另一台从数据库上。
- 通知推送错误:使用长轮徇时单个服务器上可能有上百万个用户的连接,如果服务器掉线,这些长连接都会丢失,则服务器可能需要花很长时间重建这些连接。一种处理办法是客户端主动向另一个服务器建立连接。
- 离线备份队列错误:使用复制技术,将用户订阅转移到另一台备份队列服务器上。
Step 4 - 总结
略略略。
目录 |
---|