В недавней дискуссии с инженерами я наткнулся на общее заблуждение о том, как повторные поиски, экспоненциальный отключение, дрожание и другие помогут сохранить доступность услуг, испытывая повышенную нагрузку на обслуживание. Я был взволнован, чтобы узнать о глубоких теоретических знаниях инженеров вокруг различных типов отборов, дрожащих и повторных перебоев.
Но что меня удивило, так это то, что многие люди чувствовали, что эти повторения, отборы и дрожи являются идеальными антидотами для надежной обработки повышенной нагрузки на серверах. В то время как повторные издержки, отборы и дрожание — это удивительные и дешевые решения для обработки ситуаций взрывающих нагрузков, существует важное различие, чтобы понять, прежде чем предположить, что это универсальное лекарство.
Было бы лучше понять, как и почему они работают, а затем использовать эти знания, чтобы применить и проверять, если они работают в разных ситуациях.
Введение гипотетического обслуживания
Предположим, что у нас есть услуга сделок, которая рассчитывает скидку, применимую к данному продукту. Для простоты мы предположим, что служба сделок может обрабатывать два параллельных запроса каждую секунду. Ниже приведена простая диаграмма для службы сделок.
Диаграмма 1.
Давайте предположим, что у нас есть флеш -продажа и у нас есть пять пользователей, заинтересованных в сделках. Поэтому, когда начнется продажа, все они делают параллельные запросы на нашу службу сделок. Терпеть меня здесь; Некоторые могут сказать, что это не так, как это работает в реальном мире. Учитывая, что пять запросов намного выше, чем то, что может обрабатывать службу сделок, она начинает перегружать. Это происходит, поскольку на сервере ограниченные ресурсы, такие как ЦП, память, сетевой ввод -вывод и т. Д., И с увеличением запросов усиливается утверждение для этих ресурсов. С повышенной задержкой это часто проявляется на стороне сервера, а запросы клиентов запускают время.
Диаграмма 2 показывает связь между увеличением TPS (оси X) и задержкой (ось Y), наблюдаемое клиентами. Для простоты мы возьмем на себя один секундный тайм-аут на стороне клиента.
Диаграмма 2.
Обратите внимание, что по мере того, как одновременные TPS растут за пределами 2 (безопасный лимит, который мы установили для службы сделок на диаграмме 1), задержка выходит за рамки тайм -аута клиента на 1 секунду, что приводит к тайм -аутам запроса. Обратите внимание, что производительность обслуживания быстро снижается за пределы безопасного предела двух запросов, и это также то, как реальные услуги ведут себя почти во всех случаях, поэтому это полезная диаграмма, которую нужно помнить, если вы проводите интервью.
ПРИМЕЧАНИЕ. Чтобы определить эти безопасные ограничения (например, TPS 2 в нашем случае службы сделок), нам необходимо будет последовательно загружать сервис при некоторой частоте и обеспечить, чтобы каждый серверный ресурс и показатели услуг были в безопасных пределах. Например, ЦП не превышает 60% использования для 2 ТП, но увеличивается до 90% ЦП для 3 ТП и т. Д.
Как мы решаем эту проблему?
Когда клиенты видят тайм -ауты, мы обычно полагаемся на повторения. RETRY — это мощное решение для обработки переходных сбоев (то есть, таких сетевых проблем, как потеря пакетов и т. Д.), Сводителя, с которыми сталкиваются все распределенные системы. В поисках побочных эффектов есть побочные эффекты, о которых большинство людей не думают (например, если повторные издержки будут идентифицированными, мы создадим повторные штормы и т. Д.). Мы не углубимся в это здесь ради простоты, и я расскажу об этом в отдельной статье. На данный момент давайте реализуем повторение без каких -либо задержек.
В случае службы сделок, предполагая, что все пять наших запросов Time Out после первой попытки мы немедленно отправим такой же всплеск пяти запросов на службу сделок, что приведет к тому же результату. Таким образом, добавление повторений не помогает.
Как насчет противоядия от попытки с экспоненциальным отбором?
Экспоненциальный откат (или другой тип отключения) увеличивает период ожидания в геометрической прогрессии после каждой неудачной попытки повторения. Период ожидания обычно пропорционален подсчетам попыток повторения (многие экспоненциальные отборы будут ограничивать общий период ожидания). Учитывая все пять запросов, служба сделок будет время ожидания одновременно, поэтому экспоненциальная попытка приведет к тому же результату, что и повторение, без ожидания. Таким образом, отступление не очень помогло по сравнению с повторением, не ожидая.
Как насчет повторения с экспоненциальным отбором и дрожанием?
Давайте предположим, что гипотетическая формула дрожания — Рэнд (1,3) — где мы выбираем случайное значение от 1 до 3 секунд. Мы добавляем это случайное значение джиттера к экспоненциальному значению отборочного удара и получаем новое время ожидания, прежде чем сделать последующие запросы на службу сделок. Диаграмма 3 показывает ситуацию после того, как все пять запросов потерпели неудачу после выполнения первого запроса.
Диаграмма 3.
Например, Клиент 1 вычисляет значение случайного джиттера 1S и добавляет это к экспоненциальному вычисленному значению 1, чтобы получить время ожидания 2S, прежде чем сделать последующий запрос. Аналогичным образом, клиент 2 вычисляет значение джиттера 2S и добавляет это к экспоненциальному отбору 1S, чтобы ждать 3S, прежде чем сделать следующий запрос на службу сделок.
Как мы можем видеть, добавление джиттера в экспоненциальную отборочную информацию помогает распространить разрыв запросов, что приводит к ситуации, когда все запросы добиваются успеха в следующей попытке.
Примечание. Мы удобно выбрали значение джиттера, которое помогает распространять запросы на службу сделок и сохраняет одновременные запросы в соответствии с 2 TPS. Тем не менее, в реальных сценариях несколько новых клиентов могут очень легко отправлять новые запросы, опрокидывая услугу сделок за пределы 2 TPS-точки разрыва и предпринимая наши усилия, чтобы сгладить разрыв бесполезным. Давайте посмотрим на детали ниже.
Когда джиттер и экспоненциальный откат не работают?
В нашем примере службы сделок мы предположили, что общее количество клиентов оставалось постоянным в пять (то есть фиксированное количество клиентов в нашей системе). В отличие от этого, если мы постоянно добавляем нового клиента каждую секунду (помимо этих пяти клиентов), делая новый первый запрос на услугу сделок, наше решение для отключения и дрожания не работает. Это поднимает важный момент об эффективности дрожания и экспоненциального отбора. Если у нас постоянно добавлены новые клиенты в систему, они не знают о том, что другие клиенты отступают в попытке сократить одновременную рабочую нагрузку на нашем сервисе. В результате общая одновременная нагрузка на систему продолжает увеличиваться, даже когда попытки отступления/дрожания распространяют предыдущую нагрузку на обслуживание, откладывая их в будущее.
Заключительные мысли
Отсутствие джиттера является эффективным механизмом для сглаживания короткого всплеска запросов при использовании повторных ресурсов. Тем не менее, их общая эффективность снижается, если мы видим новые запросы клиентов, которые увеличивают одновременную нагрузку на нашу услугу. В тех случаях, когда одновременная нагрузка выходит за рамки переломного момента (например, TPS из 2 в нашем случае службы сделок), отборы и дрожание вообще не помогают. Я надеюсь, что это позволит разработчикам понять, как экспоненциальные отрывы и дрожащие в реальных ситуациях и какие предположения должны существовать для них, чтобы они были полезны в распределенной системе.
Сегодняшний цифровой мир требует устойчивости и исключительной работы. Цифровые предприятия обращаются к платформе IPM Catchpoint IPM, чтобы активно выявлять и решать проблемы в интернет -стеке, прежде чем они повлияют на клиентов или рабочую силу. Интернет опирается на Catchpoint. Узнайте больше последних из The Catchpoint Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Tejas является руководителем организации Integration и Developer Experience в AWS Lambda, где он возглавляет многозакозную организацию из 80 специалистов инженеров, состоящих из главных инженеров и управлений менеджеров. С 14 -летним опытом в Amazon он … Подробнее от Tejas Ghadge
