[Перевод] Введение в системный дизайн | Проект перевода Nuggets

база данных сервер Программа перевода самородков дизайн
[Перевод] Введение в системный дизайн | Проект перевода Nuggets

Приступаем к проектированию системы





перевести

заинтересованы в участииперевестиВыполняется следующий перевод:

Цель

Научитесь проектировать большие системы.

Подготовьтесь к интервью по проектированию системы.

Научитесь проектировать большие системы

Изучение того, как проектировать масштабируемые системы, поможет вам стать лучшим инженером.

Проектирование систем — это обширная тема. в Интернете,Ресурсы по принципам системного проектирования также огромны.

Этот репозиторий для этих ресурсовколлекция тканей, который поможет вам научиться создавать масштабируемые системы.

Учитесь у сообщества открытого исходного кода

Это начальный выпуск постоянно обновляемого проекта с открытым исходным кодом.

Добро пожаловатьспособствовать!

Подготовьтесь к собеседованию по проектированию системы

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

Отработайте общие вопросы на собеседовании по проектированию системи поместите свой ответ ирешение на примерепровестиКонтроль: Обсуждение, код и диаграммы.

Дополнительные темы для подготовки к собеседованию:

Карточки





Здесьстопка карточекИспользуйте интервальные повторения, чтобы помочь вам запомнить ключевые концепции проектирования системы.

Доступно в любое время и в любом месте.

Ресурсы по коду: интерактивные задачи по программированию

Вы ищете ресурсы для подготовкиинтервью по программированию?





Проверьте наш родственный складИнтерактивное задание по программированиюСодержит дополнительную стопку карточек:

способствовать

Учитесь у сообщества.

Отправить PR, чтобы помочь:

  • исправлять ошибки
  • идеальная глава
  • Добавить главу

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

пожалуйста, проверьтеРуководство по взносам.

Указатель тем системного проектирования

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

Каждая глава содержит ссылки на дополнительные ресурсы.





методическое пособие

Основываясь на временной шкале вашего интервью (короткое, среднее, длинное), просмотрите рекомендуемые темы.

Imgur
Imgur

В: Для интервью мне нужно знать все знания здесь?

A: Нет, вам не нужно знать все, если это просто подготовка к интервью.

То, о чем вас спросят на собеседовании, зависит от следующих факторов:

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

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

Интервью будут широкими и глубокими в нескольких областях. Это время поможет вам понять некоторые темы, связанные с проектированием системы. Внесите соответствующие коррективы в приведенное ниже руководство в зависимости от вашего графика, опыта, должности, на которую вы проходите собеседование, и компании, в которую вы проходите собеседование.

  • короткий срок- Тематически оформленный системойширотакак цель. путем решенияНемногоИнтервью Вопросы для практики.
  • Средняя степень- Тематически оформленный системойширотаиначальная глубинакак цель. путем решенияполноПрактика вопросов интервью.
  • длинная- Тематически оформленный системойширотаиРасширенная глубинакак цель. путем решениясамыйОбращайтесь по вопросам интервью.
короткий срок Средняя степень длинная
читатьТемы проектирования системыполучить общее представление о том, как работает система :+1: :+1: :+1:
Вы должны прочитать некоторые из интервьюИнженерный блог компаниистатья :+1: :+1: :+1:
читатьреальная архитектура :+1: :+1: :+1:
обзорКак ответить на вопрос на собеседовании по проектированию системы :+1: :+1: :+1:
ЗаканчиватьВопросы собеседования и ответы на дизайн системы Немного полно самый
ЗаканчиватьВопросы и ответы на собеседовании по объектно-ориентированному дизайну Немного полно самый
обзорДругие вопросы на собеседовании по системному проектированию Немного полно самый

Как ответить на вопрос на собеседовании по системному проектированию

Интервью по проектированию системы являетсяоткрытый диалог. Они ожидают, что вы будете вести разговор.

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

Шаг 1. Опишите сценарии использования, ограничения и допущения

Соберите все необходимое и исследуйте проблему. Продолжайте задавать вопросы, чтобы мы могли определить сценарии использования и ограничения. Обсудите предположения.

  • Кто это будет использовать?
  • Как они будут его использовать?
  • Сколько пользователей?
  • Какова роль системы?
  • Что является входом и выходом системы?
  • Сколько данных мы хотим обработать?
  • Надеемся, что количество обрабатываемых запросов в секунду?
  • Какое соотношение чтения и записи мы хотим?

Шаг 2: Создайте расширенный дизайн

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

  • Нарисуйте основные узлы и соединения
  • Докажи свои мысли

Шаг 3: Проектирование основных компонентов

Детальный углубленный анализ каждого из основных компонентов. Например, если вы спросилиРазработка сервиса сокращения URL, чтобы начать обсуждение:

  • Создайте и сохраните хэш полного URL-адреса
    • MD5иBase62
    • Хэш-коллизия
    • SQL или NoSQL
    • Модель базы данных
  • Преобразование хешированного URL-адреса в полный URL-адрес
    • поиск в базе данных
  • API и объектно-ориентированный дизайн

Шаг 4: Дизайн метрик

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

  • балансировки нагрузки
  • Горизонтальное расширение
  • тайник
  • Шардинг базы данных

Обсудите возможные решения и стоимость. Все требует компромиссов. можно использоватьПринципы проектирования масштабируемых системразобраться с узкими местами.

Расчеты на обратной стороне конверта

你或许会被要求通过手算进行一些估算。 ВовлеченныйприложениеЗадействованы следующие ресурсы:

Связанные ресурсы и дополнительная литература

Перейдите по ссылке ниже, чтобы получить лучшие идеи, которые мы ожидаем:

Вопросы и ответы на собеседовании по системному дизайну

Общие напротив системы Интервью Вопросы и связанные с ними тематические исследования, код и диаграммы.

Ответы по содержаниюsolutions/папка.

проблема
Дизайн Pastebin.com (или Bit.ly) отвечать
Создайте временную шкалу и поиск в Twitter (или ленту и поиск в Facebook) отвечать
Разработка веб-краулера отвечать
Дизайн mint.com. отвечать
Проектирование структур данных для социальной сети отвечать
Дизайн клавишного магазина для поисковых систем отвечать
Характеристики дизайна рейтинга продаж Amazon по категориям отвечать
Разработайте систему для миллиона пользователей на AWS отвечать
Добавить вопрос по дизайну системы способствовать

Дизайн Pastebin.com (или Bit.ly)

Посмотреть практику и ответы

Imgur
Imgur

Создайте временную шкалу и поиск в Twitter (или ленту и поиск в Facebook)

Посмотреть практику и ответы

Imgur
Imgur

Разработка веб-краулера

Посмотреть практику и ответы

Imgur
Imgur

Дизайн Mint.com

Посмотреть практику и ответы

Imgur
Imgur

