Publish-Subscribe
Pub/Sub fächert ein Ereignis in unabhängige Zustellungen auf.
- PublisherVeröffentlicht eine fachliche Tatsache ohne Empfängerliste.
- AbonnementErzeugt eine eigene Zustellung und Filterregel.
- KompatibilitätErlaubt unabhängig deployten Konsumenten Schemaänderungen.
Einordnung
Warum das wichtig ist
Entkopplung gelingt nur, wenn jeder Abonnent Lag, Fehler und Kompatibilität selbst trägt.
Die verteilten Abonnenten sind hypothetisch; der aktuelle Shop hat sieben Module in einem Prozess.
Messagingformen vergleichen
Im aktuellen Shop laufen sieben Module gemeinsam. Hypothetisch veröffentlicht Bestellung nach bestätigter Zahlung das Ereignis BestellungBezahlt. Versand, Kundeninformation und Analyse erhalten über getrennte Abonnements jeweils eine Zustellung und halten eigene Position sowie Fehler fest. Das Team lässt Analyse ausfallen, veröffentlicht weitere Ereignisse und belegt, dass Versand fortschreitet, Analyse ihren Rückstand nachholt und doppelte Zustellung keine doppelte Fachwirkung erzeugt.
So liest du das Bild
- Publisher Ereignis statt Befehl
- Abonnement Lag je Empfängergruppe
- Kompatibilität Additive Evolution bevorzugen
| Vergleich | Form | Verteilung | Historie |
|---|---|---|---|
| Queue | Ein Auftrag an einen Konsumenten | Konkurrierende Worker | Bis Ack oder Ablauf |
| Pub/Sub | Eine Zustellung je Abonnement | Unabhängige Empfängergruppen | Nach Brokervertrag |
| Event Stream | Leserposition je Gruppe | Wiederlesen möglich | Definierte Aufbewahrung |
Nutzen & Grenzen
Hilft, wenn
- Mehrere unabhängige Reaktionen folgen demselben Ereignis.
- Publisher sollen neue Empfänger ohne Änderung aufnehmen können.
- Zeitversetzte Verarbeitung ist fachlich zulässig.
Grenzen
- Neue Abonnenten sehen ohne gespeicherte Historie keine früheren Ereignisse.
- Globale Reihenfolge über Abonnenten ist meist nicht zugesagt.
- Ein Ereignis ersetzt keine atomare Transaktion über Publisher und Empfänger.
In der Praxis
- Veröffentliche BestellungBezahlt und verfolge Empfangsstatus für Versand, Analyse und Kundeninformation getrennt. Prüfe, dass kein Abonnent die Arbeit der anderen übernimmt.
- Stoppe nur den Analyse-Abonnenten und beobachte dessen Rückstand. Bestätige, dass Versand weiterarbeitet und Analyse später ihren eigenen Status aufholt.
- Vergleiche Pub/Sub mit Queue-Verteilung, wenn alle Abonnenten dieselbe Nachricht erhalten sollen. Bewerte Empfängerkopplung, Aufbewahrung und Wiederholung.
Ausführliche Erklärung lesen
Der Publisher beschreibt ein geschehenes Ereignis und adressiert keinen konkreten Empfänger. Der Broker wertet Abonnements und Filter aus und legt für jede passende Konsumentengruppe eine unabhängige Zustellung an.
Ein langsamer Abonnent darf andere nicht blockieren, erzeugt aber eigenen Rückstau. Schemaänderungen müssen mit unabhängig deployten Empfängern kompatibel bleiben; Wiederholung verlangt Idempotenz je Abonnement.
Queue verteilt einen Arbeitsauftrag an einen Konsumenten. Event Stream hält eine wiederlesbare Ereignisfolge mit Position und Aufbewahrung.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele Zustellungen erzeugt ein passendes Ereignis?
Lösung mit Begründung ansehen
Eine je passendem Abonnement oder Konsumentengruppe.
AnwendenAuf eine neue Lage übertragen
Warum blockiert der Analyseausfall Versand nicht?
Lösung mit Begründung ansehen
Beide besitzen getrennte Abonnements und Rückstände.
BewertenEine Alternative abwägen
Wann braucht es eher einen Event Stream?
Lösung mit Begründung ansehen
Wenn spätere Leser historische Ereignisse ab eigener Position wiederlesen müssen.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.