Прямой ответ
Backpressure — механизм обратной связи в потоке данных: потребитель сигнализирует производителю «притормози» (я не успеваю обрабатывать — event-driven — «поток превышает обработку» — без backpressure — буфер растёт — OOM/падение — ёмкость); аналогия: водопровод (насос качает быстрее, чем труба пропускает — без клапана — разрыв — backpressure — «клапан, прикрывающий насос» — event-driven); почему нужен: производитель быстрее потребителя (сеть шлёт быстрее, чем приложение обрабатывает — ёмкость — «данных больше, чем могу обработать» — буфер/память растут — OOM — incident — backpressure ограничивает буфер); стратегии backpressure (как потребитель «тормозит» производителя): (1) ограничение буфера + блокировка (буфер заполнен — производитель блокируется/ждёт — TCP flow control (окно — «получатель не готов — отправитель ждёт» — сети — классический backpressure — event-driven); (2) отказ/drop (буфер полон — отклонить новые — «fast fail» — retry — «не успел — отклонил» — производитель получает отказ — притормозит — circuit breaker); (3) деградация (буфер полон — обработать упрощённо/отбросить старые — «graceful degradation» — retry — «лучше часть, чем падение»); (4) pull-модель (потребитель сам тянет данные, когда готов — Celery — «не push, а pull» — естественный backpressure — event-driven); backpressure в разных системах: (1) TCP (окно — получатель сообщает, сколько может принять — сети — встроенный backpressure — event-driven); (2) Reactive Streams (request(n) — потребитель запрашивает n элементов — производитель не шлёт больше — Reactive — спецификация backpressure — event-driven); (3) Kafka (consumer pull-модель — сам тянет, когда готов — Kafka — «consumer не тонет» — естественный backpressure — consumer — но producer может перегрузить брокер — ёмкость); (4) RabbitMQ (memory/disk alarms — брокер «тормозит» publisher при перегрузке — RabbitMQ — «память кончается — publisher заблокирован» — ёмкость); (5) очереди задач (Celery prefetch — worker берёт N задач, не больше — Celery — «prefetch_limit» — backpressure — Celery); backpressure vs buffering: буфер без backpressure (растёт бесконечно — OOM — ёмкость), буфер с backpressure (ограничен — производитель тормозится — event-driven — «ограниченная очередь + backpressure» — retry); когда backpressure критичен: потоковые данные (сеть/сенсоры/логи — логи — скорость переменна — ёмкость), медленный потребитель (БД/внешний API — event-driven — «обработка медленнее потока» — backpressure обязателен — retry), ограниченные ресурсы (память/диск — ёмкость — «буфер съел память» — OOM — incident); антипаттерны: неограниченный буфер («очередь растёт» — OOM — ёмкость), игнорирование backpressure (производитель шлёт, несмотря на «тормоз» — event-driven — «producer игнорирует» — перегрузка — retry), backpressure без мониторинга (тормозится — никто не знает — метрики — «backpressure сработал» — метрика/алерт — алерты).
Практика: backpressure в приложении
Reactive Streams (request-based): consumer вызывает request(n) (Reactive — «готов принять n» — producer шлёт ≤ n — event-driven — «обработал n — запросил ещё» — естественный backpressure — Reactive); Celery prefetch (Celery — worker берёт prefetch_limit задач (по умолчанию 4 — Celery — «взял 4, обработал, взял ещё» — backpressure — «prefetch=1» — строгий backpressure (одна задача за раз — медленнее, но надёжнее — Celery); Kafka consumer (Kafka — pull-модель (consumer сам тянет — consumer — «не готов — не тянет» — естественный backpressure — но max.poll.records ограничивает (не тянуть больше N — consumer); RabbitMQ flow control (RabbitMQ — memory alarm (память > порога — broker блокирует publisher — RabbitMQ — «память кончается — publisher ждёт» — ёмкость — publisher confirms + flow control — RabbitMQ); ограниченная очередь + backpressure (приложение): bounded queue (очередь с максимумом — Celery-аналогия — заполнена — производитель блокируется/отклоняет — retry — «очередь полна — 503» — retry); мониторинг backpressure (метрики — «backpressure активен» — метрика (queue size, rejection rate, consumer lag — consumer — алерт при частом срабатывании — алерты — «backpressure срабатывает часто» — потребитель не успевает — масштабировать — ёмкость).
Практический сценарий: потоковый конвейер логов
Контекст: сервис собирает логи (10k событий/с пик — логи), конвейер: сеть → буфер → обработка → БД (Postgres), боль: обработка (парсинг + запись в БД) — 5k событий/с (медленнее потока — ёмкость — буфер растёт — память кончается — OOM — incident); решение — backpressure на каждом этапе: (1) bounded buffer (буфер 10k событий — заполнен — сеть блокируется (TCP flow control — сети — «буфер полон — производитель ждёт» — event-driven); (2) обработка pull-модель (обработчик тянет из буфера, когда готов — Celery-аналогия — «обработал — взял ещё» — event-driven); (3) БД-запись batch (не 1 INSERT на событие, а batch 100 — Postgres — «batch быстрее» — ёмкость — throughput вырос — обработка успевает); (4) деградация при пике (буфер полон + обработка не успевает — отбросить старые/упростить — «graceful degradation» — retry — «лучше часть логов, чем падение»); (5) мониторинг (метрики — buffer size, processing rate, rejection rate — алерт если buffer > 80% — алерты — «буфер заполняется» — масштабировать обработку — ёмкость); (6) масштабирование (обработка не успевает стабильно — добавить обработчиков (Kafka consumer group — consumer — «больше обработчиков» — ёмкость); результат: OOM исчез (bounded buffer + backpressure — память ограничена — ёмкость), пик переживается (TCP flow control тормозит сеть — сети — деградация — часть логов, но сервис жив — retry), метрики показывают backpressure (метрики — «буфер заполнен» — алерт — масштабирование — ёмкость); вывод: backpressure решили проблему (поток > обработки — не OOM, а торможение — event-driven — ADR — «неограниченный буфер» — антипаттерн — техдолг).
FAQ
Что такое backpressure простыми словами и зачем он нужен? Backpressure — «притормози» от потребителя производителю (event-driven — «я не успеваю» — производитель снижает скорость); зачем: без backpressure — буфер растёт бесконечно (производитель шлёт быстрее, чем потребитель обрабатывает — ёмкость — память/диск кончаются — OOM/падение — incident); аналогия: водопровод (насос качает быстрее, чем труба пропускает — без клапана — разрыв — backpressure — клапан — event-driven); где встречается: TCP (окно — сети), Reactive Streams (request(n) — Reactive), Kafka (pull-модель — consumer), RabbitMQ (flow control — RabbitMQ), Celery (prefetch — Celery); «backpressure — сложно» — нет, это базовый механизм (TCP делает автоматически — сети — приложение — bounded queue + pull — event-driven — ADR — «неограниченный буфер» — главная ошибка — техдолг).
Какие стратегии backpressure бывают и когда какую применять? (1) Блокировка (буфер полон — производитель ждёт — TCP — сети — когда: можно ждать (не критично по времени — event-driven); (2) Отказ/drop (буфер полон — отклонить — retry — когда: лучше отклонить, чем ждать (веб-запрос — retry — «503 — повтор» — retry); (3) Деградация (обработать упрощённо/отбросить старые — retry — когда: лучше часть, чем ничего (логи/метрики — логи — «часть логов» — сценарий выше); (4) Pull-модель (потребитель тянет, когда готов — Celery — когда: естественный backpressure нужен (обработка переменной скорости — event-driven); выбор: зависит от контекста (можно ждать — блокировка, нельзя — отказ/деградация — event-driven — ADR — «одна стратегия для всего» — не работает — техдолг).
Backpressure в Kafka и RabbitMQ — в чём разница?
Kafka: pull-модель (consumer сам тянет — consumer — естественный backpressure — «не готов — не тянет» — Kafka — max.poll.records ограничивает — consumer); RabbitMQ: push-модель + flow control (broker шлёт, но при перегрузке — memory alarm — блокирует publisher — RabbitMQ — «память кончается — publisher ждёт» — ёмкость); разница: Kafka — backpressure на consumer (pull — consumer), RabbitMQ — на publisher (flow control — RabbitMQ — «Kafka consumer тормозит, RabbitMQ publisher тормозит»); «Kafka без backpressure» — миф (pull-модель — естественный backpressure — consumer — но producer может перегрузить брокер — ёмкость — выбор — ADR).
Как мониторить backpressure и что делать при частом срабатывании? Мониторинг (метрики): buffer size (буфер заполнен — backpressure активен — ёмкость), rejection rate (отклонено — retry), consumer lag (Kafka — consumer — «потребитель отстаёт»), processing rate vs incoming rate (ёмкость — «обработка медленнее потока»); алерт (алерты): buffer > 80%, rejection rate растёт, consumer lag растёт — алерты — incident); при частом срабатывании: масштабировать потребителя (больше обработчиков — Kafka consumer group — consumer — ёмкость), оптимизировать обработку (batch/кэш/индексы — Postgres — ёмкость), снизить incoming (rate limit на входе — retry — «входной поток слишком большой»); «backpressure срабатывает — это нормально» — иногда (пик — ёмкость), но часто — потребитель не успевает (масштабировать/оптимизировать — ёмкость — ADR — техдолг).
Источники: Reactive Streams, Kafka docs, RabbitMQ docs — ссылки в шапке.