System Design之Design Dropbox/Google Drive

本文是北美模拟面试题 Design Dropbox 的笔记，原视频可以在 System Design Guru 频道查看。

北美的 System Design 面试没有标准答案，全部为开放式问答，只要言之有理能讲清楚各种选择下的 tradeoff 即可。

原题：

请设计一个类似 Dropbox 的文件系统，其支持

1. 用户上传并下载文件

2. 多客户端/用户之间同步文件

考点：

1. 数据存储(Data Storage)
   1. 元数据存储:
      • 使用关系数据库(Relational Database, RDBMS)存储元数据，因为元数据结构良好、具有固定模式(schema)，并且从ACID事务中受益。这有助于避免不一致性并有效地处理并发性。
   2. 文件存储:
      • 使用Blob存储(Blob Store)来存储文件，因为它在成本上更具效益，并且支持非结构化数据。
      • 提及Blob存储而不是具体技术，如S3，以避免具体实现的局限性。
2. 数据分片(Data Sharding)
   1. 按项ID分片(Shard by Item ID):
      • 优点:
        1. 均匀分布: 确保跨分片的负载均衡。
        2. 容错性: 如果一个分片宕机，只有一些文件不可访问，而不是某个用户的所有文件。
      • 缺点:
        1. 复杂查询: 跨分片查询更复杂，并可能导致更高的网络延迟。
   2. 按用户ID分片(Shard by User ID):
      • 优点:
        1. 数据本地化: 一个用户上传的所有文件存储在一个分片中，简化了用户特定查询。
      • 缺点:
        1. 潜在热点: 重度用户可能会创建热点，例如某个用户有数百万个文件。
        2. 容错性: 如果一个分片宕机，受影响的用户将失去对所有文件的访问。
        3. 数据移动: 在重新平衡期间，将整个用户数据集移动到不同的分片是复杂的。
3. 文件上传
   1. 异步上传(Async Uploading):
      • 使用消息队列处理异步作业，以高效地处理大规模和并发文件上传。
   2. 数据分块(Data Chunking):
      • 原因: