Какие протоколы публикации/подписки имеют распространение данных на основе подписчиков?

Я пытаюсь оценить различные протоколы обмена сообщениями pub/sub с точки зрения их способности горизонтально масштабироваться без создания ненужной перекрестной болтовни.

В моей архитектуре будут серверы NodeJS с подключенными клиентами веб-сокетов. Я планирую использовать маршрутизатор на основе последовательного хеширования, чтобы направлять клиентов на серверы в зависимости от тем, на которые они заинтересованы в подписке. Это будет означать, что для данной темы только подмножество серверов будет иметь клиентов, подписавшихся на эту тему. Затем сообщения будут опубликованы в брокере публикации/подписки, который будет отвечать за распространение этих данных на серверах, у которых есть подписчики.

Я хочу избежать ситуации, в которой каждый брокер получает каждый запрос, и сеть становится насыщенной. Это явная проблема с масштабированием Redis Pub/Sub. Добавление серверов не должно создавать проблему n квадратов.

Количество клиентов в протоколе pub/sub равно количеству серверов. В идеале каждый сервер мог бы иметь локального брокера для эффективного распределения данных по нескольким процессам NodeJS, чтобы избежать ненужной пропускной способности сети. В большинстве случаев для данной темы все подписчики будут на одном и том же сервере.

Какие протоколы публикации/подписки предлагают такое распространение данных на основе тем?

Я оцениваю следующие протоколы: MQTT, RabbitMQ, ZMQ, nanomsg. Это не является инклюзивным, и варианты SAAS приемлемы.

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


person user1363145    schedule 27.09.2015    source источник
comment
Примечание. Для горизонтального масштабирования в вашем случае необходимо, чтобы все узлы знали одну и ту же информацию. Если вы намерены смягчить информацию с помощью очередей или другого RPC, вы ДОЛЖНЫ ввести проблему n-square. Другой способ - либо использовать что-то, что использует решение n-square (например, сетку в памяти), либо решить проблему с помощью распределяемого уровня сохраняемости (например, базы данных ant no-sql).   -  person Henry Aloni    schedule 27.09.2015
comment
Два комментария: 1) Вы действительно просите протоколы, чтобы избежать N^2? Я предполагаю, что вас больше интересуют реализации протокольных брокеров. 2) Есть ли ограничения на схему связи? Если все сабвуферы подписываются на все сообщения, выпущенные всеми пабами, то мне кажется, что это неотъемлемая проблема N ^ 2. Однако, если у каждой подпрограммы есть своя тема, вы можете, например. раздел по теме.   -  person Stefan Vaillant    schedule 28.09.2015
comment
Добавление Lightstreamer в список. Он реализует то, что мы называем парадигмой публикации по запросу, когда каждый сервер уведомляет свой канал данных о том, что он может начать публикацию данных по заданной теме только при наличии хотя бы одного подключенного подписчика.   -  person Alessandro Alinone    schedule 28.09.2015
comment
1) Меня больше всего беспокоит фильтрация на уровне PUB, которая кажется ключевым компонентом, необходимым для предотвращения проблем с архитектурой N^2. 2) Нет. 3) Скажем, например, есть 1000 тем и 10 серверов... может быть, каждый сервер подписывается на 100 тем. Пока они не получают сообщения из других 900 тем, мы в золоте.   -  person user1363145    schedule 29.09.2015


Ответы (1)


Во-первых, позвольте мне устранить риск неправильного понимания

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

Сказав это, позвольте мне рассмотреть терминус техникус PUB/SUB.

Команда Мартина САСТРИКА и Питера ХИНТДЖЕНСА, занимающаяся imatix и 250bpm, за последние десятилетия разработала несколько интеллектуальных фреймворков для обмена сообщениями, поэтому эти ребята много знают о преимуществах архитектуры, ограничениях и компромиссах реализации.

Сказанное помогает мне заявить, что эти отцы, которые ввели основы современного обмена сообщениями, не считают PUB/SUB протоколом.

