Архитектура Dropbox - вопрос на собеседовании по проектированию системы

Дизайн системы Dropbox …. Вы могли использовать эту службу хостинга файлов несколько раз, чтобы загружать и делиться файлами или изображениями, но что, если кто-то попросит вас разработать эту гигантскую систему всего за 45 минут?

Да, это то, что вы должны делать во время цикла собеседований по проектированию вашей системы. Мы не шутим, но вам нужно рассказать о своем подходе к проектированию такой системы, как Dropbox (в течение 45 минут или меньше), над которой в течение десяти лет работают сотни инженеров-программистов. Dropbox Дизайн системы (или дизайн диска Google или любой другой службы обмена и загрузки файлов) - довольно частый вопрос раунда проектирования системы.

В этом блоге мы обсудим, как создать веб-сайт, такой как Dropbox или Google Drive, но прежде чем мы продолжим, мы хотим, чтобы вы прочитали статью «Как взломать дизайн системы во время интервью?». Это даст вам представление о том, как выглядит этот раунд, что вы должны будете делать в этом раунде и каких ошибок следует избегать перед интервьюером.

Теперь давайте перейдем к прямому вопросу: «Как бы вы спроектировали Dropbox?»

Как бы вы спроектировали Dropbox?

Не сразу вдавайтесь в технические подробности, когда вам задают этот вопрос в интервью. Не идите в одну сторону, это только создаст путаницу между вами и интервьюером. Большинство кандидатов делают здесь ошибки и сразу же начинают перечислять набор инструментов, фреймворков или баз данных. Помните, что вашему интервьюеру нужны высокоуровневые идеи о том, как вы решите проблему. Неважно, какие инструменты вы будете использовать, но как вы определяете проблему, как вы разрабатываете решение и как вы анализируете проблему шаг за шагом.
В этом блоге вместо того, чтобы много говорить о веб-сервисах, мы будем предполагать, что на вашем компьютере или системе установлен клиент синхронизации, и этот клиент всегда просматривает определенные папки синхронизации, в которых он всегда отслеживает изменения в файлы и загружает его. Кроме того, мы не будем говорить о том, как построить облачное хранилище. Мы будем использовать некоторые облачные сервисы хранения, такие как Amazon S3, или любые другие сервисы хранения, которые хранят файл в облаке.

1. Обсудите основные функции

Прежде чем приступить к решению, всегда уточняйте все предположения, которые вы делаете в начале собеседования. Задавайте вопросы, чтобы определить объем системы. Это устранит первоначальные сомнения, и вы узнаете, какие конкретные детали интервьюер хочет учесть в этой услуге. Итак, начните с основных функций Dropbox, чтобы обсудить их с интервьюерами. Если интервьюеры захотят добавить еще несколько функций (например, интеграцию с API), они сообщат вам об этом.

• Пользователь должен иметь возможность загружать / скачивать, обновлять и удалять файлы.
• Управление версиями файлов (История обновлений)
• Синхронизация файлов и папок

2. Трафик

• 12+ миллионов уникальных пользователей
• 100 миллионов запросов в день с большим количеством операций чтения и записи.

3. Обсудите формулировку проблемы.

Многие люди предполагают, что при разработке Dropbox все, что им нужно сделать, это использовать некоторые облачные сервисы, загрузить файл и загрузить файл, когда захотят, но это не так, как это работает. Основная проблема: « Где и как сохранять файлы? «.

Предположим, вы хотите поделиться файлом любого размера (маленьким или большим) и загружаете его в облако. До сих пор все в порядке, но позже, если вам нужно будет обновить свой файл, не рекомендуется редактировать файл и снова и снова загружать весь файл в облако. Причина в том ...

• Больше пропускной способности и использования облачного пространства: для обеспечения истории файлов вам необходимо сохранить несколько версий файлов. Для этого требуется больше полосы пропускания и больше места в облаке. Даже для небольших изменений в вашем файле вам придется снова и снова создавать резервную копию и передавать весь файл в облако, что не является хорошей идеей.
• Задержка или использование параллелизма: вы также не можете оптимизировать время. На загрузку одного файла целиком уйдет больше времени, даже если вы внесете в него небольшие изменения. Также невозможно использовать параллелизм для загрузки / выгрузки файлов с использованием многопоточности или нескольких процессов.

Обсудить решение (высокоуровневое решение)

Мы можем разбить файлы на несколько частей, чтобы решить проблему, о которой мы говорили выше. Нет необходимости загружать / скачивать целый файл после внесения каких-либо изменений в файл. Вам просто нужно сохранить обновленный фрагмент (это займет меньше памяти и времени). Будет проще хранить разные версии файлов в разных частях.

Мы рассмотрели один файл, который разделен на несколько частей. Если файлов несколько, нам нужно знать, какие фрагменты какому файлу принадлежат. Чтобы сохранить эту информацию, мы создадим еще один файл, названный файлом метаданных . Этот файл содержит индексы блоков (имена блоков и информацию о порядке). Вам нужно указать хэш фрагментов (или некоторую ссылку) в этом файле метаданных, и вам необходимо синхронизировать этот файл с облаком. Мы можем загрузить файл метаданных из облака, когда захотим, и мы можем воссоздать файл, используя различные фрагменты.

Теперь давайте поговорим о различных компонентах для полного решения по проектированию системы службы Dropbox.

Предположим, у нас есть клиент, установленный на нашем компьютере (приложение, установленное на вашем компьютере), и этот клиент состоит из 4 основных компонентов. Эти основные компоненты - это Watcher, Chunker, Indexer и Internal DB. Мы рассмотрели только одного клиента, но может быть несколько клиентов, принадлежащих одному пользователю с одинаковыми базовыми компонентами.

• Клиент отвечает за загрузку / загрузку файлов, определение изменений файлов в папке синхронизации и обработку конфликтов из-за автономных или одновременных обновлений.
• Клиент активно следит за папками на предмет всех обновлений или изменений, происходящих в файлах.
• Для обработки обновлений метаданных файла (например, имени файла, размера, даты изменения и т. Д.) Этот клиент взаимодействует со службами обмена сообщениями и службой синхронизации.
• Он также взаимодействует с удаленным облачным хранилищем (Amazon S3 или любыми другими облачными сервисами) для хранения фактических файлов и обеспечения синхронизации папок.

Обсудить клиентские компоненты

• Watcher отвечает за мониторинг папки синхронизации для всех действий, выполняемых пользователем, таких как создание, обновление или удаление файлов / папок. Он дает уведомление индексатору и блоку обработки, если какие-либо действия выполняются в файлах или папках.
• Chunker разбивает файлы на несколько небольших частей, называемых кусками, и загружает их в облачное хранилище с уникальным идентификатором или хешем этих фрагментов. Чтобы воссоздать файлы, эти фрагменты можно объединить. Для любых изменений в файлах алгоритм фрагментирования обнаруживает конкретный фрагмент, который был изменен, и сохраняет только эту конкретную часть / фрагменты в облачном хранилище. Это сокращает использование полосы пропускания, время синхронизации и пространство для хранения в облаке.
• Индексатор отвечает за обновление внутренней базы данных при получении уведомления от наблюдателя (для любых действий, выполняемых в папках / файлах). Он получает URL-адрес фрагментов из фрагмента вместе с хешем и обновляет файл, добавляя измененные фрагменты. Индексатор взаимодействует со службой синхронизации с помощью службы очереди сообщений после успешной отправки фрагментов в облачное хранилище.
• Внутренняя база данных хранит информацию обо всех файлах и фрагментах, их версиях и их местонахождении в файловой системе.

Обсудите другие компоненты

1. База данных метаданных

База данных метаданных поддерживает индексы различных фрагментов. Информация содержит имена файлов / блоков, их различные версии, а также информацию о пользователях и рабочей области. Вы можете использовать СУБД или NoSQL, но убедитесь, что вы соответствуете свойству согласованности данных, потому что несколько клиентов будут работать с одним и тем же файлом. С РСУБД нет проблем с согласованностью, но с NoSQL вы в конечном итоге получите согласованность. Если вы решите использовать NoSQL, вам необходимо выполнить разные конфигурации для разных баз данных (например, коэффициент репликации Cassandra дает уровень согласованности).

