FehlerbildKapitel II · Verteilung · Baustein 2 von 6

Partielle Ausfälle

Ein Teilausfall tritt auf, wenn ein Teil eines verteilten Ablaufs ausfällt und andere Teile weiterarbeiten. Der Aufrufer kennt den endgültigen Zustand oft erst nach einer gezielten Klärung.

  1. ZwischenzustandDas Ergebnis ist noch unbekannt.
  2. StatusabfrageDer Anbieter nennt den echten Zustand.
  3. ZahlungskennungErmöglicht die gezielte Nachfrage.

Einordnung

Warum das wichtig ist

Bei verteilten Abläufen kann eine Antwort ausbleiben, obwohl der Anbieter die Aktion ausgeführt hat. Ohne eigenen Zwischenzustand rät der Shop und riskiert doppelte oder verlorene Zahlungen. Wiederholung und Wartezeit vertiefen eigene Bausteine.

Dieser Baustein behandelt unvollständige Ergebnisse über Dienstgrenzen. Retry beschreibt die kontrollierte Wiederholung; Timeout begrenzt die Wartezeit.

Auf einen Blick · Antwort bleibt aus, Zustand unklar

Bleibt die Antwort aus, ist das Ergebnis unbekannt, und erst eine Statusabfrage beim Anbieter klärt den Zustand.
Shop-Beispiel · Zustände und Übergänge

Zahlung mit ungeklärtem Ergebnis

Der Shop speichert eine Bestellung und ruft den Zahlungsanbieter auf. Die Verbindung bricht nach dem Absenden ab, während die Bestellverwaltung weiterläuft.

So liest du das Bild

  1. Zwischenzustand Der Kasten „Klärung läuft“: Antwort blieb aus, Ergebnis ist unbekannt.
  2. Statusabfrage Die Pfeile von „Klärung läuft“ zu „Bestätigt“ und zu „Abgelehnt“.
  3. Zahlungskennung Der Kasten „Zahlung angefordert“: Auftrag und Zahlungskennung sind gespeichert.

Breites Diagramm · bei Bedarf seitlich verschieben

Der Shop hält die Bestellung offen, bis eine Statusabfrage den Zahlungszustand klärt.
Diagramm als Text lesen
  • Zahlung angefordert: Auftrag und Zahlungskennung sind gespeichert.
  • Klärung läuft: Antwort blieb aus; Ergebnis ist unbekannt.
  • Bestätigt: Anbieterstatus bestätigt die Zahlung.
  • Abgelehnt: Anbieterstatus bestätigt die Ablehnung.
  • Zahlung angefordert → Klärung läuft: Antwortverbindung bricht ab
  • Klärung läuft → Bestätigt: Statusabfrage: erfolgreich
  • Klärung läuft → Abgelehnt: Statusabfrage: abgelehnt
Der Shop hält die Bestellung offen, bis eine Statusabfrage den Zahlungszustand klärt.

Nutzen & Grenzen

Hilft, wenn

  • Ein Aufruf kann nach möglichem Commit ohne Antwort enden; ein klärbarer Zustand hält den Vorgang bis zur Statusabfrage offen.
  • Unabhängig ausfallende Dienste brauchen getrennte Behandlung für Erfolg, Ablehnung und ungeklärten Ausgang.
  • Stabile Kennungen verbinden Statusabfrage und Wiederaufnahme, wenn ein erneuter Aufruf eine fachliche Wirkung wiederholen könnte.

Grenzen

  • Ein Timeout entscheidet den entfernten Ausgang nicht; behandle ihn als ungeklärt, bis eine Abfrage mit derselben Kennung ihn belegt.
  • Erneutes Senden kann die Zahlung verdoppeln; verbinde Wiederholung mit Idempotenz oder klärender Statusabfrage.
  • Der Zwischenzustand braucht eine Obergrenze und eine Regel, was nach ihr passiert; sonst bleibt B-1042 unbegrenzt offen.