Проектирование структур данных для социальной сети

Посмотреть практику и ответы

Imgur
Imgur

Проектирование хранилища ключей для поисковых систем

Посмотреть практику и ответы

Imgur
Imgur

Разработка рейтинга продаж Amazon по категориям

Посмотреть практику и ответы

Imgur
Imgur

Разработайте систему для миллиона пользователей на AWS

Посмотреть практику и ответы

Imgur
Imgur

Вопросы и ответы на собеседовании по объектно-ориентированному дизайну

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

Решение, связанное с контентомsolutions/папка.

Примечание. Этот раздел все еще находится в разработке.

проблема
Хэш-карта дизайна решение
Проектирование кэша LRU решение
Дизайн колл-центра решение
Спроектировать колоду карт решение
спроектировать парковку решение
Разработать чат-сервис решение
Создайте круговой массив быть решенным
Добавить вопрос об объектно-ориентированном дизайне быть решенным

Темы системного проектирования: начните здесь

Новое в системном проектировании?

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

Шаг 1. Просмотрите видеолекции по масштабируемости

Гарвардская лекция по масштабируемости

  • Темы охватывали
    • Вертикальное масштабирование
    • Горизонтальное масштабирование
    • тайник
    • балансировки нагрузки
    • репликация базы данных
    • раздел базы данных

Шаг 2. Ознакомьтесь со статьей о масштабируемости

Масштабируемость

следующие шаги

Далее мы рассмотрим компромиссы и компромиссы более высокого порядка:

  • представлениеиМасштабируемость
  • Задерживатьипропускная способность
  • Доступностьипоследовательность

ПомнитеКаждый аспект вбрасывания и компромиссов.

Затем мы углубимся в более конкретные темы, такие как DNS, CDN и балансировщики нагрузки.

Производительность и масштабируемость

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

Другой взгляд на производительность и масштабируемость:

  • Если ваша система имеетпредставлениеПроблема, медленно для одного пользователя.
  • если в вашей системе естьМасштабируемостьПроблема в том, что это быстрее для одного пользователя, но медленнее при высокой нагрузке.

Источник и дальнейшее чтение

Задержка и пропускная способность

Задерживатьвремя, необходимое для выполнения операции или результат операции.

пропускная способность- количество таких операций или операций в единицу времени (выполняемых).

Обычно следует начинать сприемлемая задержкаВнизМаксимальная пропускная способностькак цель.

Источник и дальнейшее чтение

Доступность и согласованность

Теория CAP





Источник: Пересматривая теорию CAP.

В распределенной вычислительной системе одновременно могут выполняться только следующие два пункта:

  • последовательность─ Получайте последние данные при каждом посещении, но можете получить ответ об ошибке
  • Доступность─ Получайте ответ без ошибок при каждом посещении, но не гарантируете получение последних данных
  • Допуск перегородки─ В случае сбоя сети любого раздела система может продолжать работать

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

CP — непротиворечивость и устойчивость к разделам

Ожидание ответа от разделенного узла может привести к ошибке задержки. Если вашему бизнесу требуются атомарные операции чтения и записи, CP — хороший выбор.

AP — доступность и допустимость разделов

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

Если бизнесу необходимо разрешитьокончательная согласованность, или когда есть внешняя ошибка, которая требует продолжения работы системы, AP является хорошим выбором.

Источник и дальнейшее чтение

Режим согласованности

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

слабая консистенция

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

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

окончательная согласованность

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

Такой подход используется в таких системах, как DNS и электронная почта. Согласованность в конечном счете хорошо работает в системах высокой доступности.

сильная консистенция

Доступ виден сразу после написания. Данные реплицируются синхронно.

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

Источник и дальнейшее чтение

Режим доступности

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

отказоустойчивость

Активный пассивный

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

Время простоя зависит от того, находится ли резервный сервер в состоянии «горячего» резерва или его необходимо запустить из состояния «холодного» резерва. Только рабочие серверы обрабатывают трафик.

Переход с рабочего режима на резервный также известен как переключение ведущий-ведомый.

Двойное рабочее переключение (активный-активный)

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

Если это внешний сетевой сервер, DNS должен знать обе стороны. В случае с сервером интрасети логика приложения должна знать об обеих сторонах.

Двойное рабочее переключение также может упоминаться как основное основное переключение.

Дефект: отказоустойчивость

  • Отказоустойчивость требует добавления дополнительного оборудования и увеличения сложности.
  • Если новая копия перед записью данных в систему резервного копирования может работать, система дает сбой, то возможна потеря данных.

копировать

Репликация Master-Slave и репликация Master-Master

Эта тема изучается дополнительнобаза данныхчасть:

система доменных имен





Источник: Введение в безопасность DNS.

Система доменных имен преобразует доменные имена, такие как www.example.com, в IP-адреса.

Система доменных имен является иерархической, с некоторыми DNS-серверами на верхнем уровне. Когда запрашивается IP (доменное имя), маршрутизатор или интернет-провайдер предоставляет информацию для подключения к DNS-серверу. Сопоставления кэша DNS-серверов более низкого уровня, которые могут завершиться ошибкой из-за задержек распространения DNS. Результаты DNS могут кэшироваться в браузере или операционной системе на время, зависящее отВремя жить TTL.

  • NS Record (служба доменного имени)─ Укажите сервер DNS, который разрешает доменное имя или имя поддомена.
  • Записи MX (обмен почтой)─ Укажите почтовый сервер для получения сообщений.
  • Запись (адрес)─ Укажите запись IP-адреса, соответствующую доменному имени.
  • CNAME (канонический)─ одно доменное имя сопоставляется с другим доменным именем илиCNAMEзапись ( example.com указывает на www.example.com ) или сопоставление сAзаписывать.

CloudFlareиRoute 53Подобные платформы предоставляют возможность управлять DNS. Некоторые службы DNS направляют трафик централизованно:

  • Взвешенное круговое планирование
    • Предотвратить попадание трафика на серверы, находящиеся на обслуживании
    • Балансировка нагрузки между кластерами разного размера
    • A/B-тестирование
  • Маршрутизация на основе задержки
  • Маршрутизация на основе географического положения

Дефект: DNS

  • Хотя кэширование может уменьшить задержку DNS, при подключении к DNS-серверам возникает небольшая задержка.
  • Хотя они обычноПравительства, интернет-провайдеры и крупные корпорацииУправление, но управление службой DNS может быть сложным.
  • Служба DNS недавно пострадалаDDoS-атака, блокирует доступ к Twitter пользователям, не знающим IP-адрес Twitter.

Источник и дальнейшее чтение

Сеть доставки контента (CDN)





Источник: Зачем использовать CDN

