Redis kontra Memcached: Valg af den rigtige motor

Redis (Remote Dictionary Server) er et funktionsrigt datastrukturlager i hukommelsen, der bruger én tråd (pr. instans) og understøtter strenge, hashes, lister, mængder, sorterede mængder, bitmaps, HyperLogLogs, streams og geospatiale indekser. Vigtige fordele frem for Memcached er: valgfri persistens (AOF- og RDB-snapshots), replikering (læse-replikaer og automatisk failover), pub/sub-meddelelser, Lua-scripting, transaktioner (MULTI/EXEC) og klyngetilstand til horisontal partitionering. Redis er det rigtige valg i de fleste virkelige cachesituationer.

Redis understøtter to persistensmekanismer: RDB (Redis Database) — periodiske snapshots af et bestemt tidspunkt, der gemmes på disken med konfigurerbare intervaller (hurtige genstarter, men data mellem snapshots kan gå tabt). AOF (Append-Only File) — logger hver skrivehandling; ved en genstart afspiller Redis loggen for at genopbygge tilstanden (datavedholdenhed på bekostning af større filer og langsommere genstarter). I ElastiCache kan du aktivere AOF for at bevare data på tværs af genstarter af noder. Det er afgørende, når ElastiCache ikke kun bruges som cache, men som primært datalager, f.eks. til sessionsdata.

Redis understøtter replikagrupper med én primær node, der håndterer alle skrivninger, og op til 5 læse-replikaer, der håndterer læsninger. Når Multi-AZ og automatisk failover er aktiveret, promoverer ElastiCache automatisk en læse-replika til primær node, når den primære node svigter — failoveren gennemføres typisk på under 60 sekunder. Det giver Redis-baserede applikationer en høj tilgængelighed, som Memcached ikke kan matche (Memcached har ingen replikering). Til produktionsapplikationer, der kræver caching med høj tilgængelighed, skal du altid bruge Redis med automatisk failover.

Sorterede mængder er en af Redis' mest effektive datastrukturer. Hvert medlem har en tilknyttet flydende kommatals-score, og medlemmerne holdes altid i sorteret rækkefølge. Det gør sorterede mængder ideelle til ranglister (rangordning efter score), prioritetskøer (behandling af job med højest prioritet først) og hastighedsbegrænsning (glidende vindue med tidsstempler som scores). Handlingerne ZADD, ZRANGE, ZREVRANGE, ZRANK og ZRANGEBYSCORE har alle kompleksiteten O(log n) — ekstremt effektivt selv for millioner af poster.

Redis pub/sub gør det muligt for udgivere at udsende meddelelser til kanaler uden at vide, hvem der abonnerer. Abonnenter modtager i realtid alle meddelelser, der udgives til de kanaler, de abonnerer på. Pub/sub-meddelelser gemmes ikke — hvis en abonnent er offline, går meddelelsen tabt. Til vedvarende meddelelser med garanteret levering skal du bruge Redis Streams (en mere robust datastruktur, der blev tilføjet i Redis 5) eller en specialiseret meddelelsestjeneste som SQS eller SNS. Til SAA-C03-eksamen er Redis-pub/sub en mulighed for letvægtsmeddelelser i realtid mellem tjenester.

Brug denne fremgangsmåde til at vælge til SAA-C03-eksamen: Vælg Memcached, når du har brug for en enkel cache uden krav om høj tilgængelighed, flertrådet ydeevne og horisontal skalering ved at tilføje noder (ren cache). Vælg Redis, når du har brug for: persistens (sessionslager), replikering og failover (høj tilgængelighed), komplekse datatyper (sorterede mængder til ranglister, mængder og lister), pub/sub, Lua-transaktioner eller klyngetilstand til horisontal skalering med flere shards. Hvis eksamensspørgsmålet nævner en funktion ud over simpel nøgle-værdi-caching, er Redis næsten altid svaret.

ElastiCache tilbyder flere nodetypefamilier: r7g (Graviton 3, hukommelsesoptimeret — bedste pris/ydeevne-forhold, anbefales til de fleste caches), m7g (afbalanceret CPU og hukommelse) og t4g (burstable, lave omkostninger til udvikling/test). Nodestørrelserne går fra cache.t4g.micro (500 MB) til cache.r7g.16xlarge (425 GB). I produktion skal du vælge en nodestørrelse, der holder datasættet i hukommelsen med 20-25 % reserve. Hvis hukommelsen løber tør, opstår der udsættelser (Memcached) eller OOM-fejl (Redis).

ElastiCache implementeres i din VPC, hvor sikkerhedsgrupper styrer adgangen — som standard er der ingen adgang fra det offentlige internet. For Redis skal du aktivere AUTH-tokens (en adgangskode, som klienterne skal angive) og kryptering under transport (TLS) for forbindelser samt kryptering i hvile ved hjælp af KMS. For Memcached er kun TLS under transport tilgængelig (ingen kryptering i hvile eller AUTH). Når du migrerer fra ukrypteret til krypteret Redis, kan migreringen ikke foretages på stedet — du skal oprette en ny krypteret klynge og varme den op.

Når en Redis- eller Memcached-cache er fuld, bestemmer udsættelsespolitikken, hvilke nøgler der fjernes for at skabe plads. Almindelige Redis-udsættelsespolitikker er: noeviction (returnerer en OOM-fejl — velegnet, når cachen er det primære lager), allkeys-lru (udsætter de mindst nyligt anvendte blandt alle nøgler — velegnet til generelle caches), volatile-lru (LRU blandt nøgler med angivet TTL — bevarer nøgler, der ikke udløber), allkeys-random (tilfældig udsættelse) og allkeys-lfu (mindst hyppigt anvendte). Til typiske caching-scenarier anbefales allkeys-lru eller allkeys-lfu.

I denne lektion lærte du, at Memcached er enkel, flertrådet og ikke har høj tilgængelighed — bedst til ren horisontal skalering af simple caches, at Redis understøtter komplekse datastrukturer, persistens, pub/sub og Multi-AZ-failover — bedst til de fleste caching-scenarier i produktion, og at sorterede mængder gør Redis til det naturlige valg til ranglister og prioritetskøer. Næste gang udforsker vi Redis-replikagrupper og klyngetilstand til horisontal partitionering.