6. REPLIKATION UND KONSISTENZ

Transkript

1 6. REPLIKATION UND KONSISTENZ Replikation von Daten: um Zuverlässigkeit zu steigern oder Leistung zu verbessern Allg. Problem: Konsistenz der Repliken untereinander Plan des Kapitels: Wichtigkeit der Replikation und die Relation zur Skalierbarkeit Verschiedene Konsistenzmodelle und Implementierungsansätze Client-zentrierte Konsistenz Platzierung und Aktualisierung von Repliken: Entwurfsaspekte Konsistenz- und Caching-Protokolle c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 1

2 MOTIVATION UND PROBLEME DER REPLIKATION Replikation: um die Zuverlässigkeit des Systems zu erhöhen (Schutz der Dateien oder Fehlerkorrektur) Replikation: um die Leistung durch gleichzeitige Verarbeitung mehrerer Repliken zu erhöhen Replikation kann die Skalierbarkeit verbessern: Daten sind näher zum Prozess, dabei wird aber u. U. mehr Bandbreite verbraucht! Replikation ist nicht umsonst Konsistenzprobleme, z. B.: Web-Browser stellt eine besuchte Seite in den Cache Dadurch ausgezeichnete Zugriffszeiten bei späteren Zugriffen, aber die Kopie ist evtl. nicht aktuell! Sollte der Web-Server die Cache-Kopien verwalten, kann dies seine Gesamtleistung stark verschlechtern c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 2

3 DATENZENTRIER TE KONSISTENZ: EINFÜHRUNG Wir betrachten Datenspeicher, verteilt über mehrere Maschinen Jeder Prozess besitzt eine lokale/nahe Speicher-Kopie Konsistenz intuitiv: Beim Lesen in einem Prozess wird der zuletzt geschriebene (von evtl. anderem Prozess!) Wert gesehen Konsistenzmodell intuitiv: Vertrag zwischen den Prozessen und dem Datenspeicher Speicher liefert korrekte Werte wenn Prozesse Regeln folgen Welche Schreiboperation ist die letzte, wenn es keine globale Uhr gibt? Jedes Konsistenzmodell schränkt die Werte ein, die beim Lesen für ein Datenelement zurückgegeben werden Stärker eingeschränkte Modelle sind einfacher zu nutzen, sind jedoch schwerer zu implementieren und haben oft schwächere Leistung c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 3

4 STRENGE KONSISTENZ Strenge Konsistenz: Jede Leseoperation für ein Datenelement x gibt einen Wert zurück, der dem Ergebnis der letzten Schreiboperation für x entspricht Strenge Konsistenz ist in einem vert. System unmöglich: Prozess auf Maschine A liest x von Maschine B zur Zeit T 1 Prozess auf B schreibt x zum Zeitpunkt T 2 > T 1 Wenn T 2 T 1 = 10 9 sec und zwischen A und B mehr als 3 m sind, dann muss das Signal schneller als Licht sein, um strenge Konsistenz zu garantieren! Strenge Konsistenz widerspricht damit den Physik-Gesetzen! c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 4

5 SEQUENTIELLE KONSISTENZ Datenspeicher ist sequentiell konsistent, wenn: Das Ergebnis jeder Ausführung ist, als wären die Schreib/Lese-Operationen aller Prozesse in einer sequent. Reihenfolge ausgeführt, wobei die Operationen jedes Prozesses in der Prozessprogramm-Reihenfolge erscheinen Analog: Jede gültige Verzahnung der Lese-Schreibe-Zugriffe ist akzeptabel wenn alle Prozesse dieselbe Verzahnung sehen c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 5

6 SEQ. KONSISTENZ: ANSCHAULICH Drei nebenläufig ausgeführte Prozesse: Prozess P1 x = 1; print(y, z); Prozess P2 y = 1; print(x, z); Prozess P3 z = 1; print(x, y); Abb. 6.7: nebenläufig aus geführte Prozesse c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 6

7 SEQUENTIELLE KONSISTENZ: ERKLÄRUNG ZUM BILD Ausgabe: Ergebnisse der Print-Anweisungen Signatur: Ergebnisse der Ausgaben in der Reihenfolge: P1, P2, P3 Es gibt insgesamt 64 Signaturen, nicht alle davon sind jedoch gemäß Seq. Konsistenz erlaubt: Signatur nicht erlaubt, weill die Programmreihenfolge verletzt wäre Signatur ? 00 bedeutet, dass P1 vor dem Start von P2 und P3 bereits beendet ist 10 bedeutet, dass P2 ausgeführt worden sein muss, nachdem P1 gestartet wurde, aber bevor P3 gestartet wurde 01 bedeutet, dass P3 beendet wurde, bevor P1 gestartet wurde Widerspruch! nicht erlaubt c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 7

