ZeroMQ Vertriebsmuster

Question

Ich habe derzeit ein Pub/Sub-System in Betrieb, das es Clients ermöglicht, sich mit einem zentralen Nachrichtenrouting-Dämon zu verbinden, sich für eine Reihe von Nachrichten zu abonnieren und dann loszuplappern. Der Routing-Dämon verfolgt und verwaltet die Nachrichten von Interesse jedes Abonnenten (basierend auf einem einfachen Tag) und liefert die entsprechenden Nachrichten von Interesse aus, sobald die Abonnenten sie produzieren. Jede Verbindung wird im Wesentlichen als potenzieller Publisher ODER Abonnent UND MEISTENS beides betrachtet, der Dämon übernimmt die Routing- und Zustellungsfunktionen nach Bedarf.

Zum Beispiel verbinden sich drei Clients alle und abonnieren ihre Nachrichten-Tag(s) (MT) von Interesse:

Client 1(C1) abonniert MT => 123
Client 2(C2) abonniert MT => 123 & 456
Client 3(C3) abonniert MT => 123 & 456 & 789

C1 produziert MT 456: der Dämon liefert eine Kopie an C2 und C3
C2 produziert MT 123: der Dämon liefert eine Kopie an C1 und C3 (nicht an sich selbst)
C3 produziert MT 999: der Dämon liefert sie an niemanden (niemand hat abonniert)

ZeroMQ wurde in einem Gespräch mit einem Kollegen erwähnt und nachdem ich ein paar Tage damit herumexperimentiert habe, glaube ich nicht, dass ich das richtige Muster für die Implementierung/den Ersatz des derzeitigen Systems sehe. Außerdem würde ich gerne EPGM verwenden, um von den Multicast-Vorteilen zu profitieren und den auf TCP basierenden Dämon, den ich derzeit habe, zu eliminieren.

Irgendwelche Vorschläge?

Answer 1

Es ist möglich, ein System wie dieses mit ZeroMQ zu entwerfen. Grundsätzlich können Sie einen Daemon erstellen, der zwei Sockets bindet: PULL zum Empfangen von Nachrichten von Clients und PUB zum Veröffentlichen von Nachrichten. Jeder der Clients verbindet SUB-Socket und PUSH-Socket mit dem Server. EPGM kann für PUB/SUB-Sockets verwendet werden, aber PUSH/PULL-Sockets sind immer noch TCP.

Der Nachteil dieses Designs besteht darin, dass die Themenfilterung und das Auslassen eigener Nachrichten manuell erfolgen müssen. Zum Beispiel könnten Sie eine Nachricht aus drei Teilen erstellen:

1. Thema
2. ID des Produzenten
3. Nachrichteninhalt

Der Client sollte Nachrichten Teil für Teil lesen und sofort den Nachrichtenschwanz ablegen, an dem er nicht interessiert ist. Das Arbeiten mit PUB/SUB-Nachrichtenumschlägen wird in diesem Abschnitt des Leitfadens ausführlich beschrieben: http://zguide.zeromq.org/page:all#Pub-Sub-Message-Envelopes. Die Client-Filterung sollte die Leistung nicht beeinträchtigen, da alle PGM-Pakete sowieso an alle verbundenen Empfänger geliefert werden müssen.

Dieses Design ist sehr einfach, aber ziemlich effektiv. Es deckt jedoch keine Zuverlässigkeit, hohe Verfügbarkeit, Fehlerwiederherstellung und andere wichtige Aspekte ab - dies ist alles mit ZeroMQ machbar und im Leitfaden behandelt. Wahrscheinlich das beste Merkmal von ZeroMQ ist die Möglichkeit, mit etwas Einfachem zu beginnen und nach Bedarf Funktionalität hinzuzufügen, ohne Schmerzen und/oder große Neuschreibungen.

Etwas sehr Ähnliches (plus Zustandssnapshots, Zuverlässigkeit und vieles mehr) wird im Kapitel "Zuverlässige Pub-Sub (Clone Pattern)" des Leitfadens beschrieben: http://zguide.zeromq.org/page:all#toc119

Übrigens ist es auch möglich, ein P2P-System mit dem zentralen Daemon zu entwerfen, der nur als Namensserver verwendet wird, aber es wird definitiv komplexer sein.