Delen via


Azure Cache voor Redis en betrouwbaarheid

Azure Cache voor Redis biedt een gegevensarchief in het geheugen op basis van de Redis-software (Remote Dictionary Server). Het is een beveiligde gegevenscache en berichtenbroker die hoge doorvoer en lage latentie toegang biedt tot gegevens voor toepassingen.

Belangrijke concepten en best practices die ondersteuning bieden voor betrouwbaarheid zijn onder andere:

De volgende secties bevatten ontwerpoverwegingen, een controlelijst voor configuratie en aanbevolen configuratieopties die specifiek zijn voor Azure Cache voor Redis.

Overwegingen bij het ontwerpen

Het Azure Cache voor Redis Sla (Service Level Agreements) heeft alleen betrekking op caches van de Standard- en Premium-laag. De Basic-laag wordt niet gedekt.

Redis is een cache in het geheugen voor sleutelwaardeparen en heeft standaard hoge beschikbaarheid (HA), met uitzondering van de Basic-laag. Er zijn drie lagen voor Azure Cache voor Redis:

  • Basic: niet aanbevolen voor productieworkloads. De Basic-laag is ideaal voor:

    • Eén knooppunt
    • Meerdere grootten
    • Ontwikkeling
    • Testen
    • Niet-kritieke workloads
  • Standaard: Een gerepliceerde cache in een primaire en secundaire configuratie met twee knooppunten die wordt beheerd door Microsoft, met een SLA voor hoge beschikbaarheid.

  • Premium: bevat alle functies van de Standard-laag en bevat de volgende andere functies:

    • Snellere hardware en prestaties in vergelijking met de Basic- of Standard-laag.
    • Grotere cachegrootte, tot 120GB.
    • Gegevenspersistentie, waaronder Redis Database File (RDB) en Append Only File (AOF).
    • VNET-ondersteuning.
    • Clustering
    • Geo-replicatie: een secundaire cache bevindt zich in een andere regio en repliceert gegevens van de primaire voor herstel na noodgevallen. Als u een failover wilt uitvoeren naar de secundaire, moeten de caches handmatig worden ontkoppeld en is de secundaire cache beschikbaar voor schrijfbewerkingen. De toepassing die naar Redis wordt geschreven, moet worden bijgewerkt met de cache van de secundaire verbindingsreeks.
    • Beschikbaarheidszones: implementeer de cache en replica's in verschillende beschikbaarheidszones.

      Notitie

      Standaard heeft elke implementatie één replica per shard. Persistentie, clustering en geo-replicatie zijn op dit moment allemaal uitgeschakeld met implementaties met meer dan één replica. Uw knooppunten worden gelijkmatig verdeeld over alle zones. U moet een aantal zones voor het aantal >= replica's hebben.

    • Importeren en exporteren.

Microsoft garandeert ten minste 99.9% de tijd dat klanten verbinding hebben tussen de cache-eindpunten en de internetgateway van Microsoft.

Controlelijst

Hebt u Azure Cache voor Redis geconfigureerd met het oog op tolerantie?


  • Updates plannen.
  • De cache bewaken en waarschuwingen instellen.
  • Implementeer de cache binnen een VNET.
  • Evalueer een partitioneringsstrategie in redis-cache.
  • Configureer Gegevenspersistentie om een kopie van de cache op te slaan in Azure Storage of gebruik geo-replicatie, afhankelijk van de bedrijfsvereiste.
  • Implementeer beleid voor opnieuw proberen in de context van uw Azure Redis Cache.
  • Gebruik één statische of singleton-implementatie van de verbindingsmultiplexer met Redis en volg de handleiding met aanbevolen procedures.
  • Raadpleeg How to admin Azure Cache voor Redis (Azure Cache voor Redis beheren).

Configuratieaanbeveling

Bekijk de volgende tabel met aanbevelingen om uw Azure Cache voor Redis configuratie te optimaliseren voor servicebetrouwbaarheid:

Aanbeveling Beschrijving
Updates plannen. Plan de dagen en tijden waarop Redis Server-updates worden toegepast op de cache, die geen Azure-updates of updates voor het VM-besturingssysteem bevat.
De cache bewaken en waarschuwingen instellen. Stel waarschuwingen in voor uitzonderingen, hoog CPU-gebruik, hoog geheugengebruik, serverbelasting en verwijderde sleutels voor inzicht over wanneer de cache moet worden geschaald. Als de cache moet worden geschaald, is het belangrijk om te weten wanneer de schaal moet worden aangepast, omdat dit het CPU-verbruik verhoogt tijdens de schaalgebeurtenis voor het migreren van gegevens.
Implementeer de cache binnen een VNET. Geeft de klant meer controle over het verkeer dat verbinding kan maken met de cache. Zorg ervoor dat het subnet voldoende adresruimte beschikbaar heeft om de cacheknooppunten en shards (cluster) te implementeren.
Evalueer een partitioneringsstrategie in redis-cache. Het partitioneren van een Redis-gegevensarchief omvat het splitsen van de gegevens over exemplaren van de Redis-server. Elk exemplaar bestaat uit één partitie. Azure Redis Cache abstraheert de Redis-services achter een gevel en maakt ze niet rechtstreeks beschikbaar. De eenvoudigste manier om partitioneren te implementeren is het maken van meerdere exemplaren van Azure Redis Cache maken en de gegevens hierover te verdelen. U kunt elk gegevensitem koppelen met een ID (een partitiesleutel) die aangeeft in welke cache het gegevensitem staat. De client-toepassingslogica kan vervolgens deze ID gebruiken voor het routeren van aanvragen naar de gewenste partitie. Dit schema is eenvoudig, maar als het partitieschema verandert (bijvoorbeeld als er extra Azure Redis Cache-exemplaren worden gemaakt), moeten clienttoepassingen mogelijk opnieuw worden geconfigureerd.
Configureer Gegevenspersistentie om een kopie van de cache op te slaan in Azure Storage of gebruik geo-replicatie, afhankelijk van de bedrijfsvereiste. Gegevenspersistentie: als de hoofd- en replica opnieuw worden opgestart, worden de gegevens automatisch geladen vanuit het opslagaccount. Geo-replicatie: de secundaire cache moet worden losgekoppeld van de primaire cache. De secundaire wordt nu de primaire en kan schrijfbewerkingen ontvangen.
Implementeer beleid voor opnieuw proberen in de context van uw Azure Redis Cache. De meeste Azure-services en client-SDK's bevatten een mechanisme voor opnieuw proberen. Deze mechanismen verschillen omdat elke service verschillende kenmerken en vereisten heeft. Elk mechanisme voor opnieuw proberen is afgestemd op een specifieke service.
Raadpleeg How to admin Azure Cache voor Redis (Azure Cache voor Redis beheren). Krijg inzicht in hoe gegevensverlies kan optreden bij het opnieuw opstarten van de cache en hoe u de toepassing kunt testen op tolerantie.

Bronartefacten

Gebruik de volgende query om Redis-exemplaren te identificeren die zich niet in de Premium-laag bevinden:

Resources 
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'

Volgende stap