Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Vs6.31 6.3 Verteilte Transaktionen Situation:Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.B. verteilte Datenbank, verteiltes.

Ähnliche Präsentationen


Präsentation zum Thema: "Vs6.31 6.3 Verteilte Transaktionen Situation:Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.B. verteilte Datenbank, verteiltes."—  Präsentation transkript:

1 vs Verteilte Transaktionen Situation:Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.B. verteilte Datenbank, verteiltes Dateisystem,...) d.h. in Fragmente aufgeteilt, für die jeweils ein Server zuständig ist. Auf diesem Datenbestand soll eine Operationsfolge "sicher" ausgeführt werden.

2 vs6.32 z.B.: Buchung einer Pauschalreise: Fragment Hotels + Fragment Flüge Konsistenzforderung: - keine Hotelbuchung ohne passende Flugbuchung - keine Flugbuchung ohne passende Hotelbuchung Überweisung: Fragment Bank A + Fragment Bank B Konsistenzforderung: - Es geht kein Geld verloren und es kommt keines hinzu

3 vs6.33  Operationen sollten transaktional ausgeführt werden Transaktion BEGIN..... [ABORT]..... COMMIT sichert die Eigenschaften Atomicity- Atomarität: alles oder nichts Consistence- Konsistenz: Invariante bleibt gewährleistet Isolation- Serialisierbarkeit bei nebenläufigen Zugriffen Durability- Persistenz: Daten bleiben dauerhaft erhalten

4 vs6.34 Serialisierbarkeit Isolation: Transaktionen sollen voneinander unabhängig sein, im Interesse der Performanz sollen sie jedoch so "nebenläufig wie möglich" ausgeführt werden Serialisierbarkeit: Der Effekt der nebenläufigen Ausführung mehrerer Transaktionen soll der gleiche sein, als wären die Transaktionen nacheinander ausgeführt worden

5 vs6.35 Transaktion T 1 : begin x = 0; x = x+1; commit Transaktion T 2 : begin x = 0; x = x+2; commit Transaktion T 3 : begin x = 0; x = x+3; commit Ausführungs- reihenfolge 1: x = 0; x = x+1; x = 0; x = x+2; x = 0; x = x+3; Ausführungs- reihenfolge 2: x = 0; x = x+1; x = x+2; x = 0; x = x+3; Ausführungs- reihenfolge 1: x = 0; x = x+1; x = 0; x = x+2; x = x+3; serialisiert (x==3) nicht serialisiert aber OK (x==3) nicht OK (x==5)

6 vs Serialisierbarkeit durch Ausschlusssynchronisation nur praktikabel für kleine fragmentierte Objekte, nicht für ganze Datenbanken! Möglichkeiten:  Verteilter Ausschluss (5.4  Sperrsynchronisation durch zentralen Koordinator, virtuellen Token Ring oder verteilte Warteschlange)5.4 zu strikt angesichts lesender vs. schreibender Operationen

7 vs6.37  Verteilter R/W-Ausschluss: a) In virtuellem Ring kreisende Marke (5.4.2  ) trägt Zähler m5.4.2 = Anzahl der gerade aktiven lesenden Operationen; schreibwillige Operation muß auf Marke mit m = 0 warten und diese festhalten. Nachteil: strikte Bevorzugung der Leser

8 vs6.38 b) Virtueller Ring von n Stationen, kreisende Marke enthält m „Stimmen“ (anfangs m = n); festgelegte Quoren für Lese- bzw. Schreibrecht Leser braucht r Stimmen Schreiberbraucht w Stimmen, mit folgenden Bedingungen für r und w: r + w  n(keine Leser-Schreiber-Konflikte) n/2  w  n(keine Schreiber-Schreiber-Konflikte) ( 0  r  n )

9 vs6.39 Beispiel: n = 8 r = 4 w = 5 (m = 8) Alesenm -= 4 (4) Blesenm -= 4 (0) Cschreiben(m<5)Leser-Schreiber-Ausschluss Dlesen(m<4) im Unterschied zu Variante a)...weniger Leser gleichzeitig A fertigm += 4 (4) Bfertigm += 4 (8) Cschreibenm -= 5 (3) Dlesen(m<4)Leser-Schreiber-Ausschluss...

10 vs6.310 c) Varianten anderer Ansätze aus 5.4 etwas bessere Fairness für Schreiber Fairness "einstellbar" Variante r = 1, w = n äquivalent zu a) Vorteile werden erkauft durch eingeschränkte Nebenläufigkeit für die Leser

11 vs Serialisierbarkeit durch verteilte Transaktionen (sichern nicht nur Serialisierbarkeit, sondern ACID insgesamt) naiver Ansatz: –beteilige Server starten lokale Transaktion –Koordinator fordert sie auf Wunsch des Klienten zum Commit oder Abort auf –(kein Abbruch durch andere Server möglich) Koordinator Verteiltes Objekt Klienten

12 vs Phasen-Commit-Protokoll (2PC) (nicht verwechseln mit 2-Phasen-Sperren, 2PL) –beteiligte Server müssen sich bei Commit -Wunsch einig werden über Abschluss oder Abbruch der verteilten Transaktion BEGIN : alle beteiligten Server werden zu lokalem BEGIN aufgefordert ABORT : alle beteiligten Server werden zu lokalem ABORT aufgefordert COMMIT : 2PC tritt in Aktion:...

13 vs6.313 Phase 1 – Abstimmen: 1. „Commit?“ an alle Server; 2. diese prüfen, ob Commit möglich wäre und antworten mit „Ja“ oder „Nein“. Phase 2 – Abschließen nach Eintreffen aller Anworten: 3. Falls alle Server mit „Ja“ geantwortet haben, „Commit!“ an alle Server, sonst „Abort!“ an alle Server; 4. diese befolgen den Befehl und quittieren. Präzisierung/weiter Absicherung unter Zuhilfenahme diverser Timeouts – siehe z.B. Coulouris et al.: Verteilte Systeme

14 vs6.314 Geschachtelte Transaktionen (nested transactions): Die Teiltransaktionen können wiederum Teiltransaktionen haben T X Y Z T W Y Z U V T1 T2 X T11 T12 T21 T22 flache (verteilte) Transaktion verschachtelte Transaktion

15 vs6.315 Vorteile: - Erhöhung des Parallelitätsgrades - Abbruch einer Kind-Transaktion muss nicht unbedingt Abbruch der Eltern-Transaktion zur Folge haben (letztere ist programmatisch darauf vorbereitet) weitere Details: Özsu/Valduriez: Principles of Distributed Database Systems


Herunterladen ppt "Vs6.31 6.3 Verteilte Transaktionen Situation:Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.B. verteilte Datenbank, verteiltes."

Ähnliche Präsentationen


Google-Anzeigen