1 / 12

Optimize Data Access with Object Caching in Distributed Systems

Learn about caching mechanisms and object replication techniques in distributed systems to improve data access efficiency. Explore snoopy cache, distributed shared memory, and object caching for seamless collaboration between processes.

hien
Télécharger la présentation

Optimize Data Access with Object Caching in Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 6.2 Objektpufferung (caching) = dynamische, ad-hoc-Replikation einer Primärkopie: Zugriffswilliger beschafft sich temporär eine lokale Kopie cacheoder Pufferspeicher = Bereich zum Unterbringen lokaler Kopien im Prozessor: Register, z.B. für Teil des Kellers im Prozessor: Hauptspeicherpuffer für Speicherblöcke im Arbeitsspeicher: Rahmen für Seiten aus Externspeicher im Dateisystem: Text- und Bilddateien von Webserver vs6.2

  2. Cache Cache Cache Zugriff auf Adresse a veranlasst Caching des Blocks, der a enthält; gegebenenfalls wird dafür ein anderer Blockverdrängt 6.2.1 Snoopy Cache (auch snooping cache) in Mehrprozessorsystemen Objekt = Speicherblock Operation = Lese/Schreibzugriff auf Speicherzelle Implementierung: Hardware Prozessoren Speicher (Primärkopien) . . . . . . . Bus vs6.2

  3. Schreibzugriff: 1. Block wird im Cache modifiziert. 2. Block wird im Speicher modifiziert (write-through). 3. Alle Prozessoren sind „neugierig“ (snoopy): sie „schnüffeln“ (to snoop) am Bus, bekommen den Schreibvorgang mit (vgl. Ethernet-Rundruf!) und ändern ihre Kopien (falls vorhanden) entsprechend.  Cache Coherence = Sequentielle Konsistenz wegen Totalordnung des HW-Rundrufs (!) Variante: Kopie löschen statt ändern (somit „write-invalidate statt write-update“, und somit mehr passive als aktive Replikation), reduziert den Schreibverkehr vs6.2

  4. 6.2.2 Verteilter Virtueller Speicher(distributed shared memory, DSM) • Kooperation mit anderen Prozessen durch Zugriff auf gemeinsamen Speicherbereich • "echter" gemeinsamer Speicher nur begrenzt realisierbar • Laufzeitsystem sorgt für transparenten Datenabgleich • Probleme: Konsistenz, effiziente Implementierung Objekt = Seite (gemäß Adressabbildungs-Hardware, MMU) Operation = Lese/Schreibzugriff auf Speicherzelle Implementierung: Software (Betriebssystem) vs6.2

  5. im Vergleich zur Kommunikation über Nachrichten • kein Marshalling (auf Benutzerseite) • Verwendung von Zeigern • Möglichkeit der Persistenz, asynchrone Kooperation • keine geschützten Adressräume • Kommunikationsaufwand im Code nicht sichtbar vs6.2

  6. Implementierung • auf System mit seitenorientiertem virtuellen Speicher oder auch spezieller Hardware • write-invalidate, d.h. mit Löschen obsoleter Kopien,sonst müsste jeder(!) Schreibzugriff auf eine replizierte Seite über Betriebssystem und Netz gehen) • somit mit passive Replikation • ohne feste Primärkopie • mögliches Problem: thrashing ("Seitenflattern") vs6.2

  7. Beispielsystem: Ivy(Li/Hudak 1986, Yale) • Rechner mit seitenbasierter MMU, Seiten können mit Rechten "none", "read-only" oder "read-write" versehen werden • Versucht ein Prozess P auf eine Seite zuzugreifen, für die er nicht genügend Rechte hat, erzeugt er eine Seitenfehler. Dieser wird vom DSM-Laufzeitsystem abgefangen, die Seite mit den entsprechenden Rechten besorgt und der letzte Befehl von P neu gestartet vs6.2

  8. für eine Seite gilt: • ein Prozess hat Schreibzugriff, alle andere haben keinen Zugriff, oder • ein oder mehrere Prozesse haben Lesezugriffe, weitere können Leserecht anfordern • Ein Prozess ist Eigentümer der Seite, entweder der eine schreibende oder einer der lesenden Prozesse, dies ist die "Primärkopie" • Ein oder mehrere Prozesse mit einer gültigen Kopie der Seite bilden die Kopiemenge vs6.2

  9. Prozess P führt Schreibzugriff aus;sofern er noch kein Schreibrecht hat: • Seitenfehler • P wird Eigentümer der Seite • Seite wird bei alle Prozessen der Kopiemenge entwertet;Kopiemenge ist jetzt {P} • Seite wird mit Schreibrecht bei P platziert • letzte Anweisung von P wird neu gestartet vs6.2

  10. Prozess P führt Lesezugriff aus;sofern er noch kein Leserecht hat: • Seitenfehler • Seite vom Eigentümer mit Leserecht zu P kopiert • Kopiemenge erweitert um P • letzte Anweisung von P neu gestartet • gewährleistet sequentielle Konsistenz Details und weitere DSM-Systeme: Coulouris et al.: Verteilte Systeme vs6.2

  11. 6.2.3 Programmiersprachlich definierte Objekte(object caching) Objekt: auf der Halde, mit oder ohne Datenabstraktion Operation: gemäß Schnittstelle bzw. Typsystem der Sprache Implementierung: Software (Laufzeitsystem oder Middleware (8)) • Anwendungsprogrammierung ohne expliziten Umgang mit Nachrichten • Laufzeitsystem versendet um empfängt die notwendigen Nachrichten vs6.2

  12. Beispiele • Tupel in einem Tupel-Raum (z.B. Linda, JavaSpaces) • Kooperation über gemeinsamen Tupel-Raum • Prozesse können Tupel lesen, hinzufügen und löschen • unterschiedliche Tupel-Typen("müller", 5938) ("pi", 3.14) (27, 13) • Adressierung der Tupel durch "Suchanfrage"<name, id> = take <string, 5938> • Abstrakte Daten-Objekte: • Fernaufruf(remote invocation, 8.1) vs6.2

More Related