Queues, Pub/Sub & Streams
Queues verteilen Arbeit, Pub/Sub verteilt eine Nachricht an mehrere Abonnenten und Streams halten eine geordnete Folge wiederlesbar. Zustellungs- und Aufbewahrungsregeln prägen die Verarbeitung.
- QueueVerteilt Arbeit an einen Worker.
- Pub/SubJeder Abonnent erhält die Nachricht.
- StreamGeordnete Folge wiederlesbar.
Einordnung
Warum das wichtig ist
Nicht jede Nachricht braucht dieselbe Verteilung. Wer die Form falsch wählt, verliert Arbeit, erreicht zu wenige Empfänger oder kann nicht erneut lesen. Fachliche Ereignisse behandelt Event-driven Architecture.
Dieser Baustein vergleicht Nachrichtentransporte. Für fachliche Ereignisse und Reaktionen siehe Event-driven Architecture.
Auf einen Blick · Ein Topic, viele Abonnenten
Wer bekommt die Nachricht?
Der Shop verarbeitet Rechnungsaufträge, verteilt BestellungBezahlt an Versand und Analyse und bewahrt Bestellstatusänderungen für spätere Auswertung auf.
So liest du das Bild
- Queue Bei Queue ist nur Rechnung grün: ein Worker holt den Auftrag „Rechnung erstellen“.
- Pub/Sub Bei Pub/Sub sind Versand und Analyse grün und erhalten BestellungBezahlt je einmal.
- Stream Bei Stream lesen Versand und Analyse die Statusänderungen ab ihrer eigenen Position.
- sendetBestellungstellt Auftrag „Rechnung erstellen“ ein
- empfängtRechnungein Worker holt den Auftrag
- unbeteiligtVersanderhält nichts
- unbeteiligtAnalyseerhält nichts
ein Worker pro AuftragEmpfänger
Die Queue verteilt Arbeit. Genau ein Worker bearbeitet jeden Rechnungsauftrag, Wiederlesen ist nicht der Zweck.
Nutzen & Grenzen
Hilft, wenn
- Queue, Pub/Sub und Stream ordnen Nachrichten passend zu Empfängerkreis und gewünschter Aufbewahrung.
- Eigener Empfängerfortschritt oder unterschiedliche Historien lassen sich mit der passenden Nachrichtenform wiederaufnehmen.
- Ein dauerhaft lesbarer Stream stellt älteren Ereignisstand für neu hinzukommende Konsumenten bereit.
Grenzen
- Das Verteilungsmodell bestimmt Empfängerkreis und Wiederlesbarkeit; jeder Konsument muss prüfen, was ihm zugesagt ist.
- Transportbestätigung und fachliche Verarbeitung sind getrennte Status; Zustellgarantien regeln nur den Transport.
- Verzögerung und Rückstau bleiben Folgen der zeitlichen Entkopplung; siehe Asynchrone Kommunikation.
In der Praxis
- Wähle Queue, Pub/Sub oder Stream anhand Empfängerkreis, Aufbewahrung und Wiederlesebedarf. Halte fest, wer Nachricht und Fortschritt jeweils besitzt.
- Ein gemeinsamer Transport gibt unterschiedlichen fachlichen Verarbeitungen jeweils einen eigenen Status. Speichere Fortschritt pro Konsument und verknüpfe ihn mit der Zustellkennung.
- Prüfe Aufbewahrung und Aufholverhalten unter Rückstand. Asynchrone Kommunikation ordnet zeitliche Entkopplung; Zustellgarantien präzisiert Wiederholung.
Ausführliche Erklärung lesen
Queue, Pub/Sub und Stream verteilen Nachrichten mit unterschiedlichen Regeln für Empfänger, Aufbewahrung und Wiederlesen. Eine Queue verteilt Arbeit aus einem Vorrat; Pub/Sub stellt unabhängigen Abonnements eigene Zustellungen bereit; ein Stream hält geordnete Einträge für späteres Lesen vor.
Die Wahl bestimmt, wer Fortschritt speichert, wie lange Daten verfügbar bleiben und ob neue Konsumenten die Historie lesen können. Zustellgarantie und fachliche Wirkung bleiben gesonderte Zusagen.
Asynchrone Kommunikation erklärt die zeitliche Entkopplung; Zustellgarantien präzisieren Verlust, Wiederholung und Bestätigung für den gewählten Transport.
Kafka ist eine verbreitete Streaming-Plattform. Eine Consumer Group teilt die Nachrichten eines Topics unter ihren Mitgliedern auf.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wer erhält BestellungBezahlt bei Pub/Sub?
Lösung mit Begründung ansehen
Versand und Analyse, jeweils einmal.
AnwendenAuf eine neue Lage übertragen
Der Shop will Bestellstatusänderungen später nochmals auswerten. Welche Form wählst du?
Lösung mit Begründung ansehen
Den Stream. Er hält die Folge für eine festgelegte Dauer, und Leser haben eigene Positionen.
BewertenEine Alternative abwägen
Soll BestellungBezahlt über eine Queue statt Pub/Sub laufen? Wie wägst du ab?
Lösung mit Begründung ansehen
Eine Queue verteilt Arbeit auf Worker, jede Nachricht geht an einen. Versand und Analyse sollen das Ereignis aber unabhängig je einmal erhalten, das leistet Pub/Sub.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Priority Queue und Competing Consumers
Eine Priority Queue kann dringende Arbeit vor normaler Arbeit einordnen; Competing Consumers teilen die bereitstehenden Nachrichten auf mehrere Worker auf. Priorisierung kann dringende Arbeit früher bedienen, normale Nachrichten bei dauerhaft hoher Priorität aber lange verdrängen. Faire Bedienung lässt sich etwa durch getrennte Warteschlangen, reservierte Kapazität oder begrenzte Prioritätsserien gestalten. Worker können Nachrichten erneut erhalten, daher bleibt die Verarbeitung auf Duplikate auszulegen.
Zum AusprobierenPriorität und Fairness prüfen. Teile Shopaufträge in dringend und normal, simuliere mehrere konkurrierende Worker und anhaltenden Andrang dringender Nachrichten. Lege eine faire Bedienregel fest und prüfe, dass Wiederholungen derselben Nachricht keine doppelte fachliche Wirkung erzeugen.
Weiterführende Bausteine
Quellen
- Microsoft · Publisher-Subscriber (öffnet in neuem Tab)Erklärt entkoppelte Ereignisverteilung und Zustellbedingungen.
- RabbitMQ · Queues (öffnet in neuem Tab)Erklärt Queueeigenschaften, Konsumenten und Nachrichtenlebenszyklus.
- Apache Kafka · Design (öffnet in neuem Tab)Beschreibt persistente Logs, Consumer und Zustellsemantik.
- Microsoft · Priority Queue (öffnet in neuem Tab)Nachrichten nach Priorität verarbeiten und die Bedienung niedriger Prioritäten berücksichtigen.
- Microsoft · Competing Consumers (öffnet in neuem Tab)Arbeit auf mehrere Empfänger verteilen; Reihenfolge und Wiederholungen berücksichtigen.