Caching-Strategien

Bei Caching-Strategien werden üblicherweise fünf Kategorien unterschieden:

1. Beim Cooperative Caching, auch als Distributed Caching bezeichnet, bilden mehrere Einzelsysteme (üblicherweise als Cluster-Knoten) einen großen, geteilten Cache. Die Implementierung von Cooperative Caches kann recht einfach sein. Entweder werden alle Anfragen an alle Knoten gerichtet, wo nur auf die schnellste Antwort gewartet wird. Oder sie stellen ein intelligenteres Partitionierungssystem bereit, das normalerweise auf konsistentem Hashing beruht, um die Anfrage zu einem Knoten weiterzuleiten, der den angeforderten Schlüssel enthält. Cooperative Caching ist heute das übliche Verfahren bei größeren Systemen, wenn große Datenmengen gecacht werden müssen.
2. Beim Partial Caching werden nicht alle Daten im Cache abgelegt. Abhängig von bestimmten Kriterien sind die Antworten entweder nicht cachebar oder sollen nicht im Cache abgelegt werden (beispielsweise Fehler durch temporär nicht verfügbare Daten). Ein typisches Beispiel sind Websites, für die nicht alle Daten gecacht werden sollen. Einige Seiten sind “statisch” – sie ändern sich nur im Falle manueller oder routinemäßiger Eingriffe. Diese Seiten lassen sich leicht cachen und wieder im Cache auffrischen, wenn Änderungen vorgenommen worden sind. Andere Seiten bestehen vorwiegend aus dynamischen oder häufig aktualisierten Inhalten (zum Beispiel Aktienkurse) und sollten daher gar nicht gecacht werden.
3. Beim Geographical Caching befinden sich einzelne Caches zur Verkürzung von Latenzzeiten an strategischen Orten. Diese Art von Cache wird daher meist für Inhalte von Websites verwendet. Er wird auch als CDN (Content Delivery Network) bezeichnet. Ein geografischer Cache greift transparent auf einen zentralen Cache zu, der als Hauptquelle für Inhalte und lokal abgerufene Daten dient. Dieses Konzept eignet sich gut für statische Inhalte oder Inhalte, die sich weniger häufig ändern. Die regionalen Caches können normalerweise kleiner als der zentrale Cache sein, da bestimmte Caches auf Regionen mit unterschiedlichen Sprachen oder kulturellen Unterschieden spezialisiert sind. Geographical Caching wird zudem häufig in Verbindung mit Partial Caching verwendet, um statische Inhalte (wie beispielsweise Bilder, Ton, Videos und so weiter) so nah wie möglich am Ort der Abfrage zwischenzuspeichern, während dynamische Inhalte mithilfe unterschiedlicher Routen oder Regelmechanismen (Forwardern) erstellt werden. Der geografisch nächstgelegene Cache wird häufig durch Georouting anhand von IP-Adressen (DNS-Routing) oder mithilfe von Proxies ermittelt, die die Anfragen mithilfe des HTTP-Statuscodes 302 an bestimmte IP-Adressen weiterleiten.
4. Beim Preemptive Cache handelt es sich streng genommen um keinen eigenständigen Typ. Er wird vorwiegend als geografischer Cache realisiert. Ein Preemptive Cache wird zu Beginn mit einer sogenannten “Warm-up Engine” mit Daten befüllt. Sie aktualisiert sich selbst anhand bestimmter Regeln oder Ereignisse. Dem liegt die Idee zugrunde, Daten aus einem Back-End-Service oder aus einem zentralen Cluster zu laden, bevor sie tatsächlich benötigt werden. So bleiben die Zugriffszeiten für die gecachten Elemente konstant. Außerdem werden unzumutbar lange Wartezeiten beim Zugriff auf einzelne Elemente vermieden. Der Aufbau eines Preemptive Cache erfordert gute Kenntnisse der betreffenden Domäne und der Update-Workflows.
5. Beim Latency SLA Cache verfolgt man das Ziel, maximal erlaubte Antwortzeiten auch dann zu gewährleisten, wenn der Cache langsam oder überlastet ist. Es gibt zwei Möglichkeiten, den Preemptive Cache zu realisieren. Im ersten Fall muss ein Timeout überschritten werden, bevor das System entweder das potenziell gecachte Element aus der ursprünglichen Quelle abruft (parallel zur bereits laufenden Cache-Abfrage) oder eine einfache Standardantwort gibt. Verwendet wird dann das, was zuerst vorliegt. Im zweiten Fall werden beide Abfragen parallel abgesetzt. Die zuerst vorliegende Antwort wird verwendet. Dies ist allerdings nicht die bevorzugte Implementierungsform, da sie der Idee des Cache eigentlich zuwiderläuft und das Back-Endsystem nicht entlastet. Sie lässt sich allerdings sinnvoll einsetzen, wenn mehrere Caching-Ebenen vorhanden sind, also wenn beispielsweise immer versucht wird, den ersten und zweiten nächstgelegenen Cache parallel zu verwenden.

Bei Hazelcast handelt es sich um eine Plattform für Datenpartitionierung und verteiltes Computing. Mit anderen Worten: um ein In-Memory Data Grid. Ein Hazelcast-Cluster bildet ein Peer-zu-Peer-Netzwerk mit Verbindungen zwischen allen Mitgliedern. Hazelcast-Clients verbinden sich selbstständig mit allen Mitgliedern und entscheiden anhand einer Cluster-Partitionstabelle, an welche Knoten die Daten weitergeleitet werden. Das unterbindet unnötige Roundtrips. Ein als Cache verwendeter Hazelcast-Cluster ist daher immer ein Cooperative Cache auf Basis mehrerer Mitglieder. Die JCache-Schicht von Hazelcast dient vorzugsweise für das Caching in Java-Anwendungen. Sie implementiert die neue Java Temporary Caching API, definiert in der Spezifikation JSR 107. Die Verwendung eines definierten Java-Standards erleichtert den Austausch der Implementierung und bringt Unabhängigkeit von einer einzelnen Firma.

Hazelcast zeichnet sich durch Flexibilität, einfache Implementierung und hohe Leistung aus. Das macht Hazelcast zur ersten Wahl bei quelloffenen Caching-Lösungen mit Zehntausenden installierter Cluster. Hazelcast unterstützt führende Unternehmen, wie Capital One, Chicago Board Options Exchange, Deutsche Bank, Ellie Mae und Mizuho Securities USA, bei der Verwaltung ihrer Daten und verteilten Verarbeitungsprozesse mithilfe von In-Memory-Techniken und Parallelisierung zur Erzielung von Spitzenleistungen bei Geschwindigkeit und Skalierung von Anwendungen.