Pub/Sub

Pub/Sub (сокращение от англ. Publish–Subscribe, «издатель-подписчик») — это шаблон проектирования архитектуры приложений, а также модель обмена сообщениями, в которой отправители (издатели) не отправляют сообщения напрямую конкретным получателям (подписчикам). Вместо этого сообщения классифицируются по темам (топикам), а подписчики выражают заинтересованность в получении сообщений по определённым темам. Система Pub/Sub обеспечивает слабую связанность компонентов, асинхронность и масштабируемость.

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

Основой модели Pub/Sub является посредник — брокер сообщений. Архитектура включает три ключевых компонента:

• Издатель (Publisher) — источник сообщений. Он не знает, кто и когда получит его сообщение. Издатель отправляет сообщение в брокер, указывая тему (topic).
• Брокер сообщений (Message Broker) — центральный сервер, который принимает сообщения от издателей, хранит их (в зависимости от настроек) и распределяет по подписчикам. Брокер управляет списком тем и подписок.
• Подписчик (Subscriber) — получатель сообщений. Он регистрирует у брокера подписку на одну или несколько тем. Когда в теме появляется новое сообщение, брокер доставляет его всем активным подписчикам, подписанным на эту тему.

Процесс обмена сообщениями выглядит следующим образом:

1. Подписчик отправляет брокеру запрос на подписку на тему «Температура в офисе».
2. Издатель (датчик температуры) отправляет в брокер сообщение «+22°C» с указанием темы «Температура в офисе».
3. Брокер получает сообщение, определяет всех подписчиков на эту тему и пересылает им сообщение «+22°C».
4. Подписчик получает сообщение и обрабатывает его (например, выводит на экран).

Ключевые характеристики

Слабая связанность

Издатели и подписчики не зависят друг от друга. Издатель не хранит список получателей, а подписчик не знает, кто отправил сообщение. Это позволяет изменять, добавлять или удалять компоненты системы без влияния на другие.

Асинхронность

Отправка и получение сообщений разнесены во времени. Издатель может отправить сообщение, даже если подписчик в данный момент неактивен. Брокер может сохранить сообщение до момента, когда подписчик подключится и запросит его.

Масштабируемость

Систему можно легко расширять, добавляя новых издателей и подписчиков. Брокер может быть кластеризован для обработки миллионов сообщений в секунду.

Разновидности моделей доставки

В рамках Pub/Sub существуют различные гарантии доставки сообщений:

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

История

Концепция Pub/Sub возникла в 1980-х годах в рамках исследований в области распределённых систем и операционных систем. Одной из первых реализаций была система **Isis (террористическая организация, запрещена в РФ) Toolkit** (1987), разработанная в Корнеллском университете. Она использовала модель «групповой рассылки» (group multicast), которая является предшественником Pub/Sub.

В 1990-е годы модель получила развитие в коммерческих продуктах, таких как TIBCO Rendezvous (1994) — одной из первых систем обмена сообщениями, ориентированных на финансовые рынки. В 1999 году был опубликован стандарт Java Message Service (JMS), который формализовал модель Pub/Sub для Java-приложений.

Современный этап развития Pub/Sub связан с появлением облачных вычислений и микросервисной архитектуры. Такие системы, как Apache Kafka (2011), Google Cloud Pub/Sub (2015), Redis Pub/Sub и RabbitMQ, стали стандартными инструментами для построения распределённых систем.

Применение

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

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

Событийно-ориентированная архитектура (Event-Driven Architecture, EDA)

В EDA Pub/Sub является основным механизмом взаимодействия. Системы обрабатывают потоки событий в реальном времени, что позволяет строить реактивные и отказоустойчивые приложения.

Финансовые системы

Биржевые котировки, новости, транзакции — всё это требует мгновенной доставки большому числу подписчиков. Pub/Sub обеспечивает низкую задержку и высокую пропускную способность.

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

Устройства (датчики, сенсоры) публикуют данные, а приложения-аналитики подписываются на них. Pub/Sub позволяет обрабатывать миллионы подключений от устройств с ограниченными ресурсами.

Уведомления и чаты

Системы push-уведомлений, мессенджеры и чаты используют Pub/Sub для доставки сообщений конкретным пользователям или группам.

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

Apache Kafka

Распределённая платформа для потоковой передачи данных. Kafka хранит все сообщения на диске, обеспечивает высокую пропускную способность и долговременное хранение данных. Поддерживает модель Pub/Sub через топики и группы потребителей. Широко используется в корпоративных системах.

RabbitMQ

Брокер сообщений, поддерживающий несколько протоколов, включая AMQP. Поддерживает модель Pub/Sub через обменники (exchanges) и очереди. Обеспечивает гибкие маршрутизацию и гарантии доставки.

Google Cloud Pub/Sub

Облачный сервис от Google, предоставляющий масштабируемую и отказоустойчивую систему Pub/Sub. Интегрирован с другими сервисами Google Cloud (Cloud Functions, Dataflow, BigQuery).

Redis Pub/Sub

Встроенная функция in-memory базы данных Redis. Обеспечивает сверхнизкую задержку, но не гарантирует сохранность сообщений (если подписчик отключён, сообщение теряется). Подходит для простых сценариев, где потеря данных допустима.

MQTT (Message Queue Telemetry Transport)

Лёгкий протокол Pub/Sub, оптимизированный для IoT и сетей с низкой пропускной способностью. Использует брокер (например, Mosquitto, EMQX) и поддерживает три уровня качества обслуживания (QoS).

Сравнение с очередями сообщений

Хотя Pub/Sub и очереди сообщений (message queues) часто используются вместе, между ними есть принципиальные различия:

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

• Сложность отладки — асинхронная природа и слабая связанность затрудняют трассировку потока данных и выявление проблем.
• Гарантии доставки — обеспечение exactly-once в распределённой системе является сложной задачей и часто требует дополнительных механизмов (идентификаторы сообщений, транзакции).
• Управление темами — при большом количестве тем и подписок управление ими может стать сложным и требовать специальных инструментов.
• Задержка — в отличие от прямого вызова (RPC), Pub/Sub вносит дополнительную задержку из-за прохождения через брокер и сериализации/десериализации сообщений.
• Зависимость от брокера — брокер является единой точкой отказа (SPOF) в простых конфигурациях. Для обеспечения отказоустойчивости требуется кластеризация и репликация.

Источники

1. Eugster, P. T., Felber, P. A., Guerraoui, R., & Kermarrec, A. M. (2003). The many faces of publish/subscribe. ACM Computing Surveys, 35(2), 114–131.
2. Birman, K. P., & Joseph, T. A. (1987). Exploiting virtual synchrony in distributed systems. ACM SIGOPS Operating Systems Review, 21(5), 123–138.
3. Hapner, M., Burridge, R., Sharma, R., Fialli, J., & Stout, K. (2002). Java Message Service (JMS) Specification. Sun Microsystems.
4. Kreps, J., Narkhede, N., & Rao, J. (2011). Kafka: A Distributed Messaging System for Log Processing. Proceedings of the NetDB.
5. Vinoski, S. (2006). Advanced Message Queuing Protocol. IEEE Internet Computing, 10(6), 87–89.
6. OASIS Standard. (2014). MQTT Version 3.1.1.