Azure Cache for Redis och driftseffektivitet
Azure Cache for Redis tillhandahåller ett minnesinternt datalager baserat på Redis-programvaran (Remote Dictionary Server). Det är en säker datacache och meddelandekö som ger högt dataflöde och åtkomst med låg svarstid till data för program.
Metodtips som stöder driftseffektivitet är:
Följande avsnitt innehåller designöverväganden, en checklista för konfiguration och rekommenderade konfigurationsalternativ som är specifika för Azure Cache for Redis.
Designöverväganden
Serviceavtalen för Azure Cache for Redis (SLA) omfattar endast cacheminnen på Standard- och Premium-nivå. Basic-nivån omfattas inte.
Redis är en minnesintern cache för nyckelvärdepar och har hög tillgänglighet (HA), som standard, förutom Basic-nivån. Det finns tre nivåer för Azure Cache for Redis:
Grundläggande: Rekommenderas inte för produktionsarbetsbelastningar. Basic-nivån är idealisk för:
- Enkel nod
- Flera storlekar
- Utveckling
- Test
- Icke-kritiska arbetsbelastningar
Standard: En replikerad cache i en primär och sekundär konfiguration med två noder som hanteras av Microsoft, med ett serviceavtal med hög tillgänglighet.
Premium: Innehåller alla standardnivåfunktioner och innehåller följande andra funktioner:
- Snabbare maskinvara och prestanda jämfört med Basic- eller Standard-nivån.
- Större cachestorlek, upp till
120GB
. - Datapersistence, som inkluderar Redis Database File (RDB) och Append Only File (AOF).
- VNET-stöd.
- Klustring
- Geo-replikering: En sekundär cache finns i en annan region och replikerar data från den primära för haveriberedskap. Om du vill redundansväxlara till den sekundära cachen måste cacheminnena vara olänkade manuellt och sedan är den sekundära tillgänglig för skrivningar. Programmet som skriver till Redis måste uppdateras med den sekundära cachen anslutningssträng.
- Tillgänglighetszoner: Distribuera cacheminnet och replikerna mellan tillgänglighetszoner.
Anteckning
Som standard har varje distribution en replik per shard. Beständighet, klustring och geo-replikering är inaktiverade just nu med distributioner som har fler än en replik. Noderna fördelas jämnt över alla zoner. Du bör ha ett antal zoner för antal repliker
>=
. - Importera och exportera.
Microsoft garanterar minst 99.9%
den tid då kunderna har anslutning mellan cacheslutpunkterna och Microsofts Internet-gateway.
Checklista
Har du konfigurerat Azure Cache for Redis med driftseffektivitet i åtanke?
- Schemalägg uppdateringar.
- Övervaka cachen och ange aviseringar.
- Distribuera cachen i ett virtuellt nätverk.
- Använd rätt cachelagringstyp (lokal, i roll, hanterad, redis) i din lösning.
- Konfigurera datapersistence för att spara en kopia av cacheminnet till Azure Storage eller använd Geo-Replication, beroende på affärskravet.
- Använd en statisk implementering eller singleton-implementering av anslutnings multiplexern till Redis och följ metodtipsguiden.
- Läs Så här administrerar du Azure Cache for Redis.
Konfigurationsrekommendationer
Utforska följande tabell med rekommendationer för att optimera din Azure Cache for Redis konfiguration för driftseffektivitet:
Rekommendation | Description |
---|---|
Schemalägg uppdateringar. | Schemalägg de dagar och tider som Redis Server-uppdateringar ska tillämpas på cachen, som inte innehåller Azure-uppdateringar eller uppdateringar av operativsystemet för den virtuella datorn. |
Övervaka cachen och ange aviseringar. | Ange aviseringar för undantag, hög CPU-användning, hög minnesanvändning, serverbelastning och borttagna nycklar för insikter om när cachen ska skalas. Om cacheminnet behöver skalas är det viktigt att förstå när du skalar eftersom det ökar CPU under skalningshändelsen för att migrera data. |
Distribuera cachen i ett virtuellt nätverk. | Ger kunden mer kontroll över trafiken som kan ansluta till cachen. Kontrollera att undernätet har tillräckligt med adressutrymme för att distribuera cachenoderna och shardsna (klustret). |
Använd rätt cachelagringstyp (lokal, i roll, hanterad, redis) i din lösning. | För distribuerade program används vanligtvis en eller båda av följande strategier när data cachelagras: – Använda en privat cache, där data lagras lokalt på den dator som kör en instans av ett program eller en tjänst. – Använda en delad cache som fungerar som en gemensam källa som kan nås av flera processer och datorer. I båda fallen kan cachelagring utföras på klientsidan och på serversidan. Cachelagring på klientsidan sker via processen som tillhandahåller användargränssnittet för ett system. Det kan vara en webbläsare eller ett skrivbordsprogram (lokalt program). Cachelagring på serversidan sker via processen som tillhandahåller företagstjänsterna av fjärrtyp. |
Konfigurera datapersistence för att spara en kopia av cacheminnet till Azure Storage eller använd Geo-Replication, beroende på affärskravet. | Datapersistence: Om originalet och repliken startas om läses data in automatiskt från lagringskontot. Geo-replikering: Den sekundära cachen måste vara olänkad från den primära. Den sekundära blir nu den primära och kan ta emot skrivningar. |
Läs Så här administrerar du Azure Cache for Redis. | Förstå hur dataförlust kan inträffa med cacheomstarter och hur du testar programmet för återhämtning. |
Källartefakter
Om du vill identifiera Redis-instanser som inte finns på Premium-nivån använder du följande fråga:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'