Sessionslagring og leaderboard-mønstre

Traditionelle webapplikationer gemmer sessionsdata i hukommelsen på serveren. Det fungerer med én server, men bryder sammen, når du skalerer horisontalt — hvis en brugers efterfølgende forespørgsel dirigeres til en anden EC2-instans, har den instans ingen viden om brugerens session, og brugeren logges ud. Sticky sessions (sessionstilknytning i load balanceren) løser kun problemet delvist, men reducerer effektiviteten af belastningsfordelingen. Den skalerbare løsning er at flytte sessionstilstanden til et delt lager med lav latenstid, som alle instanser har adgang til — og det er netop, hvad ElastiCache Redis leverer.

Hvis du gemmer sessioner i Redis, får du: sessionslæsninger på under et millisekund på tværs af alle applikationsservere, indbygget TTL til automatisk udløb af sessioner, atomare sessionsopdateringer for at forhindre kapløbstilstande og mulighed for straks at ugyldiggøre en session ved at slette nøglen. Applikationen gemmer session-id'et i en cookie; ved hver forespørgsel slår den session-id'et op i Redis for at hente sessionsdataene. Alle applikationsservere deler den samme Redis, så enhver server kan håndtere enhver brugers forespørgsel.

En fast TTL betyder, at sessionen udløber N sekunder efter oprettelsen uanset aktivitet. En glidende TTL (hvor udløbet forlænges ved hver adgang) er mere brugervenlig — sessionen udløber N sekunder efter den seneste adgang. I Redis implementerer du en glidende TTL ved at kalde EXPIRE (eller EXPIREAT) på sessionsnøglen ved hver vellykkede sessionslæsning for at nulstille nedtællingen til udløb. Det sikrer, at aktive brugere aldrig uventet logges ud, mens inaktive sessioner automatisk udløber og frigiver hukommelse.

En indkøbskurv i en e-handelsløsning passer naturligt til Redis. Hver kurv gemmes som en Redis-hash, hvor feltet er produktets SKU, og værdien er antallet. Hash-handlinger som HINCRBY og HDEL gør det muligt at udføre atomare opdateringer uden at hente og omskrive hele kurven. Kombineret med en TTL (så forladte kurve udløber efter 24 timer) giver Redis et hurtigt, persistent lager til kurve uden den ekstra belastning ved at bruge en relationsdatabase til hver eneste hændelse, hvor en vare lægges i kurven.

En leaderboard i realtid er et klassisk anvendelsesområde for Redis, som aktiveres af sorterede sæt (ZSET'er). Hver spillerpost har en score, og det sorterede sæt vedligeholder altid medlemmerne i stigende scoreorden. Forespørgsler til leaderboardet (de øverste N spillere, en spillers placering, spillere inden for et scoreinterval) har kompleksiteten O(log n) eller O(log n + m) — ekstremt hurtigt, selv med millioner af spillere. Redis' sorterede sæt er grundlaget for mange funktioner til rangordning inden for spil, fitness og sociale tjenester, uden behov for en kompleks databaseforespørgsel eller genberegning af placeringen ved hver sidevisning.

To almindelige leaderboard-funktioner ud over »vis top 10« er at vise en spillers placering og at vise spillere i nærheden af en bestemt spiller. Begge dele er trivielle med Redis' sorterede sæt. ZREVRANK returnerer en spillers nulbaserede placering i faldende scoreorden. Hvis du vil vise 5 spillere over og under en spiller, skal du hente spillerens placering og derefter bruge ZREVRANGE fra placering-5 til placering+5. Det giver en personlig leaderboard-visning med to Redis-kommandoer — der er ikke behov for komplekse SQL-vinduesfunktioner.

Begrænsning af anmodningshastighed (begrænsning af, hvor mange anmodninger en klient kan sende i et tidsvindue) er endnu et værdifuldt anvendelsesområde for Redis. Algoritmen med glidende vindue bruger et sorteret sæt, hvor hvert medlem er et tidsstempel for en anmodning. Ved hver anmodning: Fjern medlemmer, der er ældre end vinduet, tæl de resterende medlemmer, afvis anmodningen, hvis antallet overskrider grænsen, og tilføj det nye tidsstempel. Det implementerer præcis begrænsning af anmodningshastigheden med et glidende vindue og millisekundopløsning — langt mere nøjagtigt end tællere med faste vinduer og uden belastningen fra en database.

Distribuerede låse koordinerer eksklusiv adgang til en delt ressource på tværs af flere applikationsservere. Redis-kommandoen SET key value NX EX ttl giver atomisk erhvervelse af låsen — den angiver kun nøglen, hvis den ikke findes (NX = Not eXists), og angiver en TTL for at forhindre deadlocks, hvis indehaveren går ned. Når handlingen er fuldført, sletter indehaveren nøglen. Redlock-algoritmen (som bruger flere Redis-noder til at opnå et quorum) giver en mere robust distribueret lås, men øger kompleksiteten. Til de fleste anvendelsesområder er en lås på en enkelt Redis-node tilstrækkelig.

Både ElastiCache Redis og DynamoDB kan lagre sessionsdata, men de har forskellige afvejninger. ElastiCache Redis: mikrosekund-latenstid, lagring i hukommelsen (flygtig, medmindre persistens er aktiveret), enklere datamodel, kræver VPC. DynamoDB: latenstid på encifrede millisekunder (DAX kan matche Redis), fuldt administreret uden en klynge, der skal vedligeholdes, holdbar som standard, globalt tilgængelig med Global Tables, serverløs med kapacitet efter behov. Til SAA-C03-eksamen: Hvis spørgsmålet fremhæver mikrosekund-latenstid eller komplekse handlinger i hukommelsen, skal du vælge Redis. Hvis det fremhæver holdbarhed, serverløshed eller global skala, skal du overveje DynamoDB.

Redis har en indbygget geospatial datatype (GEO-kommandoer), der lagrer breddegrads- og længdegradskoordinater og muliggør nærhedsforespørgsler. Med GEOADD, GEODIST og GEORADIUS (nu GEOSEARCH i Redis 6.2) kan du finde alle positioner inden for en given radius fra et punkt på O(n + log n)-tid. Anvendelsesområder: find chauffører i nærheden (samkørsel), find restauranter inden for 5 km, og sortér søgeresultater efter afstand. Det eliminerer behovet for en separat geospatial database og holder positionsforespørgsler på hastigheder fra hukommelsen.

En HyperLogLog er en probabilistisk datastruktur, der estimerer antallet af unikke elementer i et sæt ved hjælp af en fast mængde hukommelse (12 KB i Redis), uanset hvor mange unikke elementer der tilføjes. Den har en standardfejl på cirka 0,81 %. Brug PFADD til at tilføje elementer og PFCOUNT til at hente estimatet. Det er perfekt til at tælle unikke dagligt aktive brugere, unikke sidevisninger eller unikke IP-adresser, når nøjagtige optællinger ikke er nødvendige, og hukommelseseffektivitet er vigtig. Lagring af millioner af unikke bruger-ID'er som et Redis-sæt ville bruge flere GB; HyperLogLog bruger 12 KB.

I denne lektion lærte du, at Redis-sessionslagring muliggør tilstandsløs horisontal skalering ved at give alle instanser adgang til en delt sessionstilstand med latenstid under et millisekund, at Redis' sorterede sæt driver leaderboards i realtid med placeringsforespørgsler på O(log n), og at specialiserede Redis-datatyper (HyperLogLog til optælling af unikke elementer, GEO til nærhed og distribuerede låse) effektivt løser almindelige arkitekturproblemer. Dette afslutter kurset Caching med ElastiCache — næste gang udforsker vi arkitekturer med høj tilgængelighed og fejltolerance.