Azure Managed Redis-arkitektur

Azure Managed Redis körs på Redis Enterprise-stacken , vilket ger betydande fördelar jämfört med communityversionen av Redis. Följande information innehåller mer information om hur Azure Managed Redis är konstruerat, inklusive information som kan vara användbar för användare.

Jämförelse med Azure Cache for Redis

Nivåerna Basic, Standard och Premium i Azure Cache for Redis byggdes på communityversionen av Redis. Den här versionen av Redis för communitybruk har flera betydande begränsningar, inklusive att vara enkeltrådad. Detta minskar prestanda avsevärt och gör skalning mindre effektivt eftersom fler vCPU:er inte utnyttjas fullt ut av tjänsten. En typisk Azure Cache for Redis-instans använder en arkitektur som den här:

Observera att två virtuella datorer används – en primär och en replik. Dessa virtuella datorer kallas även "noder". Den primära noden innehåller den huvudsakliga Redis-processen och accepterar alla skrivningar. Replikeringen utförs asynkront till repliknoden för att tillhandahålla en säkerhetskopieringskopia under underhåll, skalning eller oväntat fel. Varje nod kan bara köra en enskild Redis-serverprocess på grund av den enkeltrådade designen av communityn Redis.

Arkitektoniska förbättringar av Azure Managed Redis

Azure Managed Redis använder en mer avancerad arkitektur som ser ut ungefär så här:

Det finns flera skillnader:

• Varje virtuell dator (eller "nod") kör flera Redis-serverprocesser (kallas "shards") parallellt. Flera shards möjliggör effektivare användning av vCPU:er på varje virtuell dator och högre prestanda.
• Alla primära Redis-shards finns inte på samma virtuella dator/nod. I stället distribueras primära och replika skärvor över båda noderna. Eftersom primära shards använder fler CPU-resurser än replikskärvor gör den här metoden att fler primära shards kan köras parallellt.
• Varje nod har en proxyprocess med höga prestanda för att hantera shards, hantera anslutningshantering och utlösa självåterställning.

Den här arkitekturen ger både högre prestanda och även avancerade funktioner som aktiv geo-replikering

Klustring

Varje Azure Managed Redis-instans är internt konfigurerad för att använda klustring på alla nivåer och SKU:er. Azure Managed Redis baseras på Redis Enterprise, som kan använda flera shards per nod. Det inkluderar mindre instanser som bara har konfigurerats för att använda en enda shard. Klustring är ett sätt att dela upp data i Redis-instansen mellan flera Redis-processer, även kallade "horisontell partitionering". Azure Managed Redis erbjuder tre klusterprinciper som avgör vilket protokoll som är tillgängligt för Redis-klienter för anslutning till cacheinstansen.

Klusterriktlinjer

Azure Managed Redis erbjuder tre klustringsprinciper: OSS, Enterprise och Icke-klustrad. OSS-klusterprincip rekommenderas för de flesta program eftersom den stöder högre maximalt dataflöde, men det finns fördelar och nackdelar med varje version.

OSS-klustringsprincipen implementerar samma Redis-kluster-API som Azure Cache for Redis-nivåer. Redis-kluster-API:et gör att Redis-klienten kan ansluta direkt till shards på varje Redis-nod, vilket minimerar svarstiden och optimerar nätverkets dataflöde, vilket gör att dataflödet kan skalas nästan linjärt när antalet shards och vCPU:er ökar. OSS-klustringsprincipen ger vanligtvis bästa svarstid och dataflödesprestanda. OSS-klusterprincipen kräver dock att klientbiblioteket stöder Redis-kluster-API:et. I dag stöder nästan alla Redis-klienter Redis-kluster-API:et, men kompatibilitet kan vara ett problem för äldre klientversioner eller specialiserade bibliotek.

OSS-klustringsprincipen kan inte användas med RediSearch-modulen.

OSS-klustringsprotokollet kräver att klienten gör rätt shardanslutningar. Den första anslutningen sker via port 10000. Anslutning till enskilda noder görs med portar i 85XX-intervallet. 85xx-portarna kan ändras med tiden och bör inte hårdkodas i ditt program. Redis-klienter som stöder klustring använder kommandot KLUSTERNODER för att fastställa de exakta portarna som används för de primära partitionerna och replikskärvorna och göra shardanslutningarna åt dig.

