ZeroMQ Pub-Sub + динамическое обнаружение без посредника

Question

Я тестирую ZeroMQ как Pub-Sub (стиль служебной шины) для средней системы. У нас около 50 узлов, все они должны быть издателями и подписчиками. Сеть является своего рода звездной топологией, но ее края "общаются" друг с другом. Нам требуется динамическое обнаружение (не нужно жестко кодировать сетевые адреса участников), но также не требуется SPOF (единая точка отказа).

Я прочитал http://zeromq.org/whitepapers:0mq-3-0-pubsub и, насколько я понимаю, предлагаемый способ динамического обнаружения 0MQ включает в себя прокси-узел (XPUB/XSUB), который пересылает подписки и публикации. Я рассмотрел использование такого прокси-сервера в качестве центрального посредника в нашей системе, однако у меня есть следующие проблемы с этой архитектурой: (A) прокси-узел является SPOF - когда он выходит из строя, вся система не функционирует (B) весь трафик, включая данные, проходит через прокси-узел, что означает проблему с задержкой и производительностью.

Предполагая, что я правильно понял технический документ pub-sub, существует ли относительно простой способ для достижения pub-sub + dynamic-discovery + no-SPOF в ZeroMQ?

Дополнительное замечание: я исключил многоадресное решение (PGM), потому что большинство сообщений имеют одну / несколько заинтересованных сторон, и мы не хотим переполнять сеть.

Answer 1

Несколько подписчиков с одним издателем не требуют посредников, так как подписчики могут напрямую общаться с издателем. Но многим издателям и подписчикам одновременно не все так просто; если что-то не посередине, обслуживание будет кошмаром, поскольку новые подписчики должны быть настроены со всеми существующими издателями.

Вы можете развернуть несколько прокси XSUB/XPUB, каждый на своем компьютере, а затем развернуть балансировщик нагрузки (например, F5) между издателями и прокси. Это обеспечивает балансировку нагрузки и отказоустойчивость на стороне входа.

Код прокси прост:

Socket frontend = context.socket(ZMQ.XSUB);
frontend.bind("tcp://proxy1:5444");
Socket backend = context.socket(ZMQ.XPUB);
backend.bind("tcp://proxy1:5555");
frontend.subscribe("".getBytes());
ZMQ.proxy (frontend, backend, null);

Если прокси-узел не работает, просто перезапустите его; повторные подключения / подписки должны обрабатываться автоматически с помощью zmq.

Для нижестоящих подписчиков подключите каждого подписчика напрямую ко всем доступным прокси:

subscriber = ctx.createSocket(ZMQ.SUB)
subscriber.connect( "tcp://proxy1:5555")
subscriber.connect( "tcp://proxy2:5555")
subscriber.connect( "tcp://proxy3:5555")

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

В случае сбоя прокси-узла вышестоящие LTM маршрутизируют трафик соответственно оставшимся прокси-узлам; подписчики не будут затронуты, так как они используют все доступные прокси.

Медленный абонент может быть адресован с синхронизацией, читайте об этом.
Проверьте переадресацию по подписке и минимизацию сетевого трафика здесь.