ElastiCache Redis-replikeringsgrupper og klyngemodus
Bygg en Redis-replikeringsgruppe for skalering av lesing, og aktiver klyngemodus for å dele data på tvers av flere nodegrupper
ElastiCache Redis-replikeringsgrupper og klyngemodus er en gratis leksjon i Cloud & IT Cert Prep på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Cloud & IT Cert Prep, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.
Oversikt over Redis-replikeringsgrupper
En ElastiCache-replikeringsgruppe er en logisk gruppering av én primær Redis-node og opptil 5 lesereplikaer. Primærnoden håndterer alle skriveoperasjoner. Replikaene mottar asynkron replikering fra primærnoden og betjener lesetrafikk. Replikeringsgrupper muliggjør to viktige funksjoner: skalering av lesing (fordeling av leseforespørsler mellom flere replikaer) og høy tilgjengelighet med automatisk failover (en replika gjøres til primærnode hvis primærnoden svikter). Alle nodene i en replikeringsgruppe deler det samme datasettet.
# Create a replication group with 1 primary and 2 read replicas
aws elasticache create-replication-group \
--replication-group-id web-cache \
--replication-group-description 'Web application cache' \
--num-cache-clusters 3 \
--cache-node-type cache.r7g.large \
--engine redis \
--engine-version '7.0' \
--automatic-failover-enabled \
--multi-az-enabled \
--cache-subnet-group-name my-multi-az-subnet-groupPrimært endepunkt kontra leserendepunkt
ElastiCache tilbyr to DNS-endepunkter for en replikeringsgruppe: det primære endepunktet peker alltid til den aktuelle primærnoden (oppdateres automatisk under failover) — bruk dette for alle skriveoperasjoner. Leserendepunktet fordeler leseforespørsler mellom alle tilgjengelige replikaer — bruk dette for leseoperasjoner for å fordele belastningen. Applikasjonen Deres bør opprettholde to tilkoblingspooler: én for det primære endepunktet til skriving og én for leserendepunktet til lesing. Dette er det anbefalte tilkoblingsmønsteret for ElastiCache Redis-replikeringsgrupper.
# Get primary and reader endpoints
aws elasticache describe-replication-groups \
--replication-group-id web-cache \
--query 'ReplicationGroups[].{
Primary:NodeGroups[].PrimaryEndpoint.Address,
Reader:ReaderEndpoint.Address
}'
# Application connection pattern:
# write_client = redis.Redis(host='primary-endpoint', port=6379)
# read_client = redis.Redis(host='reader-endpoint', port=6379)Prosessen for automatisk failover
Når primærnoden svikter (oppdages av ElastiCache i løpet av sekunder ved hjelp av helsesjekker), velger automatisk failover én av lesereplikaene og gjør den til primærnode. Prosessen er som følger: (1) den valgte replikaen gjøres til primærnode, (2) DNS-oppføringen for det primære endepunktet oppdateres slik at den peker på den nye primærnoden (TTL ~1 sekund), (3) den gamle primærnoden erstattes med en ny replika. Den totale failovertiden er vanligvis 30–60 sekunder. Applikasjoner som bruker DNS-navnet til det primære endepunktet, kobler til automatisk igjen når DNS-endringen er propagert — det er ikke nødvendig å hardkode IP-adresser.
# Test failover manually (triggers primary failover)
aws elasticache test-failover \
--replication-group-id web-cache \
--node-group-id 0001
# Monitor failover events
aws elasticache describe-events \
--source-identifier web-cache \
--source-type replication-group \
--duration 60 \
--query 'Events[].{Time:Date,Message:Message}'Plassering av Multi-AZ-replikaer
For maksimal robusthet bør De fordele replikaene på flere Availability Zones. Når De aktiverer Multi-AZ for en replikeringsgruppe, plasserer ElastiCache automatisk primærnoden og replikaene i forskjellige AZ-er. Hvis en hel AZ blir utilgjengelig, gjør failover en replika fra en AZ som fortsatt er tilgjengelig, til primærnode. De kan også angi foretrukne AZ-er eksplisitt for hver node når replikeringsgruppen opprettes, ved å bruke alternativet --preferred-cache-cluster-a-zs.
# Create replication group with explicit AZ placement
aws elasticache create-replication-group \
--replication-group-id ha-redis \
--replication-group-description 'Multi-AZ Redis' \
--num-cache-clusters 3 \
--cache-node-type cache.r7g.xlarge \
--engine redis \
--automatic-failover-enabled \
--multi-az-enabled \
--preferred-cache-cluster-a-zs us-east-1a us-east-1b us-east-1c \
--cache-subnet-group-name multi-az-subnetsHva er Redis Cluster Mode
Redis Cluster Mode Enabled (CME) partisjonerer datasettet på tvers av flere nodegrupper (shards), som hver inneholder én primærnode og opptil 5 replikaer. Dette er Redis' løsning for horisontal sharding. Cluster Mode gjør det mulig å overskride minnekapasiteten til én enkelt node — De kan ha opptil 500 nodegrupper med 500 GB hver, slik at én Redis-klynge kan inneholde opptil 500 × 500 GB = 250 TB data. Cluster Mode mangedobler også skrivegjennomstrømmingen, siden hver nodegruppe behandler skrivinger uavhengig for sitt nøkkelområde.
# Create a Redis Cluster Mode Enabled replication group
# with 3 shards, each with 1 primary and 2 replicas
aws elasticache create-replication-group \
--replication-group-id clustered-redis \
--replication-group-description 'Cluster mode: 3 shards x 3 nodes' \
--num-node-groups 3 \
--replicas-per-node-group 2 \
--cache-node-type cache.r7g.large \
--engine redis \
--automatic-failover-enabled \
--multi-az-enabled \
--cache-subnet-group-name multi-az-subnetsHash-slots og nøkkelfordeling
Redis Cluster Mode deler nøkkelområdet inn i 16 384 hash-slots. Hver nodegruppe eier et sammenhengende område med hash-slots. Når en nøkkel skrives, beregner Redis CRC16(key) % 16384 for å finne hash-slottet og dermed nodegruppen som er ansvarlig. Applikasjonen Deres må bruke en Redis-klient med klyngestøtte (som redis-py-cluster eller Jedis i cluster mode) som kjenner slottilordningen og sender hver kommando til riktig node. Standardklienter returnerer MOVED-videresendingsfeil hvis de sender en nøkkel til feil shard.
# Python cluster-aware client example
# pip install redis[hiredis]
# from redis.cluster import RedisCluster
# cluster_client = RedisCluster(
# host='clustered-redis.abc123.clustercfg.use1.cache.amazonaws.com',
# port=6379,
# decode_responses=True
# )
# The client automatically resolves slot-to-node mapping
# cluster_client.set('user:1', 'Alice') # routes to correct shard
# cluster_client.get('user:1') # routes to correct shardCluster Mode kontra ikke-Cluster Mode
Til SAA-C03-eksamen velger De non-cluster mode når: dataene får plass på én enkelt node (< ~400 GB etter at margin er trukket fra), De trenger et enkelt oppsett med primærnode og replika, eller applikasjonen bruker komplekse operasjoner med flere nøkler (transaksjoner som går på tvers av flere nøkler, krever at alle nøklene ligger i samme slot). Velg cluster mode når: datasettet overskrider minnet på én enkelt node, De trenger horisontal skalering av skrivegjennomstrømmingen, eller De forventer fremtidig vekst som vil kreve resharding på nett. Cluster mode støtter at shards legges til uten nedetid (online resharding).
# Scale out a cluster-mode Redis by adding shards
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id clustered-redis \
--node-group-count 5 \
--apply-immediately \
--resharding-configuration \
NodeGroupId=0004,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
NodeGroupId=0005,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c
# No downtime — slots are migrated incrementallyGlobal Datastore for replikering på tvers av regioner
ElastiCache Global Datastore utvider Redis-replikering på tvers av flere AWS-regioner. De utpeker én region som primærklynge og legger til sekundærklynger i andre regioner. Skriveoperasjoner går til primærklyngen, mens sekundærklyngene mottar asynkron replikering med en typisk forsinkelse på under ett sekund. Sekundærklynger kan håndtere lokale leseoperasjoner med svært lav ventetid. Global Datastore gjør det mulig å bygge globale applikasjoner der brukere på ulike kontinenter leser fra den nærmeste regionen, samt DR på tvers av regioner, der en sekundærklynge kan gjøres til primærklynge hvis den primære regionen svikter.
# Create a Global Datastore (adds a secondary region to an existing cluster)
aws elasticache create-global-replication-group \
--global-replication-group-id-suffix my-global-cache \
--primary-replication-group-id prod-redis
# Add a secondary cluster in another region
aws elasticache create-replication-group \
--replication-group-id prod-redis-eu \
--replication-group-description 'EU secondary' \
--global-replication-group-id ldgnf-my-global-cache \
--region eu-west-1Redis Pub/Sub i stor skala
I en Redis-replikeringsgruppe uten klyngemodus distribueres Pub/Sub-meldinger til alle replikaer – alle abonnenter på alle noder mottar meldinger som publiseres til en kanal. I Cluster Mode er Pub/Sub imidlertid begrenset til keyspace notifications, og kanalbasert Pub/Sub fungerer bare innenfor én enkelt shard med mindre De bruker Redis 7+ with Pub/Sub sharding (SSUBSCRIBE / SPUBLISH for shard-bevisst Pub/Sub). Dette er en viktig begrensning når De utformer Pub/Sub-løsninger i stor skala med klyngemodus.
# Keyspace notification (fires when a key expires)
# Enable in parameter group: notify-keyspace-events Ex
# Subscriber in Python:
# pubsub = redis_client.pubsub()
# pubsub.psubscribe('__keyevent@0__:expired')
# for message in pubsub.listen():
# if message['type'] == 'pmessage':
# expired_key = message['data']
# print(f'Key expired: {expired_key}')Overvåking av replikeringsforsinkelse
Overvåk CloudWatch-metrikken ReplicationLag på lesereplikaer for å sikre at de holder tritt med primærklyngen. En forsinkelse på mer enn noen få sekunder tyder på en flaskehals på replikaen (overbelastet node, nettverksproblemer eller for mange skriveoperasjoner til at replikaen rekker å behandle dem). I scenarier med global datastore bør De overvåke GlobalDatastoreReplicationLag. Høy replikeringsforsinkelse betyr at lesereplikaer kan returnere foreldede data – noe som er viktig for applikasjoner som forventer eventual consistency innenfor stramme grenser.
# Monitor replication lag for all replicas
aws cloudwatch get-metric-statistics \
--namespace AWS/ElastiCache \
--metric-name ReplicationLag \
--dimensions Name=ReplicationGroupId,Value=web-cache \
--statistic Maximum \
--period 60 \
--start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)
# Alert if ReplicationLag > 10 secondsSkalering av replikeringsgrupper
De kan skalere vertikalt (endre nodetype) eller skalere horisontalt (legge til eller fjerne replikaer). Når nodetypen endres, kreves et kall til modify-replication-group, og det oppstår en kort failover når endringen brukes umiddelbart – primærnoden erstattes med en ny node av den nye typen. Det er mulig å legge til replikaer mens systemet er i drift, uten nedetid. Når De skalerer fra modus uten klynger til klyngemodus, må De opprette en ny gruppe i klyngemodus og migrere – det finnes ingen konvertering på stedet mellom klyngemodus og modus uten klynger.
# Scale up node type with maintenance window
aws elasticache modify-replication-group \
--replication-group-id web-cache \
--cache-node-type cache.r7g.xlarge \
--apply-immediately false
# Add a read replica
aws elasticache increase-replica-count \
--replication-group-id web-cache \
--new-replica-count 4 \
--apply-immediatelyKort kontroll
Test forståelsen Deres av AWS Solutions Architect-konsepter (SAA-C03) fra denne leksjonen.
Oppsummering av leksjonen
I denne leksjonen lærte De at replikeringsgrupper gir leseskalering via replikaer og høy tilgjengelighet via automatisk failover med endepunkter for primær- og lesetilgang, at Cluster Mode deler data på opptil 500 nodegrupper ved hjelp av 16 384 hash-plasser for å skalere horisontalt utover minnet til én enkelt node, og at Global Datastore replikerer data på tvers av regioner for globale leseoperasjoner med lav ventetid og DR på tvers av regioner. Deretter skal vi se nærmere på hurtigbufferstrategier: lazy loading og write-through.
Lær deg Cloud & IT Cert Prep med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 150
- Leksjoner
- 600
Ofte stilte spørsmål
Er leksjonen «ElastiCache Redis-replikeringsgrupper og klyngemodus» gratis?
Ja – hele teksten i «ElastiCache Redis-replikeringsgrupper og klyngemodus» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Cloud & IT Cert Prep-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.
Hva lærer jeg i «ElastiCache Redis-replikeringsgrupper og klyngemodus»?
Bygg en Redis-replikeringsgruppe for skalering av lesing, og aktiver klyngemodus for å dele data på tvers av flere nodegrupper Du øver på Cloud & IT Cert Prep med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Cloud & IT Cert Prep?
Ingen tidligere erfaring er nødvendig. Cloud & IT Cert Prep på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.
Hvor lang tid tar leksjonen «ElastiCache Redis-replikeringsgrupper og klyngemodus»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Cloud & IT Cert Prep-leksjonen?
Ja. Alle Cloud & IT Cert Prep-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Redis kontra Memcached: Velg riktig motor
- ElastiCache Redis-replikeringsgrupper og klyngemodus
- Bufringsstrategier: Lazy Loading og Write-Through
- Øktlagring og mønstre for ledertavler