Сеть доставки контента (CDN) — это глобальная распределенная сеть прокси-серверов, которые обслуживают контент из расположений, близких к пользователям. Как правило, статический контент, такой как HTML/CSS/JS, изображения и видео, обслуживается CDN, хотя динамический контент также поддерживается Amazon CloudFront и т. д. Разрешение DNS CDN сообщает клиентам, к какому серверу подключаться.

Хранение контента в CDN может обеспечить производительность двумя способами:

  • Обслуживание ресурсов из центров обработки данных, близких к пользователям
  • Не обязательно иметь запрос на ваш сервер через cdn вашего сервера

Пуш CDN (PUSH)

Когда контент на вашем сервере изменится, нажмите CDN, чтобы принять новый контент. Нажмите прямо на CDN и перепишите URL-адрес, чтобы он указывал на адрес CDN вашего контента. Вы можете настроить время истечения срока действия содержимого и время его обновления. Контент передается только тогда, когда вносятся изменения или добавления, минимизируя трафик, но максимально увеличивая объем хранилища.

Вытягивание CDN (вытягивание)

CDN pull извлекает ресурс с сервера, когда первый пользователь запрашивает ресурс. Вы сохраняете контент на своем собственном сервере и переписываете URL-адрес, чтобы он указывал на адрес CDN. Пока контент не будет кэширован в CDN, запрос будет только медленнее,

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

Сайты с высоким трафиком хорошо справляются с вытягиванием CDN, потому что трафик распределяется более равномерно, если последний запрошенный контент хранится в CDN.

Дефект: CDN

  • Стоимость CDN может варьироваться в зависимости от трафика, и вполне возможно, что вы не будете использовать CDN после компромисса.
  • Если содержимое обновляется до истечения TTL, кэшированное содержимое CDN может устареть.
  • CDN необходимо изменить URL-адрес статического контента, чтобы он указывал на CDN.

Источник и дальнейшее чтение

балансировщик нагрузки





Источник: Шаблоны проектирования масштабируемых систем.

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

  • Предотвратить отправку запросов на плохие серверы
  • Предотвратить перегрузку ресурсов
  • Помогите устранить единые точки отказа

Балансировщики нагрузки могут быть реализованы аппаратно (дорого) или программно, например HAProxy.
Дополнительные преимущества включают в себя:

  • SSL-терминация─ Расшифровывать входящие запросы и шифровать ответы сервера, чтобы внутренним серверам не приходилось выполнять эти потенциально дорогостоящие операции.
  • Ссылка сохраняется─ Если веб-приложение не отслеживает сеансы, выпустите файлы cookie и маршрута для конкретного клиента к тому же экземпляру.

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

Балансировщик нагрузки может направлять трафик несколькими способами:

Балансировка нагрузки уровня 4

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

Балансировщик нагрузки уровня 7

Балансировщик нагрузки уровня 7 на основе мониторингаприкладной уровеньЧтобы решить, как распределять запросы. Это будет включать содержимое, сообщение и файлы cookie запрошенного заголовка. Семиуровневый балансировщик нагрузки завершает сетевой трафик, читает сообщения и определяет балансировку нагрузки, а затем передает данные на определенные серверы. Например, семиуровневый балансировщик нагрузки может напрямую подключать видеотрафик к управляемому видео, загружая при этом более конфиденциальный трафик пользовательских счетов на более защищенный сервер.

За счет гибкости балансировка нагрузки уровня 4 требует меньше времени и вычислительных ресурсов, чем балансировка нагрузки уровня 7, хотя это оказывает незначительное влияние на производительность современного массового оборудования.

Горизонтальное расширение

Балансировщики нагрузки также помогают с горизонтальным масштабированием, повышая производительность и доступность. Экономически выгоднее использовать товарное оборудование, а не единичное оборудование.Вертикальное расширениеБолее дорогое оборудование имеет более высокую доступность. Легче нанимать таланты для коммерческого оборудования, чем для конкретных корпоративных систем.

Дефект: Горизонтальное масштабирование

  • Горизонтальное масштабирование усложняет работу и требует дублирования серверов.
    • Серверы не должны иметь состояния: они также не должны содержать данные, связанные с пользователем, такие как сеансы или изображения профиля.
    • Сеансы могут храниться централизованно в базе данных или сохранятьсятайник(Redis, Memcached) в хранилище данных.
  • Нижестоящие серверы, такие как кэши и базы данных, должны масштабироваться вместе с вышестоящими серверами, чтобы обрабатывать больше одновременных подключений.

Минусы: Балансировщик нагрузки

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

Источник и дальнейшее чтение

Обратный прокси (веб-сервер)





Источник: Википедия


Обратный прокси — это веб-сервер, который может централизованно вызывать внутренние службы и предоставлять унифицированный интерфейс общедоступным клиентам. Запрос от клиента сначала перенаправляется обратным прокси-сервером на сервер, который может ответить на запрос, а затем прокси-сервер возвращает ответ сервера клиенту.

Преимущества включают в себя:

  • Увеличение безопасности- Скрыть информацию о внутреннем сервере, заблокировать IP-адреса в черном списке и ограничить количество подключений на одного клиента.
  • Повышение масштабируемости и гибкости- Клиенты видят только IP обратного прокси-сервера, что позволяет добавлять или удалять серверы или изменять их конфигурацию.
  • Завершать сеансы SSL локально- Расшифровывать входящие запросы и шифровать ответы сервера, чтобы внутренним серверам не приходилось выполнять эти потенциально дорогостоящие операции.
    • Устраняет установку на каждом сервереX.509Требуется сертификат
  • компрессия- Сжать ответ сервера
  • тайник- Напрямую возвращает кешированный результат попадания
  • статический контент- Подавать статический контент напрямую
    • HTML/CSS/JS
    • рисунок
    • видео
    • и т.д

Балансировщик нагрузки и обратный прокси

  • Развертывание балансировщика нагрузки полезно при наличии нескольких серверов. Как правило, балансировщик нагрузки направляет трафик на группу серверов, которые работают одинаково.
  • Обратные прокси полезны даже при наличии только одного веб-сервера или сервера приложений, и вы можете воспользоваться преимуществами, описанными в предыдущем разделе.
  • Такие решения, как NGINX и HAProxy, могут поддерживать как обратный прокси-сервер уровня 7, так и балансировку нагрузки.

Минус: обратный прокси

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

Источник и дальнейшее чтение

прикладной уровень





Источник: Введение в масштабируемую системную архитектуру.

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

Принцип единой ответственностиПродвигайте небольшие автономные сервисы, которые работают вместе. Небольшие команды могут более агрессивно планировать рост, предлагая небольшие услуги.

Рабочие процессы на прикладном уровне также могут быть реализованыАсинхронный.

Микросервисы

Темы, связанные с этим обсуждением,Микросервисы, можно описать как серию небольших модульных сервисов, которые можно развернуть независимо. Каждая служба работает в независимом потоке и взаимодействует с помощью четко определенных упрощенных механизмов для совместного достижения бизнес-целей.1

Например, в Pinterest могут быть следующие микросервисы: профиль пользователя, подписчики, потоковая передача, поиск, загрузка фотографий и т. д.

обнаружение службы

рисунокConsul,EtcdиZookeeperТакая система может помочь службам обнаруживать друг друга, отслеживая регистрационные имена, адреса, порты и т. д.Health checksможет помочь подтвердить целостность службы иHTTPдорожка. И Consul, и Etcd имеют встроенныйхранилище ключей-значенийИспользуется для хранения информации о конфигурации и другой общей информации.

Недостаток: прикладной уровень

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

Источник и дальнейшее чтение

база данных





Источник: Масштабирование количества пользователей до первых десяти миллионов.

Система управления реляционными базами данных (RDBMS)

Реляционная база данных, такая как SQL, представляет собой набор элементов данных, организованных в виде таблицы.

Примечание для проверки: здесь автор SQL может иметь в виду MySQL.

ACIDИспользуется для описания реляционной базы данных.делахарактеристики.

  • атомарность- Все операции внутри каждой транзакции либо завершены, либо не завершены.
  • последовательность- Любая транзакция переводит базу данных из одного допустимого состояния в другое.
  • изоляция- Результат одновременного выполнения транзакций такой же, как при последовательном выполнении транзакций.
  • Упорство- После совершения транзакции воздействие на систему является постоянным.

Расширения реляционных баз данных включают множество методов:репликация master-slave,мастер-мастер-репликация,соединение,Фрагментация,денормализацияиНастройка SQL.





Источник: масштабируемость, доступность, стабильность, шаблоны

репликация master-slave

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

Недостаток: репликация master-slave
  • Переход от библиотеки к мастеру требует дополнительной логики.
  • Ссылаться наНедостаток: копирование, репликация master-slave и репликация master-masterобщийПроблема.





Источник: масштабируемость, доступность, стабильность, шаблоны.

мастер-мастер-репликация

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

Недостаток: репликация master-master
  • Вам нужно добавить балансировщик нагрузки или внести изменения в логику приложения, чтобы определить, в какую базу данных производить запись.
  • Most Lord - Основная система либо гарантирует консистентность (нарушая ACID), либо потому что задержка записи генерируется синхронно.
  • По мере того, как присоединяется больше узлов записи и увеличивается задержка, способы разрешения конфликтов становятся все более и более важными.
  • Ссылаться наНедостаток: копирование, репликация master-slave и репликация master-masterобщийПроблема.
Недостаток: копирование
  • Если прежняя основная библиотека реплицируется на другие узлы, то во вновь записанных данных данные будут зависать, происходит потеря данных.
  • Записи воспроизводятся на реплике, отвечающей за операции чтения. Реплика может быть заблокирована из-за чрезмерных операций записи, что приводит к ненормальной функции чтения.
  • Чем больше ведомых устройств считывается, тем больше данных для записи необходимо реплицировать, что приводит к более серьезным задержкам репликации.
  • В некоторых системах баз данных запись в мастер может выполняться параллельно с несколькими потоками, но реплики чтения поддерживают только однопотоковую последовательную запись.
  • Дублирование означает больше оборудования и дополнительную сложность.
Источник и дальнейшее чтение

соединение





Источник: Масштабирование количества пользователей до первых десяти миллионов.

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

Минусы: Объединенный
  • Если ваша схема базы данных требует большого количества функций и таблиц данных, объединения не очень эффективны.
  • Вам необходимо обновить логику вашего приложения, чтобы определить, в какую базу данных выполнять чтение и запись.
  • использоватьserver linkОбъединение данных из двух библиотек более сложно.
  • Для федерации требуется больше оборудования и дополнительная сложность.
Источник и расширение: United

Фрагментация





Источник: масштабируемость, доступность, стабильность, шаблоны.

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

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

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

Недостаток: Шардинг
  • Вам необходимо изменить логику приложения для реализации сегментирования, что может привести к сложным SQL-запросам.
  • Необоснованное сегментирование может привести к несбалансированной загрузке данных. Например, часто используемые пользовательские данные приведут к тому, что нагрузка на сегмент будет выше, чем на другие сегменты.
  • Операции с данными, которые объединяют несколько сегментов, более сложны.
  • Разделение требует большего количества оборудования и дополнительной сложности.

Источник и расширенное чтение: Sharding

денормализация

Денормализация пытается обменять производительность записи на производительность чтения. Резервные копии данных между несколькими таблицами, чтобы избежать дорогостоящих операций соединения. Некоторые реляционные базы данных, такие какPostgreSQlи поддержка Ораклматериализованное представление, который может справиться с избыточным хранением информации и обеспечить согласованность избыточных копий.

Когда используются данные, такие каксоединениеиФрагментацияи другие технологии сегментированы, что еще больше усложняет обработку операций объединения в центрах обработки данных. Денормализация может обойти эту сложную операцию соединения.

В большинстве систем чтение выполняется с гораздо большей частотой, чем запись, в соотношении 100:1 или даже 1000:1. Операции чтения, требующие сложных соединений с базой данных, очень дороги и требуют много времени на дисковые операции.

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

Настройка SQL

Настройка SQL — это широкая тема со многими связаннымиКнигаможно использовать как ссылку.

использоватьОриентирыианализ производительностиВажно моделировать и обнаруживать узкие места в системе.

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

Сравнительный анализ и анализ производительности могут привести вас к следующим сценариям оптимизации.

Улучшенный режим
  • Для быстрого доступа MySQL хранит данные на диске в непрерывных блоках.
  • использоватьCHARТипы хранят поля фиксированной длины, не используютVARCHAR.
    • CHARЭффективен для быстрого произвольного доступа. При использованииVARCHAR, если вы хотите прочитать следующую строку, вы должны сначала прочитать до конца текущей строки.
  • использоватьTEXTТипы хранят большие фрагменты текста, например основную часть блога.TEXTБулев поиск также разрешен. использоватьTEXTПоля должны хранить указатель на диске, чтобы найти блок текста.
  • использоватьINTТипы хранят большие числа до 2 ^ 32 или 4 миллиарда.
  • использоватьDECIMALТип хранит валюту, чтобы избежать ошибок представления с плавающей запятой.
  • избегать использованияBLOBSСохраните объект, сохраните место, где хранится объект.
  • VARCHAR(255)это максимальное количество символов, хранимых в виде 8-значного числа, и в некоторых реляционных базах данных максимальное использование байтов.
  • Установить в применимых сценарияхNOT NULLОграничениеУлучшить эффективность поиска.
