Введение

Модель обмена сообщениями, в которой отправители и получатели не взаимодействуют напрямую.

В архитектуре программного обеспечения, publish-subscribe (издатель-подписчик) – это модель обмена сообщениями, в которой издатели категоризируют сообщения по классам, на которые подписываются подписчики. Это отличается от типичной модели обмена сообщениями, где издатели отправляют сообщения непосредственно подписчикам. Аналогично, подписчики выражают заинтересованность в одном или нескольких классах и получают только те сообщения, которые им интересны, не зная, какие издатели существуют, если существуют вообще. Publish-subscribe является близкой парадигме очереди сообщений и обычно является частью более крупной системы промежуточного программного обеспечения, ориентированной на сообщения. Большинство систем обмена сообщениями поддерживают как модели pub/sub, так и очереди сообщений в своем API, например, Java Message Service (JMS). Эта модель обеспечивает большую масштабируемость сети и более динамичную сетевую топологию, но при этом снижает гибкость изменения издателя и структуры публикуемых данных.

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

В модели "издатель-подписчик" подписчики обычно получают лишь часть всех опубликованных сообщений. Процесс отбора сообщений для получения и обработки называется фильтрацией. Существуют две распространенные формы фильтрации: фильтрация по теме и фильтрация по содержанию. В системе, основанной на темах, сообщения публикуются в "темы" или именованные логические каналы. Подписчики в системе, основанной на темах, получают все сообщения, опубликованные в темы, на которые они подписаны. Издатель отвечает за определение тем, на которые могут подписываться подписчики. В системе, основанной на содержании, сообщения доставляются подписчику только в том случае, если атрибуты или содержание этих сообщений соответствуют ограничениям, заданным подписчиком. Подписчик отвечает за классификацию сообщений. Некоторые системы поддерживают гибридный подход: издатели публикуют сообщения по теме, а подписчики регистрируют подписки на основе содержания для одной или нескольких тем.

Топологии

Во многих системах publish-subscribe издатели публикуют сообщения в промежуточный брокер сообщений или шину событий, а подписчики регистрируют подписки у этого брокера, позволяя брокеру выполнять фильтрацию. Брокер обычно выполняет функцию сохранения и пересылки сообщений от издателей к подписчикам. Кроме того, брокер может расставлять приоритеты сообщений в очереди перед маршрутизацией. Подписчики могут регистрироваться для получения конкретных сообщений на этапе сборки, инициализации или во время выполнения. В системах графического интерфейса подписчики могут быть запрограммированы на обработку пользовательских команд (например, нажатия кнопки), что соответствует регистрации на этапе сборки. Некоторые фреймворки и программные продукты используют XML-файлы конфигурации для регистрации подписчиков. Эти файлы конфигурации считываются на этапе инициализации. Наиболее продвинутый подход – когда подписчиков можно добавлять или удалять во время выполнения. Этот подход используется, например, в триггерах баз данных, списках рассылки и RSS. Промежуточное ПО Data Distribution Service (DDS) не использует брокер. Вместо этого каждый издатель и подписчик в системе pub/sub обменивается метаданными друг о друге посредством IP-мультикаста. Издатели и подписчики кэшируют эту информацию локально и маршрутизируют сообщения на основе обнаружения друг друга в общем представлении. Фактически, безброкерные архитектуры требуют от системы publish/subscribe построения наложенной сети, обеспечивающей эффективную децентрализованную маршрутизацию от издателей к подписчикам. Джон Клейнберг показал, что эффективная децентрализованная маршрутизация требует топологий Navigable Small World. Такие топологии Small World обычно реализуются децентрализованными или федеративными системами publish/subscribe. Системы publish/subscribe, учитывающие локальность, строят топологии Small World, которые направляют подписки по коротким расстояниям и недорогим каналам, тем самым сокращая время доставки подписок.

История

Одной из самых ранних публично описанных pub/sub систем была "news" подсистема инструментария Isis, описанная на симпозиуме Ассоциации вычислительных машин (ACM) по принципам операционных систем в 1987 году (SOSP '87), в статье "Exploiting Virtual Synchrony in Distributed Systems. 123–138".

Разрушенная сцепка

Издатели слабо связаны с подписчиками и даже не обязаны знать об их существовании. Поскольку в центре внимания находится тема, издатели и подписчики могут оставаться в неведении относительно топологии системы. Каждый из них может продолжать функционировать в обычном режиме, независимо от другого. В традиционной тесно связанной парадигме «клиент-сервер» клиент не может отправлять сообщения серверу, пока серверный процесс не запущен, а сервер не может получать сообщения, если клиент не работает. Многие системы типа pub/sub разделяют не только местоположение издателей и подписчиков, но и их временную зависимость. Распространенная стратегия, используемая аналитиками промежуточного программного обеспечения в таких системах pub/sub, заключается в отключении издателя, чтобы подписчик мог обработать накопленные сообщения (форма регулирования пропускной способности).

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

Pub/sub предоставляет возможность лучшей масштабируемости по сравнению с традиционной клиент-серверной архитектурой, благодаря параллельной работе, кэшированию сообщений, маршрутизации на основе деревьев или сети и т.д. Однако, в определенных типах тесно связанных, высоконагруженных корпоративных сред, когда системы масштабируются до размеров дата-центров с тысячами серверов, использующих инфраструктуру pub/sub, существующие коммерческие системы часто теряют это преимущество; масштабируемость продуктов pub/sub при высоких нагрузках в таких условиях остается предметом научных исследований. В то же время, за пределами корпоративной среды, парадигма pub/sub продемонстрировала свою масштабируемость до объемов, значительно превышающих возможности одного дата-центра, обеспечивая широкомасштабную распределенную передачу сообщений в интернете через веб-протоколы синдикации, такие как RSS и Atom. Эти протоколы синдикации допускают более высокую задержку и отсутствие гарантий доставки в обмен на возможность даже для маломощного веб-сервера распространять сообщения (потенциально) миллионам отдельных подписчиков.

Недостатки

Наиболее серьезные проблемы систем "публикация-подписка" являются обратной стороной их главного преимущества: разделения издателя и подписчика.