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.
- ZwischenzustandDas Ergebnis ist noch unbekannt.
- StatusabfrageDer Anbieter nennt den echten Zustand.
- 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
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
- Zwischenzustand Der Kasten „Klärung läuft“: Antwort blieb aus, Ergebnis ist unbekannt.
- Statusabfrage Die Pfeile von „Klärung läuft“ zu „Bestätigt“ und zu „Abgelehnt“.
- Zahlungskennung Der Kasten „Zahlung angefordert“: Auftrag und Zahlungskennung sind gespeichert.
Breites Diagramm · bei Bedarf seitlich verschieben
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
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
- Speichere einen ungeklärten Ausgang getrennt von Erfolg und Ablehnung. Eine stabile Vorgangskennung verbindet Statusabfrage und Wiederaufnahme über Prozessgrenzen.
- Prüfe Fehler vor und nach dem Commit. Timeout bedeutet fehlende Antwort; es entscheidet nicht, ob die Gegenstelle ihre Änderung bereits festgeschrieben hat.
- 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
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.
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.
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.
Weiterführende Bausteine
Quellen
- AWS – Timeouts, retries, and backoff with jitter (öffnet in neuem Tab)Erklärt Timeouts, begrenzte Wiederholungen und Jitter anhand verteilter Ausfälle.
- Google SRE – Handling Overload (öffnet in neuem Tab)Erklärt, wie begrenzte Ressourcen und Überlast Ausfälle verstärken.
- AWS – Challenges with distributed systems (öffnet in neuem Tab)Ordnet Unsicherheit, Netzwerkausfälle und voneinander unabhängige Fehlerzustände ein.
- Unmesh Joshi · HeartBeat (öffnet in neuem Tab)Periodische Lebenszeichen als Grundlage einer zeitabhängigen Ausfallerkennung.