Three-Phase Commit (3PC)

Das Problem von Two-Phase Commit (2PC): Wenn der Koordinator (der Boss) in Phase 2 abstürzt, nachdem er "Prepare" gesendet hat, hängen alle Datenbanken (Blockierung). Sie wissen nicht: "Soll ich Committen oder Aborten?" Three-Phase Commit fügt eine dritte Phase ein ("Pre-Commit").

CanCommit? (Alle sagen Ja).
PreCommit: "Achtung, wir werden gleich committen! Wenn ich (Koordinator) sterbe, geht davon aus, dass wir es tun werden."
DoCommit: "Jetzt macht es wirklich." Dadurch können die Teilnehmer, wenn der Koordinator stirbt, untereinander reden ("Hat einer von euch PreCommit bekommen?") und das Problem lösen, ohne ewig zu warten. Klingt toll, aber: Bei Netzwerk-Partitionen (Split Brain) funktioniert es immer noch nicht. Deshalb nutzt es in der Praxis niemand. (Stattdessen Paxos/Raft).

Merksatz: Ein theoretisches Erweiterungsprotokoll von 2PC, das durch eine zusätzliche Phase ("Pre-Commit") das Blockierungsproblem bei Koordinator-Ausfall lösen soll, jedoch anfällig für Netzwerkpartitionen bleibt.

Gar nicht. Es ist ein akademisches Beispiel dafür, wie man versucht, Blocking zu verhindern. Moderne Systeme nutzen Consensus-Algorithmen (Paxos, Raft), die Mehrheitsentscheidungen (Quorum) treffen, statt auf alle zu warten.

1. Non-Blocking Protocol

3PC ist "non-blocking" unter der Annahme eines "Fail-Stop"-Modells (Knoten stürzen ab, aber Netzwerk ist perfekt). In der Realität (Internet) gibt es Netzwerk-Delays und Partitionen. Wenn Phase 2 (PreCommit) nur die Hälfte der Nodes erreicht, haben wir Inkonsistenz.

2. Timeout Design

Wenn ein Teilnehmer in Phase 2 (PreCommit) nichts mehr hört, committet er (nach Timeout). Das ist riskant. Im Grunde versucht 3PC, das CAP-Theorem auszutricksen (Consistency + Availability bei Partition), was unmöglich ist (FLP Impossibility Result).

1. Das FLP-Impossibility-Resultat

Warum "lügt" 3PC, wenn es behauptet, das Blockierungs-Problem zu lösen? Das FLP-Resultat (Fischer, Lynch, Paterson, 1985) beweist mathematisch, dass es in einem asynchronen Netzwerk (wie dem Internet, wo Nachrichten beliebig lange dauern können) unmöglich ist, einen Konsens zu erreichen, wenn auch nur ein einziger Teilnehmer abstürzen kann. 3PC versucht das Problem durch Timeouts zu lösen. Aber ein Timeout kann bedeuten: "Der Node ist tot" ODER "Das Netzwerk ist nur gerade extrem langsam". 3PC kann den Unterschied nicht wissen. Bei einer Netzwerk-Partition treffen die beiden Hälften unterschiedliche Entscheidungen (Split Brain), was zu Datenkorruption führt.

2. Virtual Synchrony

3PC funktioniert in der Praxis nur sicher innerhalb von Systemen, die Virtual Synchrony bieten (z. B. im ISIS Toolkit). Hierbei garantiert die Netzwerkschicht, dass alle überlebenden Teilnehmer exakt die gleiche Sequenz von Nachrichten sehen, bevor eine neue Gruppen-Ansicht (View Change) deklariert wird. In einer solchen kontrollierten Umgebung kann 3PC sicherstellen, dass die Phase 2 (PreCommit) entweder alle erreicht oder niemanden. In der modernen Cloud-Welt ist dieses Modell jedoch veraltet, da es nicht gut über Rechenzentrums-Grenzen hinweg skaliert.

3. Warum Paxos & Raft gewonnen haben

Der entscheidende Unterschied: 2PC und 3PC sind Quorum-intolerant. Sie brauchen die Zustimmung von allen (100%). Wenn ein Node im Urlaub ist, steht die Welt still. Paxos und Raft brauchen nur eine Mehrheit ($N/2 + 1$). Dadurch sind sie "Progressive": Solange mehr als die Hälfte des Clusters lebt, können Transaktionen fließen. Sie kombinieren die Konsistenz von 2PC mit einer Verfügbarkeit, von der 3PC nur träumen kann. 3PC bleibt daher ein wichtiges Kapitel in Lehrbüchern über verteilte Systeme, hat aber seinen Platz in der realen Software-Entwicklung an Quorum-basierte Protokolle verloren.