Я пытаюсь оценить различные протоколы обмена сообщениями pub/sub с точки зрения их способности горизонтально масштабироваться без создания ненужной перекрестной болтовни.
В моей архитектуре будут серверы NodeJS с подключенными клиентами веб-сокетов. Я планирую использовать маршрутизатор на основе последовательного хеширования, чтобы направлять клиентов на серверы в зависимости от тем, на которые они заинтересованы в подписке. Это будет означать, что для данной темы только подмножество серверов будет иметь клиентов, подписавшихся на эту тему. Затем сообщения будут опубликованы в брокере публикации/подписки, который будет отвечать за распространение этих данных на серверах, у которых есть подписчики.
Я хочу избежать ситуации, в которой каждый брокер получает каждый запрос, и сеть становится насыщенной. Это явная проблема с масштабированием Redis Pub/Sub. Добавление серверов не должно создавать проблему n квадратов.
Количество клиентов в протоколе pub/sub равно количеству серверов. В идеале каждый сервер мог бы иметь локального брокера для эффективного распределения данных по нескольким процессам NodeJS, чтобы избежать ненужной пропускной способности сети. В большинстве случаев для данной темы все подписчики будут на одном и том же сервере.
Какие протоколы публикации/подписки предлагают такое распространение данных на основе тем?
Я оцениваю следующие протоколы: MQTT, RabbitMQ, ZMQ, nanomsg. Это не является инклюзивным, и варианты SAAS приемлемы.
Ограничения по обеспечению качества просты. Максимум один раз или хотя бы один раз оба являются подходящими. Признание не важно. Порядок событий не важен. Мы ищем «выстрелил и забыл», уделяя особое внимание горизонтальной масштабируемости.