Two-Phase Commit (2PC) ist ein Protokoll, mit dem eine Transaktion über mehrere unabhängige Systeme hinweg atomar abgeschlossen wird: Entweder committen alle beteiligten Teilnehmer oder keiner. Es ist das klassische Verfahren für verteilte Transaktionen in Datenbanken und entstand als Erweiterung der ACID-Garantien auf mehrere Knoten.
Ablauf: Koordinator und Teilnehmer
Ein Koordinator (Transaction Manager) steuert die Transaktion, alle anderen beteiligten Systeme heißen Teilnehmer (Cohorts). Das Protokoll läuft in zwei Phasen:
- Phase 1 (Prepare/Vote): Der Koordinator sendet eine Prepare-Anfrage an alle Teilnehmer. Jeder Teilnehmer schreibt seine Undo-/Redo-Informationen in ein stabiles Log und antwortet mit YES (bereit) oder NO (Abort).
- Phase 2 (Commit/Abort): Haben alle Teilnehmer mit YES geantwortet, sendet der Koordinator Commit; andernfalls Abort. Die Teilnehmer führen die Anweisung aus und bestätigen.
Die Entscheidung ist damit all-or-nothing: Schon in Phase 1 sichert jeder Teilnehmer zu, den Befehl ausführen zu können, bevor das Ergebnis feststeht. Typische Umsetzungen sind der XA-Standard für verteilte Datenbanktransaktionen oder PREPARE TRANSACTION in PostgreSQL.
Das Blocking-Problem
Der entscheidende Nachteil von 2PC ist das Blocking-Problem: Fällt der Koordinator aus, nachdem die Teilnehmer mit YES geantwortet haben, aber bevor die Commit-Entscheidung ankommt, müssen alle Teilnehmer unbestimmt lange warten. Sie halten ihre Ressourcen und Locks und können weder committen noch abbrechen — der Koordinator ist ein Single Point of Failure. Das Protokoll garantiert also Atomarität, aber keinen Fortschritt bei Ausfällen; genau darin unterscheidet es sich von einem echten Konsens-Algorithmus wie Paxos, der Ausfälle durch Mehrheiten überlebt.
Alternativen
Der theoretische Three-Phase Commit (3PC) reduziert das Blocking durch eine zusätzliche Phase, ist aber bei Netzwerkpartitionen nicht zuverlässig und wird in der Praxis selten eingesetzt. Robustere Lösungen ersetzen den einzelnen Koordinator durch einen konsensbasierten Koordinator (zum Beispiel via Paxos oder Raft). In Microservices-Architekturen bevorzugt man häufig das Saga-Muster mit kompensierenden Aktionen statt strikter Atomarität, weil lange verteilte Transaktionen sonst viele Ressourcen blockieren. Auch hier bleibt die Frage, wer die Koordination übernimmt, eine Frage der Leader Election.
Verwandte Grundlagen: ACID, Sharding, Datenbank-Cluster, Konsens, Eventual Consistency.