ElastiCache Redis-replikeringsgrupper och klusterläge

När den primära noden slutar fungera (vilket ElastiCache upptäcker inom några sekunder via hälsokontroller) väljer automatisk redundansväxling en av läsreplikerna och befordrar den till primär nod. Befordringsprocessen ser ut så här: (1) den valda repliken befordras till primär nod, (2) DNS-posten för den primära slutpunkten uppdateras så att den pekar på den nya primära noden (TTL ~1 sekund), (3) den gamla primära noden ersätts med en ny replik. Den totala tiden för redundansväxlingen är vanligtvis 30–60 sekunder. Applikationer som använder DNS-namnet för den primära slutpunkten återansluter automatiskt när DNS-ändringen har spridits — hårdkodade IP-adresser behövs inte.

För maximal motståndskraft bör ni fördela repliker över flera Availability Zones. När ni aktiverar Multi-AZ för en replikeringsgrupp placerar ElastiCache automatiskt den primära noden och replikerna i olika AZ:er. Om en hel AZ blir otillgänglig befordrar redundansväxlingen en replik från en AZ som fortfarande fungerar. Ni kan även uttryckligen ange önskade AZ:er för varje nod när ni skapar replikeringsgruppen med alternativet --preferred-cache-cluster-a-zs.

Redis Cluster Mode Enabled (CME) partitionerar datamängden över flera nodgrupper (shards), där varje grupp innehåller en primär nod och upp till 5 repliker. Detta är Redis lösning för horisontell sharding. Cluster Mode gör det möjligt att överskrida minneskapaciteten hos en enda nod — ni kan ha upp till 500 nodgrupper med 500 GB vardera, vilket innebär att ett enda Redis-kluster kan innehålla upp till 500 × 500 GB = 250 TB data. Cluster Mode mångdubblar dessutom skrivgenomströmningen eftersom varje nodgrupp självständigt bearbetar skrivningar för sitt nyckelintervall.

Redis Cluster Mode delar upp nyckelutrymmet i 16 384 hashplatser. Varje nodgrupp äger ett sammanhängande intervall av hashplatser. När en nyckel skrivs beräknar Redis CRC16(key) % 16384 för att avgöra hashplatsen och därmed den ansvariga nodgruppen. Applikationen måste använda en klustermedveten Redis-klient (till exempel redis-py-cluster eller Jedis i klusterläge) som känner till platskartan och dirigerar varje kommando till rätt nod. Standardklienter returnerar MOVED-omdirigeringsfel om de skickar en nyckel till fel shard.

För SAA-C03-provet väljer ni icke-klusterläge när: era data ryms på en enda nod (< ~400 GB efter marginal), ni behöver en enkel primär-/replikauppsättning eller applikationen använder komplexa åtgärder med flera nycklar (transaktioner som omfattar flera nycklar kräver att alla nycklar finns på samma plats). Välj klusterläge när: datamängden överskrider minnet på en enda nod, ni behöver horisontell skalning av skrivgenomströmningen eller förväntar er framtida tillväxt som kommer att kräva omsharding online. Klusterläge stöder tillägg av shards utan driftstopp (online-omsharding).

ElastiCache Global Datastore utökar Redis-replikering till flera AWS-regioner. Ni utser en region till primärt kluster och lägger till sekundära kluster i andra regioner. Skrivningar går till det primära klustret, medan sekundära kluster tar emot asynkron replikering med en typisk fördröjning på under en sekund. Sekundära kluster kan hantera lokala läsningar med mycket låg latens. Global Datastore möjliggör globala applikationer där användare på olika kontinenter läser från närmaste region, samt DR mellan regioner där Ni kan befordra ett sekundärt kluster till primärt om den primära regionen slutar fungera.

I en Redis-replikeringsgrupp utan klustring distribueras pub/sub-meddelanden till alla repliker — alla prenumeranter på alla noder tar emot meddelanden som publiceras till en kanal. I Cluster Mode är pub/sub däremot begränsat till keyspace-notifieringar, och kanalbaserad pub/sub fungerar endast inom en enskild shard, såvida Ni inte använder Redis 7+ med Pub/Sub-sharding (SSUBSCRIBE / SPUBLISH för shard-medveten pub/sub). Detta är en viktig begränsning när Ni utformar pub/sub i stor skala med klusterläge.

Övervaka CloudWatch-måttet ReplicationLag på läsrepliker för att säkerställa att de hinner med det primära klustret. En fördröjning på mer än några sekunder tyder på en flaskhals på repliken, till exempel en överbelastad nod, nätverksproblem eller fler skrivningar än repliken hinner behandla. I scenarier med Global Datastore övervakar Ni GlobalDatastoreReplicationLag. Hög replikeringsfördröjning innebär att läsrepliker kan returnera inaktuella data — något som är viktigt för applikationer som förväntar sig eventual consistency inom snäva gränser.

Ni kan skala vertikalt (ändra nodtyp) eller skala horisontellt (lägga till eller ta bort repliker). Om Ni ändrar nodtypen krävs ett anrop till modify-replication-group, och det medför en kort failover om ändringen tillämpas omedelbart — den primära noden ersätts med en ny nod av den nya typen. Att lägga till repliker kan göras online utan driftstopp. När Ni skalar från läge utan klustring till klusterläge måste Ni skapa en ny grupp i klusterläge och migrera — det finns ingen konvertering på plats mellan klusterläge och läge utan klustring.

I den här lektionen har Ni lärt Er att replikeringsgrupper möjliggör lässkalning via repliker och hög tillgänglighet via automatisk failover med primära slutpunkter och läsar-slutpunkter, att Cluster Mode delar upp data över upp till 500 nodgrupper med hjälp av 16 384 hash-slots för horisontell skalning bortom en enskild nods minne, samt att Global Datastore replikerar data mellan regioner för globala läsningar med låg latens och DR mellan regioner. Härnäst utforskar vi cachningsstrategierna lazy loading och write-through.