In-Memory Power: Redis erklärt

In diesem Blogbeitrag gehe ich auf die In-Memory Datenbank Redis ein. Ziel des Artikels ist, einen Überblick über Redis zu geben und technisches Verständnis zu schaffen.

Hier ein kurzer Überblick über die behandelten Themen:

• Was ist Redis?
• Typische Einsatzgebiete
• Zeitliche Entwicklung
• Unterstützte Datentypen
• Hauptarchitekturen
  • Redis Single-Node
  • Redis Replication
  • Redis Replication mit Sentinel
  • Redis Cluster
• Cloud-Managed Redis
• Redis im CAP-Theorem
• Persistenz-Mechanismen
• Zugriff auf Redis
• Deployment
• Vor- und Nachteile von Redis
• Fazit

Was ist Redis?

Redis ist eine In-Memory Datenbank, die weit über die klassische Key-Value Speicherung hinausgeht.

Es steht für Remote Dictionary Server und hält seine Daten im Arbeitsspeicher (RAM) statt auf der Festplatte – dadurch ist es extrem schnell. Redis zählt zur Kategorie der NoSQL-Datenbanken.

Persistenz ist optional und kann entweder periodisch über Snapshots mittels RDB (Redis Database Backup) oder über ein Append Only File (AOF) realisiert werden. Ausserdem ist es möglich, beide Mechanismen (RDB sowie AOF) zu kombinieren.

