Verteilte Systeme

Acht falsche Annahmen

Schon in den 1990er-Jahren schrieben Ingenieure bei Sun Microsystems die Annahmen auf, die Entwickler verteilter Systeme stillschweigend treffen – und die alle falsch sind:

Dazu kommt das Kernproblem: Teilausfälle. Auf einem einzelnen Rechner läuft ein Programm oder es stürzt ab. In einem verteilten System kann ein Teil ausfallen, während der Rest weitermacht – und von außen sieht ein ausgefallener Rechner genauso aus wie ein langsamer oder ein schlecht erreichbarer.

Wurde es ausgeführt oder nicht?

Ein Bestelldienst schickt eine Überweisung an den Zahlungsdienst. Die Antwort bleibt aus. Was tun?

Aus Sicht des Absenders sehen „Anfrage verloren“ und „Antwort verloren“ identisch aus: Es kam nichts zurück. Deshalb gibt es nur zwei Zustellgarantien, die man tatsächlich bauen kann:

Eine Operation ist idempotent, wenn mehrfaches Ausführen dasselbe bewirkt wie einmaliges. „Setze den Status auf versandt“ ist idempotent, „Buche 100 € ab“ nicht. Nicht-idempotente Operationen macht man idempotent, indem der Absender jeder Anfrage eine eindeutige Kennung mitgibt und der Empfänger sich merkt, welche er schon ausgeführt hat.

Konsens: Wer hat das Sagen?

Viele Systeme brauchen genau einen Rechner, der Entscheidungen trifft – einen Anführer (Leader). Er ordnet alle Schreibvorgänge, damit keine Widersprüche entstehen. Fällt er aus, muss ein neuer gewählt werden, und zwar so, dass es nie zwei gleichzeitig gibt. Das leistet ein Konsensverfahren. Das bekannteste ist Raft (2014), entworfen ausdrücklich, um verständlicher zu sein als sein Vorgänger Paxos. Raft steckt in etcd, dem Gedächtnis von Kubernetes, und in vielen Datenbanken. Die Kernidee: Alles braucht eine Mehrheit.

Weil jede Entscheidung eine Mehrheit braucht und es nur eine Mehrheit geben kann, kann es nie zwei Anführer geben, die beide etwas durchsetzen – auch nicht, wenn das Netz sich teilt. Die Minderheit bleibt einfach stehen; das ist die Entscheidung für Konsistenz im CAP-Theorem. Daraus folgt eine wichtige Faustregel: Ein Cluster aus drei Rechnern verkraftet einen Ausfall, einer aus fünf zwei. Ein vierter Rechner bringt nichts – für eine Mehrheit von vier braucht man drei, er verkraftet also ebenfalls nur einen Ausfall.

Timeouts, Neuversuche und der Ansturm danach

Ohne Timeout wartet ein Aufruf im Zweifel ewig – und mit ihm ein Thread, eine Verbindung, ein Nutzer. Also: immer ein Timeout. Nach einem Timeout liegt ein Neuversuch nahe. Aber Vorsicht: Wenn ein Dienst wegen Überlastung ausfällt und alle Aufrufer im selben Takt neu versuchen, trifft ihn bei der Rückkehr eine Welle, die ihn gleich wieder umwirft.

Dazu gehören zwei weitere Muster: Ein Circuit Breaker (Sicherung) zählt Fehler und hört nach zu vielen ganz auf, einen kranken Dienst anzurufen – er antwortet sofort mit einem Fehler oder einem Ersatzwert und probiert erst nach einer Weile wieder vorsichtig. Und ein Bulkhead (Schott) begrenzt, wie viele Threads oder Verbindungen ein einzelner Abhängiger belegen darf, damit ein langsamer Dienst nicht die ganze Anwendung blockiert.

Uhren lügen

Jeder Rechner hat seine eigene Uhr, und keine geht genau. Über NTP werden sie abgeglichen, aber Abweichungen von Millisekunden sind normal, manchmal mehr – und eine Uhr kann bei einer Korrektur sogar rückwärts springen. „Was zuerst passierte“ lässt sich deshalb über Rechnergrenzen hinweg nicht an Zeitstempeln ablesen. Verteilte Systeme benutzen stattdessen logische Uhren: Zähler, die mit jeder Nachricht weitergegeben werden und eine Reihenfolge garantieren, die zur Ursache-Wirkung-Beziehung passt (Lamport-Uhren, Versionsvektoren). Googles Datenbank Spanner geht einen anderen Weg: Atomuhren und GPS in jedem Rechenzentrum, und jede Zeitangabe hat ein ausdrückliches Unsicherheitsintervall.

Für Entwickler übersetzt

// Idempotenter Endpunkt: gleiche Kennung, gleiche Antwort – keine zweite Ausführung
@PostMapping("/ueberweisungen")
Ergebnis ueberweise(@RequestHeader("Idempotency-Key") UUID key, @RequestBody Auftrag a) {
    return ergebnisse.findById(key)                 // schon verarbeitet?
            .orElseGet(() -> service.fuehreAus(key, a)); // Buchung + Ergebnis mit Key in EINER Transaktion,
}                                                     // Key mit UNIQUE-Constraint gegen Gleichzeitiges

// Resilience4j: Neuversuch mit exponentiellem Backoff und Zufall, plus Sicherung
Retry retry = Retry.of("zahlung", RetryConfig.custom()
        .maxAttempts(4)
        .intervalFunction(IntervalFunction.ofExponentialRandomBackoff(Duration.ofMillis(200), 2.0))
        .build());
CircuitBreaker cb = CircuitBreaker.ofDefaults("zahlung");

Supplier<Ergebnis> aufruf = Decorators.ofSupplier(() -> zahlung.belaste(auftrag))
        .withCircuitBreaker(cb).withRetry(retry).decorate();

Häufige Irrtümer

Verwandte Begriffe