используйте правильный индекс
  • вы спрашиваете(SELECT,GROUP BY,ORDER BY,JOIN) будет быстрее, если используется индекс.
  • Индексы обычно представляются как самобалансирующиесяB-дерево, который упорядочивает данные и позволяет выполнять операции поиска, последовательного доступа, вставки и удаления за логарифмическое время.
  • Установка индекса сохранит данные в памяти и займет больше места в памяти.
  • Операции записи будут выполняться медленнее, поскольку индекс необходимо обновить.
  • При загрузке большого количества данных отключите индекс перед загрузкой данных, затем восстановите индекс, это может быть быстрее.
Избегайте дорогостоящих операций соединения
  • Есть желаемая производительность, он может быть нестандартизирован.
Разделить таблицу данных
  • Разделение данных горячих точек на отдельные таблицы может помочь с кэшированием.
Настройка кэша запросов
Источник и дальнейшее чтение

NoSQL

NoSQL естьбаза данных "ключ-значение",база данных документов,столбчатая база данныхилиграф базы данныхсобирательное имя. Базы данных денормализованы, а соединения таблиц в основном выполняются в коде приложения. Большинство NoSQL не могут реализовать действительно ACID-совместимые транзакции, поддержкув конечном итоге последовательный.

BASEЧасто используется для описания характеристик баз данных NoSQL. по сравнению сТеория CAP, BASE делает упор на доступность, а не на согласованность.

  • в основном доступны- Система гарантирует доступность.
  • мягкое состояние- Состояние системы может меняться со временем даже без ввода данных.
  • окончательная согласованность- Через некоторое время система в конечном итоге становится согласованной, поскольку в течение этого времени система не получает никаких входных данных.

кроме как вSQL или NoSQLТакже очень полезно знать, какой тип базы данных NoSQL лучше всего подходит для вашего случая использования. Мы кратко рассмотрим в следующем разделехранилище ключей-значений,хранилище документов,столбчатое хранилищеихранилище графовбаза данных.

хранилище ключей-значений

Абстрактная модель: хеш-таблица

Хранилища «ключ-значение» обычно могут выполнять чтение и запись за время O(1) при использовании памяти или твердотельного накопителя для хранения данных. Хранение данных может бытьлексикографический порядокКлючи сохраняются, что позволяет эффективно извлекать ключи. Хранилища ключей и значений можно использовать для хранения метаданных.

Хранилища ключей и значений отличаются высокой производительностью и обычно используются для хранения простых моделей данных или часто изменяемых данных, таких как кэши в памяти. Хранилища «ключ-значение» обеспечивают ограниченные операции, и если требуется больше операций, сложность переносится на уровень приложения.

Хранилища ключей и значений являются основой для более сложных систем хранения, таких как хранилища документов и, в некоторых случаях, даже хранилища графов.

Источник и дальнейшее чтение

хранилище типов документов

Абстрактная модель: хранилище ключей и значений с документами в качестве значений

Хранилище типа документа сосредоточено вокруг документа (XML, JSON, двоичный файл и т. д.), в котором хранится вся информация об указанном объекте. Хранилище документов предоставляет API или операторы запросов для реализации запросов на основе внутренней структуры самого документа. Обратите внимание, что многие базы данных хранилища ключей и значений имеют функцию хранения метаданных для полезных значений, что также стирает границы между этими двумя типами хранения.

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

Некоторые хранилища типов документов, такие как MongoDB и CouchDB, также предоставляют SQL-подобные операторы запросов для реализации сложных запросов. DynamoDB поддерживает как хранилища ключей-значений, так и хранилища типов документов.

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

Источник и дополнительная литература: хранилище типов документов

столбчатое хранилище





Источник: SQL и NoSQL, краткая история.

Абстрактная модель: вложеннаяColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>карта

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

Google выпускает первую базу данных хранилища столбцовBigtable, который влияет на базы данных с открытым исходным кодом, активные в экосистеме Hadoop.HBaseи FacebookCassandra. Системы хранения, такие как BigTable, HBase и Cassandra, хранят ключи в алфавитном порядке, что позволяет эффективно читать ключевые столбцы.

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

Исходное и расширенное чтение: Хранилище столбцов

граф базы данных





Источник: База данных графов.

Абстрактная модель: граф

В графовой базе данных узел соответствует записи, а дуга соответствует связи между двумя узлами. Базы данных графов оптимизированы для представления сложных отношений или отношений «многие ко многим» с многочисленными внешними ключами.

Сложные отношения модели хранения данных базы данных FIG, такие как социальные сети, обеспечивают высокую производительность. Это относительно новые, еще не получившие широкого распространения средства разработки или ресурсы, которые найти относительно сложно. Многие цифры только черезREST APIдоступ.

Связанные ресурсы и дополнительная литература: Рисунок

Источник и дальнейшее чтение: NoSQL

SQL или NoSQL





Источник: Преобразование из СУБД в NoSQL

ВыбратьSQLпричина:

  • структурированные данные
  • Строгий режим
  • реляционные данные
  • Требуются сложные операции соединения
  • дела
  • Очистить режим расширения
  • Существующие ресурсы богаче: разработчики, сообщества, кодовые базы, инструменты и т. д.
  • Запрос по индексу очень быстрый

ВыбратьNoSQLпричина:

  • полуструктурированные данные
  • Динамический или гибкий режим
  • нереляционные данные
  • Не требуются сложные операции соединения
  • Храните терабайты (или даже петабайты) данных
  • Рабочие нагрузки с большим объемом данных
  • IOPS высокая пропускная способность

Пример данных, подходящих для NoSQL:

  • Данные захороненных точек и данные журнала
  • Таблица лидеров или данные о счете
  • Временные данные, такие как корзины покупок
  • Часто используемые («горячие») таблицы
  • Метаданные/справочная таблица
Источник и дополнительная литература: SQL или NoSQL





Источник: Шаблоны проектирования масштабируемых систем.

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

Лучше всего использовать осколки базы данных с равномерно распределенным чтением. Однако горячие данные будут вызывать неравномерное распределение операций чтения, что приведет к узким местам.Если перед базой данных будет добавлен кеш, он сгладит влияние неравномерной нагрузки и всплесков трафика на базу данных.

Кэш клиента

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

Кэш CDN

CDNТакже считается разновидностью тайника.

Кэш веб-сервера

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

кеш базы данных

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

кеш приложения

Кэши в памяти, такие как Memcached и Redis, представляют собой тип хранилища «ключ-значение» между приложением и хранилищем данных. Поскольку данные хранятся в оперативной памяти, это намного быстрее, чем обычная база данных, хранящаяся на диске. ОЗУ более ограничено, чем диск, поэтому, напримерleast recently used (LRU)изалгоритм инвалидации кешаВы можете поместить «популярные данные» в оперативную память и не обрабатывать некоторые «непопулярные» данные.

Redis имеет следующие дополнительные функции:

  • Параметры сохранения
  • Встроенные структуры данных, такие как отсортированные наборы и списки

Существует несколько уровней кэша, которые можно разделить на две большие категории:запрос к базе данныхиобъект:

  • уровень строки
  • уровень запроса
  • полный сериализуемый объект
  • Полностью визуализированный HTML

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

Кэширование на уровне запросов к базе данных

Когда вы делаете запрос к базе данных, хеш-значение оператора запроса и результат запроса сохраняются в кэше. Этот подход страдает от следующих проблем:

  • Трудно удалить кешированные результаты со сложными запросами.
  • Если элемент данных, например элемент данных в таблице, изменяется, все кэшированные результаты, которые могут содержать измененный элемент, необходимо удалить.

Кэширование на уровне объекта

Относитесь к своим данным как к объектам, точно так же, как к коду вашего приложения. Пусть приложение компонует данные из базы данных в экземпляр класса или структуру данных:

  • Если базовые данные объекта изменились, объект удаляется из кэша.
  • Разрешает асинхронную обработку: рабочие процессы собирают объекты, используя последние кэшированные объекты.

Предлагаемый кешированный контент:

  • сеанс пользователя
  • Полностью визуализированная веб-страница
  • поток активности
  • Данные пользовательского графика

Когда обновлять кеш

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

режим кэширования





Источник: из кеша в сетку данных в памяти.

Приложение читает и пишет из памяти. Кэш не взаимодействует напрямую с памятью, а приложение делает следующее:

  • Найти запись в кеше, если нужных данных нет в кеше
  • Загрузите нужный контент из базы данных
  • Сохранить найденные результаты в кэше
  • Вернуть желаемый контент
def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user

MemcachedОбычно используется таким образом.

Данные, добавленные в кэш, считываются быстро. Режим кэширования также известен как ленивая загрузка. Кэшируются только запрошенные данные, что позволяет избежать заполнения кеша данными, которые не были запрошены.

Недостатки кэширования:
  • Если запрошенные данные отсутствуют в кэше, для извлечения данных требуется три шага, что может привести к значительным задержкам.
  • Если данные в базе данных обновляются, данные в кеше будут устаревшими. Эту проблему необходимо смягчить, установив TTL для принудительного обновления кэша или режима сквозной записи.
  • Когда узел выходит из строя, он будет заменен новым узлом, что увеличивает время задержки.

режим сквозной записи





Источник: масштабируемость, доступность, стабильность, шаблоны.

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

  • Приложение добавляет/обновляет данные в кеш
  • Кэш синхронно записывает в хранилище данных
  • Вернуть желаемый контент

Код приложения:

set_user(12345, {"foo":"bar"})

Код кэша:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)

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

Недостатки режима сквозной записи:
  • Новые узлы, созданные из-за сбоя или масштабирования, новые узлы не кэшируются до тех пор, пока база данных не будет обновлена. Режим сквозной записи приложения кэша может решить эту проблему.
  • Большинство записанных данных могут никогда не быть прочитаны, а TTL сводит к минимуму такие случаи.

режим обратной записи





Источник: масштабируемость, доступность, стабильность, шаблоны.

В режиме записи приложение делает следующее:

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

обновить





Источник: из кеша в сетку данных в памяти.

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

Если кеш может точно предсказать, какие данные могут быть запрошены в будущем, очистка может привести к снижению задержки и времени чтения.

Недостатки обновления:
  • Невозможность точно предсказать, какие данные потребуются в будущем, может привести к снижению производительности по сравнению с отсутствием обновления.

Недостатки кэширования:

  • Необходимо поддерживать согласованность между кешем и реальным источником данных, таким как база данных в соответствии сКэш недействителен.
  • Необходимо изменить приложение, например добавить Redis или memcached.
  • Аннулирование кеша — сложная проблема, а когда обновлять кеш — сложный вопрос, связанный с ним.

Связанные ресурсы и дополнительная литература

асинхронный





Источник: Введение в масштабируемую системную архитектуру.

Асинхронные рабочие процессы помогают сократить время запросов, которые в противном случае выполнялись бы последовательно. Они могут помочь сократить время обработки запросов, заранее выполняя трудоемкую работу, например, периодически собирая данные.

очередь сообщений

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

  • Приложение отправляет задание в очередь, а затем уведомляет пользователя о статусе задания.
  • Рабочий берет задание из очереди, обрабатывает его и отображает задание как завершенное.

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

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

RabbitMQОчень популярен, но требует адаптации к протоколу AMQP и управления собственными узлами.

Amazon SQSразмещен, но может иметь большую задержку, и сообщения могут быть доставлены дважды.

очередь задач

Очередь задачи получает задачи и связанные с ними данные, запустите их, а затем доставить его результаты. Они могут поддерживать планирование и могут использоваться для запуска вычислительных интенсивных рабочих мест на заднем плане.

CeleryПланирование поддерживается и в основном разработано на Python.

обратное давление

Если очередь начинает значительно увеличиваться, размер очереди может превысить размер памяти, что приведет к промахам кэша, чтению с диска и даже снижению производительности.обратное давлениеЭто может помочь нам, ограничивая размер очереди, чтобы поддерживать высокую пропускную способность и хорошее время отклика для заданий в очереди. Как только очередь заполнится, клиент получит код состояния Server Busy HTTP 503, чтобы повторить попытку позже. Клиент может повторить запрос позже, возможно,Экспоненциальная отсрочка.

Недостатки асинхронности:

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

Связанные ресурсы и дополнительная литература

коммуникация





Источник: 7-уровневая модель OSI.

Протокол передачи гипертекста (HTTP)

HTTP — это метод кодирования и передачи данных между клиентом и сервером. Это протокол запроса/ответа: клиентские и серверные запросы и ответы на соответствующий контент и информацию о статусе выполнения. HTTP является автономным, позволяя запросам и ответам проходить через множество промежуточных маршрутизаторов и серверов, которые выполняют балансировку нагрузки, кэширование, шифрование и сжатие.

Базовый HTTP-запрос состоит из глагола (метода) и ресурса (конечной точки). Ниже приведены распространенные HTTP-глаголы:

глагол описывать *Идемпотент безопасность кэшируемый
GET читать ресурс Yes Yes Yes
POST Создайте ресурс или запустите процесс для обработки данных No No Да, если ответ содержит информацию об обновлении
PUT Создать или заменить ресурсы Yes No No
PATCH Частично обновленные ресурсы No No Да, если ответ содержит информацию об обновлении
DELETE удалить ресурс Yes No No

Многократное выполнение не дает разных результатов.

HTTP зависит от протоколов более низкого уровня, таких какTCPиUDP) протокол прикладного уровня.

Источник и расширенное чтение: HTTP

Протокол управления передачей (TCP)





Источник: Как сделать многопользовательскую игру

TCP проходитIP-сетьпротокол, ориентированный на соединение. использоватьПожать рукиПодключаться и отключаться. Все пакеты передаются в исходной последовательности для обеспечения прибытия, эти меры гарантируют, что пакеты данных не будут повреждены:

Если отправитель не получит надлежащего ответа, он повторно отправит пакет. Если есть несколько тайм-аутов, соединение будет разорвано. Реализация TCPуправление потоком)иконтроль перегрузки. Эти гарантии вызывают задержки и обычно приводят к менее эффективной передаче, чем UDP.

Чтобы обеспечить высокую пропускную способность, веб-серверы могут поддерживать большое количество соединений TCP, что приводит к высокому использованию памяти. Наличие большого количества открытых соединений между потоками веб-сервера может быть дорогостоящим и ресурсоемким, т.memcachedсервер.пул соединенийМожет помочь, кроме переключения на UDP, где это применимо.

TCP полезен для критичных ко времени приложений, требующих высокой надежности. Примеры включают веб-серверы, информацию базы данных, SMTP, FTP и SSH.

Используйте TCP вместо UDP в следующих случаях:

  • Вам нужно, чтобы данные были неповрежденными.
  • Вам нужна автоматическая оптимальная оценка пропускной способности сети.

Протокол пользовательских дейтаграмм (UDP)





Источник: Как сделать многопользовательскую игру

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

UDP может передавать дейтаграммы всем устройствам в подсети. Эта параDHCPПолезно, потому что устройству в подсети не назначен IP-адрес для TCP, а IP является обязательным.

UDP менее надежен, но подходит для VoIP, видеочата, потоковой передачи и многопользовательских игр в реальном времени.

Используйте UDP вместо TCP в следующих ситуациях:

  • вам нужна низкая задержка
  • Задержка данных хуже, чем потеря данных
  • Вы хотите реализовать свой собственный метод исправления ошибок

Источник и дальнейшее чтение: TCP и UDP

Протокол удаленного вызова процедур (RPC)





Source: Crack the system design interview

В RPC клиент перейдет к вызову другого адресного пространства (обычно это удаленный сервер) в методе. Вызывающий код выглядит так, будто вызов является локальным методом, конкретный процесс взаимодействия клиента и сервера является абстрактным. Для местных звонков междугородние звонки обычно медленные и менее надежные, поэтому полезно различать их. Популярная среда RPC включает в себяProtobuf,ThriftиAvro.

RPC — это протокол «запрос-ответ»:

  • клиентская программа── вызвать клиентскую программу-заглушку. Как и при вызове нативного метода, аргументы помещаются в стек.
  • Программа-заглушка клиента── идентификатор запроса и параметры процесса, упакованные в информацию запроса.
  • Модуль связи с клиентом── Отправлять информацию от клиента на сервер.
  • Модуль связи с сервером── Передайте принятый пакет программе-заглушке на стороне сервера.
  • Программа-заглушка сервера── Распаковать результат, вызвать метод сервера по id процедуры и передать параметры.

Пример вызова RPC:

GET /someoperation?data=anId

POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

RPC фокусируется на раскрытии методов. RPC часто используется для решения проблем производительности с внутренней связью, чтобы вы могли вручную обрабатывать локальные вызовы, чтобы лучше соответствовать вашей ситуации.

Выбирайте нативную библиотеку (также известную как SDK), когда:

  • Вы знаете свою целевую платформу.
  • Вы хотите контролировать, как осуществляется доступ к вашей «логике».
  • Вы хотите контролировать ошибки, возникающие в вашей библиотеке.
  • Опыт работы и конечного пользователя - ваши основные проблемы.

следитьRESTAPI-интерфейсы HTTP, как правило, больше подходят для общедоступных API.

Минусы: ПКП

  • Клиент RPC тесно связан с реализацией службы.
  • Новый API должен определяться для каждой операции или варианта использования.
  • RPC трудно отлаживать.
  • Вы не сможете легко модифицировать существующую технологию. Например, если вы хотитеSquidТакой кеш-сервер гарантирует, чтоRPC правильно кэшируютсяЭто может потребовать дополнительных усилий.

Передача репрезентативного состояния (REST)

REST — это обязательная модель проектирования архитектуры клиент/сервер, в которой клиент основан на серии операций с ресурсами, управляемых сервером. Сервер предоставляет интерфейс для изменения или получения ресурсов. Все коммуникации должны быть без сохранения состояния и кэшируемыми.

Интерфейсы RESTful имеют четыре правила:

  • Знаки ресурсов (URI на http)-- Используйте один и тот же URI для любой операции.
  • Изменение представления (HTTP-действие)── использовать действия, заголовки и тело.
  • Сообщение об ошибке с самоописанием (код состояния в HTTP)── Используйте коды состояния, не изобретайте велосипед.
  • HATEOAS(HTML-интерфейс в http)── ваш веб-сервер должен иметь доступ через браузер.

Пример REST-запроса:

GET /someresources/anId

PUT /someresources/anId
{"anotherdata": "another value"}

REST фокусируется на раскрытии данных. Он уменьшает степень связи между клиентом и сервером и часто используется при разработке общедоступных интерфейсов HTTP API. REST использует более общий и канонический подход к предоставлению ресурсов через URI.Выражается заголовкомА через GET, POST, PUT, DELETE и PATCH эти действия действовать. Из-за своей природы без сохранения состояния REST легко масштабировать и изолировать.

Минусы: ОТДЫХ

  • Из-за того, что REST сосредоточен на раскрытии данных, он может плохо адаптироваться, когда ресурсы не организованы или структурированы естественным образом. Например, возврат обновленных записей, соответствующих определенному набору событий за последний час, сложно представить в виде пути. В REST это можно сделать с помощью пути URI, параметров запроса и, возможно, тела запроса.
  • REST обычно полагается на несколько действий (GET, POST, PUT, DELETE и PATCH), но иногда они сами по себе не отвечают вашим потребностям. Например, перемещение просроченных документов в архивную папку может быть нелегко выразить с помощью приведенных выше глаголов.
  • Чтобы отобразить одну страницу, выборка сложных ресурсов, вложенных в иерархию, требует нескольких циклов обмена данными между клиентом и сервером. Например, получить содержимое блога и связанные с ним комментарии. Эти множественные обходы очень обременительны для мобильных приложений, использующих неопределенное сетевое окружение.
  • Со временем в ответ API может быть добавлено больше полей, и старые клиенты будут получать все новые поля данных, даже те, которые им не нужны, в результате это увеличит размер полезной нагрузки и вызовет большую задержку.

RPC против 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?

Источник и дополнительная литература: REST и RPC

Безопасность

Эта часть нуждается в большем количестве контента.собраться вместе!

Безопасность — обширная тема. Если у вас нет значительного опыта, знаний в области безопасности или должность, на которую вы претендуете, не требует знаний в области безопасности, вам не нужно знать ничего, кроме основ безопасности:

  • Шифруется во время доставки и ожидания
  • Обрабатывать все вводимые пользователем данные и параметры, отправленные пользователем, чтобы предотвратитьXSSиSQL-инъекция.
  • Используйте параметризованные запросы, чтобы предотвратить инъекцию SQL.
  • использоватьпринцип наименьших привилегий.