По крайней мере, в nanomsg и ZeroMQ это скорее умный распределенный ориентированный на масштабируемость шаблон формального общения, то есть поведение< /strong> эмулируется всеми вовлеченными сторонами.

И ZeroMQ, и nanomsg без брокера.

В этом смысле вопрос «какие протоколы» не имеет под собой веских оснований.

Начнем со стороны «распространения данных»

В первоначальных реализациях ZeroMQ у PUB не было другого выбора, кроме как рассылать все сообщения всем SUB-ам, которые находились в состоянии connected. Питер ХИНТДЖЕНС много раз объяснял это решение тем, что фактическая фильтрация на основе подписки выполнялась на стороне SUB (распространялась по схеме 1:all-connected).

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

Точно так же вы можете ознакомиться с комментариями nanomsg от Мартина САСТРИКА, который написал много подробных сообщений об улучшениях производительности, реализованных в его потрясающем проекте nanomsg.

Масштабируемость как приоритет №1

Если Scaleability находится в центре внимания вашего поста и если это серьезный проект, мой вопрос номер один будет заключаться в том, что является количественной метрикой для сравнения возможные кандидаты в соответствии с такой целью проекта, т. е. какова осуществимость, переведенная в функцию полезности для оценки кандидатов для сравнения всех параллельных атрибутов, которые интересуют ваш проект?

person user3666197    schedule 27.09.2015
comment
Цель состоит в том, чтобы обрабатывать миллионы одновременных клиентов веб-сокетов, подключенных к распределенной сети серверов NodeJS, и иметь возможность отправлять сообщения всем пользователям, заинтересованным в данной теме, внутри, между серверами. Мои критерии основаны на прагматизме. Все кандидаты должны иметь фильтрацию подписки на основе PUB, чтобы избежать дилеммы насыщения сети n квадратов при добавлении новых серверов. После этого меня в основном волнуют поддержка NodeJS, простота DevOP (желательно автоматизированное решение, дополнения SAAS/docker/AWS и т. д.) и масштабируемость. - person user1363145; 28.09.2015
comment
Тем более, если вы перейдете к стабильности/масштабируемости/отказоустойчивости производственного уровня, пересмотрите свои основные особенности архитектуры. ZeroMQ / nanomsg не требуют брокера, т. е. на один SPOF меньше для отказоустойчивости + отсутствие сингулярности центрального потока данных. Кроме того, масштабирование производительности (части балансировки нагрузки могут помочь вашей архитектуре избежать неблагоприятных проблем, связанных с масштабированием) почти линейно, поэтому ссылаться на параболическое масштабирование здесь не имеет смысла. Насыщение сети недопустимо, если вы используете фильтрацию на стороне PUB. Умная основная архитектура является ключевым моментом. Или я что-то пропустил? - person user3666197; 28.09.2015
comment
Это довольно точно. Фильтрация на стороне PUB позволяет мне избежать перенасыщения сети, при условии, что все остальное спроектировано хорошо. - person user1363145; 29.09.2015
comment
Из того, что я исследовал, похоже, что nanomsg может быть лучшим кандидатом, поскольку он реализует фильтр на стороне PUB, имеет лучшие возможности для обработки большего количества шаблонов подписки с использованием radix-дерева, среди других преимуществ. - person user1363145; 29.09.2015
comment
Ну, что касается миллионов подписок, мой опыт уступает более важным факторам, которые могут помочь решить этот менее интересный атрибут. Это неблокирующие, с малой задержкой, массивно-параллельные, самодиагностируемые, (N + M) самоотверженные плоскости обмена сообщениями, где эти миллионы просто теряют иллюзию Большой проблемы. Удачи с nanomsg. Вы можете попытаться спроектировать свое решение как независимое от фреймворка и воспользоваться возможностью оснастки 0MQ на случай, если nanomsg-0.6-beta или предыдущие выпуски сделают ваш проект проблемным. Я люблю умные и эффективные инструменты, оба - person user3666197; 29.09.2015