8 SEQUENTIELLE KONSISTENZ Sequentielle Konsistenz ist ein programmierfreundliches Modell Leistungsproblem: Es wurde bewiesen, dass, wenn die Lesezeit gleich r ist, die Schreibzeit gleich w und die minimale Paketübertragungszeit zwischen den Knoten gleich t ist, dann gilt: r + w t Mit anderen Worten, für jeden sequentiell konsistenten Speicher verschlechtert eine Änderung des Protokolls zur Verbesserung der Leseleistung die Schreibleistung, und umgekehrt Das liegt an den Einschränkungen des sequentiell konsistenten Speichers, die jedoch für viele Anwendungen viel zu streng sind Aus diesem Grund haben sich Forscher auf andere (schwächere) Modelle konzentriert c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 8

9 SCHWACHE KONSISTENZ Motivationsbeispiel: für einen Prozess im kritischen Bereich, müssen Zwischenergebnisse nicht an die Repliken kopiert werden Schwache Konsistenz erzwingt sequentielle Konsistenz auf Gruppen von Operationen. Die Gruppen werden durch Synchronisierungsvariablen abgetrennt Analogie: Ein optimierender Compiler führt eine Reihe von Operationen in Registern aus; der Zwischenzustand des Speichers ist evtl. falsch, bis er wirklich benötigt wird Nach Synchronisierung sind im Speicher die neuesten Werte c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 9

10 KONSISTENZMODELLE: ÜBERBLICK Konsistenz Streng Linearisierbarkeit Sequenziell Kausal FIFO Beschreibung Absolute Zeitreihenfolge aller gemeinsamen Zugriffe Alle Prozesse sehen alle gemeinsamen Zugriffe in derselben Reihenfolge. Die Zugriffe sind darüber hinaus gemäß einem (nicht eindeutigen) globalen Zeitstempel sortiert. Alle Prozesse sehen alle gemeinsamen Zugriffe in derselben Reihenfolge. Die Zugriffe sind nicht der Zeit nach sortiert. Alle Prozesse sehen alle kausal verknüpften gemeinsamen Zugriffe in derselben Reihenfolge. Alle Prozesse sehen Schreiboperationen voneinander in der Reihenfolge, in der sie abgesetzt wurden. Schreiboperationen von anderen Prozessen werden möglicherweise nicht immer in der Reihenfolge gesehen. Tabelle 1: Konsistenzmodelle ohne Synchronisierungsoperationen c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 10

11 Konsistenz Schwach Freigabe (Release) Eintritt Beschreibung Gemeinsam genutzte Daten sind nur dann verlässlich konsistent, nachdem eine Synchronisierung vorgenommen wurde. Gemeinsam genutzte Daten werden konsistent gemacht, nachdem ein kritischer Bereich verlassen wurde. Gemeinsam genutzte Daten, die zu einem kritischen Bereich gehören, werden konsistent gemacht, sobald ein kritischer Bereich betreten wird. Tabelle 2: Konsistenzmodelle mit Synchronisierungsoperationen c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 11

12 IRGENDWANN -KONSISTENZ (eventual consistency) Vorige Konsistenz-Modelle sind datenzentriert: sie stellen eine systemweit konsistente Sicht auf einen Datenspeicher bereit Wir betrachten nun Anwendungen, wo meistens nur Lesezugriffe stattfinden Motivierende Anwendungsbeispiele: Datenbanksystem in denen nur wenige Prozesse schreiben dürfen, die meisten lesen nur DNS: Jede Domain hat nur eine Namensautorität, die die Domain aktualisieren darf keine Schreib/Schreib-Konflikte Bei Lese/Schreib-Konflikten ist häufig akzeptabel, die Aktualisierung langsam weiterzugeben WWW: Inkonsistenzen bei Webseiten durch Browser-Caching oder Proxies; auch nur Lese/Schreib Konflikte, oft tolerierbar Irgendwann-Konsistenz = eventual consistency alle Repliken werden irgendwann konsistent, wenn längere Zeit keine Aktualisierungen stattfinden c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 12

13 CLIENT-ZENTRIER TE KONSISTENZ: MOTIVATION Problem mit der Irgendwann-Konsistenz: wenn der Client nicht auf dieselbe Replik zugreift, kann er seine eigenen Aktualisierungen evtl. nicht sehen Beispiel: mobiler Client (Benutzer mit Laptop) Client-zentrierte Konsistenz: garantiert Konsistenz f. jeden Client; keine Garantien für nebenläufige Zugriffe anderer Clients Es gibt mehrere verschiedene Modelle für Client-zentrierte Konsistenz, die wir hier nicht weiter betrachten, vgl. [Tanenbaum] c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 13