Источник и дальнейшее чтение

приложение

В какой-то момент вас попросят сделать консервативные оценки. Например, вам может потребоваться оценить, сколько времени потребуется для создания эскизов 100 изображений с диска или сколько памяти потребуется для структуры данных.2 силовой столиНекоторые временные данные, которые должен знать каждый разработчик(Аннотация: на OSChina есть эта статьяперевод) несколько полезных ссылок.

2 силовой стол

Power           Exact Value         Approx Value        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                          100   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

Метрики, основанные на приведенных выше цифрах:

  • Последовательное чтение с диска со скоростью 30 МБ/с
  • Последовательное чтение из Ethernet 1 Гбит/с со скоростью 100 МБ/с
  • Чтение с SSD со скоростью 1 ГБ/с
  • Чтение из основной памяти со скоростью 4 ГБ/с
  • Может облететь землю 6-7 раз в секунду
  • 2000 круглых поездок в секунду в центре обработки данных

Визуализация числа задержек

Источник и дальнейшее чтение

Другие вопросы на собеседовании по системному проектированию

Общие вопросы для собеседования по проектированию систем со ссылками на решения по их решению

проблема Цитировать
Создайте службу синхронизации файлов, похожую на Dropbox youtube.com
Разработать поисковую систему, похожую на Google queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu
Разработан аналогично расширяемым сетевым рептилиям Google. quora.com
Дизайн Документов Google code.google.com
neil.fraser.name
Проектирование Redis-подобного хранилища ценностей slideshare.net
Проектирование системы кэширования наподобие Memcached slideshare.net
Разработка рекомендательной системы наподобие Amazon. hulu.com
ijcai13.org
Создайте систему коротких ссылок, такую ​​как 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
Проектирование сети доставки контента наподобие CloudFlare cmu.edu
Создайте систему популярных тем в стиле Twitter. michael-noll.com
snikolov .wordpress.com
Разработайте систему генерации случайных идентификаторов blog.twitter.com
github.com
Возвращает топ k наибольшего количества запросов за определенный период времени ucsb.edu
wpi.edu
Разработайте сервисную систему с данными, поступающими из нескольких центров обработки данных. highscalability.com
Создайте многопользовательскую карточную онлайн-игру indieflashblog.com
buildnewgames.com
Разработайте систему сбора мусора stuffwithstuff.com
washington.edu
Добавьте больше вопросов по дизайну системы способствовать

реальная архитектура

Статьи о том, как настоящие системы устроены в реальности.





Source: Twitter timelines at scale

Вместо того, чтобы сосредотачиваться на деталях следующих статей, сосредоточьтесь на следующем:

  • Откройте для себя общие принципы, методы и шаблоны в этих статьях.
  • Узнайте, какие проблемы решает каждый компонент, когда его использовать, а когда не использовать.
  • Обзор изученных статей
тип система Цитировать
Data processing MapReduce- Распределенная обработка данных Google research.google.com
Data processing Spark- Распределенная обработка данных Databricks slideshare.net
Data processing Storm- Распределенная обработка данных для Twitter slideshare.net
Data store Bigtable- столбчатая база данных Google harvard.edu
Data store HBase- Реализация Bigtable с открытым исходным кодом slideshare.net
Data store Cassandra- База данных листинга Facebook slideshare.net
Data store DynamoDB- база данных документов Amazon harvard.edu
Data store MongoDB- База документов slideshare.net
Data store Spanner- Глобальная распределенная база данных Google research.google.com
Data store Memcached- Система кэширования с распределенной памятью slideshare.net
Data store Redis- Распределенная система кэширования памяти с сохранением и типами значений slideshare.net
File system Google File System (GFS)- Распределенная файловая система research.google.com
File system Hadoop File System (HDFS)- Реализация GFS с открытым исходным кодом apache.org
Misc Chubby- Служба блокировки Google с низким уровнем связи для распределенных систем. research.google.com
Misc Dapper- Инфраструктура отслеживания распределенной системы research.google.com
Misc Kafka- Система обмена сообщениями «публикация-подписка» LinkedIn. slideshare.net
Misc Zookeeper- Централизованная инфраструктура и службы координации slideshare.net
Добавить больше способствовать

Системная архитектура компании

Company Reference(s)
Amazon Архитектура Амазонки
Cinchcast 1500 часов аудио в день
DataSift Добыча 120 000 твитов в секунду в режиме реального времени
DropBox Как мы масштабируем Dropbox
ESPN 100 000 операций в секунду
Google инфраструктура Google
Instagram 14 миллионов пользователей, хранилище фотографий мега-уровня
Что движет Instagram
Justin.tv Архитектура прямых трансляций Justin.Tv
Facebook Масштабируемый memcached Facebook
TAO: распределенное хранилище данных для социального графа Facebook.
Хранилище изображений Facebook
Flickr Архитектура Flickr
Mailbox От 0 до 1 миллиона пользователей в течение 6 недель
Pinterest От нуля до миллиардов просмотров страниц в месяц
18 миллионов посетителей, 10-кратный рост, 12 сотрудников
Playfish 50 миллионов пользователей в месяц и растет
PlentyOfFish Архитектура PlentyOfFish
Salesforce Как они обрабатывают 1,3 миллиарда транзакций в день
Stack Overflow Архитектура переполнения стека
TripAdvisor 40 млн посетителей, 200 млн просмотров страниц, 30 ТБ данных
Tumblr 15 миллиардов просмотров страниц в месяц
Twitter Making Twitter 10000 percent faster
Использование MySQL для хранения 250 миллионов твитов в день
150 млн активных пользователей, 300 тыс. запросов в секунду, брандмауэр 22 МБ/с
Масштабируемое расписание
Данные о размере Twitter
Поведение в Твиттере: более 100 миллионов пользователей
Uber Как Uber расширяет свой рынок в реальном времени
WhatsApp Facebook покупает архитектуру WhatsApp за 19 миллиардов долларов
YouTube Масштабируемость YouTube
Архитектура YouTube

Инженерный блог компании

Структура компании, в которую вы проходите собеседование

Проблема, с которой вы столкнулись, может исходить из той же области

Источник и дальнейшее чтение

совершенствуется

Заинтересованы в добавлении некоторых частей или помощи в улучшении некоторых частей?Присоединяйся!

  • Распределенные вычисления с MapReduce
  • Согласованное хеширование
  • Контроллер прямого доступа к памяти (DMA)
  • способствовать

Спасибо

Сертификаты и источники предоставляются по всему репозиторию

Специальная благодарность:

Контакты

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

может быть в моемGithub home.Найдите мои контактные данные на

лицензия

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

разное

Подробнее см.:GitHub.com/редкая земля/система…

Категории