Redis — In-Memory-Caching für Websites und Shops
Redis ist die Geschwindigkeitsschicht hinter den Websites, Shops und Marktplätzen, die auf 4buildsite entstehen: Es hält genau die Daten im Arbeitsspeicher (RAM), die sofort ausgeliefert werden müssen — zwischengespeicherte Seiten, Sitzungen, Warenkörbe, Ratenbegrenzungen — und antwortet in unter einer Millisekunde. Die Quelle der Wahrheit bleibt PostgreSQL; Redis schützt sie bei hohem Traffic. Es ist enthalten und wird von der Plattform verwaltet, ganz ohne Konfiguration Ihrerseits.
Was Redis ist und warum es so schnell ist
Redis (REmote DIctionary Server) ist eine quelloffene In-Memory-Datenbank: Sie hält die Daten im RAM statt auf der Festplatte und antwortet daher in unter einer Millisekunde. Auf 4buildsite nutzen wir sie als Beschleunigungsschicht vor PostgreSQL — für alles, was sofort ausgeliefert werden muss: Seiten, Sitzungen, Warenkörbe und Ratenbegrenzungen.
Anders als eine Festplatte ist RAM um Größenordnungen schneller, und Redis ergänzt native Datenstrukturen (String, Hash, Liste, Set, Sorted Set, Stream), die komplexe Operationen direkt im Speicher erlauben, ohne den Umweg zur Hauptdatenbank. Die Befehlsverarbeitung läuft single-threaded, das Verhalten ist also vorhersehbar und frei von Race Conditions.
- Typische Latenz unter 1 ms und über 100.000 Operationen pro Sekunde auf einem einzigen Knoten
- Native Strukturen: Hashes für Sitzungen, Sorted Sets für Ranglisten und Rate Limiting, Streams für Queues
- Single-threaded bei Befehlen → vorhersehbares Verhalten, ohne komplexe Blockaden
Caching: Ihre Seiten und Daten, aus dem Speicher ausgeliefert
Die Strategie ist Cache-aside: Die erste Anfrage liest aus PostgreSQL und legt das Ergebnis mit einer TTL (Lebensdauer) in Redis ab; die folgenden Anfragen holen es direkt aus dem Speicher. Wenn Sie eine Seite bearbeiten, wird der Schlüssel ausdrücklich gelöscht — wir liefern niemals veraltete Daten über eine blinde TTL aus.
Für eine Unternehmenswebsite oder einen Shop bedeutet das, dass Produktlisten, Menüs, beliebte Seiten und Inhaltsfragmente selbst bei hohem Traffic ausgeliefert werden, ohne die Datenbank zu überlasten. In Spitzenzeiten (eine Kampagne, Black Friday) fängt Redis die wiederholten Anfragen ab.
- Cache-aside mit ausdrücklicher Invalidierung — keine veralteten Daten
- Speichert Seitenfragmente und Query-Ergebnisse, nicht nur ganze Seiten
- Schützt PostgreSQL bei Trafficspitzen und senkt die Antwortzeiten
Sitzungen, Warenkorb und Schutz vor Missbrauch
Benutzersitzungen und Refresh-Tokens liegen in Redis: schnelle Authentifizierung, automatischer Ablauf per TTL und sofortiger Widerruf auf allen Geräten, sobald sich jemand abmeldet oder das Passwort ändert.
Der Warenkorb der auf 4buildsite gebauten Shops liegt für nicht angemeldete Besucher in Redis — mit Ablauf und ohne die Hauptdatenbank aufzublähen. Ebenfalls Redis setzt das Rate Limiting auf Kontaktformularen und beim Login um, mithilfe von Sorted Sets, um Spam und Brute-Force-Versuche zu stoppen, bevor sie die Datenbank erreichen.
- Session Store mit automatischem Ablauf und selektivem Widerruf der Tokens
- Persistenter Warenkorb mit TTL für anonyme Besucher
- Rate Limiting und Missbrauchsschutz bei Formularen und Anmeldung
Echtzeit und Hintergrund-Queues
Redis Pub/Sub und Streams treiben die Echtzeitaktualisierungen an: ein Bestand, der live sinkt, eine Benachrichtigung in der Anwendung, ein sich ändernder Bestellstatus — alles, ohne dass die Besucherin die Seite neu laden muss und ohne wiederholtes Polling, das den Server ermüdet.
Schwere Aufgaben (die Verarbeitung eines Bildes, die Erzeugung eines Exports, eine Synchronisation) landen in einer Redis-Queue und werden von Workern im Hintergrund ausgeführt, damit die Besucherin eine Antwort erhält. Ein verteilter Sperrmechanismus stellt sicher, dass ein kritischer Vorgang nicht zweimal läuft.
- Pub/Sub und Streams für Live-Ereignisse (Bestand, Bestellungen, Benachrichtigungen)
- Job-Queues für schwere Verarbeitungen, die asynchron laufen
- Verteiltes Locking für Vorgänge, die nicht zweimal laufen dürfen
Vorteile und Grenzen
Vorteile
- Antwort in unter 1 ms: zwischengespeicherte Daten werden aus dem Speicher ausgeliefert
- Senkt die Last auf PostgreSQL bei hohem Traffic drastisch
- Native Strukturen für Sitzungen, Warenkorb, Rate Limiting und Ranglisten
- Pub/Sub und Streams für Echtzeitfunktionen, ohne Polling
- Job-Queues für schwere Verarbeitungen, ohne die Besucher aufzuhalten
- Enthalten und von der Plattform verwaltet — null Konfiguration für Sie
Grenzen
- Die Daten liegen im RAM, das teurer ist als Festplattenspeicher → nichts für riesige Mengen selten genutzter Daten
- Es ist ein Cache bzw. eine Hilfsschicht, nicht die Quelle der Wahrheit — die dauerhaften Daten bleiben in PostgreSQL
- Die Persistenz (RDB/AOF) verringert das Risiko, die letzten Sekunden bei einem Absturz zu verlieren, beseitigt es aber nicht vollständig
- Erfordert eine saubere Invalidierungsstrategie, sonst kann es veraltete Daten ausliefern
Kurzes Fazit
Nutzen Sie Redis für alles, was sofort da sein muss — Caching, Sitzungen, Warenkorb, Rate Limiting, Echtzeit und Job-Queues. Setzen Sie es nicht als Hauptdatenspeicher ein; dafür bleibt PostgreSQL zuständig. Auf 4buildsite haben Sie beide, automatisch aufeinander abgestimmt: Sie müssen weder wählen noch etwas konfigurieren.
Technische Daten
| Fähigkeit | Detail | Einsatz im Builder |
|---|---|---|
| Latenz | < 1 ms (In-Memory) | Seiten und Daten aus dem Speicher ausgeliefert |
| Durchsatz | > 100.000 Operationen/s je Knoten | Hoher Traffic, ohne dass die Datenbank einbricht |
| Datenstrukturen | String, Hash, List, Set, Sorted Set, Stream | Sitzungen, Warenkorb, Ranglisten, Queues, Rate Limiting |
| Persistenz | RDB-Snapshot und AOF-Log | Schnelle Wiederherstellung nach einem Neustart |
| Ablauf | TTL je Schlüssel | Warenkorb, Sitzungen und Cache mit Selbstreinigung |
| Echtzeit | Pub/Sub und Streams | Live-Bestand, Benachrichtigungen, Bestellstatus |
Redis (Cache) im Vergleich zur reinen Datenbanklösung
| Kriterium | Mit Redis | Nur PostgreSQL |
|---|---|---|
| Antwortzeit bei wiederholten Daten | unter 1 ms, aus dem Speicher | zig Millisekunden, eine Abfrage bei jeder Anfrage |
| Bei hohem Traffic | Datenbank geschützt, skaliert leicht | Datenbank staut sich, Timeouts drohen |
| Warenkorb und Sitzungen | schnell, mit automatischem Ablauf | wachsende Tabellen, die die Datenbank belasten |
| Echtzeit | Pub/Sub und Streams von Haus aus | wiederholtes Polling, teuer |
| Job-Queues | nativ, einfach zu nutzen | improvisierte Lösungen oder gar keine |
Häufige Fragen
Was ist Redis, kurz gesagt?
Eine ultraschnelle In-Memory-Datenbank, die als Schicht für Cache, Sitzungen und Echtzeit vor der Hauptdatenbank sitzt. Sie antwortet in unter einer Millisekunde.
Warum nicht einfach nur PostgreSQL?
PostgreSQL ist die Quelle der Wahrheit (dauerhafte Daten), aber Redis liefert wiederholt abgefragte Daten in unter einer Millisekunde und übernimmt Warenkorb, Sitzungen, Rate Limiting und Echtzeit; damit schützt es die Datenbank bei hohem Traffic. Die beiden arbeiten zusammen.
Verliere ich Daten, wenn Redis ausfällt?
Nicht die Inhalte der Website: Die dauerhaften Daten liegen in PostgreSQL. In Redis stehen nur Cache und temporäre Daten, und die Persistenz per RDB/AOF verringert die Verluste. Ein Neustart von Redis berührt Ihre veröffentlichte Website nicht.
Muss ich Redis selbst konfigurieren?
Nein. Es ist enthalten und wird von der Plattform 4buildsite verwaltet; Sie profitieren von der Geschwindigkeit und den Echtzeitfunktionen, ohne etwas administrieren zu müssen.
Wie hilft Redis einem Onlineshop?
Warenkorb für Besucher, zwischengespeicherte Produktlisten, live aktualisierter Bestand und Missbrauchsschutz an der Kasse und bei Formularen — alles, ohne die Datenbank zu belasten.
Wie wirkt sich Redis auf die Antwortzeit des Servers aus?
Zwischengespeicherte Daten kommen aus dem Arbeitsspeicher statt aus einer Datenbankabfrage, sodass der Server das erste Byte schneller ausliefern kann; die Zeit bis zu diesem ersten Byte misst die Kennzahl TTFB (Time to First Byte).