Таймаут и дедлайн: почему клиент ушёл, а работа продолжается

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

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

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

Числа получены прогоном bench/deadlines/chain.py и bench/deadlines/practice.py на loopback. Выдержки в 400 мс задаёт сам скрипт; содержательны здесь не миллисекунды, а счётчики выполненной и отменённой работы.

База: три разных вопроса про время

Возьмём самую обычную цепочку. Сервис A зовёт сервис B, тот зовёт сервис C, и только тогда ответ идёт обратно. Клиент, постучавшийся в A, готов ждать не больше секунды: дольше он просто уйдёт.

Про время в этой цепочке спрашивают три разные вещи, и в разговоре их постоянно подменяют одну другой:

• таймаут — сколько ждать. Это длительность, и принадлежит она тому, кто ждёт: A сам решает, сколько готов ждать ответа от B.
• дедлайн — до какого момента. Это не длительность, а точка во времени: «ответ нужен не позже такого-то мгновения», и она одна на всю цепочку, сколько бы в ней ни было шагов.
• отмена — просьба прекратить работу. Это уже не про время вовсе, а про сообщение: кто-то должен сказать исполнителю, что результат больше не нужен.

И вот главный вопрос урока: клиент ушёл — что происходит с работой, которую он заказал?

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

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

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

Механизм 1: таймаут — свойство ожидающего

Начнём с того, что такое таймаут на уровне сокета:

Обратите внимание, чего в этом описании нет: ни слова о другой стороне. Таймаут — это решение ожидающего перестать ждать. Никакого сообщения исполнителю при этом не отправляется: он даже не узнает, что его результат больше не нужен.

Проверяем цепочкой из трёх сервисов. Каждый «работает» 400 мс, клиент ждёт 500 мс:

1. THE CLIENT GAVE UP; THE WORK DID NOT
---------------------------------------
  client timeout, ms                             500
  services in the chain                          3
  work each service does, ms                     400
  what the client got                            client timeout
  how long the client waited, ms                 501
  services that did the work anyway              3
  services that refused before starting          0
  services never called at all                   0

Клиент ушёл. Все трое доработали. Ни один не отказался — им никто ничего не сказал.

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

Механизм 2: дедлайн едет вместе с запросом

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

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

2. THE SAME CHAIN WITH A DEADLINE PASSED ALONG
----------------------------------------------
  budget the client announced, ms                500
  what the client got                            deadline
  how long the client waited, ms                 401
  services that did the work anyway              1
  services that refused before starting          1
  services never called at all                   1

Три отличия от первого блока, и все три практические.

Работу сделал один сервис вместо трёх. Первый успел (у него было 500 мс на 400 мс работы), второй увидел остаток в сотню миллисекунд и отказался, не начиная, — а третий вообще не был вызван; в прогоне это отдельные строки: отказавших, не начиная, — один, непозванных — один.

Заметьте, чего здесь не произошло: клиент не получил две трети результата. Он не получил ничего — только отказ. Экономия тут не в частичном ответе, а в том, что двое из трёх не потратили по 400 мс на работу, которую никто не ждал.

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

Ответ пришёл раньше: 401 мс против 501. Отказ по дедлайну наступает в тот момент, когда становится ясно, что не успеть, — а не когда истечёт чужое терпение.

И теперь то, что в этом блоке легко проглядеть: работал не дедлайн, а сотрудничество. Сам по себе дедлайн ничего не останавливает — это величина, а не команда. Второй сервис отказался, не начиная, потому что выполнились два условия сразу: остаток бюджета доехал до него вместе с запросом, и он этот остаток посмотрел перед тем, как браться за работу. Уберите первое — протокол не перевозит бюджет, — и второй сервис отработает свои 400 мс, как в прошлом блоке. Уберите второе — бюджет приехал, но никто на него не смотрит, — и результат будет тот же. Именно поэтому «мы ввели дедлайны» само по себе ничего не значит: значит только то, что бюджет передаётся на каждом переходе и что каждый вызванный обязан его проверять.

Механизм 3: почему таймауты по цепочке не складываются

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

3. WHY PER-HOP TIMEOUTS DO NOT ADD UP TO THE CLIENT'S
-----------------------------------------------------
  timeout each service sets for the next one, ms 1000
  services in the chain                          3
  what the client got                            done
  how long the whole chain took, ms              1203
  longest any single hop waited, ms              under 1000

Ни один таймаут не нарушен. Каждый сервис честно ждал меньше секунды. А клиент ждал 1203 мс — потому что ожидания идут последовательно.

Отсюда и верхняя граница, но её важно не выдать за измеренную: три секунды здесь не замерены, а выведены из устройства цепочки. Каждый шаг ставит следующему таймаут в 1000 мс (это константа скрипта), ожидания не перекрываются, значит суммарное ожидание не превысит 3 × 1000 мс. Замер даёт 1203 мс — то есть цепочка укладывается в границу, а не достигает её.

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

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

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

Последний уровень — про ловушку в настройке. connect(2) описывает отдельную ошибку:

Это таймаут соединения — время на то, чтобы соединение вообще установилось. Он про доступность: сервер не отвечает на рукопожатие, очередь переполнена (прошлый урок), пакеты теряются.

Таймаут ответа — совсем другое: соединение уже есть, запрос отправлен, и мы ждём данные. Он про скорость обработки.

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

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

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

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

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

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

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

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

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

Практика

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

budget = int(CLIENT_TIMEOUT * 1000)
without_deadline, worked_without, _, _ = run(budget_ms=-1)
with_deadline, worked_with, refused, uncalled = run(budget_ms=budget)
print(without_deadline)
print(worked_without)
print(with_deadline)

client timeout
3
deadline

client timeout
0
deadline

client timeout
3
client timeout

deadline
1
deadline

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