系统设计 Dropbox ….您可能已经多次使用此文件托管服务来上传和共享文件或图像，但如果有人要求您在短短 45 分钟内设计出这个庞大的系统呢？
是的，这就是您在系统设计轮面试中应该做的事情。我们不是在开玩笑，但您需要讲述您的设计方法，比如设计 Dropbox（在 45 分钟或更短的时间内）之类的系统，该系统有数百名软件工程师为此工作了十年。系统设计保管箱（或设计谷歌驱动器或任何其他文件共享和上传服务）是系统设计回合中非常常见的问题。
在这个博客中，我们将讨论如何设计一个像 Dropbox 或 google drive 这样的网站，但在我们进一步讨论之前，我们希望您阅读文章“如何在面试中破解系统设计？”。它会让你知道这一轮是什么样子，你在这一轮中应该做什么，以及在面试官面前应该避免哪些错误。
现在让我们直接跳到“你会如何设计 Dropbox？”这个问题。
你会如何设计 Dropbox？
当你在面试中被问到这个问题时，不要立即进入技术细节。不要朝一个方向跑，它只会在你和面试官之间制造混乱。大多数候选人在这里犯了错误，他们立即开始列出一些工具、框架或数据库。请记住，您的面试官想要有关您将如何解决问题的高级想法。您将使用什么工具并不重要，重要的是您如何定义问题、如何设计解决方案以及如何逐步分析问题。
在此博客中，我们将假设您的计算机或系统中安装了一个同步客户端，并且该客户端始终查看特定的同步文件夹，在其中始终监视对文件并上传。此外，我们不会谈论如何构建云存储。我们将使用一些云存储服务，如 Amazon S3 或任何其他将文件保存在云中的存储服务。
1. 讨论核心特性
在你跳入解决方案之前，总是澄清你在面试开始时所做的所有假设。提出问题以确定系统的范围。这将消除最初的疑问，您将了解面试官希望在此服务中考虑哪些具体细节。所以先从dropbox的核心特性开始和面试官讨论。如果面试官想要添加更多功能（例如 API 集成），他们会通知您。
- 用户应该能够上传/下载、更新和删除文件
- 文件版本控制（更新历史）
- 文件和文件夹同步
2. 交通
- 12+ 百万独立用户
- 每天 1 亿个请求，大量读取和写入。
3. 讨论问题陈述
很多人认为设计 Dropbox 只是他们需要做的就是使用一些云服务，上传文件，并在他们想要的时候下载文件，但这不是它的工作原理。核心问题是“在哪里以及如何保存文件？ “。
假设您想共享一个可以是任意大小（小或大）的文件并将其上传到云中。到这里一切都很好，但稍后如果您必须在文件中进行更新，那么编辑文件并将整个文件一次又一次地上传到云中并不是一个好主意。原因是…
- 更多带宽和云空间利用率：要提供文件的历史记录，您需要保留文件的多个版本。这需要更多的带宽和云中的更多空间。即使对于文件中的微小更改，您也必须一次又一次地备份整个文件并将其传输到云中，这不是一个好主意。
- 延迟或并发利用率：您也无法进行时间优化。即使您对文件进行小的更改，将单个文件作为一个整体上传也会消耗更多时间。也不可能使用并发来上传/下载使用多线程或多进程的文件。
讨论解决方案（高级解决方案）
我们可以将文件分成多个块来克服我们上面讨论的问题。对文件进行任何更改后，无需上传/下载整个单个文件。您只需要保存更新的块（这将占用更少的内存和时间）。将不同版本的文件保存到不同的块中会更容易。
我们已经考虑了一个被分成不同块的文件。如果有多个文件，那么我们需要知道哪些块属于哪个文件。为了保留这些信息，我们将再创建一个名为元数据文件的文件。该文件包含块的索引（块名称和顺序信息）。您需要在此元数据文件中提及块（或某些参考）的哈希值，并且需要将此文件同步到云中。我们可以随时从云端下载元数据文件，并且可以使用各种块重新创建文件。
现在让我们来谈谈 Dropbox 服务的完整系统设计解决方案的各个组件。
假设我们的计算机上安装了一个客户端（您的计算机上安装了一个应用程序），并且这个客户端有 4 个基本组件。这些基本组件是 Watcher、Chunker、Indexer 和 Internal DB。我们只考虑了一个客户端，但可以有多个客户端属于同一用户，具有相同的基本组件。
- 客户端负责上传/下载文件，识别同步文件夹中的文件更改，以及处理由于离线或并发更新引起的冲突。
- 客户端正在主动监视文件夹中文件中发生的所有更新或更改。
- 为了处理文件元数据更新（例如文件名、大小、修改日期等），该客户端与消息服务和同步服务交互。
- 它还与远程云存储（Amazon S3 或任何其他云服务）交互以存储实际文件并提供文件夹同步。
讨论客户端组件
- Watcher负责监视同步文件夹中用户执行的所有活动，例如创建、更新或删除文件/文件夹。如果在文件或文件夹中执行了任何操作，它会通知索引器和分块器。
- Chunker将文件分成多个称为块的小块，并使用这些块的唯一 id 或哈希将其上传到云存储。要重新创建文件，可以将这些块连接在一起。对于文件中的任何更改，分块算法会检测被修改的特定块，并且仅将该特定部分/块保存到云存储。它减少了云中的带宽使用、同步时间和存储空间。
- Indexer负责在收到来自观察者的通知时更新内部数据库（对于在文件夹/文件中执行的任何操作）。它从分块器接收块的 URL 以及散列，并使用修改后的块更新文件。一旦块成功提交到云存储，索引器就会使用消息队列服务与同步服务进行通信。
- 内部数据库存储所有文件和块信息、它们的版本以及它们在文件系统中的位置。
讨论其他组件
1.元数据数据库
元数据数据库维护各种块的索引。该信息包含文件/块名称、它们的不同版本以及用户和工作区的信息。您可以使用 RDBMS 或 NoSQL，但要确保满足数据一致性属性，因为多个客户端将处理同一个文件。使用 RDBMS，一致性没有问题，但使用 NoSQL，您将获得最终的一致性。如果您决定使用 NoSQL，那么您需要对不同的数据库进行不同的配置（例如，Cassandra 复制因子给出了一致性级别）。
关系数据库难以扩展，因此如果您使用 MySQL 数据库，则需要使用数据库分片技术（或主从技术）来扩展应用程序。在数据库分片中，您需要添加多个 MySQL 数据库，但很难管理这些数据库以进行任何更新或将添加到数据库中的任何新信息。为了克服这个问题，我们需要围绕分片数据库构建一个边缘包装器。此边缘包装器提供 ORM，客户端可以轻松使用此边缘包装器的 ORM 与数据库交互（而不是直接与数据库交互）。
2. 消息队列服务
消息服务队列将负责客户端和同步服务之间的异步通信。
以下是消息队列服务的主要要求。
- 能够处理大量读取和写入请求。
- 将大量消息存储在高度可用且可靠的队列中。
- 高性能和高可扩展性。
- 为同步服务的多个实例提供负载平衡和弹性。
服务中有两种类型的消息队列。
- 请求队列：这将是一个在所有客户端之间共享的全局请求队列。每当客户端收到文件/文件夹中的任何更新或更改时，它都会通过请求队列发送请求。此请求由同步服务接收以更新元数据数据库。
- 响应队列：每个客户端都会有单独的响应队列。同步服务通过这个响应队列广播更新，这个响应队列将更新的消息传递给每个客户端，然后这些客户端将相应地更新它们各自的文件。即使客户端与 Internet 断开连接，消息也永远不会丢失（使用消息队列服务的好处）。
我们正在为 n 个客户端创建 n 个响应队列，因为一旦客户端接收到消息，消息就会从队列中删除，我们需要将更新的消息共享给各个订阅的客户端。
3. 同步服务
客户端与同步服务通信以从云存储接收最新更新或将最新请求/更新发送到云存储。
同步服务从消息服务的请求队列接收请求，并用最新的更改更新元数据数据库。此外，同步服务通过响应队列向其他客户端（如果有多个客户端）广播最新更新，以便其他客户端的索引器可以从云存储中取回块并使用最新更新重新创建文件。它还使用元数据数据库中存储的信息更新本地数据库。如果客户端一段时间未连接到 Internet 或离线，它会在上线后立即轮询系统以获取新更新。
4. 云存储
您可以使用任何云存储服务（例如 Amazon S3）来存储用户上传的文件块。对于在文件/文件夹中执行的任何操作，客户端使用云提供商提供的 API 与云存储进行通信。
许多候选人更害怕这一轮而不是编码轮，因为他们不知道在有限的时间内应该涵盖哪些主题和权衡。首先，请记住，系统设计回合是非常开放的，没有标准答案之类的东西。即使是同样的问题（ System Design Dropbox ），你也会与不同的面试官进行不同的讨论。
GeeksforGeeks 系统设计课程
想在领先的科技公司获得软件开发人员/工程师的工作吗？或 想要从 SDE I 平稳过渡到 SDE II 或高级开发人员配置文件？如果是，那么您需要深入了解系统设计世界！对系统设计概念的正确掌握非常重要，尤其是对于工作专业人士而言，要在技术面试中获得比其他人急需的优势。
这就是为什么 GeeksforGeeks 为您提供以深度面试为中心的系统设计直播课程，帮助您准备与 Google、亚马逊、Adobe、优步和其他基于产品的公司的系统设计相关的问题。