Как сервису пережить нагрузку выше его возможностей?
- Что такое load shedding?
- Что такое адаптивное ограничение параллелизма?
- Как не упасть целиком при пиковой нагрузке?
При перегрузке лучше быстро отказать части запросов, чем медленно обслуживать все: иначе очереди растут, все запросы опаздывают, клиенты повторяют, и пропускная способность падает до нуля.
- Отказывать рано и дёшево: на входе, по длине очереди или времени ожидания
- Приоритеты: сначала отбрасывать фоновое и второстепенное, оплату — в последнюю очередь
- Адаптивный лимит параллелизма (как окно TCP): растёт, пока задержка в норме, и падает при росте
А ещё Плюс деградация функциональности: отключить рекомендации, отдать кэш, упростить ответ
Подробно
Почему перегрузка ведёт к коллапсу. Когда запросов больше, чем сервис может обработать, очередь растёт, а с ней и время ответа. Клиенты не дожидаются ответа и уходят по таймауту — но сервер всё равно тратит ресурсы на их запросы. Клиенты повторяют — нагрузка ещё растёт. В итоге сервер на 100% занят работой, результат которой никому не нужен: полезная пропускная способность падает (goodput → 0), хотя CPU загружен полностью.
Load shedding — сознательный отказ:
- ограничение параллелизма — не больше N запросов в работе (семафор), лишние сразу 503/429. N по закону Литтла: пропускная способность × нормальное время ответа;
- по времени в очереди — запрос, простоявший в очереди дольше X (или дольше оставшегося дедлайна клиента), выбрасывается без обработки: его всё равно не дождутся. Вариант — очередь LIFO при перегрузке: свежие запросы успеют, старые и так потеряны;
- CoDel для запросов — если очередь не опустошалась дольше интервала, начинать сбрасывать;
- адаптивный лимит (Netflix concurrency-limits, AIMD/Vegas/Gradient): лимит растёт, пока задержка не растёт, и уменьшается, когда растёт. Не нужно знать пропускную способность заранее — она меняется с выкатками, данными, соседями.
Приоритеты. Не все запросы равны: проверка здоровья, платежи, вход пользователя — важнее фоновой синхронизации, предзагрузки и аналитики. Метка приоритета (заголовок) и отбрасывание с нижних уровней первыми. Отличать новые сессии от продолжающихся: лучше обслужить начатую оформление заказа.
Деградация — вместо отказа дать упрощённый ответ: из кэша (даже устаревший), без персонализации, без второстепенных блоков, меньше результатов поиска. Флаги аварийного отключения тяжёлых функций.
Вокруг: отказ должен быть дешёвым (до разбора тела и походов в базу), клиенты — с повторами с отсрочкой и бюджетом повторов, чтобы отказы не превращались в шторм, автомасштабирование — для устойчивого роста, а не для секундных пиков.
Пример
import asyncio, time
limit = asyncio.Semaphore(64) # ≈ RPS × нормальная задержка
async def handle(request):
if request.deadline - time.monotonic() < 0.05:
return Response(503) # клиент уже не дождётся — не тратим ресурсы
if limit.locked():
return Response(503, headers={"Retry-After": "1"}) # отказ дешёвый и быстрый
async with limit:
return await process(request)Что хотят услышать
- Механизм коллапса: очереди, таймауты, повторы, goodput → 0.
- Ранний дешёвый отказ: лимит параллелизма, время в очереди.
- Приоритизация и деградация.
- Адаптивные лимиты — для senior.
Частые ошибки
- Держать огромные очереди «чтобы не терять запросы».
- Отказывать после того, как работа уже сделана (после похода в базу).
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Обслуживать все запросы медленно — лучше, чем отказывать
- ✓Рано и дёшево отказывать части запросов по приоритету
- ✗Отказывать уже после полной обработки запроса, чтобы не терять работу
- ✗Отбрасывать сначала платежи
Что спросят дальше
Связанные вопросы
- Нагрузка превысила возможности сервиса. Какие приёмы позволяют деградировать управляемо, а не упасть целиком? Middle
- Что такое backpressure и как его реализовать? Middle
- Какие алгоритмы ограничения частоты запросов вы знаете? Middle
- Почему при загрузке сервера 90% время ответа растёт в разы, хотя запас ещё есть? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.