VS-10-Verteilte Transaktionen

Verteilte Systeme
Kapitel 10: Verteilte Transaktionen
Prof. Dr. Stefan Fischer
Institut für Telematik, Universität zu Lübeck
http://www.itm.uni-luebeck.de/people/fischer
Inhaltsüberblick der Vorlesung
1. Einführung und Motivation
2. Protokolle und Schichtenmodelle
3. Nachrichtenrepräsentation
4. Realisierung von Netzwerkdiensten
5. Kommunikationsmechanismen
6. Adressen, Namen und Verzeichnisdienste
7. Synchronisation
8. Replikation und Konsistenz
9. Fehlertoleranz
10.Verteilte Transaktionen
11.Sicherheit
1-2
Übersicht
• Transaktionen
– Flach
– Geschachtelt
– Verteilt
• Concurrency Control – ausgewählte Probleme
• Hier nur Grundlagen von Transaktionen
– Spezielle und vertiefende Grundlagen in
Datenbankvorlesungen
3
Einführung
• Transaktionen und gegenseitiger Ausschluss sind
sehr ähnlich
– Gegenseitiger Ausschluss: Eine Ressource darf nur von
einem Client gleichzeitig benutzt werden
– Transaktionen: Ebenfalls Schutz vor gleichzeitigem Zugriff
• Transaktionen gehen wesentlich weiter
– Möglich, auf mehrere Ressourcen in einer einzigen
atomaren Operation zuzugreifen
– Diverse Arten von Fehlern können abgefangen werden
– Prozesse verbleiben im Zustand vor Beginn einer
Transaktion, wenn diese zurückgesetzt wird
4
Transaktionen
• Transaktionen bestehen aus einer Folge von
Operationen (Anfragen an Server)
– Für diese gelten bestimmte Eigenschaften
– Die sog. ACID-Eigenschaften
• Beispiel: Flugbuchung
–
–
–
–
Kunde will von Hamburg nach Dallas fliegen
Kein Nonstop-Flug verfügbar; nur mit 2x umsteigen
Alle drei Flüge müssen einzeln gebucht werden
Kunde hat nur Interesse an der Buchung, wenn alle drei
Flüge buchbar sind
Implementierung durch eine Transaktion
5
Die ACID-Eigenschaften
• Von Härder und Reuter vorgeschlagenes Acronym
– Atomicity: alle Operationen der Transaktion oder keine
– Consistency: Transaktion überführt System von einem
konsistenten Zustand in den anderen
– Isolation: jede Transaktion muss von der Ausführung
anderer Transaktionen unabhängig bleiben
– Durability: wenn Transaktion abgeschlossen ist, müssen
Ergebnisse in permanentem Speicher gesichert werden
6
Transaktions-Primitive
• Mit diesen lassen sich alle interessanten
Operationen einer Transaktion unabhängig von
der spezifischen Anwendung ausdrücken
Primitive Description
BEGIN_TRANSACTION Start einer Transaktion
END_TRANSACTION Beende Transaktion und versuche zu commiten
ABORT_TRANSACTION Breche Transaktion ab, stelle alten Zustand wieder her
READ Lese Daten von Datei, Tabelle, Socket, etc.
WRITE Schreibe Daten in Datei, Tabelle, Socket, etc.
7
Beispiel Flugbuchung
Erfolgreiche Transaktion
• BEGIN_TRANSACTION
reserve HH -> FRA
reserve FRA -> JFK
reserve JFK -> DAL
END_TRANSACTION
• Alle Flüge gebucht nach
Ende der Transaktion
Abgebrochene Transaktion
• JFK -> DAL ausgebucht
• BEGIN_TRANSACTION
reserve HH -> FRA
reserve FRA -> JFK
reserve JFK -> DAL
ABORT_TRANSACTION
• Keine Flüge gebucht
8
Atomarer Commit von Transaktionen
• Erinnerung: Atomicity
– Alle Operationen der Transaktion oder keine
• Einfach: Ein-Phasen-Commit-Protokoll
– Koordinator fordert Teilnehmer solange zu commit/abort
auf, bis er von allen Bestätigungen gesammelt hat
– Teilnehmer haben keine Reaktionsmöglichkeit
• Daher: Zwei-Phasen-Commit
Security - 00 Layout Master
#9
Two-Phase-Commit-Protokoll
• Voting Phase
– Koordinator fragt jeden Teilnehmer, ob er zum Commit
bereit ist (Ja/Nein)
– Bereit: Sende Ja; bereite permanente Speicherung des
Commits vor
– Nicht bereit: Sende Nein; breche sofort ab
• Completion Phase
– Alle Teilnehmer sagen Ja: Sende doCommit an alle
• Nach Commit senden Teilnehmer haveCommitted
– Ansonsten: Sende doAbort an alle „Ja“-Sager
Security - 00 Layout Master
#10
Klassifizierung von Transaktionen
• Häufigster Fall: sog. „flache“ Transaktionen (flat
transactions)
• Probleme
– Sehr strikt und erlauben kein Commit von Teilergebnissen
– Möglicherweise nicht effizient, da alle Operationen sequentiell
ausgeführt werden
– Daten sind möglicherweise verteilt, so dass mehrere Rechner
beteiligt werden müssen
• Lösungen
– Geschachtelte Transaktionen
– Verteilte Transaktionen
11
Geschachtelte Transaktionen
• Erweitern Modell der flachen
Transaktionen
T1
– Gestatten, dass Transaktionen
aus anderen Transaktionen
zusammengesetzt sind
Op
• Transaktion auf höchster
Ebene: top-level transaction
Op
T1
– Alle anderen: Teiltransaktionen
(sub-transactions)
Op1_2
T1_1
• Problem geschachtelter
Transaktionen
– Was passiert, wenn eine
Teiltransaktion abgebrochen
wird?
...
Op
...
T1_3
Op
Op
...
Op
12
Vorteile geschachtelter Transaktionen
• Zusätzliche Nebenläufigkeit
– Subtransactions auf der selben Hierarchieebene können
nebenläufig ausgeführt werden
– Beispiel: Berechnung der Summe aller Konten einer Bank
• Operation branchTotal() muss für alle Konten getBalance() aufrufen
• Jeder dieser Aufrufe könnte als Untertransaktion gestartet werden
• Unabhängiges Commit oder Abort
– Einzelne Transaktionen werden dadurch potentiell robuster
– Hängt von der Anwendung ab
– Elterntransaktion muss jeweils entscheiden, welche Folge ein
Abort der Untertransaktion haben soll
13
Beispiel für teilweisen Commit
• Beispiel der Flugbuchung aus 3 Segmenten
– Angenommen, der Flug JFK
DAL ist nicht buchbar
• Es könnte trotzdem sinnvoll sein, die Flüge HH
FRA
und FRA
JFK zu buchen, da dies vielleicht schon
schwierig war
– Dies ist im geschachtelten Modell möglich
T1: Buche Flug HH
DAL
COMMIT
ABORT
COMMIT
T1.1: Buche HH
FRA
COMMIT
T1.2: Buche FRA
JFK
T1.3: Buche JFK
DAL
14
Regeln für Commit geschachtelter
Transaktionen
• Transaktion darf nur abgeschlossen werden, wenn alle
Untertransaktionen abgeschlossen sind
• Abbruch der Elterntransaktion: Abbruch aller Subtransaktionen
• Abschluss einer Untertransaktion: Entscheidet unabhängig,
entweder provisorisch zu comitten oder endgültig abzubrechen
• Abbruch einer Untertransaktion: Elterntransaktion entscheidet,
was weiter geschieht
• Commit einer Elterntransaktion: Alle provisorisch committeten
Untertransaktionen können committet werden
15
Verteilte Transaktionen
• Geschachtelte Transaktionen entstehen durch
logische Partitionierung größerer Transaktionen
– Subtransaktionen werden unter Umständen auf
unterschiedlichen Rechnern ausgeführt
– Subtransaktionen sind auf Blattebene logisch nicht mehr
teilbare Einheiten
– Beispiel: Reservierung eines einzelnen Fluges
• Trotzdem können diese Subtransaktionen auf
mehreren Rechnern arbeiten
– Man spricht dann von verteilten Transaktionen
16
Concurrency Control
• Parallele Ausführung von Transaktionen zur
Steigerung der Performance
– Dabei können beim Zugriff mehrere Transaktionen auf
dasselbe Datum Konflikte entstehen
• Unterscheidung
– READ-WRITE: eine Transaktion will Datum schreiben, das
eine andere gerade liest
– WRITE-WRITE: Transaktionen wollen dasselbe Datum
schreiben
– READ-READ ist kein Konflikt!
• Concurrency Control verhindert Inkonsistenzen
17
Beispiel: “Lost update”-Problem
Transaktion A
Transaktion B
• b = account1.getBalance();
• account1.setBalance(1.1*b);
• account2.withdraw(0.1*b);
• b = account1.getBalance();
• account1.setBalance(1.1*b);
• account3.withdraw(0.1*b);
b = account1.getBalance();
200
b = account1.getBalance();
200
account1.setBalance(1.1*b); 220
account1.setBalance(1.1*b); 220
account2.withdraw(0.1*b);
80
account3.withdraw(0.1*b);
Initialer Zustand: account1: 100, account2: 200, account3: 300
280
18
Locking
• Am weitesten verbreitete Form der Concurrency Control
• Einfachste Variante: Exklusive Locks
– Wenn Prozesse Zugriff auf Ressource benötigen, fordert er vom
Scheduler (über Transaction Manager) ein exklusives Lock an
– Nach Erhalt und Abschluss der Arbeit gibt er das Lock wieder
zurück
– Vergabe der Locks durch Scheduler sodass nur korrekte
Schedules entstehen
• Pessimistic locking
– Es werden mit hoher Wahrscheinlichkeit Konflikten erwartet
– Gegenteil: Optimistic Locking
19
Two-Phase Locking (2PL)
• Bewiesen ist, dass 2PL korrekte Schedules erstellt
• Zwei Phasen
– Wachstumsphase: Locks werden erhalten, aber nicht freigegeben
– Schrumpfphase: Locks nur freigeben, aber nicht anfordern
• Bei Erhalt einer Operation op(T,x)
– Prüfung ob Konflikt mit Operationen, für die schon Locks existieren
– Falls ja, wird op(T,x) verzögert, falls nein, bekommt T das Lock für x
• Unterscheidung zweier Lock-Typen
– Read-Lock (auch shared): mehrere Prozesse können lesend auf das
gesperrte Objekt zugreifen
– Write-Lock (auch exclusive): nur der sperrende Prozess kann auf das
Objekt zugreifen und dieses auch schreiben
20
Sonderfälle von 2PL: konservativ und strikt
•
Konservativ
– Zu Beginn müssen alle Locks
angefordert werden
– Verhindert Deadlocks
– Verlust an Parallelität
Operation
kann erst begonnen werden, wenn
alle Locks erhalten wurden
•
Strikt
– Locks dürfen erst am Ende
freigegeben werden
– Verhindert Schneeballeffekt
(kaskadierendes Zurücksetzen
wechselseitig abhängiger
Transaktionen)
– Locks werden ggf. länger gehalten
als erforderlich
•
Kombination aus beidem:
potenziell wie eine sequenzielle
Ausführung von Transaktionen
Security - 00 Layout Master
Bildquelle: http://de.wikipedia.org/w/index.php?title=Datei:2pl.png&filetimestamp=20101022190055
#21
Deadlocks
• Zustand, in dem jedes Mitglied einer Gruppe von
Transaktionen darauf wartet, dass ein anderes
Mitglied ein Lock freigibt
• Je feiner die Granularität bei der Concurrency
Control, desto geringer die Gefahr von Deadlocks
• Kann man Deadlocks erkennen bzw. verhindern?
22
Beispiel für Deadlock und Wait-For-Graph
Transaktion T
Locks
a.deposit(100);
write(A)
b.Withdraw(100);
Transaktion U
b.deposit(200);
write(B)
a.withdraw(200);
wait for T‘s
lock on write(A)
wait for U‘s
lock on write(B)
Held by
Waits for
A
T
U
U
T
Waits for
B
Held by
23
Allgemein: Zyklus im Wait-For-Graph
• Wenn im Wait-for-Graph ein Zyklus existiert, dann
ist das System in einem Deadlock
U
T
V
24
Distributed Deadlocks
• Verteilte Transaktionen
verteilte Deadlocks
– Problem der Deadlocks schwieriger
– Verteilte Deadlocks können u.U. nicht am lokalen WaitFor-Graphen erkannt werden
• Vielmehr muss ein globaler Graph untersucht und
dieser dann auf Zyklen untersucht werden
25
Beispiel für verteilten Deadlock
Server Z
U
Held by
V
d.deposit(10)
c
Wait
for
W
b.deposit(10)
W
d
a.deposit(20)
c.deposit(30)
Wait
for
V
b.withdr(30)
c.withdr(20)
Server X
Held
By
a.withdr(20)
a
Held
by
Wait-For-Graph
Held
By
Server Y
b
Wait
for
V
W
U
U
26
Konstruktion des globalen Wait-For-Graphen
• Konstruktion aus lokalen Wait-For-Graphen
• Einfachste Lösung
1. Zentraler Koordinator sammelt lokale Graphen und konstruiert
daraus den Globalen
2. Anschließend untersucht er ihn auf Deadlocks
3. Fällt Entscheidung und informiert betreffenden Server über die
Notwendigkeit eines Transaktionsabbruchs
4. Gehe zu 1
• Nicht immer gut wegen der üblichen Probleme (Bottleneck,
single point of failure)
27
Verteilte Ermittlung des Graphen
• Mittels eines Snapshot-Algorithmus
• Alternative: „Edge Chasing“-Algorithmus
– Keine Konstruktion des globalen Graphen
– Server erhalten für sie relevante Informationen über einige Kanten
– Server versenden Wartebeziehungen in „Probe-Nachrichten“ an andere
Server, um Zyklen aufzudecken
• Ein Prozess erkennt einen Deadlock, wenn er eine von Ihm gesendete
Nachricht wieder erhält
• Wenn ein Prozess auf eine Resource wartet, sendet er eine Probe an
alle anderen Prozesse (Inhalt: ID von A, Pfad der Nachricht)
– If eventually the probe returns to process A, there is a circular waiting loop of
blocked processes, and a deadlock is detected. Efficiently detecting such
cycles in the “wait-for graph” of blocked processes is an important
implementation problem.
28
Edge-Chasing: Drei Phasen
• Initiation
– Prozess T wartet auf U: initiiert eine Erkennung
– Sendet Probe mit „T U“
• Detection (Empfang einer Probe)
– Entscheidung: Deadlock und/oder Weiterleiten
– Empfang von T U
• Füge Kante in lokale Sicht und prüfe au Deadlocks
• Wartet U? Ja, auf V: Sende T U V
• Resolution
– Erkennung eines Deadlock: Eine Transaktionen im Zyklus
wird abgebrochen
Security - 00 Layout Master
#29
X weiss, dass W auf U
wartet. Er gibt die Info
an Y weiter.
Beispiel
Held by
W
W U V W
Deadlock
detected
Waits for
Z
X
C
A
Z schließlich fügt
hinzu, dass V auf
W wartet und
entdeckt den
Zyklus
Deadlock!
W U V
Waits
for
Held by
W U
V
U
Held by
B
Y fügt die Information
hinzu, dass U auf V
wartet. Er gibt die Info
an Z weiter.
Waits for
Y
30
Zusammenfassung
• Transaktionen sind ein mächtiges Mittel zur
Realisierung nebenläufigen Zugriffs auf Daten
• Geschachtelte und verteilte Transaktionen
erweitern das Modell, benötigen aber auch neue
Algorithmen
31