Ретраи и джиттер: почему сервис падает во второй раз в момент восстановления

Что здесь на самом деле спрашивают

Лестница обычно такая:

1. «Что делать, если запрос не прошёл?» — разминка, на которой звучит слово «повторить».
2. «Сколько раз повторять и с какой паузой?» — здесь начинается содержание.
3. «Почему экспоненциальная выдержка, а не фиксированная пауза?» — вопрос про амплификацию нагрузки.
4. «Что такое джиттер и зачем он?» — главный вопрос темы.
5. «Сервис лежал и восстановился — почему он тут же лёг снова?» — вопрос про стадный эффект.
6. «Как ограничить ретраи на уровне системы?» — вопрос про бюджет повторов.

Числа этого урока получены моделью, а не прогоном против настоящей системы. Стадный эффект — свойство расписания повторов, и чтобы его увидеть, нужны тысяча клиентов и воспроизводимая недоступность. Модель даёт и то и другое; цена — все выводы верны ровно настолько, насколько верны допущения, и потому допущения названы поимённо.

База: зачем вообще повторять и почему это опасно

Начнём с простого. Запрос к сервису не прошёл. Причина бывает разной, и одна из них — временная: сервис был в этот момент занят, перегружен или как раз перезапускался. Через секунду тот же самый запрос пройдёт. Поэтому первое, что приходит в голову, — повторить, и мысль эта верная: повтор часто и правда помогает.

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

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

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

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

И вот главный вопрос урока: как повторять так, чтобы повтор помогал, а не добивал? Ответ состоит из двух частей, и части эти отвечают на разные вопросы. Выдержка — то, насколько увеличивается пауза после каждой неудачи, — управляет тем, сколько повторов уйдёт в неотвечающий сервис. Джиттер — случайность в выборе паузы — управляет тем, когда они придут. Одно не заменяет другого.

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

Механизм 1: постоянный интервал — не «просто попроще»

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

CONSTANT INTERVAL
-----------------
  first wave at t=0 (all clients at once)  1000
  peak in one 10 ms step after recovery    0
  when that peak happened, ms              0
  requests sent into the outage (wasted)   20000
  total requests sent                      20000
  clients served                           0
  all clients served by, ms                -1

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

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

Это и есть амплификация: при отказе нагрузка на недоступный сервис не падает, а растёт в двадцать раз — с тысячи первых запросов до двадцати тысяч. Причём растёт ровно тогда, когда ему хуже всего.

Механизм 2: экспоненциальная выдержка — про темп, а не про терпение

Вторая стратегия удваивает паузу после каждой неудачи: 100 мс, 200, 400, 800. Это не изобретение прикладных библиотек — так ведёт себя само ядро, когда повторяет начальный пакет установления соединения:

В этой строке удвоение доказано арифметикой: шесть повторов дают 127 секунд только в одном случае — если паузы равны 1, 2, 4, 8, 16, 32 и 64. При постоянной паузе шесть повторов уложились бы в единицы секунд.

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

В модели это выглядит так:

EXPONENTIAL, NO JITTER
----------------------
  first wave at t=0 (all clients at once)  1000
  peak in one 10 ms step after recovery    1000
  when that peak happened, ms              3100
  requests sent into the outage (wasted)   5000
  total requests sent                      6000
  clients served                           1000
  all clients served by, ms                3100

Впустую ушло 5000 запросов вместо 20 000 — вчетверо меньше. И все клиенты в итоге обслужены.

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

Механизм 3: джиттер — это про расписание, а не про вежливость

Третья стратегия отличается одной строкой: пауза выбирается случайно из диапазона от нуля до экспоненциальной границы.

EXPONENTIAL + FULL JITTER
-------------------------
  first wave at t=0 (all clients at once)  1000
  peak in one 10 ms step after recovery    10
  when that peak happened, ms              2000
  requests sent into the outage (wasted)   5906
  total requests sent                      6906
  clients served                           1000
  all clients served by, ms                13290

Пик упал с тысячи до десяти — в сто раз. Ни один клиент не стал вести себя скромнее: каждый по-прежнему повторяет запрос до успеха. Изменилось только то, что они перестали делать это одновременно.

Отсюда формулировка, которой стоит отвечать: джиттер не уменьшает нагрузку, он её размазывает. Нагрузку создаёт сам повтор — джиттер решает лишь, в какой момент повторы придут. Общее число запросов при этом даже слегка выросло (6906 против 6000), потому что случайные паузы иногда короче регулярных.

И вот цена, которую в разговоре обычно забывают: все обслужены к 13 290 мс вместо 3100. Размазав пик, мы размазали и восстановление. Это настоящий компромисс, а не бесплатное улучшение: джиттер выбирают, когда пик опаснее задержки, — то есть почти всегда для сервиса, который от пика ложится, и не всегда для клиента, которому нужен ответ поскорее.

И сразу граница, без которой это число опасно уносить с собой. 13 290 мс — не «цена джиттера» вообще. Это результат вот этой модели с вот этими допущениями: тысяча клиентов, недоступность ровно две секунды, экспоненциальные границы 100, 200, 400, 800 и зерно случайности 20260905. Смените зерно — получите другое число; смените длительность недоступности или число клиентов — тоже. Воспроизводится здесь направление: восстановление растягивается, и растягивается тем сильнее, чем шире диапазон, из которого выбирается пауза. Правило поэтому пишется от направления, а не от числа: за срезанный пик всегда платят более поздним «обслужены все», и цену эту в своей системе измеряют, а не берут отсюда.

Глубже: чего модель не показывает

Три вещи, о которых стоит сказать самому, — и это тоже часть хорошего ответа.

Ретраи не бесплатны для того, кто их делает. Каждый повтор держит соединение и обработчик у клиента; при массовых повторах клиент упирается в собственные лимиты (предыдущие уроки: дескрипторы, очередь accept) раньше, чем сервис успевает ожить.

Повторять можно не всё. Повтор безопасен для операции, которая идемпотентна: чтение, запись с ключом, отмена по идентификатору. Для «списать деньги» повтор — это второе списание, и здесь нужна не пауза, а ключ идемпотентности.

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

Как отвечать на собеседовании

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

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличают три вещи. Первая — вы разводите два эффекта и не путаете их: объём нагрузки создаёт сам повтор, и уменьшает его выдержка (в модели 5000 запросов вместо 20 000); форму нагрузки задаёт расписание, и её меняет джиттер, ничего не убавляя (6906 запросов против 6000, а пик — 10 вместо 1000). Вторая — вы упоминаете идемпотентность: не всякую операцию можно повторять, и пауза тут не поможет. Третья — вы называете бюджет повторов как системное ограничение, потому что без него каждый слой умножает повторы предыдущего.

И одна аккуратность в числах. Цену джиттера — «все обслужены к 13 290 мс вместо 3100» — называть можно и стоит, но с оговоркой, что это результат конкретной модели с конкретным зерном, а не постоянная величина. Универсально здесь только направление: срезанный пик оплачивается более поздним моментом, когда обслужены все. Тот, кто произносит 13 290 без этой оговорки, выдаёт один прогон за закон.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона модели, а не назначен.

constant = simulate(delay_constant)
plain = simulate(delay_exponential)
jittered = simulate(delay_full_jitter)
print(plain["peak_after"])
print(jittered["peak_after"])
print(constant["served"])

1000
10
0

1000
1000
1000

10
1000
0

1000
10
1000

Проверка знаний