In der Praxis

  1. Speichere einen ungeklärten Ausgang getrennt von Erfolg und Ablehnung. Eine stabile Vorgangskennung verbindet Statusabfrage und Wiederaufnahme über Prozessgrenzen.
  2. Prüfe Fehler vor und nach dem Commit. Timeout bedeutet fehlende Antwort; es entscheidet nicht, ob die Gegenstelle ihre Änderung bereits festgeschrieben hat.
  3. Wiederhole mit derselben Kennung und nur bei geklärter Wirkung. Timeout beschreibt die Wartegrenze; Circuit Breaker schützt bei anhaltender Nichterreichbarkeit.
Ausführliche Erklärung lesen

Ein partieller Ausfall entsteht, wenn Teilnehmer eines verteilten Ablaufs unabhängig arbeiten und einzelne Verbindungen oder Antworten ausbleiben. Ein Timeout beschreibt die Beobachtung des Aufrufers; der Empfänger kann die Änderung bereits festgeschrieben haben.

Der Ausgang bleibt bis zur Statusklärung unbekannt. Eine stabile Vorgangskennung verbindet Wiederholung, Abfrage und Ergebnis. Systeme sollten „abgelehnt“, „abgeschlossen“ und „ungeklärt“ unterscheidbar speichern und anzeigen.

Timeout beschreibt die Wartegrenze, Circuit Breaker begrenzt Aufrufe bei anhaltender Störung; beide lassen einen bereits ausgeführten Commit als möglichen Ausgang offen.

Eine schwer erkennbare Spielart heißt Grey Failure: Ein Teil ist nicht ausgefallen, antwortet aber langsam oder teilweise fehlerhaft, sodass Gesundheitsprüfungen ihn weiter als gesund melden.

Selbst prüfen

Teste dich in drei Stufen

  1. AblesenIm Bild nachsehen

    Welche zwei Ausgänge führen aus „Klärung läuft“ heraus?

    Lösung mit Begründung ansehen

    Zu „Bestätigt“ und zu „Abgelehnt“, jeweils nach der Statusabfrage beim Anbieter.

  2. AnwendenAuf eine neue Lage übertragen

    Der Kunde öffnet B-1042, während die Statusabfrage noch unbeantwortet ist. Darf der Shop die Bestellung als bezahlt anzeigen?

    Lösung mit Begründung ansehen

    Nein. Der Zustand „Bestätigt“ wird erst erreicht, wenn der Anbieterstatus die Zahlung belegt. Bis dahin bleibt „Klärung läuft“ sichtbar.

  3. BewertenEine Alternative abwägen

    Der Shop könnte bei ausbleibender Antwort sofort „Abgelehnt“ setzen. Was spricht dafür, was dagegen?

    Lösung mit Begründung ansehen

    Dafür spricht ein schnelles, einfaches Ergebnis. Dagegen: Der Anbieter hat die Zahlung womöglich verbucht, und eine erneute Zahlung könnte doppelt belasten. Die Statusabfrage vermeidet dieses Raten.

Vertiefen

Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.

Heartbeat und Ausfallerkennung

Ein fehlender Heartbeat ist ein Ausfallverdacht, kein sicherer Beweis: Netzverzögerung, Überlast oder ein pausierter Prozess können dieselbe Beobachtung erzeugen. Zeitstempel, verpasste Signale und Folgeantworten helfen, die Erkennung einzuordnen. Im Shop kann der Lagerdienst weiterarbeiten, obwohl sein Heartbeat verspätet eintrifft.

Behandle den Dienst zunächst als verdächtig und sichere den Vorgangszustand. Erst eine definierte Fehlerregel oder eine frische Statusantwort erlaubt die nächste Aktion; eine Erkennung allein klärt keine bereits ausgelöste Reservierung.

Zum AusprobierenUnterbrich im Shop den Heartbeat zum Lagerdienst, während dessen Verarbeitung weiterläuft. Prüfe, dass dein System den Dienst zunächst als verdächtig markiert, keinen zweiten Reservierungsauftrag blind sendet und den Vorgang anhand seiner Kennung mit einer frischen Statusantwort klärt.