PubSub

PubSub (сокращение от англ. Publish–Subscribe, «издатель‑подписчик») — это шаблон проектирования (архитектурный паттерн) обмена сообщениями, при котором отправители (издатели) не направляют сообщения напрямую конкретным получателям, а публикуют их в общем канале (топике, теме), а получатели (подписчики) выражают интерес к определённым каналам и получают только те сообщения, которые им нужны. Паттерн обеспечивает слабую связанность компонентов системы, позволяя им обмениваться данными без прямого знания друг о друге.

История

Концепция «издатель‑подписчик» восходит к ранним работам в области операционных систем и распределённых вычислений. В 1987 году Кеннет Бирман и Джозеф Джозеф в статье «Exploiting Virtual Synchrony in Distributed Systems» описали модель групповой рассылки, ставшую прообразом PubSub. В 1990‑х годах паттерн получил развитие в системах обмена сообщениями (message‑oriented middleware, MOM), таких как IBM MQSeries и TIBCO Rendezvous. В 2000‑х годах, с ростом популярности облачных вычислений и микросервисной архитектуры, PubSub стал одним из ключевых механизмов для построения масштабируемых, асинхронных и отказоустойчивых систем. Крупные облачные провайдеры (Google, Amazon, Microsoft) внедрили собственные управляемые PubSub‑сервисы, а в экосистеме открытого кода появились такие реализации, как RabbitMQ, Apache Kafka, Redis Pub/Sub и NATS.

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

Основные компоненты

• Издатель (Publisher) — компонент, который генерирует сообщения и отправляет их в брокер сообщений, не зная, кто их получит.
• Подписчик (Subscriber) — компонент, который регистрирует интерес к определённым типам сообщений (топикам) и получает их от брокера.
• Брокер сообщений (Message Broker) — центральный узел, который принимает сообщения от издателей, хранит их (при необходимости), фильтрует по топикам и доставляет подписчикам.
• Топик (Topic) — именованный канал, к которому издатели публикуют сообщения, а подписчики подписываются. Топики могут быть организованы иерархически (например, sensor/temperature/room1).

Процесс обмена

1. Подписчик отправляет брокеру запрос на подписку к одному или нескольким топикам.
2. Издатель отправляет сообщение в брокер с указанием топика.
3. Брокер принимает сообщение, определяет, какие подписчики подписаны на этот топик, и передаёт им копию сообщения.
4. Подписчик обрабатывает полученное сообщение.

Важная особенность: издатель и подписчик взаимодействуют исключительно через брокера, не зная о существовании друг друга. Это обеспечивает слабую связанность и возможность независимого масштабирования компонентов.

Фильтрация сообщений

Существует два основных подхода к фильтрации:

• Фильтрация на основе топиков (Topic‑based) — подписчик указывает конкретный топик (или шаблон топика, например, sensor/temperature/*). Брокер доставляет все сообщения, опубликованные в этот топик.
• Фильтрация на основе содержимого (Content‑based) — подписчик задаёт условие на содержимое сообщения (например, temperature > 30). Брокер анализирует каждое сообщение и доставляет только те, которые удовлетворяют условию. Этот подход более гибкий, но требует больших вычислительных ресурсов.

Виды реализации

Централизованные системы

В централизованной реализации все сообщения проходят через единый брокер. Примеры: RabbitMQ, Google Cloud Pub/Sub, Amazon Simple Notification Service (SNS). Преимущество — простота управления и гарантии доставки. Недостаток — единая точка отказа (single point of failure) и потенциальное узкое место при высокой нагрузке.

Децентрализованные (одноранговые) системы

В децентрализованной реализации брокер может быть распределённым, а издатели и подписчики могут обмениваться сообщениями напрямую через протоколы групповой рассылки (multicast). Примеры: Apache Kafka (с распределёнными кластерами), NATS (с поддержкой кластеризации). Такие системы более отказоустойчивы и масштабируемы, но сложнее в настройке и администрировании.

Характеристики и гарантии

Гарантии доставки

• At‑most‑once (не более одного раза) — сообщение доставляется максимум один раз, возможна потеря.
• At‑least‑once (не менее одного раза) — сообщение доставляется хотя бы один раз, возможны дубликаты.
• Exactly‑once (ровно один раз) — сообщение доставляется ровно один раз, без потерь и дубликатов. Требует сложной логики (например, идемпотентности подписчиков).

Устойчивость к отказам

Для обеспечения высокой доступности брокеры часто используют кластеризацию, репликацию данных и механизмы «лидер‑выборов» (leader election). Например, в Apache Kafka данные реплицируются на несколько брокеров, что позволяет пережить отказ одного из узлов без потери сообщений.

Порядок сообщений

В большинстве PubSub‑систем порядок сообщений гарантируется только в пределах одного топика (или раздела топика). При обработке сообщений из нескольких топиков или от нескольких издателей порядок может нарушаться.

Применение

Микросервисная архитектура

PubSub широко используется для асинхронного взаимодействия между микросервисами. Например, сервис заказов публикует событие «Заказ создан», а сервисы уведомлений, логирования и аналитики подписываются на это событие и обрабатывают его независимо.

Системы реального времени

Паттерн применяется в чатах, онлайн‑играх, системах мониторинга и трейдинга, где требуется мгновенная доставка обновлений множеству клиентов. Например, в чат‑приложении каждое новое сообщение публикуется в топик комнаты, а все участники комнаты, подписанные на этот топик, получают его.

Интернет вещей (IoT)

В IoT‑системах миллионы устройств (датчиков, актуаторов) могут публиковать данные (температура, влажность, показания счётчиков) в общие топики. Подписчиками выступают аналитические платформы, системы управления и пользовательские приложения. PubSub позволяет обрабатывать огромные потоки данных без необходимости устанавливать прямые соединения между каждым устройством и каждым потребителем.

Уведомления и оповещения

Почтовые сервисы, мобильные приложения и веб‑платформы используют PubSub для рассылки push‑уведомлений, email‑сообщений и SMS. Например, сервис подписок на новости может публиковать статьи в топик «tech», а подписчики, выбравшие этот топик, получают уведомления.

Обработка событий (Event‑Driven Architecture)

PubSub является основой для построения event‑driven систем, где бизнес‑процессы запускаются в ответ на события. Например, в банковской системе событие «Перевод выполнен» может инициировать цепочку действий: обновление баланса, отправка уведомления, запись в аудит‑лог.

Примеры реализаций

Apache Kafka

Распределённая платформа потоковой обработки данных, часто используемая как высокопроизводительная PubSub‑система. Kafka хранит сообщения на диске, поддерживает репликацию и позволяет обрабатывать потоки событий в реальном времени. Широко применяется в крупных интернет‑компаниях (LinkedIn, Uber, Netflix) для сбора логов, аналитики и построения event‑driven архитектур.

RabbitMQ

Популярный брокер сообщений, поддерживающий протокол AMQP (Advanced Message Queuing Protocol). RabbitMQ реализует как модель очередей (point‑to‑point), так и PubSub (через обменники (exchanges) и привязки (bindings)). Отличается простотой настройки и богатыми возможностями маршрутизации.

Google Cloud Pub/Sub

Управляемый облачный сервис от Google, обеспечивающий асинхронную передачу сообщений между независимыми приложениями. Поддерживает автоматическое масштабирование, гарантии at‑least‑once и интеграцию с другими сервисами Google Cloud (Dataflow, BigQuery).

Redis Pub/Sub

Встроенная функция в Redis (система управления базами данных типа «ключ‑значение»). Redis Pub/Sub работает в оперативной памяти, обеспечивая минимальную задержку, но не гарантирует сохранность сообщений при сбоях (сообщения не сохраняются на диск). Подходит для сценариев, где потеря сообщений допустима (например, чаты, уведомления).

NATS

Высокопроизводительная система обмена сообщениями с открытым исходным кодом, ориентированная на низкую задержку и простоту. NATS поддерживает PubSub, очереди и запрос‑ответ. Используется в микросервисных архитектурах и IoT.

Критика и ограничения

• Сложность управления — при росте числа топиков и подписчиков администрирование системы может стать трудоёмким. Требуется тщательное проектирование структуры топиков.
• Задержки — прохождение сообщения через брокер вносит дополнительную задержку по сравнению с прямым вызовом (например, RPC). Для критичных по времени приложений это может быть неприемлемо.
• Потеря сообщений — не все реализации гарантируют доставку «ровно один раз». При сбоях брокера или подписчика сообщения могут быть потеряны или продублированы.
• Сложность отладки — из‑за слабой связанности компонентов трассировка потока сообщений и поиск ошибок могут быть затруднены. Требуется внедрение распределённого трассирования (например, OpenTelemetry).
• Управление версиями — изменение формата сообщения может привести к несовместимости с подписчиками, использующими старую версию. Необходимо продумывать механизмы версионирования схем данных (например, Avro, Protobuf).

Сравнение с другими паттернами

PubSub vs. Очереди сообщений (Message Queues)

В модели очередей (point‑to‑point) каждое сообщение обрабатывается ровно одним потребителем. В PubSub одно сообщение может быть доставлено множеству подписчиков. Очереди лучше подходят для распределения задач между рабочими процессами, PubSub — для уведомлений и широковещательной рассылки.

PubSub vs. Каналы событий (Event Channels)

Каналы событий — более общее понятие, включающее и очереди, и PubSub. PubSub является частным случаем канала событий, где каждый подписчик получает копию каждого сообщения, опубликованного в топик.

PubSub vs. Шина данных (Data Bus)

Шина данных (например, Apache Kafka) сочетает свойства PubSub и потоковой обработки: сообщения хранятся в журнале (log) и могут быть повторно прочитаны подписчиками. Это позволяет реализовать сложную аналитику и воспроизведение событий.

Источники

• Birman, K., Joseph, T. «Exploiting Virtual Synchrony in Distributed Systems». 1987.
• Eugster, P. Th., et al. «The Many Faces of Publish/Subscribe». ACM Computing Surveys, 2003.
• «RabbitMQ Documentation». Pivotal Software.
• «Apache Kafka Documentation». Apache Software Foundation.
• «Google Cloud Pub/Sub Documentation». Google LLC.
• «Redis Pub/Sub Documentation». Redis Ltd.
• «NATS Documentation». NATS.io.