14 c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 14

15 VER TEILUNGSPROTOKOLLE Bisher haben wir verschiedene Konsistenz-Modelle kennengelernt, aber keine Implementierungsaspekte Jetzt befassen wir uns mit den allgemeinen Aspekten der Konsistenz-Implementierung Insbesondere: Wie man die Repliken platziert Wie die Aktualisierungen vorgenommen werden Für diverse Konsistenzmodelle c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 15

16 PLATZIERUNG DER REPLIKEN Wir unterscheiden drei verschiedene Arten von Kopien: Permanente Repliken: Ausgangsmenge, normalerweise klein, z. B. Webseiten repliziert über die Server eines Clusters Gespiegelte Webseiten (mirrored) verteilt über das Internet c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 16

17 Server-initiierte Repliken: Kopien zur Leistungssteigerung Um die Last auf einem Server zu reduzieren Um spezifische Dateien näher zu den Clients zu bringen, die diese Dateien häufig anfragen Entscheidungen (Löschen, Verschieben, etc.) werden vom Server getroffen, der Zugriffszähler für jede Datei verwaltet c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 17

18 Client-initiierte Repliken: werden auch (Client)Caches genannt werden auf der Client-Maschine oder nah dazu platziert Daten in Caches begrenzte Zeit behalten um die Anzahl der Treffer zu erhöhen, können Caches von mehreren Clients gemeinsam genutzt werden c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 18

19 DIE WEITERGABE VON AKTUALISIERUNGEN Aktualisierungsoperationen werden i. A. auf einem Client initiiert und an eine der Repliken weitergegeben Von dort sollte die Aktualisierung an alle anderen Repliken weitergegeben werden Es muss gleichzeitig die Konsistenz sichergestellt werden Im Nachfolgenden betrachten wir die wichtigsten Entwurfsaspekte, die bei Aktualisierung eine Rolle spielen c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 19

20 STATUS VS. OPERATIONEN Es gibt drei Möglichkeiten, was überhaupt weitergegeben wird Benachrichtigung über eine Aktualisierung: durch Invalidierungsprotokoll wird mitgeteilt welche Daten nicht mehr gültig sind. Vorteil: kleine Nachrichten Daten von einer Kopie auf eine andere: ist praktisch, wenn das Lese/Schreib-Verhältnis hoch ist sonst überträgt/aktualisiert man evtl. mehrmals, ohne dass dazwischen gelesen wird Aktualisierungsoperation an andere Kopien, sog. aktive Replikation. Jede Replik = ein Prozess. Vorteil: wenig Bandbreite nötig c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 20

21 PULL- VS. PUSH-PROTOKOLLE Aktualisierungen können abgeholt (pull) oder automatisch bereitgestellt (push) werden Push (auch Server-basiert genannt): häufig zw. permanenten und server-initiierten Repliken vor allem wenn hohe Konsistenz von Repliken gefordert wird hohes Lese/Aktualisierungs-Verhältnis jede Aktualisierung wird wahrscheinlich von einem/mehreren Lesern verwendet Pull (auch Client-basiert genannt): wird häufig von Client-Caches verwendet die Aktualität der Cache-Datenelemente wird überprüft, nach- dem der Client den Server nach den aktuellen Daten fragt effizient, wenn das Lese/Schreibe-Verhältnis relativ niedrig ist c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 21

22 VERGLEICH: PULL- VS. PUSH-PROTOKOLLE Es müssen mehrere Abwägungen getroffen werden Bsp.: System mit einem Server und mehreren Clients mit Caches Aspekt Push-basiert Pull-basiert Status Server am Gesendete Nachrichten Antwortzeit auf dem Client Liste mit Client-Repliken und -Caches Aktualisierung (und möglicherweise später die Aktualisierung laden) Unmittelbar (oder Laden/Aktualisierungszeit) Keine Pull und Aktualisieren Laden/Aktualisierungszeit Tabelle 3: Vergleich Push- und Pull-basierte Client-Server Systeme c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 22

23 EPIDEMISCHE PROTOKOLLE Diese Protokolle werden verwendet, um Aktualisierungen mit Irgendwann -Konsistenz weiterzugeben Aufgabe: Möglichst weniger Nachrichten zu verwenden Algorithmen sind aus der Theorie der Epidemien entstanden und verwenden die entsprechende Terminologie Server mit den zu verbreitenden Aktualisierungen heißt infektiös Server, der noch nicht aktualisiert wurde, ist empfänglich Aktualisierter Server, der seine Aktualisierung nicht weitergeben will/kann, heißt entfernt c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 23

