Verteilte Transaktionen Flashcards
ACID Eigenschaften
Atomicity
Alle Datenänderungen werden wie eine einzige Operation verarbeitet. Dies bedeutet, dass entweder alle Änderungen durchgeführt werden oder keine.
In einer Anwendung, die Geldsummen von einem Konto auf ein anderes transferiert, stellt die Eigenschaft ‘atomicity’ beispielsweise sicher, dass nach dem Abbuchen der Geldsumme von einem Konto, die entsprechende Gutbuchung auf dem anderen Konto vorgenommen wird.
Consistency
Wenn eine Transaktion beginnt und wenn eine Transaktion endet, befinden sich die Daten in einem konsistenten Zustand.
In einer Anwendung, die Geldsummen von einem Konto auf ein anderes Konto transferiert, stellt die Eigenschaft ‘consistency’ beispielsweise sicher, dass die Gesamtsumme der Geldmittel auf beiden Konten am Anfang und am Ende jeder Transaktion gleich ist.
Isolation
Der Übergangszustand einer Transaktion ist für andere Transaktionen nicht sichtbar. Dies führt dazu, dass Transaktionen, die gleichzeitig ablaufen, wie serialisierte Transaktionen wirken.
In einer Anwendung, die Geldsummen von einem Konto auf ein anderes Konto transferiert, stellt die Eigenschaft ‘isolation’ beispielsweise sicher, dass eine andere Transaktion die transferierten Geldsummen jeweils nur auf einem der beiden Konten wahrnimmt und nicht auf beiden bzw. keinem der beiden Konten.
Durability
Nachdem die Transaktion erfolgreich abgeschlossen ist, bleiben die Datenänderungen erhalten und werden nicht rückgängig gemacht, selbst wenn ein Systemausfall auftritt.
In einer Anwendung, die Geldsummen, von einem Konto auf ein anderes Konto transferiert, stellt die Eigenschaft ‘durability’ beispielsweise sicher, dass die auf den beiden Konten vorgenommenen Änderungen nicht rückgängig gemacht werden.
• Erläutere den Ablauf des XA/2PC-Protokolls.
Das Protokoll ist ein verteilter Algorithmus zur konsistenten Beendigung einer Transaktion in einer verteilten Umgebung
Garantiert ACID
Protokoll verläuft in zwei Phasen: Vorbereitungsphase und Festschreibungsphase
Wird von einem Koordinator Prozess durchgeführt
Was sind Nachteile des XA/2PC-Protokolls?
Blocking Protocol –> Deadlocks
Blockiert die Ressource während sie benutzt wird
Eng gekoppelte Ressourcen
Wie hilft die Einführung einer „Prepare to Commit Phase“ bei 3PC zur Vermeidung
des Blocking-Problems?
The main motivation for the 3PC algorithm is to address the fact that two-phase commit protocol is blocking in case of a site (site means coordinator or participant) failure.
The three-phase commit protocol is said to be non-blocking. The blocking nature of the two-phase commit protocol is alleviated by introducing one more phase [10]..
3PC splits the prepare state in two[2]. The rationale behind this is that the reachable final state for the participant in prepare state in 2PC is commit and abort (both possibilities). Splitting state to waiting and pre-commit in 3PC we got to the situation that there is only one final state for each of them - abort from waiting, commit from pre-commit. This new state should avoid need of the external input - ie. from coordinator.
If a participant is in pre-commit state we know that all participant acked the initial coordinator canCommit query by ack vote and they are waiting to commit. Thus the pre-commit state could be marked as “commitable”. Because of this structure participants can collectively decide the overall result of the transaction in case the coordinator fails.
3PC as non-blocking does not mean that the participants are not blocked in processing. If we think about database processing as the, let say, the most intuitive, the database has to start a local transaction and put locks on appropriate places when process the transaction and when agree to commit. Thus other operations could be blocked by this effort and needs to wait till the whole 3PC ends.
The non-blocking means that protocol can proceed despite of existence of failures.
The state transition depicted with the solid line is normal execution when no crash or error happens. The transition depicted with the dot-dash line defines state where the coordinator/participant is ready to work but it waits for responds. Message was sent (e.g. from coordinator to participant but there is no response yet, or participant waits for next command). Then after predefined time the timeout occurs and the site follows the diagram transition. The dash line defines occurrence when the site crashed and now comes to live. Depending the environment it decides to change the state appropriately. The other rules are discussed below.
The protocol defines timeouts. If the participant is not commanded by coordinator to finish the transaction in one direction (to commit or to abort) and timeout expires it follow in decision by defined rules and it’s not blocked to wait for coordinator to command.
If coordinator crashes the 3PC expects a new coordinator to be elected. Because of the protocol the new coordinator is able to finish transaction only by querying participants - without need to know the state of the original coordinator (election protocol to find a new coordinator - possible from the available participants - is up to the implementation).
The three phase commit protocol is not a salvation for all failure cases that the system can moved to. The original 3PC assume synchronous networks of fail-stop model. Fail-stop means that a fail can be caused only by crashing a node. There is no network partitions[6] or asynchronous communication (the model with partitions is called fail-recover).
• Was sind Anwendungsfälle des SAGA-Patterns?
Entwurfsmuster zur Bewältigung des Problems von Verteilten Transaktionen
Von ACID mit einer DB zu ACD mit verschiedenen Datenquellen –> 2PC Nachteile
Datenkosistenz zwischen Services ohne Verteilte Transaktionen
Asynchrone Nachrichten
Umsetzung –> ist eine Logik aus den einzelnen Schritten der SAGA
Umsetzung mittels Choreographie oder Orchestrator
Der Hauptvorteil des Saga-Musters besteht darin, dass es dazu beiträgt, die Datenkonsistenz über mehrere Dienste hinweg ohne enge Kopplung aufrechtzuerhalten
Erläutere das SAGA-Pattern. Skizziere hierzu auch ein konkretes Beispiel einer
Microservice-Architektur
Vorteile und Nachteile Choreographie
+ Einfachheit der Implementation
+ lose Kopplung
- schwieriger nachzuvollziehen
- zirkuläre Abhängigkeiten
- Gefahr von enger Kopplung
Vorteile und Nachteile Orchestrator
+ einfachere Abhängigkeiten
+ geringere Kopplung
+ Verbesserte Separation of Concerns
- Gefahr der Zentralisierung
• Was ist eine Pivot-Transaktion? Gebe auch ein konkretes Beispiel.
In Saga-Mustern gilt:
Kompensierbare Transaktionen sind Transaktionen, die möglicherweise rückgängig gemacht werden können, indem eine weitere Transaktion mit dem gegenteiligen Effekt verarbeitet wird.
Pivot-Transaktionen sind der Go-/No-Go-Punkt in einer Saga. Wenn die Pivot-Transaktion committet wird, wird das Saga-Muster bis zum Abschluss ausgeführt. Bei einer Pivot-Transaktion kann es ich um eine Transaktion handeln, die weder kompensiert noch wiederholt werden kann, oder es handelt sich um die letzte kompensierbare Transaktion oder die erste wiederholbare Transaktion in der Saga. (e.g. Bezahlung bei SHop durchegangen)
Wiederholbare Transaktionen sind Transaktionen, die auf die Pivot-Transaktion folgen und garantiert erfolgreich sind.
Saga - potentielle Probleme
Verminderte “Isolation” als Herausforderung
Anomalien auf Grund von Fehlender Isolation
Lost Updates
Dirty Reads
Fuzzy Reads
Fehler (Error) als Challenge
Compensatable Transactions
• Nenne ein Beispiel einer Kompensationstransaktion.
Reuest Reservation Action for Aribnb
Welche Anomalien können bei SAGA entstehen? (Lost Updates, Dirty Read,
Nonrepeatable Read)
Verlorenes Update (auch englisch lost update) bezeichnet in der Informatik einen Fehler, der bei mehreren parallelen Schreibzugriffen auf eine gemeinsam genutzte Information auftreten kann. Wenn zwei Transaktionen dieselbe Information verändern, dann können die Änderungen der ersten sofort durch die Änderungen der zweiten überschrieben werden.
Unter dem Dirty-Read-Problem (unsauberes Lesen) versteht man, dass eine Transaktion den veränderten Wert einer anderen Transaktion liest, ohne zu erkennen, dass die Daten nach einem UPDATE oder DELETE noch nicht mit einer COMMIT -Anweisung in der Datenbank bestätigt wurden.
Nichtwiederholbares Lesen oder Non-Repeatable Read bezeichnet in der Informatik ein Problem, das auftritt, wenn innerhalb einer Transaktion die gleiche Leseoperation nacheinander unterschiedliche Ergebnisse liefert.
Verlorene Updates, wenn eine Saga schreibt, ohne die Änderungen einer anderen Saga zu lesen
Dirty Reads, wenn eine Transaktion oder Saga Updates liest, die von einer Saga vorgenommen wurden, die diese Updates noch nicht abgeschlossen hat
Ungenaue/nicht wiederholbare Lesevorgänge, wenn verschiedene Saga-Schritte verschiedene Daten lesen, weil ein Datenupdate zwischen den Lesevorgängen auftritt
Gegenmaßnahmen, um Anomalien zu verhindern
Folgende Gegenmaßnahmen werden empfohlen, um Anomalien zu reduzieren oder zu verhindern:
Semantische Sperren: Dabei handelt es sich um eine Sperre auf Anwendungsebene, bei der eine kompensierbare Saga-Transaktion einen Semaphor verwendet, um anzugeben, dass ein Update ausgeführt wird.
Kommutative Updates: Diese Updates können in einer beliebigen Reihenfolge ausgeführt werden und führen zum selben Ergebnis.
Pessimistische Ansicht: Eine Saga kann Dirty Reads für Daten durchführen, während eine andere Saga eine kompensierbare Transaktion zum Durchführen eines Rollbacks für den Vorgang ausführt. Die pessimistische Ansicht ordnet das Saga-Muster neu an, damit zugrunde liegende Datenaktualisierungen in einer wiederholbaren Transaktion durchgeführt werden, wodurch die Wahrscheinlichkeit von Dirty Reads entfällt.
Erneutes Lesen von Werten: Hiermit wird überprüft, ob die Daten unverändert sind. Dann wird der Datensatz aktualisiert. Wenn der Datensatz Änderungen aufweist, werden die Schritte abgebrochen und das Saga-Muster kann neu gestartet werden.
Eine Versionsdatei zeichnet die Vorgänge in einem Datensatz auf, sobald diese eingehen, und führt diese in der richtigen Reihenfolge aus.
Nach Wert: Bei dieser Gegenmaßnahme wird das Geschäftsrisiko der einzelnen Anforderungen verwendet, um den Parallelitätsmechanismus dynamisch auszuwählen. Anforderungen mit geringem Risiko bevorzugen Saga-Muster, während Anforderungen mit hohem Risiko verteilte Transaktionen bevorzugen.
