Кратко и по делу — сравнение трех паттернов по семантике, областям применения, проблемам с памятью и backpressure, и пример перехода.
1) Observer (наблюдатель)
- Семантика: объект (subject) хранит список наблюдателей (observers) и уведомляет их синхронно/асинхронно при изменении состояния. Обычно push-модель: subject вызывает `update(data)` у каждого observer.
- Типичные области: GUI (события интерфейса), в приложении in-process событийная логика, простые publish-to-multiple listeners.
- Проблемы с памятью: утечки из‑за незакрытых подписок — если observer регистрируется и не отписывается, subject держит сильную ссылку; часто требуется явный `unsubscribe` или слабые ссылки.
- Backpressure: отсутствует — producer пушит события без контроля скорости; при медленных потребителях данные накапливаются в коллекциях или обрабатываются медленнее, что ведёт к росту памяти/очередей.
2) Publish/Subscribe (Pub/Sub)
- Семантика: издатели публикуют сообщения в брокер или транспорт по теме/топику; подписчики получают сообщения от брокера. Декуплирование по времени и пространству (часто межпроцессно/распределённо). Может быть at-most-once, at-least-once, exactly-once в зависимости от реализации.
- Типичные области: межсервисная коммуникация, распределённые системы, логирование, очереди задач (Kafka, RabbitMQ, Redis Pub/Sub).
- Проблемы с памятью: брокер/буферы могут накапливать сообщения (в памяти или на диске); retention и размер очереди должны быть настроены. Неправильные политики хранения → рост диска/памяти.
- Backpressure: зависит от реализации. Традиционные брокеры могут позволять producer писать быстрее, чем consumers читают; решение — throttling на producer, отбрасывание, прокрутка/retention, или создание обратной нагрузки вручную. Часто нет встроенного end‑to‑end backpressure между publisher и subscriber.
3) Reactive Streams (реактивные стримы)
- Семантика: асинхронные потоки элементов с явным контролем скорости (pull/push гибрид). Контракт включает `onSubscribe`, `request(n)`, `onNext`, `onError`, `onComplete`. Подписчик запрашивает количество элементов, которые он готов принять → встроенный backpressure.
- Типичные области: потоковая обработка данных in‑process и между компонентами, реактивные API, обработка больших потоков данных с контрольным потоком (Reactor, RxJava (частично), Akka Streams, Java Flow/Reactive Streams).
- Проблемы с памятью: меньший риск переполнения, но возможны утечки при неверном управлении подписками; буферы делают bounded/контролируемыми. Хорошо сочетается с операторами, обеспечивающими ограниченную память (map/filter/flatMap с контролем concurrency).
- Backpressure: встроен — стабильность производителя/потребителя гарантируется при условии соблюдения контракта. При несоблюдении может возникать `MissingBackpressureException` (в некоторых реализациях) или блокировки.
Короткое математическое описание backpressure/стабильности
- Пусть скорость генерации = $\lambda$ (элементов/с), скорость потребления = $\mu$.
- Если $\lambda >\mu$, то backlog растёт: $B(t)=B(0)+(\lambda -\mu )t$ — неустойчиво.
- Для устойчивой системы требуется $\lambda \le \mu$ либо механизм ограничений/потерю/толерантность к задержке.
Когда переход оправдан — примеры
1. Observer → Pub/Sub
- Когда из локального in‑process GUI/event listener требуется масштабирование на несколько сервисов или нужно временное хранение/ретеншн сообщений. Пример: события от пользователей раньше обрабатывались локально, теперь нужно доставлять их в аналитическую пайплайн и несколько микросервисов ⇒ переход к брокеру (Kafka) для доставки и ретенции.
2. Pub/Sub → Reactive Streams
- Когда система столкнулась с проблемой переполнения из‑за быстрого производства сообщений и нужно гарантировать, что downstream может контролировать поток. Пример: потребитель потоковой аналитики не успевает обрабатывать события из брокера в реальном времени; выгодно перейти на реактивный конвейер (Reactive Streams / Akka Streams) между компонентами, чтобы применить backpressure и ограничить одновременную обработку, сохраняя асинхронность.
3. Observer → Reactive Streams
- Когда in‑process подписки становятся асинхронными и требуется управление скоростью/параллелизмом (например, обработка событий с внешними I/O). Пример: GUI-обработчик начинает выполнять сетевые запросы на каждое событие и приводит к перегрузке сети/памяти — переход на Reactive Streams позволяет запрашивать и обрабатывать небольшой пул событий одновременно.
Практическое правило выбора
- Нужна простота и в пределах одного процесса — Observer (с явной отпиской).
- Нужна асинхронная, временно/пространственно декуплированная доставка между компонентами/сервисами — Pub/Sub (брокер).
- Нужна потоковая обработка с гарантией контроля скорости и малым использованием памяти — Reactive Streams.
Заключение (одно предложение)
- Если проблема — утечки подписок → улучшите управление жизненным циклом (Observer/PubSub); если проблема — накопление данных из‑за различия скоростей — переходите к механизмам с backpressure (Reactive Streams) или вводите throttling/ретеншн в брокер.