Sessiesopslag en leaderboard-patronen

Een vaste TTL betekent dat de sessie N seconden na het aanmaken verloopt, ongeacht de activiteit. Een verschuivende TTL (waarbij de vervaldatum bij elke toegang wordt verlengd) is gebruiksvriendelijker: de sessie verloopt N seconden na de laatste toegang. Implementeer een verschuivende TTL in Redis door bij elke geslaagde sessieleesbewerking EXPIRE (of EXPIREAT) aan te roepen op de sessiesleutel om het aftellen opnieuw in te stellen. Zo worden actieve gebruikers nooit onverwacht uitgelogd, terwijl inactieve sessies automatisch verlopen en geheugen vrijmaken.

Een winkelwagentje voor e-commerce past goed bij Redis. Elk winkelwagentje wordt opgeslagen als een Redis Hash, waarbij het veld de SKU van het product is en de waarde de hoeveelheid. Hash-bewerkingen zoals HINCRBY en HDEL maken atomische updates mogelijk zonder het volledige winkelwagentje op te halen en opnieuw te schrijven. In combinatie met een TTL (om verlaten winkelwagentjes na 24 uur te laten verlopen) biedt Redis een snelle, persistente opslag voor winkelwagentjes zonder de overhead van een relationele database voor elke gebeurtenis waarbij een product aan het winkelwagentje wordt toegevoegd.

Een ranglijst in realtime is een klassiek gebruiksscenario voor Redis, mogelijk gemaakt door gesorteerde sets (ZSETs). Elke speler heeft een score; de gesorteerde set houdt de leden voortdurend in oplopende volgorde van score. Query's voor ranglijsten (de bovenste N spelers, de rang van een speler en spelers binnen een scorebereik) hebben een complexiteit van O(log n) of O(log n + m) — extreem snel, zelfs bij miljoenen spelers. Gesorteerde sets in Redis vormen de basis van veel rangschikkingsfuncties voor games, fitness en sociale toepassingen, zonder dat je een complexe databasequery nodig hebt of de rang bij elke weergave opnieuw moet berekenen.

Twee veelgebruikte functies van ranglijsten naast 'de top 10 tonen' zijn de rang van een speler tonen en spelers in de buurt van een bepaalde speler tonen. Met gesorteerde sets in Redis zijn beide eenvoudig. ZREVRANK geeft de op nul gebaseerde rang van een speler in aflopende volgorde van score terug. Als je 5 spelers boven en onder een speler wilt tonen, haal je eerst diens rang op en gebruik je vervolgens ZREVRANGE van rang-5 tot rang+5. Zo krijg je met twee Redis-opdrachten een gepersonaliseerde ranglijstweergave — complexe SQL-vensterfuncties zijn niet nodig.

Verzoeklimieten instellen (beperken hoeveel verzoeken een client binnen een tijdsvenster kan doen) is nog een waardevol gebruiksscenario voor Redis. Het algoritme voor een schuivend venster gebruikt een gesorteerde set waarin elk lid een tijdstempel van een verzoek is. Bij elk verzoek worden leden die ouder zijn dan het venster verwijderd, de overgebleven leden geteld, het verzoek geweigerd als de telling de limiet overschrijdt en een nieuwe tijdstempel toegevoegd. Hiermee implementeer je nauwkeurige verzoeklimieten met een resolutie van milliseconden — veel nauwkeuriger dan tellers met een vast venster en zonder de overhead van een database.

Gedistribueerde vergrendelingen coördineren exclusieve toegang tot een gedeelde bron over meerdere applicatieservers. De Redis-opdracht SET key value NX EX ttl biedt atomische vergrendelingsverwerving: de sleutel wordt alleen ingesteld als die niet bestaat (NX = Not eXists) en er wordt een TTL ingesteld om deadlocks te voorkomen als de houder crasht. Wanneer de bewerking is voltooid, verwijdert de houder de sleutel. Het Redlock-algoritme (waarbij meerdere Redis-knooppunten voor een quorum worden gebruikt) biedt een robuustere gedistribueerde vergrendeling, maar maakt de oplossing complexer. Voor de meeste gebruiksscenario's is een vergrendeling op één Redis-knooppunt voldoende.

Zowel ElastiCache Redis als DynamoDB kan sessiegegevens opslaan, maar ze hebben verschillende voor- en nadelen. ElastiCache Redis: latentie van microseconden, in het geheugen (vluchtig tenzij persistentie is ingeschakeld), eenvoudiger gegevensmodel, vereist een VPC. DynamoDB: latentie van enkele milliseconden (DAX kan Redis evenaren), volledig beheerd zonder cluster dat je moet onderhouden, standaard duurzaam, wereldwijd toegankelijk met Global Tables, serverloos met capaciteit op aanvraag. Voor het SAA-C03-examen geldt: als de vraag de nadruk legt op latentie van microseconden of complexe bewerkingen in het geheugen, kies je Redis. Als de nadruk ligt op duurzaamheid, serverloos werken of wereldwijde schaal, overweeg je DynamoDB.

Redis heeft een ingebouwd geospatiaal gegevenstype (GEO-opdrachten) dat breedtegraad- en lengtegraadcoördinaten opslaat en nabijheidsquery's mogelijk maakt. Met GEOADD, GEODIST en GEORADIUS (in Redis 6.2 nu GEOSEARCH) kun je alle locaties binnen een bepaalde straal van een punt vinden in O(n + log n) tijd. Gebruiksscenario's zijn onder meer: chauffeurs in de buurt vinden (ritdelen), restaurants binnen 5 km vinden en zoekresultaten op afstand sorteren. Zo heb je geen aparte geospatiale database nodig en blijven locatiequery's werken met de snelheid van gegevens in het geheugen.

Een HyperLogLog is een probabilistische gegevensstructuur die het aantal unieke elementen in een set schat met een vaste hoeveelheid geheugen (12 KB in Redis), ongeacht hoeveel unieke items worden toegevoegd. De standaardfout is ongeveer 0,81%. Gebruik PFADD om elementen toe te voegen en PFCOUNT om de schatting op te vragen. Dit is ideaal voor het tellen van dagelijks actieve unieke gebruikers, unieke paginaweergaven of unieke IP-adressen wanneer exacte aantallen niet nodig zijn en geheugenefficiëntie belangrijk is. Miljoenen unieke gebruikers-ID's opslaan als een Redis Set zou GB's aan geheugen gebruiken; HyperLogLog gebruikt 12 KB.

In deze les heb je geleerd dat opslag van Redis-sessies stateless horizontaal schalen mogelijk maakt doordat alle instanties toegang krijgen tot gedeelde sessiestatus met een latentie van minder dan een milliseconde, dat gesorteerde sets in Redis ranglijsten in realtime mogelijk maken met rangquery's van O(log n), en dat gespecialiseerde gegevenstypen in Redis (HyperLogLog voor unieke tellingen, GEO voor nabijheid en gedistribueerde vergrendelingen) veelvoorkomende architectuurproblemen efficiënt oplossen. Hiermee is de cursus Caching met ElastiCache voltooid — hierna bekijken we architecturen met hoge beschikbaarheid en fouttolerantie.