Developer

Rate limiting и backpressure

↑ 7.3 Надёжность и отказоустойчивость · ← Предыдущая

Желательно~3 мин чтенияУровень: senior

Зачем это на собесе

Как защитить систему от перегрузки: ограничить вход и не дать очередям расти бесконечно.

Объяснение

Rate limiting ограничивает скорость входящих (или исходящих) запросов. Backpressure — механизм, когда перегруженный потребитель замедляет производителя.

АлгоритмСуть
Fixed windowN запросов в окне; всплеск на границе окон
Sliding windowплавное окно, точнее
Token bucketтокены пополняются с постоянной скоростью; допускает всплески
Leaky bucketпостоянная скорость обработки, лишнее отбрасывается/ждёт
Concurrency limitмаксимум одновременных запросов

Реализация в .NET — встроенный RateLimiter (см. CORS, rate limiting, сжатие ответов); для кластера — общий счётчик в Redis (INCR с TTL, Lua-скрипт) или лимиты на API Gateway.

Ограничения бывают: по IP, пользователю/ключу, тарифному плану, эндпоинту (логин строже).

Ответ при превышении: 429 Too Many Requests + Retry-After + RateLimit-* заголовки.

Backpressure

МеханизмГде
Bounded-очередь (Channel с BoundedChannelFullMode.Wait)внутри процесса
Prefetch/max.poll.recordsброкеры сообщений
TCP/HTTP2 flow controlсеть
Load shedding (быстрый отказ)при перегрузке
Reactive Streamsстриминг
Autoscalingвертикально/горизонтально по метрикам очереди

Нюансы и подводные камни

  • Неограниченные очереди скрывают перегрузку до OOM и огромной задержки.
  • Лимиты без клиентской стороны (ретраи с backoff) приводят к штормам повторов.
  • Лимит по IP за NAT/прокси бьёт по многим пользователям: используйте идентификатор клиента.
  • Distribution: локальные лимиты умножаются на число реплик.
  • Приоритеты: критичный трафик не должен упираться в общий лимит.

Практика

  1. Реализуйте token bucket в Redis и проверьте под нагрузкой.
  2. Замените unbounded-очередь на bounded Channel и измерьте поведение.
  3. Добавьте Retry-After и клиентский backoff.

Вопросы с ответами

Связанные темы

Вид графа

Обратные ссылки