© GreenFlash/Shutterstock.com
Ein Überblick über Umsetzungsstrategien

Verteilte Transaktionen in verteilten Systemen


Verteilte Transaktionen sind out, das haben die Softwarearchitekten im Laufe der letzten Jahre erkannt. Neuere Persistenzsysteme bieten die Funktionalität für verteilte Transaktionen gar nicht an oder empfehlen, dieses Transaktionsverhalten, falls doch vorhanden, nur in Ausnahmefällen zu verwenden. Doch was kann man als Softwarearchitekt empfehlen, wenn die fachlichen Anforderungen so gestaltet sind, dass Daten, die in mehreren Datentöpfen persistiert werden, zueinander konsistent sein müssen? Der nachfolgende Überblick soll die Auswahl der passenden Umsetzungsstrategie abgestimmt auf den jeweiligen Use Case erleichtern.

Verteilte Transaktionen (XA Transactions) basieren auf dem Two-Phase-Commit-(2PC-)Protokoll. Dieses Protokoll war in der Vergangenheit essenzieller Bestandteil eines jeden Datenbanksystems und wurde somit das zentrale Konzept, um das Konsistenzproblem bei verteilten Datenbanken zu lösen. Doch wo liegen nun die Probleme beim Einsatz dieses Protokolls? Durch die synchronen Eigenschaften des Protokolls werden verteilte System miteinander sehr eng gekoppelt. Der Ausfall eines der beiden Systeme wird auch das andere System stark beeinträchtigt. Neben dem Absturz eines der beiden Systeme, was eher selten der Fall ist, kann es aber auch zu Problemen in der Kommunikation untereinander kommen [1]. Beide Fehlerwahrscheinlichkeiten zusammen genommen erhöhen das gesamte Ausfallrisiko. Nachdem man sich endlich eingestanden hat, dass Ausfälle passieren können, wurde begonnen, nach Alternativen zu suchen. Doch dazu später mehr.

Das 2PC-Protokoll ist, wie der Name schon sagt, in zwei Phasen unterteilt. Phase 1 ist die sogenannte Prepare-Phase, die im zweiten Schritt mit der Commit-Phase abgeschlossen wird. Jede XA Transaction muss diese beiden Phasen durchlaufen, wodurch die Ausführung der Transaktion sehr langsam wird. Ein Mehr an Kommunikation erhöht wiederum die Wahrscheinlichkeit eines Fehlers. Für den Fall eines Absturzes muss das Datenbanksystem eine Recovery-Funktionalität besitzen, die das System wieder in einen fehlerfreien Zustand versetzen kann. All diese Anforderungen an das 2PC-Protokoll erhöhen die Komplexität eines Datenbanksystems enorm. Bei Hochlastsystemen hat man sich daher als Softwarearchitekt immer schon zweimal überlegt, ob der Use Case eine verteilte Transaktion erforderlich macht oder ob man darauf verzichten kann.

Doch es gibt auch ganz triviale Gründe für die Vermeidung von verteilten Transaktionen: Sie sind schlicht und ergre...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang