Verteilte Systeme (Vorlesung 13)

Heute haben wir uns mit Konsistenzmodellen und Verteilten Transaktionen beschäftigt.

Skript-Anfang	VS_4_So2014_3 – Seite 1
Skript-Ende	VS_4_So2014_3 – Seite 51

Konsistenz

• Paralelle Zugriffe können mit Hilfe von Lamport blockiert werden

2 Phasen Commit

1. Koordinator (Aufrufender Prozess) fragt die Teilnehmer, ob die Transaktion gelingt
2. Ein Teilnehmer blockiert seine Ressourcen nach seinem ready, bis eine Antwort vom Koordinator kommt
3. Nur wenn alle Teilnehmer zustimmen, leitet der Koordinator das finale Schreiben ein
4. Wenn ein Teilnehmer fehlschlägt, werden die Transaktionen zurückgesetzt
5. Die Ressourcen werden danach wieder freigegeben

Commit-request Phase

• Koordinator sendet ein prepare an alle Teilnehmer
• Koordinator wartet auf Antworten aller Teilnehmer
• Teilnehmer verarbeiten die Transaktion bis zu dem Punkt, wo die Transaktion entweder mit commit oder rollback abgeschlossen würde
• Teilnehmer schreiben Einträge in ihr undo log und in ihr redo log
• Teilnehmer antworten mit ready, wenn die Transaktion erfolgreich war – oder sie antworten mit failed, wenn die Transaktion fehlgeschlagen ist

Commit Phase

Alle Teilnehmer sind ready

1. Der Koordinator sendet commit an alle Teilnehmer
2. Die Teilnehmer schließen die Transaktion mit commit ab und geben alle Locks und Ressourcen frei
3. Die Teilnehmer senden ein acknowledgment zurück
4. Der Koordinator beendet die Transaktion, wenn er von allen Teilnehmern die Bestätigung erhalten hat

Wenn mindestens ein Teilnehmer failed ist

1. Koordinator sendet abort an alle Teilnehmer
2. Die Teilnehmer schließen die Transaktion mit rollback ab (mittels des undo logs) und geben alle Locks und Ressourcen frei
3. Die Teilnehmer senden ein acknowledgment zurück
4. Der Koordinator beendet die Transaktion ebenso mit rollback, wenn er von allen Teilnehmern die Bestätigung erhalten hat

Quorum Algorithmen

• Bildung von Untermengen auf denen Lese- und Schreiboperationen realisiert werden
• Im Hintergrund kann dann später noch aktualisiert werden
• Bei Timeouts kann es zu Deadlocks kommen

Fehlersemantik

Typ	Request wird im Fehlerfall	Filterung empfangener Duplikate	Notiz
maybe	Nicht noch einmal verschickt	Keine Behandlung
at-least-once	Noch einmal verschickt	Nein	Die entfernte Prozedur wird bei einem empfangenen Duplikat wiederholt ausgeführt (nur empfehlenswert für idempotente Operationen)
at-most-once	Noch einmal verschickt	Ja	Duplikate werden gefiltert, entweder komplette Ausführung des Auftrags, oder Fehlermeldung
exactly-once	Noch einmal verschickt	Ja	Duplikate werden ebenfalls gefiltert. Weiterhin wird auch bei Ausfall des Systems die Ausführung des Auftrags über den Wiederanlauf hinaus gewährleistet. In einigen Büchern wird jedoch angegeben, dass exactly-once bei verteilten Systemen nicht möglich ist.

Idempotente Operation

einzahlen(Wert, Eindeutige ID);

Wie kann man Fehler behandeln?

• Auftrag bzw. Nachricht einfach wiederholen
• Zwischenspeicherung der Nachrichten beim Server und nochmal schicken (auf Anfrage)
• Neustart des Servers und Clients wiederholen Anfragen mittels exponential backoff
• Server schickt vorläufige Antwort mit Status

exponential backoff

• Exponentiell steigendes Intervall
• Nachricht wird nach 1, 2, 4, 8, 16, .. neu gesendet