Verteilte Transaktionen sind Transaktionen, die Daten auf mehreren unabhängigen Knoten verändern und trotzdem als eine einzige atomare Einheit behandelt werden: Entweder committen alle beteiligten Systeme den Vorgang oder keines. Eine einzelne Datenbank kann Transaktionen mit klassischen ACID-Eigenschaften garantieren; sobald die Daten jedoch über mehrere Datenbanken oder Services verteilt sind, reicht der lokale Mechanismus nicht mehr aus.
Warum verteilte Transaktionen nötig sind
In verteilten Systemen entstehen sie vor allem durch Sharding und Cluster-Betrieb: Liegt Zeile A auf Knoten 1 und Zeile B auf Knoten 2, muss eine Transaktion, die beide Zeilen verändert, auf beiden Knoten atomar wirken. Das klassische Beispiel ist eine Überweisung: Das Konto des Senders liegt auf Datenbank A, das Konto des Empfängers auf Datenbank B. Wird nur auf einer Seite gebucht, entsteht ein inkonsistenter Zustand.
Der Koordinator und seine Teilnehmer
Eine verteilte Transaktion braucht einen Transaktionskoordinator, der die beteiligten Systeme – die sogenannten Teilnehmer – abstimmt. Das bekannteste Protokoll dafür ist das Two-Phase-Commit-Protokoll (2PC): Zuerst fragen alle Teilnehmer, ob sie den Vorgang ausführen können (Prepare-Phase), erst wenn alle zustimmen, wird der Commit ausgelöst. Quorum-Regeln, wie sie auch der Konsens-Ansatz nutzt, stellen sicher, dass genügend Knoten den Zustand bestätigen.
XA: Der Standard für verteilte Transaktionen
Der XA-Standard (X/Open, 1991) definiert eine Schnittstelle, über die Ressourcenmanager wie Datenbanken und Message Queues an einen Transaktionsmanager angebunden werden. Praktische Implementierungen sind XA-Transaktionen in MySQL, vorbereitete Transaktionen (Prepared Transactions) in PostgreSQL und das Java-Transaktions-API (JTA) mit Transaktionsmanagern wie Atomikos oder Narayana. Auch Cluster-Datenbanken nutzen ähnliche Koordinationsmechanismen.
Grenzen und Alternativen
Verteilte Transaktionen sind teuer: 2PC hält Ressourcen-Locks, bis alle Teilnehmer geantwortet haben, und blockiert bei einem Ausfall des Koordinators – die Teilnehmer warten dann auf eine Entscheidung. Das Drei-Phasen-Commit-Protokoll (3PC) versucht, dieses Blockieren zu vermeiden, wird in der Praxis aber selten eingesetzt. Bei langlaufenden Prozessen über viele Services ist stattdessen das Saga-Muster mit Kompensation verbreitet; Systeme, die auf Eventual Consistency setzen, verzichten ganz auf die sofortige Atomarität. Wer strikte Lese- und Schreibgarantien über mehrere Knoten braucht, findet sie bei Strong Consistency.
Zusammenfassung
- Verteilte Transaktionen machen mehrere Knoten zu einer atomaren Einheit.
- Der Koordinator stimmt die Teilnehmer per Two-Phase-Commit ab; XA ist der Standard dafür.
- Bei langen Prozessen sind Saga-Kompensation oder Eventual Consistency oft die bessere Wahl.
Verwandte Grundlagen: Raft, ACID-Transaktionssicherheit, Transaktionen in Datenbanken.