Enterprise-klustringsprincipen är en enklare konfiguration som använder en enda slutpunkt för alla klientanslutningar. Med hjälp av enterprise-klustringsprincipen dirigeras alla begäranden till en enda Redis-nod som sedan används som proxy och som internt dirigerar begäranden till rätt nod i klustret. Fördelen med den här metoden är att den gör att Azure Managed Redis ser icke-klustrad ut för användare. Det innebär att Redis-klientbibliotek inte behöver stöd för Redis-klustring för att få några av prestandafördelarna med Redis Enterprise. Om du använder en enskild slutpunkt ökar kompatibiliteten bakåt och gör anslutningen enklare. Nackdelen är att proxyn för en nod kan vara en flaskhals, antingen i beräkningsanvändningen eller nätverkets dataflöde.

Enterprise-klustringsprincipen är den enda som kan användas med RediSearch-modulen. Även om enterprise-klusterprincipen gör att en Azure Managed Redis-instans verkar vara icke-klustrad för användare, har den fortfarande vissa begränsningar med kommandon med flera nycklar.

Principen för icke-klustrad klustring lagrar data på varje nod utan horisontell partitionering. Det gäller endast cacheminnen med storleken 25 GB och mindre. Scenarier för att använda icke-klustrad klustringsprincip är:

• När du migrerar från en Redis-miljö som inte är fragmenterad. Till exempel de icke-shardade topologierna för Basic-, Standard- och Premium-SKU:er i Azure Cache for Redis.
• När du kör kommandon över flera platser i stor utsträckning och delar upp data i fragment, skulle det orsaka fel. Till exempel MULTI-kommandona.
• När du använder Redis som meddelandekö och inte behöver horisontell partitionering.

Övervägandena för att använda icke-klustrad princip är:

• Detta gäller endast för Azure Managed Redis-nivåer som är mindre än eller lika med 25 GB.
• Det är inte lika högpresterande som andra klustringsprinciper, eftersom processorer bara kan använda flera trådar med Redis Enterprise-programvaran när cachen är fragmenterad.
• Om du vill skala upp Azure Managed Redis-cachen måste du först ändra klusterprincipen.
• Om du flyttar från en icke-klustrad topologi av typen Basic, Standard eller Premium kan du överväga att använda OSS-kluster för att förbättra prestandan. Icke-klustrade konfigurationer bör endast användas om programmet inte kan stöda OSS- eller Enterprise-topologier.

Skala ut eller lägga till noder

Redis Enterprise-kärnprogramvaran kan antingen skala upp (med större virtuella datorer) eller skala ut (genom att lägga till fler noder/virtuella datorer). I slutändan utför antingen skalningsåtgärden samma sak – att lägga till mer minne, fler vCPU:er och fler shards. På grund av den här redundansen erbjuder Azure Managed Redis inte möjlighet att styra det specifika antalet noder som används i varje konfiguration. Den här implementeringsinformationen är abstrakt för användaren för att undvika förvirring, komplexitet och suboptimala konfigurationer. I stället är varje SKU utformad med en nodkonfiguration för att maximera vCPU:er och minne. Vissa SKU:er för Azure Managed Redis använder bara två noder, medan vissa använder fler.

Kommandon med flera tangenter

Eftersom Azure Managed Redis-instanser är utformade med en klustrad konfiguration, kan det uppstå CROSSSLOT undantag för kommandon som behandlar flera nycklar. Beteendet varierar beroende på vilken klustringsprincip som används. Om du använder OSS-klustringsprincipen kräver kommandon med flera nycklar att alla nycklar mappas till samma hash-plats.

Du kan också se CROSSSLOT fel med klustringsprincipen för företag. Endast följande flernyckelkommandon tillåts mellan platser med Enterprise-klustring: DEL, MSET, MGET, EXISTS, UNLINKoch TOUCH.

I Active-Active databaser kan skrivkommandon med flera nycklar (DEL, , MSETUNLINK) bara köras på nycklar som finns i samma fack. Följande kommandon med flera nycklar tillåts dock på flera platser i Active-Active databaser: MGET, EXISTSoch TOUCH. Mer information finns i Databaskluster.

Shardingkonfiguration

Varje SKU för Azure Managed Redis är konfigurerad för att köra ett visst antal Redis-serverprocesser, shards parallellt. Relationen mellan dataflödesprestanda, antalet shards och antalet tillgängliga vCPU:er för varje instans är komplicerad. Om du lägger till shards ökar vanligtvis prestandan eftersom Redis-åtgärder kan köras parallellt. Men om shards inte kan köra kommandon eftersom inga vCPU:er är tillgängliga för att köra kommandon kan prestandan faktiskt sjunka. I följande tabell visas partitioneringskonfigurationen för varje Azure Managed Redis SKU. Dessa shards är kartlagda för att optimera användningen av varje vCPU medan man reserverar vCPU-cykler för Redis Enterprise-proxy, hanteringsagent och operativsystemuppgifter som också påverkar prestanda.

* Dessa nivåer finns i offentlig förhandsversion.

Körs utan aktiverat läge för hög tillgänglighet

Det går att köra utan hög tillgänglighet (HA) aktiverat. Det innebär att Redis-instansen inte har replikering aktiverad och inte har åtkomst till tillgänglighetsavtalet. Vi rekommenderar inte att du kör i icke-HA-läge utanför utvecklings-/testscenarier. Du kan inte inaktivera hög tillgänglighet i en instans som redan har skapats. Du kan dock aktivera hög tillgänglighet i en instans som inte har den. Eftersom en instans som körs utan hög tillgänglighet använder färre virtuella datorer/noder kan vCPU:er inte användas lika effektivt, så prestandan kan vara lägre.

Reserverat minne

På varje Azure Managed Redis-instans reserveras cirka 20% av det tillgängliga minnet som en buffert för icke-cacheåtgärder, till exempel replikering under redundansväxling och aktiv geo-replikeringsbuffert. Den här bufferten hjälper till att förbättra cacheprestanda och förhindra minnessvält.

Skala ned

Nedskalning stöds för närvarande inte på Azure Managed Redis. Mer information finns i Begränsningar för skalning av Azure Managed Redis.

Flash-optimerad nivå

Nivån Flash Optimized använder både NVMe Flash Storage och RAM. Eftersom flashlagring är kostnadseffektivt kan du med nivån Flash-optimerad offra viss prestanda för att uppnå bättre priseffektivitet.

På Flash Optimized-instanser finns 20% av cacheutrymmet på RAM-minnet, medan de andra 80% använder Flash Storage. Alla nycklar lagras på RAM-minnet, medan värdena kan lagras antingen i Flash Storage eller RAM. Redis-programvaran avgör intelligent platsen för värdena. Frekventa värden som används ofta lagras på RAM-minnet, medan kalla värden som används mindre ofta sparas på Flash. Innan data läses eller skrivs måste det flyttas till RAM-minnet och bli hett data.

Eftersom Redis optimerar för bästa prestanda fyller instansen först upp det tillgängliga RAM-minnet innan objekt läggs till i Flash Storage. Att fylla RAM-minnet först har några konsekvenser för prestanda:

• Bättre prestanda och kortare svarstid kan inträffa vid testning med låg minnesanvändning. Testning med en fullständig cacheinstans kan ge lägre prestanda eftersom endast RAM-minne används i testfasen med låg minnesanvändning.
• När du skriver mer data till cacheminnet minskar andelen data i RAM-minnet jämfört med Flash Storage, vilket vanligtvis gör att även svarstid och dataflödesprestanda minskar.

Arbetsbelastningar som passar bra för Flash Optimized-nivån

Arbetsbelastningar som sannolikt kommer att köras bra på flashoptimerad nivå har ofta följande egenskaper:

• Läsintensivt, med ett högt förhållande mellan läskommandon och skrivkommandon.
• Åtkomst fokuserar på en delmängd nycklar som används mycket oftare än resten av datamängden.
• Relativt stora värden jämfört med nyckelnamn. (Eftersom nyckelnamn alltid lagras i RAM kan stora värden bli en flaskhals för minnestillväxt.)

Arbetsbelastningar som inte passar bra för Flash Optimized-nivån

Vissa arbetsbelastningar har åtkomstmönster som inte är lika optimerade för designen av Flashoptimerad nivå:

• Skriva tunga arbetsbelastningar.
• Slumpmässiga eller enhetliga dataåtkomstmönster i de flesta datamängder.
• Långa nyckelnamn med relativt små värdestorlekar.

Relaterat innehåll

• Skala en Azure Managed Redis-instans