24 GOSSIPING Gebräuchliche Variante des epidemischen Ansatzes Wenn Server P für das Datenelement X aktualisiert wurde, wendet er sich an einen beliebigen Server Q und versucht, diesem die Aktualisierung bereitzustellen, k mal Wenn Q bereits von einem anderen Server aktualisiert wurde, wird P entfernt, mit der Wahrscheinlichkeit 1/k, k Parameter Analogie: Gerüchteerzählen zwischen Freunden Gossiping ist erwiesenermassen eine gute Methode, Aktualisierungen sparsam weiterzureichen Es kann jedoch nicht garantieren, dass alle Server irgendwann aktualisiert werden Formal gezeigt: wenn der Datenspeicher aus vielen Servern besteht, dann erfährt der folgende Bruchteil von Servern nichts über eine Aktualisierung: s = e (k+1)(1 s) Für z. B. k = 3 gilt s < Man trifft spezielle Vorkehrungen, damit auch diese 2 % Server aktualisiert werden c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 24

25 KONSISTENZPROTOKOLLE Ein Konsistenzprotokoll beschreibt eine Implementierung eines spezifischen Konsistenzmodells Protokolle können nachdem klassifiziert werden, ob es eine primäre Kopie der Daten gibt, an die alle Schreiboperationen weitergegeben werden sollen In primärbasierten Protokollen ist jedem Datenelement X im Datenspeicher ein primärer Server zugeordnet Dieser Server ist verantwortlich, Schreiboperationen für X zu koordinieren Es wird unterschieden, ob die primäre Kopie auf einem entfernten Server festgelegt ist, oder ob Schreiboperationen lokal ausgeführt werden können; danach wird die primäre Kopie zu dem Prozess verschoben, wo die Schreiboperation initiiert wird c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 25

26 ENTFERNTES-SCHREIBEN-PROTOKOLL Das einfachste primärbasierte Protokoll: alle Lese- und Schreiboperationen werden auf einem einzigen entfernten Server ausgeführt: keine Repliken! c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 26

27 PRIMÄRES BACKUP-PROTOKOLL Protokolle, die Prozessen erlauben, Leseoperationen auf einer lokal verfügbaren Kopie auszuführen Schreiboperationen werden auf eine (feste) primäre Kopie weitergeben c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 27

28 ANALYSE Leistungsproblem: kann lange dauern, bis der Prozess, der die Aktualisierung initiiert hat, weitermachen kann Alternative: Nicht-blockierender Ansatz; dies ist allerdings nicht fehlertolerant Primär-Backup-Protokolle bieten eine einfache Implementierung sequentieller Konsistenz: der primäre Server kann alle eingehenden Schreiboperationen sortieren Alle Prozesse sehen alle Schreiboperationen in derselben Reihenfolge; beim blockierenden Ansatz sehen die Prozesse immer die Wirkung ihrer letzten Schreiboperation c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 28

29 LOKALES-SCHREIBEN-PROTOKOLL Es gibt eine Kopie jedes Datenelements, d. h. keine Repliken Diese Kopie wird zu dem Prozess übertragen, der eine Operation ausführen will Das Problem: Zu beobachten wo sich die Datenelemente aktuell befinden; Lösungen vgl. VL 4: Broadcast, Vorwärtszeiger, etc. c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 29

30 LOKALES-SCHREIBEN MODIFIKATION Primär-Backup: die primäre Kopie migriert zwischen Prozessen, die schreiben wollen Vorteil: mehrere Schreiboperationen nacheinander können lokal ausgeführt werden, während lesende Prozesse auf ihre lokale Kopie zugreifen Auch für mobile Computer: der Computer wird zum primären Server für Elemente, die er aktualisieren wird Nach Abbau der Verbindung werden Aktualisierungen lokal gemacht während andere Prozesse weiter lesen Bei erneuter Verbindung werden Aktualisierungen von primären Servern an die Backup-Server weitergegeben konsistenter Status c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 30

31 c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 31

32 REPLIZIER TES-SCHREIBEN-PROTOKOLL: AKTIVE REPLIKATION Operationen werden auf mehreren Repliken ausgeführt Jeder Replik ist ein Prozess zugeordnet, der Aktualisierungen ausführt Problem: Wie die Operationen überall in gleicher Reihenfolge ausführen? Ansatz (s. VL 5): vollständig sortierter Multicast Anderer Ansatz: Sequenzer ein zentraler Koordinator, an den jede Operation weitergegeben wird und der sie eindeutig sortiert sehr ähnlich den primär-basierten Konsistenzprotokollen c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 32

