常见分布式应用系统设计图解（八）：文件同步分享系统

文件同步分享系统包括 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 和客户端建立长连接，推送告知客户端需要同步的数据。移动客户端和桌面端不一样，可以告知需要同步的文件，但它不一定要时刻保持实际的文件同步，主要是考虑流量节约的目的。

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