Слияние кода завершено, страница обновится автоматически
Системный дизайн: руководство
Научитесь проектировать крупномасштабные системы.
Подготовьтесь к собеседованию по системному дизайну.
Умение проектировать масштабируемые системы поможет вам стать лучшим инженером.
Системный дизайн — обширная тема. В интернете можно найти огромное количество ресурсов, посвящённых принципам системного дизайна.
Это репозиторий представляет собой организованную коллекцию ресурсов, которые помогут вам научиться создавать масштабные системы.
Этот проект постоянно обновляется и является открытым исходным кодом.
Вклад приветствуется!
Помимо собеседований по кодированию, системный дизайн является обязательным компонентом процесса технического собеседования во многих технологических компаниях.
Практикуйте распространённые вопросы собеседования по системному дизайну и сравнивайте свои результаты с образцовыми решениями: обсуждениями, кодом и диаграммами.
Дополнительные темы для подготовки к собеседованию:
Предоставленные колоды флеш-карт Анки используют повторение через определённые промежутки времени, чтобы помочь вам запомнить ключевые концепции системного дизайна.
Отлично подходит для использования в дороге.
Ищете ресурсы, которые помогут подготовиться к собеседованию по кодированию?
Обратите внимание на сестринский репозиторий Интерактивные задачи по кодированию, который содержит дополнительную колоду Анки. Контрибьютинг
Учитесь у сообщества.
Не стесняйтесь отправлять пул реквесты, чтобы помочь:
Контент, который нуждается в доработке, помещён в раздел «В разработке».
Ознакомьтесь с руководством по контрибьютингу.
Индекс тем проектирования систем
Резюме различных тем проектирования систем, включая плюсы и минусы. Всё — это компромисс.
Каждый раздел содержит ссылки на более подробные ресурсы.
В запросе не было обнаружено кода на каком-либо языке программирования, гиперссылок, специальных тегов форматирования в markdown, html, yaml, json, plantuml и других. Процедура вызова (RPC)
Учебное пособие
Предлагаемые темы для изучения в зависимости от вашего расписания интервью (краткосрочное, среднесрочное, долгосрочное).
Вопрос: Нужно ли мне знать всё это для собеседования?
Ответ: Нет, вам не нужно знать всё это, чтобы подготовиться к собеседованию.
То, что вас спросят на собеседовании, зависит от таких переменных, как:
От кандидатов с большим опытом обычно ожидают более глубоких знаний о системном проектировании. От архитекторов или руководителей команд могут ожидать больше знаний, чем от отдельных участников. Ведущие технологические компании, вероятно, проведут один или несколько раундов собеседования по дизайну системы.
Начните широко и углубитесь в нескольких областях. Полезно иметь представление о различных ключевых темах системного проектирования. Адаптируйте следующее руководство в соответствии с вашим графиком, опытом, должностями, на которые вы претендуете, и компаниями, с которыми вы проводите собеседование.
| Краткосрочное | Среднесрочное | Долгосрочное | |
|---|---|---|---|
| Прочтите Темы системного проектирования, чтобы получить общее представление о том, как работают системы |  |
|
|
| Прочитайте несколько статей в Инженерных блогах компаний для компаний, в которых вы проходите собеседование | |
|
|
| Ознакомьтесь с несколькими Реальными архитектурами | |
|
|
| Изучите Как подойти к вопросу собеседования по системному дизайну | |
|
|
| Решите Вопросы собеседования по системному дизайну с решениями | Некоторые | Многие | Большинство |
| Решите Вопросы объектно-ориентированного проектирования с решениями | Некоторые | Многие | Большинство |
| Повторите Дополнительные вопросы собеседования по системному дизайну | Некоторые | Многие | Большинство |
Как решить вопрос собеседования по системному дизайну.
Собеседование по системному дизайну — это открытый разговор. Вы должны его вести.
Вы можете использовать следующие шаги, чтобы направлять обсуждение. Чтобы закрепить этот процесс, проработайте раздел Вопросы собеседования по системному дизайну с решениями, используя следующие шаги.
Соберите требования и определите рамки проблемы. Задайте вопросы, чтобы уточнить варианты использования и ограничения. Обсудите предположения.
Опишите высокоуровневый дизайн со всеми важными компонентами.
Шаг 3: Дизайн основных компонентов
Подробно опишите каждый основной компонент. Например, если бы вас попросили разработать сервис сокращения URL, обсудите:
Шаг 4: Масштабирование дизайна
Определите и устраните узкие места с учётом ограничений. Например, нужно ли вам следующее для решения проблем масштабируемости?
Обсудите возможные решения и компромиссы. Всё является компромиссом. Устраните узкие места, используя принципы масштабируемого системного дизайна.
Приблизительные расчёты
Вас могут попросить сделать некоторые оценки вручную. Обратитесь к Приложению за следующими ресурсами:
Источники и дополнительная литература
Посмотрите следующие ссылки, чтобы получить лучшее представление о том, чего ожидать:
Распространённые вопросы собеседования по системному проектированию с примерами обсуждений, кодом и диаграммами.
Решения связаны с содержимым папки
solutions/.
| Вопрос | |
|---|---|
| Разработайте Pastebin.com (или Bit.ly) | Решение |
| Разработайте временную шкалу и поиск Twitter (или ленту новостей и поиск Facebook) | Решение |
| Разработайте веб-сканер | Решение |
| Разработайте Mint.com | Решение |
| Разработайте структуры данных для социальной сети | Решение |
| Разработайте хранилище «ключ-значение» для поисковой системы | Решение |
| Разработайте систему ранжирования продаж Amazon по категориям | Решение |
| Разработайте масштабируемую систему на AWS | Решение |
| Добавьте вопрос по системному проектированию | Внести вклад |
Посмотреть упражнение и решение
Посмотреть упражнение и решение
Посмотреть упражнение и решение
Посмотреть упражнение и решение
Посмотреть упражнение и решение
Посмотреть упражнение и решение
Посмотреть решение ### Проектирование системы, масштабируемой до миллионов пользователей на AWS
Посмотреть упражнение и решение
Посмотреть упражнение и решение
Общие вопросы для собеседования по объектно-ориентированному дизайну с примерами обсуждений, кодом и диаграммами.
Решения связаны с содержимым в папке
solutions/
Примечание: этот раздел находится в разработке
| Вопрос | |
|---|---|
| Спроектировать хеш-таблицу | Решение |
| Разработать наименее используемый кеш | Решение |
| Спроектировать кол-центр | Решение |
| Создать колоду карт | Решение |
| Продумать парковку | Решение |
| Организовать чат-сервер | Решение |
| Описать круговой массив | Внести вклад |
| Добавить вопрос по объектно-ориентированному проектированию | Внести вклад |
Новичок в системном проектировании?
Сначала вам потребуется базовое понимание общих принципов, изучение того, что они собой представляют, как они используются, их плюсы и минусы.
Лекция о масштабируемости в Гарварде
Далее мы рассмотрим высокоуровневые компромиссы:
Имейте в виду, что всё является компромиссом.
Затем мы углубимся в более конкретные темы, такие как DNS, CDN и балансировщики нагрузки.
Сервис масштабируем, если он приводит к увеличению производительности пропорционально добавленным ресурсам. Как правило, повышение производительности означает обслуживание большего количества единиц работы, но это также может быть связано с обработкой более крупных единиц работы, например, когда наборы данных растут.1
Другой способ взглянуть на производительность и масштабируемость:
Задержка — это время, необходимое для выполнения какого-либо действия или получения какого-либо результата.
Пропускная способность — это количество таких действий или результатов за единицу времени.
Как правило, следует стремиться к максимальной пропускной способности с приемлемой задержкой.
Сети ненадёжны, поэтому вам потребуется поддерживать устойчивость к разделению. Вам придётся искать компромисс между согласованностью и доступностью в программном обеспечении. Ожидание ответа от разделённого узла может привести к ошибке тайм-аута. CP является хорошим выбором, если потребности бизнеса требуют атомарного чтения и записи. Ответы возвращают наиболее доступную версию данных, доступных на любом узле, которая может быть не самой последней. Запись может занять некоторое время для распространения после разрешения разделения. AP является хорошим выбором, когда бизнес должен допускать возможную согласованность или когда системе необходимо продолжать работу, несмотря на внешние ошибки. Имея несколько копий одних и тех же данных, мы сталкиваемся с вариантами их синхронизации, чтобы клиенты имели согласованное представление о данных. Вспомните определение согласованности из теоремы CAP — каждое чтение получает самое последнее записанное значение или ошибку. После записи чтение может увидеть её, а может и нет. Используется подход «наилучших усилий». Этот подход используется в таких системах, как memcached. Слабая согласованность хорошо работает в случаях реального времени, таких как VoIP, видеочат и многопользовательские игры в реальном времени. Например, если вы разговариваете по телефону и теряете связь на несколько секунд, то при восстановлении соединения вы не слышите, что было сказано во время потери связи. После записи чтения в конечном итоге увидят её (обычно в течение миллисекунд). Данные реплицируются асинхронно. Этот подход используется в таких системах, как DNS и электронная почта. Возможная согласованность хорошо работает в высокодоступных системах. После записи чтения увидят её. Данные реплицируются синхронно. Этот подход используется в файловых системах и RDBMS. Сильная согласованность хорошо работает в системах, требующих транзакций. Существует два взаимодополняющих шаблона для обеспечения высокой доступности: отработка отказа и репликация. При активном-пассивном режиме отработки отказа между активным и пассивным серверами в режиме ожидания отправляются контрольные сигналы. Если контрольный сигнал прерывается, пассивный сервер берёт на себя IP-адрес активного и возобновляет обслуживание. Продолжительность простоя определяется тем, работает ли пассивный сервер уже в «горячем» режиме ожидания или ему нужно запускаться из «холодного» режима ожидания. Только активный сервер обрабатывает трафик. Активную-пассивную отработку отказа также можно назвать отработкой отказа ведущий-ведомый. В активном-активном режиме оба сервера управляют трафиком, распределяя нагрузку между собой. Если серверы общедоступны, DNS должен знать об общедоступных IP-адресах обоих серверов. Если серверы являются внутренними, логике приложения необходимо знать о обоих серверах. Активный-активную отработку отказа также можно назвать отработкой отказа главный-главный. Эта тема подробнее обсуждается в разделе [База данных](#база данных): Доступность часто измеряется временем бесперебойной работы (или простоя) как процент времени, когда услуга доступна. Доступность обычно измеряется количеством девяток — услуга с доступностью 99,99 % описывается как имеющая четыре девятки.
Согласованность — каждое чтение получает самое последнее записанное значение или ошибку.
Доступность — каждый запрос получает ответ, без гарантии того, что он содержит самую последнюю версию информации.
Устойчивость к разделению — система продолжает работать несмотря на произвольное разделение из-за сетевых сбоев.
CP — согласованность и устойчивость к разделению
AP — доступность и устойчивость к разделению
Источники и дальнейшее чтение
Модели согласованности
Слабая согласованность
Возможная согласованность
Сильная согласованность
Источники и дальнейшее чтение
Модели доступности
Отработка отказа
Активный-пассивный
Активный-активный
Недостатки отработки отказа
Репликация
Ведущий-ведомый и ведущий-ведущий
Доступность в цифрах
Доступность 99.9 % — три девятки
Длительность
Допустимое время простоя
Простой в год
8 часов 45 минут 57 секунд
Простой в месяц
43 минуты 49,7 секунды
Простой в неделю
10 минут 4,8 секунды
Простой за день
1 минута 26,4 секунды
Доступность 99.99 % — четыре девятки
Длительность
Допустимое время простоя
Простой в год
52 минуты 35,7 секунды
Простой в месяц
4 минуты 23 секунды
Простой в неделю
1 минута 5 секунд
Простой за день
8,6 секунды
Доступность параллельно или последовательно
Если сервис состоит из нескольких компонентов, подверженных сбоям, общая доступность сервиса зависит от того, работают ли компоненты последовательно или параллельно.
Общая доступность снижается, если два компонента с доступностью < 100 % работают последовательно:
Доступность (общая) = Доступность (Foo) * Доступность (Bar)
Если у Foo и Bar была доступность 99,9 %, их общая доступность в последовательном режиме составила бы 99,8 %.
Общая доступность увеличивается, если два компонента с доступностью < 100 % работают параллельно:
Доступность (общая) = 1 - (1 - Доступность (Foo)) * (1 - Доступность (Bar))
Если у Foo и Bar была доступность 99,9 %, их общая доступность в параллельном режиме составила бы 99,9999 %.
Источник: презентация по безопасности DNS
Система доменных имён (DNS) преобразует доменное имя, например www.example.com, в IP-адрес.
DNS иерархична, с несколькими авторитетными серверами на верхнем уровне. Ваш маршрутизатор или интернет-провайдер предоставляет информацию о том, к какому DNS-серверу(ам) обращаться при поиске. Серверы нижнего уровня кэшируют сопоставления, которые могут стать устаревшими из-за задержек распространения DNS. Результаты DNS также могут быть кэшированы вашим браузером или ОС на определённый период времени, определяемый временем жизни (TTL).
Такие сервисы, как CloudFlare и Route 53, предоставляют управляемые DNS-сервисы. Некоторые DNS-службы могут направлять трафик различными способами:
Для защиты от сбоев обычно настраивают несколько балансировщиков нагрузки либо в режиме активный-пассивный, либо активный-активный.
Балансировщики нагрузки могут направлять трафик на основе различных метрик, включая:
Балансировщик нагрузки уровня 4 анализирует информацию на транспортном уровне, чтобы решить, как распределять запросы. Обычно это включает в себя исходный и целевой IP-адреса и порты в заголовке, но не содержимое пакета. Балансировщики нагрузки уровня 4 пересылают сетевые пакеты на вышестоящий сервер и обратно, выполняя трансляцию сетевых адресов (NAT).
Балансировщик нагрузки уровня 7 анализирует прикладной уровень, чтобы определить, как распределить запросы. Это может включать содержимое заголовка, сообщения и cookie. Балансировщик нагрузки уровня 7 завершает сетевой трафик, читает сообщение, принимает решение о балансировке нагрузки, а затем устанавливает соединение с выбранным сервером. Например, балансировщик нагрузки уровня 7 может направлять видеопоток на серверы, на которых размещены видео, и направлять более чувствительный пользовательский биллинговый трафик на защищённые серверы.
За счёт гибкости балансировка нагрузки уровня 4 требует меньше времени и вычислительных ресурсов, чем уровня 7, хотя влияние на производительность может быть минимальным на современном коммерческом оборудовании.
Балансировщики нагрузки также помогают с горизонтальным масштабированием, улучшая производительность и доступность. Масштабирование за счёт использования коммерческих машин более экономично и приводит к более высокой доступности, чем вертикальное масштабирование одного сервера на более дорогом оборудовании. Также легче найти специалистов для работы на коммерческом оборудовании, чем для специализированных корпоративных систем.
Дополнительные преимущества включают:
Источник: Введение в архитектуру систем для масштабирования
Отделение веб-слоя от прикладного слоя (также известного как платформенный слой) позволяет независимо масштабировать и настраивать оба слоя. Добавление нового API приводит к добавлению серверов приложений без обязательного добавления дополнительных веб-серверов. Принцип единственной ответственности выступает за небольшие и автономные сервисы, которые работают вместе. Небольшие команды с небольшими сервисами могут более агрессивно планировать быстрый рост.
Работники прикладного уровня также помогают обеспечить асинхронность.
С этим обсуждением связаны микросервисы, которые можно описать как набор независимо развёртываемых, небольших, модульных сервисов. Каждый сервис работает в уникальном процессе и общается через чётко определённый, лёгкий механизм для достижения бизнес-цели. Например, Pinterest может иметь следующие микросервисы: профиль пользователя, подписчик, лента, поиск, загрузка фотографий и т.д.
Системы, такие как Consul, Etcd и Zookeeper, могут помочь сервисам находить друг друга, отслеживая зарегистрированные имена, адреса и порты. Проверки работоспособности помогают проверить целостность сервиса и часто выполняются с использованием конечной точки HTTP. И Consul, и Etcd имеют встроенную... Хранилище типа «ключ — значение», которое может быть полезно для хранения конфигурационных значений и других общих данных.
Источник: Масштабирование до первых 10 миллионов пользователей
Реляционная база данных, такая как SQL, представляет собой набор элементов данных, организованных в таблицы.
ACID — это набор свойств транзакций реляционной базы данных.
Существует множество методов масштабирования реляционных баз данных: основно-резервное копирование, основно-основное копирование, федерация, сегментирование, денормализация и настройка SQL.
Мастер обслуживает операции чтения и записи, реплицируя записи на один или несколько резервных серверов, которые обслуживают только операции чтения. Резервные серверы также могут реплицироваться на дополнительные резервные серверы древовидным образом. Если мастер становится недоступен, система может продолжать работать в режиме только для чтения, пока резервный сервер не будет повышен до мастера или не будет подготовлен новый мастер.
Источник: Масштабируемость, доступность, стабильность, шаблоны
Оба мастера обслуживают операции чтения и записи и координируют друг с другом операции записи. Если любой из мастеров выходит из строя, система может продолжить работу с операциями чтения и записи.
Источник: Масштабируемость, доступность, стабильность, шаблоны
Репликация приводит к увеличению задержки репликации.
Источники и дополнительная литература: репликация
Федерация
Федерация (или функциональное разделение) разделяет базы данных по функциям. Например, вместо одной монолитной базы данных у вас может быть три базы данных: форумы, пользователи и продукты, что приводит к уменьшению трафика чтения и записи в каждую базу данных и, следовательно, к меньшей задержке репликации. Меньшие базы данных приводят к тому, что больше данных помещается в памяти, что, в свою очередь, приводит к большему количеству попаданий в кэш из-за улучшенной локальности кэша. Без единого центрального мастера, сериализующего записи, вы можете писать параллельно, увеличивая пропускную способность.
Недостатки федерации:
Источники и дополнительная литература: федерация
Шардирование
Шардирование распределяет данные по разным базам данных таким образом, что каждая база данных может управлять только подмножеством данных. Если взять в качестве примера базу данных пользователей, то по мере увеличения числа пользователей в кластер добавляется больше сегментов.
Как и преимущества федерации, шардирование приводит к меньшему трафику чтения и записи, меньшей репликации и большему количеству обращений к кэшу. Размер индекса также уменьшается, что обычно улучшает производительность за счёт более быстрых запросов. Если один сегмент выходит из строя, другие сегменты остаются работоспособными, хотя вы захотите добавить некоторую форму репликации, чтобы избежать потери данных. Как и в случае с федерацией, нет единого центрального мастера, который сериализует записи, позволяя вам писать параллельно с увеличенной пропускной способностью.
Распространённые способы разделения таблицы пользователей — либо по инициалам фамилии пользователя, либо по географическому местоположению пользователя.
Недостатки шардирования:
Источники и дополнительная литература: шардирование
Денормализация
Денормализация пытается улучшить производительность чтения за счёт некоторой производительности записи. Избыточные копии данных записываются в нескольких таблицах, чтобы избежать дорогостоящих объединений. Некоторые системы управления реляционными базами данных (RDBMS), такие как PostgreSQL и Oracle, поддерживают материализованные представления, которые выполняют работу по хранению избыточной информации и поддержанию согласованности избыточных копий.
После того как данные становятся распределёнными с помощью таких методов, как федерализация и сегментирование, управление объединениями между центрами обработки данных ещё больше усложняется. Денормализация может помочь избежать необходимости в таких сложных объединениях.
В большинстве систем операции чтения могут значительно превосходить операции записи в соотношении 100:1 или даже 1000:1. Операция чтения, приводящая к сложному объединению базы данных, может быть очень затратной, поскольку она тратит значительное количество времени на дисковые операции.
Оптимизация SQL — это обширная тема, и было написано множество книг в качестве справочных материалов.
Важно проводить бенчмаркинг и профилирование, чтобы смоделировать и выявить узкие места.
Бенчмаркинг и профилирование могут указать вам на следующие оптимизации.
Как нулевые значения влияют на производительность?
Медленный журнал запросов
NoSQL — это набор элементов данных, представленных в виде хранилища «ключ-значение», хранилища документов, хранилища широких столбцов или графовой базы данных. Данные денормализованы, и объединения обычно выполняются в коде приложения. Большинство хранилищ NoSQL не имеют настоящих транзакций ACID и предпочитают возможную согласованность.
Часто для описания свойств баз данных NoSQL используется термин BASE. В сравнении с теоремой CAP, BASE выбирает доступность вместо согласованности.
Помимо выбора между SQL или NoSQL, полезно понять, какой тип базы данных NoSQL лучше всего подходит для вашего случая использования. Мы рассмотрим хранилища «ключ-значение», хранилища документов, хранилища широких столбцов и графовые базы данных в следующем разделе.
Абстракция: хеш-таблица
Хранилище «ключ-значение» обычно позволяет выполнять операции чтения и записи за O(1) и часто поддерживается памятью или SSD. Хранилища данных могут поддерживать ключи в лексикографическом порядке, что позволяет эффективно извлекать диапазоны ключей. Хранилища «ключ-значение» позволяют хранить метаданные со значением.
Хранилища «ключ-значение» обеспечивают высокую производительность и часто используются для простых моделей данных или быстро меняющихся данных, таких как слой кэша в памяти. Поскольку они предлагают только ограниченный набор операций, сложность переносится на уровень приложения, если требуются дополнительные операции.
Хранилище «ключ-значение» является основой для более сложных систем, таких как хранилище документов и, в некоторых случаях, графовая база данных.
Абстракция: хранилище «ключ-значение» с документами, хранящимися в качестве значений
Хранилище документов сосредоточено вокруг документов (XML, JSON, двоичные файлы и т. д.), где документ хранит всю информацию для данного объекта. Хранилища документов предоставляют API или язык запросов для запроса на основе внутренней структуры самого документа. Обратите внимание, многие хранилища «ключ-значение» включают функции для работы с метаданными значения, размывая границы между этими двумя типами хранилищ.
На основе базовой реализации документы организуются по коллекциям, тегам, метаданным или каталогам. Хотя документы можно организовать или сгруппировать вместе, документы могут иметь поля, которые полностью отличаются друг от друга.
Некоторые хранилища документов, такие как MongoDB и CouchDB, также предоставляют язык, подобный SQL, для выполнения сложных запросов. DynamoDB поддерживает как «ключ-значения», так и документы.
Хранилища документов обеспечивают высокую гибкость и часто используются для работы с периодически изменяющимися данными.
Wide column store — это база данных, в которой основной единицей информации является столбец (пара «имя/значение»). Столбцы группируются в семейства столбцов (аналогично таблицам SQL). Семейства суперстолбцов объединяют семейства столбцов. Доступ к каждому столбцу осуществляется с помощью ключа строки, а столбцы с одинаковым ключом строки образуют строку. Каждое значение содержит временную метку для управления версиями и разрешения конфликтов.
Google представил Bigtable как первую базу данных широкого столбца, которая повлияла на широко используемый в экосистеме Hadoop открытый исходный код HBase и Cassandra от Facebook. Такие хранилища, как BigTable, HBase и Cassandra, поддерживают ключи в лексикографическом порядке, что позволяет эффективно извлекать отдельные диапазоны ключей.
Ширококолоночные хранилища обеспечивают высокую доступность и масштабируемость. Они часто используются для очень больших наборов данных.
Источники и дополнительная литература: ширококолоночное хранилище
Графовая база данных
В графовой базе данных каждый узел представляет собой запись, а каждая дуга — связь между двумя узлами. Графовые базы данных оптимизированы для представления сложных отношений со множеством внешних ключей или отношений «многие ко многим».
Графовые базы данных обеспечивают высокую производительность для моделей данных со сложными отношениями, такими как социальная сеть. Они относительно новы и ещё не получили широкого распространения; может быть сложнее найти инструменты разработки и ресурсы. Многие графы можно получить только через REST API.
Источники и дополнительная литература: графовая база данных
Источники и дополнительная литература: NoSQL
SQL или NoSQL
Причины использования SQL:
Причины использования NoSQL:
Полуструктурированные данные
Динамическая или гибкая схема
Нереляционные данные
Отсутствие необходимости в сложных объединениях
Хранение многих ТБ (или ПБ) данных
Очень интенсивная работа с данными
Очень высокая пропускная способность для IOPS Кэши и источник истины, такие как база данных через аннулирование кэша.
Аннулирование кэша — сложная задача, связанная с обновлением кэша возникает дополнительная сложность.
Необходимо внести изменения в приложение, например, добавить Redis или memcached.
Источник: Введение в проектирование систем для масштабирования
Асинхронные рабочие процессы помогают сократить время запросов на дорогостоящие операции, которые в противном случае выполнялись бы в режиме реального времени. Они также могут помочь, выполняя трудоёмкую работу заранее, например периодическое агрегирование данных.
Очереди сообщений получают, хранят и доставляют сообщения. Если операция слишком медленная для выполнения в реальном времени, вы можете использовать очередь сообщений со следующим рабочим процессом:
Пользователь не блокируется, и задание обрабатывается в фоновом режиме. В это время клиент может дополнительно выполнить небольшой объём обработки, чтобы создать впечатление, что задача выполнена. Например, если вы публикуете твит, он может быть мгновенно размещён в вашей ленте, но может пройти некоторое время, прежде чем ваш твит будет доставлен всем вашим подписчикам.
Redis полезен в качестве простого брокера сообщений, но сообщения могут быть потеряны.
RabbitMQ популярен, но требует адаптации к протоколу AMQP и управления собственными узлами.
Amazon SQS размещается, но может иметь высокую задержку и возможность доставки сообщений дважды.
Очередь задач получает задачи и связанные с ними данные, выполняет их, а затем доставляет результаты. Они могут поддерживать планирование и использоваться для запуска ресурсоёмких заданий в фоновом режиме.
Celery поддерживает планирование и в основном имеет поддержку Python.
Если очереди начинают значительно расти, размер очереди может стать больше, чем объём памяти, что приведёт к промахам кэша, чтению с диска и даже снижению производительности. Обратное давление может помочь, ограничивая размер очереди и поддерживая высокую скорость передачи и хорошее время отклика для заданий, уже находящихся в очереди. Как только очередь заполнится, клиенты получат сообщение о том, что сервер занят, или HTTP 503, чтобы повторить попытку позже. Клиенты могут повторить запрос позже, возможно, с экспоненциальной отсрочкой.
Закон Литтла (Little's law) — это формула, которая связывает среднее количество заданий в системе (или очереди), среднее время нахождения задания в системе и среднюю скорость поступления заданий в систему. Закон назван в честь Джона Литтла (John Little), который впервые сформулировал его в 1961 году.
В чём разница между очередью сообщений и очередью задач?
Что такое очередь сообщений и чем она отличается от очереди задач? Почему для работы очереди задач требуется брокер сообщений, такой как RabbitMQ, Redis, Celery или IronMQ?
Источник: модель OSI с 7 уровнями
HTTP — это метод кодирования и передачи данных между клиентом и сервером. Это протокол «запрос-ответ»: клиенты отправляют запросы, а серверы выдают ответы с соответствующим содержимым и информацией о статусе выполнения запроса. HTTP является автономным, позволяя запросам и ответам проходить через множество промежуточных маршрутизаторов и серверов, которые выполняют балансировку нагрузки, кэширование, шифрование и сжатие.
Базовый HTTP-запрос состоит из глагола (метода) и ресурса (конечной точки). Ниже приведены распространённые HTTP-глаголы:
| Глагол | Описание | Идемпотентность* | Безопасность | Кэшируемость |
|---|---|---|---|---|
| GET | Чтение ресурса | Да | Да | Да |
| POST | Создание ресурса или запуск процесса, обрабатывающего данные | Нет | Нет | Да, если ответ содержит информацию о свежести |
| PUT | Создание или замена ресурса | Да | Нет | Нет |
| PATCH | Частичное обновление ресурса | Нет | Нет | Да, если ответ содержит информацию о свежести |
| DELETE | Удаление ресурса | Да | Нет | Нет |
*Можно вызывать много раз без разных результатов.
HTTP является протоколом прикладного уровня, полагающимся на протоколы нижнего уровня, такие как TCP и UDP.
Источник: Как сделать многопользовательскую игру
TCP — это ориентированный на соединение протокол по IP-сети (IP network). Соединение устанавливается и разрывается с помощью рукопожатия (handshake). Все отправленные пакеты гарантированно достигают места назначения в исходном порядке и без искажений благодаря:
Если отправитель не получает правильный ответ, он повторно отправит пакеты. Если происходит несколько тайм-аутов, соединение разрывается. TCP также реализует управление потоком (flow control) и контроль перегрузки (congestion control). Эти гарантии вызывают задержки и обычно приводят к менее эффективной передаче, чем UDP.
Чтобы обеспечить высокую пропускную способность, веб-серверы могут поддерживать большое количество открытых TCP-соединений, что приводит к высокому использованию памяти. Может быть дорого иметь большое количество открытых соединений между веб-серверными потоками и, скажем, сервером memcached. Пул соединений может помочь в дополнение к переключению на UDP, где это применимо.
TCP полезен для приложений, требующих высокой надёжности, но менее критичных ко времени. Некоторые примеры включают веб-серверы, информацию базы данных, SMTP, FTP и SSH.
Используйте TCP вместо UDP, когда:
Примечание: в тексте запроса присутствуют изображения, однако они не были включены в ответ. Удаленный вызов процедур (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 ориентирован на предоставление данных. Он минимизирует связь между клиентом и сервером и часто используется для общедоступных HTTP API. REST использует более общий и унифицированный метод предоставления ресурсов через URI, представление через заголовки и действия через глаголы, такие как GET, POST, PUT, DELETE и PATCH. Будучи без сохранения состояния, 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 эскизов изображений с диска или сколько памяти займёт структура данных. Таблицы степеней двойки и чисел задержки, которые должен знать каждый программист, являются удобными справочными материалами.
Таблица степеней двойки
| Степень | Точное значение | Приблизительное значение | Байты |
|---|---|---|---|
| 7 | 128 | 1 КБ | |
| 8 | 256 | ||
| 10 | 1 024 | 1 тысяча | 1 КБ |
| 16 | 65 536 | 64 КБ | |
| 20 | 1 048 576 | 1 миллион | 1 МБ |
| 30 | 1 073 741 824 | 1 миллиард | 1 ГБ |
| 32 | 4 294 967 296 | 4 ГБ | |
| 40 | 1 099 511 627 776 | 1 триллион | 1 ТБ |
Источник: Степени двойки.
Числа задержки, которые должен знать каждый программист
| Задержка | Сравнение чисел |
|---|---|
| Ссылка на кэш L1 | 0,5 нс |
| Неверное предсказание перехода | 5 нс |
| Ссылка на кеш L2 | 7 нс |
| Блокировка/разблокировка мьютекса | 25 нс |
| Основная память | 100 нс |
| Сжатие 1 Кб байтов с помощью Zippy | 10 000 нс |
| Отправка 1 Кб по сети со скоростью 1 Гбит/с | 10 000 нс |
| Случайное чтение 4 Кб из SSD | 150 000 нс |
| Последовательное чтение 1 Мб из памяти | 250 000 нс |
| Круговой обход в пределах одного центра обработки данных | 500 000 нс |
| Последовательное чтение 1 Мб с SSD | 1 000 000 нс |
| Поиск HDD | 10 000 000 нс |
| Чтение 1 Мб последовательно из памяти | 250 000 нс |
| Передача пакета CA->Нидерланды->CA | 150 000 000 нс |
Примечания: 1 нс = 10⁻⁹ секунд. 1 мкс = 10⁻³ секунд = 1 000 нс. 1 мс = 10⁻³ секунд = 1 000 мкс = 1 000 000 нс.
Удобные показатели на основе приведённых выше чисел:
Источники и дополнительная литература:
| Вопрос | Ссылка(и) |
|---|---|
| Спроектировать службу синхронизации файлов наподобие 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 | Системы реального мира |
Статьи о том, как разрабатываются реальные системы.
Статьи о том, как разрабатываются системы реального мира.
Источник: Масштабируемость временных шкал Twitter.
Не фокусируйтесь на мельчайших деталях следующих статей, вместо этого:
| Тип | Система | Ссылка(и) |
|---|---|---|
| Обработка данных | MapReduce — Распределённая обработка данных от Google | research.google.com |
| Обработка данных | Spark — Распределённая обработка данных от Databricks | slideshare.net |
| Обработка данных | Storm — Распределённая обработка данных от Twitter | slideshare.net |
| Хранилище данных | Bigtable — Распределённая колоночно-ориентированная база данных от Google | harvard.edu |
| Хранилище данных | HBase — Открытая реализация Bigtable | slideshare.net |
| Хранилище данных | Cassandra — Распределённая колоночно-ориентированная база данных от Facebook | slideshare.net |
| Хранилище данных | DynamoDB — Документно-ориентированная база данных от Amazon | Архитектуры компаний |
| Компания | Ссылка(и) |
|---|---|
| Amazon | Архитектура Amazon |
| Cinchcast | Производство 1500 часов аудио каждый день |
| DataSift | Анализ данных в реальном времени со скоростью 120 000 твитов в секунду |
| Dropbox | Как мы масштабировали Dropbox |
| ESPN | Работа на скорости 100 000 дух-нух-нухов в секунду |
| Архитектура Google | |
|
14 миллионов пользователей, терабайты фотографий Что стоит за Instagram |
|
| Justin.tv | Архитектура прямой видеотрансляции Justin.Tv |
|
Масштабирование memcached в Facebook TAO: Распределённое хранилище данных для социального графа Facebook Хранение фотографий в Facebook Как Facebook транслирует Live-видео для 800 000 одновременных зрителей |
|
| Flickr | Архитектура Flickr |
| Mailbox | От 0 до миллиона пользователей за 6 недель |
| Netflix | Полный обзор всей системы Netflix Стек Netflix: что происходит, когда вы нажимаете кнопку «play»? |
Pinterest: от 0 до десятков миллиардов просмотров страниц в месяц.
Playfish: 50 миллионов пользователей ежемесячно и рост.
PlentyOfFish: архитектура PlentyOfFish.
Salesforce: как они обрабатывают 1,3 миллиарда транзакций в день.
Stack Overflow: архитектура Stack Overflow.
TripAdvisor: 40 млн посетителей, 200 млн динамических просмотров страниц, 30 ТБ данных.
Tumblr: 15 миллиардов просмотров страниц в месяц.
Twitter: ускорение Twitter на 10 000 процентов. Хранение 250 миллионов твитов в день с использованием MySQL. Архитектура Twitter для работы с 150 миллионами активных пользователей. Временные шкалы в масштабе. Большие и малые данные в Twitter. Операции в Twitter: масштабирование за пределы 100 миллионов пользователей. Как Twitter обрабатывает 3 000 изображений в секунду.
Uber: как Uber масштабирует свою платформу реального времени. Уроки, извлечённые из масштабирования Uber до 2 000 инженеров, 1 000 сервисов и 8 000 репозиториев Git.
WhatsApp: архитектура WhatsApp, купленная Facebook за 19 миллиардов долларов.
YouTube: масштабируемость YouTube. Архитектура YouTube.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )