Competing Consumers
Competing Consumers verteilen Queueaufträge auf einen Workerpool.
- SperreOrdnet einen Auftrag zeitweise genau einem Worker zu.
- AckErfolgt erst nach dauerhafter Fachwirkung.
- SkalierungNutzt Queuealter, Laufzeit und Ressourcengrenzen.
Einordnung
Warum das wichtig ist
Der Durchsatzgewinn ist nur sicher, wenn erneute Zustellung dieselbe Fachwirkung erkennt.
Die vier Rechnungsworker sind hypothetisch; aktuell laufen sieben Module gemeinsam.
Workerfehler und Brokerreaktion
Der aktuelle Shop erzeugt Rechnungen im modularen Monolithen mit sieben Modulen. Hypothetisch legt Bestellung Rechnungsaufträge in eine Queue, aus der vier Worker konkurrierend lesen. Bestell-ID und Rechnungsversion bilden den Idempotenzschlüssel. Das Team beendet einen Worker nach dem Speichern des PDFs und vor der Brokerbestätigung; nach Sperrablauf übernimmt ein anderer Worker, erkennt die vorhandene Wirkung und bestätigt ohne zweite Rechnung. Queuealter und Laufzeit steuern die Workerzahl.
So liest du das Bild
- Sperre Länger als Laufzeit oder verlängerbar
- Ack Wirkung vor Ack
- Skalierung Alter statt Anzahl
| Vergleich | Fehlerpunkt | Broker | Schutz |
|---|---|---|---|
| Vor Wirkung | Sperre läuft aus | Auftrag erscheint erneut | Sicherer Neustart |
| Nach Wirkung, vor Ack | Auftrag erscheint erneut | Wirkung existiert | Idempotenzschlüssel |
| Nach Ack | Auftrag abgeschlossen | Keine reguläre Wiederholung | Audit verbindet Wirkung |
Nutzen & Grenzen
Hilft, wenn
- Unabhängige Hintergrundaufträge haben variables Volumen.
- Je Auftrag soll genau ein Worker gleichzeitig arbeiten.
- Reihenfolge genügt pro Bestell- oder Kundenschlüssel.
Grenzen
- At-least-once-Zustellung kann denselben Auftrag erneut liefern.
- Zu kurze Sperren erzeugen parallele Doppelarbeit; zu lange verzögern Erholung.
- Globale Reihenfolge und freie Parallelität widersprechen sich.
In der Praxis
- Starte mehrere Rechnungsworker und teile Testaufträge auf. Prüfe, dass jede Nachricht nur einmal gleichzeitig beansprucht wird und die Gesamtrate bei Last wächst.
- Beende einen Worker nach fachlichem Commit, aber vor Bestätigung der Nachricht. Verifiziere erneute Zustellung und genau eine Rechnungswirkung durch Idempotenz.
- Bewerte horizontale Skalierung mit Blick auf geordnete Aufträge desselben Kunden, Poison Messages und Dead-Letter-Behandlung. Lege fest, was pro Schlüssel serialisiert bleibt.
Ausführliche Erklärung lesen
Der Broker sperrt eine Nachricht für einen Worker. Nach erfolgreicher Wirkung bestätigt der Worker; endet die Sperre vorher, darf ein anderer Worker denselben Auftrag erhalten.
Mehr Worker erhöhen Parallelität nur für unabhängige Arbeit. Gemeinsame Ressourcen, Reihenfolge oder ungleich große Aufträge begrenzen den Durchsatz; Queuealter ist deshalb aussagekräftiger als bloße Anzahl.
Queue beschreibt den Arbeitskanal. Idempotenz schützt die Fachwirkung bei erneuter Übergabe nach einem Absturz.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie unterscheidet sich das Muster von Pub/Sub?
Lösung mit Begründung ansehen
Ein Worker verarbeitet den Auftrag; Abonnenten erhalten keine eigenen Kopien.
AnwendenAuf eine neue Lage übertragen
Wie verhindert das Beispiel eine zweite Rechnung?
Lösung mit Begründung ansehen
Bestell-ID und Version erkennen die vorhandene Fachwirkung.
BewertenEine Alternative abwägen
Welche Skalierungsmetrik ist besonders nützlich?
Lösung mit Begründung ansehen
Das Alter der ältesten Nachricht zusammen mit Bearbeitungszeit.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.