Azure Cache for Redis och tillförlitlighet
Azure Cache for Redis tillhandahåller ett minnesinternt datalager baserat på Redis-programvaran (Remote Dictionary Server). Det är en säker datacache och asynkron meddelandekö som ger hög dataflödes- och låg latensåtkomst till data för program.
Viktiga begrepp och metodtips som stöder tillförlitlighet ä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 nyckel/värde-par och har hög tillgänglighet (HA), som standard, med undantag för 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 perfekt 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 avlänkas 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 cachen 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 distribueras jämnt över alla zoner. Du bör ha ett antal repliker
>=av zoner. - 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 återhämtning i åtanke?
- Schemalägg uppdateringar.
- Övervaka cachen och ange aviseringar.
- Distribuera cachen i ett virtuellt nätverk.
- Utvärdera en partitioneringsstrategi i Redis Cache.
- Konfigurera datapersistence för att spara en kopia av cacheminnet till Azure Storage eller använd geo-replikering, beroende på affärsbehovet.
- Implementera återförsöksprinciper i kontexten för Azure Redis Cache.
- Använd en statisk implementering eller en singleton-implementering av multiplexeranslutningen till Redis och följ metodtipsguiden.
- Läs Administrera Azure Cache for Redis.
Konfigurationsrekommendationer
Utforska följande tabell med rekommendationer för att optimera din Azure Cache for Redis konfiguration för tjänstens tillförlitlighet:
| Rekommendation | Description |
|---|---|
| Schemalägg uppdateringar. | Schemalägg de dagar och tider som Redis Server-uppdateringar ska tillämpas på cacheminnet, 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 avlägsnade nycklar för att få insikter om när cachen ska skalas. Om cachen behöver skalas är det viktigt att förstå när den ska skalas eftersom den ökar PROCESSORn 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 cachenoder och shards (kluster). |
| Utvärdera en partitioneringsstrategi i Redis Cache. | Partitionering av ett Redis-datalager innebär att data delas upp mellan redis-serverns instanser. Varje instans utgör en enda partition. Azure Redis Cache abstraherar Redis-tjänsterna bakom en fasad och exponerar dem inte direkt. Det enklaste sättet att partitionera är att skapa flera instanser av Azure Redis Cache och sprida data mellan dem. Du kan koppla varje dataobjekt till en identifierare (en partitionsnyckel) som anger vilket cacheminne som lagrar dataobjektet. Klientprogramlogiken kan sedan använda identifieraren och omdirigera begäranden till rätt partition. Det här schemat är enkelt, men om partitioneringsschemat ändras (till exempel om extra Azure Redis Cache-instanser skapas) kan klientprogram behöva konfigureras om. |
| Konfigurera datapersistence för att spara en kopia av cacheminnet till Azure Storage eller använd geo-replikering, beroende på affärsbehovet. | Datapersistence: om huvudservern 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. |
| Implementera återförsöksprinciper i kontexten för Azure Redis Cache. | De flesta Azure-tjänster och klient-SDK:er har en återförsöksmekanism. Dessa mekanismer skiljer sig åt eftersom varje tjänst har olika egenskaper och krav. Varje återförsöksmekanism är inställd på en specifik tjänst. |
| Läs Administrera 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'