Was ist Redis? Caching, Sessions und wann man es braucht

Redis ist ein quelloffener Key-Value-Datenspeicher, der Daten im Arbeitsspeicher (RAM) statt auf der Festplatte hält. Kurz gesagt: Der häufigste Einsatz ist das Caching. Indem häufig gelesene und teuer berechnete Ergebnisse vor der Hauptdatenbank in Redis liegen, sinken die Antwortzeiten und die Datenbank wird entlastet. Redis ersetzt die Hauptdatenbank nicht, sondern ist eine schnelle Schicht davor.

Was ist Redis und wie funktioniert es?

Redis speichert jeden Wert unter einem Schlüssel: Der Wert von "product:42" kann ein JSON-Text sein, der Wert von "cart:alice" eine Liste. Weil aus dem Speicher gelesen wird, dauert ein einzelner Lesevorgang meist weniger als eine Millisekunde. Neben einfachen Strings bietet Redis Datenstrukturen wie Listen, Sets, Sorted Sets, Hashes und Streams. Deshalb dient es nicht nur als Cache, sondern auch als Zähler, Rangliste und einfache Queue. Jeder Schlüssel kann eine Lebensdauer (TTL) bekommen; läuft sie ab, wird der Schlüssel automatisch gelöscht.

Redis kann auch auf die Festplatte schreiben (RDB-Snapshots und AOF-Log), ist aber von seiner Bauart her nicht der führende Datenspeicher. Daten, die nicht verloren gehen dürfen, etwa Bestellungen, Zahlungen und Benutzerkonten, gehören in eine relationale Datenbank; bei der Wahl hilft unser Artikel PostgreSQL oder MySQL. Redis hält eine schnell lesbare Kopie dieser Daten.

Wofür ist ein Cache gut?

Jedes Mal, wenn eine Produktseite geöffnet wird, gehen dieselben Abfragen erneut an die Datenbank. Ein Cache bewahrt eine Kopie des Ergebnisses für kurze Zeit auf und beantwortet die folgenden Anfragen daraus. Der Gewinn wirkt in zwei Richtungen: Der Nutzer erhält schneller eine Antwort, und die Datenbank muss dieselbe Arbeit nicht tausendfach erledigen. Nicht jede Geschwindigkeit kommt aus dem Cache; für Bilder, JavaScript und Servereinstellungen bietet unser Artikel Wege, eine Website schneller zu machen eine breitere Liste.

Wofür wird Redis eingesetzt?

• Abfrage- und API-Cache: teure Abfrageergebnisse oder Antworten externer Dienste für eine bestimmte Zeit vorhalten.
• Session-Speicher: Wenn mehrere Server laufen, liegt die Sitzung des Nutzers an einer Stelle, die alle lesen können.
• Rate Limiting: Anfragen pro Minute für eine IP oder einen Nutzer zählen und stoppen, wer das Limit überschreitet.
• Queues und Hintergrundjobs: Aufgaben wie E-Mails, Benachrichtigungen oder Berichte einreihen und in einem eigenen Worker abarbeiten.
• Ranglisten und Zähler: Live-Punktetabellen mit Sorted Sets, Aufruf- und Like-Zähler.
• Verteilte Sperren: verhindern, dass derselbe Job gleichzeitig auf zwei Servern läuft, etwa damit nur eine Kopie einer geplanten Aufgabe ausgeführt wird.

Das Cache-Aside-Muster: Caching mit Redis einrichten

Das verbreitetste Muster ist Cache-Aside (Lazy Loading). Die Anwendung fragt zuerst Redis; ist der Wert vorhanden, gibt sie ihn zurück. Wenn nicht, liest sie aus der Datenbank, schreibt das Ergebnis mit einer TTL nach Redis und gibt es zurück. Ändern sich die Daten, wird zuerst die Datenbank aktualisiert und danach der zugehörige Schlüssel gelöscht; der nächste Lesevorgang legt frische Daten wieder in den Cache. Das folgende Node.js-Beispiel zeigt diesen Ablauf:

import { createClient } from 'redis';

const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

// Cache-aside: read from Redis first, fall back to the database on a miss.
async function getProduct(id: string, loadFromDb: (id: string) => Promise<object | null>) {
  const key = 'product:' + id;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const product = await loadFromDb(id);
  if (product) {
    // A TTL keeps stale data from living forever.
    await redis.set(key, JSON.stringify(product), { EX: 300 });
  }
  return product;
}

// On every write, the database is updated first and the cache key is removed.
async function onProductUpdated(id: string) {
  await redis.del('product:' + id);
}

Jeder Schlüssel im Cache muss zwei Fragen beantworten: Wann stirbt er von selbst (TTL), und welcher Schreibvorgang löscht ihn? Ein Schlüssel ohne Antwort auf beide zeigt Nutzern früher oder später veraltete Daten.

Die häufigsten Fehler beim Caching

• Keine TTL: Auf einem Schreibweg, bei dem die Invalidierung vergessen wurde, bleiben veraltete Daten für immer.
• Nutzerspezifische Daten unter einem gemeinsamen Schlüssel: Enthält der Schlüssel weder Nutzer noch Berechtigung, kann ein Nutzer die Daten eines anderen sehen.
• Den Cache für die einzige Kopie halten: Startet Redis neu oder verdrängt Schlüssel bei vollem Speicher, muss sich das System aus der Datenbank erholen können.
• Viele Schlüssel laufen gleichzeitig ab: Alle Anfragen landen in derselben Sekunde bei der Datenbank; ein kleiner zufälliger Aufschlag auf die TTL verteilt die Last.
• Alles cachen: Selten gelesene oder ohnehin schnelle Daten zu speichern kostet Speicher und bringt nichts.

Wann braucht man Redis und wann ist es überflüssig?

In einer Anwendung, die auf einem Server läuft, wenig Traffic hat und ohnehin schnelle Abfragen nutzt, bedeutet Redis eine weitere Komponente, die überwacht und gesichert werden muss. Zuerst sollten langsame Abfragen gemessen, fehlende Indizes ergänzt und ein einfacher Speicher-Cache im Prozess ausprobiert werden. Sinnvoll wird Redis, wenn die Anwendung auf mehreren Servern läuft und Sessions oder Cache geteilt werden müssen, wenn dieselben Daten viele Male pro Sekunde gelesen werden, wenn eine externe API langsam oder pro Anfrage kostenpflichtig ist oder wenn Rate Limiting, Queues oder verteilte Sperren nötig sind. Am praktischsten läuft Redis in der Entwicklung als Container neben der Anwendung; mehr dazu in unserem Artikel Was ist Docker.

Fazit

Redis ist ein schneller In-Memory-Key-Value-Speicher, der vor allem für Caching, Sessions, Queues und Rate Limiting genutzt wird. Gut eingerichtet wird er zum Puffer vor der Datenbank; werden TTL und Invalidierung nicht von Anfang an durchdacht, entsteht ein Problem mit veralteten Daten. Wenn Sie gemeinsam prüfen möchten, ob Ihr Projekt wirklich eine Cache-Schicht braucht, sehen Sie sich unsere Seiten zu individueller Software und Webentwicklung an oder schreiben Sie uns über das Formular Angebot anfordern.