Redis („Remote Dictionary Server") ist ein In-Memory-Datenstruktur-Server, der meist als Cache, Session Store, Queue oder Rate Limiter eingesetzt wird. Weil alles im RAM lebt, dauern Lese- und Schreiboperationen weit unter einer Millisekunde — und weil RAM endlich und flüchtig ist, dreht sich operativ fast alles darum, wie Sie Speicherlimits, Persistenz und Failover handhaben.

Die Lizenznotiz, die in keine 2026er-Bewertung fehlen darf: Redis verließ im März 2024 mit dem Wechsel auf RSALv2/SSPLv1 die Open Source, was den Valkey-Fork der Linux Foundation auslöste — heute der Motor hinter mehreren Managed-Angeboten. Redis 8 (Mai 2025) ergänzte die OSI-anerkannte AGPLv3 und brachte Redis selbst zurück zur Open Source. Praktisch wählen Sie zwischen Redis 8+, Valkey oder einem Managed Service, der eines von beidem betreibt; die Befehle und Konzepte unten gelten für alle.

Wofür wird Redis benutzt?

Derselbe Motor deckt erstaunlich viele Jobs ab. Die häufigsten Redis-Einsatzfälle in Produktion:

  • Caching — der Klassiker: heiße Datenbankergebnisse oder gerenderte Fragmente mit TTL im RAM halten und Leselatenz wie Datenbanklast senken.
  • Session-Speicherung — Nutzersessions für Web-Apps, geteilt über alle Applikationsserver.
  • Rate Limiting — atomare Zähler mit Ablauf machen Limits pro Nutzer oder IP zu einer Sache weniger Befehle.
  • Queues und Messaging — Lists und Streams tragen Job-Queues und Event-Pipelines (mit Consumer Groups für Fan-out).
  • Leaderboards und Zähler — Sorted Sets erledigen Ranking, Scoring und Top-N-Abfragen nativ.
  • Echtzeit-Features — Pub/Sub für Chat, Benachrichtigungen und Live-Dashboards.

Datenstrukturen

Redis ist im Kern Key-Value, aber die Werte sind typisierte Strukturen: Strings, Hashes, Lists, Sets, Sorted Sets (Leaderboards, Prioritätsqueues), Streams (Append-only-Logs mit Consumer Groups), dazu Bitmaps und HyperLogLogs. Jeder Schlüssel kann eine TTL tragen — das macht Redis zum natürlichen Cache.

Eviction-Policies: die Einstellung, die Produktion umwirft

Erreicht der Speicher maxmemory, entscheidet die Eviction-Policy, was passiert. Der Default ist noeviction: Schreibvorgänge schlagen fehl — und ist maxmemory gar nicht gesetzt, wächst der Prozess, bis der Kernel ihn OOM-killt. Für einen reinen Cache wollen Sie fast immer allkeys-lru (oder allkeys-lfu); die volatile-*-Varianten evicten nur Schlüssel mit TTL. Das ist keine theoretische Sorge — wir haben einen Produktionsausfall durch die Default-noeviction-Policy dokumentiert.

Persistenz: RDB und AOF

Redis bietet zwei Persistenzmechanismen. RDB nimmt planmäßige Snapshots: kompakte Dateien und schnelle Neustarts, aber ein Crash verliert alles seit dem letzten Snapshot. AOF (Append-only File) loggt jeden Schreibvorgang, typischerweise einmal pro Sekunde gefsynct, und begrenzt den Verlust auf etwa eine Sekunde — zum Preis größerer Dateien und langsamerer Neustarts. Produktionssetups, denen die Daten wichtig sind, kombinieren häufig beides. Die Designfrage ist simpel: Ein wegwerfbarer Cache kann ganz ohne Persistenz laufen; ein Session Store, eine Queue oder ein Rate Limiter nicht — wenn der Verlust des Datensatzes jemanden aufwecken würde, konfigurieren und testen Sie Persistenz.

Hochverfügbarkeit: Sentinel und Cluster

Replikation ist in Redis asynchron; ein Failover kann Schreibvorgänge verlieren, die der alte Primary bestätigt, aber nie ausgeliefert hat — designen Sie dafür. Darüber gibt es zwei HA-Modi. Sentinel ergänzt Monitoring und automatischen Failover für ein Primary/Replica-Set; der Datensatz muss auf einen Knoten passen. Redis Cluster shardet Daten über 16.384 Hash-Slots auf mehrere Knoten und skaliert Speicher und Schreibdurchsatz — mit der Einschränkung, dass Multi-Key-Operationen Schlüssel im selben Slot treffen müssen. Wählen Sie Sentinel, wenn Sie Verfügbarkeit für einen Ein-Knoten-Datensatz brauchen; Cluster, wenn Daten oder Schreiblast einen Knoten wirklich übersteigen.

Typische Fehlermuster

  • Cache Stampede. Ein Redis-Neustart oder massenhafter TTL-Ablauf schickt jeden Request gleichzeitig direkt zur Datenbank. Dieses Muster haben wir in einem Cache-Ausfall gesehen, der die Datenbank dahinter tötete. Mit TTL-Jitter, Request Coalescing und Warm-up abmildern.
  • Hot Keys und Big Keys. Ein stark genutzter Schlüssel nagelt die Last auf einen Knoten, und Befehle wie KEYS oder das Laden eines riesigen Sets blockieren den Single-Thread-Event-Loop für alle.
  • Den Cache als Source of Truth behandeln. Liegt die einzige Kopie der Daten ohne getestete Persistenz und Backups in Redis, ist das kein Cache — sondern eine uneingestandene Datenbank.

Schnellstart

Mit Pythons redis-py-Client:

import redis

r = redis.Redis(host="localhost", port=6379, db=0, decode_responses=True)
r.set("greeting", "hello", ex=60)  # 60 Sekunden TTL
print(r.get("greeting"))           # hello

Beachten Sie decode_responses=True — ohne kommen Werte als rohe Bytes zurück (b'hello').

Häufige Fragen

Ist Redis eine Datenbank oder ein Cache?

Beides, je nach Konfiguration. Redis ist ein vollwertiger In-Memory-Datenspeicher: Mit aktivierter Persistenz (RDB/AOF) und Replikation kann er für geeignete Workloads als Primärdatenbank dienen. In der Praxis betreiben ihn die meisten Teams als Cache oder Session Store vor einer diskbasierten Datenbank — entscheidend ist, die Rolle festzulegen und die Persistenz passend zu konfigurieren.

Was für eine Datenbank ist Redis? Ist sie relational?

Redis ist ein NoSQL-In-Memory-Key-Value-Store — genauer ein Datenstruktur-Server. Er ist nicht relational: keine Tabellen, kein SQL, keine Joins. Daten modelliert man über Schlüssel, die auf typisierte Strukturen zeigen (Hashes, Lists, Sets, Sorted Sets, Streams).

Wofür steht Redis, und wer hat es erschaffen?

Redis steht für REmote DIctionary Server. Es wurde 2009 von Salvatore Sanfilippo („antirez") geschaffen und ist in C geschrieben — einer der Gründe für seine Geschwindigkeit.

Wie funktioniert Redis?

Redis hält den gesamten Datensatz im RAM und verarbeitet Befehle in einem überwiegend single-threaded Event-Loop; Operationen dauern Mikrosekunden, ohne Lock-Contention. Haltbarkeit kommt aus optionalen Snapshots (RDB) und einem Append-only-Schreiblog (AOF); Verfügbarkeit aus asynchroner Replikation mit Sentinel- oder Cluster-Failover.

Redis oder Memcached — was nehmen?

Memcached ist ein einfacherer, multi-threaded reiner Cache; er genügt, wenn Sie nur flaches Key-Value-Caching brauchen. Redis ergänzt typisierte Datenstrukturen, Persistenz, Replikation, Transaktionen, Lua-Scripting und Pub/Sub — deshalb ist es die Standardwahl geworden. Wenn Sie je mehr als GET/SET mit TTL brauchen könnten, starten Sie mit Redis (oder Valkey).

Redis belohnt Teams, die es als echte Infrastruktur behandeln: maxmemory und Eviction-Policy bewusst setzen, Persistenz am Wert der Daten ausrichten, Speicher und Replikations-Lag überwachen. Sizing, HA-Design und die Wahl von Managed Redis/Valkey sind Alltagsarbeit unserer Cloud-Engineering-Practice.

Läuft das bei Ihnen in Produktion? Unser AWS-Managed-Services-Team betreibt solche Umgebungen 24/7 — Monitoring, Incident Response, Patching und Kostenkontrolle durch benannte Senior Engineers, ab €3.000/Monat.

Tags: #Redis #Datenbank #Caching #Performance