常见分布式应用系统设计图解(八):文件同步分享系统

文件同步分享系统包括 Dropbox、Google Drive,也包括国内的各种网盘,比如百度网盘。总的来说,这里讨论的这个系统包含这样几个基本功能:

  • 文件变更检测;
  • 文件增量上传和下载;
  • 文件分享和同步。
  • 总体来说,上半部分是文件变化的检测和上传。上传分为两条路线,一条是控制流,一条是数据流。
  • 客户端方面,包含这样几个关键组件和步骤:
    • 有一个 Watcher 用来监控操作系统的文件变化,无论是 Linux 还是 Windows 都可以在文件系统上挂载回调,当文件系统发生变化的时候通知它。
    • 有一个 Chunker 帮助给需要传输的数据分块,也负责将收到的 chunks 写入成为文件。对它来说它只负责听从 Indexer 的要求,处理 chunk 和文件之间的转换并进行文件系统的读写,属于数据流部分。
    • 有一个 Indexer 是客户端的大脑,状态维持在一个客户端的数据库中,还要指挥 Chunker 通过远程的文件服务读写数据。客户端的变更元数据通过 Indexer 发送给服务端的 Metadata Service,它属于控制流部分。
  • 服务端方面,上半部分是文件上传部分。由于一个客户端的数据变更而引起的文件上传的数量很可能不稳定,例如第一次的时候有可能要上传大量的文件,因此上传的文件需要通过队列缓冲。
  • Metadata 需要放在一个数据库中,单条数据比较小,可以选用 KV 数据库+事务控制,或者 RDB+sharding。控制流部分告知要上传的文件,得到 Metadata Service 的批准以后,客户端直接向 Block Service 写文件数据。完成以后再告知 Metadata Service,并在 Metadata 数据库中更新文件上传的状态。
  • 文件实际的数据按照块的形式组织,存放在分布式文件系统中。大文件拆分成小的块,这样如果某一个块的校验码(checksum)不匹配,重传该块即可,不需要重传整个文件。理论上文件去重也可以根据块通过特定的 hash 算法来进行,重复的块可以避免传输和存储来节约开销,当然,文件去重一定会面临着 collision 的风险,即便这个可能性再小它也依然是存在的。去重算法所得到的块 hash 串,不但在服务端存储,也在客户端存储。
  • Sync Service 由队列中的数据驱动,负责同步逻辑,把需要同步的数据放到下半部分的若干个同步队列中去,每个客户端由于所在的文件系统状态很可能不一样,因此一般需要消费不同的队列。
  • Notification Service 和客户端建立长连接,推送告知客户端需要同步的数据。移动客户端和桌面端不一样,可以告知需要同步的文件,但它不一定要时刻保持实际的文件同步,主要是考虑流量节约的目的。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

500 次阅读

2 thoughts on “常见分布式应用系统设计图解(八):文件同步分享系统

  1. 请问这里的 queue 是不是位置不对?queue 按理解来说应该是放 block 的?Metadata 本身大小应该不大,个人感觉好像没有必要要用队列缓冲。

    1. 你说的是其中的哪个 queue?最上面那个 queue 当初引入的原因是,用户上传变更在这类系统之中,往往是批量且大量的(比如整个文件夹里面有成千上万个小文件),给系统的冲击很大,所以这个队列对于 metadata 的处理起到一个缓冲作用。

Leave a Reply

Your email address will not be published.

back to top