33 REPLIZIER TE AUFRUFE Problem: Ein repliziertes Objekt kann mehrere Aufrufe hervorrufen, durch jede Replik Das gleiche kann in jedem Client-Server System auftreten: wenn ein Server repliziert wird, kann er evtl. mehrere Anforderungen an andere senden c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 33

34 REPLIZIER TE AUFRUFE: LÖSUNG Es wird eine replikationsfähige Kommunikationsschicht bereitgestellt, auf der replizierte Objekte ausgeführt werden wenn repliziertes Objekt B ein repl. Objekt C aufruft, wird der Aufrufanforderung durch jede Replik von B dieselbe ID zugewiesen Jetzt gibt ein Koordinator der Repliken von B seine Anforderung an alle Repliken von C weiter, während die anderen Repliken von B ihre Aufrufanforderung zurückhalten Ergebnis: nur eine Anforderung wird an jede Replik von C weitergegeben Derselbe Mechanismus: um sicherzustellen, dass nur eine Antwortnachricht an die Replik von B zurückgegeben wird c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 34

35 c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 35

36 QUORUM-BASIER TE PROTOKOLLE Idee: Clients müssen Berechtigungen von mehreren Servern anfordern und erhalten, bevor sie ein repliziertes Datenelement lesen oder schreiben Z.B.: eine Datei ist über N Server repliziert, für Aktualisierung muss mehr als die Hälfte zustimmen, dann wird geändert und eine Versionsnummer zugewiesen Gifford-Schema für N Repliken: zum Lesen: N R Server, zum Schreiben: N W N R + N W > N & N W > N/2 c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 36

37 (a): Beispiel für N R = 3, N W = 10, das letzte Schreib-Quorum bestand aus 10 Servern von C bis L. Zum Lesen: Lese-Quorum muss mind. einen aus dieser Menge enthalten. Der Client betrachtet Versionsnummer und wählt mit der neuesten. (b): es kann ein Schreib/Schreib Konflikt auftreten, weil N W N/2, z.b. ein Client wählt {A,B,C,E,F,G} und anderer Client c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 37

38 wählt {D,H,I,J,K,L} als Schreibmenge, dann werden beide Aktualisierungen akzeptiert, ohne Konflikt erkannt zu haben (c): N R wird auf 1 gesetzt, es ist also möglich, eine replizierte Datei zu lesen, indem eine beliebige Kopie davon gefunden und verwendet wird. Dafür müssen jedoch Schreibaktualisierungen aller Kopien angefordert werden c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 38

39 CACHE-KOHÄRENZ-PROTOKOLLE Caches sind ein Spezialfall der Replikation: sie werden durch die Clients und nicht durch die Server kontrolliert Zwei Unterscheidungskriterien für Caching-Protokolle: Strategie zur Kohärenz-Erkennung: statisch (durch den Compiler) oder dynamisch (Überprüfen zur Laufzeit) Zeitpunkt der Überprüfung bei Transaktionen: beim Zugriff auf das Datenelement, während des Transaktionsweiterlaufs, oder beim TR-Festschreiben Strategie zur Erzwingung der Kohärenz: Caching gemeinsamer Daten verbieten Invalidierung versenden Aktualisierung weitergeben c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 39

40 ZUSAMMENFASSUNG Zwei Gründe für Replikation von Daten: höhere Zuverlässigkeit und bessere Leistung Neues Problem: Konsistenz von mehreren Repliken; Aktualisierungs-Verteilung kann die Leistung wieder reduzieren Lösung: die Konsistenz möglichst lockern: strenge sequentielle schwache Im Gegensatz zu diesen dezentralisierten Modellen Client-zentrierte Konsistenzmodelle, vor allem für mobile Clients die sich mit verschiedenen Repliken verbinden Weitergabe der Aktualisierungen unterschiedliche Techniken: Durch Benachrichtigungen, Operationen, Statuszustände Welche Replik wann aktualisiert wird Verteilungsprotokoll Werden die Aktualisierungen automatisch weitergegeben oder müssen abgeholt werden Konsistenzprotokolle spezifische Implementierung eines Konsistenzmodells: primär-basiert vs. repliziertes-schreiben c 2006 BY SERGEI GORLATCH UNI MÜNSTER VERTEILTE SYSTEME VORLESUNG 6 40