Es ist in der Programmiersprache C geschrieben (-> sehr ressourcenschonend) und bietet Clients für viele aktuelle Programmiersprachen (Python, Node.js, Go, Java, C# etc.) an.

Typische Einsatzgebiete

Zu den typischen Einsatzgebieten von Redis zählen:

• Caching
• Session Store
• Message Queues / Publish-Subscribe
• Message Brokers
• Streams
• Echtzeit-Analysen und Leaderboards
• Temporäre Datenbank

Zeitliche Entwicklung

Die folgende Tabelle zeigt die zeitliche Entwicklung von der Entstehung, bis zur Übernahme und Lizenzwechsel durch Redis Inc. sowie der Entstehung des Forks Valkey auf:

Unterstützte Datentypen

Redis bietet eine Menge verschiedener Datentypen an. Nachfolgend werden die wichtigsten Datentypen von Redis mit ein paar konkreten Use Cases aufgezeigt:

Ausserdem gibt es zahlreiche Redis-Module, welche entweder über die Redis-Distribution Redis Stack genutzt oder alternativ manuell geladen werden können.

Hier die gängigsten Redis-Module und deren Nutzen:

Hauptarchitekturen

Redis kann auf vielfältige Weise eingesetzt werden. Je nach Anforderungen an das System eignet sich eine der folgenden Hauptarchitekturen:

• Redis Single-Node
• Redis Replication (ehemals Master-Slave)
• Redis Replication mit Sentinel
• Redis Cluster

In den nachfolgenden Kapiteln wird auf die Redis-Hauptarchitekturen näher eingegangen.

Redis Single-Node

Redis als Single-Node ist die einfachste Art, Redis zu betreiben.
Hierbei ist mit Node eine einzelne Redis-Instanz gemeint.

Wichtigste Eigenschaften von Redis Single-Node:

• Eine einzige Redis-Instanz (ein Server).
• Alle Lese- und Schreiboperationen laufen über diese Instanz.
• Kein Failover (-> kein automatisches Umschalten auf ein Ersatzsystem bei einem Ausfall).
• Keine Hochverfügbarkeit.
• Komplexität: Einfach

-> Einfach, aber kein Schutz vor Ausfall.

Redis Single-Node Architektur

Redis Replication

Redis Replication wird manchmal auch Redis Primary-Replica Replication genannt (ehemals Redis Master-Slave Replication).

Wichtigste Eigenschaften von Redis Replication:

• Eine Primary-Instanz (ehemals „Master“) und eine oder mehrere Replicas (ehemals „Slaves“).
• Der Primary verarbeitet Schreib- und Leseanfragen, Replicas replizieren Daten asynchron -> eventual consistency.
• Üblicherweise wird nicht empfohlen, dass der Client direkt von den Replicas liest, aufgrund der potentiell veralteten/inkonsistenten Daten der Replicas.
• Fällt der Primary aus, muss manuell eine Replica zum neuen Primary promoted werden. Die restlichen Replicas müssen anschliessend manuell auf den neuen Primary umkonfiguriert werden.
• Komplexität: Mittel

-> Bessere Performance + Datenredundanz, aber kein automatisches Failover.

Redis Replication Architektur

Redis Replication mit Sentinel

Wichtigste Eigenschaften von Redis Replication mit Sentinel:

• Mehrere Sentinel-Instanzen (Wächter) überwachen die Redis-Server.
• Erkennt ein Sentinel, dass der Primary ausgefallen ist, wird automatisch eine Replica als neuer Primary auserkoren.
• Clients fragen Sentinels nach dem aktuellen Primary.
• Typischerweise 3 oder 5 Sentinels, da die Sentinels Entscheidungen durch Mehrheitsabstimmung (Quorum) treffen.
• Komplexität: Mittel

-> Automatisches Failover + Monitoring, hohe Verfügbarkeit.

Redis Replication mit Sentinel Architektur

Redis Cluster

Wichtigste Eigenschaften von Redis Cluster:

• Mehrere Redis-Nodes teilen die Daten über Shards (Hash-Slots) auf.
• Jeder Shard hat einen Primary + Replicas.
• Clients wissen, welcher Shard für welchen Key zuständig ist und sprechen die Nodes direkt an.
• Automatisches Failover und horizontale Skalierung.
• Komplexität: Hoch

-> Hohe Skalierbarkeit + Ausfallsicherheit.

Redis Cluster Architektur

Cloud-Managed Redis

Ebenfalls besteht die Möglichkeit, Redis über einen Cloud-Anbieter zu betreiben. Dabei muss man sich selber nicht mehr um Aspekte wie Hochverfügbarkeit, Backups, Skalierung, Sicherheit, Updates und Monitoring kümmern.

Hier eine Übersicht bekannter Anbieter und dem entsprechenden Produkt:

Bemerkung: Hinter den Kulissen eines Cloud-gemanagedem Redis läuft eine Form der oben genannten Architekturen.

Redis im CAP-Theorem

Je nach Architektur ändern sich die CAP-Eigenschaften (Consistency, Availability und Partition Tolerance).

Das CAP-Theorem besagt, dass ein verteiltes System bei Netzwerkausfällen nur zwei der drei CAP-Eigenschaften gleichzeitig garantieren kann.

Im Single-Node-Betrieb handelt es sich nicht um ein verteiltes System. Da es keine Replicas gibt und Cluster Partitionen nicht möglich sind, müssen in diesem Betrieb keine Partitionen toleriert werden. Somit wird die Eigenschaft P nicht erfüllt, jedoch A und C.

Redis Replication und Redis Replication mit Sentinel erfüllen die Eigenschaften A und P. Gibt es bspw. einen Netzwerkunterbruch zwischen dem Primary und seinen Replicas, akzeptiert der Primary trotzdem Schreibbefehle vom Client. Sollten jedoch die Daten direkt von den Replicas gelesen werden, kann die Konsistenz der Daten, aufgrund der asynchronen Replikation, nicht gewährleistet werden (-> eventual consistency).

Grundsätzlich ist Redis Cluster AP. Bei einem Quorum-Verlust zeigt es jedoch CP-Verhalten, da es Schreiboperationen stoppt, um die Konsistenz zu wahren.

Die folgende Abbildung zeigt auf, welche Redis-Architekturen welche Eigenschaften des CAP-Theorems erfüllen:

CAP-Eigenschaften der Redis-Architekturen

Persistenz-Mechanismen

Da Redis eine In-Memory Datenbank ist, muss man im Fall eines Ausfalls seiner Redis-Instanz mit einem Datenverlust rechnen. Möchte man seine Daten dennoch persistieren, so bietet Redis mehrere Persistenz-Mechanismen an:

Selbstverständlich kann Redis auch ohne Persistenz-Mechanismen betrieben werden. Dies ist standardmässig der Fall, wenn man Redis als Cache nutzt (bspw. vor einer Datenbank).

Zugriff auf Redis

Redis läuft standardmäßig auf Port 6379. Man sprichst Redis über ein einfaches Textprotokoll (RESP=Redis Serialization Protocol) oder eine Client-Library an.

Zugriff über CLI:

redis-cli
127.0.0.1:6379> SET user:1 "Anna"
OK
127.0.0.1:6379> GET user:1
"Anna"

Ausserdem bietet Redis Client-Bibliotheken für praktisch jede Sprache an:

Das folgende Code-Beispiel in Python illustriert, wie einfach es ist, Redis als Cache zu nutzen:

import redis

r = redis.Redis(host='localhost', port=6379, db=0)

# Daten cachen
r.set("user:42:name", "Anna", ex=60)  # ex = Ablaufzeit in Sekunden

# Daten abrufen
print(r.get("user:42:name"))

Deployment

Redis kann auf folgende Arten eingesetzt werden:

apt install redis-server

docker run -p 6379:6379 redis

docker run -p 6379:6379 -p 8001:8001 redis/redis-stack

Vor- und Nachteile von Redis

Nachfolgend werden die Vor- und Nachteile von Redis bezogen auf die jeweilige Kategorie aufgezeigt:

Fazit

Redis ist ein High-Performance-Baustein, ideal für Szenarien, die eine niedrige Latenz und einen hohen Datendurchsatz erfordern. Es ergänzt relationale Datenbanken perfekt, z. B. als Cache, Queue oder Echtzeit-Analytics-Backend. Redis kann lokal, in Docker Containern oder in der Cloud betrieben und über viele Programmiersprachen genutzt werden. Je nach Anwendungsfall ist es aufgrund der BSD-Lizenz sinnvoller, den Redis-Fork Valkey zu verwenden.