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
- Koordinator (Aufrufender Prozess) fragt die Teilnehmer, ob die Transaktion gelingt
- Ein Teilnehmer blockiert seine Ressourcen nach seinem ready, bis eine Antwort vom Koordinator kommt
- Nur wenn alle Teilnehmer zustimmen, leitet der Koordinator das finale Schreiben ein
- Wenn ein Teilnehmer fehlschlägt, werden die Transaktionen zurückgesetzt
- 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
- Der Koordinator sendet commit an alle Teilnehmer
- Die Teilnehmer schließen die Transaktion mit commit ab und geben alle Locks und Ressourcen frei
- Die Teilnehmer senden ein acknowledgment zurück
- Der Koordinator beendet die Transaktion, wenn er von allen Teilnehmern die Bestätigung erhalten hat
Wenn mindestens ein Teilnehmer failed ist
- Koordinator sendet abort an alle Teilnehmer
- Die Teilnehmer schließen die Transaktion mit rollback ab (mittels des undo logs) und geben alle Locks und Ressourcen frei
- Die Teilnehmer senden ein acknowledgment zurück
- 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