Слияние кода завершено, страница обновится автоматически
Результаты интеграции
Доступность. Паттерны
Система доменных имён (DNS)
Сеть доставки контента (CDN)
Балансировщик нагрузки
Обратный прокси (веб-сервер)
Уровень приложений
База данных
Кэш
Асинхронная обработка
Коммуникация
Безопасность
Дополнение
В процессе
Кредит
Контактная информация
Лицензия
Темы, которые следует изучить в зависимости от продолжительности обучения (короткое, среднее, длинное)
Вопрос: Нужно ли делать всё, что здесь перечислено, чтобы пройти собеседование?
Ответ: Нет, вам не нужно делать всё перечисленное здесь.
То, о чём будут спрашивать на собеседовании, зависит от следующих условий:
Кандидаты с большим опытом обычно должны иметь более глубокие знания в области системного проектирования. Системные архитекторы и руководители команд должны обладать более глубоким пониманием, чем их коллеги. В ведущих технологических компаниях часто проводят несколько раундов собеседований по дизайну системы.
Рекомендуется начать с широкого охвата и постепенно сужать его, углубляясь в различные темы системного проектирования. Знание различных тем системного проектирования может быть полезным. Следующее руководство по обучению можно адаптировать для ваших целей, учитывая время, опыт, должность, компанию, в которую вы подаёте заявку.
| Короткое обучение | Среднее обучение | Длинное обучение | |
|---|---|---|---|
| Чтение о системном проектировании и получение общего представления о работе системы | +1 | +1 | +1 |
| Прочитать несколько страниц из следующих ссылок и узнать о инженерных блогах компаний, в которые вы подаете заявку | +1 | +1 | +1 |
| Прочитайте несколько страниц следующей ссылки и узнайте об архитектуре в реальном мире | +1 | +1 | +1 |
| Повторите, как подготовиться к собеседованию по системному дизайну | +1 | +1 | +1 |
| Решите некоторые вопросы собеседования по системному дизайну | Некоторые | Многие | Большинство |
| Решите несколько задач объектно-ориентированного проектирования | Некоторые | Многие | Большинство |
| Повторение других примеров вопросов на собеседовании по системному дизайну | Некоторые | Многие | Большинство |
Собеседование по системному проектированию — это открытый разговор (вопросы, на которые нельзя ответить «да» или «нет»). Вам будет предложено самостоятельно построить диалог.
Вы можете построить обсуждение, следуя следующим шагам. Чтобы сделать этот процесс более надёжным, рекомендуется прочитать следующий раздел [примеры вопросов и решения для собеседования по системному проектированию] в соответствии с этими указаниями.
Узнайте требования к спецификации системы и определите проблемные области. Задайте вопросы, чтобы уточнить использование примеров и ограничений. Также обсудите предполагаемые оценки.
В конфигурации активный-активный оба сервера распределяют нагрузку, обрабатывая трафик.
Если эти серверы публичные, то DNS должен знать публичные IP-адреса обоих серверов. Если они приватные, то логика приложения должна быть осведомлена о данных обоих серверах.
Активный-активный failover также называют мастер-мастер failover.
Недостатки:
Эта тема подробнее рассматривается в разделе «База данных»:
Доменная система имён (DNS) переводит доменные имена, такие как www.example.com, в IP-адрес.
DNS представляет собой иерархическую структуру, где несколько авторизованных серверов расположены на верхних уровнях. Ваш маршрутизатор или интернет-провайдер предоставляет информацию о том, к какому DNS-серверу обращаться при поиске. Более низкие уровни DNS-серверов кэшируют эту информацию. Однако она может устаревать из-за задержки распространения. Результаты DNS кэшируются вашим браузером или операционной системой на определённый период времени (time to live (TTL), установленный срок).
Такие сервисы, как CloudFlare и Route 53, предоставляют управляемые DNS-сервисы. Некоторые DNS-сервисы используют различные методы для распределения трафика:
Недостатки DNS:
Сеть доставки контента (CDN) — это сеть прокси-серверов, расположенных по всему миру, которая доставляет контент пользователям с ближайшего сервера. Например, Amazon CloudFront также может доставлять динамический контент, хотя обычно статические файлы, такие как HTML/CSS/JS, изображения и видео, передаются через CDN. Сайт сообщает клиентам, с каким сервером взаимодействовать через DNS.
Использование CDN значительно улучшает производительность по двум причинам:
Push CDN работает так, что новые данные автоматически загружаются на CDN, когда на сервере происходят обновления. Контент подготавливается и загружается непосредственно на CDN, а URL настраивается так, чтобы указывать на CDN. Это минимизирует трафик, но приводит к тому, что все данные загружаются сразу, что может привести к переполнению хранилища.
Push CDN подходит для сайтов с небольшим трафиком или тех, где контент обновляется редко. В этом случае контент загружается на CDN один раз и остаётся там.
Pull CDN загружает новый контент с сервера при первом запросе пользователя. Контент сохраняется на собственном сервере, а затем URL изменяется, указывая на CDN. В результате обработка запросов замедляется до тех пор, пока контент не будет кэширован на CDN.
TTL определяет, как долго контент будет храниться в кэше CDN. Хотя pull CDN минимизирует использование пространства на CDN, существует риск избыточного трафика, если устаревшие файлы будут загружены до обновления.
Для крупных сайтов с большим трафиком pull CDN может быть предпочтительнее. Трафик обычно состоит в основном из недавно запрошенных данных, которые уже есть на CDN.
(Изображение отсутствует.) Лоуд-балансер распределяет входящие запросы от клиентов между приложением, сервером или базой данных.
Задачи лоуд-балансёра:
Лоуд-балансеры могут быть реализованы с помощью дорогостоящего оборудования или программного обеспечения, такого как HAProxy.
Преимущества использования лоуд-балансёров:
Трафик распределяется с использованием различных метрик:
Балансировка на транспортном уровне (Layer 4) основана на анализе информации транспортного уровня, такой как IP-адреса источника и назначения, номера портов. Балансировщик принимает сетевой пакет от вышестоящего сервера и перенаправляет его на нижестоящий сервер. Это позволяет реализовать преобразование сетевых адресов (NAT).
Балансировка на прикладном уровне (Layer 7) учитывает содержимое запроса, включая заголовки, сообщения и куки. Балансировщик обрабатывает сетевой трафик, анализирует запрос и выбирает подходящий сервер для обработки. Например, видеотрафик может направляться напрямую на сервер, где хранятся данные, а более чувствительные операции, такие как обработка платежей, могут обрабатываться на более защищённых серверах.
Балансировщики на уровне приложений обеспечивают большую гибкость, но требуют больше времени и ресурсов для работы. Однако современные универсальные аппаратные решения могут обеспечить только базовую производительность.
Горизонтальное масштабирование позволяет улучшить производительность и доступность системы за счёт добавления дополнительных серверов. Добавление универсальных машин проще и дешевле, чем масштабирование до более мощных серверов (вертикальное масштабирование). Также легче найти специалистов, способных работать с универсальным оборудованием.
Недостатки горизонтального масштабирования включают увеличение сложности системы и необходимость клонирования серверов. Серверы должны быть без состояния, чтобы избежать проблем с сохранением пользовательских данных и сессий. Сессии и другие данные должны храниться в централизованной базе данных или кэше.
К недостаткам лоуд-балансировщика относятся возможность стать узким местом системы при недостаточной настройке и усложнение системы при попытке устранить единую точку отказа путём добавления балансировщика.
Другие источники информации:
Обратный прокси-сервер объединяет внутренние сервисы и предоставляет унифицированный интерфейс для внешних пользователей. Запросы от клиентов направляются на соответствующий сервер, после чего ответ возвращается клиенту через обратный прокси.
Преимущества обратного прокси:
Разница между лоуд-балансировщиком и обратным прокси заключается в том, что балансировщик полезен при наличии нескольких серверов, тогда как обратный прокси обеспечивает дополнительные функции безопасности, сжатия и кэширования. Масштабируемость, доступность и стабильность: подходы к проектированию
Недостатки Master-Master репликации:
Недостатки репликации:
Другие ресурсы:
Федерация (или разделение функций)
Федерация разделяет базу данных по функциям, например, на форум, пользователей и продукты. Это уменьшает трафик записи и чтения для каждой базы данных и сокращает задержку репликации. Меньший размер баз данных позволяет хранить больше данных в памяти, повышая локальность кэша и, следовательно, коэффициент попаданий в кэш. Отсутствие последовательной записи на один центральный мастер позволяет выполнять параллельную запись и потенциально улучшить пропускную способность.
Недостатки федерации:
Другие ресурсы:
Шардирование
Шардирование разделяет данные так, что каждый узел хранит только часть данных. Например, в пользовательской базе данных с увеличением числа пользователей на кластер добавляется больше шардов.
Преимущества шардирования схожи с преимуществами федерации: оно снижает трафик чтения и записи, уменьшает репликацию и увеличивает коэффициент попадания в кэш. Индексы также могут быть уменьшены, что обычно приводит к улучшению производительности и скорости запросов. Однако без функции репликации потеря данных неизбежна, хотя наличие нескольких активных шардов минимизирует этот риск. Как и в случае с федерацией, отсутствие центрального мастера позволяет выполнять параллельную запись, потенциально улучшая пропускную способность.
Распространённым методом шардирования пользовательских таблиц является использование инициалов фамилий пользователей или их географического расположения.
Недостатки шардирования:
Другие ресурсы:
Денормализация
Денормализация стремится улучшить производительность чтения за счёт некоторого снижения производительности записи. Она допускает избыточное копирование данных в несколько таблиц вместо сложных объединений, которые могут потребовать значительных вычислительных ресурсов. Некоторые RDBMS, такие как PostgreSQL и Oracle, поддерживают эту избыточность и обеспечивают согласованность с помощью материализованных представлений.
Объединение данных, распределённых по различным центрам обработки данных с использованием таких методов, как федерация или шардирование, может быть сложной задачей. Денормализация упрощает этот процесс.
Во многих системах количество операций чтения может значительно превышать количество операций записи. Выполнение сложных операций соединения для обеспечения чтения может быть дорогостоящим с точки зрения вычислений и занимать значительное время на диске.
Недостатки денормализации:
Если база данных не нормализована и должна обрабатывать чрезмерные записи, она может уступать в производительности нормализованной базе данных.
SQL-тюнинг — это область, требующая обширных знаний, и существует множество книг по этой теме.
Очень важно выявить узкие места и провести симуляцию, установив бенчмарки и профилирование.
Проведение бенчмарков и профилирования позволит выбрать следующие варианты оптимизации:
Другие источники информации и страницы: SQL-тюнинг
NoSQL представляет собой набор элементов данных, представленных в виде key-value store, document-store, wide column store или graph database. Данные обычно не нормализованы, и объединение выполняется на стороне приложения. Большинство NoSQL не поддерживает истинные ACID-транзакции и предпочитает поведение, ориентированное на согласованность результатов.
BASE часто используется для описания свойств баз данных NoSQL. В отличие от CAP-теоремы, BASE отдаёт предпочтение доступности перед консистентностью.
Помимо выбора между SQL и NoSQL, полезно понимать, какой тип NoSQL лучше всего подходит для различных сценариев использования. Этот раздел рассматривает key-value store, документ-хранилище, wide column store и графовые базы данных.
Резюме: хеш-таблица
Key-value stores обычно обеспечивают O(1) чтение и запись и поддерживаются памятью или SSD. Хранилища данных сохраняют ключи в лексикографическом порядке, обеспечивая эффективное извлечение ключей. Key-value stores могут хранить метаданные вместе со значениями.
Key-value stores предлагают высокую производительность и используются в случаях, когда данные имеют простую модель и быстро меняются, например, в качестве быстрого кэша в памяти или слоя. Ограниченные функции делают их подходящими только для простых операций, и дополнительные функции обработки должны быть реализованы на уровне приложений.
Key-value stores являются основой для более сложных систем, таких как document store и graph databases.
Key-value database.
Недостатки key-value table по сравнению с nullable columns или.
Архитектура Redis.
Memcache architecture. Документ-ориентированное хранилище
Обзор: хранилище, в котором документы (XML, JSON, двоичные и т. д.) сохраняются как значения в ключевом хранилище. В документ-ориентированном хранилище предоставляется API или язык запросов, основанный на внутренней структуре документа. Примечание: во многих ключевых хранилищах документов также есть функции для обработки метаданных значений, что делает границу между двумя типами хранилищ размытой.
Для реализации этого документы организованы в коллекции, теги, метаданные и каталоги. Документы могут быть сгруппированы вместе, но каждый из них может иметь совершенно разные поля.
Такие хранилища документов, как MongoDB и CouchDB, предоставляют сложные языки запросов, подобные SQL, для обработки сложных запросов. DynamoDB поддерживает как ключи, так и документы.
Документ-ориентированные хранилища обеспечивают высокую гибкость, поэтому они часто используются при работе с данными, которые часто меняются.
Другие ресурсы и страницы: Документ-ориентированные хранилища
— Документно-ориентированная база данных;
— Архитектура MongoDB;
— Архитектура CouchDB;
— Архитектура Elasticsearch.
Ширококолоночное хранилище
Обзор: базовая единица данных в ширококолоночных хранилищах — это столбец (пара «имя-значение»). Каждый столбец можно сгруппировать в семейство столбцов (аналогично таблицам SQL). Суперсемейство столбцов представляет собой набор семейств столбцов. Доступ к каждому столбцу осуществляется через ключ строки. Столбцы с одинаковыми ключами строк считаются одной строкой. Каждое значение включает временную метку для управления версиями и разрешения конфликтов.
Google представил Bigtable как первое ширококолоночное хранилище. Оно оказало влияние на такие проекты, как HBase с открытым исходным кодом, который часто используется с Hadoop, и Cassandra от Facebook. Хранилища, такие как BigTable, HBase и Cassandra, эффективно извлекают данные в заданном диапазоне ключей, сохраняя ключи в виде словаря.
Ширококолоночные хранилища обеспечивают высокую доступность и масштабируемость. Они часто используются для работы с очень большими наборами данных.
Другие ресурсы и страницы: Ширококолоночные хранилища
— SQL & NoSQL: краткая история;
— Архитектура Bigtable;
— Архитектура HBase;
— Архитектура Cassandra.
Графовая база данных
Обзор: в графовой базе данных каждый узел является записью, а каждая дуга определяет связь между двумя узлами. Графовые базы данных хорошо подходят для представления сложных отношений, таких как множество внешних ключей и многие ко многим.
Графовые базы данных эффективны для моделирования сложных моделей отношений, например, в службах социальных сетей. Поскольку они относительно новые и ещё не получили широкого распространения, поиск инструментов разработки и ресурсов может быть сложнее, чем другие методы. Многие графы доступны только через REST APIs.
Дополнительные ресурсы и страницы: Графовые базы данных
— Графовая база данных;
— Neo4j;
— FlockDB.
Дополнительная информация и ресурсы: NoSQL
— Объяснение базовой терминологии;
— Исследование и руководство по выбору NoSQL баз данных;
— Масштабируемость;
— Введение в NoSQL;
— Паттерны NoSQL.
SQL или NoSQL?
Причины выбрать SQL:
— Структурированные данные;
— Строгая схема;
— Реляционные данные;
— Необходимость сложных объединений;
— Транзакции;
— Когда паттерн масштабирования ясен;
— Более полное сообщество разработчиков, код и т.д.;
— Очень быстрый поиск данных с помощью индексов.
Причины выбрать NoSQL:
— Полуструктурированные данные;
— Динамическая или гибкая схема;
— Нереляционные данные;
— Нет необходимости в сложных объединениях;
— Хранить много ТБ (или ПБ) данных;
— Способность выдерживать интенсивные и крупномасштабные нагрузки на данные. IOPS демонстрирует чрезвычайно высокую пропускную способность
Примеры данных, подходящих для NoSQL:
Кэш может сократить время загрузки страницы и снизить нагрузку на серверы и базы данных. В этой модели диспетчер сначала проверяет, был ли запрос отправлен ранее, и получает последний результат.
База данных требует распределённой записи и чтения по своим разделам, но популярные элементы могут исказить это распределение и стать узким местом всей системы. Помещая кэш перед базой данных, можно поглотить неравномерные нагрузки и резкие увеличения трафика.
Кэширование может быть установлено на стороне клиента, например, в операционной системе или браузере, на сервере или в независимом слое кэширования.
CDN также можно рассматривать как один из видов кэширования.
Такие кэширующие веб-серверы, как обратные прокси и Varnish, могут напрямую доставлять статические и динамические материалы. Веб-сервер также может кэшировать запросы и отвечать на них без подключения к серверу приложений.
Базы данных обычно имеют настройки кэширования, подходящие для типичного использования. Эти настройки можно настроить в соответствии с конкретными требованиями для повышения производительности.
Memcached и другие кэши в оперативной памяти, такие как Redis, представляют собой хранилища «ключ-значение» между приложением и хранилищем данных. Поскольку данные хранятся в ОЗУ, они значительно быстрее, чем данные, хранящиеся на диске в обычных базах данных. Однако объём ОЗУ ограничен, поэтому алгоритмы аннулирования кэша, такие как LRU (наименее недавно использованные), удаляют «холодные» записи и сохраняют «горячие» данные в ОЗУ.
Redis также предлагает дополнительные функции:
Существует множество уровней кэширования, но все они можно разделить на две основные категории: уровень запросов к базе данных и объектный уровень:
Как правило, следует избегать файлового кэширования, поскольку оно может затруднить автоматическое масштабирование.
При запросах к базе данных всегда используйте запрос в качестве ключа для хеширования и сохранения результата в кэше. Этот подход имеет проблемы с истечением срока действия кэша:
Рассмотрим данные как объекты и сохраним их в приложении. Приложение создаёт экземпляры классов или структуры данных из наборов данных, полученных из базы данных:
Что кэшировать:
Когда обновлять кэш:
Необходимо учитывать ограничения по объёму кэша.
Приложение обрабатывает операции чтения и записи в хранилище данных. Кэш не взаимодействует напрямую со хранилищем. Приложение выполняет следующие действия:
Этот подход часто используется с Memcached.
Последующие операции чтения из кэша выполняются быстро. Кэширование вне основной системы также известно как ленивая загрузка. Это предотвращает переполнение кэша данными, которые не запрашивались.
Недостатки кэширования вне основной системы:
Приложение использует кэш в качестве основного хранилища данных и выполняет операции чтения и записи непосредственно в нём. Кэш синхронно записывает данные в базу данных.
def set_user(user_id, values):
user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
cache.set(user_id, user)
Light-through (Light-Through) — это операция, которая в целом является медленной из-за процесса записи, но чтение данных, которые были только что записаны, происходит быстро. Для пользователей обычно допустимо большее время ожидания при обновлении данных по сравнению с временем чтения. Данные в кэше сохраняются в последней версии.
Light-Behind (Light-Back) — приложение выполняет следующие действия:
Добавляет и обновляет записи в кэше.
Асинхронно записывает данные в хранилище, что улучшает производительность записи.
Недостатки Light-Behind:
Refresh Ahead — можно настроить автоматическое обновление всех недавно использованных кэшированных записей до истечения срока их действия.
Если можно точно предсказать, какие элементы потребуются в будущем, можно сократить задержку по сравнению с подходом с использованием только кэша.
Асинхронный рабочий процесс — это метод обработки тяжёлых задач отдельно от основного потока, чтобы избежать перегрузки запросов, если они выполняются последовательно. Асинхронные рабочие процессы также полезны для предварительной обработки данных, требующих времени, например, сбор данных.
Очередь сообщений принимает, сохраняет и доставляет сообщения. Если обработка слишком медленная для выполнения в реальном времени, рассмотрите следующий рабочий процесс с использованием очереди сообщений:
Обработка пользователя не останавливается, и задания выполняются в фоновом режиме. В то же время клиент может выполнять небольшие задачи, такие как показ твитов, которые выглядят так, будто они уже были отправлены всем подписчикам, хотя на самом деле они ещё не доставлены всем.
Redis хорош для простых посредников сообщений, но есть риск потери сообщений.
RabbitMQ широко используется, но требует запуска собственного узла, который соответствует протоколу AMQP.
Amazon SQS также является вариантом, но имеет высокую задержку и может дублировать доставку сообщений.
Очередь задач принимает задачу и связанные с ней данные, обрабатывает их и возвращает результат. Очередь задач может также использоваться для планирования и выполнения очень тяжёлых заданий в фоновом режиме.
Celery поддерживает планирование и Python.
Если размер очереди становится слишком большим, память может быть меньше, чем размер очереди, что приводит к ошибкам кэша и доступу к диску, что снижает производительность. Backpressure позволяет ограничить размер очереди и предотвратить перегрузку сервера или ответ HTTP 503, когда очередь заполнена. Клиент может повторить попытку позже, используя экспоненциальный откат.
В тексте запроса присутствуют фрагменты кода на языке Python, ссылки на внешние ресурсы, специальные символы и форматирование, которое не поддерживается в ответе. Ответ представляет собой перевод основной части текста без учёта этих элементов. Удаленный вызов процедур (RPC)
При использовании RPC клиент может вызывать процедуры, которые выполняются на удаленном сервере или в другом адресном пространстве. Процедура кодируется без указания деталей того, как будет происходить связь между клиентом и сервером, подобно локальному вызову. Удаленные вызовы обычно медленнее локальных вызовов и могут быть менее надежными, поэтому рекомендуется отличать RPC-вызовы от локальных вызовов. Популярными фреймворками для RPC являются Protobuf, Thrift и Avro.
В RPC используется модель запрос-ответ:
Пример вызовов RPC:
GET /someoperation?data=anId
POST /anotheroperation
{
"data":"anId";
"anotherdata": "another value"
}
RPC фокусируется на поведении. RPC часто используется из-за его внутренних коммуникационных характеристик. Это позволяет создавать собственные нативные вызовы, если это необходимо.
Вызов нативной библиотеки (или SDK) необходим в следующих случаях:
HTTP API, соответствующие протоколу REST, широко используются в публичных API.
Недостатки RPC:
REST поддерживает архитектурный стиль клиент-сервер, где клиент выполняет операции над ресурсами, управляемыми сервером. Сервер предоставляет представление ресурсов или действий, с которыми можно работать. Все коммуникации должны быть без сохранения состояния и кэшируемыми.
Особенности RESTful интерфейса включают:
Примеры REST-вызовов:
GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
REST фокусируется на публикации данных. Он минимизирует связь между клиентом и сервером и часто используется в публичных API. REST использует более общие и унифицированные методы, такие как URI, представление через заголовки и GET, POST, PUT, DELETE, PATCH и другие HTTP-глаголы. Из-за своей безгосударственности REST хорошо подходит для горизонтального масштабирования и разделения.
Недостатки REST:
| Операция | RPC | REST |
|---|---|---|
| Регистрация | POST /signup | POST /persons |
| Отставка |
POST /resign { "personid": "1234" } |
DELETE /persons/1234 |
| Чтение информации о человеке | GET /readPerson?personid=1234 | GET /persons/1234 |
| Чтение списка предметов человека | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items |
| Добавление предмета в список предметов человека |
POST /addItemToUsersItemsList { "personid": "1234"; "itemid": "456" } |
POST /persons/1234/items { "itemid": "456" } |
| Обновление предмета | POST /modifyItem | |
| { | ||
| "itemid": "456"; | ||
| "key": "value" | ||
| } | PUT /items/456 | |
| { | ||
| "key": "value" | ||
| } |
| アイテム削除 | POST /removeItem { "itemid": "456" } | DELETE /items/456 |
Источник: Вы действительно знаете, почему вы предпочитаете REST вместо RPC?
Этот раздел нуждается в обновлении. Вклад, пожалуйста!
Безопасность — это обширная тема. Даже если у вас нет достаточного опыта или знаний в области безопасности, вам не нужно знать больше, чем основы, если только вы не претендуете на должность, требующую знаний в этой области.
Иногда необходимо оценить приблизительное значение. Например, сколько времени потребуется для создания эскизов 100 изображений с диска или сколько дисковой памяти будет использовано в этот момент.Таблица степеней двойки и значения задержки, которые должен знать каждый программист, могут оказаться полезными.
Степень Точное значение Приблизительное значение Bytes
---------------------------------------------------------------------------------
7 128
8 256
10 1024 1 thousand 1 KB
16 65,536 64 KB
20 1,048,576 1 million 1 MB
30 1,073,741,824 1 billion 1 GB
32 4,294,967,296 4 GB
40 1,099,511,627,776 1 trillion 1 TB
Latency Comparison Numbers
--------------------------
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns 14x L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy 10,000 ns 10 us
Send 1 KB bytes over 1 Gbps network 10,000 ns 10 us
Read 4 KB randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD
Read 1 MB sequentially from memory 250,000 ns 250 us
Round trip within same datacenter 500,000 ns 500 us
Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory
Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps 10,000,000 ns 10,000 us 10 ms 40x memory, 10X SSD
Read 1 MB sequentially from disk 30,000,000 ns 30,000 us 30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns
Полезные значения на основе таблицы:
Скорость последовательного чтения из основной памяти: 4 ГБ/с.
Можно облететь вокруг Земли 6-7 раз за 1 секунду.
Обмен данными между дата-центром и сервером можно осуществить 2000 раз за 1 секунду.
Визуальная таблица задержки.
| Вопрос | Ответ |
|---|---|
| Как разработать сервис синхронизации файлов наподобие Dropbox? | youtube.com |
| Как спроектировать поисковый движок наподобие Google? | queue.acm.org, stackexchange.com, ardendertat.com, stanford.edu |
| Как спроектировать масштабируемый веб-краулер наподобие Google? | quora.com |
| Как спроектировать Google Docs? | code.google.com, neil.fraser.name |
| Как спроектировать систему хранения данных типа «ключ-значение» наподобие Redis? | slideshare.net |
| Как спроектировать кэш-систему наподобие Memcached? | slideshare.net |
| Как спроектировать рекомендательную систему наподобие Amazon? | hulu.com, ijcai13.org |
| Как спроектировать сервис сокращения URL наподобие Bitly? | n00tc0d3r.blogspot.com |
| Как спроектировать чат-приложение наподобие WhatsApp? | highscalability.com |
| Как спроектировать фотосервис наподобие Instagram? | highscalability.com, highscalability.com |
| Как спроектировать новостную ленту наподобие Facebook? | quora.com, quora.com, slideshare.net |
| Как спроектировать временную шкалу наподобие Facebook? | facebook.com, highscalability.com |
| Как спроектировать чат наподобие Facebook? | erlang-factory.com, facebook.com |
| Как спроектировать графовый поиск наподобие Facebook? | facebook.com, facebook.com, facebook.com |
| Как спроектировать CDN наподобие CloudFlare? | cmu.edu |
| Как спроектировать функцию трендов наподобие Twitter? | michael-noll.com, snikolov .wordpress.com |
| Как спроектировать систему случайного генерирования ID? Определения основного языка текста запроса: |
Основной язык текста запроса — английский.
Перевод текста на русский язык:
Блог Твиттера (2010): анонс Snowflake. GitHub: твиттер/snowflake/.
UC Santa Barbara: исследования / технические отчёты / отчёты / 2005-23.pdf. Worcester Polytechnic Institute: документы / XMDV / документы / EDBT11-diyang.pdf.
High Scalability: блог (2009): как Google обслуживает данные из нескольких центров обработки данных.
Indie Flash Blog: как создать асинхронную многопользовательскую игру. Build New Games: многопользовательская игра в реальном времени.
Stuff with Stuff: журнал (2013): детский сборщик мусора. Вашингтон: курсы / CS / Вашингтон / CSEP521 / 07wi / prj / рик.pdf.
Статьи о том, как устроены системы в мире.
Не углубляйтесь в мелкие детали, которые занимают углы тяжёлых ящиков. Вместо этого:
| Тип | Система | Ссылка |
|---|---|---|
| Обработка данных | MapReduce — распределённая система обработки данных Google | research.google.com: архив / MapReduce-osdi04.pdf |
| Обработка данных | Spark — распределённая система обработки данных Databricks | slideshare.net: Apache Spark Architecture |
| Обработка данных | Storm — распределённая система обработки данных Twitter | slideshare.net: Storm |
| Хранилище данных | Bigtable — столбцовая ориентированная распределённая база данных Google | harvard.edu: чтение / море / гарвард / класс / cs239-w08 / чанг06bigtable.pdf |
| Хранилище данных | HBase — открытая реализация Bigtable | slideshare.net: введение в HBase |
| Хранилище данных | Cassandra — столбцовая ориентированная база данных Facebook | slideshare.net: Cassandra: введение, функции |
| Хранилище данных | DynamoDB — документно-ориентированная распределённая база данных Amazon | harvard.edu: читать / море / гарвард / класс / cs239-w08 / декандиа07dynamo.pdf |
| Хранилище данных | MongoDB — документно-ориентированная распределённая база данных | slideshare.net: Введение в MongoDB |
| Хранилище данных | Spanner — глобальная распределённая база данных Google | research.google.com: архив / spanner-osdi2012.pdf |
| Хранилище данных | Memcached — распределённая система кэширования памяти | slideshare.net: введение в memcached |
| Хранилище данных | Redis — распределённая система кэширования с постоянным хранением и несколькими типами значений | slideshare.net: введение в Redis |
| Файловая система | Google File System (GFS) — распределённая файловая система | research.google.com: архив / gfs-sosp2003.pdf |
| Файловая система | Hadoop File System (HDFS) — открытая версия GFS | apache.org: Hadoop: руководство по файловой системе |
| Разное | Chubby — сервис Google для блокировки слабосвязанных распределённых систем | research.google.com: архив / chubby-osdi06.pdf |
| Разное | Dapper — инфраструктура для отслеживания распределённых систем | research.google.com: архив / dapper-osdi09.pdf |
| Разное | Kafka — очередь сообщений Pub/sub от LinkedIn | slideshare.net: Tri-Hug: разговор о Kafka |
| Разное | Zookeeper — централизованная инфраструктура и сервисы для обеспечения синхронизации | slideshare.net: введение в Apache ZooKeeper |
| Добавить архитектуру | Contribute #contributing |
| Компания | Ссылка |
|---|---|
| Amazon | Amazon architecture |
| Cinchcast | Производство 1500 часов аудио каждый... day |
DataSift | Realtime datamining At 120,000 tweets per second
DropBox | How we've scaled Dropbox
ESPN | Operating At 100,000 duh nuh nuhs per second
Google | Google architecture
Instagram | 14 million users, terabytes of photos
Justin.tv | Justin.Tv's live video broadcasting architecture
Facebook | Масштабирование memcached в Facebook
TAO: Распределённое хранилище данных Facebook для социального графа
Хранение фотографий в Facebook
Flickr | Flickr architecture
Mailbox | От 0 до одного миллиона пользователей за 6 недель
Pinterest | От 0 До 10 миллиардов просмотров страниц в месяц
18 миллионов посетителей, 10-кратный рост, 12 сотрудников
Playfish | 50 миллионов ежемесячных пользователей и рост
PlentyOfFish | PlentyOfFish architecture
Salesforce | Как они обрабатывают 1,3 миллиарда транзакций в день
Stack Overflow | Stack Overflow architecture
TripAdvisor | 40M посетителей, 200M динамических просмотров страниц, 30TB данных
Tumblr | 15 миллиардов просмотров страниц в месяц
Twitter | Ускорение Twitter на 10 000 процентов
Как Twitter хранит 250 миллионов твитов в день с помощью MySQL
150M активных пользователей, 300K QPS, пожарный шланг 22 МБ/с
Временные шкалы в масштабе
Большие и малые данные в Twitter
Операции в Twitter: масштабирование более 100 миллионов пользователей
Uber | Масштабирование платформы Uber в реальном времени
WhatsApp | Архитектура WhatsApp, купленная Facebook за 19 миллиардов долларов
YouTube Масштабируемость YouTube
Масштабируемость и архитектура YouTube.
Возможно, на собеседовании вам зададут вопросы из этой же области.
Корпоративные инженерные блоги
Интервьюер может спросить о корпоративных инженерных блогах. Вот некоторые из них:
Текущая работа
В этом разделе продолжается работа над добавлением разделов и текущей работой. Рассматривается возможность добавления ссылок на инженерные блоги в этот раздел, а не сюда.
Благодарности
Благодарности и ссылки на страницы указаны в репозитории.
Особая благодарность:
Контактная информация
Не стесняйтесь обращаться ко мне, чтобы обсудить любые проблемы, вопросы или комментарии.
Мою контактную информацию можно найти на моём GitHub. ## License
Я предоставляю вам код и ресурсы в этом репозитории по лицензии с открытым исходным кодом. Поскольку это мой личный репозиторий, лицензия на мой код и ресурсы предоставляется мной, а не моим работодателем (Facebook).
Авторское право 2017 Донне Мартин
Международная лицензия Creative Commons Attribution 4.0 (CC BY 4.0)
http://creativecommons.org/licenses/by/4.0/
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )