Sitzungsspeicherung und Leaderboard-Muster

Herkömmliche Webanwendungen speichern Sitzungsdaten im Arbeitsspeicher des Servers. Das funktioniert mit einem einzelnen Server, scheitert jedoch bei horizontaler Skalierung: Wenn die nächste Anfrage eines Benutzers an eine andere EC2-Instance weitergeleitet wird, kennt diese Instance die Sitzung des Benutzers nicht, und der Benutzer wird abgemeldet. Sticky Sessions (Sitzungsaffinität im Load Balancer) lösen dieses Problem teilweise, verringern jedoch die Effektivität des Load Balancing. Die skalierbare Lösung besteht darin, den Sitzungsstatus in einen gemeinsam genutzten Speicher mit niedriger Latenz zu verschieben, auf den alle Instances zugreifen können – genau das bietet ElastiCache Redis.

Das Speichern von Sitzungen in Redis bietet Ihnen Folgendes: Sitzungslesevorgänge über alle Anwendungsserver hinweg in weniger als einer Millisekunde, integrierte TTLs für den automatischen Ablauf von Sitzungen, atomare Sitzungsaktualisierungen zur Vermeidung von Race Conditions sowie die Möglichkeit, eine Sitzung durch Löschen des Schlüssels sofort zu invalidieren. Die Anwendung speichert die Sitzungs-ID in einem Cookie. Bei jeder Anfrage sucht sie die Sitzungs-ID in Redis nach, um die Sitzungsdaten abzurufen. Alle Anwendungsserver verwenden dasselbe Redis, sodass jeder Server die Anfrage jedes Benutzers verarbeiten kann.

Bei einer festen TTL läuft die Sitzung unabhängig von der Aktivität N Sekunden nach ihrer Erstellung ab. Eine gleitende TTL (bei der der Ablauf bei jedem Zugriff verlängert wird) ist benutzerfreundlicher: Die Sitzung läuft N Sekunden nach dem letzten Zugriff ab. Implementieren Sie eine gleitende TTL in Redis, indem Sie bei jedem erfolgreichen Lesen der Sitzung EXPIRE (oder EXPIREAT) für den Sitzungsschlüssel aufrufen, um den Ablauf-Countdown zurückzusetzen. Dadurch werden aktive Benutzer nicht unerwartet abgemeldet, während inaktive Sitzungen automatisch ablaufen und Speicher freigeben.

Ein E-Commerce-Warenkorb eignet sich hervorragend für Redis. Jeder Warenkorb wird als Redis Hash gespeichert, wobei das Feld die Produkt-SKU und der Wert die Menge enthält. Hash-Operationen wie HINCRBY und HDEL ermöglichen atomare Aktualisierungen, ohne den gesamten Warenkorb abzurufen und neu zu schreiben. In Verbindung mit einer TTL (um verlassene Warenkörbe nach 24 Stunden ablaufen zu lassen) bietet Redis einen schnellen, beständigen Warenkorbspeicher, ohne dass für jedes Hinzufügen zum Warenkorb der Overhead einer relationalen Datenbank anfällt.

Eine Echtzeit-Rangliste ist ein klassischer Anwendungsfall für Redis, der durch Sorted Sets (ZSETs) ermöglicht wird. Jeder Spielereintrag hat einen Punktestand; das Sorted Set hält die Mitglieder jederzeit in aufsteigender Reihenfolge des Punktestands. Abfragen für Ranglisten (die besten N Spieler, der Rang eines Spielers, Spieler innerhalb eines Punktebereichs) haben eine Komplexität von O(log n) oder O(log n + m) — und sind selbst bei Millionen von Spielern extrem schnell. Redis Sorted Sets bilden die Grundlage vieler Ranglistenfunktionen für Spiele, Fitness- und soziale Anwendungen, ohne dass komplexe Datenbankabfragen oder eine Neuberechnung des Rangs bei jedem Seitenaufruf erforderlich sind.

Zwei häufige Ranglistenfunktionen über „die besten 10 anzeigen“ hinaus sind den Rang eines Spielers anzeigen und Spieler in der Nähe eines bestimmten Spielers anzeigen. Mit Redis Sorted Sets sind beide Funktionen unkompliziert. ZREVRANK gibt den bei 0 beginnenden Rang eines Spielers in absteigender Reihenfolge des Punktestands zurück. Um 5 Spieler über und unter einem Spieler anzuzeigen, ermitteln Sie zunächst dessen Rang und verwenden dann ZREVRANGE vom Rang-5 bis zum Rang+5. Dadurch erhalten Sie mit zwei Redis-Befehlen eine personalisierte Ranglistenansicht — komplexe SQL-Fensterfunktionen sind nicht erforderlich.

Ratenbegrenzung (die Beschränkung, wie viele Anfragen ein Client innerhalb eines Zeitfensters stellen darf) ist ein weiterer wertvoller Anwendungsfall für Redis. Der Sliding-Window-Algorithmus verwendet ein Sorted Set, in dem jedes Mitglied einen Anfragezeitstempel darstellt. Bei jeder Anfrage werden Mitglieder entfernt, die älter als das Zeitfenster sind, die verbleibenden Mitglieder gezählt, die Anfrage abgelehnt, wenn die Anzahl das Limit überschreitet, und ein neuer Zeitstempel hinzugefügt. Damit lässt sich eine präzise Ratenbegrenzung mit Sliding Window und Millisekundenauflösung implementieren — deutlich genauer als Zähler mit festen Zeitfenstern und ohne den Overhead einer Datenbank.

Verteilte Sperren koordinieren den exklusiven Zugriff auf eine gemeinsam genutzte Ressource über mehrere Anwendungsserver hinweg. Der Redis-Befehl SET key value NX EX ttl ermöglicht eine atomare Sperrenerfassung — er setzt den Schlüssel nur, wenn dieser nicht vorhanden ist (NX = Not eXists), und legt eine TTL fest, um Deadlocks zu verhindern, falls der Halter abstürzt. Nach Abschluss des Vorgangs löscht der Halter den Schlüssel. Der Redlock-Algorithmus (mit mehreren Redis-Knoten für ein Quorum) bietet eine robustere verteilte Sperre, erhöht jedoch die Komplexität. Für die meisten Anwendungsfälle ist eine Sperre auf einem einzelnen Redis-Knoten ausreichend.

Sowohl ElastiCache Redis als auch DynamoDB können Sitzungsdaten speichern, jedoch mit unterschiedlichen Vor- und Nachteilen. ElastiCache Redis: Mikrosekunden-Latenz, im Arbeitsspeicher (flüchtig, sofern keine Persistenz aktiviert ist), einfacheres Datenmodell, VPC erforderlich. DynamoDB: Latenz im einstelligen Millisekundenbereich (DAX kann Redis entsprechen), vollständig verwaltet, ohne dass ein Cluster gewartet werden muss, standardmäßig dauerhaft, mit Global Tables global zugänglich, serverlos mit On-Demand-Kapazität. Für die SAA-C03-Prüfung gilt: Wenn die Frage Mikrosekunden-Latenz oder komplexe Operationen im Arbeitsspeicher hervorhebt, wählen Sie Redis. Wenn sie dauerhafte Speicherung, Serverless oder globale Skalierung betont, ziehen Sie DynamoDB in Betracht.

Redis verfügt über einen integrierten georäumlichen Datentyp (GEO-Befehle), der Breiten- und Längengradkoordinaten speichert und Abfragen nach räumlicher Nähe ermöglicht. Mit GEOADD, GEODIST und GEORADIUS (in Redis 6.2 jetzt GEOSEARCH) können Sie alle Orte innerhalb eines bestimmten Radius um einen Punkt mit einer Laufzeit von O(n + log n) finden. Anwendungsfälle sind beispielsweise das Finden nahegelegener Fahrer (Ride-Sharing), das Finden von Restaurants innerhalb von 5 km oder das Sortieren von Suchergebnissen nach Entfernung. Dadurch ist keine separate georäumliche Datenbank erforderlich, und Standortabfragen behalten die Geschwindigkeit des Arbeitsspeichers.

Ein HyperLogLog ist eine probabilistische Datenstruktur, die die Anzahl eindeutiger Elemente in einer Menge mit einem festen Speicherbedarf schätzt (12 KB in Redis), unabhängig davon, wie viele eindeutige Elemente hinzugefügt werden. Der Standardfehler beträgt ungefähr 0,81 %. Verwenden Sie PFADD, um Elemente hinzuzufügen, und PFCOUNT, um die Schätzung abzurufen. Dies eignet sich ideal zum Zählen täglich aktiver eindeutiger Benutzer, eindeutiger Seitenaufrufe oder eindeutiger IP-Adressen, wenn keine exakten Zählungen erforderlich sind und Speichereffizienz eine Rolle spielt. Das Speichern von Millionen eindeutiger Benutzer-IDs als Redis Set würde GB an Speicher belegen; HyperLogLog verwendet 12 KB.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Redis-Sitzungsspeicherung ermöglicht zustandslose horizontale Skalierung, indem alle Instanzen mit einer Latenz von unter einer Millisekunde Zugriff auf einen gemeinsam genutzten Sitzungsstatus erhalten; Redis Sorted Sets ermöglichen Echtzeit-Ranglisten mit Rangabfragen in O(log n); und spezialisierte Redis-Datentypen (HyperLogLog für eindeutige Anzahlen, GEO für räumliche Nähe und verteilte Sperren) lösen gängige Architekturprobleme effizient. Damit ist der Kurs „Caching mit ElastiCache“ abgeschlossen — als Nächstes beschäftigen wir uns mit hochverfügbaren und fehlertoleranten Architekturen.