Øktlagring og mønstre for ledertavler

Tradisjonelle webapplikasjoner lagrer øktdata i minnet på serveren. Dette fungerer med én server, men bryter sammen når De skalerer horisontalt – hvis den neste forespørselen fra en bruker rutes til en annen EC2-instans, kjenner ikke den instansen brukerens økt, og brukeren blir logget ut. Klistrede økter (øktaffinitet i lastbalansereren) løser dette delvis, men reduserer effektiviteten til lastbalanseringen. Den skalerbare løsningen er å flytte økttilstanden til et delt lager med lav ventetid som alle instanser har tilgang til – og det er nettopp dette ElastiCache Redis tilbyr.

Ved å lagre økter i Redis får De: øktlesing på under ett millisekund på tvers av alle applikasjonsservere, innebygd TTL for automatisk utløp av økter, atomiske øktoppdateringer som hindrer kappløpstilstander, samt muligheten til å ugyldiggjøre en økt umiddelbart ved å slette nøkkelen. Applikasjonen lagrer økt-ID-en i en informasjonskapsel. Ved hver forespørsel slår den opp økt-ID-en i Redis for å hente øktdataene. Alle applikasjonsserverne deler samme Redis, slik at enhver server kan håndtere forespørselen fra enhver bruker.

En fast TTL betyr at økten utløper N sekunder etter opprettelsen, uavhengig av aktivitet. En glidende TTL (der utløpstiden forlenges ved hver tilgang) er mer brukervennlig – økten utløper N sekunder etter den siste tilgangen. I Redis implementerer De glidende TTL ved å kalle EXPIRE (eller EXPIREAT) på øktnøkkelen ved hver vellykkede lesing av økten, slik at nedtellingen til utløp tilbakestilles. Dette sikrer at aktive brukere aldri uventet logges ut, samtidig som inaktive økter utløper automatisk og frigjør minne.

En handlevogn i en netthandelsløsning passer naturlig til Redis. Hver handlevogn lagres som en Redis Hash, der feltet er produktets SKU og verdien er antallet. Hash-operasjoner som HINCRBY og HDEL gjør atomiske oppdateringer mulig uten å hente og skrive om hele handlevognen. Kombinert med en TTL (for å utløpe forlatte handlevogner etter 24 timer) gir Redis et raskt og varig lager for handlevogner, uten kostnadene ved å bruke en relasjonsdatabase for hver «legg i handlevogn»-hendelse.

En ledertavle i sanntid er et klassisk bruksområde for Redis, muliggjort av sorterte mengder (ZSET-er). Hver spilleroppføring har en poengsum, og den sorterte mengden holder medlemmene sortert i stigende poengsum til enhver tid. Forespørsler mot ledertavlen (de N beste spillerne, spillerens rangering, spillere innenfor et poengsumintervall) har kompleksiteten O(log n) eller O(log n + m) — ekstremt raskt, selv for millioner av spillere. Redis-sorterte mengder er grunnlaget for mange rangeringsfunksjoner innen spill, trening og sosiale tjenester, uten behov for komplekse databasespørringer eller ny beregning av rangeringen ved hver sidevisning.

To vanlige ledertavlefunksjoner utover «vis topp 10» er å vise spillerens rangering og å vise spillere i nærheten av en bestemt spiller. Begge deler er enkelt med Redis-sorterte mengder. ZREVRANK returnerer spillerens nullbaserte rangering i synkende poengsumrekkefølge. Hvis De vil vise 5 spillere over og under en spiller, henter De først rangeringen og bruker deretter ZREVRANGE fra rangering-5 til rangering+5. Dette gir en personlig ledertavlevisning med to Redis-kommandoer — uten behov for komplekse SQL-vindusfunksjoner.

