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

Question

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

Я прочитал 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); 

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

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

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

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

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

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