Brockhaus

Erfahrene Programmierer haben es sicherlich schon erkannt: Memcached arbeitet intern mit einem Wörterbuch (Dictionary, bei einigen Programmiersprachen auch als Assoziatives Array bezeichnet). Ähnlich wie ein reales Wörterbuch speichert diese Datenstruktur jeden Wert unter einem bestimmten Schlüssel(-wort). Das Memcached-System realisiert dieses Dictionary mit zwei hintereinander geschalteten Hashtabellen [5] : Zunächst nimmt die Client-Bibliothek den Schlüssel und errechnet aus ihm mit einer ausgeklügelten, mathematischen Funktion eine Zahl, den so genannten Hashwert. Diese Nummer sagt der Bibliothek, an welchen Memcached-Daemon sie sich wenden muss. Nachdem dieser alle Daten erhalten hat, errechnet er mit einer eigenen Hashfunktion die Speicherstelle, unter der er die Daten schließlich einlagert. Die mathematischen Funktionen sind dabei so gestaltet, dass sie zu einem ganz bestimmten Schlüssel immer dieselbe Nummer ausspucken. Diese Arbeitsweise erlaubt extrem kurze Such- und Antwortzeiten: Um eine Information wieder aus dem Cache zu ziehen, muss das memcached-System lediglich wieder die beiden mathematische Funktionen auswerten. Den größten Teil der Antwortzeit schluckt somit die Datenübertragung im Netz.

Da jedoch die Client-Bibliothek bestimmt, welcher Daemon welche Daten speichert, sind auf allen beteiligten Maschinen die gleichen Bibliotheken in der gleichen Version nötig. Bei gemischtem Betrieb kann es sonst vorkommen, dass die Clients unterschiedliche Hashfunktionen nutzen und somit die gleiche Information auf unterschiedlichen Servern landet, was wiederum zu Inkonsistenzen und komplett durcheinander gewürfelten Daten führt. Wer die C- und C++-Bibliothek »libmemcached« verwendet, muss sogar besonders aufpassen, da diese mehrere Hashfunktionen zur freien Auswahl stellt.

Darüber hinaus verwendet jeder Client eine andere Methode zur Serialisierung. Unter Java kommt beispielsweise Hibernate zum Einsatz, während PHP seine Objekte über »serialize« speichert. Sobald also nicht mehr nur einzelne Zeichenketten, sondern ganze Objekte im Cache landen sollen, wird eine gemeinsame Nutzung aus verschiedenen Sprachen heraus unmöglich – selbst dann, wenn alle Clients die gleiche Hashfunktion verwenden würden. Als Sahnehäubchen obendrauf dürfen die Bibliotheken die Daten noch mit einem beliebigen Verfahren komprimieren.

Gedächtnisschwund

Im Gegenzug bedient der Cache auch parallele Abfragen ohne Geschwindigkeitsverlust. Im Theater können mehrere Garderobieren gleichzeitig durch die Gänge flitzen und Mäntel auf- und abhängen, ohne dass eine auf die andere warten müsste. Genau das gleiche gilt hier für memcached: Jeder Client berechnet selbst, welchen Daemon er anfunken muss, im Idealfall rennt jede Garderobiere in einen anderen Gang. Allerdings verhindert auch niemand, dass die hilfreichen Damen munter ineinander laufen: Holt man Daten aus dem Cache, manipuliert diese und schreibt sie wieder zurück, so garantiert niemand, dass diese Daten nicht zwischenzeitlich von einer anderen Instanz geändert wurden. Abhilfe schaffen seit Version 1.2.5 die Kommandos »gets« und »cas« : Holt der Anwender per »gets« Daten ab, erhält er zusätzlich noch eine eindeutige ID (den Unique Identifier). Diese schickt er später zusammen mit den überarbeiteten Daten per »cas« -Befehl wieder Richtung Server. Dort stellt der Daemon anhand der ID fest, ob die Daten seit der letzten Abfrage noch unversehrt sind und überschreibt sie erst bei einer positiven Antwort mit dem neuen Wert.

Wie Memcached mit einem komplett ausgefallenen Server umgeht, hängt ebenfalls maßgeblich vom Client ab. Standardmäßig verhält er sich so, als wäre die gesuchte Information im Cache einfach nicht (mehr) vorhanden. Man sollte die Cache-Server somit besser ständig überwachen. Dank des modularen Aufbaus lässt sich ein solcher Daemon immerhin schnell durch einen neuen ersetzen. Dazu muss man meist neue IP-Adressen bei den Clients an-, beziehungsweise wieder abmelden. Einige Bibliotheken deklarieren dann jedoch den gesamten Cache auf einen Schlag für ungültig.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2022