[00:01] доступности товаров во время пиковых нагрузок в «Чёрную пятницу» ? Почему финансовые системы редко теряют транзакции, несмотря на сбои в сети? Сегодня мы рассмотрим концепции надежности и согласованности, лежащие в основе высокомасштабных распределенных [00:15] систем. Давайте сразу перейдем к делу. Надежность системы заключается не в предотвращении всех сбоев. Речь идёт о том, чтобы продолжать работать правильно, когда сбои неизбежны. Сетевые разрывы неизбежны. Серверы будут выходить из строя, жесткие диски будут [00:30] ломаться. Вопрос в том, как нам создать системы, которые будут корректно справляться с этими реалиями ? Это становится возможным благодаря семи ключевым концепциям. Давайте рассмотрим каждый из них. Теоремы CAP устанавливают фундаментальное ограничение. Распределенная [00:45] система может одновременно обеспечить не более двух из этих трех гарантий. Последовательность. Все заметки видят одни и те же данные одновременно. Доступность. На каждый запрос, поданный в рамках процедуры, не являющейся провальной, дается ответ. Допуск на разделение. [01:00] Система продолжает работать, несмотря на сбои в сети. Поскольку в распределенных системах разрывы сети неизбежны, во время таких событий вам фактически приходится выбирать между согласованностью и доступностью. [01:13] Давайте посмотрим, как реальные системы принимают это решение. Google Spanner выбирает последовательность. Она использует атомные часы и синхронизированное время в глобальных центрах обработки данных для поддержания линеаризуемых транзакций. В случае разделения сети, [01:27] мажоритарный раздел остается доступным как для чтения, так и для прав доступа, в то время как миноритарные разделы становятся доступными только для чтения. Компромисс заключается в том, что права на использование нот, находящихся в миноритарной части, теряются до тех пор, пока ситуация в миноритарной части не стабилизируется. Amazon Dynamo DB [01:42] выбирает уровень доступности. В случае разделения сети, она продолжает принимать права доступа, используя принцип согласованности в конечном итоге, и разрешает конфликты, полагаясь на то, что последнее право доступа имеет приоритет, исходя из временных меток. Пользователь всегда получает ответы, но иногда может [01:55] увидеть устаревшие данные. Ни один из подходов не является правильным или неправильным. Это зависит от ваших требований. Банковские системы, как правило, нуждаются в согласованности. В лентах социальных сетей со временем может появиться стабильность. В конечном итоге, последовательность действий сводится к простому [02:10] обещанию. Если вы прекратите вносить обновления, все реплики в конечном итоге придут к одному и тому же состоянию. Это может показаться небрежным подходом, но для крупномасштабных систем это невероятно мощный инструмент . Вот почему. В системе с конечной согласованностью процесс рисования может завершиться [02:25] немедленно, без ожидания подтверждения от всех реплик. Это повышает производительность и доступность. Корзина покупок Amazon работает именно так. Вы можете добавлять предметы, даже если некоторые серверы временно недоступны. Но как [02:38] система обрабатывает конфликты, когда разные реплики получают разные обновления? При возникновении конфликтов системы используют различные стратегии разрешения. При определении последнего правого ветра используется временная метка для выбора наиболее актуального обновления. Просто, но может привести к потере данных. [02:51] Бесконфликтные реплицируемые типы данных используют математические свойства для гарантии того, что все реплики сходятся к одному и тому же состоянию независимо от порядка обновления. Функции слияния, определяемые приложением, позволяют разработчикам создавать собственную логику для [03:05] разрешения конфликтов на основе бизнес- правил. Современные системы, такие как Dynamob, обычно достигают стабильности в течение миллисекунд в нормальных условиях, благодаря чему последующая парковка практически незаметна для пользователей. [03:19] Низкий баланс распределяет входящие запросы между несколькими серверами. Звучит за эффективной балансировкой нагрузки стоит сложная инженерная задача . Существует два основных типа. Балансировщики нагрузки 4-го уровня работают на транспортном уровне. Они принимают [03:34] решения о маршрутизации на основе IP-адресов и портов TCP/UDP. Они работают быстро, потому что им но при этом их возможности в области маршрутизации ограничены. Балансировщики нагрузки 7-го уровня [03:46] работают на прикладном уровне. Они могут анализировать HTTP-заголовки, URL-адреса и даже содержимое запросов, чтобы принимать более взвешенные решения о маршрутизации. Более затрат. [04:00] Современные балансировщики нагрузки выходят за рамки простого распределения нагрузки по принципу «кругового распределения». Маршрутизация арендованных соединений направляет новые запросы на сервер, обрабатывающий наименьшее количество активных соединений. Время аренды сервера влияет на скорость ответа каждого сервера, позволяя избежать использования [04:14] более медленных серверов. Для обеспечения высокой доступности сами устройства с низким балансом ресурсов развертываются в конфигурациях первичного и вторичного уровней с использованием протоколов пульсации. Если основной блок выйдет из строя, резервный блок возьмет на себя управление в течение миллисекунд. [04:28] Последовательное хеширование гарантирует, что один и тот же клиент будет постоянно обращаться к одному и тому же серверу, что крайне важно для поддержания состояния сессии. В прошлом видео мы говорили о горизонтальном масштабировании. Вот проблема, с которой [04:41] сталкиваются крупные системы горизонтального масштаба. У вас есть данные, распределенные по нескольким узлам, и вам нужно добавить или удалить узлы, не перемещая огромные объемы данных. Традиционные методы хеширования здесь не подходят. Если вы используете простое модульное хеширование, [04:55] то добавление одного узла потребует переназначения почти всех ваших данных. Это дорого и создаст неудобства. Последовательное хеширование элегантно решает эту проблему. Вместо прямого сопоставления клавиш с нотами, и клавиши, и ноты размещаются на [05:09] кольцевом хеше. Вот как это работает шаг за шагом. Сначала хешируем каждую ноту, чтобы определить ее положение на кольце. Во-вторых, чтобы определить, к какому месту относятся данные, хешируйте ключ и двигайтесь по кольцу по часовой стрелке, пока не дойдете до первой ноты. В-третьих, продублируйте [05:24] данные на следующие n минус одну ноту по часовой стрелке кольца. При добавлении новой заметки она получает права собственности только на ключи своих ближайших соседей. При удалении ноты клавиши перераспределяются на следующую ноту в [05:37] кольце. В результате добавления или перемещения заметок требуется переместить всего k за n клавиш, а не почти все клавиши, где k — общее количество клавиш, а n — количество узлов. И Amazon Dynamo DB, и Apache Cassandra используют согласованное хеширование именно по [05:54] этой причине. Это позволяет им масштабироваться горизонтально без масштабной реорганизации данных. сбоев в зависимых службах. Автоматические выключатели предотвращают это. Автоматический [06:10] выключатель отслеживает массив частоты отказов при вызовах зависимой службы. В нём три штата. Закрытые запросы обрабатываются в обычном режиме. Открытые запросы блокируются немедленно, возвращая быстрые ошибки. Приоткрыто. Пропускается несколько тестовых запросов, чтобы [06:26] проверить, восстановилась ли работа сервиса . Вот как это работает шаг за шагом. Автоматические выключатели отслеживают успешные и неудачные запросы к сервису. Когда частота отказов превышает пороговое значение, автоматический выключатель переходит в [06:39] разомкнутое состояние. В открытом состоянии запросы немедленно завершаются с ошибкой, даже не пытаясь обратиться к неисправной службе. Это предотвращает истощение ресурсов и дает неисправному сервису время на восстановление. По истечении заданного времени автоматический [06:53] выключатель переходит в полуоткрытое положение и пропускает несколько тестовых запросов. Если тестовые запросы пройдут успешно, автоматический выключатель замкнется, и нормальная работа возобновится. Если они потерпят неудачу, его откроют снова. Компания Netflix первой применила этот подход со своей [07:07] библиотекой истории, и теперь он является стандартом в микросервисных архитектурах. Главная мысль заключается в том, что быстрые отказы лучше, чем медленные отказы, которые расходуют ресурсы. Ограничение скорости запросов определяет, сколько запросов [07:20] клиент может отправить в течение заданного временного интервала. Это защищает системы от перегрузки и неправильного использования. Существует несколько алгоритмов, каждый из которых обладает различными характеристиками. В хранилище токенов токены накапливаются с фиксированной скоростью до достижения [07:33] максимальной вместимости. Каждый запрос расходует токен. Это позволяет контролировать импульсную скорость передачи данных, сохраняя при этом среднюю скорость. Технология Leaky Bucket обрабатывает запросы с постоянной скоростью, сглаживая пики трафика. Избыточные просьбы либо милы, либо [07:48] отброшены. Запросы с фиксированным окном могут отправляться через дискретные интервалы времени. Простой, но подверженный влиянию граничных условий, когда клиенты могут удвоить скорость, запрашивая данные в промежутках между окнами. В скользящих окнах используется скользящее среднее, которое [08:03] сглаживает проблемы, возникающие при использовании фиксированных окон. В распределенных системах ограничение лучей становится более сложным процессом. Нельзя просто подсчитывать количество запросов на одном сервере. Необходима координация между несколькими экземплярами. Одно из решений — [08:17] ограничители космических лучей, использующие скрипт l для атомарного увеличения счетчиков и установки TTL. Это обеспечивает единообразное ограничение лучей во всем кластере сервисов. Во многих системах реализовано ограничение количества пользователей на разных уровнях с различными лимитами для [08:32] аутентификаторов и анонимных пользователей, а также постепенно ужесточающимися ограничениями по мере а также постепенно ужесточающимися ограничениями по мере обнаружения подозрительных закономерностей. Вы можете управлять тем, что можете измерить. Мониторинг обеспечивает прозрачность [08:45] поведения и производительности системы. Современная наблюдательность фокусируется на четырех ключевых типах сигналов. Метрики, числовые данные временных рядов, такие как загрузка ЦП, частота запросов и количество ошибок. Журналы содержат структурированные записи [09:00] отдельных событий с контекстной информацией. Отслеживает сквозные потоки запросов, показывая, как один запрос перемещается по вашей распределенной системе. события, значимые происшествия, такие как развертывание или изменение конфигурации. Задача [09:16] состоит в обработке огромных объемов телеметрических данных. Крупномасштабные системы телеметрических данных. Крупномасштабные системы аспекта. Вам нужно быстро выявлять реальные проблемы, но вы не хотите [09:29] быть перегружены ложными тревогами. Статические пороговые значения работают для стабильных показателей, но перестают работать при изменении характера трафика. Современные системы используют статистическое обнаружение аномалий, которое выявляет нормальные закономерности и оповещает об отклонениях. Составные [09:43] оповещения объединяют несколько сигналов для снижения уровня шума. Вместо того чтобы выдавать оповещения только о высокой загрузке ЦП, вы можете выдавать оповещения, когда загрузка ЦП высока, увеличивается количество ошибок и замедляется время отклика. Цель состоит в достижении целевых показателей уровня обслуживания, которые позволяют оценить [09:58] пользовательский опыт. Не каждой системе нужны все эти шаблоны. Простое веб-приложение, обслуживающее несколько тысяч пользователей, не нуждается в согласованном хешировании или автоматических выключателях. Рассмотренные нами концепции предоставляют [10:11] вам инструменты для осознанного принятия такого компромисса, вместо того чтобы обнаруживать ограничения вашей системы во время сбоя. Начинайте с простого, всё измеряйте и усложняйте только тогда, когда у вас есть чёткие доказательства необходимости этого. Так [10:24] доказательства необходимости этого. Так создаются системы, которые надежно масштабируются. Если вам нравятся наши видео, вам может понравиться и наша рассылка по системному проектированию. В нем рассматриваются темы и тенденции в проектировании крупномасштабных систем. Нам доверяют 1 миллион [10:36] system design. Trusted by 1 million readers. Subscribed at blog.by go.com.