Begriff

Two-Phase Commit (2PC)

Distributed Systems Database S3

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Du willst eine Hochzeit feiern (Transaktion). Du (Koordinator) fragst alle Gäste: "Kommst du?" Es gibt zwei Phasen:

Prepare (Voting): Der Priester fragt: "Willst du, Datenbank A, diese Daten speichern? Willst du, Datenbank B, diese Daten speichern?" Jede Datenbank prüft (habe ich Platz? Locks?), schreibt ins Log "Prepared" und antwortet "Ja".
Commit (Decision): Wenn alle Ja gesagt haben, sagt der Priester: "Hiermit seid ihr committed!" -> Datenbanken schreiben endgültig. Wenn einer "Nein" sagt (oder nicht antwortet) -> Priester sagt: "Abort!" -> Alle rollen zurück. Das garantiert Atomicity über mehrere Server hinweg (Distributed Transaction).

Merksatz: Ein Protokoll zur Koordination verteilter Transaktionen, das in zwei Phasen (Prepare und Commit) sicherstellt, dass alle beteiligten Knoten entweder gemeinsam zustimmen (Commit) oder gemeinsam ablehnen (Abort).

1. Das Logging-Gesetz (Write-Ahead Logging)

Damit 2PC einen Crash überlebt, müssen alle Beteiligten zwingend ein Log führen. Bevor ein Teilnehmer "Ja" zum Koordinator sagt, muss er den Zustand "PREPARED" auf seine Festplatte (oder einen persistenten State-Store) schreiben (fsync). Wenn der Server danach den Strom verliert und neu startet, sieht er im Log: "Ich habe Ja gesagt, ich warte auf die Entscheidung." Ohne dieses Log wäre 2PC nicht "durabel". Dieses ständige Schreiben auf die Festplatte ist der Grund, warum 2PC in Cloud-Systemen oft als Performance-Bremse gilt.

2. In-Doubt Transactions & Admin-Hell

Wenn der Koordinator stirbt, während die Teilnehmer auf "PREPARED" hängen, nennt man das eine In-Doubt Transaction. Die Datenbanken halten Sperren (Locks) auf den betroffenen Zeilen. Kein anderer User kann diese Daten lesen oder ändern. In Hochverfügbarkeits-Umgebungen ist das der Super-GAU. Ein Datenbank-Admin muss dann manuell eingreifen und entscheiden: "Heuristisch Committen" oder "Heuristisch Aborten". Er spielt Gott, mit dem Risiko, die Datenkonsistenz zu zerstören. Modernes SRE-Design versucht genau diese manuelle Entscheidung durch automatische Recovery-Manager zu vermeiden.

3. Google Spanner: 2PC über Paxos

Google hat mit Spanner bewiesen, dass 2PC doch skalieren kann, wenn man es richtig kombiniert. Anstatt eines einzelnen Koordinators nutzt Spanner eine Paxos-Gruppe pro Shard. Innerhalb eines Shards herrscht Paxos-Konsens (kein Single-Point-of-Failure). Über die Shards hinweg wird dann 2PC genutzt, um globale Transaktionen zu koordinieren. Da Paxos dafür sorgt, dass "immer jemand da ist", wird das klassische 2PC-Blocking-Problem fast vollständig eliminiert. Zusätzlich nutzt Spanner atomare Uhren (TrueTime), um das Timing der Transaktionen weltweit zu synchronisieren – ein technischer Kraftakt, der zeigt, wie viel Aufwand nötig ist, um 2PC absolut zuverlässig zu machen.

Quick-Check

Unterschied zu 3PC?
3PC fügt eine Phase "Pre-Commit" hinzu, um das Blocking-Problem zu lösen. Wird aber in der Praxis fast nie genutzt (zu komplex, Netzwerk-Partitionen machen es kaputt). Paxos Commit ist besser.
Langsam?
Ja. 2 Round-Trips pro Transaktion. Und fsync auf allen Nodes. Skaliert schlecht.
Wer nutzt es?
Google Spanner nutzt 2PC über Paxos-Gruppen ("Paxos over 2PC"). Das ist State of the Art.