Реляционные базы данных сложно масштабировать, поэтому, если вы используете базу данных MySQL, вам необходимо использовать технику сегментирования базы данных (или методику «ведущий-ведомый») для масштабирования приложения. При сегментировании баз данных вам необходимо добавить несколько баз данных MySQL, но будет сложно управлять этими базами данных для любого обновления или для любой новой информации, которая будет добавлена в базы данных. Чтобы решить эту проблему, нам нужно создать граничную оболочку вокруг сегментированных баз данных. Эта граничная оболочка предоставляет ORM, и клиент может легко использовать ORM этой граничной оболочки для взаимодействия с базой данных (вместо прямого взаимодействия с базами данных).

2. Служба очереди сообщений

Очередь службы обмена сообщениями будет отвечать за асинхронную связь между клиентами и службой синхронизации.

Ниже приведены основные требования к службе очереди сообщений.

• Возможность обрабатывать большое количество запросов на чтение и запись.
• Храните большое количество сообщений в высокодоступной и надежной очереди.
• Высокая производительность и масштабируемость.
• Обеспечивает балансировку нагрузки и эластичность для нескольких экземпляров службы синхронизации.

В сервисе будет два типа очередей обмена сообщениями.

• Очередь запросов: это будет глобальная очередь запросов, совместно используемая всеми клиентами. Всякий раз, когда клиент получает какое-либо обновление или изменения в файлах / папке, он отправляет запрос через очередь запросов. Этот запрос получен службой синхронизации для обновления базы данных метаданных.
• Очередь ответов: будет отдельная очередь ответов, соответствующая отдельным клиентам. Служба синхронизации транслирует обновление через эту очередь ответов, и эта очередь ответов будет доставлять обновленные сообщения каждому клиенту, а затем эти клиенты будут обновлять свои соответствующие файлы соответственно. Сообщение никогда не будет потеряно, даже если клиент будет отключен от Интернета (преимущество использования службы очереди сообщений).

  Мы создаем n очередей ответов для n клиентов, потому что сообщение будет удалено из очереди, как только оно будет получено клиентом, и нам нужно поделиться обновленным сообщением с различными подписанными клиентами.

3. Служба синхронизации

Клиент связывается со службами синхронизации либо для получения последних обновлений из облачного хранилища, либо для отправки последних запросов / обновлений в облачное хранилище.

Служба синхронизации получает запрос из очереди запросов служб обмена сообщениями и обновляет базу данных метаданных с учетом последних изменений. Кроме того, служба синхронизации транслирует последнее обновление другим клиентам (при наличии нескольких клиентов) через очередь ответов, чтобы индексатор другого клиента мог получить обратно фрагменты из облачного хранилища и воссоздать файлы с последним обновлением. Он также обновляет локальную базу данных информацией, хранящейся в базе данных метаданных. Если клиент не подключен к Интернету или не подключен к Интернету в течение некоторого времени, он опрашивает систему на наличие новых обновлений, как только он выходит в Интернет.

4. Облачное хранилище

Вы можете использовать любые облачные сервисы хранения, такие как Amazon S3, для хранения фрагментов файлов, загруженных пользователем. Клиент связывается с облачным хранилищем для любых действий, выполняемых в файлах / папках, с помощью API, предоставленного облачным провайдером.

Многие кандидаты боятся этого раунда больше, чем раунда кодирования, потому что они не имеют представления о том, какие темы и компромиссы им следует охватить в течение этого ограниченного периода времени. Во-первых, помните, что раунд разработки системы является чрезвычайно открытым и не существует такого понятия, как стандартный ответ. Даже по одному и тому же вопросу ( Dropbox о дизайне системы ) у вас будет разное обсуждение с разными интервьюерами.

Вниманию читателя! Не прекращайте учиться сейчас. Получите все важные концепции системного дизайна с отраслевыми экспертами. Присоединяйтесь к курсу системного дизайна, чтобы посещать живые занятия.