Seite 8 - Redis

Redis auf Kubernetes zu betreiben klingt zunächst nach einem einfachen Deployment mit einem Image und einem Service. In der Praxis ist Redis jedoch ein zustandsbehafteter Dienst mit Replikation, Failover-Logik und persistenten Daten, und genau das passt nicht ohne Weiteres zum zustandslosen Grundmodell von Kubernetes. Ein Redis Operator schließt diese Lücke, indem er Sentinel-basiertes Failover, Pod-Identität und Speicherverwaltung als deklarative Custom Resources abbildet, statt sie manuell mit YAML-Dateien und Shell-Skripten nachzubauen. Dieser Artikel zeigt, wie ein Operator konkret arbeitet, welche StatefulSet-Eigenheiten dabei relevant werden und wo der Punkt liegt, an dem ein Managed-Service die pragmatischere Wahl ist.

Wo Redis Pub/Sub Nachrichten unwiderruflich verliert, sobald kein Subscriber lauscht, speichert ein Redis Stream jede Nachricht dauerhaft im Speicher, mit fortlaufender ID, Consumer Groups fuer verteilte Verarbeitung und expliziter Bestaetigung per XACK. Das macht Streams zur leichtgewichtigen Alternative zu Kafka fuer Event-Logs mittlerer Groessenordnung.

Datenverlust in Redis entsteht selten durch einen einzelnen offensichtlichen Fehler, sondern durch das Zusammenspiel aus fsync-Timing, Replikationsverzögerung und automatischem Failover unter Zeitdruck. Wer die konkreten Szenarien kennt, unter denen Redis tatsächlich Daten verliert, kann gezielt die richtigen Absicherungsmaßnahmen kombinieren, statt sich auf ein einzelnes Feature zu verlassen.

Klassisches Lua-Scripting mit EVAL und EVALSHA ist seit Jahren der Standardweg für atomare Serverlogik in Redis, bringt aber praktische Probleme bei Wartbarkeit, Versionierung und Replikationsverhalten mit sich. Seit Redis 7 stehen mit Redis Functions eine strukturiertere Alternative über FUNCTION LOAD zur Verfügung, die Skripte als benannte, dauerhaft gespeicherte Bibliotheken behandelt statt als flüchtige, über Hashes referenzierte Einzelskripte. Wie der Umstieg konkret aussieht, welche Vorteile er bringt und wo EVAL trotzdem die bessere Wahl bleibt, zeigt dieser Artikel.

Redis eignet sich mit dem LPUSH/BRPOP-Muster gut als einfache Task-Queue, und Streams liefern mit Consumer Groups sogar Zustellgarantien und Nachrichten-Historie. Doch beide Ansaetze stossen an Grenzen bei komplexem Routing, garantierter Reihenfolge ueber viele Consumer hinweg oder sehr hohem Nachrichtendurchsatz, wo dedizierte Systeme wie RabbitMQ oder Kafka die robustere Wahl sind.

Wer JSON-Daten bisher als String in Redis abgelegt hat, kennt das Problem: Jede noch so kleine Änderung an einem einzelnen Feld erfordert, das komplette Dokument zu laden, zu deserialisieren, zu ändern und wieder als Ganzes zurückzuschreiben. RedisJSON löst dieses Problem, indem es JSON-Dokumente als eigenen, nativen Datentyp verwaltet und über JSONPath-Ausdrücke gezielten Zugriff auf einzelne Pfade erlaubt, ohne das gesamte Dokument zu bewegen.

Diskless Replication verspricht schnellere Replica-Synchronisation, indem der RDB-Snapshot direkt über den Netzwerk-Socket statt über eine Zwischendatei auf Disk übertragen wird. Doch dieser Vorteil bringt reale Grenzen mit sich, die vor dem produktiven Einsatz verstanden werden müssen, damit ein Netzwerkproblem nicht zum vollständigen Neustart der Synchronisation führt.

Wer Requests pro Sekunde, Antwortzeiten oder Warenkorb-Events über die Zeit beobachten will, landet schnell bei einer dedizierten Time-Series-Datenbank. RedisTimeSeries bringt genau dieses Datenmodell direkt in Redis: mit automatischem Downsampling, konfigurierbaren Retention-Policies und derselben niedrigen Latenz, die Redis ohnehin für andere Datentypen bietet.

Redis Pub/Sub verteilt Nachrichten in Echtzeit an alle aktuell verbundenen Abonnenten, ohne sie zu speichern oder eine Zustellgarantie zu geben. Diese Fire-and-Forget-Semantik macht Pub/Sub ideal fuer Live-Benachrichtigungen zwischen Services, aber ungeeignet fuer alles, was Persistenz oder garantierte Zustellung braucht.

RDB-Snapshots speichern den kompletten Datenbestand eines Redis-Servers als kompakte Binärdatei zu festen Zeitpunkten. Wer save-Punkte, den BGSAVE-Fork-Mechanismus und Copy-on-Write versteht, kann Snapshot-Intervalle so konfigurieren, dass Datenverlust und Latenz-Spitzen gleichermaßen kontrolliert bleiben, statt sich auf Standardwerte zu verlassen.