Frekvensbegrensning (å begrense hvor mange forespørsler en klient kan sende i løpet av et tidsvindu) er et annet verdifullt bruksområde for Redis. Algoritmen for et glidende vindu bruker en sortert mengde der hvert medlem er et tidsstempel for en forespørsel. Ved hver forespørsel fjernes medlemmer som er eldre enn tidsvinduet, de gjenværende medlemmene telles, forespørselen avvises hvis antallet overskrider grensen, og det nye tidsstempelet legges til. Dette implementerer presis frekvensbegrensning med glidende vindu og millisekundoppløsning — langt mer nøyaktig enn tellere for faste vinduer og uten belastningen ved å bruke en database.

Distribuerte låser koordinerer eksklusiv tilgang til en delt ressurs på tvers av flere applikasjonsservere. Redis-kommandoen SET key value NX EX ttl gir atomisk låseopptakelse — den setter nøkkelen bare hvis den ikke allerede finnes (NX = Not eXists), og angir en TTL for å forhindre vranglåser hvis innehaveren krasjer. Når operasjonen er fullført, sletter innehaveren nøkkelen. Redlock-algoritmen (som bruker flere Redis-noder for å oppnå flertall) gir en mer robust distribuert lås, men øker kompleksiteten. For de fleste bruksområder er en lås på én Redis-node tilstrekkelig.

Både ElastiCache Redis og DynamoDB kan lagre øktdata, men de har ulike avveininger. ElastiCache Redis: mikrosekundforsinkelse, lagring i minnet (flyktig hvis ikke persistens er aktivert), enklere datamodell og krav om VPC. DynamoDB: forsinkelse på ensifret antall millisekunder (DAX kan matche Redis), fullstendig administrert uten en klynge som må vedlikeholdes, varig som standard, globalt tilgjengelig med Global Tables og serverløst med kapasitet etter behov. For SAA-C03-eksamen: Hvis oppgaven vektlegger mikrosekundforsinkelse eller komplekse operasjoner i minnet, velger De Redis. Hvis den vektlegger varighet, serverløs drift eller global skala, bør De vurdere DynamoDB.

Redis har en innebygd geospatial datatype (GEO-kommandoer) som lagrer breddegrads- og lengdegradskoordinater og muliggjør nærhetssøk. Ved å bruke GEOADD, GEODIST og GEORADIUS (nå GEOSEARCH i Redis 6.2) kan De finne alle steder innenfor en gitt radius fra et punkt på O(n + log n)-tid. Bruksområder er å finne sjåfører i nærheten (samkjøringstjenester), finne restauranter innenfor 5 km og sortere søkeresultater etter avstand. Dette eliminerer behovet for en separat geospatial database og holder stedssøk på hastigheten til minnebaserte operasjoner.

En HyperLogLog er en sannsynlighetsbasert datastruktur som anslår antallet unike elementer i en mengde ved å bruke en fast mengde minne (12 KB i Redis), uavhengig av hvor mange unike elementer som legges til. Den har en standardfeil på omtrent 0,81 %. Bruk PFADD for å legge til elementer og PFCOUNT for å hente anslaget. Dette passer perfekt til å telle unike daglig aktive brukere, unike sidevisninger eller unike IP-adresser når nøyaktige antall ikke er nødvendig og effektiv minnebruk er viktig. Lagring av millioner av unike bruker-ID-er som en Redis Set ville brukt flere GB; HyperLogLog bruker 12 KB.

I denne leksjonen har De lært at Redis for lagring av økter muliggjør tilstandsløs horisontal skalering ved å gi alle instanser tilgang til delt økttilstand med under millisekunds forsinkelse, at Redis-sorterte mengder driver ledertavler i sanntid med rangeringsspørringer på O(log n), og at spesialiserte Redis-datatyper (HyperLogLog for unike antall, GEO for nærhet og distribuerte låser) løser vanlige arkitekturproblemer effektivt. Dette fullfører kurset Caching with ElastiCache — neste tema er høy tilgjengelighet og feiltolerante arkitekturer.