Ein schneller, hochverfügbarer, robuster und skalierbarer Caching-Layer für alle Clouds
Caching verbessert die Reaktionszeit von Anwendungen, indem Kopien der meistgenutzten Daten auf einem temporären, aber sehr schnellen Speicher gelagert werden. In-Memory-Caching-Lösungen sind sehr effektiv, da die Daten nicht auf langsamen Festplatten sondern in schnellem DRAM gespeichert wird. Caching wird vor allem für die Verbesserung der Latenzzeit eingesetzt. Ein hochverfügbarer und robuster Cache kann aber auch bei der Skalierung von Anwendungen helfen. Durch das Verschieben von Aufgaben von der Anwendungsebene auf die Caching-Ebene werden Rechenressourcen verfügbar gemacht. So können mehr Anfragen bearbeitet werden.
Die meisten herkömmlichen Datenbanken sind eher auf robuste Funktionalität als auf Schnelligkeit ausgelegt. Der Datenbank-Cache wird häufig zum Speichern von Kopien von Lookup-Tabellen und für die Speicherung von Ergebnissen von langlaufenden Datenbankabfragen verwendet. Dadurch wird die Anwendungsleistung verbessert und die Datenquelle entlastet.
Das Caching von User Session Daten ist ein fester Bestandteil beim Aufbau skalierbarer und reaktionsschneller Anwendungen. Weil jede Interaktion des Benutzers einen Zugriff auf die Sitzungsdaten erfordert, verringert das Speichern dieser Daten in einem Cache die Reaktionszeit für den Benutzer der Anwendung. Es ist besser, Sitzungsdaten im Cache zu speichern als Sitzungen auf einer Loadbalancer Ebene festzuhalten. Caching ermöglicht die Bearbeitung der Anfragen durch jeden App-Server, ohne dass dabei der Benutzerstatus verloren geht. Beim Loadbalancer Ansatz hingegen werden alle Anfragen in einer Sitzung zwangsweise durch einen einzigen App-Server bearbeitet.
Moderne Anwendungen bestehen aus lose gekoppelten Komponenten, die über APIs kommunizieren. Die Anwendungskomponenten nutzen APIs um Serviceanfragen an andere Komponenten zu stellen. Dies geschieht entweder innerhalb (z. B. bei einer Microservice-Architektur) oder außerhalb der Anwendung (z. B. in einem Saas-Anwendungsfall). Selbst bei einer nur kurzfristigen Speicherung der API-Reaktion im Cache wird die Anwendungsleistung verbessert, indem diese Interprozesskommunikation vermieden wird.
Eine Caching-Ebene muss bei jeder Belastung Höchstleistung zeigen. Studien zeigen, dass die End-to-End-Reaktionszeit nicht länger als 100 Millisekunden sein darf, damit Nutzer eine Appplikationsreaktion noch als “sofort” empfinden. Eine Hochleistungs-Caching-Ebene muss also durchgehend eine hohe Durchsatzleistung bei niedriger Latenzzeit bieten, um Leistungsengpässe zu umgehen.
Eine Hochleistungs-Caching-Ebene muss in der Lage sein zu skalieren und Anfragen, die aus Geschäftswachstum oder plötzlichen Anstiegen (wie im Fall von Valentinstag, Black Friday, Naturkatastrophen oder Pandemien) resultieren, zu erfüllen. Diese Skalierbarkeit sollte dynamisch erfolgen und keinen Ausfall oder Offline-Migrationen verursachen. Auch die Reaktionszeit darf sich nicht erhöhen.
Immer mehr Unternehmen wenden Multi-Cloud-Strategien an. Entweder weil sie einen Lock-in-Effekt vermeiden wollen oder weil sie die besten Werkzeuge von verschiedenen Cloud-Anbietern gleichzeitig nutzen möchten. Es ist jedoch ziemlich kompliziert, ein geografisch verteiltes Caching-System zu verwalten, das eine Latenzzeit im Sub-Millisekundenbereich garantiert und zugleich Datensatz-Konflikte in mehreren Clouds lösen kann..
Auf diese Art wird Redis meist als Cache verwendet. Dabei inspiziert die Anwendung zuerst den Cache, um dort Daten abzurufen. Sollten keine Daten gefunden werden (Cache Miss), ruft die Anwendung die Daten direkt aus dem Haupdatenquelle bzw. dem Operational Data Store ab. Die Daten werden nur dann in den Cache geladen, wenn es erforderlich ist (deshalb wird die Methode auch Lazy Loading genannt). Anwendungen, die primär lesend auf die Daten zugreifen , können von einem Cache-Aside-Ansatz profitieren.
Bei dieser Strategie werden Daten zuerst in den Cache (z. B. Redis) geschrieben und dann asynchron im Operational Data Store aktualisiert. Dieser Ansatz verbessert die Schreibleistung und vereinfacht die Entwicklung der Anwendung, da der Entwickler nur an einem Ort ablegt (Redis). RedisGears bietet sowohl Write-Through- als auch Write-Behind-Fähigkeiten.
GitHub Demo anzeigen
Diese Strategie ähnelt dem Write-Behind-Ansatz, da der Cache zwischen der Anwendung und dem Operational Data Store sitzt. Die Updates erfolgen jedoch synchron. Das Write-Through-Muster begünstigt die Datenkonsistenz zwischen Cache und Datenspeicher, da das Schreiben auf dem Haupt-Thread des Servers erfolgt. RedisGears bietet sowohl Write-Through- als auch Write-Behind-Fähigkeiten.
GitHub Demo anzeigen
In einer Umgebung mit einer großen Menge von Verlaufsdaten (z. B. ein Mainframe) oder in der jedes Schreiben in einem Operational Data Store erfasst werden muss, können Change Data Capture-Konnektoren (CDC) von Redis Enterprise individuelle Datenänderungen erfassen und genaue Kopien der Daten zur Verfügung stellen, ohne laufende Vorgänge mit fast Echtzeit-Konsistenz zu unterbrechen. Dank der Fähigkeit von Redis Enterprise, mehrere Datenmodelle zu nutzen, kann CDC wertvolle Einblicke in Daten bieten, die vorher nicht möglich waren.
Redis als Multi-Modal DatenbankDie Anwendungsleistung beruht auf der Caching-Ebene. Da Ihr Cache in der Lage ist, Millionen von Operationen pro Sekunde zu unterstüttzen, kann selbst ein Ausfall von einer Sekunde eine deutliche Auswirkung auf die Leistung und das Erfüllen Ihrer SLAs haben. Automatische Sicherungen, sofortige Fehlererkennung, schnelle Wiederherstellung in Racks/Zonen/Regionen und mehrere Datenpersistenz-Optionen sind bei Redis Enterprise entscheidende Vorteile, um eine hochverfügbare Caching-Ebene zu garantieren und eine konsistente User Experience zu bieten.
Eine Hochleistungs-Caching-Ebene für Anwendungen muss einfach und sofort skalierbar sein, um die Wachstumsanforderungen und die Lastspitzen zu erfüllen. Die hohe Durchsatzrate bei einer Sub-Millisekunden-Latenzzeit, eine Shared-Nothing-Architektur für eine lineare Skalierung, Mandantenfähigkeit und eine Mehrkern-Architektur stellen bei Redis Enterprise sicher, dass Rechenressourcen bei höchster Leistung vollständig verwendet werden.
Unabhängig vom jeweiligen Einsatzgebiet sollte die Caching-Ebene hohe Verfügbarkeit und niedrige Latenzzeiten in allen Regionen bieten. Die CRDT-basierte Active-Active-Technologie von Redis Enterprise bietet zudem lokale Latenz für Lese- und Schreibvorgänge und einfache Konfliktlösungen für alle Datentypen. Selbst wenn eine hohe Anzahl von Kopien funktionsunfähig sind, ist Ihre Business Continuity garantiert. Das Ergebnis: weniger Entwicklungsprobleme und betriebliche Belastungen.
Es gibt viele verfügbare Lösungen, die auf Nischen-Technologien beruhen oder nur für spezifische Anwendungsfälle entwickelt sind. Redis Open-Source unterstützt über 50 Programmiersprachen, über 150 Client-Bibliotheken und ist die standardmäßige Caching-Ebene in den meisten Einsatzumgebungen. Redis ist die Firma hinter Open-Source Redis, seit nunmehr 4 Jahren in Folge die beliebteste Datenbank, und verleiht Ihrer Caching-Ebene Fähigkeiten, die die wesentlichen Unternehmensanforderungen abdecken.
Die Entwicklung einer Caching-Ebene sollte einfach und schnell und ohne zusätzliche Mehraufwand für Ihr Team erfolgen. Redis Enterprise kann als Managed Service in Public Clouds eingesetzt werden. Dadurch müssen Sie sich nicht um Support, Patching, Überwachung oder anderen Administrationsaufgaben kümmern. Es kann jedoch auch als installierbare Software in Ihrer eigenen Infrastruktur eingesetzt werden, wenn Sie die komplette Kontrolle über Management und Konfiguration haben wollen. Außerdem wird ein hybrides Modell unterstützt, um die operationale Flexibilität zu bewahren.
Redis basiert auf einer Menge von Datenstrukturen, Ihre Daten können in Strings, Hashes, Sorted Sets, Sets, Listen, Streams und anderen Datenstrukturen oder Applikations-spezifischen Datentypen, die durch Redis Module implementiert werden, gespeichert werden.
Mit Node.js kann man einfache Strings durch GET- und SET-Befehle des Client-Objekts abrufen und speichern:
// Redis Client mit lokaler Instanz verbinden. const client = redis.createClient(6379) // Einen String-Wert von Redis abrufen, wenn dieser für diese Schlüssel bereits existiert return client.get(‘myStringKey’, (err, value) => { If (value) (Wert) { console.log(‘Der mit diesem Schlüssel verknüpfte Wert ist: ‘ + Wert) } sonst { //Schlüssel nicht gefunden // Einen einfachen String im Redis Speicher speichern client.set(‘myStringKey’, ‘Redis Enterprise Anleitung’); } } });Dieser Snippet versucht, den mit der myStringKey-Schlüssel verknüpften String-Wert mit dem GET-Befehl abzurufen. Kann der Schlüssel snicht gefunden werden, speichert der SET-Befehl den Wert “Redis Enterprise Tutorial” unter dem Schlüssel myStringKey.
Derselbe Code kann in Python geschrieben werden:
# Redis Client mit lokaler Instanz to local instance. r = redis.Redis(host=’localhost’, port=6379, db=0) # Einen String-Wert von Redis abrufen, wenn er für diesen Schlüssel bereits existiert value= r.get(‘myStringKey’) If value == None: # Schlüssel nicht gefunden # Einen einfachen String i Redis speichern r.set(‘myStringKey’, ‘Redis Enterprise Tutorial’) Else: print ‘Der mit diesem Schlüssel verknüpfte Wert ist: ‘, value
