Перейти к содержанию

Backpressure и overload protection

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы

Очередь не устраняет недостаток service capacity: она преобразует его в latency, storage pressure и риск retention expiry. Если долговременная входная скорость выше скорости обработки, backlog растёт; autoscaling не поможет при фиксированной пропускной способности sink.

INFERENCE: ограничивайте одновременно in-flight requests, bytes и per-tenant долю. Admission control должен отвергать новую работу до irreversible acceptance либо сохранять её durable. В потоковой цепочке обратное давление лучше переносить к replayable source, чем в неограниченную память consumer.

Flink связывает checkpoints с потоковой обработкой и восстановлением состояния; operator slowdown нужно оценивать вместе с checkpoint progression. Flink 1.20.3. Внешний sink может быть узким местом даже при низком CPU workers.

Иллюстративная архитектура

flowchart LR
 S[Durable source backlog] --> A[Admission and fair scheduling]
 A --> Q[Bounded in-flight queue]
 Q --> W[Workers]
 W --> D[Rate-limited sink]
 D -. backpressure .-> A

Failure scenarios

Sink замедляется, futures копятся до OOM, worker рестартует и повторяет весь незакоммиченный хвост. Масштабирование workers создаёт connection storm. Replay после outage вытесняет live traffic. При остановке poll Kafka consumer теряет assignment, хотя DB threads продолжают работать.

Recovery protocol

  1. Остановить intake сверх durable capacity, ограничить retries и разделить live/rebuild quotas.
  2. Проверить oldest record age против доступного source retention и места на диске.
  3. Снижать batch size/concurrency по sink saturation, не только по worker CPU.
  4. Восстанавливать ограниченный partition set и непрерывный commit prefix.
  5. После catch-up сверить полноту: снижение lag не гарантирует отсутствие пропусков или DLQ debt.

Trade-offs и критерии выбора

Большие batches снижают overhead, но увеличивают memory и replay amplification. Маленькие очереди быстрее показывают overload и требуют явной политики отказа. Fair scheduling защищает tenants ценой возможного снижения общей утилизации.

FinTech и iGaming

Wallet команды должны получать понятный rejected/pending статус, а не исчезать при OOM. Backfill betting history не должен занимать весь ClickHouse capacity и задерживать live exposure. Для antifraud track feature age, а не только queue length.

Практический пример

Составьте учебный overload test: замедлите sink в сценарии H, ограничьте in-flight per partition и убедитесь, что memory перестаёт расти, а источник сохраняет backlog. Реальная Kafka-интеграция без daemon — NOT_RUN.

Типичные ошибки проектирования

Unbounded executor queue; autoscale только CPU; много независимых retry loops; pause processing без обслуживания consumer group protocol; оптимизация lag пропуском ошибок.

Вопросы на собеседовании

Как отличить overload от временного всплеска? По устойчивому росту возраста backlog, sink saturation и скорости drain после ограничения intake.

Почему добавление consumers ухудшает работу? Sink connections/locks и retries могут превысить его capacity.

Дополнительные источники