ZeroMQ Pub-Sub + Dynamische Erkennung ohne Mediator

Question

Ich teste ZeroMQ als Pub-Sub (Service Bus-Stil) infra für ein mittleres System. Wir haben etwa 50 Knoten, alle sollten Publisher und Abonnenten sein. Das Netzwerk ist eine Art Sterntopologie, aber die Kanten "sprechen" miteinander. Wir benötigen eine dynamische Erkennung (keine Notwendigkeit, die Netzwerkadressen der Teilnehmer fest zu codieren), aber auch keinen SPOF (Single Point of Failure).

Ich habe gelesen http://zeromq.org/whitepapers:0mq-3-0-pubsub und von dem, was ich verstehe, beinhaltet die vorgeschlagene 0MQ Weg für die dynamische Erkennung einen Proxy-Knoten (XPUB/XSUB), der Abonnements und Publikationen weiterleitet. Ich überlegte, einen solchen Proxy als zentralen Vermittler in unserem System zu verwenden, jedoch habe ich folgende Bedenken mit dieser Architektur: (A) Der Proxy-Knoten ist ein SPOF - wenn es fehlschlägt, funktioniert das ganze System nicht (B) Der gesamte Datenverkehr, einschließlich Daten, wird über den Proxy-Knoten übertragen, was die Latenz & Leistungsproblem bedeutet.

Angenommen, ich verstehe das Pub-Sub-Whitepaper richtig, gibt es einen relativ einfachen Weg, Pub-Sub + Dynamic-Discovery + No-SPOF in ZeroMQ zu erreichen?

Zusätzlicher Punkt: Ich habe Multicast (PGM) -Lösung ausgeschlossen, weil die meisten Nachrichten eine einzelne/wenige interessierte Parteien haben und wir nicht gerne das Netzwerk überladen.

Answer 1

Mehrere Abonnenten mit einem einzigen Publisher benötigen keinen Vermittler, da die Abonnenten direkt mit dem Publisher kommunizieren können. Aber viele Verleger und Abonnenten zur gleichen Zeit ist nicht so einfach; es sei denn, es ist etwas in der Mitte, Wartung wird ein Albtraum sein, da neue Abonnenten mit allen vorhandenen Publishern konfiguriert werden müssen.

Sie können mehrere XSUB/XPUB-Proxys auf ihrem eigenen Computer bereitstellen und dann einen Load-Balancer (wie F5) zwischen den Herausgebern und den Proxys bereitstellen. Dies erreicht Lastausgleich und Fehlertoleranz auf der Upstream-Seite.

Der Proxy-Code ist einfach:

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); 

Wenn ein Proxy-Knoten ausfällt, nur um es neu zu starten; re-connections/subscriptions sollten automatisch von zmq behandelt werden.

Für nachgeschaltete Teilnehmer, verbinden jeden Teilnehmer direkt an alle verfügbaren Proxies:

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

Publishers werden kommen und gehen häufiger als Proxies, so Teilnehmer direkt zu Proxies Ergebnisse in weniger Konfiguration Wartung, da die Anzahl von Proxies Verbindungs wird größtenteils statisch sein.

Wenn ein Proxy-Knoten ausfällt, leiten die Upstream-LTMs den Datenverkehr entsprechend an die verbleibenden Proxy-Knoten weiter. Die Abonnenten sind nicht betroffen, da sie von allen verfügbaren Proxys konsumieren.

Langsamer Teilnehmer kann mit Synchronisierung angesprochen werden, lesen Sie this.
Auschecken-Forwading und minimieren Netzwerkverkehr here.