Software ArchitectureAtlas

Software Architecture Atlas

Überblick gewinnen. Zusammenhänge verstehen.

KonzeptKapitel II · Verteilung · Baustein 3 von 6

Zustellgarantien

Ein Broker kann eine Nachricht erneut zustellen, wenn eine Bestätigung ausbleibt. Eine zuverlässige Verarbeitung verbindet deshalb dauerhafte Wirkung mit wiederholbarer Behandlung.

Von Michael Meierhoff · Meierhoff Systems

  1. At-most-onceBestätigen vor dem Speichern.
  2. At-least-onceBestätigen nach dem Speichern.
  3. Effektiv einmalAt-least-once plus Idempotenz.

Einordnung

Warum das wichtig ist

Der Bestätigungszeitpunkt entscheidet über Verlust oder Duplikat. Exactly-once gibt es nicht als Transportzusage; effektiv einmal entsteht aus at-least-once plus Idempotenz. Outbox, Idempotenz und Retry vertiefen einzelne Mechanismen.

Dieser Baustein erklärt Zustellbestätigungen und Wiederzustellung. Outbox sichert die Veröffentlichung aus einer lokalen Transaktion; Idempotenz schützt die Wirkung vor Duplikaten.

Auf einen Blick · Bestätigung nach dem Speichern

Bleibt die Bestätigung aus, stellt der Broker erneut zu; deshalb muss die Verarbeitung wiederholbar sein.
Shop-Beispiel · Bestätigung durchspielen

Wann wird bestätigt?

Der Shop veröffentlicht eine Bestellung für die Rechnungserstellung. Ein Worker speichert Rechnung und Auftragskennung, bevor er die Brokerzustellung bestätigt.

So liest du das Bild

  1. At-most-once Reihenfolge „vor dem Speichern“ mit Absturz ergibt: Auftrag verloren.
  2. At-least-once Reihenfolge „nach dem Speichern“ mit Absturz ergibt eine Wiederzustellung.
  3. Effektiv einmal Mit gesetzter Kennungsprüfung zeigt das Ergebnis „effektiv einmal“ statt zwei Rechnungen.
  1. Broker stellt B-1042 zu
  2. Worker speichert Rechnung
  3. Absturz
  4. Worker bestätigtentfällt
  5. Broker stellt erneut zu
  6. Worker speichert Rechnung (erneut)
  7. Worker bestätigt

zwei Rechnungen

Die Wiederzustellung von B-1042 trifft einen Worker ohne Kennungsprüfung; er legt eine zweite Rechnung an.

Wähle Bestätigungszeitpunkt, Absturz und Idempotenz; das Ergebnis zeigt, wie viele Rechnungen für B-1042 entstehen.

Nutzen & Grenzen

Hilft, wenn

  • Zustellgarantien helfen beim Entwurf, wenn Transport bei Fehlern Nachrichten verlieren oder wiederholen kann.
  • Getrennte Transportbestätigung und fachliche Änderung benötigen eine Behandlung des Wiederholungsfensters.
  • Eine genau-einmalige Zusage muss ihren unterstützten Transaktionsbereich ausdrücklich benennen.

Grenzen

  • At-most-once kann Aufträge verlieren, at-least-once erzeugt Duplikate; wähle nach der fachlichen Folge für die Rechnung.
  • Broker und Rechnungsablage haben getrennte Transaktionsgrenzen; ohne gemeinsame Kennung bleibt eine Wiederzustellung nicht erkennbar.
  • Idempotenz schützt nur die Wirkung im Worker; Retry begrenzt zusätzlich Wiederholungen und Ressourcenverbrauch.

In der Praxis

  1. Wähle Verlust- und Wiederholungszusage für den Transport und nenne deren Transaktionsgrenze. Die fachliche Wirkung erhält eine davon getrennte Erfolgskontrolle.
  2. Speichere die fachliche Empfängerwirkung dauerhaft und bestätige die Nachricht anschließend. Ein Absturz zwischen Commit und Bestätigung führt zu einer Wiederholung, die der Empfänger sicher zuordnet.
  3. Teste Duplikate und dauerhafte Fehler mit Kennung und Reihenfolge. Idempotenz schützt Wirkungen; Retry steuert Versuche.
Ausführliche Erklärung lesen

Zustellgarantien legen fest, welche Ergebnisse ein Transport ermöglicht: At-most-once vermeidet Wiederholungen und kann Nachrichten verlieren; at-least-once wiederholt bis zur Bestätigung und kann Duplikate liefern.

Genau-einmal-Aussagen gelten nur innerhalb ausdrücklich unterstützter Transaktionsgrenzen. Bestätigung des Transports ist nicht automatisch die dauerhafte fachliche Wirkung. Deduplizierung, Wiederaufnahme und Behandlung dauerhafter Fehler schließen diese Lücke.

Idempotenz schützt die fachliche Empfängerwirkung bei doppelter Zustellung; Retry steuert Zeitpunkt und Begrenzung weiterer Versuche. Transportbestätigung und Geschäftserfolg bleiben getrennte Aussagen.

Exactly-once gibt es über ein Netzwerk nicht als Transportzusage. Praktisch entsteht „effektiv einmal“ aus At-least-once plus idempotenter Verarbeitung, siehe Idempotenz.

Selbst prüfen

Teste dich in drei Stufen

  1. AblesenIm Bild nachsehen

    Welches Ergebnis zeigt die Ansicht bei „Bestätigen vor dem Speichern“ mit Absturz zwischen den Schritten?

    Lösung mit Begründung ansehen

    „Keine Rechnung – Auftrag verloren“: B-1042 ist quittiert, die Rechnung wurde aber nie gespeichert.

  2. AnwendenAuf eine neue Lage übertragen

    Der Shop bestätigt nach dem Speichern, der Worker stürzt dazwischen ab und prüft keine Kennung. Wie viele Rechnungen entstehen für B-1042?

    Lösung mit Begründung ansehen

    Zwei. Der Broker stellt erneut zu, und ohne Kennungsprüfung legt der Worker die Rechnung ein zweites Mal an.

  3. BewertenEine Alternative abwägen

    Was spricht für at-least-once mit Idempotenz statt at-most-once? Was ist der Preis, und was empfiehlst du für Rechnungen?

    Lösung mit Begründung ansehen

    Vorteil: Kein Auftrag geht verloren. Nachteil: Der Worker braucht Kennungsprüfung und Ablage. Für Rechnungen empfehle ich at-least-once mit Idempotenz, weil ein verlorener Auftrag fachlich schwerer wiegt.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

KommunikationTransactional OutboxTransactional Outbox speichert eine fachliche Änderung gemeinsam mit ihrer Versandabsicht.Öffnen KommunikationIdempotenzIdempotenz hält die fachliche Wirkung stabil, wenn derselbe Auftrag wiederholt wird.Öffnen BetriebRetryRetry wiederholt eine fehlgeschlagene Operation begrenzt und unter klaren Bedingungen.Öffnen

Quellen

Weiter im Lernpfad

Als Nächstes in Verteilte Systeme: CAP & PACELC.

6 Bausteine

Weiter mitCAP & PACELC