Seite 5 - Redis

Redis TTL-Werte bestimmen nicht nur, wann ein Key verschwindet, sondern beeinflussen direkt die Systemlast beim Ablauf. Wer Tausende Keys mit identischer TTL setzt, riskiert einen Thundering-Herd-Effekt, bei dem alle Caches gleichzeitig leerlaufen und das Backend mit Anfragen ueberfluten. TTL-Jitter loest genau dieses Problem.

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.

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.

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.

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.

Redis Geo-Commands speichern Koordinaten nicht in einer eigenen Datenstruktur, sondern in einem gewoehnlichen Sorted Set mit einem speziell kodierten Score. Wer diesen Mechanismus versteht, kann Umkreissuchen, Store-Locator-Funktionen und Distanzberechnungen mit wenigen Befehlen umsetzen, ganz ohne zusaetzliche Geodatenbank.

Redis Keyspace Notifications verwandeln jede Schreiboperation und jeden Key-Ablauf in ein Pub/Sub-Event, auf das beliebig viele Consumer reagieren koennen. Statt teures Polling gegen den Datenbestand zu betreiben, abonniert eine Anwendung genau die Aenderungen, die sie interessieren, und baut so reaktive Architekturen ohne zusaetzliche Message-Queue.

Eine Rangliste mit tausenden Spielern klingt nach einem Sortier- und Skalierungsproblem, ist mit Redis Sorted Sets aber eine Datenstruktur, die genau dafuer gebaut wurde. ZADD, ZRANK und ZREVRANGE liefern Ranking, Umgebungsabfragen und Top-N-Listen in logarithmischer Zeit, ohne dass die Anwendung selbst sortieren oder cachen muss.