Utveckling med Azure Managed Redis

  • Gäller för: ✅ Azure Managed Redis

I den här artikeln beskrivs hur du utvecklar kod för Azure Managed Redis.

Anslutningsresiliens och serverbelastning

När du utvecklar klientprogram bör du överväga relevanta metodtips för anslutningsresiliens och hantering av serverbelastning.

Överväg fler nycklar och mindre värden

Azure Managed Redis fungerar bäst med mindre värden. Om du vill sprida data över flera nycklar kan du överväga att dela upp större datasegment i mindre segment. Mer information om idealvärdesstorlek finns i den här artikeln.

Stor storlek på begäran eller svar

En stor begäran eller ett stort svar kan orsaka timeouter. Anta till exempel att du konfigurerar timeout-värdet på klienten som 1 sekund. Programmet begär två nycklar (till exempel A och B) samtidigt (med samma fysiska nätverksanslutning). De flesta klienter stöder pipelining av begäranden, där både begäranden A och B skickas en efter en utan att vänta på deras svar. Servern skickar tillbaka svaren i samma ordning. Om svaret A är stort kan det förbruka det mesta av tidsgränsen för senare begäranden.

I följande exempel skickas begäranden A och B snabbt till servern. Servern börjar skicka svar A och B snabbt. På grund av dataöverföringstider måste svaret B vänta tills svaret A får en timeout, även om servern svarade snabbt.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Det här mönstret för begäran och svar är svårt att mäta. Du kan instrumentera klientkoden för att spåra stora begäranden och svar.

Lösningar för stora svarsstorlekar varierar men omfattar:

  • Optimera programmet för ett stort antal små värden i stället för några få stora värden.
  • Öka storleken på den virtuella datorn (VM) för att få högre bandbreddsfunktioner.
    • Mer bandbredd på den virtuella klient- eller serverdatorn kan minska dataöverföringstiderna för större svar.
    • Jämför din aktuella nätverksanvändning på båda datorerna med gränserna för din aktuella storlek på virtuell dator. Högre bandbredd enbart på servern eller enbart på klienten kanske inte är tillräckligt.
  • Öka antalet anslutningsobjekt som programmet använder.
    • Använd en rundgångsmetod för att göra förfrågningar över olika anslutningsobjekt.

Använd pipelining

Försök att välja en Redis-klient som stöder Redis-pipelining. Pipelining hjälper till att effektivt använda nätverket och få bästa möjliga dataflöde.

Undvik dyra åtgärder

Vissa Redis-åtgärder, till exempel KOMMANDOT NYCKLAR , är dyra och du bör undvika dem. För några saker att tänka på kring tidskrävande kommandon, se tidskrävande kommandon.

Välj en lämplig nivå

Azure Managed Redis erbjuder nivåerna Minnesoptimerad, Balanserad, Beräkningsoptimerad och FlashOptimerad. Mer information om hur du väljer en nivå finns i Skala. Testa prestanda för att välja rätt nivå och verifiera anslutningsinställningar. Mer information finns i Prestandatestning.

Välj ett lämpligt tillgänglighetsläge

Azure Managed Redis erbjuder alternativet att aktivera eller inaktivera konfiguration med hög tillgänglighet. När du inaktiverar läget för hög tillgänglighet replikeras inte data i AMR-instansen och Redis-instansen är inte tillgänglig under underhåll. Alla data i AMR-instansen går förlorade under planerat eller oplanerat underhåll. Inaktivera endast hög tillgänglighet för dina utvecklings- eller testarbetsbelastningar. Prestanda för Redis-instanser med hög tillgänglighet kan också vara lägre på grund av bristen på datareplikering som är avgörande för att fördela belastningen mellan primär data- och replikdatashard.

Klienten i samma region som Redis-instansen

Leta upp din Redis-instans och ditt program i samma region. Att ansluta till en Redis i en annan region kan avsevärt öka svarstiden och minska tillförlitligheten.

Även om du kan ansluta utanför Azure rekommenderas det inte, särskilt när du använder Redis för att påskynda programmets eller databasens prestanda. Om du använder Redis-servern som ett nyckel-/värdearkiv kanske svarstiden inte är det primära problemet.

Förlita dig på värdnamn, inte offentlig IP-adress

IP-adressen som tilldelats cacheminnet kan ändras till följd av en skalningsåtgärd eller serverdelsförbättring. Förlita dig på värdnamnet i stället för en explicit offentlig eller privat IP-adress. Den konfigurerade statiska IP-adressen för en cache i ett virtuellt nätverk är inte en oföränderlig garanti och kan ändras under vissa åtgärder, även om ändringar är sällsynta.

Värdnamn i Azure Managed Redis ser ut så här: <DNS name>.<Azure region>.redis.azure.net

Använda TLS-kryptering

Azure Managed Redis kräver TLS-krypterad kommunikation som standard. TLS-versionerna 1.2 och 1.3 stöds för närvarande. Om klientbiblioteket eller verktyget inte stöder TLS är det möjligt att aktivera okrypterade anslutningar.

Övervaka minnesanvändning, cpu-användningsstatistik, klientanslutningar och nätverksbandbredd

När du använder Azure hanterad Redis-instans i produktion anger du aviseringar för måtten Använd minnesprocent, CPU och Anslutna klienter. Om dessa mått konsekvent överstiger 75 % bör du överväga att skala instansen till en större minnesnivå eller en bättre dataflödesnivå. Mer information finns i när du ska skala. Mer information om hur minne rapporteras och hur du planerar kapacitet finns i Minneshantering.

Överväg att aktivera datapersistence eller säkerhetskopiering av data

Redis är utformat för tillfälliga data som standard, vilket innebär att dina data i sällsynta fall kan gå förlorade på grund av olika omständigheter som underhåll eller avbrott. Om ditt program är känsligt för dataförlust aktiverar du datapersistence eller regelbunden säkerhetskopiering av data med hjälp av dataexportåtgärden.

Funktionen för datapersistence ger automatiskt en snabb återställningspunkt för data när ett cacheminne går ned. Snabbåterställningen är möjlig eftersom funktionen lagrar RDB- eller AOF-filen på en hanterad disk som den monterar på cacheinstansen. Användare kan inte komma åt beständighetsfiler på disken och ingen annan AMR-instans kan använda dem.

Många kunder vill använda beständighet för att utföra regelbundna säkerhetskopieringar av data i cacheminnet. Använd inte datapersistence för det här ändamålet. Använd i stället funktionen import/export . Du kan exportera kopior av data i RDB-format direkt till ditt valda lagringskonto och utlösa dataexporten så ofta du behöver. Du kan utlösa export antingen från portalen eller med hjälp av CLI-, PowerShell- eller SDK-verktygen.

Klientbiblioteksspecifik vägledning

Mer information finns i Azure Hanterade Redis-klientbibliotek.

Relaterat innehåll

  • Last updated on